please start marking releases

[blshkv]

It would be good to have release tarballs to mark milestones. It helps a lot for distro packaging.
Thanks.

[darkk]

Yep, I do that as soon as some build is "stable": tested and documented.
Last implemented feature (TPROXY + UDP) is not documented and breaks builds on another platforms as soon as it's Linux-specific, it also requires proper privilege dropping to avoid running as root.
0.5 is not "release-ready" yet :(

[blshkv]

the reason why I asked is that it were no new updates since April. Perhaps you might consider marking it as "beta" at some point. That would help.
I've added a "live" ebuild to Pentoo (https://code.google.com/p/pentoo/source/detail?r=3474) for now, but we don't like when stuff "breaks" obviously.
Thanks.

[darkk]

I understand you.
You can get tarball for release X at https://github.com/darkk/redsocks/tarball/release-${X}, mask 9999 ebuild as ~ and have 0.4 as latest stable ebuild.
If you're maintainer, you can subscribe to mailing list http://librelist.com/browser/redsocks to be notified about new releases.
Subscription procedure is described at http://librelist.com/ mainpage.

[blshkv]

That will do, thanks a lot. Feel free to close the issue.

[blshkv]

btw, it would also help if you could structure the tarball in a "standard" way, such as: /name-version/tree instead of "darkk-redsocks-e0b284d/tree". Hope I'm not asking too much ;-)

[darkk]

I'm afraid I can't control it. Github generates tarball with $USER-$REPO-$HASH/tree directory and I see no option to change it (I may be wrong).

Is this default github's directory layout too annoying to maintain?

[blshkv]

not at all, as long as you keep it the same with each new version.
update: actually - yes, $HASH will be different every time. That would be a problem :(

I'm a bit surprised about that github behavior and was sure it would give a full control. Here is an example of a different structure:
https://github.com/lattera/libhijack/downloads
(we had to add a S="${WORKDIR}/${P}/src" workaround)

Anyway, I have pushed the updated ebuild. Thanks for the quick responds and the tool.

[darkk]

I have to upset you: $HASH changes in every release, e.g. release-0.3 unpacks to darkk-redsocks-8839230.
I have not used gentoo, so I don't know if it's possible to set S to something like "-redsocks-"

libhijack repacks their tarballs to get sane directory structure, I can do same. I googled a bit, seems, it's only possible way to get sane directory names in the tarball, but it's possible to script it: http://developer.github.com/v3/repos/downloads/

I'll write the script and close the issue when it'll be ready.

[darkk]

https://github.com/darkk/redsocks/downloads is full of tarballs :)

[blshkv]

sweet ;-)

[blshkv]

Hi, could you have a look at this issue again?
github changed that: https://github.com/blog/1302-goodbye-uploads So there is no need in this trick anymore.
However, something wrong with currently tagged sources, like this one: https://github.com/darkk/redsocks/archive/release-0.4.tar.gz
The root folder is "redsocks-release-0.4"

[przemoc]

However, something wrong with currently tagged sources, like this one: https://github.com/darkk/redsocks/archive/release-0.4.tar.gz
The root folder is "redsocks-release-0.4"

It's because Leonid went with unusual tag naming. With v0.4 tag it would get a proper redsocks-0.4.tar.gz with redsocks-0.4 directory in it.

[darkk]

Przemysław, thanks for hint! I did not know that feature of github.

[przemoc]

I'm not even sure it's documented anywhere actually. My tests showed that their tar.gz archives for tags are created with following (or working in the same manner, i.e. giving the same exact archive) command:

git archive --prefix $PROJNAME-$VTAG/ --format tar.gz $TAG -o $PROJNAME-$VTAG.tar.gz

where VTAG is TAG stripped from front v when it's used in vN.M... format (cannot say about other v prefixed formats as I haven't tried vLETTERS for instance :>). Tags like v0.0.3b work fine too.

It's sad that Bitbucket is still doing something different, though. After all GitHub removal of upload feature for Downloads is quite inconvenient and that's why Bitbucket is useful (beside being another repo mirror, of course).

Side note: I still make my own release archives (using the same git archive command as I've shown above), because I don't like to be too dependent on external services, but if GitHub provides the exact same files for them, then it's double win.