fvwm-2.5.26 has been in portage for almost a year now and there are no open bugs (also most of the open bugs against fvwm seem to be outdated/invalid/unrelated) 14 May 2008; David Shakaryan <omp@gentoo.org> +fvwm-2.5.26.ebuild: Version bump; copied from my subversion repository. While new versions of FVWM seem to be added to portage regularly, they aren't being stabilised. The last version that was marked stable was released over 2.5 years ago ( http://fvwm.org/news/#2.5.18 ) Fvwm 2.5.18 released by upstream on 11-Sep-2006 and stabilised in portage from 14th to 20th Nov. 2006 for various arch. Reproducible: Always Steps to Reproduce: 1. emerge fvwm 2. 3. Actual Results: installs a 2.5 year old release of fvwm 2.5.18-r1 http://fvwm.org/news/#2.5.18 / Expected Results: should install 2.5.26 which has been in portage for almost a year now
I've requested this many times myself, and right now, the only version marked stable in portage is 2.5.18, which is, whithout any doubt the less stable of the versions around that lives in the tree. 2.5.18 was released 2006-09-11. Lots of bugs have been resolved since then and there's absolutely no sense in recommending .18 as the stable version. If because of the gentoo policy we can't get .27 stabilized yet (it's not even in the tree), we should at least stabilize .26, and include .27, I already opened another bug for that some time ago. http://bugs.gentoo.org/show_bug.cgi?id=261301
*** Bug 276933 has been marked as a duplicate of this bug. ***
Looks like a simple use dep is needed in the ebuild to avoid bug 238905
Created attachment 197087 [details] checks if imlib was compiled with USE=gtk Fixes bug #238905
(In reply to comment #3) > Looks like a simple use dep is needed in the ebuild to avoid bug 238905 > Hopefully it's fixed now. Thanks for the quick response to #276933.
I will request stabilisation of a fixed 2.5.27 ebuild in August. Please remind me if it slips me. :)
(In reply to comment #6) > I will request stabilisation of a fixed 2.5.27 ebuild in August. Please remind > me if it slips me. :) > Jesús: Scrap what we talked about in email then. Christian already did everything. I've edited metadata.xml to reflect reality now though ;) Thanks Christian ;)
(In reply to comment #7) > (In reply to comment #6) > > I will request stabilisation of a fixed 2.5.27 ebuild in August. Please remind > > me if it slips me. :) > > > > Jesús: Scrap what we talked about in email then. Christian already did > everything. I've edited metadata.xml to reflect reality now though ;) > > Thanks Christian ;) Ok then, one or another way, which count is to get it done. Thanks to both of you.
(In reply to comment #6) > I will request stabilisation of a fixed 2.5.27 ebuild in August. Please remind > me if it slips me. :) > I shall. Just to keep all the pieces together (even for myself since my memory isn't the best), I link here the two related bugs that we need to consider when stabilizing this critter. xlockmore needs stabilization as well: http://bugs.gentoo.org/show_bug.cgi?id=277043 fvwm needs some cleaning in the keywords: http://bugs.gentoo.org/show_bug.cgi?id=277004 I also filled this one in my way to stabilize xlockmore, take a look since segfaults are never a good thing when you are planning on stabilization: http://bugs.gentoo.org/show_bug.cgi?id=277061
(In reply to comment #9) > (In reply to comment #6) > > I will request stabilisation of a fixed 2.5.27 ebuild in August. Please remind > > me if it slips me. :) > > > > I shall. > > Just to keep all the pieces together (even for myself since my memory isn't the > best), I link here the two related bugs that we need to consider when > stabilizing this critter. > > xlockmore needs stabilization as well: > http://bugs.gentoo.org/show_bug.cgi?id=277043 > > fvwm needs some cleaning in the keywords: > http://bugs.gentoo.org/show_bug.cgi?id=277004 > > I also filled this one in my way to stabilize xlockmore, take a look since > segfaults are never a good thing when you are planning on stabilization: > http://bugs.gentoo.org/show_bug.cgi?id=277061 > Just to keep track of the things, xlockmore has been fixed by removing the unicode support, and it has been stabilized for amd64 as well. So, now there's nothing stopping us from stabilizing fvwm 2.5.27 once the time to do so comes.
Created attachment 199432 [details] proposal of ebuild for 2.5.27 with the right keywords + imlib[gtk] fix Since it is coming the time to stabilize it in some days, I submit the ebuild with keywords corrected, this also includes the imlib[gtk] fix of the previous ebuild, so marking it as deprecated in favor of this new one.
(In reply to comment #11) > Created an attachment (id=199432) [edit] > proposal of ebuild for 2.5.27 with the right keywords + imlib[gtk] fix > > Since it is coming the time to stabilize it in some days, I submit the ebuild > with keywords corrected, this also includes the imlib[gtk] fix of the previous > ebuild, so marking it as deprecated in favor of this new one. > arch teams must stabilize the package and change keywords, not the maintainer. :)
Please stabilise.
x86 stable
ppc stable
(In reply to comment #15) > ppc stable > Please, stabilize amd64.
That xlockmore bug (#277043) should've included alpha since it's a dep there, too. Another unmentioned dep is >=ftgl-2.1.3_rc5, so I tested and added that. In summary: stabilized ftgl-2.1.3_rc5, xlockmore-5.28 and fvwm-2.5.27 on alpha.
ppc64 done
amd64 stable
In the install phase, x11-wm/fvwm-2.5.27 gives the following warning: chmod: cannot access `/var/tmp/portage/x11-wm/fvwm-2.5.27/image//etc/X11/Sessions/fvwm': No such file or directory >>> Completed installing fvwm-2.5.27 into /var/tmp/portage/x11-wm/fvwm-2.5.27/image/ Apparently, the ebuild needs to issue the command dodir /etc/X11/Sessions before creating the file (and probably add || die to the echo call while there to prevent things like this in the future). Should I proceed and mark it stable?
(In reply to comment #20) > Apparently, the ebuild needs to issue the command dodir /etc/X11/Sessions > before creating the file (and probably add || die to the echo call while there > to prevent things like this in the future). Thanks for the note, it has been fixed with a revbump (stable keywords transferred). > Should I proceed and mark it stable? Yes, please.
(In reply to comment #21) > Thanks for the note, it has been fixed with a revbump (stable keywords > transferred). Thanks for the quick reply. However, dodir shouldn't try to create a directory called fvwm under /etc/X11/Sessions.
+ 11 Sep 2009; Jeremy Olexa <darkside@gentoo.org> fvwm-2.5.27-r1.ebuild: + Fix dodir call, Comment #22 bug 266937
sparc stable
(In reply to comment #23) > + 11 Sep 2009; Jeremy Olexa <darkside@gentoo.org> fvwm-2.5.27-r1.ebuild: > + Fix dodir call, Comment #22 bug 266937 Still won't build on amd64 or x86 at the dodir call in the ebuild, during the install phase; dies with the message that fvwm is already a directory in /etc/X11/Sessions.
(In reply to comment #25) > (In reply to comment #23) > > + 11 Sep 2009; Jeremy Olexa <darkside@gentoo.org> fvwm-2.5.27-r1.ebuild: > > + Fix dodir call, Comment #22 bug 266937 > > Still won't build on amd64 or x86 at the dodir call in the ebuild, during the > install phase; dies with the message that fvwm is already a directory in > /etc/X11/Sessions. No problems here.
> > Still won't build on amd64 or x86 at the dodir call in the ebuild, during the > > install phase; dies with the message that fvwm is already a directory in > > /etc/X11/Sessions. > > No problems here. It builds successfully now, with the new dodir line: dodir /etc/X11/Sessions in place of the old offending line: dodir /etc/X11/Sessions/${PN} Thanks!
ia64 stable, closing
