Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | As far as progress on this issue, we're looking into adopting glep 37 | and creating a virtual/x11 ebuild to address this. I've just committed virtual/x11 to the tree. See https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any problems with it. It won't work properly with macos yet because they use a fake package, so they'll have to hang on to virtual/x11 in the profiles. I plan to remove the virtual/x11 definition from base/virtuals in a couple of days, because this should provide a full (and non-broken) replacement. To return to the original issue, this means the virtual/x11 remains the correct way to specify modular dependencies and =6.99 should not be used. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlpdFXVaO67S1rtsRAjhcAKDNT1Y+SeZvx6pXxHk5MC4Fr4nxhgCeNw1e HAXKaKYVrFbfipv0taBqLJ4= =RNhi -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Modular X porting: dependency changes
On Wednesday 07 December 2005 17:03, Donnie Berkholz wrote: Donnie Berkholz wrote: | As far as progress on this issue, we're looking into adopting glep 37 | and creating a virtual/x11 ebuild to address this. I've just committed virtual/x11 to the tree. See https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any problems with it. It won't work properly with macos yet because they use a fake package, so they'll have to hang on to virtual/x11 in the profiles. It should work if the listed package matches what the macos profiles have in package.provided... I plan to remove the virtual/x11 definition from base/virtuals in a couple of days, because this should provide a full (and non-broken) replacement. This can be easily tested in advance by adding the following: # cat /etc/portage/profile/virtuals virtual/x11 -* -- Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [GLEP] Manifest2 format
On Wednesday 07 December 2005 04:04, Marius Mauch wrote: As stated in the GLEP, gpg is outside the scope of this. As for the questions, per entry sigs would invert one of the main goals (size reduction). And so far I haven't seen any sufficient answer to questions I raised on -core and -portage-dev regarding the transaction/stacked/fragmented/whatever-you-want-to-call-it Manifest signing proposed by Robin, so I'm still quite against it. Per entry sigs make no sense in the current design. All ebuilds can touch all files, and so the complete manifest should be verified. This means that the whole manifest should be signed. Having said that, I would like to argue that this GLEP be implemented only together with gpg signing the manifest. Doing otherwise would require another change in the manifest format in a short time. If the manifest format has optional signing that would also be ok. Just align the requirements and make manifest2 and the gpg signing of it compatible. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp0ri8AWuBMk.pgp Description: PGP signature
Re: [gentoo-dev] [GLEP] Manifest2 format
On Wed, 7 Dec 2005 16:15:49 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: On Wednesday 07 December 2005 04:04, Marius Mauch wrote: As stated in the GLEP, gpg is outside the scope of this. As for the questions, per entry sigs would invert one of the main goals (size reduction). And so far I haven't seen any sufficient answer to questions I raised on -core and -portage-dev regarding the transaction/stacked/fragmented/whatever-you-want-to-call-it Manifest signing proposed by Robin, so I'm still quite against it. Per entry sigs make no sense in the current design. All ebuilds can touch all files, and so the complete manifest should be verified. This means that the whole manifest should be signed. Having said that, I would like to argue that this GLEP be implemented only together with gpg signing the manifest. Doing otherwise would require another change in the manifest format in a short time. If the manifest format has optional signing that would also be ok. Just align the requirements and make manifest2 and the gpg signing of it compatible. Signing is already implemented and independent of the Manifest format. It's just not yet mandatory due to the missing key policy. Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Modular X porting: dependency changes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jason Stubbs wrote: | On Wednesday 07 December 2005 17:03, Donnie Berkholz wrote: | |Donnie Berkholz wrote: || As far as progress on this issue, we're looking into adopting glep 37 || and creating a virtual/x11 ebuild to address this. | |I've just committed virtual/x11 to the tree. See |https://bugs.gentoo.org/show_bug.cgi?id=112896 if you run into any |problems with it. | |It won't work properly with macos yet because they use a fake package, |so they'll have to hang on to virtual/x11 in the profiles. | | | It should work if the listed package matches what the macos profiles have in | package.provided... Please do try adding the section and running repoman, then, from an x86 profile. |I plan to remove the virtual/x11 definition from base/virtuals in a |couple of days, because this should provide a full (and non-broken) |replacement. | | | This can be easily tested in advance by adding the following: | | # cat /etc/portage/profile/virtuals | virtual/x11 -* Well, I've already tested locally by just removing the line from base/virtuals. But yes, that does sound like a nice, non-overwritable way to do it. =) Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlyPtXVaO67S1rtsRAunBAJoD0hJmFdnrxGghdpusrvGqHXgAIACdESjv Kwx4QY+EOdteHzyXaxrfzYE= =xrrk -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm planning on porting every installed app on my system to modular X, starting in the next couple of days. This means I will be committing to many of your applications, libraries, etc. If you don't trust my ability to do this or otherwise don't want me touching your app, please email me off-list. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlzWiXVaO67S1rtsRAj8UAJ93vZGrhn/zM5TCMigzI8iH7KkPhgCgxeEF R65Nny/Zu3uTAZpb1FsdBEc= =A4gU -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Getting your apps ported to modular X
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. | | If you don't trust my ability to do this or otherwise don't want me | touching your app, please email me off-list. For your benefit, here's my world file. You can determine whether your app's in the list by replacing yours with it, then running 'emerge -ep world'. Thanks, Donnie -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDlzepXVaO67S1rtsRAg7LAJsGEHpWe8PKXVtWk+pg3l7lYLg6FgCfdM7H /LCgrs1Wnskju21pVwaXG3U= =36oE -END PGP SIGNATURE- app-text/docbook-sgml-dtd x11-libs/libSM app-forensics/chkrootkit app-shells/bash-completion app-office/dia x11-proto/xineramaproto x11-apps/xkbprint app-portage/portage-utils media-fonts/font-adobe-utopia-75dpi x11-apps/ico app-office/tpp x11-libs/Xaw3d media-fonts/font-misc-misc x11-proto/xf86miscproto app-misc/colordiff x11-apps/xeyes app-text/sgml-common app-admin/syslog-ng x11-libs/libdrm x11-libs/libXt dev-util/darcs x11-libs/libXv x11-misc/makedepend x11-libs/libXprintUtil media-fonts/font-bh-lucidatypewriter-75dpi x11-libs/libXi mail-filter/spamassassin app-portage/splat media-gfx/gimp-print app-admin/pydf dev-util/anjuta x11-apps/xfd x11-apps/xdm x11-apps/xconsole x11-apps/xrandr x11-proto/resourceproto games-fps/americas-army app-portage/porthole media-fonts/font-mutt-misc x11-libs/libXxf86dga x11-proto/fontcacheproto net-misc/curl media-video/ffmpeg x11-apps/xdriinfo app-misc/pax-utils app-text/ghostscript-afpl app-pda/gnupod app-text/rman sci-libs/acml dev-util/meld media-fonts/font-bitstream-type1 x11-proto/xf86bigfontproto x11-apps/xload net-print/foomatic-db-engine app-misc/beagle media-fonts/font-schumacher-misc sys-fs/udev media-libs/freeglut media-libs/mesa x11-apps/scripts app-text/docbook-sgml x11-misc/glx-utils dev-lang/f2c app-editors/mlview app-forensics/rkhunter x11-apps/luit x11-apps/rstart net-misc/logjam app-office/magicpoint app-crypt/seahorse media-plugins/gst-plugins-faad x11-apps/xprehashprinterlist media-video/mplayer app-doc/autobook media-sound/rhythmbox x11-apps/xrx app-text/docbook-xml-dtd x11-drivers/xf86-video-savage media-gfx/gthumb media-fonts/font-adobe-100dpi dev-python/gnome-python-extras media-video/kino app-admin/superadduser cross-sparc-unknown-linux-gnu/glibc media-fonts/font-bh-lucidatypewriter-100dpi app-text/docbook-xml-simple-dtd x11-misc/xrestop x11-apps/fslsfonts x11-misc/xcompmgr x11-apps/xstdcmap app-admin/gamin media-fonts/font-ibm-type1 app-portage/esearch x11-proto/dmxproto x11-apps/xsetpointer dev-util/subversion media-plugins/gst-plugins-ogg x11-apps/oclock dev-python/pygtk app-admin/sudo sci-chemistry/gamess media-sound/ogg2mp3 media-fonts/font-screen-cyrillic x11-apps/xvinfo sci-chemistry/mpqc media-sound/easytag x11-libs/libXxf86vm x11-apps/xhost net-analyzer/nessus dev-util/bazaar x11-apps/bitmap net-im/gaim dev-util/dialog net-misc/netkit-telnetd x11-misc/xkbdata x11-apps/xdpyinfo dev-util/gquilt x11-libs/libXTrap net-print/ink media-fonts/font-sun-misc www-client/mozilla-firefox x11-libs/pango net-print/foomatic-filters sci-chemistry/molmol x11-proto/xf86vidmodeproto app-editors/bluefish x11-misc/transset media-sound/alsa-utils x11-apps/xlsfonts x11-apps/xwud app-admin/gentoo-bugger media-libs/tiff media-plugins/xmms-xf86audio sys-kernel/linux-headers x11-apps/xphelloworld x11-libs/libXdamage sys-devel/crossdev x11-apps/rgb app-text/evince x11-apps/xmodmap net-analyzer/etherape net-www/apache x11-apps/xset app-office/planner x11-themes/xmms-themes media-sound/alsa-headers net-misc/tightvnc dev-util/screem x11-libs/libXfont media-fonts/font-sony-misc x11-libs/libXp x11-libs/libXext x11-libs/libXpm media-libs/libpng dev-lang/mono net-misc/drivel games-misc/typespeed x11-wm/fluxbox media-fonts/font-util x11-libs/libfontenc x11-libs/libXfixes app-cdr/gcombust x11-proto/fixesproto x11-proto/trapproto app-pda/gtkpod x11-proto/compositeproto x11-libs/libXvMC x11-libs/libXprintAppUtil app-cdr/gnomebaker net-irc/irssi x11-libs/libXmu x11-terms/clusterssh x11-apps/xclipboard sci-libs/mmdb media-sound/xmms x11-apps/xedit app-office/openoffice-bin x11-libs/libXres x11-proto/evieext app-misc/alexandria app-portage/epm gnome-base/control-center media-sound/mp3gain x11-libs/libXft app-portage/gentoolkit-dev media-fonts/font-bh-75dpi dev-util/gazpacho net-analyzer/nmap x11-proto/recordproto media-libs/freetype games-puzzle/mindless x11-apps/xbiff x11-themes/gentoo-xcursors media-fonts/encodings mail-client/mozilla-thunderbird x11-apps/xwd media-plugins/gst-plugins-lame x11-apps/xf86dga games-fps/ut2003-demo sys-apps/hal media-fonts/font-xfree86-type1 net-analyzer/dnstracer dev-util/pkgconfig app-text/xpdf net-dns/dnsmasq x11-apps/xprop x11-apps/xfontsel app-admin/webapp-config app-office/gnumeric media-plugins/gst-plugins-mad
Re: [gentoo-dev] Getting your apps ported to modular X
On Wed, 2005-12-07 at 11:27 -0800, Donnie Berkholz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Donnie Berkholz wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing to | many of your applications, libraries, etc. | | If you don't trust my ability to do this or otherwise don't want me | touching your app, please email me off-list. For your benefit, here's my world file. You can determine whether your app's in the list by replacing yours with it, then running 'emerge -ep world'. Nevermind that last email since you sent out your world. -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Getting your apps ported to modular X
On Wed, 07 Dec 2005 11:18:58 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | I'm planning on porting every installed app on my system to modular X, | starting in the next couple of days. This means I will be committing | to many of your applications, libraries, etc. So is there now a safe, correct way of specifying modular X dependencies that will actually work? -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] Getting your apps ported to modular X
Ciaran McCreesh wrote: So is there now a safe, correct way of specifying modular X dependencies that will actually work? It will work when I pull the virtual/x11 from base/virtuals this weekend. Until then, it will wrongly think xorg-x11-7 ebuilds provide the virtual. See my recent post on the other modular thread, Modular X porting: dependency changes. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] http://people.gentoo.org/
On Tuesday 06 of December 2005 23:28 Doug Goldstein wrote: Yeah so... I don't really know what your last name means... Only thing close that I see is female repoductive organ but of the 4 letter variation. I dunno... Lemme know... maybe even off list.. :-D Bingo, I see you already know all the important words ;-). (Just FYI, there's no four-letter variant of this word in Czech, but adding one letter to the part of someone's surname is an extremely easy operation :-) ) Cheers, -jkt -- cd /local/pub more beer /dev/mouth pgpxwxxWHAd0e.pgp Description: PGP signature
Re: [gentoo-dev] Getting your apps ported to modular X
Donnie Berkholz wrote: For your benefit, here's my world file. You can determine whether your app's in the list by replacing yours with it, then running 'emerge -ep world'. It was pointed out that I worded this poorly. Rather than replacing, you should back up your own file, copy mine in, then replace it with your backup when you finish. If you've already overwritten your world file without understanding what you were doing, try regenworld. Also, here's a generated list of things from my world file that depend on X, again not produced by me: app-admin/gkrellm-2.2.5 app-text/ghostscript-7.07.1-r8 gnome-base/gnome-libs-1.4.2 gnome-base/libglade-0.17-r6 gnome-base/libgtop-2.10.2 gnome-extra/zenity-2.10.1 media-gfx/xloadimage-4.1-r4 media-libs/giflib-4.1.4 media-libs/glut-3.7.1 media-libs/gst-plugins-0.8.10 media-libs/imlib-1.9.14-r3 media-libs/imlib2-1.2.0-r2 media-libs/libmpeg2-0.4.0b media-libs/libsdl-1.2.8-r1 media-libs/smpeg-0.4.4-r7 media-plugins/xmms-alsa-1.2.10-r2 media-plugins/xmms-crossfade-0.3.8 media-plugins/xmms-esd-1.2.10-r1 media-plugins/xmms-extra-0.1 media-plugins/xmms-fmradio-1.5 media-plugins/xmms-mad-0.8 media-plugins/xmms-mpg123-1.2.10-r1 media-plugins/xmms-oggre-0.3 media-plugins/xmms-status-plugin-1.0 media-plugins/xmms-vorbis-1.2.10-r1 media-sound/xmms-1.2.10-r15 net-misc/rdesktop-1.4.1 net-www/netscape-flash-7.0.61 www-client/links-2.1_pre18 x11-base/xorg-x11-6.8.2-r6 x11-libs/gtk+-1.2.10-r11 x11-libs/gtk+-2.6.10-r1 x11-libs/libwnck-2.10.3 x11-libs/libxklavier-2.0 x11-libs/pango-1.8.1-r1 x11-libs/startup-notification-0.8 x11-libs/vte-0.11.15 x11-misc/xscreensaver-4.22-r4 x11-plugins/gkrellmms-2.1.21 x11-terms/xterm-204 x11-wm/metacity-2.10.3 You can probably count on all of those getting dep changes. Other things may as well, if they link statically or are binary. Thanks, Donnie -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] December Council Meeting
this is your [belated] reminder of the December council meeting. future reminders will not be late anymore ... we've proven that we cant remember it so i've gone ahead and crontab-ed future reminders to go out on the first :) current agenda: none ?! -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Looking for a vile maintainer
Anyone (existing developers only please, I'm not recruiting) use vile? If so, congratulations. You just volunteered to maintain it, starting with bug #114178. You can join the Vim herd (which seems to own all the vi clones for some bizarre reason) or maintain it separately if you prefer. -- Ciaran McCreesh : Gentoo Developer (I can kill you with my brain) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] December Council Meeting
On Wed, 7 Dec 2005 23:49:59 + Mike Frysinger [EMAIL PROTECTED] wrote: this is your [belated] reminder of the December council meeting. future reminders will not be late anymore ... we've proven that we cant remember it so i've gone ahead and crontab-ed future reminders to go out on the first :) current agenda: decision on multi-hash for Manifest1 Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] Looking for a vile maintainer
LOL. Sorry, subject line gave me the chuckles. -m -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Looking for a vile maintainer
On 12/7/05, Ciaran McCreesh [EMAIL PROTECTED] wrote: Anyone (existing developers only please, I'm not recruiting) use vile? If so, congratulations. You just volunteered to maintain it, starting with bug #114178. You can join the Vim herd (which seems to own all the vi clones for some bizarre reason) or maintain it separately if you prefer. Vile maintainer, eh? You may have better luck on user ;-) -Mike -- Michael E. Crute Software Developer SoftGroup Development Corporation Linux takes junk and turns it into something useful. Windows takes something useful and turns it into junk. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] .53, .54 and beyond...
On Wednesday 07 December 2005 11:57, Marius Mauch wrote: On Wed, 7 Dec 2005 08:41:27 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: On Wednesday 07 December 2005 01:01, Marius Mauch wrote: On Tue, 6 Dec 2005 23:19:38 +0900 Jason Stubbs [EMAIL PROTECTED] wrote: If there's no solid opposition, Saturday I will put current trunk into ~arch as 2.1_beta20051210. Well, I've already stated several times that IMO using a 2.1 branch is wrong (use 2.2 instead), but if I'm overvoted, so it shall be. As Brian stated, 2.2 being a version higher than 2.1 will have all the same expectations placed on it. From what I can see, 1% of users know anything about 2.1 so 99% would be wondering why there was a jump from 2.0 to 2.2. Do you have anything against 2.1 other than fearing that people will expect more from it than it will turn out to be? It isn't about expectations. Ok, I misunderstood your previous posts on this topic then. I just think it's bad engineering to use the same version prefix for two rather different codebases. ... After all, wasn't engineering the reason why we're going to increase the minor? I don't understand where the conflict comes in between the two. Internally, the old 2.1 has been known as HEAD, trunk and now 2.1-experimental. Externally, it's been known as 2.1.0_alpha20050718. The set of new features available in 2.1.0_alpha20050718 are pretty much all available in current trunk as far as I know... You'll need to explain the issue in a little bit more detail. Really, the bottom line is that regardless of what the response was when you asked about portage keywording, if all the arch teams had confidence in what we thought 2.0.53 would have been stable a long time ago. On the surface the only benefit is extra testing (which has already payed off) but it also allows others to take an active hand in the quality of portage as well as strengthens the communication channels. Ok, but it still doesn't really have anything to do with arch teams, just general QA. True, but currently there's no general QA team for coordinating the stability of the tree in general. Instead, this has been left up to the individual arch teams (which is a little strange/disorganized) so Also I didn't mean to criticize you, just stating that this option exists. Isn't it your responsibility to? ;) I can't tell if you followed what I said in my last email so I'll reiterate. Trunk will go into ~arch on Saturday. 2.0.54 will go out (also in ~arch) two weeks after that with the two fixes and include the cache rewrite based on the opinion of a broad range of users (rather than just the noise makers). SHA1 will of course also go in based on how it is voted. Ehm, what's the point of having .54 in ~arch after trunk is in ~arch? You won't get much testing that way as ~arch users would already use trunk and stable users likely won't know about .54 ... (typical visibility problem) The visibility problem is exactly why I'm suggesting it be done that way. Neither ~arch users nor arch users get needless bumps and testing of trunk doesn't get held up at all. .54 would be .53 + selective patches from trunk hence all its parts will have had extensive testing. The whole would only need a minimal amount of testing by those marking it stable before doing so. -- Jason Stubbs -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] DepSet
Zac Medico wrote: 1) Save test_conditionals.py in your PYTHONPATH as portage/test/ebuild/test_conditionals.py 2) Run `trial portage.test.ebuild` and watch it fail. 3) Apply DepSet-AndRestriction.patch then watch the previous test succeed. 4) Run vdb-depset-test.py to try it on your whole vdb (ParseErrors can be expected due to invalid syntax). Actually, step 4 will not work without the attached patch that fixes a problem with the vdb multiplex repository. After the DepSet and multiplex repository work mentioned above, I spend some time experimenting with bin/tests/build_installed_state_graph.py and was able to get the state_graph working correctly for most of the packages in my vdb (neglecting ParseErrors which I fixed by editing vdb *DEPEND files directly). The first and last hunks of the attached patch fix a couple small breakages that are due to code changes elsewhere. The middle hunk fixes a problem with block atoms that do not match any packages. Previously, these atoms would not make it into the okay_atoms set which caused unresolved dependencies. One other problem worth noting is that some DepSet conditionals may be evaluated incorrectly due to USE flag handling in portage.vdb.repository where USE flags are filtered to only include the ones listed in IUSE. This causes the ARCH flag to be excluded (x86 in my case) and conseqent problems when the pkg.rdepends DepSet is evaluated. Zac Index: portage/graph/state_graph.py === --- portage/graph/state_graph.py (revision 2326) +++ portage/graph/state_graph.py (working copy) @@ -6,7 +6,7 @@ import sets from portage.package.atom import atom -from portage.restrictions.packages import OrRestriction +from portage.restrictions.boolean import OrRestriction class StateGraph(object): @@ -58,12 +58,19 @@ all_atoms.union_update(atomset) okay_atoms = sets.Set() for atom in all_atoms: +have_blocker=False for child in self.pkgs: if atom.key != child.key: continue - if atom.match(child) ^ atom.blocks: - okay_atoms.add(atom) + if atom.match(child): + if atom.blocks: + have_blocker=True + else: + okay_atoms.add(atom) break +if atom.blocks and not have_blocker: + # block atom that does not match any packages + okay_atoms.add(atom) for choice in self.pkgs[pkg][0]: if choice.issubset(okay_atoms): break @@ -187,10 +194,7 @@ ret = sets.Set() if isinstance(restrict, OrRestriction): - # XXX: OrRestrictions currently contain a single DepSet that contains - # the Or'd elements. This seems broken to me. - # -- jstubbs - for element in restrict[0]: + for element in restrict: if isinstance(element, atom): newset = sets.Set() newset.add(element)
