Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 3.3.2010 08:52, Ryan Hill napsal(a): On Wed, 03 Mar 2010 08:52:55 +0200 Petteri Räty betelge...@gentoo.org wrote: On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: Members of Gentoo Python Project have agreed to deprecate the following functions in EAPI =2: - python_version() - python_mod_exists() - python_tkinter_exists() - distutils_python_version() - distutils_python_tkinter() These functions are already banned in EAPI =3. 1. In this week, these functions will start printing deprecation warnings in older EAPIs. 2. On 2010-07-01, these functions will start calling die(). (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01, then addition of calls to die() will be delayed.) 3. On 2011-01-01, these functions will be removed. Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuOIikACgkQHB6c3gNBRYdIoQCfXZupVWgQByemjTLbSyN6qH+H L3IAn2yFop+l4dclIyzoCYdlGK0a/xSn =iutE -END PGP SIGNATURE-
[gentoo-dev] Lastrite: dev-lang/squeak
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. libraries # GLSA 200606-11, GLSA 200807-03 and likely more # # http://bugs.gentoo.org/show_bug.cgi?id=247363 # # Removed in 60 days dev-lang/squeak
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
[gentoo-dev] Lastrite: libnetdude, netdude and naim
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copy of vuln. libltdl, CVE-2009-3736 # # Bugs 252402, 296953, 296954, 215252, 297649 # # Masked for removal in 60 days net-libs/libnetdude net-analyzer/netdude net-im/naim
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. Yes, eclasses go along the same lines as shared libraries, which is probably what Tomáš meant any way. Regards, Petteri
[gentoo-dev] Lastrite: net-nntp/bnr2
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. libpng, zlib # # Masked for removal in 60 days net-nntp/bnr2
[gentoo-dev] Lastrite: games-fps/openarena
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena
Re: [gentoo-dev] Lastrite: games-fps/openarena
On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 signature.asc Description: PGP signature
[gentoo-dev] Lastrite: app-shells/pdsh
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # After over an year of no word from maintainers # # Internal copy of vuln. libltdl, CVE-2009-3736 # # Masked for removal in 60 days app-shells/pdsh
[gentoo-dev] Lastrite: net-irc/ircd-hybrid
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # After more than a year of no word from maintainers # # Internal copy of vulnerable libpcre, bug 258330 # Remote command execution, CVE-2009-4016, bug 303735 # Build issues, bug 212255 # # Masked for removal in 60 days. net-irc/ircd-hybrid
Re: [gentoo-dev] Lastrite: games-fps/openarena
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dne 3.3.2010 12:32, Joshua Saddler napsal(a): On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 Bug opened for 1 year. Diego commented on 30 July 2009. No other response from maintainers... If there is patch it is maintainers job to apply them. At least was when I last looked. We of course can patch the bundled versions and wait for next breakage, but it is simpler to treeclean it and let people reintroduce it later without bundled libs... Tom -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuOTjcACgkQHB6c3gNBRYc3FwCginYSFYiW0zOEKP9ehqUsweba 3BoAnRNtdY4YqNyX3C766xEXgPosBffY =v05+ -END PGP SIGNATURE-
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Wed, 03 Mar 2010 13:09:49 +0200 Petteri Räty betelge...@gentoo.org wrote: On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. Yes, eclasses go along the same lines as shared libraries, which is probably what Tomáš meant any way. Is this actually documented anywhere? Or is this another of our this-is-policy-because-everyone-knows-it's-policy policies? I know there was a technical issue with removing pkg_*_rm functions way-back-when, but if there's no technical reason why functions can't be deprecated, and we're just clinging to policy in the name of policy, then I can't say I see the point. And if this is such a bad idea, then can we get it in writing? -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 03 Mar 2010 09:47:37 +0100 Tomáš Chvátal scarab...@gentoo.org wrote: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. since when? Since ever. If you change eclass abi you need to rename it. No, that's not been the case 'since ever' at all. It used to be that if you changed or removed a function, you just had to make sure you didn't break anything. This was made more complicated by the way that eclasses in the tree were used for removing installed packages too, which is no longer an issue. - -- Ciaran McCreesh -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEARECAAYFAkuOWnAACgkQ96zL6DUtXhHcgACgj8hDz+sIgvCbqXeotvUqHyYr v2wAoJzESPARQnPDaWhrbFNiK0zHp2G2 =RzSg -END PGP SIGNATURE-
[gentoo-dev] Re: Lastrite: games-fps/openarena
Dne 3.3.2010 12:32, Joshua Saddler napsal(a): On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 One of the reasons I left the treecleaner project was that it became apparent that people were more interested in dumping packages with simple problems than fixing them (which believe it or not, was what treecleaner was formed to do). Now they call it QA. :) I'm all for dropping broken crap, but things people use with working patches attached? QA is also about getting that stuff applied. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Lastrite: games-fps/openarena
On 03/03/2010 02:58 PM, Ryan Hill wrote: Dne 3.3.2010 12:32, Joshua Saddler napsal(a): On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 One of the reasons I left the treecleaner project was that it became apparent that people were more interested in dumping packages with simple problems than fixing them (which believe it or not, was what treecleaner was formed to do). Now they call it QA. :) I'm all for dropping broken crap, but things people use with working patches attached? QA is also about getting that stuff applied. And now you have good 60 days to apply and test the package, and co-ordinate it with upstream. Don't forget to add yourself to metadata.xml, as it's a non-trivial task. ;-)
Re: [gentoo-dev] Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
Petteri Räty wrote: On 03/02/2010 08:27 PM, Arfrever Frehtes Taifersar Arahesis wrote: Members of Gentoo Python Project have agreed to deprecate the following functions in EAPI =2: - python_version() - python_mod_exists() - python_tkinter_exists() - distutils_python_version() - distutils_python_tkinter() These functions are already banned in EAPI =3. 1. In this week, these functions will start printing deprecation warnings in older EAPIs. 2. On 2010-07-01, these functions will start calling die(). (If any ebuilds in gentoo-x86 still call any of these functions on 2010-07-01, then addition of calls to die() will be delayed.) 3. On 2011-01-01, these functions will be removed. Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. That is a bogus policy - never heard of it myself, either. I don't always agree with Arfrever's methods but he has thought this one out and has a decent migration plan, imo. Sounds good to me. -Jeremy Regards, Petteri
[gentoo-dev] Lastrite: gnu-smalltalk
# Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copy of vuln. libltdl, CVE-2009-3736 # # http://bugs.gentoo.org/show_bug.cgi?id=277089 # # Masked for removal in 60 days dev-lang/gnu-smalltalk
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 02:47 PM, Ciaran McCreesh wrote: On Wed, 03 Mar 2010 09:47:37 +0100 Tomáa Chvátal scarab...@gentoo.org wrote: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. since when? Since ever. If you change eclass abi you need to rename it. No, that's not been the case 'since ever' at all. It used to be that if you changed or removed a function, you just had to make sure you didn't break anything. This was made more complicated by the way that eclasses in the tree were used for removing installed packages too, which is no longer an issue. You can't fix all possible overlays so you can only start removing functions that are used for installations if we decide we don't care about overlays. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 02:40 PM, Ryan Hill wrote: On Wed, 03 Mar 2010 13:09:49 +0200 Petteri Räty betelge...@gentoo.org wrote: On 3.3.2010 11.23, Nirbheek Chauhan wrote: 2010/3/3 Tomáš Chvátal scarab...@gentoo.org: Removing eclass functions like this is not allowed by current policy. If you want to do it, you should discuss about changing policy. ?! since when? Since ever. If you change eclass abi you need to rename it. I think you can *add* functions and variables to eclasses, you can change *how* a function works internally, you can *fix* problems with functions (which would technically result in a change in API). I don't think it has ever been as strict as, say, the kernel ABI interface. Yes, eclasses go along the same lines as shared libraries, which is probably what Tomáš meant any way. Is this actually documented anywhere? Or is this another of our this-is-policy-because-everyone-knows-it's-policy policies? I know there was a technical issue with removing pkg_*_rm functions way-back-when, but if there's no technical reason why functions can't be deprecated, and we're just clinging to policy in the name of policy, then I can't say I see the point. Big eclass changes should go through gentoo-dev so someone here will point it out at least. Devmanual should document it so I challenge anyone to submit a patch: http://devmanual.gentoo.org/eclass-writing/index.html git+ssh://git.gentoo.org/var/gitroot/devmanual.git Also policies should be changed when they don't make sense any more as I said in my first response but I am not sure if that's the case here. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: Lastrite: games-fps/openarena
I've remove the mask for games-fps/openarena. The mask was done without consulting the games team. On Wed, Mar 3, 2010 at 8:09 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 03/03/2010 02:58 PM, Ryan Hill wrote: Dne 3.3.2010 12:32, Joshua Saddler napsal(a): On Wed, 03 Mar 2010 13:35:10 +0200 Samuli Suominen ssuomi...@gentoo.org wrote: # Samuli Suominen ssuomi...@gentoo.org (03 Mar 2010) # Masked for QA, security # # Internal copies of vuln. zlib, jpeg, speex and likely # others # # http://bugs.gentoo.org/show_bug.cgi?id=255453 # # Masked for removal in 60 days. games-fps/openarena Why? Why did you ignore the patches posted to the bug? Even Diego, the original reporter, commented that the patches fix the problems.[1] [1] http://bugs.gentoo.org/show_bug.cgi?id=255453#c4 One of the reasons I left the treecleaner project was that it became apparent that people were more interested in dumping packages with simple problems than fixing them (which believe it or not, was what treecleaner was formed to do). Now they call it QA. :) I'm all for dropping broken crap, but things people use with working patches attached? QA is also about getting that stuff applied. And now you have good 60 days to apply and test the package, and co-ordinate it with upstream. Don't forget to add yourself to metadata.xml, as it's a non-trivial task. ;-)
Re: [gentoo-dev] Re: Lastrite: games-fps/openarena
Michael Sterrett mr_bon...@gentoo.org said: I've remove the mask for games-fps/openarena. The mask was done without consulting the games team. This is no reason to remove the mask. The games team had more than enough time to fix the package. I'll be adding the mask back as the package is vulnerable via multiple bundled libs and therefore shouldn't be in the tree. You can apply the patches if you want to keep it and remove the mask at that time. Thanks, -- Mark Loeser email - halcy0n AT gentoo DOT org email - mark AT halcy0n DOT com web - http://www.halcy0n.com signature.asc Description: Digital signature
Re: [gentoo-dev] Re: Lastrite: games-fps/openarena
On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote: Michael Sterrett mr_bon...@gentoo.org said: I've remove the mask for games-fps/openarena. The mask was done without consulting the games team. This is no reason to remove the mask. The games team had more than enough time to fix the package. I'll be adding the mask back as the package is vulnerable via multiple bundled libs and therefore shouldn't be in the tree. You can apply the patches if you want to keep it and remove the mask at that time. Thanks, This thread is yet another proof that we need to introduce a Upcoming masking for unmaintained packages. Instead of first masking a package and then announce it, we can simply announce that we are gonna mask the package in 10days if there is no activity on the respective bug -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On E, 2010-03-01 at 13:40 -0800, Zac Medico wrote: On 03/01/2010 01:24 PM, Ben de Groot wrote: For some reason beyond my understanding, we have the cups useflag enabled by default in profiles. This has started to generate circular dependencies, at least for desktop profile users (gtk - cups - poppler - gtk). I propose we no longer enable the cups useflag. If you don't want to disable the cups flag globally, you might choose to disable for gtk+ by default in profiles/base/package.use like this: x11-libs/gtk+ -cups That can be overridden by user's USE=cups setting in make.conf, so the only effect would be to break the circular dependency by default. I don't think there was any such problem until poppler maintainers decided to unsplit poppler into one big packages with USE flags again instead of the nice split poppler, poppler-glib (that should have been named poppler-cairo probably instead), poppler-qt3, poppler-qt4 and poppler-utils. I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. -- Mart Raudsepp Gentoo Developer Mail: l...@gentoo.org Weblog: http://blogs.gentoo.org/leio signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Thu, Mar 4, 2010 at 12:15 AM, Mart Raudsepp l...@gentoo.org wrote: I don't think there was any such problem until poppler maintainers decided to unsplit poppler into one big packages with USE flags again instead of the nice split poppler, poppler-glib (that should have been named poppler-cairo probably instead), poppler-qt3, poppler-qt4 and poppler-utils. Also of note is that we've made efforts to split packages to avoid circular dependencies[1]. So it's really silly to add circular deps by un-splitting packages. 1. http://bugs.gentoo.org/show_bug.cgi?id=269747#c11 -- ~Nirbheek Chauhan Gentoo GNOME+Mozilla Team
Re: [gentoo-dev] Re: Lastrite: games-fps/openarena
On Wed, Mar 3, 2010 at 8:59 AM, Markos Chandras hwoar...@gentoo.org wrote: On Wednesday 03 March 2010 18:29:13 Mark Loeser wrote: Michael Sterrett mr_bon...@gentoo.org said: I've remove the mask for games-fps/openarena. The mask was done without consulting the games team. This is no reason to remove the mask. The games team had more than enough time to fix the package. I'll be adding the mask back as the package is vulnerable via multiple bundled libs and therefore shouldn't be in the tree. You can apply the patches if you want to keep it and remove the mask at that time. Thanks, This thread is yet another proof that we need to introduce a Upcoming masking for unmaintained packages. sarcasm Shall I file those forms in triplicate and fax them to the main office sir? /sarcasm Since amazingly I actually started the Treecleaners project; the intent was actually to fix problems with packages. Part of the problem is that there are hundreds of packages in the tree and the fixes vary in complexity so it is difficult to create hard-and-fast rules on when to keep a package versus when to toss it. One of the things I like about masking is that it quickly gets people who actually care about the package up to bat to fix it instead of leaving it broken for months. I realize maintainers do not exactly enjoy this kind of poking, however when things have been left for long enough I believe our options become a bit more limited (in this case, masking for removal due to unfixed sec bugs.) Instead of first masking a package and then announce it, we can simply announce that we are gonna mask the package in 10days if there is no activity on the respective bug -- Markos Chandras (hwoarang) Gentoo Linux Developer Web: http://hwoarang.silverarrow.org
[gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Wed, 03 Mar 2010 17:55:41 +0200 Petteri Räty betelge...@gentoo.org wrote: On 03/03/2010 02:40 PM, Ryan Hill wrote: Is this actually documented anywhere? Or is this another of our this-is-policy-because-everyone-knows-it's-policy policies? I know there was a technical issue with removing pkg_*_rm functions way-back-when, but if there's no technical reason why functions can't be deprecated, and we're just clinging to policy in the name of policy, then I can't say I see the point. Big eclass changes should go through gentoo-dev so someone here will point it out at least. Devmanual should document it so I challenge anyone to submit a patch: http://devmanual.gentoo.org/eclass-writing/index.html git+ssh://git.gentoo.org/var/gitroot/devmanual.git Also policies should be changed when they don't make sense any more as I said in my first response but I am not sure if that's the case here. The problem is I don't think this is actually a policy. One of the first projects I did as a developer, while still under probation, was a complete rewrite, in-place, of an eclass. Many functions were removed or renamed (done in an overlay of course, with a migration path). It was fully reviewed, on list, by senior devs at the time. I was told by several people that if there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be touched because of portage limitations (those limitations were removed ~3 years ago now IIRC). So I wonder if this isn't just a years-long game of Telephone where one rule passed down by word of mouth got over-generalized and sufficiently twisted as to apply to everything. Nor do I think it's a particularly useful policy that keeps deprecated interfaces around forever. Careful removal with a long warning period shouldn't actually pose a problem. I think Arfrever's plan is reasonable. -- fonts,by design, by neglect gcc-porting, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. 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 3 March 2010 19:54, Nirbheek Chauhan nirbh...@gentoo.org wrote: Also of note is that we've made efforts to split packages to avoid circular dependencies[1]. So it's really silly to add circular deps by un-splitting packages. I think it's silly to split packages for no good reason. And doing it to avoid circular deps is only a good reason in extreme cases where they can't be worked around in any other way. Standard Gentoo practice is one ebuild per upstream package and useflags to toggle optional functionality. I don't see any reason to deviate from that practice in the case of poppler. 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/03/10 15:51, Ben de Groot wrote: On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, I agree that CUPS is not really necessary in the desktop profile, and especially in the base profile. Many systems run desktop environments without needing printing support. As we advance further toward a paperless computing experience, the need for printing support becomes even less. And, as it is incredibly simple to add print capabilities by placing the cups USE flag in /etc/make.conf, that choice should be left to the user. Regards, Nathan Zachary
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
chrome://messenger/locale/messengercompose/composeMsgs.properties: On 03/03/10 15:51, Ben de Groot wrote: On 3 March 2010 19:45, Mart Raudseppl...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, I agree that CUPS is not really necessary in the desktop profile, and especially in the base profile. Many systems run desktop environments without needing printing support. As we advance further toward a paperless computing experience, the need for printing support becomes even less. And, as it is incredibly simple to add print capabilities by placing the cups USE flag in /etc/make.conf, that choice should be left to the user. Regards, Nathan Zachary One could argue the opposite as well. Adding -cups to make.conf is just as easy. I'm one of those lowly users. Dale :-) :-)
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, I agree that CUPS is not really necessary in the desktop profile, and especially in the base profile. Many systems run desktop environments without needing printing support. As we advance further toward a paperless computing experience, the need for printing support becomes even less. And, as it is incredibly simple to add print capabilities by placing the cups USE flag in /etc/make.conf, that choice should be left to the user. Regards, Nathan Zachary One could argue the opposite as well. Adding -cups to make.conf is just as easy. I'm one of those lowly users. Dale :-) :-) I think that the point is that it is better to have it disabled by default so that new users do not run into these circular dependencies upon their first installation. They can then add cups to their make.conf and emerge -avuDN world to get full printing support. Just as a sidebar, there is not a lowly user. Your input is greatly important in all matters regarding Gentoo as you are a member of the userbase. It's your operating system too! :) Regards, Nathan Zachary
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
chrome://messenger/locale/messengercompose/composeMsgs.properties: I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, I agree that CUPS is not really necessary in the desktop profile, and especially in the base profile. Many systems run desktop environments without needing printing support. As we advance further toward a paperless computing experience, the need for printing support becomes even less. And, as it is incredibly simple to add print capabilities by placing the cups USE flag in /etc/make.conf, that choice should be left to the user. Regards, Nathan Zachary One could argue the opposite as well. Adding -cups to make.conf is just as easy. I'm one of those lowly users. Dale :-) :-) I think that the point is that it is better to have it disabled by default so that new users do not run into these circular dependencies upon their first installation. They can then add cups to their make.conf and emerge -avuDN world to get full printing support. Just as a sidebar, there is not a lowly user. Your input is greatly important in all matters regarding Gentoo as you are a member of the userbase. It's your operating system too! :) Regards, Nathan Zachary Let just think of it this way. I have to reinstall say from a dead hard drive. I have copies of my make.conf and world file. I install my new drive, download the tarball and unpack it. I copy over make.conf and world. Naturally cups will be enabled. Then I sync and start to update. Isn't that circular dependency still going to be there? After all, this is how I install Gentoo even if from scratch. I set my USE line before I start to emerge or update. It seems to me, in my situation, this would not solve much. Maybe I am incorrect in that. Dale :-) :-)
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
chrome://messenger/locale/messengercompose/composeMsgs.properties: On 03/03/10 20:17, Dale wrote: chrome://messenger/locale/messengercompose/composeMsgs.properties: I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, I agree that CUPS is not really necessary in the desktop profile, and especially in the base profile. Many systems run desktop environments without needing printing support. As we advance further toward a paperless computing experience, the need for printing support becomes even less. And, as it is incredibly simple to add print capabilities by placing the cups USE flag in /etc/make.conf, that choice should be left to the user. Regards, Nathan Zachary One could argue the opposite as well. Adding -cups to make.conf is just as easy. I'm one of those lowly users. Dale :-) :-) I think that the point is that it is better to have it disabled by default so that new users do not run into these circular dependencies upon their first installation. They can then add cups to their make.conf and emerge -avuDN world to get full printing support. Just as a sidebar, there is not a lowly user. Your input is greatly important in all matters regarding Gentoo as you are a member of the userbase. It's your operating system too! :) Regards, Nathan Zachary Let just think of it this way. I have to reinstall say from a dead hard drive. I have copies of my make.conf and world file. I install my new drive, download the tarball and unpack it. I copy over make.conf and world. Naturally cups will be enabled. Then I sync and start to update. Isn't that circular dependency still going to be there? After all, this is how I install Gentoo even if from scratch. I set my USE line before I start to emerge or update. It seems to me, in my situation, this would not solve much. Maybe I am incorrect in that. Dale :-) :-) I believe the circular dependency is solved if one emerges gtk+ (and possibly poppler?) without CUPS support, and then goes back and emerges everything with CUPS. Regards, Nathan Zachary So in the situation above, removing cups doesn't help any? The user would still have to work around the dependency problem. Is there not a better way to handle this? Dale :-) :-)
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 03/03/2010 09:41 PM, Dale wrote: So in the situation above, removing cups doesn't help any? The user would still have to work around the dependency problem. Is there not a better way to handle this? Agreed that there should be better ways of handling things. However, at the very least if somebody follows the instructions in the Gentoo Handbook to the letter, they shouldn't end up staring at an error message. A completely scripted install using any non-experimental profile should just work. So, removing the use flag should probably be done at least in the interim. That said, I do agree that we need to try to avoid this circular dependency in the first place. It is kind of silly that you can't even do an emerge -u world right out of a stage3 using a fairly common set of use flags and get a working system.
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
chrome://messenger/locale/messengercompose/composeMsgs.properties: On 03/03/2010 09:41 PM, Dale wrote: So in the situation above, removing cups doesn't help any? The user would still have to work around the dependency problem. Is there not a better way to handle this? Agreed that there should be better ways of handling things. However, at the very least if somebody follows the instructions in the Gentoo Handbook to the letter, they shouldn't end up staring at an error message. A completely scripted install using any non-experimental profile should just work. So, removing the use flag should probably be done at least in the interim. That said, I do agree that we need to try to avoid this circular dependency in the first place. It is kind of silly that you can't even do an emerge -u world right out of a stage3 using a fairly common set of use flags and get a working system. I only raised the point in case someone could come up with a better long term solution. It may be that this is the only way right now. However, it may be that someone will consider this that actually sits and writes the code for portage or decides how dependencies are calculated. Maybe a better way will present itself in the future. A good solution for most of the blocks was found so this will be dealt with at some point with a long term plan. Now watch some geek find a really simple solution next week. ;-) Dale :-) :-)
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Wednesday 03 March 2010 22:51:10 Ben de Groot wrote: On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. I'm not talking about selectively disabling cups. My proposal is to no longer enable the cups useflag in the base profile. I don't think cups should be part of the base profile, and as a result cascading to the desktop profile. And a lot of people seem to agree. Users can always enable that functionality when they need it. It is not something that is necessary for running a desktop system. Cheers, How is that going to fix circular dependency problem? What will you do if every user add cups to USE in make.conf? Say we don't support cups turned on by default? I hope no. Removing this flag from profile will not fix any problem but hide it. -- Cheers Dawid Węgliński
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. It is not something that is necessary for running a desktop system. Your logic is very thin here. By that same line of reasoning, neither are the gtk or qt flags, since you don't need 'em if you're building, say, a *box desktop. Printing is something I'd argue is part of a desktop environment. It's very much a graphical activity, and that's what a desktop is. We've had the Printing Guide in our Desktop Documentation Resources section for years for that very reason. http://www.gentoo.org/doc/en/?catid=desktop signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/03/2010 11:39 PM, Ryan Hill wrote: Also policies should be changed when they don't make sense any more as I said in my first response but I am not sure if that's the case here. The problem is I don't think this is actually a policy. One of the first projects I did as a developer, while still under probation, was a complete rewrite, in-place, of an eclass. Many functions were removed or renamed (done in an overlay of course, with a migration path). It was fully reviewed, on list, by senior devs at the time. I was told by several people that if there were any exported pkg_post_rm or pkg_pre_rm functions, they couldn't be touched because of portage limitations (those limitations were removed ~3 years ago now IIRC). So I wonder if this isn't just a years-long game of Telephone where one rule passed down by word of mouth got over-generalized and sufficiently twisted as to apply to everything. You can mostly get away with deprecating eclass functions in a slowly manner. Nor do I think it's a particularly useful policy that keeps deprecated interfaces around forever. Careful removal with a long warning period shouldn't actually pose a problem. I think Arfrever's plan is reasonable. If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Remove cups from default profile to solve circular deps
On Wed, Mar 03, 2010 at 11:08:07PM -0800, Joshua Saddler wrote: On 3 March 2010 19:45, Mart Raudsepp l...@gentoo.org wrote: I don't believe we should selectively cripple one GUI toolkit with not having proper printing support out of the box on a desktop profile, while others do, just because maintainers are lazy. It is not something that is necessary for running a desktop system. Your logic is very thin here. By that same line of reasoning, neither are the gtk or qt flags, since you don't need 'em if you're building, say, a *box desktop. Printing is something I'd argue is part of a desktop environment. It's very much a graphical activity, and that's what a desktop is. We've had the Printing Guide in our Desktop Documentation Resources section for years for that very reason. http://www.gentoo.org/doc/en/?catid=desktop Isn't the split of the desktop profile, into KDE and gnome profiles, whilst leaving a base Desktop profile, exactly meant for the purpose that if you're not building KDE/Gnome, then you don't need to set the qt flags, unless some application needs it, or you find that you'd prefer to have them set system-wide? -- Zeerak Waseem pgpEJ2836hG1f.pgp Description: PGP signature
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On Thu, 04 Mar 2010, Petteri Räty wrote: If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html I think removal of functions is a special case of Adding and Updating Eclasses and we already have a policy for this. Ulrich
Re: [gentoo-dev] Re: Deprecation of python_version(), python_mod_exists(), python_tkinter_exists(), distutils_python_version() and distutils_python_tkinter() in EAPI =2
On 03/04/2010 09:39 AM, Ulrich Mueller wrote: On Thu, 04 Mar 2010, Petteri Räty wrote: If we decide allowing removal of functions, we should come up with a common procedure like the eclass removal policy: http://devmanual.gentoo.org/eclass-writing/index.html I think removal of functions is a special case of Adding and Updating Eclasses and we already have a policy for this. Ulrich Removing functions needs a migration plan. For example how long to have a warning there, how long before it can be removed etc. I don't see how you can get those from the common policy? Regards, Petteri signature.asc Description: OpenPGP digital signature
