Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot yng...@gentoo.org wrote: If no, I can split off utils from poppler - with CMake it's effortless. We just rejoined the split poppler into one package again. So if you are going to split it up again, you will have some explaining to do to our users. I would like to prevent splitting, and see if we can fix maybe the cups ebuild instead. Or maybe the gtk+ maintainers want to split up their package... I understand they like that sort of thing. These kind of pot-shots at Mart and the GNOME team are not welcome. Please desist from making such unproductive statements. This is precisely how flames begin, and this thread already has too much heated argument going on. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot yng...@gentoo.org wrote: On 5 March 2010 21:51, Maciej Mrozowski reave...@gmail.com wrote: If no, I can split off utils from poppler - with CMake it's effortless. We just rejoined the split poppler into one package again. So if you are going to split it up again, you will have some explaining to do to our users. I would like to prevent splitting, and see if we can fix maybe the cups ebuild instead. There's nothing wrong with back-tracking on decisions if they seem to cause problems. For instance, the mozilla herd has done a lot of flip-flop on the system/internal sqlite issue, and we explained the reasons to our users[1] and they agreed that it was useful, and a good decision. If it turns out there is no easier way of properly fixing this, we may have to split poppler-utils out from poppler. In this regard, I like how people like Maciej are spending efforts to solve the problem in new ways (PDEPEND, etc) 1. http://is.gd/9O3k2 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
El vie, 05-03-2010 a las 22:06 +0100, Ben de Groot escribió: If no, I can split off utils from poppler - with CMake it's effortless. We just rejoined the split poppler into one package again. So if you are going to split it up again, you will have some explaining to do to our users. I would like to prevent splitting, and see if we can fix maybe the cups ebuild instead. Or maybe the gtk+ maintainers want to split up their package... I understand they like that sort of thing. Cheers, I think that it will be easy to explain users that we *need* to split poppler and poppler-utils to prevent circular dependencies. About splitting others... well, sometime ago I saw that cups is being split in Arch (having cups and libcups) when trying to investigate how to deal with avahi - gtk+ - cups - avahi circular dep problems (bug 222601), but I don't know if it could help with this case and how much work would it require :-/ Best regards signature.asc Description: Esta parte del mensaje está firmada digitalmente
[gentoo-dev] Looking for courier maintainers...
Do we have any Courier maintainers? courier-authlib is vulnerable to CVE-2009-3736 (internal copy of libltdl) [1] [1] http://bugs.gentoo.org/show_bug.cgi?id=254062 It seems a bit too important package to be masked, but that's what will happen if noone cares
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 6 March 2010 10:11, Nirbheek Chauhan nirbh...@gentoo.org wrote: On Sat, Mar 6, 2010 at 2:36 AM, Ben de Groot yng...@gentoo.org wrote: If no, I can split off utils from poppler - with CMake it's effortless. We just rejoined the split poppler into one package again. So if you are going to split it up again, you will have some explaining to do to our users. I would like to prevent splitting, and see if we can fix maybe the cups ebuild instead. Or maybe the gtk+ maintainers want to split up their package... I understand they like that sort of thing. These kind of pot-shots at Mart and the GNOME team are not welcome. Please desist from making such unproductive statements. This is precisely how flames begin, and this thread already has too much heated argument going on. I'm sorry, it's just rubbing me the wrong way that many people here assume that the best solution is to split poppler again, while not even looking at other possible solutions. But let's try to be more constructive instead. Would it be possible to make cups a PDEPEND in gtk+ or is it really needed at compile time? The same for cups: can we make poppler a PDEPEND? Maciej, did you get any further with looking into that? And how about splitting cups, as Pacho mentioned, so that gtk+ would only need the lib? Cheers, -- Ben de Groot Gentoo Linux developer (qt, media, lxde, desktop-misc) __
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/05/2010 08:06 AM, Ben de Groot wrote: On 5 March 2010 04:18, Graham Murraygra...@gmurray.org.uk wrote: 3. Include one or both of the packages in the stage tarball. None of the packages involved (gtk+, cups and poppler) is in any shape or form essential, so you will have a very hard time convincing people that this is the best solution. I tend to agree, but do consider this: 1. We wouldn't need to put all the packages in the dep list up to these packages in the tarball - you could just put one package in the tarball so that when emerge gets to this point it won't die. 2. You don't need to put that package in @system, so the first time the user cleans out their install it will be removed. For server users it will start out there but will eventually go away. It does increase the size of the tarball, which is of course undesirable. We might also need to modify the build scripts since I'm guessing those scripts look at @system to figure out what belongs in the tarball and these packages don't need to be there. I do agree that it isn't really an ideal solution, and probably not the first thing we should try... Rich
[gentoo-dev] Lastrite: x11-misc/glunarclock
# Samuli Suominen ssuomi...@gentoo.org (06 Mar 2010) # Doesn't compile wrt #287698 and is untested with libxklavier-4 # and libxklavier-5. Also deps on dummy gail package. # # Masked for removal in 60 days unless someone picks it up. # x11-misc/glunarclock
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Tuesday 02 March 2010, Sebastian Pipping wrote: On 03/02/10 20:28, Nathan Zachary wrote: This looks like overkill to me. One keyword should be enough, and for supplementary information Status Whiteboard could be used. I agree. Simply having the BUGDAY keyword should be sufficient, and more information can be provided elsewhere in the report. If more than one keyword is commonly considered overkill I would at least request the whiteboard for it: somewhere in the report involves more than zero searching for it. Some people use the whiteboard for their own marking of bugs (e.g. security, and myself). If you add more information in there, you might be breaking other people's marking / sorting algorithms. I'd say one keyword BUGDAY is enough. Any bug editor can set and remove it and the bug history will show who set and removed it when. Sorting any syntax is taken care of by Bugzilla that way. It seems to me problem you seem to try to solve (review of bugs) can also be tackled with tools displaying new bugs that have the keyword set and just removing the keyword. If bugs are repeatedly spammed with BUGDAY comments, talk to the spammers or leave a comment. Robert signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Looking for courier maintainers...
Am Samstag 06 März 2010 schrieb Samuli Suominen: Do we have any Courier maintainers? I sort-of maintained courier in the past, although due to the number of issues and the complexity, I hesitated to add myself as a maintainer. I'll take care of the security issue and try to get that handled with upstream. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:ha...@hboeck.de signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Marking bugs for bugday?
Well, I personally would prefer to have two keywords at least, one for candidates and another for confirmed bugs. Otherwise it will be a real trouble for us to sort things out. If adding more than one keywords breaks anything, then I can tell you now it is already broken. The only thing that could make me thing that one keyword is enough, is that an actual comment is added every time a keyword is being added or removed off a bug, to be able to keep track of these changes. On Sat, Mar 6, 2010 at 3:45 PM, Robert Buchholz r...@gentoo.org wrote: On Tuesday 02 March 2010, Sebastian Pipping wrote: On 03/02/10 20:28, Nathan Zachary wrote: This looks like overkill to me. One keyword should be enough, and for supplementary information Status Whiteboard could be used. I agree. Simply having the BUGDAY keyword should be sufficient, and more information can be provided elsewhere in the report. If more than one keyword is commonly considered overkill I would at least request the whiteboard for it: somewhere in the report involves more than zero searching for it. Some people use the whiteboard for their own marking of bugs (e.g. security, and myself). If you add more information in there, you might be breaking other people's marking / sorting algorithms. I'd say one keyword BUGDAY is enough. Any bug editor can set and remove it and the bug history will show who set and removed it when. Sorting any syntax is taken care of by Bugzilla that way. It seems to me problem you seem to try to solve (review of bugs) can also be tackled with tools displaying new bugs that have the keyword set and just removing the keyword. If bugs are repeatedly spammed with BUGDAY comments, talk to the spammers or leave a comment. Robert -- Ioannis Aslanidis http://www.deathwing00.org deathwing00[at]gentoo.org 0x47F370A0
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/06/2010 04:24 AM, Richard Freeman wrote: On 03/05/2010 08:06 AM, Ben de Groot wrote: On 5 March 2010 04:18, Graham Murraygra...@gmurray.org.uk wrote: 3. Include one or both of the packages in the stage tarball. None of the packages involved (gtk+, cups and poppler) is in any shape or form essential, so you will have a very hard time convincing people that this is the best solution. I tend to agree, but do consider this: 1. We wouldn't need to put all the packages in the dep list up to these packages in the tarball - you could just put one package in the tarball so that when emerge gets to this point it won't die. 2. You don't need to put that package in @system, so the first time the user cleans out their install it will be removed. For server users it will start out there but will eventually go away. It does increase the size of the tarball, which is of course undesirable. We might also need to modify the build scripts since I'm guessing those scripts look at @system to figure out what belongs in the tarball and these packages don't need to be there. I do agree that it isn't really an ideal solution, and probably not the first thing we should try... Another possible solution would be distribute binary packages to users via PORTAGE_BINHOST. The user can simply set something like PORTAGE_BINHOST=http://tinderbox.dev.gentoo.org/default-linux/x86; in /etc/make.conf. Since DEPEND is ignored for binary packages, and circular RDEPEND doesn't block installation, the circular dependencies won't necessarily be an problem. The emerge --pretend output shows that emerge will go ahead and install those packages despite the circular RDEPEND: These are the packages that would be merged, in order: Calculating dependencies... done! [binary N] net-print/cups-1.3.11-r2 USE=X acl avahi dbus gnutls java jpeg ldap pam perl php png ppds python samba slp ssl tiff -kerberos -static -xinetd -zeroconf LINGUAS=en -de -es -et -fr -he -id -it -ja -pl -sv -zh_TW [0] [binary N] x11-libs/gtk+-2.18.6 USE=cups jpeg test tiff xinerama (-aqua) -debug -doc -jpeg2k -vim-syntax [0] [binary N] dev-python/pygtk-2.16.0-r1 USE=doc examples test [0] [binary N] gnome-extra/libgsf-1.14.17 USE=bzip2 gtk python -doc -gnome -thumbnail [0] [binary N] app-text/poppler-0.12.4 USE=abiword cairo jpeg lcms png qt4 utils xpdf-headers -cjk -debug -doc -exceptions -jpeg2k [0] -- Thanks, Zac
[gentoo-dev] Lastrite: dev-lisp/cl-albert
+# Samuli Suominen ssuomi...@gentoo.org (06 Mar 2010) +# Masked for QA, treecleaners, security +# +# Internal copy of vuln. dev-libs/expat +# +# Masked for removal in 60 days +dev-lisp/cl-albert
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot yng...@gentoo.org wrote: Would it be possible to make cups a PDEPEND in gtk+ or is it really needed at compile time? cups is definitely needed at compile-time The same for cups: can we make poppler a PDEPEND? Maciej, did you get any further with looking into that? From what I can see in cups-1.3.11, pdftops is purely a runtime dependency. The configure flags enable code that doesn't need pdftops at compile-time. Infact, poppler[utils] is in pure RDEPEND to reflect that. So in total, I think it can be moved to PDEPEND. This change should be made to all ebuilds; not just the latest ~arch since people do install stable ;p -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Saturday 06 of March 2010 18:05:20 Nirbheek Chauhan wrote: On Sat, Mar 6, 2010 at 5:02 PM, Ben de Groot yng...@gentoo.org wrote: Would it be possible to make cups a PDEPEND in gtk+ or is it really needed at compile time? cups is definitely needed at compile-time The same for cups: can we make poppler a PDEPEND? Maciej, did you get any further with looking into that? From what I can see in cups-1.3.11, pdftops is purely a runtime dependency. The configure flags enable code that doesn't need pdftops at compile-time. Infact, poppler[utils] is in pure RDEPEND to reflect that. So in total, I think it can be moved to PDEPEND. Apart from PDEPEND, one change needed as well in cups ebuilds: --with-pdftops pdftops needs to be replaced with --with-pdftops=/usr/bin/pdftops as otherwise it will fail during configure phase (giving absolute path disables autodetection) cups can use either poppler or ghostscript as pdf-to-ps filter, so given the fact that ghostscript is already a dep of cups, maybe --with-pdftops=gs could be used instead to avoid poppler dependency completely, but that's up to cups maintainers to determine whether it's safe/desired. So it's all simple, all this fuzz was unnecessary. Btw, do we still have active printing herd? -- regards MM
[gentoo-dev] Re: [rfc] making autotools.eclass depends flexible
On 03/06/2010 02:11 AM, Petteri Räty wrote: What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the DEPENDs should be under. This approach doesn't allow the ebuild maintainer to forget adding the depends. That approach also disallows (or makes unduly difficult) making the dependency such that I need autotools on USE=kernel_SunOS or USE=kernel_freemint, but nowhere else or I need autotools when USE=foo and USE=bar, but not otherwise. -- Jonathan Callen signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Sex, 2010-03-05 at 19:03 +0100, Dawid Węgliński wrote: On Friday 05 March 2010 17:12:23 Roy Bamford wrote: That's not a new install as per the handbook. Neither are you a new user as you have a premade make.conf and world file and some experience with Gentoo. Put yourself in the place of a brand new Gentoo user doing his/her first install. It needs to just work out of the box, one way or another, without forums posts or calls for help in #gentoo about circular dependences. That's not just cups - thats all circular dependencies. Brand new gentoo user goes throu handbook - reads set up USE variables in make.conf and does it according to his/her needs following use.*.desc. If gentoo was new to me i *would* enter cups as i use printers often at work. +1 Most people trying Gentoo already had some history with other Linux distros. So, I'm sure they will recognize the cups USE flag when they see it. Most everyone I know also have a printer (some with a pile of dust on it) so I think most of people will enable that USE flag anyway. -- Angelo Arrifano AKA MiKNiX Gentoo Embedded/OMAP850 Developer Linwizard Developer http://www.gentoo.org/~miknix http://miknix.homelinux.com
Re: [gentoo-dev] Re: [rfc] making autotools.eclass depends flexible
On 03/06/2010 08:28 PM, Jonathan Callen wrote: On 03/06/2010 02:11 AM, Petteri Räty wrote: What we use in Java is JAVA_PKG_OPT_USE to declare what use flag the DEPENDs should be under. This approach doesn't allow the ebuild maintainer to forget adding the depends. That approach also disallows (or makes unduly difficult) making the dependency such that I need autotools on USE=kernel_SunOS or USE=kernel_freemint, but nowhere else or I need autotools when USE=foo and USE=bar, but not otherwise. You can provide both approaches if there ever is a need for things you said but in my opinion just declaring the use flag should be the preferred approach as it results in less code in the individual ebuilds. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Marking bugs for bugday?
On Saturday 06 March 2010 15:26:10 Ioannis Aslanidis wrote: Well, I personally would prefer to have two keywords at least, one for candidates and another for confirmed bugs. This sounds like the sort of thing Bugzilla's flags mechanism is for. http://www.bugzilla.org/docs/2.22/html/flags-overview.html
Re: [gentoo-dev] Re: Marking bugs for bugday?
Now that's what I wanted. Thanks! On Sat, Mar 6, 2010 at 8:09 PM, David Leverton levert...@googlemail.com wrote: On Saturday 06 March 2010 15:26:10 Ioannis Aslanidis wrote: Well, I personally would prefer to have two keywords at least, one for candidates and another for confirmed bugs. This sounds like the sort of thing Bugzilla's flags mechanism is for. http://www.bugzilla.org/docs/2.22/html/flags-overview.html -- Ioannis Aslanidis http://www.deathwing00.org deathwing00[at]gentoo.org 0x47F370A0
Re: [gentoo-dev] Re: RFC: News item for removal of 2008.0 and old hardened profiles
On Friday 05 March 2010 20:22:44 Duncan wrote: Ed W posted on Fri, 05 Mar 2010 23:33:43 + as excerpted: I think I have mostly upgraded my machines, but I completely agree - I sometimes let some old virtual machines sit unbooted for a year and then suddenly want to use them and bring them up to date and occasionally this can be a right old pain in the derrier... Surely, if you've let it go for a year, it's about as easy to reinstall from a new stage-3 as it is to try to update from where you are? tell that to my headless machines. shout at their butts. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: RFC: News item for removal of 2008.0 and old hardened profiles
On 03/07/2010 12:31 AM, Mike Frysinger wrote: On Friday 05 March 2010 20:22:44 Duncan wrote: Ed W posted on Fri, 05 Mar 2010 23:33:43 + as excerpted: I think I have mostly upgraded my machines, but I completely agree - I sometimes let some old virtual machines sit unbooted for a year and then suddenly want to use them and bring them up to date and occasionally this can be a right old pain in the derrier... Surely, if you've let it go for a year, it's about as easy to reinstall from a new stage-3 as it is to try to update from where you are? tell that to my headless machines. shout at their butts. -mike no real rush, we can postpone it, but 3 years sounds a bit too much imho how about news item this year's November, and removal on next January? approx - Samuli
[gentoo-dev] Lastrite: Some dev-libs/dv* pkgs
# Samuli Suominen ssuomi...@gentoo.org (07 Mar 2010) # These won't compile against =dev-libs/dvutil-1. # # Also, dvutil-1 is unslotted and won't compile with recent # toolchain. # # No updates available from upstream. # # Bugs 247054, 251605 and 251608. # # Masked for removal in 30 days. dev-libs/dvcgi dev-libs/dvenv dev-libs/dvmysql dev-libs/dvticket dev-libs/dvxml
Re: [gentoo-dev] Re: RFC: News item for removal of 2008.0 and old hardened profiles
On Saturday 06 March 2010 17:47:04 Samuli Suominen wrote: On 03/07/2010 12:31 AM, Mike Frysinger wrote: On Friday 05 March 2010 20:22:44 Duncan wrote: Ed W posted on Fri, 05 Mar 2010 23:33:43 + as excerpted: I think I have mostly upgraded my machines, but I completely agree - I sometimes let some old virtual machines sit unbooted for a year and then suddenly want to use them and bring them up to date and occasionally this can be a right old pain in the derrier... Surely, if you've let it go for a year, it's about as easy to reinstall from a new stage-3 as it is to try to update from where you are? tell that to my headless machines. shout at their butts. no real rush, we can postpone it, but 3 years sounds a bit too much imho how about news item this year's November, and removal on next January? approx i dont think news items are necessary when profiles already have a built in deprecation and documentation/notification system. removal in January means they've been in the tree for ... ? -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Changes to flag-o-matic's _filter-var
On Wednesday 24 February 2010 15:27:21 ChIIph wrote: Here are some minor changes I'd like to propose to flag-o-matic's _filter-var() to work properly with LDFLAGS. Without this, things like -Wl,-O1,--as-needed won't be affected by any kind of filter since there are no spaces to separate each flag. I don't know of any better way to do this, but here's a patch that works just fine. the func is used by other code where you dont want to screw with commas. plus, there are a few other ways to trick the system. my opinion is still: - bypassing the system is sometimes useful - use separate -Wl flags and things just work so thanks, but no thanks -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Proposed change to savedconfig.eclass
On Wednesday 24 February 2010 12:03:16 Jeroen Roovers wrote: If no one objects, I will look forward to committing the patch in a week or two. commit it already :p -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Marking bugs for bugday?
On 03/06/10 20:09, David Leverton wrote: This sounds like the sort of thing Bugzilla's flags mechanism is for. http://www.bugzilla.org/docs/2.22/html/flags-overview.html Good idea! What I wonder now is: - Will it work with our very instance of Bugzilla? - Can certain flag states be required when searching? - Can we get their current value out using ctype=rdf output All yes makes it work. Sebastian
Re: [gentoo-dev] Moving packages to dev-vcs
On 03/06/10 08:08, Petteri Räty wrote: After the move is done could you please come up with a list of all the things you needed to take into account and then work with me for example to get it included in devmanual. Good idea. I opened a bug for it so we don't forget about it. https://bugs.gentoo.org/show_bug.cgi?id=308151 Sebastian
Re: [gentoo-dev] Re: [RFC] Remove cups from default profile to solve circular deps
On Thursday 04 March 2010 19:32:10 Brian Harring wrote: On Thu, Mar 04, 2010 at 06:07:17PM -0600, Dale wrote: chrome://messenger/locale/messengercompose/composeMsgs.properties: On 03/04/10 12:53, Ben de Groot wrote: Exactly. The last time I owned a printer is over 5 years ago. So I don't think cups warrants to be in the standard desktop profile. Cheers, I print almost daily, but I'm not sure if printers are commonplace enough for cups to be a default. Some users may expect it though. As for the circular deps, it would seem more logical to fix the problem at the source, rather than to cover it up for one subset of users. I can't think of anyone that doesn't have a printer. All my friends and family that has a computer has a printer. Heck, I had a printer hooked up to my old Vic-20 for goodness sake. That was over 20 years ago. A sampling size of one is of course representive of the whole. The vast majority of gentoo deployments I deal in, cups is bloat- my personal laptop, sure, that's a different story. That's well under a tenth of my installs however. The point there is that one size doesn't fit all- we have inheritance in the profiles for a reason. Shift cups out of the base and into desktop specific profiles. That one shouldn't be a point of debate. indeed. printing support should absolutely be enabled by default in desktop profiles. i'm not sure it makes sense in other profiles. -mike signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: [gentoo-dev-announce] Lastrite: app-antivirus/f-prot
Fabian Groffen wrote: # Fabian Groffengrob...@gentoo.org (06 Mar 2010) # Masked for security issues and discontinued interest from upstream to # support non-Windows platforms. Bug #233928 # Pending removal on April 6, 2010 app-antivirus/f-prot I use f-prot once in a blue moon and have it installed. While I won't miss it, I went to the website out of curiosity. They *claim* to have released version 6, which is currently in the tree and is the same version for windoze. I did read where they are cutting off windoze 98, ME and such. I didn't see any mention of stopping Linux. Am I correct to assume that someone has direct contact with them and they said they are not fixing Linux issues? Dale :-) :-)
