[gentoo-dev] Re: [PATCH] Check for USE_PYTHON - PYTHON_TARGETS sync.
On Fri, Nov 16, 2012 at 1:44 PM, Michał Górny mgo...@gentoo.org wrote: This is much more complex than the previous version. The inline comments and debug-print statements are helpful. Do we have a way to test this with various combinations of PYTHON_COMPAT, PYTHON_TARGETS, eselect python, and USE_PYTHON? I have some suggestions on the actual warning text below. If user doesn't have USE_PYTHON set, it tries to solve the issue using eselect-python only, suggesting user to switch the active implementation. If eselect-python won't help or user has USE_PYTHON set, it nicely suggests a new value, highlighting added and listing removed entries. The basic issue here is that the package can only check PYTHON_TARGETS values in IUSE, so only the implementations supported by the package. It tries hard to help and not to do any damage, so user may need to modify his USE_PYTHON more than once. For example, consider the following: - installed: 2.6, 2.7, 3.1, 3.2, pypy1.8 - active: 2.6, 3.2 - USE_PYTHON not set - PYTHON_TARGETS: 2.7, 3.1, 3.2, pypy1.8 Package 1 supports Python 2 only. The eclass can't access Python 3 PYTHON_TARGETS, thus it can only suggest user to switch active Python interpreter to Python 2.7. This solves the Python2 packages only. Package 2 supports both Python 2 3. The eclass notices two Python 3 versions and suggests user to add USE_PYTHON='2.7 3.1 3.2'. Package 3 supports PyPy additionally. The eclass notices that, and suggests user to add '2.7-pypy-1.8' to USE_PYTHON. Of course, that assumes building one-by-one. If more packages get pulled into the dep tree, the results of checks may look even contradictory. Hopefully, after a few changes and rebuilds user will finally get the correct value. --- gx86/eclass/python-r1.eclass | 198 +++ 1 file changed, 198 insertions(+) diff --git a/gx86/eclass/python-r1.eclass b/gx86/eclass/python-r1.eclass index 0d6ef4c..61edf94 100644 --- a/gx86/eclass/python-r1.eclass +++ b/gx86/eclass/python-r1.eclass @@ -363,6 +363,202 @@ python_copy_sources() { done } +# @FUNCTION: _python_check_USE_PYTHON +# @INTERNAL +# @DESCRIPTION: +# Check whether USE_PYTHON and PYTHON_TARGETS are in sync. Output +# warnings if they are not. +_python_check_USE_PYTHON() { + debug-print-function ${FUNCNAME} ${@} + + if [[ ! ${_PYTHON_USE_PYTHON_CHECKED} ]]; then + _PYTHON_USE_PYTHON_CHECKED=1 + + # python-exec has profile-forced flags. + if [[ ${CATEGORY}/${PN} == dev-python/python-exec ]]; then + return + fi + + _try_eselect() { + # The eselect solution will work only with one py2 py3. + + local impl py2 py3 dis_py2 dis_py3 + for impl in ${PYTHON_COMPAT[@]}; do + if use python_targets_${impl}; then + case ${impl} in + python2_*) + if [[ ${py2+1} ]]; then + debug-print ${FUNCNAME}: - more than one py2: ${py2} ${impl} + return 1 + fi + py2=${impl/_/.} + ;; + python3_*) + if [[ ${py3+1} ]]; then + debug-print ${FUNCNAME}: - more than one py3: ${py3} ${impl} + return 1 + fi + py3=${impl/_/.} + ;; + *) + return 1 + ;; + esac + else + case ${impl} in + python2_*) + dis_py2=1 + ;; + python3_*) + dis_py3=1 + ;; + esac + fi + done + + # The eselect solution won't work if the
Re: [gentoo-dev] Re: [PATCH] Check for USE_PYTHON - PYTHON_TARGETS sync.
On Sat, 17 Nov 2012 11:58:48 -0500 Mike Gilbert flop...@gentoo.org wrote: On Fri, Nov 16, 2012 at 1:44 PM, Michał Górny mgo...@gentoo.org wrote: This is much more complex than the previous version. The inline comments and debug-print statements are helpful. Do we have a way to test this with various combinations of PYTHON_COMPAT, PYTHON_TARGETS, eselect python, and USE_PYTHON? Well, I've just tested it by hand. If someone wants to work on bringing tests for it, I don't mind. To be honest, I don't really feel like they would be of much use. I tested and fixed what came to my head. I doubt tests will be able to find much (especially if I write them); live testing will be probably much more useful. The warning code is imperfect and mostly transitional. It tries to help but can't do more than PMS permits it to. It should lie there for some time, then we should be able to get rid of it, and forget about the whole thing. Considering that, writing tests is IMO mostly a waste of time. I have some suggestions on the actual warning text below. + if [[ ${warned} ]]; then + ewarn + ewarn Please note that after switching the active Python interpreter, + ewarn you may need to run 'python-updater' to ensure the system integrity. Change ensure the system integrity to something like rebuild affected packages. The former statement is awkward and doesn't really explain anything. Applied. + if [[ ${USE_PYTHON} ]]; then + ewarn It seems that your USE_PYTHON setting does list different Python Drop It seems that; it softens the statement for no reason. This also applies to a few statements below. Well, the main reason for that was to emphasis that the check is imperfect and the result simply may be wrong. How can I express that without adding yet another paragraph to the lengthy enough text? The phrase does list looks odd in English. Right. Replace with Your USE_PYTHON setting lists different Python + ewarn implementations than your PYTHON_TARGETS variable. Please consider + ewarn using the following value instead: + ewarn + ewarn USE_PYTHON='\033[35m${old[@]}${new[@]+ \033[1m${new[@]}}\033[0m' + + if [[ ${removed[@]} ]]; then + ewarn + ewarn (removed \033[31m${removed[@]}\033[0m) + fi + else + ewarn It seems that you need to set USE_PYTHON to make sure that legacy s/It seems that you need/You should/ The same as above. Two 'it seems' with different values vs 'you should' with two different values. + ewarn packages will be built with respect to PYTHON_TARGETS correctly: + ewarn + ewarn USE_PYTHON='\033[35;1m${new[@]}\033[0m' + fi + + ewarn + ewarn Please note that after changing the USE_PYTHON variable, you may need + ewarn to run 'python-updater' to ensure the system integrity. Again, s/ensure the system integrity/rebuild affected packages/. Applied. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] app-portage/mirrorselect-9999 call for testers
I've just done a major update of mirrorselect. While the actual functioning code did not change significantly it has been chunked up, moved short list of changes: -- fix the make.conf move. now dual location capable -- now py3 compatible. (3.1 restricted, due to differences, failures) 2.6, 2.7, 3.2, 3.3 have been tested, are known to work. testing with pypy, jython and others welcomed -- now works with a POSIX locale as well as unicode locales -- all code has been moved from a mostly monolithic script into site-packages. A minimal script now just imports and calls the site-packages code -- split up the code into several files -- create a usable api -- create a MirrorSelect class which holds all primary functions and logic -- move the logic out of main() into individual step functions. main() now calls the steps in sequence. It is primarily for use by the cli script. While it is not an often used tool past an initial install. It is a very useful tool used by many new users. I would like to get some broader testing by more people to ensure the code is ready for a release. It has not been tested in prefix yet, I'm still getting mine up to date. Thank you -- Brian Dolbec dol...@gentoo.org signature.asc Description: This is a digitally signed message part
[gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 08:02:07PM +0100, Fabian Groffen wrote: Handling separate /usr support == WilliamH requested approval for two methods to support separate /usr systems[2]. The discussion is closely related to recent opinons on udev, such as e.g. [1], because the main reason to force a system without separate /usr during boot is to allow newer versions of udev to be used. The originally announced item of discussing the removal of gen_usr_ldscript has been retracted[4]. - approve/disapprove plan (forcing everyone to take action, and implement one of the two supported solutions) WilliamH requests a council vote to allow migrating everyone after bugs [5,6,7] are resolved. He proposes a news item to announce this that allows to assume after a given period of time that everyone who is using split /usr is using a method to mount /usr before boot. The focus is purely on this topic. rich0 prefers to move on until suport for separate /usr becomes a barrier, and handle things from there. This allows for alternative solutions to be developed and put forward. He favours waiting somewhat to see developments of the udev fork. Chainsaw is a strong proponent for waiting a month and see how the new udev fork develops itself. If within a month no solution is provided by the udev fork, things need to be moved forward in WilliamH's proposed way. scarabeus approves the plan. betelgeuse likes to ensure users won't be caught off guard, but has no preference for any direction taken in particular. graaff's main concern is how the problem is tied to udev, or not. A fork of udev may not change the situation regarding separate /usr, hence delaying a decision now is not sensical. Opt-in system for people to ensure they can boot is pre-requisite. If this cannot be ensured, we have to wait. grobian disapproves the plan, since there will be systems that cannot easily be changed to ensure /usr being mounted at boot, and it is no good to expel users of (security) updates just because of that. With the use of a special profile (masks/unmasks, variables and/or use-flags), users that want to move on, can opt-in to getting packages that require non separate /usr. So, that's a nice summary, but, what is the end result here? I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) The commits so far in that repo are fun to watch for a variety of reasons, none of which I should repeat hear less I get a bunch of people mad at me :) But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) As I posted elsewhere, working on a project based on hate only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago[1]. You need to have a real solid goal in place in order to be able to keep this up in the long-run. Otherwise you are going to burn yourself out, and end up alienating a lot of people along the way. Oh, and if _anyone_ thinks that changing udev is going to solve the no separate /usr without an initrd issue, I have a bridge I want to sell them. thanks, greg k-h [1] Long story, best told over beers, take me up on it the next time you see me, I'll buy.
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) Heh, ok, it's been renamed to eudev now, that's a bit better, but not much. Odd vowel choice. Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 10:29 PM, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) That was a placeholder name. If you checked before you sent your email, you would see that we had settled on eudev. But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release The goal is to replace systemd as upstream for Gentoo Linux, its derivatives and any distribution not related to RedHat. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. Would you mind joining us in IRC to discuss your concerns? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: On 11/17/2012 10:29 PM, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) That was a placeholder name. If you checked before you sent your email, you would see that we had settled on eudev. The name change still doesn't make it any less entertaining :) What does the e stand for? But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release The goal is to replace systemd as upstream for Gentoo Linux, its derivatives and any distribution not related to RedHat. Wait, really? You want to replace systemd? Then why are you starting at udev and not systemd? What is wrong with systemd that it requires a fork? All other distros seem to be participating in the development process of systemd quite well, what is keeping Gentoo developers from also doing the same? What are your goals, specifically, in detail. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. confused, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. Seriously? Look at the comment I made on that commit for details, but here it is again: You can not claim copyright on a file you did not do one of the two things: - create yourself - modify in a major manner Adding a comment at the top saying it is part of the eudev project and covered under the LGPL2+ does not meet either of these requirements at all. By merely importing a file into a new project, you can not claim copyright on it. That's the law. The fact that this was reviewed by someone makes me seriously wonder about the copyright policies of the Gentoo Foundation. Also, you can not assign copyright to a third party, unless you have a copyright assignment form. Do the developers doing this work have such a form assigned? And in what country and state is that form valid for? Different countries, and states, have different laws here, and one-form-fits-all is not true anywhere. So blindly adding a Gentoo Foundation copyright to _any_ file in this repo, that has not met one of the two above rules, is illegal, and grounds for opening the Gentoo Foundation up to big trouble. Would you mind joining us in IRC to discuss your concerns? I don't do IRC anymore, sorry. Email is the best way to reach me. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 11:19 PM, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: On 11/17/2012 10:29 PM, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) That was a placeholder name. If you checked before you sent your email, you would see that we had settled on eudev. The name change still doesn't make it any less entertaining :) What does the e stand for? That is a common question. Someone associated with Canonical suggested that e stand for embedded. Others consider the eu prefix to be the greek root for true. Honestly, we don't care. It is just a name. But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release The goal is to replace systemd as upstream for Gentoo Linux, its derivatives and any distribution not related to RedHat. Wait, really? You want to replace systemd? Then why are you starting at udev and not systemd? What is wrong with systemd that it requires a fork? All other distros seem to be participating in the development process of systemd quite well, what is keeping Gentoo developers from also doing the same? What are your goals, specifically, in detail. Is there any way that the answer to your inquiry would result in a productive conversation where you would not attempt to dictate what we do? I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. I can say the same about the manner in which these changes were introduced. Ripping them out to get the codebase back into a state from which we are comfortable moving forward is the only sane way of dealing with them. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. To note here, since I was CC'd directly: I said changed files should get the modified notice, as Gentoo should have copyright on the changes that are explicitly new by Gentoo. I didn't say to add it to every file in the repo (but I will admit that I didn't tell him not to either). I'll state it clearly what should be the case: - the s/systemd/eudev/ line, and insertion of From prior code in systemd and pre-systemd udev being added now is fine. - WHEN substantial changes are made to an existing file, the copyright attribution should be amended to include the Gentoo Foundation. The attribution should NOT be changed before this. Better text given the existing wording would be: Portions Copyright 2012 Gentoo Foundation. - Files that have no copyright notice should NOT be touched until such time as a major addition is added to them. http://dpaste.com/832634/ is what I approved with klondike (his 2nd paste to me in the discussion). Copying out of the pastebin so we have a permanent record. Original: /*** This file is part of systemd. Copyright 2011 Lennart Poettering systemd is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. systemd is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. ***/ Modification: /*** This file is part of eudev. From prior code in systemd and pre-systemd udev. Copyright 2011 Lennart Poettering Copyright 2012 Gentoo Foundation eudev is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. eudev is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with eudev; If not, see http://www.gnu.org/licenses/. ***/ -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 11:28 PM, Greg KH wrote: On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. Seriously? Look at the comment I made on that commit for details, but here it is again: You can not claim copyright on a file you did not do one of the two things: - create yourself - modify in a major manner Adding a comment at the top saying it is part of the eudev project and covered under the LGPL2+ does not meet either of these requirements at all. By merely importing a file into a new project, you can not claim copyright on it. That's the law. The fact that this was reviewed by someone makes me seriously wonder about the copyright policies of the Gentoo Foundation. Also, you can not assign copyright to a third party, unless you have a copyright assignment form. Do the developers doing this work have such a form assigned? And in what country and state is that form valid for? Different countries, and states, have different laws here, and one-form-fits-all is not true anywhere. So blindly adding a Gentoo Foundation copyright to _any_ file in this repo, that has not met one of the two above rules, is illegal, and grounds for opening the Gentoo Foundation up to big trouble. Would you mind joining us in IRC to discuss your concerns? I don't do IRC anymore, sorry. Email is the best way to reach me. thanks, greg k-h Thanks for clarifying that. It will be fixed before it goes into HEAD. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: On 11/17/2012 11:19 PM, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: On 11/17/2012 10:29 PM, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) That was a placeholder name. If you checked before you sent your email, you would see that we had settled on eudev. The name change still doesn't make it any less entertaining :) What does the e stand for? That is a common question. Someone associated with Canonical suggested that e stand for embedded. Others consider the eu prefix to be the greek root for true. Honestly, we don't care. It is just a name. I wouldn't pick embedded as the embedded world is now using systemd as it meets their requirements much better than anything else :) But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release The goal is to replace systemd as upstream for Gentoo Linux, its derivatives and any distribution not related to RedHat. Wait, really? You want to replace systemd? Then why are you starting at udev and not systemd? What is wrong with systemd that it requires a fork? All other distros seem to be participating in the development process of systemd quite well, what is keeping Gentoo developers from also doing the same? What are your goals, specifically, in detail. Is there any way that the answer to your inquiry would result in a productive conversation where you would not attempt to dictate what we do? The only thing I'm telling anyone to do is to fix the copyright mess they created, as it is a legal liability for the Gentoo Foundation, which I care about. That HAS to be resolved. I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. I can say the same about the manner in which these changes were introduced. Ripping them out to get the codebase back into a state from which we are comfortable moving forward is the only sane way of dealing with them. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 11:28 PM, Robin H. Johnson wrote: On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. To note here, since I was CC'd directly: I said changed files should get the modified notice, as Gentoo should have copyright on the changes that are explicitly new by Gentoo. I didn't say to add it to every file in the repo (but I will admit that I didn't tell him not to either). I'll state it clearly what should be the case: - the s/systemd/eudev/ line, and insertion of From prior code in systemd and pre-systemd udev being added now is fine. - WHEN substantial changes are made to an existing file, the copyright attribution should be amended to include the Gentoo Foundation. The attribution should NOT be changed before this. Better text given the existing wording would be: Portions Copyright 2012 Gentoo Foundation. - Files that have no copyright notice should NOT be touched until such time as a major addition is added to them. http://dpaste.com/832634/ is what I approved with klondike (his 2nd paste to me in the discussion). Copying out of the pastebin so we have a permanent record. Original: /*** This file is part of systemd. Copyright 2011 Lennart Poettering systemd is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. systemd is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with systemd; If not, see http://www.gnu.org/licenses/. ***/ Modification: /*** This file is part of eudev. From prior code in systemd and pre-systemd udev. Copyright 2011 Lennart Poettering Copyright 2012 Gentoo Foundation eudev is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. eudev is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with eudev; If not, see http://www.gnu.org/licenses/. ***/ These changes were made in a branch so that they could be reviewed for the consequences of such misunderstandings before going into HEAD. I will let klondike fix the branch. We can review it again after he has finished. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 04:28:00AM +, Robin H. Johnson wrote: On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. To note here, since I was CC'd directly: I said changed files should get the modified notice, as Gentoo should have copyright on the changes that are explicitly new by Gentoo. I didn't say to add it to every file in the repo (but I will admit that I didn't tell him not to either). I'll state it clearly what should be the case: - the s/systemd/eudev/ line, and insertion of From prior code in systemd and pre-systemd udev being added now is fine. - WHEN substantial changes are made to an existing file, the copyright attribution should be amended to include the Gentoo Foundation. The attribution should NOT be changed before this. Better text given the existing wording would be: Portions Copyright 2012 Gentoo Foundation. - Files that have no copyright notice should NOT be touched until such time as a major addition is added to them. http://dpaste.com/832634/ is what I approved with klondike (his 2nd paste to me in the discussion). That makes sense, but is not what ended up in that commit. The commit needs to be removed. Also, how can any new work be assigned to the Gentoo Foundation? Is there an explicit copyright assignment happening somewhere that I am not aware of? thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:26:41PM -0500, Richard Yao wrote: Thanks for clarifying that. It will be fixed before it goes into HEAD. I recommend deleting the branch and starting over, having that commit floating around like that could cause trouble. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/17/2012 11:35 PM, Greg KH wrote: On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: On 11/17/2012 11:19 PM, Greg KH wrote: On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: On 11/17/2012 10:29 PM, Greg KH wrote: I see an entertaining fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked udev all those years ago, maybe I still should...) That was a placeholder name. If you checked before you sent your email, you would see that we had settled on eudev. The name change still doesn't make it any less entertaining :) What does the e stand for? That is a common question. Someone associated with Canonical suggested that e stand for embedded. Others consider the eu prefix to be the greek root for true. Honestly, we don't care. It is just a name. I wouldn't pick embedded as the embedded world is now using systemd as it meets their requirements much better than anything else :) As far as I know, they are using busybox. But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release The goal is to replace systemd as upstream for Gentoo Linux, its derivatives and any distribution not related to RedHat. Wait, really? You want to replace systemd? Then why are you starting at udev and not systemd? What is wrong with systemd that it requires a fork? All other distros seem to be participating in the development process of systemd quite well, what is keeping Gentoo developers from also doing the same? What are your goals, specifically, in detail. Is there any way that the answer to your inquiry would result in a productive conversation where you would not attempt to dictate what we do? I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. A consequence of being open source means that everyone can see what we do, so people are able to send us their opinions on things that have not been officially announced, much like this project. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. I can say the same about the manner in which these changes were introduced. Ripping them out to get the codebase back into a state from which we are comfortable moving forward is the only sane way of dealing with them. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. At some point, someone has to enforce a form of structure where further change
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 17/11/2012 21:00, Richard Yao wrote: I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Can I step in and just as you to shut your mouth? It might not be the most tactful way to say it, but the more you write, the more Gentoo as a whole project is looking like a circus... the AGILE bullshit was really the last straw for me trying to keep quiet... -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: On 11/17/2012 10:39 PM, Greg KH wrote: Anyway, I now see a _very_ dangerous commit in the Copyright branch that better not get merged into the tree, as it's wrong, and illegal under all countries that follow the normal body of Copyright Law. It should be removed right now before someone gets into trouble, not the least of which would be the orginization that the copyright is now being attributed to. Come on people, this is basic copyright law, it's not something radically new. It's something that _all_ software developers should know, either from school, or any company they have ever worked at. Please fix this now. klondike discussed the copyright branch changes with robbat2 before they started and there was no problem at the time. We have retained all copyright notices and looking at the branch, I find nothing objectionable. Why is this getting a Gentoo Foundation copyright in the first place? Why is that necessary? greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:05 AM, Diego Elio Pettenò wrote: On 17/11/2012 21:00, Richard Yao wrote: I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Can I step in and just as you to shut your mouth? It might not be the most tactful way to say it, but the more you write, the more Gentoo as a whole project is looking like a circus... the AGILE bullshit was really the last straw for me trying to keep quiet... I would appreciate it if people would avoid harassing others that decide to develop things different than what they want to use. Read GLEP 0039: http://www.gentoo.org/proj/en/glep/glep-0039.html We do not need to justify the need for our project before it is announced or even after it is announced. It is free to conflict with RedHat's systemd project. If we find next year that we can reconcile with Kay Sievers and Lennart Poettering, then we are free to do that. These projects need not be long term commitments. There is absolutely no reason for this harassment. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an official Gentoo project without this being discussed in an open manner? A consequence of being open source means that everyone can see what we do, so people are able to send us their opinions on things that have not been officially announced, much like this project. Given that the Gentoo Foundation is claiming copyright on this project now, not announcing it seems a bit rude to the rest of us who make up this foundation, don't you think? That's not very open :( I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. I can say the same about the manner in which these changes were introduced. Ripping them out to get the codebase back into a state from which we are comfortable moving forward is the only sane way of dealing with them. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. At some point, someone has to enforce a form of structure where further change occurs in a well defined manner and change because we can is rejected as being pointless. That is what we want and that is what we feel that our users want. Ok, what is that structure you are wishing were present? What problems do you have with systemd on a technical level that are not being addressed? What technical problems with udev do you have that caused this to be forked? What problems are you wishing to solve, and what goals do you have by doing all of this? Have you studied the problem area for booting, process monitoring, system isolation, device creation and notification, persistant naming, multiple users with multiple displays, and the like, and found that Linux is lacking in this area? If so, I would love to learn more, as I want Linux, and Gentoo, to succeed. Without knowing the problems you are having, there's no way anyone will ever change. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 17/11/2012 21:13, Richard Yao wrote: I would appreciate it if people would avoid harassing others that decide to develop things different than what they want to use. Read GLEP 0039: And I would appreciate if you'd avoid making us look like a bunch of wannabes, by using buzzwords like waterfall and agile just because you read about them in a book or something. Really, I'm not caring a single bit about what you want to do with your free time, and I'm not telling you to shut your project down (as I can't). Heck I'm the cause of its existence I'm afraid. But you've made Gentoo the laughing stock of the Linux world over the past couple of days, and now you come up with this? Please get a clue, please. I appreciate your enthusiasm, but you're going quite a tad overboard, and looks like your concept of development is I'm not sure of what I'm doing, but I'm doing it anyway. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:20 AM, Diego Elio Pettenò wrote: But you've made Gentoo the laughing stock of the Linux world over the past couple of days, and now you come up with this? Please get a clue, please. Arguably, the fact that others forced our hand before we were ready lead to the widespread attention. With that said, responses to Gentoo have always been mixed, but I have seen far more positive responses than negative responses and I am quite happy with the result. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 17/11/2012 21:26, Richard Yao wrote: Arguably, the fact that others forced our hand before we were ready lead to the widespread attention. With that said, responses to Gentoo have always been mixed, but I have seen far more positive responses than negative responses and I am quite happy with the result. Then keep being happy for the result, but leave it to someone else to speak. Because Robin is not making us looking like a bunch of idiots, you are, with your replies. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:13:37AM -0500, Richard Yao wrote: We do not need to justify the need for our project before it is announced or even after it is announced. It is free to conflict with RedHat's systemd project. If we find next year that we can reconcile with Kay Sievers and Lennart Poettering, then we are free to do that. These projects need not be long term commitments. systemd is not a Red Hat project at all. It just happens to have some of the developers of it working for them. If that is their job to develop it or not, is unknown to all of us. Also, in the beginning of systemd, a lot of the code, and research, was done by someone working for a distro different than Red Hat. systemd is a freedesktop.org project, that is all, please don't play this as a distro-vs-distro issue, otherwise it will end up looking like it is a Gentoo vs. the world thing, and I, as a long-term Gentoo developer, do not want that at all. So, I'll say this again, why is this project getting the copyright of the Gentoo Foundation? Is it an official project of Gentoo in some manner? And, to all of you who have emailed me privately saying they don't want to talk about this on-list, that's what gentoo-core is for, I'd be glad to take it there if you feel gentoo-dev is to public for stuff like this. Otherwise, this is opensource, we do development in the open, not in private. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:19 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an official Gentoo project without this being discussed in an open manner? We are in the process of getting started. If you read my original email, you would know that the announcement was supposed to occur relatively soon. The reason I sent it was because the Gentoo Council meeting required something be sent sooner than we were ready. A consequence of being open source means that everyone can see what we do, so people are able to send us their opinions on things that have not been officially announced, much like this project. Given that the Gentoo Foundation is claiming copyright on this project now, not announcing it seems a bit rude to the rest of us who make up this foundation, don't you think? That's not very open :( Actually, that is one developer who asked if he could join the project and thought that he was being helpful. I insisted that those changes go into a branch because I felt that they could cause problems. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) See the following: https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. I can say the same about the manner in which these changes were introduced. Ripping them out to get the codebase back into a state from which we are comfortable moving forward is the only sane way of dealing with them. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. The result of what the existing people have been doing has been the equivalent of throwing stuff against the wall for many of us. We have decided to try doing things ourselves to see if we can do better. We think we can. At some point, someone has to enforce a form of structure where further change occurs in a well defined manner and change because we can is rejected as being pointless. That is what we want and that is what we feel that our users want. Ok, what is that structure
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:35 AM, Greg KH wrote: So, I'll say this again, why is this project getting the copyright of the Gentoo Foundation? Is it an official project of Gentoo in some manner? One developer who asked to join our project as we are in the process of getting started thought he would be helpful by working on this. He is behind the commit that you find to be objectionable and I am going to let him fix it. As for being an official project, we will make an official announcement soon. Others wanted to have a repository that people could use on their systems before we did an announcement to avoid a paper launch. I agreed with their sentiments, which is why it is unannounced at this time. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 11/18/2012 12:20 AM, Diego Elio Pettenò wrote: I appreciate your enthusiasm, but you're going quite a tad overboard, and looks like your concept of development is I'm not sure of what I'm doing, but I'm doing it anyway. It's human nature to wake up one day and exclaim, I will develop X!, and then go off and do so without any formal planning or even a rough idea of how to start. Sometimes it works, and sometimes it doesn't. Sometimes, you just roll dice. That's what keeps life interesting. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 17/11/2012 21:52, Joshua Kinard wrote: It's human nature to wake up one day and exclaim, I will develop X!, and then go off and do so without any formal planning or even a rough idea of how to start. Sometimes it works, and sometimes it doesn't. Sometimes, you just roll dice. That's what keeps life interesting. Agreed. Heck I've worked for how long on Gentoo/FreeBSD? And did I have a plan for most of that? Not really. But I didn't go around saying that I was not following the waterfall or developing AGILE. I was just doing shit that sounded cool and looked nice. Did I expect much out of it? Not really. At the end we did get something, in particular we got OpenRC out of it, which has served us very well for quite a while, and we never planned for it before that. But it was just luck, and I wouldn't brag about it. That's why I'm not saying please shut down the project, just please keep ryao away from the keyboard. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: nvidia-driver.eclass
On 18/11/12 07:47, Doug Goldstein (cardoe) wrote: cardoe 12/11/18 05:47:02 Modified: nvidia-driver.eclass Log: Update to support a new legacy series Revision ChangesPath 1.16 eclass/nvidia-driver.eclass file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?r1=1.15r2=1.16 Index: nvidia-driver.eclass === RCS file: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- nvidia-driver.eclass22 Aug 2011 04:46:32 - 1.15 +++ nvidia-driver.eclass18 Nov 2012 05:47:02 - 1.16 @@ -1,6 +1,6 @@ # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.15 2011/08/22 04:46:32 vapier Exp $ +# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.16 2012/11/18 05:47:02 cardoe Exp $ # @ECLASS: nvidia-driver.eclass # @MAINTAINER: @@ -30,9 +30,21 @@ 031b 031c 0320 0321 0322 0323 0324 0325 0326 0327 0328 032a 032b 032c 032d \ 0330 0331 0332 0333 0334 0338 033f 0341 0342 0343 0344 0347 0348 034c 034e +drv_304x=0040 0041 0042 0043 0044 0045 0046 0047 0048 004e 0090 0091 0092 \ +0093 0095 0098 0099 009d 00c0 00c1 00c2 00c3 00c8 00c9 00cc 00cd 00ce 00f1 \ +00f2 00f3 00f4 00f5 00f6 00f8 00f9 0140 0141 0142 0143 0144 0145 0146 0147 \ +0148 0149 014a 014c 014d 014e 014f 0160 0161 0162 0163 0164 0165 0166 0167 \ +0168 0169 016a 01d0 01d1 01d2 01d3 01d6 01d7 01d8 01da 01db 01dc 01dd 01de \ +01de 01df 0211 0212 0215 0218 0221 0222 0240 0241 0242 0244 0245 0247 0290 \ +0291 0292 0293 0294 0295 0297 0298 0299 029a 029b 029c 029d 029e 029f 02e0 \ +02e1 02e2 02e3 02e4 038b 0390 0391 0392 0393 0394 0395 0397 0398 0399 039c \ +039e 03d0 03d1 03d2 03d5 03d6 0531 0533 053a 053b 053e 07e0 07e1 07e2 07e3 \ +07e5 + mask_96xx==x11-drivers/nvidia-drivers-97.0.0 mask_71xx==x11-drivers/nvidia-drivers-72.0.0 mask_173x==x11-drivers/nvidia-drivers-177.0.0 +mask_173x==x11-drivers/nvidia-drivers-305.0.0 I don't know the eclass, but shouldn't this say mask_304x here ? # @FUNCTION: nvidia-driver-get-card # @DESCRIPTION: @@ -71,6 +83,13 @@ return 0; fi done + + for drv in $drv_304x; do + if [ x$card = x$drv ]; then + echo $mask_304x; + return 0; + fi + done done echo ;
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: nvidia-driver.eclass
On Sun, Nov 18, 2012 at 12:18 AM, Samuli Suominen ssuomi...@gentoo.org wrote: On 18/11/12 07:47, Doug Goldstein (cardoe) wrote: cardoe 12/11/18 05:47:02 Modified: nvidia-driver.eclass Log: Update to support a new legacy series Revision ChangesPath 1.16 eclass/nvidia-driver.eclass file : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16view=markup plain: http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?rev=1.16content-type=text/plain diff : http://sources.gentoo.org/viewvc.cgi/gentoo-x86/eclass/nvidia-driver.eclass?r1=1.15r2=1.16 Index: nvidia-driver.eclass === RCS file: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v retrieving revision 1.15 retrieving revision 1.16 diff -u -r1.15 -r1.16 --- nvidia-driver.eclass22 Aug 2011 04:46:32 - 1.15 +++ nvidia-driver.eclass18 Nov 2012 05:47:02 - 1.16 @@ -1,6 +1,6 @@ # Copyright 1999-2011 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 -# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.15 2011/08/22 04:46:32 vapier Exp $ +# $Header: /var/cvsroot/gentoo-x86/eclass/nvidia-driver.eclass,v 1.16 2012/11/18 05:47:02 cardoe Exp $ # @ECLASS: nvidia-driver.eclass # @MAINTAINER: @@ -30,9 +30,21 @@ 031b 031c 0320 0321 0322 0323 0324 0325 0326 0327 0328 032a 032b 032c 032d \ 0330 0331 0332 0333 0334 0338 033f 0341 0342 0343 0344 0347 0348 034c 034e +drv_304x=0040 0041 0042 0043 0044 0045 0046 0047 0048 004e 0090 0091 0092 \ +0093 0095 0098 0099 009d 00c0 00c1 00c2 00c3 00c8 00c9 00cc 00cd 00ce 00f1 \ +00f2 00f3 00f4 00f5 00f6 00f8 00f9 0140 0141 0142 0143 0144 0145 0146 0147 \ +0148 0149 014a 014c 014d 014e 014f 0160 0161 0162 0163 0164 0165 0166 0167 \ +0168 0169 016a 01d0 01d1 01d2 01d3 01d6 01d7 01d8 01da 01db 01dc 01dd 01de \ +01de 01df 0211 0212 0215 0218 0221 0222 0240 0241 0242 0244 0245 0247 0290 \ +0291 0292 0293 0294 0295 0297 0298 0299 029a 029b 029c 029d 029e 029f 02e0 \ +02e1 02e2 02e3 02e4 038b 0390 0391 0392 0393 0394 0395 0397 0398 0399 039c \ +039e 03d0 03d1 03d2 03d5 03d6 0531 0533 053a 053b 053e 07e0 07e1 07e2 07e3 \ +07e5 + mask_96xx==x11-drivers/nvidia-drivers-97.0.0 mask_71xx==x11-drivers/nvidia-drivers-72.0.0 mask_173x==x11-drivers/nvidia-drivers-177.0.0 +mask_173x==x11-drivers/nvidia-drivers-305.0.0 I don't know the eclass, but shouldn't this say mask_304x here ? # @FUNCTION: nvidia-driver-get-card # @DESCRIPTION: @@ -71,6 +83,13 @@ return 0; fi done + + for drv in $drv_304x; do + if [ x$card = x$drv ]; then + echo $mask_304x; + return 0; + fi + done done echo ; Thank you for finding the flaw in my mail filter rule to delete these e-mails when they hit gentoo-dev, where I'm directly addressed. In the future if you want these e-mails to go through you'll have to e-mail me directly without CCing the list or sending it to the list. Just doing my part to help clean up pointless e-mails to -dev one mail filter at a time. That said, you are actually correct. -- Doug Goldstein
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:35:22AM -0500, Richard Yao wrote: On 11/18/2012 12:19 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an official Gentoo project without this being discussed in an open manner? We are in the process of getting started. If you read my original email, you would know that the announcement was supposed to occur relatively soon. The reason I sent it was because the Gentoo Council meeting required something be sent sooner than we were ready. The announce later, act first seems like a new move for the Gentoo Council to be taking. Is this really an official act that the council is approving? Why wait to announce a project that is being hosted on a Gentoo account, with Gentoo Foundation copyrights on them? I don't understand the delay. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. Are you using busybox to load your kernel modules? Are you saying that this is something that will be required here? Or is this change because you want to use busybox to load your modules? If so, why not just use mdev instead of udev at all? That's what mdev was created for, busybox-like systems that don't want the heavy udev on them. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? So we will now have 3 different Linux kernel loaders floating around? What's wrong with using kmod in the first place? What does it do that is so wrong? And again, back to my original point above, you have reintroduced the problem that kmod solved. How is that good? With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. The result of what the existing people have been doing has been the equivalent of throwing stuff against the wall for many of us. Really? What, specifically, is wrong with the existing systemd solution that you have a problem with? Specifics please, otherwise they can't be fixed. We have decided to try doing things ourselves to see if we can do better. We think we can. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. Have you studied the problem area for booting, process monitoring, system isolation, device creation and notification, persistant naming, multiple users with multiple displays, and the like, and found that Linux is lacking in this area? If so, I would love to learn more, as I want Linux, and Gentoo, to succeed. Without knowing the problems you are having, there's no way anyone will
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:49 AM, Greg KH gre...@gentoo.org wrote: On Sun, Nov 18, 2012 at 12:35:22AM -0500, Richard Yao wrote: On 11/18/2012 12:19 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an official Gentoo project without this being discussed in an open manner? We are in the process of getting started. If you read my original email, you would know that the announcement was supposed to occur relatively soon. The reason I sent it was because the Gentoo Council meeting required something be sent sooner than we were ready. The announce later, act first seems like a new move for the Gentoo Council to be taking. Is this really an official act that the council is approving? Why wait to announce a project that is being hosted on a Gentoo account, with Gentoo Foundation copyrights on them? I don't understand the delay. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. Are you using busybox to load your kernel modules? Are you saying that this is something that will be required here? Or is this change because you want to use busybox to load your modules? If so, why not just use mdev instead of udev at all? That's what mdev was created for, busybox-like systems that don't want the heavy udev on them. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? So we will now have 3 different Linux kernel loaders floating around? What's wrong with using kmod in the first place? What does it do that is so wrong? And again, back to my original point above, you have reintroduced the problem that kmod solved. How is that good? With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. The result of what the existing people have been doing has been the equivalent of throwing stuff against the wall for many of us. Really? What, specifically, is wrong with the existing systemd solution that you have a problem with? Specifics please, otherwise they can't be fixed. We have decided to try doing things ourselves to see if we can do better. We think we can. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. Have you studied the problem area for booting, process monitoring, system isolation, device creation and notification, persistant naming, multiple users with multiple displays, and the like, and found that Linux is lacking in this area? If so, I would love to learn more, as I want Linux, and Gentoo, to
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 10:49 PM, Greg KH gre...@gentoo.org wrote: On Sun, Nov 18, 2012 at 12:35:22AM -0500, Richard Yao wrote: On 11/18/2012 12:19 AM, Greg KH wrote: On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. I am afraid that I have to disappoint you. If we were using the waterfall model, I could outline some very nice long term goals for you, but we are doing AGILE development, so long term goals have not been well defined. Some short term goals have been defined, but I imagine that you are already familiar with them. I suggest asking again after our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an official Gentoo project without this being discussed in an open manner? We are in the process of getting started. If you read my original email, you would know that the announcement was supposed to occur relatively soon. The reason I sent it was because the Gentoo Council meeting required something be sent sooner than we were ready. The announce later, act first seems like a new move for the Gentoo Council to be taking. Is this really an official act that the council is approving? Why wait to announce a project that is being hosted on a Gentoo account, with Gentoo Foundation copyrights on them? I don't understand the delay. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h Having a builtin is a good idea, but the implementation as a mandatory dependency on kmod is not. The plan is to reintroduce it as an optional dependency, so that distributions (and Gentoo users) that do not want it can avoid it. None of us want to force dependencies on others and there is no need for this one. You do realize that you didn't really drop the dependency at all, right? kmod does not exist on my system and eudev builds without a problem. Are you using busybox to load your kernel modules? Are you saying that this is something that will be required here? Or is this change because you want to use busybox to load your modules? If so, why not just use mdev instead of udev at all? That's what mdev was created for, busybox-like systems that don't want the heavy udev on them. I am thinking of writing my own busybox-style code to handle module loading in the builtin when the configure script is told not to build with kmod. Does this not avoid the dependency? So we will now have 3 different Linux kernel loaders floating around? What's wrong with using kmod in the first place? What does it do that is so wrong? And again, back to my original point above, you have reintroduced the problem that kmod solved. How is that good? With that said, Linux distributions are victims of people continually trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. The result of what the existing people have been doing has been the equivalent of throwing stuff against the wall for many of us. Really? What, specifically, is wrong with the existing systemd solution that you have a problem with? Specifics please, otherwise they can't be fixed. So I'm pretty sure the concerns were laid out in other threads. 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. We have decided to try doing things ourselves to see if we can do better. We think we can. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:59 PM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: On 17/11/2012 21:52, Joshua Kinard wrote: It's human nature to wake up one day and exclaim, I will develop X!, and then go off and do so without any formal planning or even a rough idea of how to start. Sometimes it works, and sometimes it doesn't. Sometimes, you just roll dice. That's what keeps life interesting. Agreed. Heck I've worked for how long on Gentoo/FreeBSD? And did I have a plan for most of that? Not really. But I didn't go around saying that I was not following the waterfall or developing AGILE. I was just doing shit that sounded cool and looked nice. Did I expect much out of it? Not really. At the end we did get something, in particular we got OpenRC out of it, which has served us very well for quite a while, and we never planned for it before that. But it was just luck, and I wouldn't brag about it. Diego I'm going to have to call you out here. You've so far in this thread claimed you were the reason behind the eudev project and now claim you're behind OpenRC. Sounds like bragging to me. That's why I'm not saying please shut down the project, just please keep ryao away from the keyboard. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ -- Doug Goldstein
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release That approach would be viable if upstream were co-operative or gave a damn about anybody else. They've broken people's sytems with the new and improved udev, and claimed that people's systems were already broken. Kay Sievers got Linus angry enough to go on a rant. See https://lkml.org/lkml/2012/10/3/484 So now, after you've dismissed the patch that did the equivalent fix in udev (Ming Lei's patch basically disabled your idiotic and wrong sequence number test for firmware loading), you say it's ok to bypass udev entirely, because that is more robust. Kay, you are so full of sh*t that it's not funny. You're refusing to acknowledge your bugs, you refuse to fix them even when a patch is sent to you, and then you make excuses for the fact that we have to work around *your* bugs, and say that we should have done so from the very beginning. Yes, doing it in the kernel is more robust. But don't play games, and stop the lying. It's more robust because we have maintainers that care, and because we know that regressions are not something we can play fast and loose with. If something breaks, and we don't know what the right fix for that breakage is, we *revert* the thing that broke. So yes, we're clearly better off doing it in the kernel. Not because firmware loading cannot be done in user space. But simply because udev maintenance since Greg gave it up has gone downhill. And as for Gentoo expecting co-operation, see Lennart's attitude http://lists.linuxaudio.org/pipermail/linux-audio-dev/2009-June/023434.html If you don't do RT development or doing RT development only for embedded cases, or if you are a Gentoo-Build-It-All-Myself-Because-It-Is-So-Much-Faster-And-Need-To-Reinvent-The-Wheel-Daily-And-Configurating-Things-Is-Awesome-Guy then it doesn't mean anything for you. In short, the systemd-udev people are hard to work with in general, and have a dislike for Gentoo. Good luck with getting patches accepted by them. Oh, and if _anyone_ thinks that changing udev is going to solve the no separate /usr without an initrd issue, I have a bridge I want to sell them. If udev-systemd merely broke a filesystem layout that functioned very well in linux for 2 decades, you would not be seeing this rebellion. udev-systemd is also breaking media drivers. The entire thread https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay has screwed up udev. You participated in that thread. I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? Wrong. You're assuming that Sievers/Poettering would allow that. They've made no secret of their disdain of standalone udev. Everybody has seen Poettering's post... http://lists.freedesktop.org/archives/systemd-devel/2012-August/006066.html (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.) How many people have read Siever's post? http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html We promised to keep udev properly *running* as standalone, we never told that it can be *build* standalone. And that still stands. We never claimed, that all the surrounding things like documentation always fully match, if only udev is picked out of systemd. I would welcome if people stop reading that promise into the announcement, it just wasn't written there. You (the former udev maintainer) are saying that a standalone udev *WITHOUT SYSTEMD* will always be possible. The current maintainer is saying that isn't necessarily true. Who do you expect me to believe? You also wrote... And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) Some people are finding firmware drivers not loading, and the cards not functioning. Don't you consider that a regression? Seiver's response is basically the same as for people with separate /usr; telling them that they have to re-write their drivers to accomadate the new and improved udev. And people whose drivers don't fail entirely now get a 60-second delay while udev times out before loading the firmware in another manner. Those people have seen their bootup times increased by a full minute. Do you not consider that a regression? As I posted
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 17/11/2012 23:05, Doug Goldstein wrote: Diego I'm going to have to call you out here. You've so far in this thread claimed you were the reason behind the eudev project and now claim you're behind OpenRC. Sounds like bragging to me. Please don't put words in my mouth. I'm not behind any of the two and I don't want to be. So let me qualify. For eudev — I told ryao to go and fork udev. This is not exactly the effect I was aiming for, but okay, it's done, I should have spoken more carefully (kinda like Robin said regarding the copyright earlier). As for OpenRC — Roy's the guy who made it and there's no way I'm going to take that from him. But it did come out of Gentoo/FreeBSD (which, by the way, was not my brainchild, but ka0ttic's afaict — I just had more time in my hands at that point that I made it viable), as it was basically a rewrite of baselayout 2 to be independent of the Linux code. Most people don't even know that, and I'm fine with that. Sometimes you do shit because you feel like doing it, and sometimes it brings you results, other times it brings you nothing... it's just shit you're doing, which is fine but makes you neither bad nor good. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:05 PM, Walter Dnes waltd...@waltdnes.org wrote: As I posted elsewhere, working on a project based on hate only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago. The Xfree86 people generated a lot of hate, just like Sievers and Poettering. Xorg hasn't burned out yet. Let's be fair. The Xorg fork was done by a lot of really competent professional developers who had been developing XFree86 for a long time.
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 1:25 AM, Matt Turner matts...@gentoo.org wrote: On Sat, Nov 17, 2012 at 11:05 PM, Walter Dnes waltd...@waltdnes.org wrote: As I posted elsewhere, working on a project based on hate only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago. The Xfree86 people generated a lot of hate, just like Sievers and Poettering. Xorg hasn't burned out yet. Let's be fair. The Xorg fork was done by a lot of really competent professional developers who had been developing XFree86 for a long time. And it was made because it had become almost impossible to work with the main developer of XFree86; not because of hate, but by very clear and valid technical reasons The systemd+udev project instead has code contributed by every major Linux distribution, and many small ones. Even Ubuntu hasn't talked about forking udev, and they keep sending patches, even with their staunch commitment to Upstart. This is what a developer from Arch Linux (which has just made the decision to move to systemd) has to say about it: ... systemd is a cross-distro project: every major and many, many minor distros have had people contributing to systemd. last i heard even two debian devs have commit access to the repo, among many others. systemd upstream is very accommodating of different needs and different use-cases (as long as they are presented on technical grounds) and have been a pleasure to work with so far. We are getting the joint experience of a lot of people/projects who have worked on different init systems for a long time, I think this is one of the most important features one could have. https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 Seeing some people comparing udev to XFree86 is one of the more bizarre things coming out from this fork, and that's saying. However, I agree with Doug that anyone should code whatever they want to code. Who knows, maybe something interesting would come off from this fork, and it certainly doesn't affect us happy Gentoo+systemd+udev users. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 02:05:39AM -0500, Walter Dnes wrote: On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release That approach would be viable if upstream were co-operative or gave a damn about anybody else. They've broken people's sytems with the new and improved udev, and claimed that people's systems were already broken. Kay Sievers got Linus angry enough to go on a rant. See https://lkml.org/lkml/2012/10/3/484 Yes, I know all about the firmware issue with media drivers. It's now resolved and fixed, in two different ways (the kernel now loads firmware directly, and on older kernels, udev has fixed the issue.) So that's no longer an issue for anyone. In short, the systemd-udev people are hard to work with in general, and have a dislike for Gentoo. Good luck with getting patches accepted by them. The fact that Gentoo is alone in wanting to build udev, without systemd dependencies being on the system, is something that if I were the systemd maintainer, I would reject. It's also a pretty simple set of patches that Gentoo can keep around if it's really a serious issue for people. Oh, and if _anyone_ thinks that changing udev is going to solve the no separate /usr without an initrd issue, I have a bridge I want to sell them. If udev-systemd merely broke a filesystem layout that functioned very well in linux for 2 decades, you would not be seeing this rebellion. Note, a separate /usr has been broken for a while now, udev is just pointing the issue out. And again, if you want a separate /usr, just use an initrd, the solution is simple. udev-systemd is also breaking media drivers. The entire thread https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay has screwed up udev. You participated in that thread. Again, this is now resolved, no need to keep beating it :) How many people have read Siever's post? http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html We promised to keep udev properly *running* as standalone, we never told that it can be *build* standalone. And that still stands. We never claimed, that all the surrounding things like documentation always fully match, if only udev is picked out of systemd. I would welcome if people stop reading that promise into the announcement, it just wasn't written there. You (the former udev maintainer) are saying that a standalone udev *WITHOUT SYSTEMD* will always be possible. The current maintainer is saying that isn't necessarily true. Who do you expect me to believe? They are saying it as well. It's Gentoo that is unique in wanting to build it without the rest of the systemd package as well. Two different things here. You also wrote... And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) Some people are finding firmware drivers not loading, and the cards not functioning. Don't you consider that a regression? Again, been a bug for 6 months, hit by very few people, now resolved, not an issue. Seiver's response is basically the same as for people with separate /usr; telling them that they have to re-write their drivers to accomadate the new and improved udev. And people whose drivers don't fail entirely now get a 60-second delay while udev times out before loading the firmware in another manner. Those people have seen their bootup times increased by a full minute. Do you not consider that a regression? Again, now resolved, not an issue. You need to have a real solid goal in place in order to be able to keep this up in the long-run. Otherwise you are going to burn yourself out, and end up alienating a lot of people along the way. Howsabout a standalone udev, with no dependancies on systemd, and it won't break people's systems? If that is the goal, great, it would be wonderful if someone would say that. But from looking at the commits so far in the repo, it really doesn't look like that is the goal. Or if it is, it's getting there in a very odd way. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:52 PM, Greg KH gre...@gentoo.org wrote: On Sun, Nov 18, 2012 at 02:05:39AM -0500, Walter Dnes wrote: On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release That approach would be viable if upstream were co-operative or gave a damn about anybody else. They've broken people's sytems with the new and improved udev, and claimed that people's systems were already broken. Kay Sievers got Linus angry enough to go on a rant. See https://lkml.org/lkml/2012/10/3/484 Yes, I know all about the firmware issue with media drivers. It's now resolved and fixed, in two different ways (the kernel now loads firmware directly, and on older kernels, udev has fixed the issue.) So that's no longer an issue for anyone. In short, the systemd-udev people are hard to work with in general, and have a dislike for Gentoo. Good luck with getting patches accepted by them. The fact that Gentoo is alone in wanting to build udev, without systemd dependencies being on the system, is something that if I were the systemd maintainer, I would reject. It's also a pretty simple set of patches that Gentoo can keep around if it's really a serious issue for people. Oh, and if _anyone_ thinks that changing udev is going to solve the no separate /usr without an initrd issue, I have a bridge I want to sell them. If udev-systemd merely broke a filesystem layout that functioned very well in linux for 2 decades, you would not be seeing this rebellion. Note, a separate /usr has been broken for a while now, udev is just pointing the issue out. And again, if you want a separate /usr, just use an initrd, the solution is simple. udev-systemd is also breaking media drivers. The entire thread https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay has screwed up udev. You participated in that thread. Again, this is now resolved, no need to keep beating it :) How many people have read Siever's post? http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html We promised to keep udev properly *running* as standalone, we never told that it can be *build* standalone. And that still stands. We never claimed, that all the surrounding things like documentation always fully match, if only udev is picked out of systemd. I would welcome if people stop reading that promise into the announcement, it just wasn't written there. You (the former udev maintainer) are saying that a standalone udev *WITHOUT SYSTEMD* will always be possible. The current maintainer is saying that isn't necessarily true. Who do you expect me to believe? They are saying it as well. It's Gentoo that is unique in wanting to build it without the rest of the systemd package as well. Two different things here. You also wrote... And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) Some people are finding firmware drivers not loading, and the cards not functioning. Don't you consider that a regression? Again, been a bug for 6 months, hit by very few people, now resolved, not an issue. Seiver's response is basically the same as for people with separate /usr; telling them that they have to re-write their drivers to accomadate the new and improved udev. And people whose drivers don't fail entirely now get a 60-second delay while udev times out before loading the firmware in another manner. Those people have seen their bootup times increased by a full minute. Do you not consider that a regression? Again, now resolved, not an issue. You need to have a real solid goal in place in order to be able to keep this up in the long-run. Otherwise you are going to burn yourself out, and end up alienating a lot of people along the way. Howsabout a standalone udev, with no dependancies on systemd, and it won't break people's systems? If that is the goal, great, it would be wonderful if someone would say that. But from looking at the commits so far in the repo, it really doesn't look like that is the goal. Or if it is, it's getting there in a very odd way. The project is like a day old, chillax. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: 1) systemd-udev will require systemd. Stated by the systemd maintainers themselves as a thing they want to do in the future. Some users don't want to use systemd. We could go into detail as to why; but I think that is not as important as one may think. The point is that the desire is there, and thusly there are users who want to make other systems (namely openrc) work. People like openrc. My VMs for instance, boot reasonably quickly. Booting 5 seconds faster may be super duper, but not at the cost of an existing reliable solution. So is this the goal? Great, someone say that then, that's all I'm asking for here. That's wonderful, seriously. But why is this suddenly an official Gentoo project? When did that happen, and why? Why not just do a normal project and if it matures and is good enough, then add it to the distro like all other packages are added. My main point here is the fact that this is now being seen as an act by Gentoo, the distro / foundation. And that happened in private, without any anouncement. Which is not good on many levels. I'm unsure on what grounds you disapprove. People start (and abandon) projects often in Gentoo. Suddenly you dislike one such project and object to this practice? Certainly if we had to get some sort of Foundation consensus (for anything) nothing would happen. We can't even get more than 40% of foundation members to vote. I object if this is seen as a Gentoo blessed fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Also, the whole issue with the copyrights is very serious, for the reasons I've stated before. Don't mess with copyrights, developers, and companies, take them very serious, as they are the basis for our licenses. thanks, greg k-h
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
On 05/09/2012 06:36 PM, Greg KH wrote: On Wed, May 09, 2012 at 08:51:37PM +0200, Fabio Erculiani wrote: I foresee a new udev fork then. Please feel free to do so, the code has been open since the first day I created it. Remember, forks are good, there's nothing wrong with them, I strongly encourage people to do them if they wish to, it benefits everyone involved. If udev is going to end up like avahi is, this is *highly* probable. That's an odd transition... With avahi is ... I actually mean, one single tarball blob depending on the whole world and its solar system and galaxy. Hyperbole, how nice :( Please stop throwing lennartware at people. FailAudio has been enough, thanks. The use of these terms is both rude and totally uncalled for. You should be ashamed of yourself. Seriously, that's unacceptable behavior from anyone. No one forces you to use any of this software if you do not want to. There are lots of other operating systems out there, feel free to switch to them if you do not like the way this one is working out, no one is stopping you. But for you to disparage someone who has given immense bodies of work to the community, and you, for free, is horrible behavior and needs to stop right now. greg k-h Greg, would you clarify what you meant by this? Your recent comments suggest to me that you did not mean what I thought you meant. signature.asc Description: OpenPGP digital signature