slrn 0.9.9 was released, see attached ebuild. Generally copied over the slrn-0.9.8.1_p1.ebuild but inserted stripping of MAKEOPTS=-jx to -j1, otherwise a race condition occurs in install process: make[1]: Entering directory `/usr/src/tmp/portage/net-nntp/slrn-0.9.9/work/slrn-0.9.9/src' /usr/src/tmp/portage/net-nntp/slrn-0.9.9/work/slrn-0.9.9/src/x86objs/chkslang slrn 20000 slrnpull created in /usr/src/tmp/portage/net-nntp/slrn-0.9.9/work/slrn-0.9.9/src/x86objs ../autoconf/mkinsdir.sh /usr/src/tmp/portage/net-nntp/slrn-0.9.9/image//usr/bin /usr/bin/install -c -m 755 -s /usr/src/tmp/portage/net-nntp/slrn-0.9.9/work/slrn-0.9.9/src/x86objs/slrn /usr/src/tmp/portage/net-nntp/slrn-0.9.9/image//usr/bin /usr/bin/install: cannot create regular file `/usr/src/tmp/portage/net-nntp/slrn-0.9.9/image//usr/bin': No such file or directory make[1]: *** [installbin] Error 1 This way, enjoy the new release!
Created attachment 163799 [details] slrn-0.9.9 ebuild
(In reply to comment #1) > Created an attachment (id=163799) [edit] > slrn-0.9.9 ebuild > That is incorrect. You would want to do something like: emake -j1 in src_compile() to force a non-parallel build.
I must admit that I agree, my MAKEOPTS line does only append -j1 to -j3, right? Actually I see this watching emerge with ps: "make -j3 -j1" is running. The funny thing is, this works. What also works without this line is MAKEOPTS="-j1" emerge slrn but not "emake -j1 || ..." with my MAKEOPTS omitted. The funny thing is, even then I see "make -j3 -j1" running while watching my processes with ps. But the same die message occurs. So for now I don't know how to cope with this otherwise. The die message "`/usr/src/tmp/portage/net-nntp/slrn-0.9.9/image//usr/bin': No such file or directory" complains about the directory missing but after emerge died an ls on this directory is succesful, so I suspected a parallel make race condition. MAKEOPTS=-j3 is what I ahve in my /etc/make.conf.
Created attachment 166550 [details] A working net-nntp/slrn-0.9.9.ebuild The problem was that the installation procedure in the Makefile has been split into several targets such as installdirs, installbins etc. - with file-installing targets not depending on the directory-creating one. The proper solution to the problem would be to create such dependencies - but that I believe should preferably be handled by upstream. As far as ebuilds are concerned, the most simple solution to the problem is IMHO to call "make installdirs" explicitly before "make install" - that way no patches have to be applied to the sources. Attached you will find my version of the ebuild, which in addition to introducing the aforementioned workaround cleans up some leftovers from previous versions not necessary with 0.9.9. It has been tested on amd64 and x86, as reflected by the content of KEYWORDS. Hopefully everything will be okay this time and 0.9.9 will make its way into Portage soon, we had to wait long enough for a new version of slrn as it was :-)
I've commited 0.9.9_p1 to the tree.
I installed it and it works fine :-)
Created attachment 201392 [details, diff] patch to enable cancel-locks and correcting uudeview configuration diff against the actual slrn-0.9.9_p1.ebuild Enables cancel-lock headers and correcting --with-uudeview to --with-uu. Sebastian
