[gentoo-dev] Re: RFC: new global USE flag srcdist
On Fri, 3 Jan 2014 00:53:17 +0100 Ulrich Mueller u...@gentoo.org wrote: On Thu, 2 Jan 2014, Ryan Hill wrote: In case it's helpful here's what FOSSology[1] has to say about some common packages that people have uploaded to their demo server. I don't get your point here. The licenses of a package have to be checked in any case. Why would it be more complicated to check the full set of files in the tarball, instead of the subset of files that the package will actually install? I was trying to see how many packages contain licenses that aren't already in LICENSES, assuming these would be ones that we would have to have a srcdist USE flag for. Rich said that is was rare. I'm finding every package I've checked so far would need one. Either way I don't care what you do. -- Ryan Hillpsn: dirtyepic_sk gcc-porting/toolchain/wxwidgets @ gentoo.org 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 signature.asc Description: PGP signature
[gentoo-dev] libtool lt_dlopenext vs. gen_ld_script: breakages at runtime
Summary: gen_ld_script is removing a vital unversioned symlink from some packages, and this breaks libtool lt_dlopenext consumers at runtime. Details: While examining bug #486640, I discovered a concerning interaction [1] between libtool's lt_dlopenext and gen_ld_script. I don't have a good handle on how many packages are affected, but it would be an code that uses lt_dlopenext to try and find a library. For our example, we're using the fact that sys-power/nut wants to use libusb from dev-libs/libusb-compat. dev-libs/libusb-compat has these files: /usr/lib64/libusb.so (from gen_ld_script) /lib64/libusb-0.1.so.4.4.4 /lib64/libusb-0.1.so.4 (symlink to 4.4.4) lt_dlopenext is given the basename of a library to find. In this case, the (modified) code tries both libusb and libusb-0.1, with slightly different failures: 1. lt_dlopenext cannot parse linker scripts at all, so the libusb.so from gen_ld_script cannot be opened. 2. lt_dlopenext only tries to append .so, it doesn't add version specifiers. If I manually add a symlink: /lib64/libusb-0.1.so - /lib64/libusb-0.1.so.4 then lt_dlopenext succeeds. This led me to looking at the libusb-compat in more detail. Before gen_ld_script runs, it has the library and two symlinks in /usr/lib64: /usr/lib64/libusb-0.1.so.4.4.4 /usr/lib64/libusb-0.1.so.4 (symlink) /usr/lib64/libusb.so (symlink) At this stage, lt_dlopenext works still. Now after gen_ld_script, the unversioned symlink is replaced by a linker script. The versioned symlink and base file have moved to /lib64. Since lt_dlopenext cannot handle the linker script, and the unversioned symlink is gone, we now get a failure. Proposed Fix: - I would like to propose that gen_ld_script does NOT remove the unversioned symlinks, but instead moves them along with the versioned symlinks. Questions: -- How can we sanely get all user systems updated for this subtle bug? Comments: - In bug #4411, comment 43, vapier noted: any package that does dlopen(libfoo.so) without the version info like .so.X is broken. In this case, the lt_dlopenext consumer is explicitly testing multiple versions of libusb at runtime, and picking the correct interface: it doesn't need to depend on a specific version. This is also because the lt_dlopenext interface does NOT accepted files versioned after the .so: it needs the filename with no extensions. [1] I do half-expect vapier, flameeyes or patrick to shoot me down, and tell me the package is doing something wrong, but I've also got a chance of this actually being a system breakage. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-portage-dev] New portage version with latest fixes in git is needed
On Sat, 2014-01-04 at 15:28 +0100, Pacho Ramos wrote: Hello I think this was pointed some days ago, but would be nice (and needed) to get a newer portage version including fixes from git, some of them important like: https://bugs.gentoo.org/show_bug.cgi?id=490362 Not sure if I can contribute with something on this, but if you thing so, please let me know Thanks! Yes, I planned to get it out this weekend, if all goes well. There are one or two more patches to apply. Then I'll start packaging it. Is everyone else in agreement? signature.asc Description: This is a digitally signed message part
Re: [gentoo-portage-dev] New portage version with latest fixes in git is needed
Am 04.01.2014 16:03, schrieb Mike Frysinger: On Saturday 04 January 2014 09:56:28 Brian Dolbec wrote: On Sat, 2014-01-04 at 15:28 +0100, Pacho Ramos wrote: I think this was pointed some days ago, but would be nice (and needed) to get a newer portage version including fixes from git, some of them important like: https://bugs.gentoo.org/show_bug.cgi?id=490362 Not sure if I can contribute with something on this, but if you thing so, please let me know Yes, I planned to get it out this weekend, if all goes well. There are one or two more patches to apply. Then I'll start packaging it. Is everyone else in agreement? we should document the release process. ideally, it should be as simple as: make dist PV=2.1.8 and even: make distcheck PV=2.1.8 -mike There is mkrelease.sh in the portage repo. The following commands creates a portage-2.2.7.tar.bz2 that's almost identical to the one released by Zac (Changelog differs): $ ./mkrelease.sh --changelog-rev v2.2.6 -t 2.2.7 2.2.7 The first argument states where the Changelog entries should begin (tag v2.2.6 in this case). The second argument is the tag to create the tarball from. The third argument is the new version. I don't know how Zac choose the --changelog-rev parameter. That's why the Changelog is different. For 2.2.8 the process should look like: * Create a tag named v2.2.8. * ./mkrelease.sh --changelog-rev -t 2.2.8 2.2.8 * Upload the tarball somewhere * Copy the ebuild (adjust SRC_URI) Sebastian
Re: [gentoo-portage-dev] New portage version with latest fixes in git is needed
Am 04.01.2014 15:56, schrieb Brian Dolbec: On Sat, 2014-01-04 at 15:28 +0100, Pacho Ramos wrote: Hello I think this was pointed some days ago, but would be nice (and needed) to get a newer portage version including fixes from git, some of them important like: https://bugs.gentoo.org/show_bug.cgi?id=490362 Not sure if I can contribute with something on this, but if you thing so, please let me know Thanks! Yes, I planned to get it out this weekend, if all goes well. There are one or two more patches to apply. Then I'll start packaging it. I'd say, apply only the really necessary patches (i.e. the python-2.6 compat patch) and commit the remaining patches after the release. Is everyone else in agreement? Go for it. Sebastian
