Re: [gentoo-dev] Non-free software in Gentoo
Le 28/12/2009 06:36, Vincent Launchbury a écrit : Hi, I recently emailed the Gentoo PR team, voicing my concerns about the amount of non-free software within Gentoo. I got an interesting response from Sebastian Pipping, who said that while Gentoo is all about choice, including the choice to install non-free software, the project is interested in making it easy for people to run a 100% free system, should they choose that path. Gentoo - like the rest of Free and Open Source Software - isn't about choice, it's about empowering users. Gentoo gives you tools and documentation to do whatever you wish. It doesn't mean that we (Gentoo) _have_ to support it. With that out of the way, moving on to the rest of the mail. 1) Not all of the licenses are completely accurate. For example, the Linux kernels are listed as soley GPL-2, yet they contain blobs of non-free firmware. Indeed, that's a very good point. And that's precisely why I was against ACCEPT_LICENSE to begin with. It's a good idea on paper, but it's just not feasible at a large scale (like portage) without a proper _team_ of devoted people sifting through code and license blobs to make it useful. I'm also pretty sure a couple lawyers would be needed as well. Unless people dedicate time and effort, ACCEPT_LICENSE is useless. [snip] The rest of your points are indeed all valid as well. I can only encourage you to either work with individual developers to get ebuilds fixed (USE=bindist or whatever) or join our ranks to fix this yourself if you really want a pure Free Gentoo. This is my first post here, so I apologize if it's misdirected. I'm not sure if I'd really be able to help much on the technical side, but if this garners any cooperation, I'll gladly help out with anything I can. If someone could point me in the right direction, I'd be very grateful. I'd say this is probably better suited for gentoo-project, but it's probably ok to start here, to gauge interest :) Best of luck Rémi
[gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
In the aim of improving binpkgs status, I filed a bunch of bugs against all the libX* available in tree that contain wrong RDEPEND bits pointing to x11-proto/* stuff. To x11, just don't get angry (eheh), let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). List of Gentoo bugs: 298616 298618 298620 298621 298623 298624 298626 298627 298629 298631 298633 298634 298636 298638 298640 298642 298644 298645 298646 298648 298649 298653 298654 298656 298657 298658 298659 -- Fabio Erculiani http://www.gentoo.org http://www.sabayon.org signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-dev-announce] Lastrite: k3guitune, akode
Samuli Suominen demis ki:: # Samuli Suominen ssuomi...@gentoo.org (27 Dec 2009) # KDE3-only, no porting being done for KDE4. # Replaced by e.g. gtkguitune, gtick, kmetronome # Masked for removal media-sound/k3guitune The message can be a little more helpful to users. qpitch is a Qt4 tuning application which is directly based on k3guitune. gtick and kmetronome are not tuning applications, so they do not replace k3guitune. -- Gokdeniz Karadag
Re: [gentoo-dev] Re: [gentoo-dev-announce] Lastrite: k3guitune, akode
On 12/28/2009 11:46 AM, Gokdeniz Karadag wrote: Samuli Suominen demis ki:: # Samuli Suominen ssuomi...@gentoo.org (27 Dec 2009) # KDE3-only, no porting being done for KDE4. # Replaced by e.g. gtkguitune, gtick, kmetronome # Masked for removal media-sound/k3guitune The message can be a little more helpful to users. qpitch is a Qt4 tuning application which is directly based on k3guitune. gtick and kmetronome are not tuning applications, so they do not replace k3guitune. I've fixed the message few mins after posting here, with a new commit, media-sound/k4guitune. Sync away :)
Re: [gentoo-dev] Gentoo Prefix Lite Quiz
On Friday 18 December 2009 14:00:06 Fabian Groffen wrote: As promised, here is the slimmed down version of the Prefix quiz. As requested, I'll post the answers on -core. Prefix development quiz (Zero taste) ** when porting ebuilds for Gentoo Prefix, one will get confronted with certain problems, these two questions hint at such problems ** 4. Package Y has a configure script that's just being run by econf. You just added Y and now try to install it. What do you watch for? Maybe better: 4. Package Y's configure script has just been run. What potential problems do you especially need to be on the lookout for in the output of ./configure? Marijn
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, 28 Dec 2009 00:36:34 -0500 Vincent Launchbury vinc...@doublecreations.com wrote: Also relating to this, what is freedist? The package app-text/dos2unix lists 'freedist' as its license, and /usr/portage/licenses/freedist says only Freely Distributable. Several other packages do this, and I'm sure it's not correct. I'm not entirely sure, but I think the dos2unix package is from http://www.thefreecountry.com/tofrodos/, which clearly says its GPLv2. Packages like this could be looked into and fixed. No, that would be app-text/tofrodos (see bug #225903 [1] for details - some of the confusion over where the app-text/dos2unix sources originated was discussed there). Regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=225903
Re: [gentoo-dev] QA Documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 28.12.2009 03:43, Richard Freeman napsal(a): Could this include documenting QA policies a bit better? Some are documented in scattered docs, some are in the ebuild quiz answers (which of course no two developers have the exact same answers to, and they aren't anywhere you can point to for reference), and many are learned when QA files a bug on a package one maintains. It would be really nice to just have a list somewhere that we could periodically look at and refresh our memories against. Plus, some policies aren't always obvious or can be misinterpreted. Don't get me wrong - the QA team is doing a great job and I love Diego's work on the tinderbox. I've had a bug or two filed by them, and I've found that they've only been helpful when somebody actually bothers to try to resolve them. Yeah that is the weak point. We need to write for each policy what it does and why we enforce it (probably also common approach to fix). And we should ENFORCE it, not just fill bugs about it, because mostly people tend to ignore that things. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAks4lT4ACgkQHB6c3gNBRYfS+QCfdw7ler6i8xGPufZnNsQjNV9m bBYAoKLKekHRe6SShSNcU7jHIEZiYrCw =9y3A -END PGP SIGNATURE-
Re: [gentoo-dev] QA Documentation
On Mon, Dec 28, 2009 at 3:43 AM, Richard Freeman ri...@gentoo.org wrote: [..] Don't get me wrong - the QA team is doing a great job and I love Diego's work on the tinderbox. I've had a bug or two filed by them, and I've found that they've only been helpful when somebody actually bothers to try to resolve them. Just to let you all know, we have two build servers since 2007 in where we compile Portage ~arch (x86, amd64) and produce binary packages through Entropy for Sabayon (http://sabayon.org/packages). In 2010 we plan, with some students from the University of Milano-Bicocca to add some static analysis bits into the workflow. Maybe, there are some commonalities between the two ideas (tinderbox vs what Sabayon is doing already). -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, Dec 28, 2009 at 1:40 PM, Rémi Cardona r...@gentoo.org wrote: Le 28/12/2009 06:36, Vincent Launchbury a écrit : 1) Not all of the licenses are completely accurate. For example, the Linux kernels are listed as soley GPL-2, yet they contain blobs of non-free firmware. Indeed, that's a very good point. And that's precisely why I was against ACCEPT_LICENSE to begin with. It's a good idea on paper, but it's just not feasible at a large scale (like portage) without a proper _team_ of devoted people sifting through code and license blobs to make it useful. I'm also pretty sure a couple lawyers would be needed as well. I think we can simply follow debian and fedora's lead on this. They have the lawyers, and being in the same bowl as them would be a good idea if any problems ever crop up. One area where we're in a fishy situation (distinct from debian/fedora) is our distribution of isos and stages without the adjoining sources[1]. This situation always makes me queasy. But I'm digressing here... Unless people dedicate time and effort, ACCEPT_LICENSE is useless. Not entirely useless, and maintainers can, and should, spend time making sure ACCEPT_LICENSE is complete and accurate. [snip] The rest of your points are indeed all valid as well. I can only encourage you to either work with individual developers to get ebuilds fixed (USE=bindist or whatever) or join our ranks to fix this yourself if you really want a pure Free Gentoo. ++ on this. We're a direct-to-users distro; we empower you and give you the means to empower yourself. We probably have the easiest and most direct way to get recruited (although it's strenous on the recruiters side ;). 1. Actually, I was thinking we could take the result at the end of src_prepare, tarball it up, do it for all the packages we have in the iso, tar up all *those* and serve the end result up too. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Non-free software in Gentoo
Vincent Launchbury wrote: Hi, I recently emailed the Gentoo PR team, voicing my concerns about the amount of non-free software within Gentoo. I got an interesting response from Sebastian Pipping, who said that while Gentoo is all about choice, including the choice to install non-free software, the project is interested in making it easy for people to run a 100% free system, should they choose that path. I found out about the license filtering feature in the dev version of portage, and used it to remove all the non-free software from my system. However, it wasn't a perfect experience. Based on what Sebastian had to say, and my own experience using it, I have a few suggestions. 1) Not all of the licenses are completely accurate. For example, the Linux kernels are listed as soley GPL-2, yet they contain blobs of non-free firmware. Perhaps a general-purpose not-free license could be appended to such packages. This would only affect people who choose to use the feature. It could be minused from the FSF-APPROVED group for example. Also relating to this, what is freedist? The package app-text/dos2unix lists 'freedist' as its license, and /usr/portage/licenses/freedist says only Freely Distributable. Several other packages do this, and I'm sure it's not correct. I'm not entirely sure, but I think the dos2unix package is from http://www.thefreecountry.com/tofrodos/, which clearly says its GPLv2. Packages like this could be looked into and fixed. File bugs mate. Licensing is not exactly clear to all users or devs. As can be seen here[1] for dos2unix. It sounds like you care in this area, so get involved. [1]: https://bugs.gentoo.org/show_bug.cgi?id=177822 -Jeremy 2) There are no free versions of the kernel in the main tree. The Latin American FSF maintains blob-free kernels at http://www.linux-libre.fsfla.org/pub/linux-libre/releases/. They could be added alongside the official vanilla ebuilds. 3) Some free software packages bring in non-free optional dependencies by default. For example, media-gfx/imagemagick brings in media-fonts/corefonts. As suggested by Sebastian, a free profile could be created, that changes these defaults, to reduce the hassle of maintaining a free system. Again, this would only affect users who choose to use that profile. 4) Using something like ACCEPT_LICENSES=-* @FSF-APPROVED is a good start, but its quite a hassle to keep checking all the licenses. One annoyance is packages like sys-devel/gcc. gcc has the libgcc license, which is just GPLv2+, with some extra permissions granted. Although it's important to make such a distinction, these extra freedoms are irrelevant to license filtering. I suppose the only feasible way to fix this would be to expand the license groups in /usr/portage/profiles/license_groups. Would it cause any problems if they were quite large? Another option might be to introduce an optional IS_FREE=yes/no option to the ebuild files, which could override the other license settings. 5) Documentation on how to set up and maintain a fully free system could be added. To summarize, my general idea is to fix some licensing issues, introduce the libre kernels and have a 100% free profile that would create the least possible amount of hassle for anyone using it. This in turn would make Gentoo more accessible to the free software community, without affecting people that don't use the profile. This is my first post here, so I apologize if it's misdirected. I'm not sure if I'd really be able to help much on the technical side, but if this garners any cooperation, I'll gladly help out with anything I can. If someone could point me in the right direction, I'd be very grateful. Kind Regards, Vincent Launchbury.
Re: [gentoo-dev] QA Documentation
On 12/28/2009 06:23 AM, Tomáš Chvátal wrote: we should ENFORCE it, not just fill bugs about it, because mostly people tend to ignore that things. Agreed, although some presumption of innocence should be assumed. If a dev is ignoring repoman output that is a fairly big violation, but if a dev missed that compiling under some strange set of circumstances or combination of use flags causes a problem, well, that's a bug that needs to be fixed. There were some --as-needed issues detected by the tinderbox that only show up when you use a modified gcc profile, for example. That doesn't mean they're not worth fixing, but we shouldn't punish people for that stuff. I don't think the QA team has an issue with mistakes (not that I can really speak for them) - their main frustration is probably when bugs get filed and then get ignored. Expecting people to resolve bugs in a week for minor issues is probably asking a bit much, but if a dev has 14 packages with 25 open bugs each that are six months old that is probably a cause for concern that should be escalated to devrel. On the other hand, some allowance for brain-dead upstream tactics should be made. I'd consider embedded libraries a QA issue, but if we made that a stern policy we'd never see chromium in the tree for quite a long time. I'm sure the guys maintaining that would love to try to patch out as much of the embedded stuff as they can, but they've got a LOT of work to do due to the way it was written. I'm not sure that simply banning chromium from the tree is the right approach either as long as upstream deals with the inevitable security issues when they come up.
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 3:10 AM, lx...@gentoo.org wrote: In the aim of improving binpkgs status, I filed a bunch of bugs against all the libX* available in tree that contain wrong RDEPEND bits pointing to x11-proto/* stuff. To x11, just don't get angry (eheh), let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). Why not provide some actual meat and potatoes here instead of a useless e-mail with bug numbers and some stupid attempt at humor at the expense of the x11 herd?
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 8:24 PM, Samuli Suominen ssuomi...@gentoo.org wrote: [...snip...] Samuli I know, but actually Zac told me that as of now RDEPENDs are not considered that way. I knew that you were going to comment here (hence why I posted), maybe it's a good time to clear out our mind and eventually decide how to deal with those. Because most of the ebuilds don't seem to follow your logic. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
I discussed this a few weeks ago with some devs on IRC and the general answer was, file bugs. I filed bugs. About the rest, I decline any comment. Have fun. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, 28 Dec 2009 10:10:48 +0100 (CET) lx...@gentoo.org wrote: let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). If they are genuine bugs, then there isn't anything to discuss. List of Gentoo bugs: Tracker bug is #298759[1] Regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=298759
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 8:15 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 28 Dec 2009 10:10:48 +0100 (CET) lx...@gentoo.org wrote: let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). If they are genuine bugs, then there isn't anything to discuss. Thanks, I will also create a tracker bug next time. List of Gentoo bugs: Tracker bug is #298759[1] Regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=298759 -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On 12/28/2009 11:10 AM, lx...@gentoo.org wrote: In the aim of improving binpkgs status, I filed a bunch of bugs against all the libX* available in tree that contain wrong RDEPEND bits pointing to x11-proto/* stuff. To x11, just don't get angry (eheh), let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). Xdbe.h is part of libXext: Xdbe.h:#include X11/extensions/dbe.h x11-libs/libXext (/usr/include/X11/extensions/Xdbe.h) Where dbe.h is coming from xextproto: x11-proto/xextproto (/usr/include/X11/extensions/dbe.h) As such, xextproto should be a RDEPEND of libXext or otherwise you'd be breaking everything that's using libXext's Xdbe.h as a build depend because having xextproto only in DEPEND would allow --depclean to remove the required header from system my 1 or 2 cents
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Tue, Dec 29, 2009 at 12:54 AM, Samuli Suominen ssuomi...@gentoo.org wrote: Xdbe.h is part of libXext: Xdbe.h:#include X11/extensions/dbe.h x11-libs/libXext (/usr/include/X11/extensions/Xdbe.h) Where dbe.h is coming from xextproto: x11-proto/xextproto (/usr/include/X11/extensions/dbe.h) As such, xextproto should be a RDEPEND of libXext or otherwise you'd be breaking everything that's using libXext's Xdbe.h as a build depend because having xextproto only in DEPEND would allow --depclean to remove the required header from system It won't do that unless you do --with-bdeps=y ; plus removing headers from the system won't cause the packages to stop working, and if someone removes the headers, they'll be pulled back on upgrade. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On 12/28/2009 11:10 AM, lx...@gentoo.org wrote: To x11, just don't get angry (eheh), let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). Filing bugs first and then opening discussion here doesn't make sense. It should be the other way around. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, Dec 28, 2009 at 12:36:34AM -0500, Vincent Launchbury wrote: 1) Not all of the licenses are completely accurate. For example, the Linux kernels are listed as soley GPL-2, yet they contain blobs of non-free firmware. Perhaps a general-purpose not-free license could be appended to such packages. This would only affect people who choose to use the feature. It could be minused from the FSF-APPROVED group for example. Actually, this is a case where the license on the ebuild is wrong, not the license group. The kernel ebuilds should have GPL-2 and something else, and by definition should not pass @FSF-APPROVED alone. Also relating to this, what is freedist? The package app-text/dos2unix lists 'freedist' as its license, and /usr/portage/licenses/freedist says only Freely Distributable. Several other packages do this, and I'm sure it's not correct. I'm not entirely sure, but I think the dos2unix package is from http://www.thefreecountry.com/tofrodos/, which clearly says its GPLv2. Packages like this could be looked into and fixed. tofrodos is NOT dos2unix. If you compare the sources you'll see they are radically different. The COPYRIGHT file in dos2unix is actually a 2-clause BSD license. I've updated the ebuild suitably. Yes, we do definitely need to review licenses on packages where they aren't clear, correct any mistakes. 2) There are no free versions of the kernel in the main tree. The Latin American FSF maintains blob-free kernels at http://www.linux-libre.fsfla.org/pub/linux-libre/releases/. They could be added alongside the official vanilla ebuilds. File a bug with some ebuilds. 3) Some free software packages bring in non-free optional dependencies by default. For example, media-gfx/imagemagick brings in media-fonts/corefonts. As suggested by Sebastian, a free profile could be created, that changes these defaults, to reduce the hassle of maintaining a free system. Again, this would only affect users who choose to use that profile. A profile is not the answer here. An optional DEP block || ( media-fonts/corefonts ... ) where the other item does resolve using ACCEPT_LICENSES is what should be used. In this line of work, we would greatly appreciate bugs being filed for all cases where dependencies are not resolvable with your reasonable ACCEPT_LICENSES setting. 4) Using something like ACCEPT_LICENSES=-* @FSF-APPROVED is a good start, but its quite a hassle to keep checking all the licenses. One annoyance is packages like sys-devel/gcc. gcc has the libgcc license, which is just GPLv2+, with some extra permissions granted. Although it's important to make such a distinction, these extra freedoms are irrelevant to license filtering. I suppose the only feasible way to fix this would be to expand the license groups in /usr/portage/profiles/license_groups. Would it cause any problems if they were quite large? No, the file can become a lot larger before any problems come up. I deliberately introduced @BINARY-REDISTRIBUTABLE to help packaging of the 10.x release. They simply set that into their ACCEPT_LICENSES and then we're reasonable set. In your case, I propose that we add one or more stacked groups, with an initial content as such: License group name: LIBRE-FREE Purpose: easily selectable license group for libre-free systems. Initial license group contents: @FSF-APPROVED @GPL-COMPATIBLE @OSI-APPROVED @LIBRE-FREE-1 License group name: LIBRE-FREE-1 Purpose: license group to put additional special-case libre-free licenses in. Initial license group contents: libgcc libstdc++ gcc-runtime-library-exception-3.1 We might be able to merge LIBRE-FREE-1 directly into the LIBRE-FREE entry, the portage folk would be able to answer if there would be a performance benefit to having it split or not. Another option might be to introduce an optional IS_FREE=yes/no option to the ebuild files, which could override the other license settings. No. 5) Documentation on how to set up and maintain a fully free system could be added. Under my license_group proposal: # echo 'ACCEPT_LICENSES=-* @LIBRE-FREE' /etc/make.conf done. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgppJJZ2R6qZ2.pgp Description: PGP signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 10:10, lx...@gentoo.org a écrit : List of Gentoo bugs: 298616 298618 298620 298621 298623 298624 298626 298627 298629 298631 298633 298634 298636 298638 298640 298642 298644 298645 298646 298648 298649 298653 298654 298656 298657 298658 298659 RESOLVED - WONTFIX Others and myself have spent considerable time making those deps the way they are because : 1) upstream packaging is a bit uncommon 2) ebuild deps don't fit with upstream deps 3) a few embedded devs told me they wiped /usr/include when making images So if you want to fix this properly, a new DEP variable needs to be cooked up : add the following deps to ebuilds' DEPEND when those ebuids DEPEND on this ebuild. Until such a variable exist, having the protos in both DEPEND and RDEPEND is the only _valid_ solution. Thanks Rémi
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 9:06 PM, Rémi Cardona r...@gentoo.org wrote: RESOLVED - WONTFIX Others and myself have spent considerable time making those deps the way they are because : 1) upstream packaging is a bit uncommon 2) ebuild deps don't fit with upstream deps 3) a few embedded devs told me they wiped /usr/include when making images What all this has to do with the fact that they are just build dependencies? Just wondering. So if you want to fix this properly, a new DEP variable needs to be cooked up : add the following deps to ebuilds' DEPEND when those ebuids DEPEND on this ebuild. Other package managers out there have explicit build dependency lists, so, if DEPEND is not really a list of build dependencies, yeah, I agree, we need a list describing strict build dependencies. Until such a variable exist, having the protos in both DEPEND and RDEPEND is the only _valid_ solution. Thanks Others here gave opposite opinion by the way. Rémi -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself).
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 9:51 PM, David Leverton levert...@googlemail.com wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). To me you are saying that DEPEND would work just fine. No? -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Sorry, some more bits here: AFAIK, Portage considers DEPEND when used as source-based package manager (and emerge --depclean stuff) while it ignores them when binpkgs come into play. So, (I ask Zac to correct me), putting x11-protos to DEPEND doesn't really change much for 99% of Portage users (those who are using it to *compile* pkgs). While it changes a lot for binary package managers, which hopefully don't consider DEPEND at all (at least this was the initial idea). The fact is, since Portage binary package management is really and unfortunately a joke as of today, the amount of people using it versus the amount of people not using it is really big (that's why I wrote a separate app). Thus, many ebuilds have broken RDEPEND/DEPEND and as you (all) have proven, there is not even a real container of build dependencies nor a clear idea among developers (my initial email wanted to bring devs to this exact point, it seems I did it). Moreover, the amount of legacy, undocumented, perhaps *workaroundish* solutions inside Portage codebase are not really helping in fixing this situation. I say, unfortunately, not to blame anybody. A lot of work is being done lately to try to improve it. -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On 12/28/2009 10:51 PM, David Leverton wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). That's what I've been trying to say (also with my example). That is, they are more than DEPENDs. Thanks, Samuli
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 10:32 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 12/28/2009 10:51 PM, David Leverton wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). That's what I've been trying to say (also with my example). That is, they are more than DEPENDs. How comes, this is the list of files owned by xproto: /usr/include/X11/extensions/dmxext.h /usr/include/X11/extensions/dmxproto.h /usr/share/doc/dmxproto-2.2.2/ChangeLog.bz2 /usr/lib64/pkgconfig/dmxproto.pc /usr/include/X11/DECkeysym.h /usr/include/X11/Xos.h /usr/include/X11/HPkeysym.h /usr/include/X11/Xosdefs.h /usr/include/X11/Xwinsock.h /usr/include/X11/Xos_r.h /usr/include/X11/Xalloca.h /usr/include/X11/Xatom.h /usr/include/X11/Xfuncproto.h /usr/include/X11/Sunkeysym.h /usr/include/X11/Xdefs.h /usr/include/X11/ap_keysym.h /usr/include/X11/Xarch.h /usr/include/X11/keysymdef.h /usr/include/X11/Xw32defs.h /usr/include/X11/Xprotostr.h /usr/include/X11/keysym.h /usr/include/X11/X.h /usr/include/X11/Xwindows.h /usr/include/X11/Xproto.h /usr/include/X11/XWDFile.h /usr/include/X11/Xthreads.h /usr/include/X11/Xpoll.h /usr/include/X11/Xmd.h /usr/include/X11/Xfuncs.h /usr/include/X11/XF86keysym.h /usr/share/doc/xproto-7.0.16/ChangeLog.bz2 /usr/lib64/pkgconfig/xproto.pc How can a bunch of .h and pkgconfig files *do* all that magic you are talking about? Thanks, You are more than welcome, Samuli -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
In any case, I think that this situation should be addressed, and perhaps a comment from PMS might help. Regards, -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Fabio Erculiani demis ki:: How comes, this is the list of files owned by xproto: /usr/include/X11/extensions/dmxext.h /usr/include/X11/extensions/dmxproto.h /usr/share/doc/dmxproto-2.2.2/ChangeLog.bz2 /usr/lib64/pkgconfig/dmxproto.pc /usr/include/X11/DECkeysym.h . How can a bunch of .h and pkgconfig files *do* all that magic you are talking about? X preprocesses some files at each startup(using the C preprocessor(cpp) via xrdb configuration tool) Strange but true. Macros defined by these .h files might be used during this configuration. -- Gokdeniz Karadag
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, 28 Dec 2009 22:54:42 +0100 (CET) Fabio Erculiani lx...@gentoo.org wrote: In any case, I think that this situation should be addressed, and perhaps a comment from PMS might help. The PMS side is that we know that the current three DEPEND variables are nowhere near enough, and there are proposals for fixing it properly, but they're not things that are easy to implement in Portage, so there's no timescale. In the mean time, RDEPEND is the closest we have to a dependency saying if I'm used to satisfy a build dependency, then this must also be installed. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On 12/28/2009 11:47 PM, Fabio Erculiani wrote: On Mon, Dec 28, 2009 at 10:32 PM, Samuli Suominen ssuomi...@gentoo.org wrote: On 12/28/2009 10:51 PM, David Leverton wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). That's what I've been trying to say (also with my example). That is, they are more than DEPENDs. How comes, this is the list of files owned by xproto: ... How can a bunch of .h and pkgconfig files *do* all that magic you are talking about? There's no magic involved. In order to _use_ libXext, which in this case is building something against libXext, also xextproto must be around, because libXext's includes are including xextproto's includes. As in, libXext must have xextproto around to be a complete package.
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 10:48 PM, Gokdeniz Karadag gokden...@gmail.com wrote: X preprocesses some files at each startup(using the C preprocessor(cpp) via xrdb configuration tool) Strange but true. Macros defined by these .h files might be used during this configuration. That's the missing bit! Thanks for the answer. -- Gokdeniz Karadag -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] Non-free software in Gentoo
On 12/28/2009 01:56 PM, Robin H. Johnson wrote: Actually, this is a case where the license on the ebuild is wrong, not the license group. The kernel ebuilds should have GPL-2 and something else, and by definition should not pass @FSF-APPROVED alone. Is this appropriate? The kernel sources indicate that they are licensed under GPLv2, and they make no mention of other licenses for any component of the sources. Perhaps Linus/etc are wrong about this - but shouldn't that be something that people take up with them, unless Gentoo gets a letter from some lawyers claiming that we're infringing? For that matter, for all we know kdelibs contains 10 lines of code from Jack Smith, who didn't agree to the LGPL and those 10 lines are under the Jack Smith Distribution License. However, it would be best if Jack Smith were to take this up with the KDE team and not with every distro that uses KDE. If Gentoo starts second-guessing the licenses on packages, do we then become liable if we fail to do this for a package?
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 22:04, Fabio Erculiani a écrit : On Mon, Dec 28, 2009 at 9:51 PM, David Leverton levert...@googlemail.com wrote: On Monday 28 December 2009 20:50:17 Fabio Erculiani wrote: What all this has to do with the fact that they are just build dependencies? Just wondering. They're not just build dependencies. They're required to use the library in a certain way, namely to compile other programs against it. As long as we don't have compile-against dependencies, the only correct way to express that is RDEPEND (and also DEPEND because they're /also/ needed to build the library itself). To me you are saying that DEPEND would work just fine. No? No, but I understand why you're insisting. It took us a few weeks to wrap our heads around this to understand it. Let's take an example (bug #228211 but there are dozens more). In this example, libfakekey does : #include XTest.h and its configure.ac checks for xtst.pc. Both files are provided by x11-libs/libXtst so this dep is added to DEPEND and RDEPEND. The problem comes from libXtst's XTest.h which #includes XInput.h which was provided by x11-proto/inputproto [1]. inputproto is/was a build-time dep of libXtst. - libXtst _directly_ requires inputproto at build-time only - libXtst _directly_ requires libXi at build-time and run-time However : - requiring libXtst at build-time _also_ requires inputproto. For most users out there, this would never be a problem since most Gentoo users always keep build-time deps on their systems. The problem arises for people who only keep run-time deps, usually for binary packages. inputproto being a DEPEND-only dep of libXtst, binary users will never get inputproto when they build libfakekey. So there were 3 solutions : 1) add explicit deps in _all_ packages that DEPEND on libXtst to _also_ depend on inputproto even if they don't use it at all (most don't, they just use XTest functions). 2) add inputproto to libXtst's DEPEND and RDEPEND 3) modify EAPI to add a new *DEPEND variable to cater X's very special needs. Solution #1 is error prone. If we fix ebuilds now, new ebuilds might pop up later with broken dependencies. No go. Solution #3 really isn't for me. I tried getting near PMS and I got bit. If anyone wants to do this, I'll help, but I won't do this on my own. So we went with solution #2. Yes, it does add nasty little headers on a binary distribution, but that was a far better compromise than any of the other 2 solutions. Really, the correct solution (please _listen_ and _trust_ me on this) is to add a new dependency variable to EAPI to correctly describe how X headers and libs really work. That's solution #3. I agree with you, pulling protos in both DEPEND and RDEPEND is a hack, but it's *much* better than the other alternatives. Rémi [1] This file is now part of libXi, but the problem has now shifted to XI.h, so it's still going to be the exact same problem today, but for the sake of simplicity, I'll keep it short.
[gentoo-dev] Re: [gentoo-dev-announce] Packages up for grab (some might die)
2009/12/28 Diego E. 'Flameeyes' flamee...@gentoo.org: Since I've stopped using some of them, I've decided to leave up for grabs some packages: app-forensics/zzuf * app-text/convertlit * app-text/ssddiff * app-text/libxmlpatch * gnome-extra/gnome-color-chooser ♥ x11-themes/gtk-engines-nimbus I'll take app-text/convertlit. -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Interesting, eventually somebody gave me a detailed and technical explanation without [bla bla snip]. Thanks Rémi. Yes, I agree with you that the best (and the one I would go for, too) solution is adding support to a new *DEPEND, perhaps one that could host build-deps only. It looks weird that other PMs out there do that since 1994 (replace 1994 with older value). Perhaps adding a big fat # XXX somewhere in ebuilds would have helped us all in saving some time today. So, at least for now, I suspect I have to give up and close my shiny 27 bugs. Right? -- Fabio Erculiani http://www.sabayon.org http://www.gentoo.org
Re: [gentoo-dev] Non-free software in Gentoo
On Mon, Dec 28, 2009 at 05:15:06PM -0500, Richard Freeman wrote: On 12/28/2009 01:56 PM, Robin H. Johnson wrote: Actually, this is a case where the license on the ebuild is wrong, not the license group. The kernel ebuilds should have GPL-2 and something else, and by definition should not pass @FSF-APPROVED alone. Is this appropriate? The kernel sources indicate that they are licensed under GPLv2, and they make no mention of other licenses for any component of the sources. You're wrong there. The kernel does contain additional licenses, and EXPLICITLY mentions them. Go and read 'firmware/WHENCE'. The licenses listed therein range from use-permitted only no-modification, to GPL-compliant and BSD-like. For that matter, for all we know kdelibs contains 10 lines of code from Jack Smith, who didn't agree to the LGPL and those 10 lines are under the Jack Smith Distribution License. However, it would be best if Jack Smith were to take this up with the KDE team and not with every distro that uses KDE. I'm not concerned with a case such as the above. Jack Smith needs to take it up with KDE. If Gentoo starts second-guessing the licenses on packages, do we then become liable if we fail to do this for a package? There is no second-guessing. What I am concerned with is that Gentoo's statement of licensing does not accurately reflect what licenses are on the package. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Monday 28 December 2009 21:04:01 Fabio Erculiani wrote: To me you are saying that DEPEND would work just fine. No? Setting the proto as DEPEND for the library wouldn't work because a user could install the library, remove every DEPEND-only package and legitimately expect the library to continue working, including being able to build other programs against it. Putting the proto in DEPEND for every package that uses the library isn't good because (unless the package references the proto directly) the fact that the proto is needed is an internal detail of the library, that might even change between versions, and packages using the library shouldn't have to know about it.
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
Le 28/12/2009 23:53, Fabio Erculiani a écrit : Interesting, eventually somebody gave me a detailed and technical explanation without [bla bla snip]. Thanks Rémi. Yes, I agree with you that the best (and the one I would go for, too) solution is adding support to a new *DEPEND, perhaps one that could host build-deps only. It looks weird that other PMs out there do that since 1994 (replace 1994 with older value). Perhaps adding a big fat # XXX somewhere in ebuilds would have helped us all in saving some time today. We could indeed, but back then we had something like 20~30 dupes so it felt like an obvious fix. I'll start adding comments in the overlay to clear it up. So, at least for now, I suspect I have to give up and close my shiny 27 bugs. Right? I'm afraid so, yes :) But if you do want to tackle the EAPI/PMS issue, feel free to reuse the tracker for that. I'll gladly tune in for that discussion. Cheers, Rémi
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
2009/12/28 Doug Goldstein car...@gentoo.org: Why not provide some actual meat and potatoes here instead of a useless e-mail with bug numbers and some stupid attempt at humor at the expense of the x11 herd? That hostility was totally uncalled for. Please try to remain civil. Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] Non-free software in Gentoo
On 12/28/2009 05:53 PM, Robin H. Johnson wrote: You're wrong there. The kernel does contain additional licenses, and EXPLICITLY mentions them. Go and read 'firmware/WHENCE'. The licenses listed therein range from use-permitted only no-modification, to GPL-compliant and BSD-like. I stand corrected. Somebody should tell Linus that his readme/copying is a bit misleading. They really shouldn't bury licenses in subdirectories. There is no second-guessing. What I am concerned with is that Gentoo's statement of licensing does not accurately reflect what licenses are on the package. Agreed - I think the key is for the package maintainer to ensure the license is accurate, and if anybody notices a problem just file a bug. I think the kernel is a bit of an oddball since the sources are so large - most packages are much smaller and have a single license, and the maintainer will probably be familiar enough to sort it out.
Re: [gentoo-dev] Non-free software in Gentoo
Rémi Cardona wrote: Unless people dedicate time and effort, ACCEPT_LICENSE is useless. Well, I think an incomplete tool is better than no tool at all. Even though it's far from perfect, I still found it very useful to create a free system. I'm certainly interested in helping to improve it. I'd say this is probably better suited for gentoo-project, but it's probably ok to start here, to gauge interest :) Thanks, I'll subscribe to gentoo-project also. Jeremy Olexa wrote: File bugs mate. Licensing is not exactly clear to all users or devs. As can be seen here[1] for dos2unix. It sounds like you care in this area, so get involved. That looks like a great starting point, thanks. The bug you mentioned has been fixed already! Robin H. Johnson wrote: The COPYRIGHT file in dos2unix is actually a 2-clause BSD license. I've updated the ebuild suitably. Thanks, much appreciated. File a bug with some ebuilds. It looks like somebody already has. See http://bugs.gentoo.org/show_bug.cgi?id=266157. I tested the latest ebuild, and it worked fine (see comment #59.) What would have to be done to get it in the main tree? A profile is not the answer here. An optional DEP block || ( media-fonts/corefonts ... ) where the other item does resolve using ACCEPT_LICENSES is what should be used. I'll have to read through the devmanual, thanks for the pointer. In your case, I propose that we add one or more stacked groups, with an initial content as such... I'll start working on expanding LIBRE-FREE-1 then. I assume a bug report would be the correct place to suggest this when I've made a decent start?
Re: [gentoo-dev] x11-libs/lib*: wrong RDEPENDs bug
On Mon, Dec 28, 2009 at 1:15 PM, Jeroen Roovers j...@gentoo.org wrote: On Mon, 28 Dec 2009 10:10:48 +0100 (CET) lx...@gentoo.org wrote: let's discuss concerns here (actually I don't see any and I am willing to fix all the ebuilds and close all my bugs if you ack). If they are genuine bugs, then there isn't anything to discuss. List of Gentoo bugs: Tracker bug is #298759[1] Regards, jer [1] https://bugs.gentoo.org/show_bug.cgi?id=298759 Then there was no need to waste everyone's time with a backhanded comment about the X11 herd. And we can all get on with our lives. -- Doug Goldstein
