[gentoo-dev] Re: [PATCH] libtool.eclass: Have elibtoolize explicitly apply configure patches
On 11/13/2013 10:14 AM, Michael Haubenwallner wrote:
Hi all,
as you might or might not be aware of, elibtoolize() originally was for
applying
patches to ltmain.sh, but now also applies patches to configure scripts.
Attached patch drops that wild guesses, explicitly applying configure-patches
to
configure scripts, while still explicitly applying ltconf.sh-patches to
ltconf.sh.
One update to this patch, to run elibtoolize once per directory again,
even if both filenames are in that same directory:
- set -- $(find ${S} '(' -name ltmain.sh -o -name configure ')'
-printf '%h ')
+ set -- $(find ${S} '(' -name ltmain.sh -o -name configure ')'
-printf '%h\n' | sort -u)
WDYT?
Without objections, I plan to commit this patch by the end of next week.
Thank you!
/haubi/
Index: libtool.eclass
===
RCS file: /var/cvsroot/gentoo-x86/eclass/libtool.eclass,v
retrieving revision 1.106
diff -u -r1.106 libtool.eclass
--- libtool.eclass 11 May 2013 11:17:58 - 1.106
+++ libtool.eclass 15 Nov 2013 09:57:08 -
@@ -204,9 +204,9 @@
# Reuse $@ for dirs to patch
set --
if [[ ${do_shallow} == yes ]] ; then
- [[ -f ${S}/ltmain.sh ]] set -- ${S}
+ [[ -f ${S}/ltmain.sh || -f ${S}/configure ]] set -- ${S}
else
- set -- $(find ${S} -name ltmain.sh -printf '%h ')
+ set -- $(find ${S} '(' -name ltmain.sh -o -name configure ')'
-printf '%h\n' | sort -u)
fi
local d p
@@ -225,8 +225,12 @@
ewarn avoid this if possible (perhaps by filing a
bug)
fi
+ local ret
+
+ # patching ltmain.sh
+ [[ -f ${d}/ltmain.sh ]]
for p in ${elt_patches} ; do
- local ret=0
+ ret=0
case ${p} in
portage)
@@ -258,17 +262,6 @@
ELT_walk_patches ${d}/ltmain.sh ${p}
ret=$?
;;
- uclibc-conf)
- if grep -qs 'Transform linux'
${d}/configure ; then
- ELT_walk_patches
${d}/configure ${p}
- ret=$?
- # ltmain.sh and co might be in a
subdirectory ...
- elif [[ ! -e ${d}/configure ]] \
-grep -qs 'Transform linux'
${d}/../configure ; then
- ELT_walk_patches
${d}/../configure ${p}
- ret=$?
- fi
- ;;
uclibc-ltconf)
# Newer libtoolize clears ltconfig, as
not used anymore
if [[ -s ${d}/ltconfig ]] ; then
@@ -276,34 +269,12 @@
ret=$?
fi
;;
- fbsd-conf)
- if grep -qs 'version_type=freebsd-'
${d}/configure ; then
- ELT_walk_patches
${d}/configure ${p}
- ret=$?
- # ltmain.sh and co might be in a
subdirectory ...
- elif [[ ! -e ${d}/configure ]] \
-grep -qs
'version_type=freebsd-' ${d}/../configure ; then
- ELT_walk_patches
${d}/../configure ${p}
- ret=$?
- fi
- ;;
fbsd-ltconf)
if [[ -s ${d}/ltconfig ]] ; then
ELT_walk_patches
${d}/ltconfig ${p}
ret=$?
fi
;;
- darwin-conf)
- if grep -qs ' echo \.so ||'
${d}/configure ; then
- ELT_walk_patches
${d}/configure ${p}
- ret=$?
- # ltmain.sh and co might be in a
subdirectory ...
- elif [[ ! -e ${d}/configure ]] \
-grep -qs ' echo
[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
Ulrich Mueller posted on Fri, 15 Nov 2013 08:13:47 +0100 as excerpted: On Fri, 15 Nov 2013, Ben de Groot wrote: As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. Option 1 is not a solution, but a workaround. It has served us, but IMHO its replacement is overdue. Just to give an example, stable emul-linux-x86-xlibs suffers from several security issues (bug 471098, A1/critical severity) since half a year. Besides, distributing pre-compiled binary packages seems very un-Gentoo-ish. Indeed. From amd64's gentoo roots the gentoo/amd64 people considered emul-* a sort-of-embarrassing workaround for a distro such as gentoo, where for many the biggest /point/ is building from sources in ordered to enable more user-level customization. Basically it was and remains a case of saying Umm... we believe in building from source, except don't look too closely because in some cases we don't. If people are willing to accept emul-* because it's easier, why bother with gentoo at all, because binary distros that make all compile-time choices for the user are even /easier/? So indeed, emul-* is a workaround, and quite a hacked up one for a distro such as gentoo at that, NOT a solution. However, I'd replace it as a solution with the (32-bit) chroot solution, which I use here along with no-multilib for my main amd64 system, except that I extended the chroot to build the full image (including kernel, system daemons, grub, etc, that wouldn't need built on a simple 32-bit chroot) so as to be able to transfer it first via USB thumbdrive and eventually via SSH to my 32-bit netbook, which boots from it. (I could thus make the 32-bit image on my main machine bootable as well, with trivial effort, letting me dual-boot it, but I've had no reason to do so.) The 32-bit chroot solution is indeed a full gentoo-level solution, already documented, requiring no changes to the tree or to PMs, since it uses the existing x86 arch profiles just as they come. So: 1: emul-* packages[1] 2: multilib-portage 3: multilib.eclass 4: chroot[2] [1] hacked up workaround, not a proper gentoo level solution. [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either one for x86-32, or some other combination for other archs. Not sure why you think that option 3 is more intrusive than option 2. What can be more intrusive than requiring a modified package manager? If the perspective is that of a plain no-multilib user (even one like me using the 32-bit chroot solution), or even a standard multilib user satisfied with the emul-* workaround, then option 3 is very intrusive indeed, since it has already triggered quite a few package updates with the only purpose being introduction of a feature these users aren't particularly interested in. To these folks, options 2 and 4 are preferred, since for the most part the only folks affected are those who will actually be using the feature. Indeed, while option 2 has required some mostly trivial patches and I think a whole EAPI, option 4 requires none of that, operating with the existing tree just as it is. It'd be a rare bug indeed that affected a chroot solution but didn't affect other users of the target arch, especially since gentoo's installation model already involves chroots, so bugs involving chroots in @system at least, by /definition/ involve the affected arch, and should be caught and worked out by releng as a result. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On 11/15/2013 03:13 PM, Ulrich Mueller wrote: On Fri, 15 Nov 2013, Ben de Groot wrote: As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. Option 1 is not a solution, but a workaround. It has served us, but IMHO its replacement is overdue. Just to give an example, stable emul-linux-x86-xlibs suffers from several security issues (bug 471098, A1/critical severity) since half a year. That's not an argument for or against anything, that just shows that we don't even have enough devs caring for the easiest method. Maybe ... dunno ... maybe that should be more automated so that a single trigger could generate the packages. Besides, distributing pre-compiled binary packages seems very un-Gentoo-ish. Indeed. Not sure why you think that option 3 is more intrusive than option 2. What can be more intrusive than requiring a modified package manager? What's intrusive? We tolerate EAPI5, @preserved-rebuild and other package manager mods too ...
[gentoo-dev] Re: keep a gen 2013 snapshot on mirrors
Rich Freeman posted on Wed, 13 Nov 2013 16:18:51 -0500 as excerpted: On Wed, Nov 13, 2013 at 3:49 PM, Roy Bamford neddyseag...@gentoo.org wrote: The GPL obliges us to keep such patches around for three years, iirc. Don't we do that ? Why? We own the copyright on the patches (to whatever degree that they're copyrightable), so we don't need a license to distribute them. If somebody else wants to redistribute our patches they need our permission or they need to comply with whatever license we issue them under (likely the same as the upstream license so that our users don't have bindist issues). IANAL of course, but as someone who cares about such things because he knows they protect his rights, and who thus follows discussions such as this rather closer than most... For the GPL, the biggest concern is binary distribution, covered under section three of the GPL (v2 at least), and this is where the three-year clause appears. Because gentoo in-the-main only distributes sources and any patches are generally distributed under the same license as the primary package sources, that clause in general doesn't apply. There are, however, two big exceptions to gentoo's sources-only distribution, the installers and stage tarballs, and the packages CD/DVD images. It is with these that there is some concern, and where gentoo has in the past had GPL violations. However, if you look at section three, there are three alternative clauses. Complying with only one of the three is necessary (my rewording of the GPLv2 license from the file in the tree, see the license itself for the literal wording if there's any doubt): 3a) Accompany binaries/object code with complete source-code. 3b) Accompany them with a written offer for source code, valid for at least three years from date of last distribution of binary/object code. 3c) Pass on the 3b offer you received from upstream. (Non-commercial only, only applies to code unmodified from upstream and thus not to the case under discussion.) Since 3c is out for modified code, that leaves 3a or 3b. But the three years of 3b ends up being a long time to track such things! Luckily, there's still 3a, which if properly complied with, lets gentoo off the hook for 3b. What that means is this: Every time and place gentoo distributes binaries, we must make available sources as well. If we're giving away install-CDs at a conference, we better have a few copies of the parallel sources CD, including our patches, available as well. (The stack of sources CDs could of course be smaller, provided we're willing to remove the stack of installer CDs until we burn a few more source CDs if they ever run out.) Similarly on the net, if we're distributing stage tarballs, we should ensure that we have the sources available for download at the same time as well. Where gentoo screwed up in the past is that for quite awhile, we kept past installer images available as well, for historical interest. At some point we were made aware of the fact that this was a violation of the GPL if the corresponding sources, INCLUDING OUR PATCHES, were not either directly available as well, or available on request for three years, and we had to take those historical copies down. But IIRC that was well over three years ago now, so AFAIK, we're out of violation on at least the major scale, tho it remains possible that someone representing gentoo at a conference might up and fail to ensure those source CDs are made available with the installer CDs, for instance, thus obligating us to a three-year-clock we might have problems actually following up on, should someone make that request. I would hope that the PR project folks properly brief all conference booth volunteers to ensure that doesn't happen, however. The only thing we might need a license to redistribute are the parts of the patch that we didn't change, and upstream already provides those. I don't think patches are a derivative work. To the extent patches are larger than the rather blurry trivial level, I believe there's no question that they ARE derivative. In the case of literal patches, literally and provably so, due to the context-diff which literally includes lines from the original from which it is derived. However, fair-use laws often allow trivial use, and while that's a somewhat blurry line and fair-use laws definitely differ from country to country, I found a reference in the FSF FAQ that says they use a 300-line benchmark (tho that's in the whole work context): http://www.gnu.org/licenses/gpl-faq.html#WhatIfWorkIsShort While I think most would agree that a one-line patch is trivial, I'm not so sure about a 50-line patch tho it's nowhere near that 300-line threshold, which itself is just the FSF benchmark, tho I'm not sure if that FAQ context is applicable to patches or not. However, given the above 3a clause and gentoo's efforts to comply with it, I suppose the whole question
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 1:53 AM, Ben de Groot yng...@gentoo.org wrote: I don't really want to bring up this episode again, but it is a telling example, which you asked for. I appreciate that. I did ask for an example. I'll also limit my comments just to things that I think are more helpful moving forward. As can be seen from the ChangeLog, I was the primary maintainer. Depends on your definition of maintainer. If you define maintainer as somebody who has actually been doing work on a package, then you were. If you define it as the person listed in metadata.xml, then you weren't. Ideally those should match, so that when projects have to go running around the tree making changes they don't have to read between the lines to figure out who is the right contact for any particular package. They match now, which is good. I am even tempted to undo the multilib changes to freetype, since it is still causing trouble (just search for freetype bugs and see how often multilib pops up). Well, make sure you talk to the OTHER maintainer for that package, which is the multilib team, before doing that. You don't own the package - you just help to maintain it. I don't want to rehash the thread from last summer - I do appreciate your feelings and I'm trying to find a balance. I want to appreciate the fact that maintainers have the largest investment in their packages, but at the same time those working on projects are investing in Gentoo as well. Michał did add the multilib project as a co-maintainer, taking responsibility for dealing with the multilib-related issues long-term. In my mind this is the sort of things projects should do. Indeed, but more communication with the current actual maintainers of the package in question should also be part of that. You're both actual maintainers now. Certainly I agree that you should be talking to each other. :) I'd hope that things are going better now, but if they aren't I'd hope that Comrel would provide some assistance here. I am also cautiously optimistic about a renewed QA team, which could be involved more in this kind of issues. I tend to agree here, but their role isn't to pick winners so much as to defend the general integrity of the tree. I think the challenge is figuring out how good, good enough, is before these packages end up in ~arch (which IS intended for TESTING packages, but packages that are fairly likely to work with some maintainer testing already). If you say council should take more of a leadership role, then maybe this issue can be decided by council and a clear direction be taken by the distro as a whole? Then those who oppose the choice made can either put up or shut up, and we can all work at implementing the chosen solution. Should we pick an init system while we're at it? :) Honestly, I don't think we can really choose anything at this point as none of the solutions are really fully-baked. If the Council simply pronounced support for one of them the only result would be that people might stop working on the other two, with no further progress on the chosen one. Then if that one dies on the vine we're stuck. I do have thoughts around things that could be improved, but I don't think either of the new options are at the point where they make sense. Both options really have to progress further on their own before we can think about standardizing/etc. Rich
Re: [gentoo-dev] Re: keep a gen 2013 snapshot on mirrors
On Fri, Nov 15, 2013 at 8:17 AM, Duncan 1i5t5.dun...@cox.net wrote: To the extent patches are larger than the rather blurry trivial level, I believe there's no question that they ARE derivative. In the case of literal patches, literally and provably so, due to the context-diff which literally includes lines from the original from which it is derived. Ok, to illustrate, let's consider the bit I just quoted the original work. This would be a derivative work: To the extent patches are larger than the rather blurry trivial level, I believe there's no question that they ARE derivative. In the case of literal patches, literally, and figuratively, and provably so, due to the context-diff which literally includes lines from the original from which it is derived. This would not be a derivative work: and figuratively, This isn't a derivative work: On line three insert the characters and figuratively, after the second comma. This is more fuzzy, but is probably fair use to the extent that it is a derivative work: I believe there's no question that they ARE derivative. In the case of -literal patches, literally, and provably so, due to the context-diff which +literal patches, literally, and figuratively, and provably so, due to the context-diff which literally includes lines from the original from which it is derived. That's what I'm getting at. The actual changes themselves aren't a derivative work - it is the result of applying them that is. Rich
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 02:13 AM, Ulrich Mueller wrote: On Fri, 15 Nov 2013, Ben de Groot wrote: As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. Option 1 is not a solution, but a workaround. It has served us, but IMHO its replacement is overdue. Just to give an example, stable emul-linux-x86-xlibs suffers from several security issues (bug 471098, A1/critical severity) since half a year. Besides, distributing pre-compiled binary packages seems very un-Gentoo-ish. Not sure why you think that option 3 is more intrusive than option 2. What can be more intrusive than requiring a modified package manager? I concurr -- option #1 has existed for some time but it's entirely a workaround rather than a solution. Option 2 and Option 3, though, I don't see as having to be a competing system -- to me they provide for different goals (most of which overlap, but still). Multilib-portage provides the ability to build an entire userland in as many ABIs as can be supported -- bins, libs, the whole deal; no matter if the in-tree ebuilds have an alt-ABI specification or not. The multilib eclasses allow any ebuild that needs to, to depend on a non-native-ABI library and forces any package manager to work it out via use flags. #3 works for everyone in a more limited scope than #2 (just libs, generally with the goal of only including the few libs the in-tree consumers actually need). #2 provides users that want it with a specific PM to manage their system, as alternative to the other PMs out there. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGLzgACgkQ2ugaI38ACPCrkgD+JNG1iF/oGh/5gXtqhTXlhHGL A4tM6dbfZxmt793CTGwA+wercYN3gwb10GHyxs0bUMkime+cWDFpPphjPHU9BAtn =BPc1 -END PGP SIGNATURE-
Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 06:08 AM, Duncan wrote: [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either one for x86-32, or some other combination for other archs. Well, not really -- an x86 toolchain can't build for amd64 or x32 , you need a crossdev for that. I don't think either multilib-portage or the multilib-eclass solution are going to be substantive enough to incorporate crossdev building directly into the package manager. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGMCAACgkQ2ugaI38ACPBGWwD/QaFE626C44E8N1d/6aupdfsh vHlKe9xmtfcANRV8QlkA/0pt9P9XYsNahnU/hJvpwSg3QGTQlB3yf3npTuZ8BkiL =ImMI -END PGP SIGNATURE-
[gentoo-dev] Re: keep a gen 2013 snapshot on mirrors
Rich Freeman posted on Fri, 15 Nov 2013 08:38:20 -0500 as excerpted: That's what I'm getting at. The actual changes themselves aren't a derivative work - it is the result of applying them that is. I can (cautiously) agree with that, tho I'm sure there are those who would take an opposing position, certainly if they're lawyers paid to do so! Meanwhile, I found your (paraphrased) on the third line, after the comma example interesting, both since I saw a similar argument on one of the pages that came up in my google, and because it's basically what a sed script (as opposed to a patch) does in practice. The point being that simple instructions saying /how/ to do it, without incorporating any of the original work, can hardly be said to be derived. (The example I saw in my google was text instructions for cutting a face out of a larger photo and putting a red frame around it. It's quite clear that those text instructions are not derivative of a particular photo, while a screen-grab illustrating the process may well be considered derivative of the original photo, since it includes part of it. A sed script is arguably similar, tho s// regex replacement can certainly be borderline, but for the triviality test.) -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
Ian Stakenvicius posted on Fri, 15 Nov 2013 09:30:56 -0500 as excerpted: On 15/11/13 06:08 AM, Duncan wrote: [2] 32-bit for amd64, but could be the reverse, 64-bit for x86, or either one for x86-32, or some other combination for other archs. Well, not really -- an x86 toolchain can't build for amd64 or x32 , you need a crossdev for that. I don't think either multilib-portage or the multilib-eclass solution are going to be substantive enough to incorporate crossdev building directly into the package manager. Good point. I let my efforts to be inclusive get the best of my common sense. =:^( -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Matt Turner wrote: I think in large part recently it's because of use.stable.mask and package.use.stable.mask. These really are a nightmare for users. .. I think most of the confusion is caused by the necessity to put a *stable* package atom into package.keywords to unmask a *USE* flag. A lot can be learned just from the filenames: use.stable.mask package.use.stable.mask The latter indicates that this concept has no less than four dimensions. Let's enumerate and associate: 1. use - USE flags - no problem, Gentoo users either love USE flags or leave 2. stable - arch vs. ~arch - no problem, even installation docs describe it 3. mask - masked packages - OK, at some point people encounter masked packages 4. package - per-package stuff - like with /etc/portage/package.use How stable and mask interact with USE is absolutely unclear and usability of this is very close to zero. //Peter
Re: [gentoo-dev] Re: keep a gen 2013 snapshot on mirrors
Duncan wrote: 3a) Accompany binaries/object code with complete source-code. .. What that means is this: Every time and place gentoo distributes binaries, we must make available sources as well. accompany !== make available If we're giving away install-CDs at a conference, we better have a few copies of the parallel sources CD, including our patches, available as well. (The stack of sources CDs could of course be smaller, provided we're willing to remove the stack of installer CDs until we burn a few more source CDs if they ever run out.) Similarly on the net, if we're distributing stage tarballs, we should ensure that we have the sources available for download at the same time as well. I think those two are nowhere near good enough. Accompanied means that both go together AFAIU, though I'm not a native english speaker. //Peter
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 10:54 AM, Peter Stuge wrote: Matt Turner wrote: I think in large part recently it's because of use.stable.mask and package.use.stable.mask. These really are a nightmare for users. .. I think most of the confusion is caused by the necessity to put a *stable* package atom into package.keywords to unmask a *USE* flag. A lot can be learned just from the filenames: use.stable.mask package.use.stable.mask The latter indicates that this concept has no less than four dimensions. Let's enumerate and associate: 1. use - USE flags - no problem, Gentoo users either love USE flags or leave 2. stable - arch vs. ~arch - no problem, even installation docs describe it 3. mask - masked packages - OK, at some point people encounter masked packages 4. package - per-package stuff - like with /etc/portage/package.use How stable and mask interact with USE is absolutely unclear and usability of this is very close to zero. Well, reordering this a bit: 1 - package: so this is per-package. 2 - use: so this has to do with use flags, per package 3 - stable: so this has to do with stable systems' use flags, per package 4 - mask: so this is disallowing something on stable systems' use flags, per package. So I don't think this is entirely unclear. I suppose it might be a bit more clear if it was called 'package.stable.use.mask', or the ideal english version of 'stable.package.use.mask', but i think renaming it at this point doesn't really provide that much of an advantage and definitely doesn't change what it does. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGRkUACgkQ2ugaI38ACPAu+gD/U6rExYFTC7fUMFIuQgbgJwRn I0sA9NSixk6gtVj8E8IA/i1jzlQnkjHQFnHw3qHnTtdUGpJHFn/0saxItbn6ieE9 =+7UA -END PGP SIGNATURE-
[gentoo-dev] Local Gentoo User Group community support
Hi What does Gentoo Linux provide for $SUBJ? I know there are mailing lists like gentoo-user-lang. Is there anything else? --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner matts...@gentoo.org wrote: Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner matts...@gentoo.org wrote: Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 15/11/13 02:24 PM, Tom Wijsman wrote: On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner matts...@gentoo.org wrote: Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. Not only that, but these spurious slot collision errors pop up all the time and are useful only for confusing portage users, unless they actually get it right in the very rare cases -- and they only get it right, it seems, when you don't see no parents that aren't satisfied by other packages in this slot on one side of the collision. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlKGdogACgkQ2ugaI38ACPBlWAD8CxzN2Q2jnkCZkmrXcBpTQNoD v30A1BnDvJen3JilQf0A/jm3aT/2B7vY7xwqTCnlaRE8VQNjgJQptn3HT7LRCic0 =nEcM -END PGP SIGNATURE-
Re: [gentoo-dev] News item about Gnome 3.8
El jue, 14-11-2013 a las 22:22 +0100, Pacho Ramos escribió: New try: Title: Upgrade to GNOME 3.8 Author: Pacho Ramos pa...@gentoo.org Content-Type: text/plain Posted: 2013-11-14 Revision: 1 News-Item-Format: 1.0 Display-If-Installed: gnome-base/gnome-3.8 Display-If-Installed: gnome-base/gnome-light-3.8 Display-If-Installed: gnome-base/gnome-session-3.8 We are pleased to announce the stabilization of GNOME-3.8. Users are strongly encouraged to read the GNOME 3.8 Upgrade Guide to avoid any possible issues relating to the upgrade. The guide will also show you how to migrate to systemd as it is the only supported setup now, suggesting you how to avoid blockers and problems trying to let you have a smoother update. Additionally, will - *it* will (as pointed by Mark Pariente via mail) :) inform you about important changes regarding configuration and troubleshooting. Please read the Gnome 3.8 Upgrade Guide: http://wiki.gentoo.org/wiki/GNOME/3.8-upgrade-guide
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 11:24 AM, Tom Wijsman tom...@gentoo.org wrote: On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner matts...@gentoo.org wrote: Attempting to merge =x11-proto/kbproto-1.0.6-r1 results in: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) No, it doesn't, it gives you a lot more output than that; you appear to be distracted by something that doesn't appear to be a problem at all. What? Where do you get off telling me that the output I copied and pasted into this email is wrong? dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg =x11-proto/kbproto-1.0.6-r1 dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] x11-proto/kbproto-1.0.6-r1 ABI_X86=32 (64) (-x32) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB dynamic71 mattst88 # sed -i -e 's|=x11-proto/kbproto|#=x11-proto/kbproto|' /etc/portage/package.keywords/xorg dynamic71 mattst88 # grep kbproto /etc/portage/package.keywords/xorg #=x11-proto/kbproto-1.0.6-r1 dynamic71 mattst88 # emerge '=x11-proto/kbproto-1.0.6-r1' -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] x11-proto/kbproto-1.0.6-r1 ABI_X86=(64) (-32*) (-x32) 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: x11-proto/kbproto:0 (x11-proto/kbproto-1.0.6-r1::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-proto/kbproto-1.0.6-r1::gentoo, installed) pulled in by x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libX11-1.6.2::gentoo, installed) x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?] required by (x11-libs/libXt-1.1.4::gentoo, installed) !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Thu, 14 Nov 2013 20:56:32 -0800 Matt Turner matts...@gentoo.org wrote: There's a single problem. It can't enable abi_x86_32. Why didn't it just say that? As per the full output, it does: !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. That together with ABI_X86=(64) (-32*) (-x32) from the package line makes it clear that it is trying to change that USE flag. But as you haven't told emerge yet to do so, it doesn't; which makes it unable. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Local Gentoo User Group community support
On 15.11.2013 20:12, yac wrote: Hi What does Gentoo Linux provide for $SUBJ? I know there are mailing lists like gentoo-user-lang. Is there anything else? -project is where you wanted to post this --- Jan Matějka| Gentoo Developer https://gentoo.org | Gentoo Linux GPG: A33E F5BC A9F6 DAFD 2021 6FB6 3EBF D45B EEB6 CA8B -- Alex Legler a...@gentoo.org Gentoo Security/Ruby/Infrastructure signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. That together with ABI_X86=(64) (-32*) (-x32) from the package line makes it clear that it is trying to change that USE flag. I disagree quite strongly with that statement. There is no clear message at all about the situation. The problem is that the USE flag is hidden on the package line as opposed to mentioned explicitly by portage. It's easy for software to print meaningful output based on the data it has while it is awkward for humans to scan lines and lines of output for parentheses with *s and -s. I very much appreciate that you clarified what you meant by No. Thanks //Peter pgp6r0PcRQNo2.pgp Description: PGP signature
[gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
Ian Stakenvicius a...@gentoo.org wrote: On 15/11/13 10:54 AM, Peter Stuge wrote: .. I think most of the confusion is caused by the necessity to put a *stable* package atom into package.keywords to unmask a *USE* flag. A lot can be learned just from the filenames: [...] The latter indicates that this concept has no less than four dimensions. Well, reordering this a bit: [...] So I don't think this is entirely unclear. I think the point of Peter is not whether the *name* of the file is optimally chosen: His point is that the *semantics* (which is somehow reflected in the name) is too complex in the sense that it combines at least two concepts (USE-Flags and Stability) which from th user's point of view are completely unrelated. Only the developer's point of view of wanting to stabilize something earlier makes a connection between these concepts, but it is not really a natural conncetion: For someone who is not familiar with implicit implications of every USE-flag (i.e. a non-developer), the result looks like an almost random change of active USE-flags. Probably a lot of the confusion could be avoided if /etc/portage/package.accept_keywords would not implicitly unmask useflags. If this is not very hard to implement in portage, I would strongly vote to remove this implicit connection: This side effect is obviously the cause of the dependency hell examples.
Re: [gentoo-dev] Re: Please consider removing use.stable.mask and package.use.stable.mask
Martin Vaeth wrote: Probably a lot of the confusion could be avoided if /etc/portage/package.accept_keywords would not implicitly unmask useflags. I think so too. Anything that happens implicitly where explicit knobs exist is really counter-intuitive. //Peter
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 21:10:41 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: !!! Enabling --newuse and --update might solve this conflict. !!! If not, it might help emerge to give a more specific suggestion. That together with ABI_X86=(64) (-32*) (-x32) from the package line makes it clear that it is trying to change that USE flag. I disagree quite strongly with that statement. There is no clear message at all about the situation. The problem is that the USE flag is hidden on the package line as opposed to mentioned explicitly by portage. It's easy for software to print meaningful output based on the data it has while it is awkward for humans to scan lines and lines of output for parentheses with *s and -s. Which is not the case here; as a single package is being emerged, the output is rather short. So, it is as clear as how much you read of it. The shortness of the output actually makes it much easier to scan. The other case would be `emerge -uDN @world` which gives a lot of output; but that case is different, as it wouldn't suggest the above. Now imaging if that long output was very much longer; the longness of that output, would be quite impossible to scan within the time one would process the normal `emerge -uDN @world` output. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org wrote:
On Thu, 14 Nov 2013 20:56:32 -0800
Matt Turner matts...@gentoo.org wrote:
There's a single problem. It can't enable abi_x86_32. Why didn't it
just say that?
As per the full output, it does:
!!! Enabling --newuse and --update might solve this conflict.
!!! If not, it might help emerge to give a more specific suggestion.
That together with ABI_X86=(64) (-32*) (-x32) from the package line
makes it clear that it is trying to change that USE flag. But as you
haven't told emerge yet to do so, it doesn't; which makes it unable.
Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
unmerge kbproto and attempt to emerge libXt:
dynamic71 mattst88 # emerge libXt -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
emerge: there are no ebuilds built with USE flags to satisfy
x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?].
!!! One of the following packages is required to complete your request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by x11-libs/libXt-1.1.4 [ebuild])
(dependency required by libXt [argument])
It suggests that I turn off abi_x86_32 for libXt rather than telling
me to turn the flag on for kbproto!
Portage prints other things intelligently:
mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)
[ebuild N ] dev-python/pytest-2.3.5 USE={test} -doc
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 417 kB
[ebuild N ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 185 kB
Total: 2 packages (2 new), Size of downloads: 602 kB
* Error: circular dependencies:
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
(dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge) (buildtime)
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)
Note that this change can be reverted, once the package has been installed.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner matts...@gentoo.org wrote:
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org
wrote:
Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
unmerge kbproto and attempt to emerge libXt:
[...]
emerge: there are no ebuilds built with USE flags to satisfy
x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?].
!!! One of the following packages is required to complete your
request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by x11-libs/libXt-1.1.4 [ebuild])
(dependency required by libXt [argument])
It suggests that I turn off abi_x86_32 for libXt rather than telling
me to turn the flag on for kbproto!
Why should it literally suggest you to do something known to be broken?
It is clear from the output how it wants the dependency to be; so, if
you want to do something different, you can and the output tells enough.
Due to the complexity of the dependency, you will need `man 5 ebuild`
though; (-) means to assume it as disabled if it doesn't exist.
Portage prints other things intelligently:
mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)
[ebuild N ] dev-python/pytest-2.3.5 USE={test} -doc
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 417 kB
[ebuild N ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 185 kB
Total: 2 packages (2 new), Size of downloads: 602 kB
* Error: circular dependencies:
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
(dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
(buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)
Note that this change can be reverted, once the package has been
installed.
This is just like how you can't compile gcc without having compiled gcc
with another compiler first (or used a binpkg, or obtained from stage3);
thus, similarly, you can't test py without having pytest first etc...
For example, emerging dev-java/icedtea without a Java compiler / runtime
present will show you the same behavior; and there are some other
circular dependencies present in the tree that behave similarly.
It's a problem that you can't really solve as far as I know; bugs are
often getting filed for it, but without a fix. One filed against
Portage is for example https://bugs.gentoo.org/show_bug.cgi?id=417675
but it hasn't received much attention; because well, I doubt if a proper
solution to this would be simple.
Workarounds mentioned are hacking up the vdb or changing --newuse.
Does replacing this explicit behavior by implicit behavior make
sense for the users in general? Does it make sense for those that just
want to test? Will people understand it if it were implicit behavior?
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: Does replacing this explicit behavior by implicit behavior make sense for the users in general? Please don't warp the words. Maybe I misunderstand, but it seems like that's what you're doing. I'll try to clarify: With explicit I was refering to allowing manual setting and unsetting of USE flags, keywords and masks. With implicit I was refering to those same things happening automatically. USE flags set or unset automatically, keywords set or unset automatically, masks set or unset automatically - as a result of something or other. Any such automations significantly diminish the value of the explicit knobs and are counter-intuitive. If someone is given a mechanism to control which USE flags are set or unset then it's just stupid to go around those settings. I understand the temptation to make things happen automatically for ease of development, and that is perfectly fine as long as those automations aren't exposed to users. //Peter pgpiM9GF5fyrB.pgp Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman tom...@gentoo.org wrote:
On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner matts...@gentoo.org wrote:
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org
wrote:
Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for
kbproto but was attempting to emerge unstable (or unmasked abi_x86_32)
libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked),
unmerge kbproto and attempt to emerge libXt:
[...]
emerge: there are no ebuilds built with USE flags to satisfy
x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?].
!!! One of the following packages is required to complete your
request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by x11-libs/libXt-1.1.4 [ebuild])
(dependency required by libXt [argument])
It suggests that I turn off abi_x86_32 for libXt rather than telling
me to turn the flag on for kbproto!
Why should it literally suggest you to do something known to be broken?
I don't know what you mean. kbproto[abi_x86_32] isn't known to be
broken. You're asking a really weird question based on some implicit
context that's not available to me.
I'm claiming in this example that attempting to emerge
libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
set for kbproto, rather than telling you to unset abi_x86_32 for libXt
(which you're requesting to be emerged, damn it!).
It is clear from the output how it wants the dependency to be; so, if
you want to do something different, you can and the output tells enough.
Due to the complexity of the dependency, you will need `man 5 ebuild`
though; (-) means to assume it as disabled if it doesn't exist.
Portage prints other things intelligently:
mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)
[ebuild N ] dev-python/pytest-2.3.5 USE={test} -doc
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 417 kB
[ebuild N ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 185 kB
Total: 2 packages (2 new), Size of downloads: 602 kB
* Error: circular dependencies:
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends on
(dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
(buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)
Note that this change can be reverted, once the package has been
installed.
This is just like how you can't compile gcc without having compiled gcc
with another compiler first (or used a binpkg, or obtained from stage3);
thus, similarly, you can't test py without having pytest first etc...
I don't think you understood my intention for giving this example.
Portage correctly figures out the proper solution and suggests it. I'm
saying that this is a good thing.
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 22:09:04 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: Does replacing this explicit behavior by implicit behavior make sense for the users in general? Please don't warp the words. Maybe I misunderstand, but it seems like that's what you're doing. I'll try to clarify: With explicit I was refering to allowing manual setting and unsetting of USE flags, keywords and masks. With implicit I was refering to those same things happening automatically. USE flags set or unset automatically, keywords set or unset automatically, masks set or unset automatically - as a result of something or other. Any such automations significantly diminish the value of the explicit knobs and are counter-intuitive. implicit in the context of this sub thread is it being present as part of another choice, whereas explicit makes it a separate choice. Currently the behavior is explicit because you have to break the dependency cycle yourself and decide how to, whereas making it implicit would solve it; in one or another particular way you'd be unaware of. If someone is given a mechanism to control which USE flags are set or unset then it's just stupid to go around those settings. This example was about a circular dependency, not about USE flags. I understand the temptation to make things happen automatically for ease of development, and that is perfectly fine as long as those automations aren't exposed to users. And that's the question, it is the hard part of figuring it out... :) (To be clear: In the context of the sub thread answering the example.) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 13:21:53 -0800
Matt Turner matts...@gentoo.org wrote:
On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman tom...@gentoo.org
wrote:
On Fri, 15 Nov 2013 12:25:47 -0800
Matt Turner matts...@gentoo.org wrote:
On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org
wrote:
Imagine I had simply forgotten to unmask the abi_x86_32 USE flag
for kbproto but was attempting to emerge unstable (or unmasked
abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that
abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt:
[...]
emerge: there are no ebuilds built with USE flags to satisfy
x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?].
!!! One of the following packages is required to complete your
request:
- x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32)
(dependency required by x11-libs/libXt-1.1.4 [ebuild])
(dependency required by libXt [argument])
It suggests that I turn off abi_x86_32 for libXt rather than
telling me to turn the flag on for kbproto!
Why should it literally suggest you to do something known to be
broken?
I don't know what you mean. kbproto[abi_x86_32] isn't known to be
broken. You're asking a really weird question based on some implicit
context that's not available to me.
A mask implies something is broken (or experimental).
I'm claiming in this example that attempting to emerge
libXt[abi_x86_32], portage should tell you that abi_x86_32 should be
set for kbproto, rather than telling you to unset abi_x86_32 for libXt
(which you're requesting to be emerged, damn it!).
You have to be explicit when you want broken (or experimental) things;
just emerging it isn't enough, taking a step further than that is.
I'm not sure if making broken (or experimental) things more easily
available or a suggestion would be a good idea; people already have
enough trouble as it is, adding more doesn't seem to be the right way.
It is clear from the output how it wants the dependency to be; so,
if you want to do something different, you can and the output tells
enough.
Due to the complexity of the dependency, you will need `man 5
ebuild` though; (-) means to assume it as disabled if it doesn't
exist.
Portage prints other things intelligently:
mattst88@dynamic71 ~ % FEATURES=test emerge dev-python/py -vp
These are the packages that would be merged, in order:
Calculating dependencies... done!
[nomerge ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3)
[ebuild N ] dev-python/pytest-2.3.5 USE={test} -doc
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 417 kB
[ebuild N ] dev-python/py-1.4.13 USE={test}
PYTHON_TARGETS=python2_7 python3_2 (-pypy2_0) -python2_6
(-python3_3) 185 kB
Total: 2 packages (2 new), Size of downloads: 602 kB
* Error: circular dependencies:
(dev-python/py-1.4.13::gentoo, ebuild scheduled for merge) depends
on (dev-python/pytest-2.3.5::gentoo, ebuild scheduled for merge)
(buildtime) (dev-python/py-1.4.13::gentoo, ebuild scheduled for
merge) (buildtime)
It might be possible to break this cycle
by applying the following change:
- dev-python/py-1.4.13 (Change USE: -test)
Note that this change can be reverted, once the package has been
installed.
This is just like how you can't compile gcc without having compiled
gcc with another compiler first (or used a binpkg, or obtained from
stage3); thus, similarly, you can't test py without having pytest
first etc...
I don't think you understood my intention for giving this example.
Portage correctly figures out the proper solution and suggests it. I'm
saying that this is a good thing.
Now the question is whether this is or isn't an opposite example;
because it might very well be intelligent, that doesn't mean that the
other example isn't intelligent. As we trying to make that clear, this
example doesn't really fit; so, I didn't assume it to be opposite.
--
With kind regards,
Tom Wijsman (TomWij)
Gentoo Developer
E-mail address : tom...@gentoo.org
GPG Public Key : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
signature.asc
Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 15 Nov 2013 13:21:53 -0800 Matt Turner matts...@gentoo.org wrote: On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 15 Nov 2013 12:25:47 -0800 Matt Turner matts...@gentoo.org wrote: On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org wrote: Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for kbproto but was attempting to emerge unstable (or unmasked abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt: [...] emerge: there are no ebuilds built with USE flags to satisfy x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]. !!! One of the following packages is required to complete your request: - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) (dependency required by x11-libs/libXt-1.1.4 [ebuild]) (dependency required by libXt [argument]) It suggests that I turn off abi_x86_32 for libXt rather than telling me to turn the flag on for kbproto! Why should it literally suggest you to do something known to be broken? I don't know what you mean. kbproto[abi_x86_32] isn't known to be broken. You're asking a really weird question based on some implicit context that's not available to me. A mask implies something is broken (or experimental). Then to answer your previous question: it would suggest it [something broken, according to you] because you've asked for something broken that depends on it! I'm claiming in this example that attempting to emerge libXt[abi_x86_32], portage should tell you that abi_x86_32 should be set for kbproto, rather than telling you to unset abi_x86_32 for libXt (which you're requesting to be emerged, damn it!). You have to be explicit when you want broken (or experimental) things; just emerging it isn't enough, taking a step further than that is. I'm explicitly saying that I want libXt with USE=abi_x86_32. Suggesting that I turn it off is kind of ridiculous, don't you think? This seems pretty clear cut. Are you just jerking me around now?
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: I'm not sure if making broken (or experimental) things more easily available or a suggestion would be a good idea; people already have enough trouble as it is, adding more doesn't seem to be the right way. It's not about broken/experimental, it's about the logical consequences of an explicit action taken by the user. The user must get feedback based on what they said that they wanted to do, not based on what is experimental. Mentioning that something is experimental is an optional bonus, but assuming that the user already knows that this is the case is OK too. portage should say, with as similar wording as possible: If you want to emerge libXt with those USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. Bonus points: Would you like me to set those USE flags for libYt and libZt for you? [Y/n] //Peter pgpeLULoOr_EM.pgp Description: PGP signature
[gentoo-dev] How to obsolete this python-exec news fix the issue automatically for users
On Wed, Nov 06, 2013 at 04:12:47PM +0100, Michał Górny wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. I don't know why nobody looked at a better automatic solution for the python-exec issue, but since it's still biting me on systems, and the manual solution is annoying, I found a working automatic solution. Add this line to the dev-lang/python-exec ebuilds: PDEPEND==dev-python/python-exec-1:$SLOT I wrote up the full research of it here: http://robbat2.livejournal.com/240335.html If there are no objections, I'd like to do this to the affected ebuilds in a few hours. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 13:45:29 -0800 Matt Turner matts...@gentoo.org wrote: On Fri, Nov 15, 2013 at 1:38 PM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 15 Nov 2013 13:21:53 -0800 Matt Turner matts...@gentoo.org wrote: On Fri, Nov 15, 2013 at 12:53 PM, Tom Wijsman tom...@gentoo.org wrote: On Fri, 15 Nov 2013 12:25:47 -0800 Matt Turner matts...@gentoo.org wrote: On Fri, Nov 15, 2013 at 12:00 PM, Tom Wijsman tom...@gentoo.org wrote: Imagine I had simply forgotten to unmask the abi_x86_32 USE flag for kbproto but was attempting to emerge unstable (or unmasked abi_x86_32) libXt. In fact, if I un-unmask kbproto (so that abi_x86_32 is masked), unmerge kbproto and attempt to emerge libXt: [...] emerge: there are no ebuilds built with USE flags to satisfy x11-proto/kbproto[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?]. !!! One of the following packages is required to complete your request: - x11-libs/libXt-1.1.4::gentoo (Change USE: -abi_x86_32) (dependency required by x11-libs/libXt-1.1.4 [ebuild]) (dependency required by libXt [argument]) It suggests that I turn off abi_x86_32 for libXt rather than telling me to turn the flag on for kbproto! Why should it literally suggest you to do something known to be broken? I don't know what you mean. kbproto[abi_x86_32] isn't known to be broken. You're asking a really weird question based on some implicit context that's not available to me. A mask implies something is broken (or experimental). Then to answer your previous question: it would suggest it [something broken, according to you] because you've asked for something broken that depends on it! Because a maintainer or achitecture team forgot to cover that case and didn't check on reverse dependencies, which is another case; but even in this case Portage handles well, as it suggests to step away from the brokenness. I'm claiming in this example that attempting to emerge libXt[abi_x86_32], portage should tell you that abi_x86_32 should be set for kbproto, rather than telling you to unset abi_x86_32 for libXt (which you're requesting to be emerged, damn it!). You have to be explicit when you want broken (or experimental) things; just emerging it isn't enough, taking a step further than that is. I'm explicitly saying that I want libXt with USE=abi_x86_32. Suggesting that I turn it off is kind of ridiculous, don't you think? In your case, yes. In general, no; if you suggest to do this to anyone instead of just the small few that want it, it would encourage people to override what we mark as broken and that is a recipe for disaster. This seems pretty clear cut. Are you just jerking me around now? For your case it could be made better, but as this very same output gets the eyes of people with other intentions; we can't just outright apply it that way and break systems, we have to satisfy most parties. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 22:57:06 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: I'm not sure if making broken (or experimental) things more easily available or a suggestion would be a good idea; people already have enough trouble as it is, adding more doesn't seem to be the right way. It's not about broken/experimental, it's about the logical consequences of an explicit action taken by the user. The user must get feedback based on what they said that they wanted to do, not based on what is experimental. Mentioning that something is experimental is an optional bonus, but assuming that the user already knows that this is the case is OK too. The * in the USE flag list marks this. portage should say, with as similar wording as possible: If you want to emerge libXt with those USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. Bonus points: Would you like me to set those USE flags for libYt and libZt for you? [Y/n] Which part of this warns the user that the user is about to run into something broken / experimental? We need to add that too, because it is not clear from the output that you suggest. And if we add that as well, it gets to be quite long; how would we condense that? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Tom Wijsman wrote: portage should say, with as similar wording as possible: If you want to emerge libXt with those USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. Bonus points: Would you like me to set those USE flags for libYt and libZt for you? [Y/n] Which part of this warns the user that the user is about to run into something broken / experimental? We need to add that too, because it is not clear from the output that you suggest. And if we add that as well, it gets to be quite long; It gets one word longer: If you want to emerge libXt with those experimental USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. how would we condense that? If something is a bit complicated then a bit more verbosity can be really good. //Peter pgpCEQB4bI4gC.pgp Description: PGP signature
Re: [gentoo-dev] How to obsolete this python-exec news fix the issue automatically for users
On Fri, 15 Nov 2013 22:06:45 + Robin H. Johnson robb...@gentoo.org wrote: On Wed, Nov 06, 2013 at 04:12:47PM +0100, Michał Górny wrote: Please review the following news item. I would prefer committing it as soon as I get an ACK from all the relevant parties since the issue is hitting users pretty hard. I don't know why nobody looked at a better automatic solution for the python-exec issue, but since it's still biting me on systems, and the manual solution is annoying, I found a working automatic solution. Had on mind to have some kind of if this then that rules in some pre-defined file like the profile updates; this would do specific emerge actions in specific situations (like this case). But as I saw it more as a hack, I didn't suggest it; it is better to keep the Portage tree consistent instead, than to add another file that grows the complexity further. Seems that you have cracked it. Add this line to the dev-lang/python-exec ebuilds: PDEPEND==dev-python/python-exec-1:$SLOT I wrote up the full research of it here: http://robbat2.livejournal.com/240335.html Was wondering why CC missed, but I see you have contacted mgorny on IRC. If there are no objections, I'd like to do this to the affected ebuilds in a few hours. It is an improvement and it has been tested on a few systems; I don't think this is something that would hurt or be irreversible, it reverses the condition and adds a SLOT to be easier on Portage. It should work. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] How to obsolete this python-exec news fix the issue automatically for users
On Fri, Nov 15, 2013 at 11:27:33PM +0100, Tom Wijsman wrote: If there are no objections, I'd like to do this to the affected ebuilds in a few hours. It is an improvement and it has been tested on a few systems; I don't think this is something that would hurt or be irreversible, it reverses the condition and adds a SLOT to be easier on Portage. It should work. Thanks. I committed with acks from mgorny, zerochaos patrick. -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot yng...@gentoo.org napisał(a): As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. If you say council should take more of a leadership role, then maybe this issue can be decided by council and a clear direction be taken by the distro as a whole? Then those who oppose the choice made can either put up or shut up, and we can all work at implementing the chosen solution. And what does, say, a Council decision change? Sure, Council can affect opinions of some developers and so on but this is something that needs real work, not talking and deciding. Sure, you can convince the developers that X is better than Y but you also need to find someone who will actually work on X. And I think the actual work done by *different* people shows which solution is most preferred by the community. This is not something that judges whether it's the best one, but probably it'll the most maintainable one. Think of bus factor. About your list, let's first note that emul-linux are not dead. We're working on getting a replacement but we aren't dumping them yet and we're actively encouraging developers to use any-of deps to support both multilib packages and emul-linux. As you probably have seen, emul-linux even had an update recently. On the other hand, let's be honest -- emul-linux are basically single-handedly maintained by Pacho. I can't talk for him but if you really want to keep that supported long-term, you need to find people who are going to work on them actively. I don't know the exact number of people actively working on multilib-portage but I haven't seen any progress on getting all the formal stuff done. And remember that this particular idea requires much more work since it assumes the spec becoming part of immutable EAPI -- getting it all right, extensive testing, considering all the corner cases, etc. One thing I can tell is that gx86-multilib is getting the widest support of all the solutions. It has most active developers, most active helping users and some support from random developers that just maintain their packages. It requires less work on the formal side, and gets better testing for the simple reason that you need to do it per-package. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 23:26:57 +0100 Peter Stuge pe...@stuge.se wrote: Tom Wijsman wrote: portage should say, with as similar wording as possible: If you want to emerge libXt with those USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. Bonus points: Would you like me to set those USE flags for libYt and libZt for you? [Y/n] Which part of this warns the user that the user is about to run into something broken / experimental? We need to add that too, because it is not clear from the output that you suggest. And if we add that as well, it gets to be quite long; It gets one word longer: If you want to emerge libXt with those experimental USE flags then you'll also have to set those same USE flags for libYt and libZt because libXt DEPENDs on them. By making it a single word its true meaning is hidden; broken or experimental are just two possible meanings, there are others (eg. security masks). I think we will want to be more explicit here. how would we condense that? If something is a bit complicated then a bit more verbosity can be really good. Extra words and verbosity's relationship depends on which extra words and what verbosity that one aims to achieve; so, it might be possible to condense this without making a change in verbosity, or even add verbosity by reaching more with less output (in processable list form): emerge: there are no ebuilds built with USE flags to satisfy x11-proto/kbproto[abi_x86_32]. (dependency required by x11-libs/libXt-1.1.4 [ebuild]) (dependency required by libXt [argument]) because of default/linux/amd64/13.0/package.use.stable.mask:1: # Ian Stakenvicius a...@gentoo.org (20 Sep 2013) # on behalf of gx86-multilib project multi...@gentoo.org # Mask abi_x86_32 on stable until emul-* packages are made # fully redundant and end-user experience in resolving # flag changes and blockages is generally smooth. # Please keep in sync with hardened/linux/amd64. x11-proto/kbproto abi_x86_32 Unmask at your own risk or set x11-libs/libXt[-abi_x86_32]. This is similar to the package.mask output. (Automatic config writing behavior would indeed be nice to have.) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Please consider removing use.stable.mask and package.use.stable.mask
On Fri, 15 Nov 2013 23:39:34 +0100 Michał Górny mgo...@gentoo.org wrote: Dnia 2013-11-15, o godz. 14:53:00 Ben de Groot yng...@gentoo.org napisał(a): As I see it now, with respect to multilib, we have three competing solutions, but not a clear direction which way we want to go as a distro: 1: emul-* packages 2: multilib-portage 3: multilib.eclass I would like to vote for option 1, as it is the least intrusive and does what we need. If it is really felt we need a more complete solution, then my vote would be for 2, since 3 is too intrusive and more likely to break or complicate stuff for normal users. If you say council should take more of a leadership role, then maybe this issue can be decided by council and a clear direction be taken by the distro as a whole? Then those who oppose the choice made can either put up or shut up, and we can all work at implementing the chosen solution. And what does, say, a Council decision change? Sure, Council can affect opinions of some developers and so on but this is something that needs real work, not talking and deciding. Sure, you can convince the developers that X is better than Y but you also need to find someone who will actually work on X. And I think the actual work done by *different* people shows which solution is most preferred by the community. This is not something that judges whether it's the best one, but probably it'll the most maintainable one. Think of bus factor. This is comparable to survival of the fittest; you can't just pick an animal and have it be a success in a circus, you'd need to careful to see which animal is fit for it and learn it all the tricks. Only then people will come, watch and come back later... (Cirque du Soleil thinks outside of the box and doesn't use animals) -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
