it is not worked about 1 year already. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 52690 [details] emerge info
Created attachment 52691 [details] emerge log ANY version of arj failed with same symptoms
and if you try it with LDFLAGS="" ?
could not be compiled, NEVER, even without any flags...
same here (but on amd64) ... tried with and without flags, all versions, nada :(
Re-assign.
*** Bug 102768 has been marked as a duplicate of this bug. ***
This thing does not work at all... Fix or punt from portage.
*** Bug 85452 has been marked as a duplicate of this bug. ***
arj-3.10.22 incl. two Patches from Debian in cvs. Brian: Is it a known "feature", that Portage (2.0.53_rc7) incorrectly treats arj-3.10g as a higher version number than arj-3.10.xy, or is it worth opening a bug report?
it's known, i just didnt really care was hoping to get the latest version working and then we'd just punt the others
OK, success with 3.10.22 (tried w/ gcc-3.4.4 hardened/non-hardened and gcc-4.0.2) - thanks Carlo! Lets punt the b0rked ones.
> incorrectly treats arj-3.10g as a higher version number than arj-3.10.xy *cough* it's higher (eg, it's behaviour is correct). cmp("3", "3") == 0 cmp("10g", "10") == 1 is the rough logic, and reasoning.
(In reply to comment #13) > *cough* it's higher (eg, it's behaviour is correct). > cmp("3", "3") == 0 > cmp("10g", "10") == 1 > > is the rough logic, and reasoning. That's why I asked, if this is a "feature". I'm convinced that it would make more sense to treat the char as an adendum to the version number, instead treating it as being part of it. But well... Arch herders: Could you give arj 3.10.22 some intensive testing and mark stable, if nothing holds you back, please. I think I'll remove the older versions as soon as possible, since they all don't work.
Will test, however I tested 3.10.18 using stable SPARC keywords and everything appeared to be working fine.
I'm not really comfortable marking something stable that has only been in the tree for a few days. 3.10.18 seems to work on x86 stable. Is there any reason we can't just look to stable 3.10.21 and punt 3.10g?
*** Bug 112784 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > I'm not really comfortable marking something stable that has only been in the > tree for a few days. 3.10.18 seems to work on x86 stable. This miserably fails to compile on anything but gcc-3.3.x; so it fails on amd64 stable, e.g.
Okay, well, the initial fix for archs that have gcc-3.3 stable is for the completely broken version (3.10g) to be removed so the other one will be installed. I would like to have 3.10.21 in the tree for awhile before we consider it to be stable on x86.
(In reply to comment #15) > Will test, however I tested 3.10.18 using stable SPARC keywords and everything > appeared to be working fine. I didn't test this version, but it's 18 months old and .22 is from June this year, so it will have some testing already... (In reply to comment #16) > Is there any reason > we can't just look to stable 3.10.21 and punt 3.10g? Yeah. .21 needs the two patches applied to .22 and three other ones as well. I'd point you to the thread, but bugs.debian.org seems not to be accessable it the moment.
I was referring to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318366 In the mean time there's another bug report against .22: "arj: broken on 64-bit platforms" http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=339815
(in reply to <a href="http://bugs.gentoo.org/show_bug.cgi?id=84142#c14">comment #14</a> I tried both versions 3.10g and 3.10.22 for x86. They comile well and they also work very well for me. I tested it with some large dirs with lots of files and subdirs.
Just committed arj-3.10.22-r1. Please test and mark stable as you like, but hopefully soon. ;)
(In reply to comment #23) > Just committed arj-3.10.22-r1. Please test and mark stable as you like, but > hopefully soon. ;) Works like a charm form me (stable x86). The only thing was that portage gave me the error: arj-3.10.22.ebuild not in digest. This was solved after: # ebuild arj-3.10.22.ebuild digest But i guess this shouldn't happen after an emerge sync.
Stable on SPARC.
Carsten: could you punt 3.10g since all archs have atleast 3.10.18 stable? Otherwise, people won't be getting the "newer" versions :) Also, 3.10.22-r1 is stable on x86.
works well now
Please leave this bug open, other archs still need to fix this problem.
Marked 3.10.22-r1 stable on ppc.
Please keep the bug open until amd64 found the time.
Stable on amd64, sorry for the delay.
