Created attachment 401710 [details] 3proxy-0.7.1.2.ebuild Ebuild for new stable version (15 feb 2015).
Created attachment 401712 [details, diff] fixed hardcoded CFLAGS, fixed hardcoded installation into a /usr/local
https://github.com/gentoo/gentoo-portage-rsync-mirror/pull/107
I wish co-maintain this package.
You are welcome to maintain this package as proxy however currently 1. Patch 3proxy-0.7.1.2-gentoo.patch appears to be lacking to line that execute the diff cmd as a line 1. Either way the patch didn't take. . 2. The ebuild submitted in its current form simply lacks the phases src_compile and src_install present in the prior ebuilds. Because the patch doesn't take I cannot even attempt a build test.
(In reply to Ian Delaney from comment #4) > You are welcome to maintain this package as proxy however currently > > 1. Patch 3proxy-0.7.1.2-gentoo.patch appears to be lacking to line that > execute the diff cmd as a line 1. Either way the patch didn't take. . > 2. The ebuild submitted in its current form simply lacks the phases > src_compile and src_install present in the prior ebuilds. > > Because the patch doesn't take I cannot even attempt a build test. But when I emerge 3proxy from local overlay with this path, it seems that the patch works...
(In reply to Ian Delaney from comment #4) > You are welcome to maintain this package as proxy however currently > > 1. Patch 3proxy-0.7.1.2-gentoo.patch appears to be lacking to line that > execute the diff cmd as a line 1. Either way the patch didn't take. . > 2. The ebuild submitted in its current form simply lacks the phases > src_compile and src_install present in the prior ebuilds. > > Because the patch doesn't take I cannot even attempt a build test. I have done the following steps: 1) download and unpack tarball with sources into ~/3proxy 2) cd 3proxy 3) cp Makefile.Linux Makefile.Linux.orig 4) nano Makefile.Linux 5) diff -Nru Makefile.Linux.orig Makefile.Linux >> 3proxy-0.7.1.2-gentoo.patch 6) cd src 7) cp stringtable.c stringtable.c.orig 8) nano stringtable.c 9) diff -Nru stringtable.c.orig stringtable.c >> ../3proxy-0.7.1.2-gentoo.patch 10) cp ../3proxy-0.7.1.2-gentoo.patch <my localoverlay>/net-proxy/3proxy/files/ What's wrong?
This patch can substitute with 2 sed statements and achieve the same end. The Makefile.Linux has line endings that clash with path / epatch and its options. This has been confirmed by at least one other dev. I think the file Makefile.unix used in previous versions might be fine. src_prepare() { sed -e 's:-g -O2 -c:-g -c:' -e 's:-Wall -O2:-Wall:' -e 's/; make ;/; ${MAKE} ;/' \ -e 's: /usr/local::' -e 's:/share:/usr/share:' \ -i Makefile.Linux || die sed -e 's:/usr/local/etc/:/etc/:' \ -i src/stringtable.c || die } This is in fact lighter weighter than classic patch and has equivalemt functionality. It appears the changes in stringtable.c assist in a dafeult compile install working fine without the phases. I will attempt to confirm that more before I would commit. For now there is this that needs a 'clean up'; >>> Completed installing 3proxy-0.7.1.2 into /mnt/gen2/TmpDir/portage/net-proxy/3proxy-0.7.1.2/image/ * QA Notice: Pre-stripped files found: * /bin/3proxy * /bin/countersutil * /bin/dighosts * /bin/ftppr * /bin/mycrypt * /bin/pop3p * /bin/proxy * /bin/socks * /bin/tcppm * /bin/udppm ecompressdir: bzip2 -9 /usr/share/man This I believe can be made fixed by setting the apt var. The 3proxy-0.6.1.ebuild suffers a different * QA Notice:
(In reply to Ian Delaney from comment #7) > > This I believe can be made fixed by setting the apt var. The > 3proxy-0.6.1.ebuild > suffers a different * QA Notice: set a apt QA var to ignore this warnings? oh, please NO! instead, please check why this package try to strip, and disable/fix it. usually we let portage handle the strip-the-symbols job
I said this can be made fixed by setting the apt var, however I never said it was the optimum solution. Maintainer dlan sets you good advice. Normally the use of a patch is preferred however this file you have patched in this package appears to be the exception to the rule. I suggest you remake a path for the ebuild incorporating this sed statement, We can do it ourselves, but the idea here is to allow you to manage it.
Right now this ebuild install binaries into /bin/, which isn't nice. In case of installing into /usr/bin/ it conflicts with /usr/bin/proxy from net-libs/libproxy package. Current 3proxy ebuilds in portage rename all 3proxy binaries and man pages by adding "3proxy-" prefix (except for 3proxy binary itself) - I suppose this is done to work around this conflict. In case Yuri Tsimbaloff doesn't want to continue his work on this ebuild then I can try to fix it and continue to support it (I'm using 3proxy, need this version to fix bug in 0.5.3k, so I'll have to support it in my own overlay anyway - if it won't be added to main portage, of course).
(In reply to Alex Efros from comment #10) > Right now this ebuild install binaries into /bin/, which isn't nice. > > In case Yuri Tsimbaloff doesn't want to continue his work on this ebuild > then I can try to fix it and continue to support it (I'm using 3proxy, need > this version to fix bug in 0.5.3k, so I'll have to support it in my own > overlay anyway - if it won't be added to main portage, of course). At this point, the bug has no designated proxy maintainer. You both qualify, and Yuri Tsimbaloff declared his interest in Comment 3. You offer is equally valid. Yuri Tsimbaloff has been offered some advice / feedback then silence for 3 months. We here are not to know of the cause since so many are possible. You (plural) are welcome to contribute either independently as co-contributors. The concern now is that the first has stopped supplying input. So feel free to pick up from where Yuri left off or restart. What we don't yet have is a working ebuild. Tip. Preparing ebuilds in a personal overlay is prone to not working when dropped into a system like mine that relies on the actual portage tree. Work your ebuild in your overlay then drop it into your proper portage tree and repeat run tests. Then make patches for presentation here. Drawing from a customised repo and dropping them into SRC_URI may not always work. Have seen this a few times. Any patches you present need work as presented so that any dev can patch without replying "your patch didn't work", then stalling any progress.
Alex, do you wish to pursue maintaining this package through the Proxy Maintainers[0] project? If so, please attach an ebuild to this bug and we can organise getting it committed. For reference, it appears that Yuri is unable to do so based on the closure of the PR mentioned in comment 2. 0: https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers
Created attachment 428790 [details] 3proxy-0.7.1.2.ebuild Also available at https://github.com/gentoo/gentoo/pull/1118
Created attachment 428794 [details] 3proxy-0.7.1.2.ebuild cleanup for EAPI 6
Created attachment 428796 [details] 3proxy-0.7.1.4.ebuild bump to latest 0.7.x (not supported anymore except for security fixes)
Created attachment 428798 [details] 3proxy-0.8.6.ebuild bump to latest stable (0.8.x) this ebuild require own patch file, to be attached next
Created attachment 428800 [details, diff] files/3proxy-0.8.6-gentoo.patch
commit 7a1d01d00d0cb307935c30e3f38ea47b23acc9fc (HEAD -> master) Author: Patrice Clement <monsieurp@gentoo.org> AuthorDate: Wed Mar 23 18:20:39 2016 +0000 Commit: Patrice Clement <monsieurp@gentoo.org> CommitDate: Wed Mar 23 18:21:28 2016 +0000 net-proxy/3proxy: Grant maintainership to Alex Efros <powerman@powerman.name>. This commit merges a string of commits pulled from gentoo/gentoo#1118 and closes bug 547234. Gentoo-Bug: https://bugs.gentoo.org/547234 Package-Manager: portage-2.2.26 Signed-off-by: Patrice Clement <monsieurp@gentoo.org> net-proxy/3proxy/metadata.xml | 27 +++++++++++++++++++++------ 1 file changed, 21 insertions(+), 6 deletions(-)
> net-proxy/3proxy: Grant maintainership to Alex Efros <powerman@powerman.name>. > Assignee: maintainer-needed@gentoo.org → powerman-asdf@yandex.ru I'm using different emails in bugzilla and github - hope this won't be an issue.
(In reply to Alex Efros from comment #19) > > net-proxy/3proxy: Grant maintainership to Alex Efros <powerman@powerman.name>. > > Assignee: maintainer-needed@gentoo.org → powerman-asdf@yandex.ru > > I'm using different emails in bugzilla and github - hope this won't be an > issue. No, this won't be an issue so long as your Bugzilla address at least remains monitored/in-use. If you need to change address, you will need to have the metadata of any packages you maintain updated with the address to match your Bugzilla account (for bug assignment). Thanks for the contribution, and welcome to the Proxy Maintainers project!
This has been fixed. Thanks for the heads up.
Well, it turns out while copying patch files from my PR to portage tree \r was stripped from line endings. Personally I hate \r too, but it's used in 3proxy sources which we needs to patch. So, how this should be handled? Is I should reopen this bug, open new one, and which options I've to fix it (rewrite patch using sed? change patch file itself on-the-fly by adding \r? use .patch.gz to keep \r from being stripped? add some magic flag to ebuild to avoid stripping \r from patches?)? * Applying 3proxy-0.8.6-gentoo.patch ... * Failed Patch: 3proxy-0.8.6-gentoo.patch ! * ( /usr/portage/net-proxy/3proxy/files/3proxy-0.8.6-gentoo.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/net-proxy/3proxy-0.8.6/temp/3proxy-0.8.6-gentoo.patch.out # cat /var/tmp/portage/net-proxy/3proxy-0.8.6/temp/3proxy-0.8.6-gentoo.patch.out ... checking file Makefile.Linux Hunk #1 FAILED at 10 (different line endings). Hunk #2 FAILED at 39 (different line endings). 2 out of 2 hunks FAILED checking file src/stringtable.c Hunk #1 FAILED at 38 (different line endings). 1 out of 1 hunk FAILED
Since it's a problem with the fix of this bug, re-opening this is fine. Can you attach a gzipped version of the working patch so I can have a look? Thanks.
(In reply to Sam Jorna (wraeth) from comment #23) > Can you attach a gzipped version of the working patch so I can have a look? I've just tried to download patch attached to this bug https://bugs.gentoo.org/attachment.cgi?id=428800 and it is correct (1512 bytes, md5sum a4509afb9613aa07c53241a95bee6426). Same file was in my PR. So I don't really understand why you need gzipped version, but I'll attach it now, just in case.
Created attachment 428884 [details] 3proxy-0.8.6-gentoo.patch.gz
I'm not sure what caused the line endings to be flipped in the first place, but this should now be resolved (I tested the patch applied before pushing). commit 1cf47799c54ca2484060751d56d673da928f3831 Author: Sam Jorna <wraeth@gentoo.org> Date: Thu Mar 24 15:15:02 2016 +1100 net-proxy/3proxy: add fixed patch, bug 547234 When originally added, line endings in patch somehow got modified.
(In reply to Sam Jorna (wraeth) from comment #26) > I'm not sure what caused the line endings to be flipped in the first place, > but this should now be resolved (I tested the patch applied before pushing). It is resolved - for 0.8.6. But 3proxy-0.7.1.2-gentoo.patch also needs to be fixed in same way. Attached to this bug version https://bugs.gentoo.org/attachment.cgi?id=401712 is correct (1536 bytes) while one currently in portage is not (1500 bytes).
Fixed the remaining patch, also verified that all 3proxy ebuilds now complete prepare stage successfully. commit 1493b3ed1027bf1f52b28f87ff0e2c4947cd6a95 Author: Sam Jorna <wraeth@gentoo.org> Date: Thu Mar 24 20:06:22 2016 +1100 net-proxy/3proxy: fix broken patch, #547234 Gentoo-bug: 547234 Package-Manager: portage-2.2.28 Signed-off-by: Sam Jorna <wraeth@gentoo.org>
