Re: [gentoo-dev] Cleaning tree of outdated packages
On 14 December 2012 06:21, Chí-Thanh Christopher Nguyễn chith...@gentoo.org wrote: William Hubbs schrieb: For example, glibc-2.9 and gcc-2.95. I think that if we are going to keep things this old in the tree we need a good reason for them. iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems) play best together. I'm not sure how strong this argument is because we don't have any 2.4 kernels in the tree, and I am wondering why we still have a linux-headers-2.4. Those systems will likely be unable to use any vanilla kernel either, but use specially patched kernels from the hardware vendor, for which no Gentoo package ever existed. There seems to be a pretty high number of unmaintained packages in the tree if you look at hwoarang's response to this thread, so I'm not sure how that is going. Not all maintainer-needed packages are neglected, broken or useless. Best regards, Chí-Thanh Christopher Nguyễn They may not be broken or useless but if they are not neglected, please add yourself to metadata.xml. What's the point of having them marked as unmaintained if there is a maintainer behind them? -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Packages up for grab
On 14 December 2012 07:36, Kacper Kowalik xarthis...@gentoo.org wrote: Hi Folks! There are a few packages that I'm no longer interested in maintaining: media-gfx/mandelbulber (co maintained-by media-gfx, needs bump and some opencl love) net-irc/irssi-xmpp (stablereq pending #440864) net-misc/identicurse (no bugs, no stable) I'll drop myself in a week and assign to m-n@g.o or leave just the herd. Of course unless you grab them first ;-) Thanks! Kacper If the herd is not active, please drop it from metadata otherwise bugs will remain unattended. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Cleaning tree of outdated packages
On 14 December 2012 07:56, George Shapovalov geo...@gentoo.org wrote: On Thursday 13 December 2012 21:25:59 Markos Chandras wrote: We also have 720 packages listed as maintainer-needed[1] meaning nobody is actually taking care of them. And this number is pretty scary. Scary how? With over 15000 packages total by now (in only the official tree; or even more, what are the last statistics anyway?) this makes for 5% of total. Reasonably good I'd say. Oh, they better be taken care of, sure. Just saying that some arbitraty number is scary and thus we have to kill stuff because of that is not right. George I never said to remove them. Just pointing out that the number ( as an absolute number ) is high. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On 13 December 2012 21:46, Zac Medico zmed...@gentoo.org wrote: On 12/13/2012 12:43 PM, Michał Górny wrote: On Thu, 13 Dec 2012 21:33:50 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: Yes, and having 'stable' and 'unstable' profiles will work just the same. Except for the fact that it will be a bit cleaner, not require EAPI=5 at all and probably make arch testing a bit easier for a few people. Sounds good to me. Except that it completely breaks stabilization procedures, since packages are then not only tested with a larger range of useflags, but with an entirely different profile. Not such a great idea. The whole point of the stable masking was to keep the changes minimal when going from a testing to a stable state - by only restricting the use flag choices, and nothing else. This means most of the testing done with ~arch packages is still valid and provides meaningful feedback to maintainers and arch teams for stabilization. Well, it's all a question of decisions, I believe. If we make sure that the new 'unstable' profiles differ from the 'stable' ones only by additional masked/unmasked USE flags, I don't think it'd be an issue. Yeah, should be fine. How are you engoing to ensure that? And how are you going to monitor them so they will not get out-of-sync in future? We have plenty of examples of stale profile entries all over the profiles/arch directory so I think that the stable *use.stable.mask will also end up unmaintained in the near future. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Cleaning tree of outdated packages
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/12/12 10:51 PM, William Hubbs wrote: On Thu, Dec 13, 2012 at 10:06:34PM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 13/12/12 06:49 PM, William Hubbs wrote: For example, glibc-2.9 and gcc-2.95. I think that if we are going to keep things this old in the tree we need a good reason for them. iirc, gcc-2.95 and linux-2.4 (still used for some embedded systems) play best together. I'm not sure how strong this argument is because we don't have any 2.4 kernels in the tree, and I am wondering why we still have a linux-headers-2.4. Yeah i'm not arguing to keep it, just mentioning a possible use case for it compared to newer versions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDLICkACgkQ2ugaI38ACPAKQAD/b8NgCW4xTzHQNWD1CJvBJ90O VfmOuwqZt6Q5PZEPidsBALduZxL/MXFJQipiXv0Ux5yb2YWyczJpxgbVC6PY8bQv =dVew -END PGP SIGNATURE-
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On Fri, 14 Dec 2012 12:38:24 + Markos Chandras hwoar...@gentoo.org wrote: On 13 December 2012 21:46, Zac Medico zmed...@gentoo.org wrote: On 12/13/2012 12:43 PM, Michał Górny wrote: On Thu, 13 Dec 2012 21:33:50 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: Yes, and having 'stable' and 'unstable' profiles will work just the same. Except for the fact that it will be a bit cleaner, not require EAPI=5 at all and probably make arch testing a bit easier for a few people. Sounds good to me. Except that it completely breaks stabilization procedures, since packages are then not only tested with a larger range of useflags, but with an entirely different profile. Not such a great idea. The whole point of the stable masking was to keep the changes minimal when going from a testing to a stable state - by only restricting the use flag choices, and nothing else. This means most of the testing done with ~arch packages is still valid and provides meaningful feedback to maintainers and arch teams for stabilization. Well, it's all a question of decisions, I believe. If we make sure that the new 'unstable' profiles differ from the 'stable' ones only by additional masked/unmasked USE flags, I don't think it'd be an issue. Yeah, should be fine. How are you engoing to ensure that? And how are you going to monitor them so they will not get out-of-sync in future? We have plenty of examples of stale profile entries all over the profiles/arch directory so I think that the stable *use.stable.mask will also end up unmaintained in the near future. What is your solution then? Keeping two revisions of most ebuilds so that one could be stabilized? I don't see how that is more maintainable, except for a few days who will easily stay out of it and pretend that the issue doesn't exist. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On 14 December 2012 14:29, Michał Górny mgo...@gentoo.org wrote: On Fri, 14 Dec 2012 12:38:24 + Markos Chandras hwoar...@gentoo.org wrote: On 13 December 2012 21:46, Zac Medico zmed...@gentoo.org wrote: On 12/13/2012 12:43 PM, Michał Górny wrote: On Thu, 13 Dec 2012 21:33:50 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: Yes, and having 'stable' and 'unstable' profiles will work just the same. Except for the fact that it will be a bit cleaner, not require EAPI=5 at all and probably make arch testing a bit easier for a few people. Sounds good to me. Except that it completely breaks stabilization procedures, since packages are then not only tested with a larger range of useflags, but with an entirely different profile. Not such a great idea. The whole point of the stable masking was to keep the changes minimal when going from a testing to a stable state - by only restricting the use flag choices, and nothing else. This means most of the testing done with ~arch packages is still valid and provides meaningful feedback to maintainers and arch teams for stabilization. Well, it's all a question of decisions, I believe. If we make sure that the new 'unstable' profiles differ from the 'stable' ones only by additional masked/unmasked USE flags, I don't think it'd be an issue. Yeah, should be fine. How are you engoing to ensure that? And how are you going to monitor them so they will not get out-of-sync in future? We have plenty of examples of stale profile entries all over the profiles/arch directory so I think that the stable *use.stable.mask will also end up unmaintained in the near future. What is your solution then? Keeping two revisions of most ebuilds so that one could be stabilized? I don't see how that is more maintainable, except for a few days who will easily stay out of it and pretend that the issue doesn't exist. -- Best regards, Michał Górny By keeping multiple ebuilds around you are transfering the maintenance responsibility to the invdividual developer/herd. By adding the *use.stable.mask to each architecture, you are transferring this responsibility to the arch maintainers. We already have plenty of understaffed arches, I don't think it is wise to throw more responsibilities to them. Unless of course all developers are allowed to touch these *stable* profiles which personally I don't like because arches will lose control of their stable trees. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Remind me and the list again pls, why is this necessary rather than just using use.stable.mask and EAPI5 ebuilds in the regular profiles? This shouldn't break the tree with a non-EAPI5 portage as the files would just be ignored, as would the EAPI5 ebuilds. For some core stuff (like portage) i could see this as being an issue but we aren't going to need to use.stable.mask flags on core packages are we? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDLOjwACgkQ2ugaI38ACPAaugD/frwJ+kv9w49o1vPGQfLD0uQT nj2pVXrks/RYUZp+PL8A/1JYcKdzlAup+LIpY/uQzcGwqmtS3U34ZzM7vG+CRQ70 =nXpr -END PGP SIGNATURE-
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On Fri, 14 Dec 2012 14:36:49 + Markos Chandras hwoar...@gentoo.org wrote: On 14 December 2012 14:29, Michał Górny mgo...@gentoo.org wrote: On Fri, 14 Dec 2012 12:38:24 + Markos Chandras hwoar...@gentoo.org wrote: On 13 December 2012 21:46, Zac Medico zmed...@gentoo.org wrote: On 12/13/2012 12:43 PM, Michał Górny wrote: On Thu, 13 Dec 2012 21:33:50 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 12. Dezember 2012, 11:30:17 schrieb Zac Medico: Yes, and having 'stable' and 'unstable' profiles will work just the same. Except for the fact that it will be a bit cleaner, not require EAPI=5 at all and probably make arch testing a bit easier for a few people. Sounds good to me. Except that it completely breaks stabilization procedures, since packages are then not only tested with a larger range of useflags, but with an entirely different profile. Not such a great idea. The whole point of the stable masking was to keep the changes minimal when going from a testing to a stable state - by only restricting the use flag choices, and nothing else. This means most of the testing done with ~arch packages is still valid and provides meaningful feedback to maintainers and arch teams for stabilization. Well, it's all a question of decisions, I believe. If we make sure that the new 'unstable' profiles differ from the 'stable' ones only by additional masked/unmasked USE flags, I don't think it'd be an issue. Yeah, should be fine. How are you engoing to ensure that? And how are you going to monitor them so they will not get out-of-sync in future? We have plenty of examples of stale profile entries all over the profiles/arch directory so I think that the stable *use.stable.mask will also end up unmaintained in the near future. What is your solution then? Keeping two revisions of most ebuilds so that one could be stabilized? I don't see how that is more maintainable, except for a few days who will easily stay out of it and pretend that the issue doesn't exist. -- Best regards, Michał Górny By keeping multiple ebuilds around you are transfering the maintenance responsibility to the invdividual developer/herd. By adding the *use.stable.mask to each architecture, you are transferring this responsibility to the arch maintainers. Yes and no. Although we have a few arches which believe nobody should touch their files (but instead wait a few weeks till they actually notice someone asked them to mask a flag), I think you shouldn't overreact on this. Let's talk on examples. A good example is pypy which is not stable on any arch. I don't really see a problem with Python team actually maintaining use.mask entry for that implementation. And even if arch teams preferred to handle this on their own, I don't think that's much work as long as it's clear what the goal is. A quick look at dev-python gives me almost 800 packages; a quick ugly grep gives around 350 packages with stable keywords. This means that in the near time there will be around 250-300 additional ebuilds to maintain just because we can't mask the pypy flag on stable arches. We already have plenty of understaffed arches, I don't think it is wise to throw more responsibilities to them. Unless of course all developers are allowed to touch these *stable* profiles which personally I don't like because arches will lose control of their stable trees. I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 x86. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, 14 Dec 2012 09:39:56 -0500 Ian Stakenvicius a...@gentoo.org wrote: Remind me and the list again pls, why is this necessary rather than just using use.stable.mask and EAPI5 ebuilds in the regular profiles? This shouldn't break the tree with a non-EAPI5 portage as the files would just be ignored, as would the EAPI5 ebuilds. PMS requires that profiles directory is EAPI=5 before we can use those files. In other words, we would be forced to make non-EAPI5 portage ignore the whole profiles. - -- Best regards, Michał Górny -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iJwEAQEIAAYFAlDLPygACgkQfXuS5UK5QB02zAP/bu9eANQrQ01PlKdp/IDDuPxm VgXi18K1sVUYXNA3n2K46t+7pkX/YewPRBqN8Bn7pHJwsfo/7m/FOfcOvdsdDCoM sCySNcAKSXq65qG8rKuFK50yWUTNFfSLKC+nFgKlm+Zz8qPuHYAZnkAu5B9idlxV Fr0DDriG5oRhduqWlEM= =2Ftf -END PGP SIGNATURE-
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On 14 December 2012 14:59, Michał Górny mgo...@gentoo.org wrote: We already have plenty of understaffed arches, I don't think it is wise to throw more responsibilities to them. Unless of course all developers are allowed to touch these *stable* profiles which personally I don't like because arches will lose control of their stable trees. I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 x86. -- Best regards, Michał Górny I fear that the stable and testing profiles will diverge way too much as time passes. But if you feel that maintainers and herds will be able to keep the 'diff' between them as minimum as possible, then I have no objections. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Getting EAPI 5 *use.stable.mask to work in gx86?
On Fri, 14 Dec 2012 15:08:24 + Markos Chandras hwoar...@gentoo.org wrote: On 14 December 2012 14:59, Michał Górny mgo...@gentoo.org wrote: We already have plenty of understaffed arches, I don't think it is wise to throw more responsibilities to them. Unless of course all developers are allowed to touch these *stable* profiles which personally I don't like because arches will lose control of their stable trees. I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 x86. -- Best regards, Michał Górny I fear that the stable and testing profiles will diverge way too much as time passes. But if you feel that maintainers and herds will be able to keep the 'diff' between them as minimum as possible, then I have no objections. Well, my hope is that we will be able to do it mostly via a common 'testing' profile (or per-arch testing profiles) which will be parents to other sub-profiles. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Cleaning tree of outdated packages
On Thu, 13 Dec 2012 21:25:59 + Markos Chandras hwoar...@gentoo.org wrote: We also have 720 packages listed as maintainer-needed[1] meaning nobody is actually taking care of them. And this number is pretty scary. [1]http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml Why is the number 720 scary? We have about 16,000 packages, so that's just 5 percent of all packages. We would be in trouble if there were significantly more m-n packages, but then the urgency would probably drive more people to fix/remove the packages with actual problems. All the other m-n packages can just sit there and be useful to an unknown number of users out there. Only 135 bugs are assigned to m-n right now. Some of the affected packages are up for removal. which we have a team for. Most of the remaining bugs can be fixed by anyone with commit access, which is what m-n assignment is intended for. jer
Re: [gentoo-dev] Cleaning tree of outdated packages
WH == William Hubbs willi...@gentoo.org writes: WH For example, glibc-2.9 and gcc-2.95. I think that if we are going to WH keep things this old in the tree we need a good reason for them. gcc-2.95 is still the current version for some non-mainstream dist+ architecture tuples. The ability to test whether one's code works on 2.95 has value. Of course, if it will not compile on mainstream systems, that is and entirely different story. The older compiles also do support some targets which since have been dropped, should one want to cross-compile for such systems one would require the archaic compiler. In short, as long as it doesn't require *too* much effort, old versions of slotted packages shouldn't be dropped *only* because they are old. -JimC -- James Cloos cl...@jhcloos.com OpenPGP: 1024D/ED7DAEA6
[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? thanks, greg k-h
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDLeHcACgkQ2ugaI38ACPCErAEAug/ESN7UT1ll76ey9o2ZeNh4 khuFMK8Q5NsUiQBn9ukBAMA9ZeCQ5RqkaaKqEg9mMRDaaDUFepDWFisEhZBjNLy4 =iWNA -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. Greg, can you write back to this message with specific examples of what would need to be customized so that separate /usr would work right without an initramfs? I have tried to explain multiple times that this is a mis-conception that udev caused it, but I am getting nowhere. Thanks, William pgpWL6Lcqvv9C.pgp Description: PGP signature
Re: [gentoo-dev] Cleaning tree of outdated packages
El jue, 13-12-2012 a las 21:51 -0600, William Hubbs escribió: [...] I'm wondering if packages assigned to maintainer-needed should be looked at and removed since no one cares about them after they have sat there for a certain amount of time? They are, aren't they? treecleaners has been doing a pretty good job of that iirc. At least, those that have had bugs filed against them without being addressed... There seems to be a pretty high number of unmaintained packages in the tree if you look at hwoarang's response to this thread, so I'm not sure how that is going. William Regarding maintainers-needed packages, I am in its mail alias to try to take care of them (there are more developers in its alias doing really nice work with them) and, since I am also in treecleaners team, we try to remember to lastrite packages under maintainer-needed umbrella when an important bug for them is reported and there is no way to fix them. Then, from maintainer-needed packages point of view, I think they are pretty clean when talking about broken packages still living in the tree. Regarding its old stable versions, I think I talked about this with Ago time ago and he cleaned a bunch of old versions. The only problem I see with amount of packages under maintainer-needed umbrella is that... would be nice to get specific maintainer/proxy-maintainers for them or more people joining to maintainer-needed mail alias to fix their bugs when have enough time ;) signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. Ok, when is soon? I'm guessing that the result of the council meeting ment that things are progressing, right? If so, in what way? In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. I am not referring to udev's dependancies, that was never the real issue with a separate /usr/ partition as those could easily be fixed with a configuration option for the package. There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. That's the big problem, those need to be fixed. Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. Again, udev itself was never an issue, it could work just fine with a separate /usr/ partition. Now perhaps our ebuild didn't build it in that matter, but that's a configuration/ebuild issue, not a upstream package issue. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. If the plan is still to require an initramfs (hint, it's the only way it can work), then why was the eudev package forked and created? Please, I'm totally confused now, especially after reading the commits in the eudev repo, I see nothing that fixed any /usr/ problems, what am I missing? Oh, you also slowed the build time of the package down in eudev compared to udev, but I'm sure you realized that already, and did it for a good reason. confused, greg k-h
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote: On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. Greg, can you write back to this message with specific examples of what would need to be customized so that separate /usr would work right without an initramfs? I have tried to explain multiple times that this is a mis-conception that udev caused it, but I am getting nowhere. It's not my job to do this, nor yours, or fix any of these issues. It's up to the people who wish to keep a separate /usr partition without an initramfs to do this work. greg k-h
[gentoo-dev] Re: Getting EAPI 5 *use.stable.mask to work in gx86?
Michał Górny posted on Fri, 14 Dec 2012 16:15:05 +0100 as excerpted: On Fri, 14 Dec 2012 15:08:24 + Markos Chandras hwoar...@gentoo.org wrote: I'd like to point out that my proposal implies that the *current* arches become the stable arches, and new sub-arches would be the testing ones. Therefore, everyone will be allowed to touch like everyone is allowed to touch the *stable* profiles today. In other words, we mask python_targets_pypy* in the base profiles, and unmask them in the testing sub-profiles for amd64 x86. I fear that the stable and testing profiles will diverge way too much as time passes. But if you feel that maintainers and herds will be able to keep the 'diff' between them as minimum as possible, then I have no objections. Well, my hope is that we will be able to do it mostly via a common 'testing' profile (or per-arch testing profiles) which will be parents to other sub-profiles. Yes. Divergence over time is a worry, but we've had cascading profiles for quite some time now, so in theory, all that would be needed here is a a set of cascading testing profiles that simply inherit the stable profiles. Then the testing profiles can simply inherit the stable profiles, with the only difference being the new EAPI-5 files in the testing profiles (and perhaps eventually the deprecation and in a year or two the final removal of the old profiles, with everything from them then moved to the new ones). As long as that's KEPT the only difference... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
Firstly I use your longlasting 3.2 kernel currently though perhaps not for long as I'm switching distro to avoid systemd and thank you for the LTS work, however that won't stop me speaking my mind. _ Greg, can you write back to this message with specific examples of what would need to be customized so that separate /usr would work right without an initramfs? I have tried to explain multiple times that this is a mis-conception that udev caused it, but I am getting nowhere. It's not my job to do this, nor yours, or fix any of these issues. It's up to the people who wish to keep a separate /usr partition without an initramfs to do this work. So even though you keep stating things without being specific like udev is not a blocker, you have just admitted that the udev package does violate the Filesystem Hiearchical Standard as well as the latest draft when installing. I can understand following the current trend (some of which I agreed with) but what is the justification for that which didn't already have an optional solution? It's not your job?. I'd hope your unix spirit or atleast professionalism would be greater than this and realise that helping may save good devs time more than it costs you and realise that the generic goals may not be everyone's or even the long lasting correct ones and competition is good and not intended as a kick in the teeth or insult. p.s. embedded does not equal mobile and android uses a leaner init than /sbin/init and experiments posted to the buildroot list found systemd to be slower, guessed to be due to increased cycles but perhaps memory usage on even some mobile level processors which accounts for a fraction of linux potential in embedded applications. POSIX compliance is also a requirement by some major industries. -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
[gentoo-dev] Re: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/12 03:02 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: Eudev's project announcement is coming soon, should answer your questions. Ok, when is soon? It's being drafted as we speak, so it will probably be released within a few days. I'm not authoring it so I can't give you an exact time for when the announcement will be posted. I'm guessing that the result of the council meeting meant that things are progressing, right? If so, in what way? Sounds like you should join us in #gentoo-udev to discuss, or join the eudev mailing list. I'd rather not spend a significant amount of time writing about eudev development on gentoo-dev@ given it's not really on-topic here. In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. I am not referring to udev's dependancies, that was never the real issue with a separate /usr/ partition as those could easily be fixed with a configuration option for the package. Understood, but they still needed to be fixed (their packaging). (I expect most issues regarding separate-/usr-without-initramfs support will be about fixing packaging) There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. That's the big problem, those need to be fixed. Agreed. However as i'm looking at this from the eudev perspective at this point, rather than the sys-fs/udev perspective, there are things necessary to integrate into eudev (the gentoo package, and possibly also the code) itself before we as the eudev team are ready to see what else is broken and needs adjustment. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. If the plan is still to require an initramfs (hint, it's the only way it can work), then why was the eudev package forked and created? This is the plan for sys-fs/udev in gentoo (sorry i'd thought i was clear on that, i apologize if I wasn't), sys-fs/eudev maintainers intend to support separate-/usr without initramfs to the best of our abilities. Please, I'm totally confused now, especially after reading the commits in the eudev repo, I see nothing that fixed any /usr/ problems, what am I missing? You're not missing anything -- eudev is still a WIP and doesn't have the support for separate-/usr yet (either in the codebase or in the gentoo package). We're working on it. It'll be in place by the time we have a full release tagged. For further details (and as stated above) I suggest we discuss on irc, via the eudev mailing list, or via email directly. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDLlY4ACgkQ2ugaI38ACPB52gD/d2E2WL2ZYxadGswJIqP3nqqW Co+0ua+G5yXQ8+lFiP4A/248opPpMkzm1pEklhJBUvaVrZ7JW3xWSLOpKOPs6iQr =xy6w -END PGP SIGNATURE-
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Everyone, given we already went through a major bikeshed a month ago, let's not do it again...? On 14/12/12 04:00 PM, Kevin Chadwick wrote: [ Snip! ] -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDLlfAACgkQ2ugaI38ACPBEyAD+KU3unjYTmevc2SRVCZDH9eZ2 nrpgstesBNH7KG6bcsMBAJwE+vsPQJouMQA6tQ8xzCpM7s929+fk4R+AQh96b0Gd =zTGa -END PGP SIGNATURE-
[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
Greg KH posted on Fri, 14 Dec 2012 12:04:03 -0800 as excerpted: n Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote: On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: On 14/12/12 01:28 PM, Greg KH wrote: udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. Greg, can you write back to this message with specific examples of what would need to be customized so that separate /usr would work right without an initramfs? I have tried to explain multiple times that this is a mis-conception that udev caused it, but I am getting nowhere. It's not my job to do this, nor yours, or fix any of these issues. It's up to the people who wish to keep a separate /usr partition without an initramfs to do this work. There's a saying, extreme claims require extreme proof. I don't personally have a stake in this as by personal policy my root includes /usr, but... for (1) people who had a separate /usr, who then (2) had that break with a udev upgrade, and (3) saw the very high visibility claims that despite the evidence of their own eyes, udev was *NOT* what broke things... To these people, the claim that udev was NOT what broke (non initr*) boot of a separate /usr system, looks rather extreme. Yet the people who made that claim both: 1) Continue to make it, just as strenuously and high visibility as they did before, and 2) Continue to try to shift responsibility for proving evidence for that claim, despite the (a) I was THERE! evidence many have that a udev update is what broke things for THEM and (b) the high visibility yet evidently extreme (from the point of view of those who saw the breakage happen with a udev update) claims to the contrary. There's a discontinuity there. Either udev wasn't the problem and those claiming it was should be easily able to provide a list of (non-corner- case) examples where it was broken previously, or udev WAS the problem, as they I was THERE! evidence of many users suggest. Yet those making the (to those that were there) extreme claim continue to avoid providing appropriate evidence to back it up, saying it's not their job to provide such evidence, despite the /apparent/ extremity of their claim. This sort of /apparent/ illogic and refusal to justify apparently arbitrary decisions only contributes to the unfortunate situation. Oh, well, both the making of sausage and the making of law is said not to be pretty, who ever expected the making and evolution of FLOSS platform software to be pretty. Surprisingly, despite the issues, we always seem to muddle thru, and the problems eventually resolve themselves to a reasonably stable situation of either a major dominance of one solution (see xorg/xfree86), or of competing multiple solutions (see emacs/vi or kde/gnome/xfce/...), over time. Regardless of any temporary angst, I suppose the same will ultimately apply here. From a third party perspective, however, some of that angst sure seems unnecessary. shrug -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, 14 Dec 2012 12:02:40 -0800 Greg KH gre...@gentoo.org wrote: On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: On 14/12/12 01:28 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: Handling separate /usr support == After the discussion on [1] during the previous meeting, a delay of one month due to a new fork of udev was requested. We need an update on what's happened. Chainsaw reported udev and eudev have moved on, and for both it is now possible to have a separate /usr. The follow-up discussion related to the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? Eudev's project announcement is coming soon, should answer your questions. Ok, when is soon? I'm guessing that the result of the council meeting ment that things are progressing, right? If so, in what way? Why would it matter if soon meant a week or a month from now? In terms of udev's dependencies, yes, the few dependencies that were installing only to /usr (ie, kmod and xz-utils) have been switched to install to /, and then fixed again due to issues with they way they were done the first time so that they also work. I believe however they are still ~arch keyworded. I am not referring to udev's dependancies, that was never the real issue with a separate /usr/ partition as those could easily be fixed with a configuration option for the package. If some vocal upstream and otherwise respected maintainers claim it to be broken and calls everyone a fool for not following suite, that's what we get. ;) There may of course be other entirely independent packages needed at boot time prior to localmount, I do not know that status of those. That's the big problem, those need to be fixed. But there is no hurry as separate /usr is broken for years, right? Once eudev (the gentoo package) fully supports separate-/usr (which it doesn't at this time as it uses the same init scripts as udev-196), we will be sure to resolve them. Again, udev itself was never an issue, it could work just fine with a separate /usr/ partition. Now perhaps our ebuild didn't build it in that matter, but that's a configuration/ebuild issue, not a upstream package issue. udev not only could work just fine with a separate /usr but potentially make it a non issue. Let's see if eudev succeeds here. If it's the right place to solve it is another question, though the right place for udev isn't in systemd either. It should be noted that sys-fs/udev (the package) since .. 186 I think? whichever version dropped support for the failed-rules queue (and whichever package dropped the udev-postmount init script) does not support booting with a separate /usr. This has more to do with how the package installs than the upstream code itself, though; as such (WilliamH please correct me if I'm wrong) the plan is still to require an initramfs if using sys-fs/udev with a separate-/usr. If the plan is still to require an initramfs (hint, it's the only way it can work), then why was the eudev package forked and created? sys-fs/udev is systemd-udev, hope we don't have to rename the package to make this clear. Please, I'm totally confused now, especially after reading the commits in the eudev repo, I see nothing that fixed any /usr/ problems, what am I missing? The sentence in the very same mail that it's currently not working / implemented maybe? Oh, you also slowed the build time of the package down in eudev compared to udev, but I'm sure you realized that already, and did it for a good reason. That's always the last straw, spd! confused, greg k-h Seriously, while I agree the eudev fork had an ivory tower start, I don't get what you gain by running around like an elephant in a porcelain shop. I for one welcome yet another fork. Time will tell if it can prevail. Regards Ralph
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 09:00:56PM +, Kevin Chadwick wrote: Greg, can you write back to this message with specific examples of what would need to be customized so that separate /usr would work right without an initramfs? I have tried to explain multiple times that this is a mis-conception that udev caused it, but I am getting nowhere. It's not my job to do this, nor yours, or fix any of these issues. It's up to the people who wish to keep a separate /usr partition without an initramfs to do this work. So even though you keep stating things without being specific like udev is not a blocker, you have just admitted that the udev package does violate the Filesystem Hiearchical Standard as well as the latest draft when installing. Specifically how does udev violate it? And also note, FHS is a trailing standard, documenting how things are done, not how they should be done. It can be changed. And since when did Gentoo start worrying about FHS and LSB? I can understand following the current trend (some of which I agreed with) but what is the justification for that which didn't already have an optional solution? I don't understand, what in the udev package, or source, goes against FHS? p.s. embedded does not equal mobile and android uses a leaner init than /sbin/init and experiments posted to the buildroot list found systemd to be slower, guessed to be due to increased cycles but perhaps memory usage on even some mobile level processors which accounts for a fraction of linux potential in embedded applications. POSIX compliance is also a requirement by some major industries. What does POSIX have to do with anything here? And when did I bring up systemd and boot times? That's not what this thread is about, sorry. greg k-h
Re: [gentoo-dev] Re: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)
On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote: On 14/12/12 03:02 PM, Greg KH wrote: I'm guessing that the result of the council meeting meant that things are progressing, right? If so, in what way? Sounds like you should join us in #gentoo-udev to discuss, or join the eudev mailing list. I'd rather not spend a significant amount of time writing about eudev development on gentoo-dev@ given it's not really on-topic here. It was discussed at the Gentoo Council meeting, how could that _not_ be on topic here? greg k-h
Re: [gentoo-dev] Re: [e]udev , and please let's move this to a better location
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 14/12/12 06:24 PM, Greg KH wrote: On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote: On 14/12/12 03:02 PM, Greg KH wrote: I'm guessing that the result of the council meeting meant that things are progressing, right? If so, in what way? Sounds like you should join us in #gentoo-udev to discuss, or join the eudev mailing list. I'd rather not spend a significant amount of time writing about eudev development on gentoo-dev@ given it's not really on-topic here. It was discussed at the Gentoo Council meeting, how could that _not_ be on topic here? greg k-h Not really, no -- what was discussed at the Council meeting was more or less verbatum what was said in the summary -- Chainsaw reported that eudev was progressing, had entered the tree, and that he was confident that it will fulfill the needs of a udev package in Gentoo that will support separate-/usr without an initramfs. Any further details of eudev's implementation and/or development were not discussed at the meeting and are not something that I believe Council cares about in any particular way either. (in fact, the conversation rather quickly turned to a discussion on the role of gen_usr_ldscript() rather than anything udev/eudev related) So, everyone, for more discussion about eudev development, please join the shiny new eudev mailing list; we'll be happy to get into all the nitty gritty details there and spare all the dev's that don't care from having to filter it out of their inboxes. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlDL2okACgkQ2ugaI38ACPAuyAD/esvQcRiUWBeaO8jHyAOvWBp9 yt/2xghT+VGjbpKJmOQA/jpIIoRuCe87k28nvJj1iVSwVALhq9n5dvER3NReR/C/ =8p5A -END PGP SIGNATURE-
[gentoo-dev] eudev project announcement
Dear Everyone, I am pleased to announce the Gentoo eudev project. Many of you already know about the eudev project from early publicity that we had before things were ready. Despite that, I hope to take advantage of the official announcement to explain what we are doing, why we are doing it and what it means for you. I have broken the announcement into subsections, each with a title for ease of reading. Why fork udev? Earlier this year, udev upstream was absorbed into systemd. udev often breaks compatibility with older systems by depending upon recent Linux kernel releases, even when such dependencies are avoidable. This became worse after udev became part of systemd, which has jeopardized our ability to support existing installations. The systemd developers are uninterested in providing full support in udev to systemd alternatives. These are problems for us and we have decided to fork udev to address them. You are a Gentoo project. What does this mean? Gentoo as an organization is quite similar to github, although it is exclusive to Gentoo developers. Our rules permit all Gentoo developers have the ability to start a project and such projects are entitled to be hosted on Gentoo infrastructure. This by no means constitutes official endorsement by Gentoo's governing body and we have no authority to dictate the future direction of Gentoo. We do have the ability to provide an alternative to Gentoo users, which we fully intend to do. eudev will be by no means exclusive to Gentoo. We will handle bug reports from users of other distribution in the same way that we handle bug reports involving Gentoo. This will be much like other Gentoo-hosted projects such as portage and OpenRC. What is your project's license? The systemd developers were in the middle of a transition to the LGPL from the GPL when we forked. We inherited the code in the middle of that transition and we see no reason to pursue a different course. Therefore, all future changes that we make to eudev will be available under the LGPL. What are your project's goals? Our primary goal is to address the problems with systemd-udev that caused us to fork it in the first place. In particular, we want better compatibility with existing software such as OpenRC and Upstart, older kernels, various toolchains and anything else required by users and various distributions. We also want to minimize regressions and work with developers of other distributions (and components used by them) to address issues. How will you minimize regressions? We intend to maintain HEAD in a releaseable state. All minor changes require review from one eudev developer and all major changes require review from two eudev developers. This does not include the author. In addition, we intend to require commits to make logically independent changes with descriptive commit messages to make regression hunting easier when regressions do happen. These rules were not enforced at the beginning, but we are transitioning toward enforcement. They will enter full effect once we tag our first release candidate. How do you intend to work with other distributions? We have our repository on github, which is known for easy collaboration. If a distribution developer identifies a problem with eudev, they can file an issue and we will do our best to resolve their problem. If they wish to work with us to resolve it, we can talk in IRC and they can also file pull requests. Provided that the changes are not entirely unreasonable (e.g. pushing an init system into udev), we are willing to work with authors of pull requests to get them into a mergeable state. The only hard rule is that changes cannot break the ability of existing systems to upgrade. We also plan to make an official mailing list, which will be hosted on Gentoo infrastructure. Will you make the boot process faster? We have ideas on how to make udevd faster. However, people usually only notice the time that udevd takes when there is a bug and we are more interested in fixing those bugs than we are in shaving milliseconds off boot time. There are plenty of areas that could use attention by people that are interested in a faster boot process before udev becomes one of them. We consider things such as a reliable boot process to be more important than speed and we are willing to subject users to the additional few hundred milliseconds that failing to tweak things for speed incurs. We are already dealing with regressions that the systemd developers introduced in their attempt to make things faster and we consider fixing them to be a priority. However, we would be happy to collaborate with people willing to work on boot speed improvements to get them into a mergeable state. We encourage people interested in speed improvements to talk to us about how they could be done in a reasonable manner. It would be premature to do it at this instant, but it
Re: [gentoo-dev] eudev project announcement
On 12/14/2012 10:52 PM, Richard Yao wrote: Dear Everyone, I am pleased to announce the Gentoo eudev project. Many of you already know about the eudev project from early publicity that we had before things were ready. Despite that, I hope to take advantage of the official announcement to explain what we are doing, why we are doing it and what it means for you. I have broken the announcement into subsections, each with a title for ease of reading. Thunderbird's autocompletion appears to have caused me to send this to gentoo-dev-announce+subscribe by mistake. I have sent out a second email to correct that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] eudev project announcement
Richard Yao wrote: Where is development now? We have rewritten the build system and restored support for older kernels and verified compatibility as far back as Linux 2.6.31. We have tagged 1_beta1 and eudev is in the portage tree. A few lingering dependency issues exist, but we should have them ironed out shortly. Not yet something I care about. (That's fine.) I hope that eudev wants to do the respectable thing for any fork, ie. work hard to minimize the amount of wasted effort in both projects by sharing much code and bugfixes. //Peter pgpK7Wuj1DVLs.pgp Description: PGP signature
Re: [gentoo-dev] eudev project announcement
On Sat, Dec 15, 2012 at 05:16:48AM +0100, Peter Stuge wrote I hope that eudev wants to do the respectable thing for any fork, ie. work hard to minimize the amount of wasted effort in both projects by sharing much code and bugfixes. That would be nice if systemd/udev upstream was agreeable. On the other hand, if the systemd/udev maintainers had accepted bug reports (WONTFIX is not acceptance) and had accepted proposed patches, there wouldn't have been a need for the eudev fork in the first place. Lennart Poettering has admitted systemd's outright hostility to to standalone udev... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html Well, we intent to continue to make it possible to run udevd outside of systemd. But that's about it. We will ***NOT POLISH THAT, OR ADD NEW FEATURES*** to that or anything. OTOH we do polish behaviour of udev when used *within* systemd however, and that's our primary focus. And what we will ***CERTAINLY NOT DO IS COMPROMISE THE UNIFORM INTEGRATION INTO SYSTEMD FOR SOME COSMETIC IMPROVEMENTS FOR NON-SYSTEMD SYSTEMS***. (Yes, udev on non-systemd systems is in our eyes a dead end, in case you haven't noticed it yet. I am looking forward to the day when we can drop that support entirely.) They've essentially announced ahead of time that most bugs from non-systemd users would be closed with WONTFIX. Actually, for political reasons, I hope that eudev does submit a bunch bugs+patches, and gets them rejected. Then whenever anyone complains about not sharing code, show them a bunch of WONTFIX emails from systemd/udev maintainers. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-dev] Re: eudev project announcement
On 15/12/12 06:16, Peter Stuge wrote: Richard Yao wrote: Where is development now? We have rewritten the build system and restored support for older kernels and verified compatibility as far back as Linux 2.6.31. We have tagged 1_beta1 and eudev is in the portage tree. A few lingering dependency issues exist, but we should have them ironed out shortly. Not yet something I care about. (That's fine.) I hope that eudev wants to do the respectable thing for any fork, ie. work hard to minimize the amount of wasted effort in both projects by sharing much code and bugfixes. I, on the other hand, hope that this isn't an indication of Gentoo not being interested in systemd. I'm eagerly awaiting the moment where I can emerge systemd and just have it working.
[gentoo-dev] Re: eudev project announcement
Walter Dnes posted on Sat, 15 Dec 2012 01:33:04 -0500 as excerpted: [Udev-systemd has] essentially announced ahead of time that most bugs from non-systemd users would be closed with WONTFIX. Agreed, to this point. Actually, for political reasons, I hope that eudev does submit a bunch bugs+patches, and gets them rejected. Then whenever anyone complains about not sharing code, show them a bunch of WONTFIX emails from systemd/udev maintainers. This attitude is and the described events would be... unfortunate. For the reasons you list, I don't believe people should be /surprised/ if many such bugs+patches are rejected after submission, but that wouldn't make it any less unfortunate, and IMO, hoping they DO get rejected is the wrong attitude to have. The best possible outcome, IMO, would be that the eudev (and any other udev replacement projects) eventually work themselves out of a job. Ideally, the very existence of these projects will trigger a rethink on the part of the udev folks, causing the reasons for the fork to disappear over time. Ideally, with effort and compromise on NIH and similar attitudes on /both/ sides, differences can be put aside and udev (whether it remains developed under the systemd umbrella or not) can once again be the unifying influence its authors claim to intend. To some extent the hubbub has already appeared to trigger incremental walkbacks and/or the exploration of third ways. The kernel's recent addition of its own module loading code, endorsed by the udev folks, is one such third way development. Perhaps I'm reading my own viewpoint into things, but it seems from here anyway, that the systemd-udev side rhetoric on initr*-less support for a separate /usr is... less strident... than it was. And kmod was initially required by new udev, but is now optional. I'd call all of these good developments... that may well have never occurred had pushback including but not limited to the eudev project hadn't occurred. Ideally, then, the need for eudev as an actually installed systemd-udev alternative will disappear even as eudev is being born. However, that's no argument yet for termination of the project and in fact is arguably the reverse, given systemd and now udev's history of ignoring feedback from those it's riding roughshod over, as long as people continue to LET it ride roughshod over them. The existence of the eudev project, therefore, may continue to be necessary, if only to provide a practical udev alternative such that udev itself moderates to the point that the alternative need not be actually used on a system. But at least there's an alternative now, so that regardless of whether systemd-udev moderates or not, people aren't left without recourse. Hopefully that moderation occurs and the alternatives can ultimately be merged back in, but there's recourse now, so people are no longer actually dependent on udev-systemd's moderation. Which way that takes both udev-systemd and eudev remains to be seen, but I'd /still/ consider it /unfortunate/ if those bugs+patches do appear and get WONTFIXed, thus, certainly I hope they appear, but just as certainly, one can HOPE they get resolved/merged, *NOT* resolved/WONTFIXed. Time will tell. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
