[gentoo-dev] Re: [PATCH] Check for USE_PYTHON - PYTHON_TARGETS sync.

2012-11-17 Thread Mike Gilbert
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.

2012-11-17 Thread Michał Górny
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

2012-11-17 Thread Brian Dolbec
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Robin H. Johnson
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Diego Elio Pettenò
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Diego Elio Pettenò
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Diego Elio Pettenò
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Richard Yao
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)

2012-11-17 Thread Joshua Kinard
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)

2012-11-17 Thread Diego Elio Pettenò
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

2012-11-17 Thread Samuli Suominen

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

2012-11-17 Thread Doug Goldstein
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Doug Goldstein
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)

2012-11-17 Thread Alec Warner
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)

2012-11-17 Thread Doug Goldstein
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)

2012-11-17 Thread Walter Dnes
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)

2012-11-17 Thread Diego Elio Pettenò
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)

2012-11-17 Thread Matt Turner
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)

2012-11-17 Thread Canek Peláez Valdés
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)

2012-11-17 Thread Greg KH
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)

2012-11-17 Thread Alec Warner
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)

2012-11-17 Thread Greg KH
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]

2012-11-17 Thread Richard Yao
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