[gentoo-dev] Re: [gentoo-kernel] Dropping stable USE flags for 4.14

[Greg KH]

On Sat, Dec 30, 2017 at 03:14:45PM +0100, Greg KH wrote:
> On Fri, Dec 29, 2017 at 10:58:28PM +0900, Alice Ferrazzi wrote:
> > 
> > - Unbootable system with CONFIG_MCORE2 [6]

This turns out to be a gentoo-specific bug, not much upstream can do
about a broken compiler that some profiles are using :(

greg k-h

[gentoo-dev] Re: [gentoo-kernel] Dropping stable USE flags for 4.14

[Greg KH]

On Fri, Dec 29, 2017 at 10:58:28PM +0900, Alice Ferrazzi wrote:
> Hello,
> 
> We have recently started the stabilization of gentoo-sources-4.14.8.
> 
> Very soon we received reports regarding broken e1000e driver [1] and moved
> to gentoo-sources-4.14.8-r1.
> 
> Since then we keep receiving new problems related to 4.14.x kernel:
> 
> - IPSec is broken [2]
> 
> - Change in 4.14.9 broke nVIDIA driver [3]
> 
> - Colors on console are broken with some Radeon HD cards [4]
> 
> - BUG report on boot [5]
> 
> - Unbootable system with CONFIG_MCORE2 [6]
> 
> - ...more bugs [7]
> 
> While not all issues are present in gentoo-sources-4.14.8-r1 we are
> concerned about the current stability/quality of the 4.14.x branch in
> general and don't feel comfortable recommending 4.14.x branch for general
> use at the moment. But that's what a stable USE flag means for most
> Gentoo users.
> 
> So, for now, we have decided to drop gentoo-sources-4.14.x stable keywords.
> We will keep watching 4.14 branch and once the stability/quality matches
> our requirements we will restart stabilization.

Be careful, you don't want to drop back to older kernels with known
security issues that are already fixed in the latest 4.14.y release.

Most of the above issues have resolutions already, and yes, 4.14 is
being a bit more "temperamental", sorry, it will pay off in the end...

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 05:08:13PM -0700, Daniel Campbell wrote:
> Forgive me, but I don't see why people have so much trouble with
> copyright wrt Gentoo. I've simply assumed anything I wrote for Gentoo
> would be attributed to me via git log information and/or metadata.xml
> and should I leave Gentoo, Gentoo keeps the rights to it since I'm
> contributing to it. Nothing stops me from pushing ebuilds to my personal
> overlay *and* the primary Gentoo tree.

Note, lots of people (i.e. almost anyone who is employed in the US), are
in the situation where the copyright ownership of your contributions are
not owned by yourself, so you can not give the copyright away to the
Gentoo Foundation without an explicit legal document from that owner
granting that copyright transfer (or additional ownership.)

So this is a real issue, and a problem, for many of our developers
(myself included), which is why many many years ago some of us worked to
get that copyright ownership document removed.

> With a DCO, it greatly complicates things. Would my right to keep my
> contributions in an overlay be infringed upon? What would change if we
> switch to this?

Nothing, it just explicitly calls out that you know the contribution you
are making is allowed and under the license of the file/project you are
contributing to.  It does not change the ownership of the copyright of
the contribution at all.  It's a very simple document, I think I've
written more words in this email than the whole document has, I suggest
reading it for all of the details.

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 04:41:37PM +0200, Ulrich Mueller wrote:
> >>>>> On Thu, 27 Oct 2016, Greg KH wrote:
> 
> >> Also, I wouldn't completely exclude that we need to change the
> >> wording at some later point. Therefore, we may indeed consider
> >> taking the DCO from the Linux source tree which is distributed
> >> under the GPL-2, instead of the non-free version ("changing it is
> >> not allowed") from developercertificate.org. Their wording is
> >> identical except for the preamble.
> 
> > You can't change the text of a license and call it the same thing,
> > which is why that wording is there (same wording is in the GPL), so
> > don't think that by pointing at the one in the kernel source tree
> > that changes anything...
> 
> Sure, the text shouldn't be changed without changing the name. I guess
> that's common sense, because otherwise it would be confusing.
> 
> > And I would _strongly_ not recomment changing the wording without
> > consulting with a license lawyer, you can mess things up really
> > quickly by changing stuff.
> 
> So the DCO was devised by a license lawyer?

It was created with one, but that was not the only contributor of it.

> TBH, I find it less than optimal. It is an enumeration with all its
> items at equal level, but its meaning is "I certify ((a || b || c) &&
> d)". That is, structure doesn't follow contents there, and at first
> glance the "or" (or its absence) at the end of each item can be easily
> missed.

See, you have to be careful and read the whole thing, words can be
tricky :)

good luck!

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote:
> On Thu, Oct 27, 2016 at 9:29 AM, Greg KH <gre...@gentoo.org> wrote:
> >
> > You can't change the text of a license and call it the same thing,
> 
> So is the objection mainly to calling it a "Developer Certificate of Origin?"

That's one objection of mine, yes.  The other being you can't just take
almost all of the original text and still call it the same thing, when
it obviously isn't, and the document says you can't do that :)

> I'd think that the title of a legal document falls more under
> trademark law than copyright law.  That is why the FSF publishes the
> "GNU GENERAL PUBLIC LICENSE" and not just the "GENERAL PUBLIC
> LICENSE."  The former has far more trademark protection than the
> latter.

Do you see that term trademarked anywhere?  I will go file for one if
you really insist on it, but really, think this through please.

> > which
> > is why that wording is there (same wording is in the GPL), so don't
> > think that by pointing at the one in the kernel source tree that changes
> > anything...
> 
> The Linux Foundation published a version of their DCO under the GPL,
> which we would of course abide by.  The fact that they published it
> elsewhere with a different license doesn't mean that we can't re-use
> the version published under the GPL.

How well does "plain text" work under the GPL?  Go on, I've been down
that path before, it's well-worn, we'll be here when you get back... :)

> If we aren't changing anything that does raise the question of why not
> just use the Linux DCO, v1.1 or whatever it is at, incorporated by
> reference.  I do think we have the legal right to fork it since it was
> effectively published by the Linux Foundation under the GPL, but that
> doesn't require us to fork it.

Please just use the one as-published.

thanks,

greg k-h

Re: [gentoo-dev] newsitem: important fstab update

[Greg KH]

On Wed, Oct 26, 2016 at 11:04:34AM +0200, Michał Górny wrote:
> Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard  
> napisał(a):
> >On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> >wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need
> >to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>  
> >>  They probably will.
> >> 
> >>> If this is about the udev-settle issue for OpenRC, I would urge you
> >to
> >>> reconsider that.
> >>  
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the
> >safer
> >>  route.
> >> 
> >>  William
> >> 
> >
> >I take it us museum relics still using jurassic-era device names like
> >/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
> >device
> >naming gets any more complicated than using UUID's.  What's next,
> >saving the
> >serial numbers of discovered disks in an overly-complicated
> >key/value-based
> >non-SQL database format?
> 
> Wait full you-know-who notices that disk device names are not predictable and 
> fixes that.

disk device names have never been predictable, don't get comfortable :)

If you rely on them, you need to be aware that they can change at
times...

good luck!

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Sat, Oct 22, 2016 at 06:47:04PM +0200, Ulrich Mueller wrote:
> >>>>> On Sat, 22 Oct 2016, Greg KH wrote:
> 
> > On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
> >> This is from the last policy draft:
> >> https://dev.gentoo.org/~rich0/copyrightpolicy.xml
> 
> > Why redraft the already-useful DCO that is out there for you to use
> > as-is:
> > http://developercertificate.org/
> 
> > As you copied the text, be sure to give proper reference to who owns
> > the copyright of that text please, you just can't rename it and
> > claim it as your own :)
> 
> In fact, Rich *does* give credit to Linux:
> "The DCO is based on the
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SubmittingPatches
> Linux Kernel DCO"

Credit is nice, but you have to remember copyright issues :)

> Also, I wouldn't completely exclude that we need to change the wording
> at some later point. Therefore, we may indeed consider taking the DCO
> from the Linux source tree which is distributed under the GPL-2,
> instead of the non-free version ("changing it is not allowed") from
> developercertificate.org. Their wording is identical except for the
> preamble.

You can't change the text of a license and call it the same thing, which
is why that wording is there (same wording is in the GPL), so don't
think that by pointing at the one in the kernel source tree that changes
anything...

And I would _strongly_ not recomment changing the wording without
consulting with a license lawyer, you can mess things up really quickly
by changing stuff.

Again, just point to the one we have, use the web site (which better not
go away), and copy it locally if you feel it somehow will.

thanks,

greg k-h

Re: [gentoo-dev] Dealing with GitHub Pull Requests the easy way

[Greg KH]

On Wed, Oct 19, 2016 at 09:19:36AM -0400, Rich Freeman wrote:
> On Wed, Oct 19, 2016 at 8:32 AM, Kent Fredric  wrote:
> >
> > So if this commit was to get teleported to a different repo,
> > --signoff by would be preserved, as an intermediate between these two.
> >
> > So I think the intent for this is "X reviewed these changes for Gentoo
> > and takes responsibility for them"
> >
> > what text you use to convey that is irrelevant, as long as its used
> > consistently and everyone understands what the text means.
> >
> 
> Actually, the text matters a great deal, which is why projects that
> care about copyright tend to have an explicit DCO.  One for Gentoo was
> in the works but has stalled somewhat (to be fair, it was stalled
> originally because we were waiting for git to come along).  It
> probably makes sense to at least get that into effect even if we don't
> have a long-term strategy around copyright attribution and so on.
> 
> The last draft DCO was:
> Gentoo DCO 1.0 By making a contribution to this project, I certify
> that: (a) The contribution was created in whole or in part by me and I
> have the right to submit it under the open source license indicated in
> the file; or (b) The contribution is based upon previous work that, to
> the best of my knowledge, is covered under an appropriate open source
> license and I have the right under that license to submit that work
> with modifications, whether created in whole or in part by me, under
> the same open source license (unless I am permitted to submit under a
> different license), as indicated in the file; or (c) The contribution
> was provided directly to me by some other person who certified (a),
> (b) or (c) and I have not modified it. (d) I understand and agree that
> this project and the contribution are public and that a record of the
> contribution (including all personal information I submit with it,
> including my sign-off) is maintained indefinitely and may be
> redistributed consistent with this project or the open source
> license(s) involved.
> 
> This is from the last policy draft:
> https://dev.gentoo.org/~rich0/copyrightpolicy.xml

Why redraft the already-useful DCO that is out there for you to use
as-is:
http://developercertificate.org/

As you copied the text, be sure to give proper reference to who owns the
copyright of that text please, you just can't rename it and claim it as
your own :)

thanks,

greg k-h

Re: [gentoo-dev] On banning merge commits

[Greg KH]

On Sun, May 08, 2016 at 01:44:43PM +0800, cbergst...@pathscale.com wrote:
> Don't be crazy - I know many developer groups which dislike merge
> commits. That nonlinear work flow is just a mess long term.

Really?  What "mess" does it cause?

Are things harder to bisect?  Harder to determine what came before what?
Harder to do future development?  Harder because it is unfamiliar
compared to the cvs workflow?

Or just "messier" when you look at the graph of the tree?

What is the _real_ reason that you don't like merges?

thanks,

greg k-h

Re: [gentoo-dev] package.mask vs ~arch

[Greg KH]

On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote:
 On Mon, 30 Jun 2014 09:25:27 -0400
 Rich Freeman ri...@gentoo.org wrote:
 
  Agree 100%.  I'm taking about masking things that HAVEN'T BEEN TESTED
  AT ALL.  The maintainer knows that they compile, and that is it.
 
 Developers who HAVEN'T [...] TESTED AT ALL and still commit their
 changes to the tree should immediately hand in their toys and leave
 the project.

What toys?  Were we given some when we became developers?  If I had some
I'd send mine back in, but as I don't, I'll keep committing stable
kernel ebuilds that I never test as no one seems to be complaining...

greg never make absolute statements k-h

Re: [gentoo-dev] Docker 1.0.0 masked for no known reason?

[Greg KH]

On Sun, Jun 29, 2014 at 05:17:36AM +0200, Jeroen Roovers wrote:
 On Sat, 28 Jun 2014 19:58:22 -0700
 Greg Kroah-Hartman gre...@gentoo.org wrote:
 
  Hi Markos,
  
  I was wondering why docker 1.0.0 wasn't seeming to get updated on my
  boxes recently, despite me commiting the update to the cvs tree, and
  Tianon noticed that it was masked at the moment:
  
  # Markos Chandras hwoar...@gentoo.org (03 May 2014)
  # Masked for further testing
 
 Oh, that good old masked for testing, which actually never works.

Exactly.

 If you want testing to be done, you don't mask stuff. Also, no bug
 number referenced. All you get is someone's e-mail address.

So, given a total lack of testing by anyone, I might as well just
remove the mask, so it can actually be done given that people are
wanting the latest Docker release, especially due to the security fixes
in it over the one that is currently not masked...

thanks,

greg k-h

Re: [gentoo-dev] New virtuals for libudev and libgudev

[Greg KH]

On Sat, Mar 29, 2014 at 09:27:18PM +0100, Francisco Blas Izquierdo Riera 
(klondike) wrote:
 Hi!
 
 El 29/03/14 05:13, Samuli Suominen escribió:
  I took the liberty to unbreak the tree for you. Don't ever touch my
  packages again unless
  they are broken.
 Udev is broken:
 * They have known off by one string handling errors on their libraries,
 the developers were warned of that but have chosen to ignore the issue.
 The issue is still on
 http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/strxcpyx.c
 on the function size_t strpcpyf(char **dest, size_t size, const char
 *src, ...) which can overflow the string boundaries in some case. This
 issue keeps coming up from time to time thanks to their nice efforts
 for cahnging the whole thing instead of fixing bugs. Also after a year
 nothing has been done.

I must have missed it, where was this reported?

And where is the off-by-one issue here?  What am I missing in the code?

 * They keep losing cohesion
 (http://en.wikipedia.org/wiki/Cohesion_%28computer_science%29) by
 inserting more and more unrelated software into Udev/systemd. This helps
 things like the above happen again.

That has nothing to do with a logic bug.

 * They have the bad habit of recoding functions that are already
 provided by their only supported c library. This helps things like the
 above happen.ç

Where are these functions in glibc that should have been used instead?

greg k-h

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Greg KH]

On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
 At the end of the day we have one codebase which is engineered and
 another which has evolved.

I'll take an evolved codebase over engineered anyday.

You do realize that is exactly why Linux has succeeded, right?  The
kernel has evolved, and was never engineered.  There's lots people
should be learning from biology...

So you are using the benifits of evolution right now on your system,
don't knock it, it's proven to work.

greg k-h

Re: [gentoo-dev] [OT] pkgcore bikeshed (was Portage team)

[Greg KH]

On Tue, Jan 14, 2014 at 12:42:00AM +0700, C. Bergström wrote:
 On 01/14/14 12:37 AM, Greg KH wrote:
 On Mon, Jan 13, 2014 at 04:15:37PM +0700, C. Bergström wrote:
 At the end of the day we have one codebase which is engineered and
 another which has evolved.
 I'll take an evolved codebase over engineered anyday.
 
 You do realize that is exactly why Linux has succeeded, right?  The
 kernel has evolved, and was never engineered.  There's lots people
 should be learning from biology...
 
 So you are using the benifits of evolution right now on your system,
 don't knock it, it's proven to work.
 I'll bite - While I don't think nature stopped to properly design interfaces
 along the way. I bet you Linus wouldn't agree with your comment very much.

I don't think you have been paying attention much, I'm directly quoting
Linus:
Linux is evolution, not intelligent design - Linus

There are many more statements exactly like this from him over the
years, do a bit of research to dig them up.

 1) I expect quite a bit of time has gone into (Solaris and Linux) kernel
 interfaces

Time doesn't mean they haven't evolved.

 2) Any larger or invasive changes require quite a bit of planning, review
 and testing. (Possibly with tests (public/private) to cover a large amount
 of the new/existing feature

And we always get it wrong, so they evolve into something that later on
works.

Seriously, this is how the very system you are using has been created,
it's a well-documented fact (look at our changelogs for details.)

sorry,

greg k-h

Re: [gentoo-dev] Re: Portage QOS

[Greg KH]

On Fri, Jan 10, 2014 at 04:10:18PM +0400, Igor wrote:
 Hello Chris,
 
 Friday, January 10, 2014, 1:08:39 AM, you wrote:
 
  Right here is the big problem: you're not looking at this from the
  perspective of the average Gentoo developer. We don't care about market
  share. We don't care whether we're on top for another few years. There
  are several forks of Gentoo. I doubt most devs care about them. I
  personally know that we're not going to compete with Debian, which has a
  huge contributor, or Ubuntu or Red Hat, which have whole companies
  behind them. You're selling this as if you're selling to a company which
  wants to be on the top of the market and beating out competitors, and
  that's not what we are. We are a source-based distro that requires some
  effort from users, and people want that or they don't want it.
  What we need is a vote YES or NO. If you against it - vote NO. It's
  perfectly normal, if there would be no NO there would be no need voting.
 
 Thank you for you opinion. 
 
 The competition in open source world is much harder than with
 commercial software. 3 commercial systems share 96% of the users.

Really?  What market?  Last I looked, more Linux systems were being run
on processors than any other single kernel.

Don't confuse desktops for all of computing.

 1,6% of the users are shared by 296 Linux distros

Really?  And what is the number of total users you are talking about
here?

 You may think that you're outside this rules but the competition is natural 
 on the planet and Gentoo is certainly competing weather you want it or not.

No, we aren't competing with anyone, please realize that this is not how
Linux distros and the ecosystem works at all.

Remember, Red Hat is Gentoo's engineering team :)

good luck,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote:
 On Fri, 9 Aug 2013 06:38:56 -0400
 Rich Freeman ri...@gentoo.org wrote:
 
  My sense is that Greg is using the term security bugs to refer to
  implementation errors that could be exploited to obtain unintended
  access to a system.  Using this definition, any bug could be a
  security bug, and figuring this out is about as easy as figuring out
  whether a particular move is a good or bad one in chess.
 
 That's indeed not what I understood; Greg, was this your though?

Yes, that's close to the issue.  Any bug could be classified as a
security bug if you wish to do so, so there's no need to call out some
fixes and not others, as odds are, you will miss some, and give people
the wrong impression they are safe when they are really not.

  I don't follow the kernel closely, but my guess is that they stay
  well-ahead of CVE most of the time.  I'd certainly say that any
  project should clearly document which releases incorporate fixes to
  CVEs - perhaps the kernel already does this.
 
 Currently I don't see this; so, my assumption was that it does not
 currently happen, as far as I have seen this appears to happen on an
 individual basis, but I assume not everyone does report to CVE.
 
 Reporting to CVE is much more work than it takes to tag a commit; so,
 as you can see tagging here might be a benefit to lift the work to
 other people that have more time for reporting it as a CVE, etc...

The kernel usually has things fixed it in long before a CVE is asked
for.  So there's no way to go back in time and add CVEs to commits.

thanks,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote:
 On Thu, 8 Aug 2013 15:32:45 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
   On Wed, 7 Aug 2013 15:44:34 -0700
   Greg KH gre...@gentoo.org wrote:
   
I am not going to impose an additional burden on developers to get
their patches into the stable kernel releases like this, sorry.
   
   As I said, it's not your task; so, what you impose doesn't matter.
  
  What do you mean by that?  I am the upstream stable kernel maintainer,
  as well as a subsystem maintainer.  I don't want to do the extra work
  of tagging all of my stable patches with this type of information, I
  can barely keep on top of the ones that I have to mark for stable as
  it is.
 
   ...
 
  But I will argue that you can not annotate them properly.  That is
  imposing more work on me, a subsystem maintainer, that I will not do.
 
 Not just stable patches, but any patch; why delay till after the fact?
 
 Tagging at the time of committing is just a few extra characters.

And don't people do that already with their changelog comments in the
kernel?

No, not in any offical format, but that's been rejected numerous
times.  Just read the commits to find out what is resolved, if anything
is known at that point in time, if you are curious.


Hint, the line between a bugfix and a security fix is not always
obvious, or even known at all.
   
   The developer knows; and if not, he can probably just mark it as a
   fix.
  
  Ok, so you have just now divided everything into fix or feature.
  As the feature patches are quite obvious, everything else must be
  fix. So why tag anything, your classification is already done for
  you.
 
 If they are obvious, what's so hard abut tagging them?

Because it's extra work that is pointless.  You do realize just how many
patches go into the kernel every day, right?  Doing anything to a patch
will slow things down, and given the huge number of the, odds are a
percentage will be wrong anyway.

 No classification is done if there is no single command to obtain them.

I don't understand what you mean by this.

And what about all of the fixes I merge in, that _are_ really
security fixes, yet we do not want to shout it out to the world
at the moment?
   
   For known security bugs, being aware of a fix earlier helps.
  
  I don't understand what you mean here at all.
 
 Neither do I understand what you mean by not shouting it out; so,
 unless you have argumentation to not shout it out, I'm in the belief
 that the faster one is able to apply a security fix, the more secure he
 is as a result. If not shouting it out makes things more secure, then
 please state me how and why; because it only gives attackers more time.

The kernel team does not explicitly call out security fixes when they go
into the kernel for a variety of good reasons, all of which have been
argued and debated numerous times for many years.  See the linux-kernel
mailing list archives if you are curious, I'm not going to get into that
argument here, except to point out that the current behavior is probably
not going to change.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote:
 On Fri, 9 Aug 2013 12:30:42 -0700
 Greg KH gre...@gentoo.org wrote:
 
  ...  Just read the commits to find out what is resolved, ...
 
  ... Because it's extra work that is pointless.  ...
  
   No classification is done if there is no single command to obtain
   them.
  
  I don't understand what you mean by this.
 
 What I'm suggesting is based on the need for a digest; we both know,
 that a lot of people are not going to read every single commit to
 classify them, if everyone has to do that that causes a lot of double
 work which could be easily spared out at the source. Alternatively,
 we are in need of a separate resource outside of the kernel infra that
 is interested in classifying commits this way, I'm not sure whether
 there is anybody doing such thing.

There is not, and anyone who has tried to do such a thing quickly gave
up as it was a very difficult task.  But please, if you feel like you
can succeed where others have failed, please do so, I know a lot of
people would like someone to do this type of work for them.

 Undoubtedly you heard thoughts similar to the above many times before;
 but I'm new to this train of thoughts, so I'm unaware of those debates.

Yes, it comes up every few months by people who are just suddenly
thinking of it.  Please give us some kind of credit, we have been
dealing with this issue for well over a decade, and have come to the
existing state based on our experience and knowledge of what works best
for us, and hopefully, the rest of the community.

thanks,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote:
 On Wed, 7 Aug 2013 16:19:43 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
   Greg KH wrote:
See above for why it is not easy at all, and, why even if we do
know some fixes are security ones, we would not tag them as such
anyway.
   
   I think this supports the argument that the better kernel is always
   the one with the most fixes.
 
 Define better; because 3.10.0 has also been worse than the last 3.9
 release in some ways, despite it having more fixes than the last 3.9.

How was it worse?  You don't seem to define that either :)

Yes, there are always going to be bugs and regressions, but as long as
we are fixing them more than we are making them, we are doing ok.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote:
 On Wed, 7 Aug 2013 15:44:34 -0700
 Greg KH gre...@gentoo.org wrote:
 
  On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
 
   Some kind of annotation with tags would make this kind of thing
   easy; I'm not saying it is your task to apply such annotations to
   commits, but it would rather be the task of the person who makes an
   individual patch.
  
  I am not going to impose an additional burden on developers to get
  their patches into the stable kernel releases like this, sorry.
 
 As I said, it's not your task; so, what you impose doesn't matter.

What do you mean by that?  I am the upstream stable kernel maintainer,
as well as a subsystem maintainer.  I don't want to do the extra work of
tagging all of my stable patches with this type of information, I can
barely keep on top of the ones that I have to mark for stable as it is.

As the stable kernel maintainer, all I ask for is that subsystem
maintainers tag their patches for the stable tree.  If I have questions
about them, I ask, otherwise I accept them.

  Can you judge which bug fixes are security ones, and which are not?
  And do so for 100+ patches a week?  52 weeks a year?  Great, please
  do so, as no one has ever been able to do this (others have tried.)
 
 Yes, that is easy on the premise that they are annotated.

But I will argue that you can not annotate them properly.  That is
imposing more work on me, a subsystem maintainer, that I will not do.

  Hint, the line between a bugfix and a security fix is not always
  obvious, or even known at all.
 
 The developer knows; and if not, he can probably just mark it as a fix.

Ok, so you have just now divided everything into fix or feature.  As
the feature patches are quite obvious, everything else must be fix.
So why tag anything, your classification is already done for you.

  And what about all of the fixes I merge in, that _are_ really security
  fixes, yet we do not want to shout it out to the world at the moment?
 
 For known security bugs, being aware of a fix earlier helps.

I don't understand what you mean here at all.

greg k-h

Re: [gentoo-dev] Gnome Stabilization 3.6 or 3.8

[Greg KH]

On Thu, Aug 08, 2013 at 09:40:00PM +0100, Mike Auty wrote:
 On 08/08/13 11:38, Samuli Suominen wrote:
  i'm not volunteering but I never really got why our GNOME
  maintainers insisted on staying with it instead of going with the
  distribution after it was clear logind is a dead end on non-systemd
  systemd
 
 Ok,
 
 So there's lots of people that don't want systemd.  Can't we group
 together and have some kind of an affect on upstream?

Become upstream developers and create fixes to remove the dependancy
either by working on openrc features to emulate the same things that
systemd has that GNOME requires, or split things out of GNOME so that it
does not require systemd dependencies.

But to complain to upstream without providing patches is a bit futile,
don't you think?  That's not how open source projects work, we all know
that.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote:
 On Wed, 24 Jul 2013 16:09:11 -0700
 Greg KH gre...@gentoo.org wrote:
 
  Please
  tell me exactly how you are going to evaluate which fixes I make are
  security fixes, and you know which to pick and choose from.
 
 Some kind of annotation with tags would make this kind of thing easy;
 I'm not saying it is your task to apply such annotations to commits, but
 it would rather be the task of the person who makes an individual patch.

I am not going to impose an additional burden on developers to get their
patches into the stable kernel releases like this, sorry.

Can you judge which bug fixes are security ones, and which are not?  And
do so for 100+ patches a week?  52 weeks a year?  Great, please do so,
as no one has ever been able to do this (others have tried.)

Hint, the line between a bugfix and a security fix is not always
obvious, or even known at all.

And what about all of the fixes I merge in, that _are_ really security
fixes, yet we do not want to shout it out to the world at the moment?
How would one properly tag that?

 This would benefit multiple people; it would benefit users to know the
 amount of patches that are security and code fixes, new features and
 see them separately. It would also benefit distributions and system
 admins to filter them out, they could for instance drop new feature
 patches so they just get the fixes they need.
 
 It puts the power in the user's hands; allowing them to evaluate, pick
 and choose according to their own demands and needs.
 
 Implementation wise, I don't think this is any harder than the already
 existing annotations; work wise, adding a tag is easy to do.

See above for why it is not easy at all, and, why even if we do know
some fixes are security ones, we would not tag them as such anyway.

So that kind of makes that whole idea fall apart, right?  :)

sorry,

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Thu, Aug 08, 2013 at 12:50:32AM +0200, Peter Stuge wrote:
 Greg KH wrote:
  See above for why it is not easy at all, and, why even if we do know
  some fixes are security ones, we would not tag them as such anyway.
 
 I think this supports the argument that the better kernel is always
 the one with the most fixes.

That's what us kernel developers have been saying for 10+ years, nice to
see it's finally getting some traction :)

 Rather than separating bug fixes from security fixes maybe it's
 wiser to think about separating fixes from features - this may
 be easier, but still not neccessarily easy.

For stable kernel releases, that type of thing should be quite easy for
someone to do, if they want to do it, as the only type of features I
take for them are new device ids.

But I fail to see how marking 5 patches out of 100 as features is
really doing to do much for anyone, do you?

thanks,

greg k-h

Re: [gentoo-dev] newsitem: Kernel Team vanilla-sources policy

[Greg KH]

On Sun, Aug 04, 2013 at 12:53:35AM -0400, Mike Pagano wrote:
 
 All,
 Here is the vanilla-sources non stablizing policy news item.
 If all goes well, this will be committed to the tree  on 08/07 UTC.

Thanks for writing this all up, much appreciated.

greg k-h

Re: [gentoo-dev] Vanilla sources stabilization policy change

[Greg KH]

On Wed, Jul 24, 2013 at 04:40:38PM -0400, Rich Freeman wrote:
 Also, not all fixes are equal.  The ones that are the biggest concern
 are security fixes.

How do you _know_ which fixes are security fixes?

 If you tell me that the kernel has a new exploit
 2x/week then I'll start to wonder when the kernel team started
 outsourcing to MS.  Most fixes provide no benefit to most users.
 Upgrading kernels on Gentoo is not automatic either, especially if you
 have an initramfs, complex configuration, modules in outside packages
 (nvidia, virtualization, etc), and so on.

I'm releasing, on the average, 3 new kernel versions a week, with 100+
patches in them (for different branches.)  Sometimes more.  Please tell
me exactly how you are going to evaluate which fixes I make are security
fixes, and you know which to pick and choose from.

Trust me, it's a hard problem, people have tried it in the past, and
failed horribly :)

 It just seems like we should be able to get by without a semiweekly
 kernel upgrade on our stable branch.

You want me to slow down and do releases in larger chunks then?  Hah,
not a chance...

good luck,

greg k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

Almost all of this portion of the thread is off-topic for gentoo-dev, so
I'll leave it alone, and will be more than willing to take it up
somewhere else it is on-topic for, like linux-kernel, if you want to.

But, there is one thing I do want to ask/comment on, as it is relevant
to users of Gentoo:

On Mon, Jul 01, 2013 at 11:29:39PM -0400, Richard Yao wrote:
  4. Risk of patent trolls
 
  I know of no kernel patches outside of the tree because of this, do you?
 
 There is compatibility code for DOS long filenames in fat that is no
 longer in-tree because of this.

I remember the conversations that a number of us had a few years ago
about this potential issue, but do not see any in-kernel changes that
were ever made because of that.  Could you point me at the changes that
were made that were accepted into the kernel.org tree?

thanks,

gerg k-h

[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 04:41:49PM +0200, Tom Wijsman wrote:
 This problem is not only visible for patches, but also in the config.
 
 Meet CONFIG_DEVTMPFS; forget to enable it, greet a failing boot. We're
 telling users to enable it in some places, in the handbook it's a single
 line you must read, on the Wiki it's kind of missing unless you are
 luckily on the right page, on the Quick Install book it is missing too.

This is not the only build option that users must enable to get a
booting system by far.  So why single this one out?

 Q: I don't want feature X? Please don't add the patch!
 
 A: It's optional, don't enable it in your menu config.
 
 Q: What about my stable server? I really don't want to run this stuff!
 
 A: These options would depend on !CONFIG_VANILLA or CONFIG_EXPERIMENTAL

What is CONFIG_VANILLA?  I don't see that in the upstream kernel tree at
all.

CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to have
a problem with this.

which would be disabled by default, therefore if you keep this option
the way it is on your stable server; it won't affect you.

Not always true.  Look at aufs as an example.  It patches the core
kernel code in ways that are _not_ accepted upstream yet.  Now you all
are running that modified code, even if you don't want aufs.

Note, I'm just using aufs as an example here, I'm not commenting on the
quality of the code, or why it is modifying the core kernel at all, I
happen to run it on some of my own servers, but your feelings might
differ.

In other words, genpatches stay as stable as before; unless you
explicitly toggle options that intentionally make it unstable.

As pointed out above, this is not always true.

Also, as others stated, the hardened patches also don't always only
touch areas covered by non-config-selected portions of the kernel.

Mix and match your external kernel patches at your own risk, what you
are suggesting does make it easy for users, but I bet it will be a
huge support issue for the already-overworked gentoo kernel developers,
the combinations just are too big to test and guarantee working.

good luck,

greg stick to the vanilla-sources k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
   Q: What about my stable server? I really don't want to run this
   stuff!
   
   A: These options would depend on !CONFIG_VANILLA or
   CONFIG_EXPERIMENTAL
  
  What is CONFIG_VANILLA?  I don't see that in the upstream kernel tree
  at all.
  
  CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to
  have a problem with this.
 
 Earlier I mentioned 2) These feature should depend on a non-vanilla /
 experimental option. which is an option we would introduce under the
 Gentoo distribution menu section.

Distro-specific config options, great :(

  which would be disabled by default, therefore if you keep this
   option the way it is on your stable server; it won't affect you.
  
  Not always true.  Look at aufs as an example.  It patches the core
  kernel code in ways that are _not_ accepted upstream yet.  Now you all
  are running that modified code, even if you don't want aufs.
 
 Earlier I mentioned 3) The patch should not affect the build by
 default.; if it does, we have to adjust it to not do that, this is
 something that can be easily scripted. It's just a matter of embedding
 each + block in the diff with a config check and updating the counts.

Look at aufs as a specific example of why you can't do that, otherwise,
don't you think that the aufs developer(s) wouldn't have done so?

The goal of don't touch any other kernel code is a very good one, but
not always true for these huge out-of-tree kernel patches.  Usually that
is the main reason why these patches aren't merged upstream, because
those changes are not acceptable.

So be very careful here, you are messing with things that are rejected
by upstream.

greg k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 02:30:51PM -0400, Anthony G. Basile wrote:
 Tom, you already know my opinion because we discussed it.  I'm all
 for it.  Just a reminder: there's always problems somewhere in the
 kernel which can be triggered by various options.  The kernel is not
 one big take it or leave it chunk of code, but many chunks
 selectable by Kconfig with the exception of course of the core.  The
 best we can do wrt to BFQ and other risky patches is mark these
 options as EXPERIMENTAL.  I was going to say depend on
 CONFIG_EXPERIMENTAL in Kconfig, but this is deprecated.  See
 scripts/checkpatch.pl
 
 Use of CONFIG_EXPERIMENTAL is deprecated. For alternatives, see
 https://lkml.org/lkml/2012/10/23/580;

It's flat out gone now in the 3.10 kernel release, so if you use it,
your code just will never be enabled.

greg k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote:
 On Mon, 1 Jul 2013 14:09:57 -0500
 Matthew Summers quantumsumm...@gentoo.org wrote:
  If the patchset patches the kernel's core, it doesn't matter what
  CONFIG_* option is set the core kernel code _has_now_been_changed_.
  This is the crux of the argument, I believe. AUFS simply being one
  example of this. I'm sure there are others.
 
 As per my response to that point, this statement is no longer true.
 
 Let me re-iterate it here:
 
 Earlier I mentioned 3) The patch should not affect the build by
 default.; if it does, we have to adjust it to not do that, this is
 something that can be easily scripted. It's just a matter of embedding
 each + block in the diff with a config check and updating the counts.

Wonderful, now you are maintaining a patch that looks nothing like the
one created by the original developers, nor tested by anyone else other
than gentoo developers.

There's a reason that no other distro does this.

Playing fast-and-loose with kernel patches is a fun thing to do, but
really, why?  Users love doing this type of thing, but the interactions
of different kernel patches with core subsystems is almost always a
non-trivial thing.

I'm not saying not to do this, but consider this a friendly warning that
this is going to be a MAJOR pain to maintain and debug over the
long-run.

But hey, what do I know?  It's not like I've ever done this before and
had the experience of the resulting fall-out that took years to recover
from on user's production systems, causing a number of enterprise Linux
companies to swear that they would never do this type of thing again...

Personally, I wish you luck, it will push the sane users to the
vanilla-sources tree, which I strongly encourage :)

greg kids, get off my lawn! k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 05:17:07PM -0400, Anthony G. Basile wrote:
 On 07/01/2013 03:23 PM, Greg KH wrote:
 On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
 Q: What about my stable server? I really don't want to run this
 stuff!
 
 A: These options would depend on !CONFIG_VANILLA or
 CONFIG_EXPERIMENTAL
 What is CONFIG_VANILLA?  I don't see that in the upstream kernel tree
 at all.
 
 CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to
 have a problem with this.
 Earlier I mentioned 2) These feature should depend on a non-vanilla /
 experimental option. which is an option we would introduce under the
 Gentoo distribution menu section.
 Distro-specific config options, great :(
 
 I'm not sure what you mean by distro-specific,

See later mention of CONFIG_GENTOO_EXPERIMENTAL, that is what I was
referring to.

 but suppose people
 want BFQ? Why can't we have it in gentoo-sources.  It is totally
 disabled by not selecting CONFIG_BFQ.  Selecting it is no different
 than emerging pf-sources with the same other options ported over.

Until you run into a patch that modifies code outside of it's CONFIG_
option, like the aufs example I pointed out.

 By your logic, we should not distribut pf-sources either.  The truth
 of the matter is, there are forks of the vanilla kernel out there. Are
 you suggesting we distribute none of them?

That's a total false argument, the discussion here is about our main
gentoo-kernel tree, not one of our many domain-specific kernel versions
that are maintained separately.

 NOTE: hardened-sources is its own world.  There is not level of
 turning on/off options that get you back to a vanilla kernel.

Agreed, which keeps that from being merged into this tree, hopefully :)

thanks,

greg k-h

Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.

[Greg KH]

On Mon, Jul 01, 2013 at 09:36:21PM -0400, Richard Yao wrote:
 On 07/01/2013 03:23 PM, Greg KH wrote:
  On Mon, Jul 01, 2013 at 08:45:16PM +0200, Tom Wijsman wrote:
  Q: What about my stable server? I really don't want to run this
  stuff!
 
  A: These options would depend on !CONFIG_VANILLA or
  CONFIG_EXPERIMENTAL
 
  What is CONFIG_VANILLA?  I don't see that in the upstream kernel tree
  at all.
 
  CONFIG_EXPERIMENTAL is now gone from upstream, so you are going to
  have a problem with this.
 
  Earlier I mentioned 2) These feature should depend on a non-vanilla /
  experimental option. which is an option we would introduce under the
  Gentoo distribution menu section.
  
  Distro-specific config options, great :(
  
 which would be disabled by default, therefore if you keep this
  option the way it is on your stable server; it won't affect you.
 
  Not always true.  Look at aufs as an example.  It patches the core
  kernel code in ways that are _not_ accepted upstream yet.  Now you all
  are running that modified code, even if you don't want aufs.
 
  Earlier I mentioned 3) The patch should not affect the build by
  default.; if it does, we have to adjust it to not do that, this is
  something that can be easily scripted. It's just a matter of embedding
  each + block in the diff with a config check and updating the counts.
  
  Look at aufs as a specific example of why you can't do that, otherwise,
  don't you think that the aufs developer(s) wouldn't have done so?
 
 I am accquainted with the developer of a stackable filesystem developer.
 According to what he has told me in person offline, the developers on
 the LKML cannot decide on how a stackable filesystem should be
 implemented. I was told three different variations on the design that
 some people liked and others didn't, which ultimately kept the upstream
 kernel from adopting anything. I specifically recall two variations,
 which were doing it as part of the VFS and doing it as part of ext4. If
 you want to criticize stackable filesystems, would you lay out a
 groundwork for getting one implemented upon which people will agree?

I was not criticising stackable filesystems at all, nor the aufs code,
which I personally run on some of my own systems.

I agree that the upstream kernel development of stackable filesystems
has been all over the place, with seemingly not much guidance on how to
get things merged properly.  Being that I am not part of the subset of
the kernel development community, I am in no position to lay any
groundwork out at all.

And note, this is totally off-topic from this thread.

My main point is that if Gentoo wants to start maintaining out-of-tree
kernel patches, and modifying them, the maintenance nightmare is going
to be huge.  Been there, done that, have way too many t-shirts
commemorating it, and never want to do it again.

  The goal of don't touch any other kernel code is a very good one, but
  not always true for these huge out-of-tree kernel patches.  Usually that
  is the main reason why these patches aren't merged upstream, because
  those changes are not acceptable.
 
 I was under the impression that there were several reasons for patches
 not being merged upstream:
 
 1. Lack of signed-off

No distro will accept code that does not have a signed-off-by line,
otherwise they might get into trouble, as that implies the patch is not
properly licensed, right?

 2. Code drop that no one will maintain

Agreed.

 3. Subsystem maintainers saying no simply because they do not like
 insert non-technical reason here.

That is very rare and usually the subsystem maintainer can be poked to
resolve this.

 4. Risk of patent trolls

I know of no kernel patches outside of the tree because of this, do you?

 5. Actual technical reasons

That's the majority of the reasons patches aren't accepted.

 Only some of the patches were rejected. Others were never submitted. The
 PaX/GrSecurity developers prefer their code to stay out-of-tree. As one
 of the people hacking on ZFSOnLinux, I prefer that the code be
 out-of-tree.

There's also a small legal issue with the zfs code that might prevent it
from being merged :)

 That is because fixes for other filesystems are either held back by a
 lack of system kernel updates or held hostage by regressions in newer
 kernels on certain hardware.

I have never heard this being a reason for keeping code upstream, what
do you mean by it?

 With that said, being in Linus' tree does not make code fall under some
 golden standard for quality. There are many significant issues in code
 committed to Linus' the kernel, some of which have been problems for
 years. Just to name a few:

bug reports snipped

The fact that bugs happen in 16 million lines of kernel code, moving at
a rate that is orders of magnitude faster than any other software
development project, is not news to anyone, it's a fact of life.

The fact that we fix them when they are found is the important thing,
don't you agree

Re: [gentoo-dev] Temporary DevRel actions for CoC violations

[Greg KH]

On Wed, Jun 19, 2013 at 06:35:49PM +0100, Markos Chandras wrote:
 For me, this problem is critical. Devrel is working on formalizing a new
 policy, and we will announce news on this soon. In the meantime, to
 prevent further escalations,  I will use my lead powers to request
 immediate bans whenever I see one of you violate the CoC[2] and ignore
 the previous warnings.

Thank you for stepping up and working to address this, it's much
appreciated.

greg k-h

Re: [gentoo-dev] evar_push/pop helpers

[Greg KH]

On Mon, Jun 17, 2013 at 01:46:02AM -0400, Mike Frysinger wrote:
 here's v2

These changes look good to me, and quite useful, thanks for doing this
work.

greg k-h

Re: [gentoo-dev] Re: devmanual moved to github

[Greg KH]

On Mon, May 13, 2013 at 12:12:19AM +0200, Alexander Berntsen wrote:
 On 12/05/13 20:24, Peter Stuge wrote:
  [GitHub] enforces some particular workflow
 You keep saying this. What do you mean? A lot of projects (including
 Linux) just use GitHub for hosting and nothing else. I don't see the
 problem.

Linux does not use GitHub for anything, but a lot of users do use the
copy of the kernel tree on GitHub for their own development, which has
nothing to do with the main Linux kernel developer workflow.

Please don't confuse the two.

thanks,

greg k-h

[gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution

[Greg KH]

On Mon, Mar 11, 2013 at 04:51:17PM -0400, Rich Freeman wrote:
 
 If you have any concerns/objections to the policy which was outlined,
 which includes a mandatory requirement to sign a contributor license
 agreement and an option to also sign an assignment-like document based
 on the FSFe FLA, please speak up this week.

I've already said this before, but I guess I need to say it again:

If a contributor license is required to be signed, I'll have to
stop contributing to Gentoo.

Other developers will be also affected, and you will find it hard to
attract new developers who happen to work for companies that forbid
their employees to sign these types of things (a _very_ common thing in
the US, I have yet to work for a company in the past 20+ years that
would have allowed this without going through the company's legal
council for approval, a usually very difficult thing to achieve for a
single developer.)

I was here when the copyright assignment form was dropped due to all of
the problems it was causing new developers (myself included.)  Have you
somehow figured out how to handle all of the issues that were raised 8+
years ago with the old assignment we had?

Is there really no one around now (other than myself) that had to deal
with that mess in the past?

History, forgetting it, doomed.

sadly,

greg k-h

Re: [gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution

[Greg KH]

On Mon, Mar 11, 2013 at 07:12:43PM -0400, Rich Freeman wrote:
 On Mon, Mar 11, 2013 at 6:40 PM, Rich Freeman ri...@gentoo.org wrote:
  No change intended. This is what happens when you send a thirty second
  follow-up to a policy formed over two weeks, and then step away to eat...
 
 So, clarification now that I'm back at a keyboard...
 
 DCO is mandatory, and is simply a declaration that the committer has
 checked and the new code is distributed under the license chosen for
 the project (see original email for details, but generally
 GPL/BSD/etc).  The Linux kernel is the main model for this.  Since
 Gentoo is not always being assigned copyright we need to have a clear
 declaration that the code is available under a suitable free license
 so that we can further distribute it.
 
 FLA is optional, and is essentially a copyright assignment (or
 reasonable facsimile in certain jurisdictions designed by the FSFe).
 KDE is the main model for this.
 
 But, to whatever extent that anything I just wrote disagrees with the
 original email, just read the original email.  The original email was
 carefully proofread by the Trustees, the rest is just
 discussion/reminders/etc.  The final policy will be even more
 carefully reviewed.  The whole bit about mandatory copyright
 assignment was dropped after the last round of discussion for all the
 reasons that have just been rehashed...

Ok, good, that's why I didn't object to the first email, only to this
one which seemed to say something else, so I assumed it was I who
misread the first version.

Nevermind then, sorry for the noise :)

greg k-h

Re: [gentoo-dev] maintainer-wanted: x11-drivers/nvidia-drivers

[Greg KH]

On Tue, Mar 05, 2013 at 02:01:31AM -0500, Walter Dnes wrote:
 On Mon, Mar 04, 2013 at 03:44:33PM -0100, Carlos Silva wrote
  On Mon, Mar 4, 2013 at 3:28 PM, Walter Dnes waltd...@waltdnes.org wrote:
  
 I'm not a C programmer, let alone a developer, so this may be a stupid
   question, but here goes... has anyone ever tried doing a HAL (Hardware
   Abstraction Layer) to present a reasonably stable interface to binary
   video drivers?  Think of it as a shim translating a pseudo-API into
   the real API that the kernel exposes directly.  Surely, we can do
   better than VESA.  Give drivers 2 options...
   1) direct kernel access like now
   2) access via the HAL/shim
  
  
  Just read this file and you'll have the answer:
  /usr/src/linux/Documentation/stable_api_nonsense.txt
 
   Thanks.  That was an eye-opener.  If user-space drivers are really
 that slow, we may as well stick with VESA as a fallback.

Ok, I'll bite, What do you mean by that?  Where does the
stable_api_nonsense.txt file talk about userspace drivers?

greg I wrote that file k-h

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 07:51:15PM +0100, Diego Elio Pettenò wrote:
 On 20/02/2013 19:43, Greg KH wrote:
  Really?  What firmware files are that way, I just did a quick scan
  through the upstream linux-firmware.git tree and didn't see anything
  that would prevent Gentoo from doing this.
 
 No, not really. Greg, please don't expect everybody's word here to be
 the Project's as you did already once - especially not if they are not
 even really involved in it.

Of course not, I know better than that from -dev, I've been around long
enough :)

That's why I was asking for specifics.

 Ulrich Mueller (ulm) wrote this on the 16th:
 
  Look into the WHENCE file and be horrified. Taking just the first ten
  items (of a total 114):
  
 Unknown license (3 times)

Which ones specifically?

 GPL, but without source (3 times)

Really?  Which?

 All rights reserved

That's not an issue, unless it is alone, is there something else in the
license as well?

 BSD, without source

There's no problem with that.

 Right for redistribution not granted

Huh?  Which?

 Permission is hereby granted for the distribution [...] as part of
 a Linux or other Open Source operating system kernel

What is wrong with that?  We happen to be distributing a Linux operating
system.

  With one exception, we are not even allowed to redistribute these.

I don't understand, please explain all of these in detail so that we can
fix this upstream.

 This is what we've been discussing about. This is not really about
 Gentoo by itself, but the ability to distribute the sources at all, be
 it from us or somebody else.

I understand, and as an upstream developer, I want to see that fixed
because all distros need to be able to distribute these files for the
kernel to work properly.

Oh, and other distros, with lots of lawyers, are distributing these
firmware images as a single package, so this needs to be resolved either
by realizing that our interpretation is incorrect, or that everyone is
wrong here.

thanks,

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Thu, Feb 21, 2013 at 07:33:48PM +0100, Ulrich Mueller wrote:
  On Thu, 21 Feb 2013, Greg KH wrote:
 
  Ulrich Mueller (ulm) wrote this on the 16th:
  
   Look into the WHENCE file and be horrified. Taking just the first ten
   items (of a total 114):
   
  Unknown license (3 times)
 
  Which ones specifically?
 
 Driver: snd-korg1212 -- Korg 1212 IO audio device
 Driver: kaweth -- USB KLSI KL5USB101-based Ethernet device
 Driver: dvb-ttusb-budget -- Technotrend/Hauppauge Nova-USB devices

As these originally came from the kernel source tree, they are by
default ok.

  GPL, but without source (3 times)
 
  Really?  Which?
 
 Driver: ambassador -- Madge Ambassador (Collage PCI 155 Server) ATM NIC.
 Driver: snd-maestro3 -- ESS Allegro Maestro3 audio device
 Driver: qla1280 - Qlogic QLA 1240/1x80/1x160 SCSI support

Some of these came from the kernel source tree originally, others don't,
but they all imply that the GPL really isn't for the firmware itself.
Odd.

  All rights reserved
 
  That's not an issue, unless it is alone, is there something else in the
  license as well?
 
 Driver: snd-ymfpci -- Yamaha YMF724/740/744/754 audio devices
 
 According to WHENCE, it is:
 Copyright (c) 1997-1999 Yamaha Corporation. All Rights Reserved.
 Nothing else.

That's a copyright notice, not a license, so I don't know what to
suggest :)

  BSD, without source
 
  There's no problem with that.
 
 Driver: advansys - AdvanSys SCSI
 
 Right, and it's the only one out of the first ten that we're allowed
 to redistribute.
 
  Right for redistribution not granted
 
  Huh?  Which?
 
 Driver: smctr -- SMC ISA/MCA Token Ring adapter

Token ring drivers were dropped from the kernel already, so this isn't
an issue.

  Permission is hereby granted for the distribution [...] as part of
  a Linux or other Open Source operating system kernel
 
  What is wrong with that?  We happen to be distributing a Linux operating
  system.
 
 Driver: keyspan -- USB Keyspan USA-xxx serial device
 
 We distribute it in a separate package. And it doesn't say part of
 an OS but explicitly part of a kernel.

Ah, that's because at the time, that's the way it was originally
distributed.  Given that the company isn't around anymore, I don't think
this is going to be an issue :)

 
   With one exception, we are not even allowed to redistribute these.
 
  I don't understand, please explain all of these in detail so that we can
  fix this upstream.
 
  This is what we've been discussing about. This is not really about
  Gentoo by itself, but the ability to distribute the sources at all, be
  it from us or somebody else.
 
  I understand, and as an upstream developer, I want to see that fixed
  because all distros need to be able to distribute these files for the
  kernel to work properly.
 
  Oh, and other distros, with lots of lawyers, are distributing these
  firmware images as a single package, so this needs to be resolved either
  by realizing that our interpretation is incorrect, or that everyone is
  wrong here.
 
 Can you show me a distro that distributes above-mentioned files?
 Debian, for example, doesn't distribute them (AFAICS).

As far as I can tell, both SuSE and Red Hat distribute these today.  And
so does Canonical, but really, that can't be taken as valid legal
usage at all :)

Has anyone asked the upstream linux-firmware developers about these
files?

thanks for the detailed descriptions, much appreciated.

I think this is something that the Board needs to decide, after
discussing it with our lawyers, it's not something that non-legal people
(like myself) should be saying is the definitive answer.

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Thu, Feb 21, 2013 at 09:44:12PM +0100, Ulrich Mueller wrote:
  On Thu, 21 Feb 2013, Greg KH wrote:
 
  Has anyone asked the upstream linux-firmware developers about these
  files?
 
 I don't know. I haven't, for my part. But maybe we should first try
 to produce a more complete list, instead of reporting each file
 separately? Given that most of the files are being distributed since
 years, another few days cannot matter.

Such a list would be wonderful to have.

  thanks for the detailed descriptions, much appreciated.
 
  I think this is something that the Board needs to decide, after
  discussing it with our lawyers, it's not something that non-legal
  people (like myself) should be saying is the definitive answer.
 
 I fully agree. And IANAL, so anything that I say about license issues
 should be taken with a grain of salt.

I am willing to work with lawyers, who know these type of things quite
well, to get upstream straightened out, given that I was the one who
originally added firmware files to the kernel, oh so many years ago,
causing this problem...

This should be a cross-distro issue/solution, so I suggest working with
the Linux Foundation on this.  Anyone object to me doing that?

thanks,

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 11:03:47AM -0500, Rich Freeman wrote:
 On Wed, Feb 20, 2013 at 8:17 AM, Diego Elio Pettenò
 flamee...@flameeyes.eu wrote:
  On 20/02/2013 13:02, Rich Freeman wrote:
  I'm actually wondering if that makes sense with git when a specific
  commit is referenced, since everything is content-hashed anyway.
  Perhaps we just need to confirm that git actually checks the hash.
 
  The policy is also because any ebuild relying on a network service to
  work cannot be assured to work at any point in time: not only it depends
  on the network connection of the user, but it also depends on the
  service to be available.
 
 Makes sense in general.
 
 If there really are firmware blobs that are only available via git and
 which cannot be redistributed we might consider whether it makes sense
 to not support them entirely, or to force them to be masked.

Did anyone actually consider the fact that there should not be
non-redistributable firmware blobs in the upstream git tree in the first
place, as it is the thing that is doing the redistributing originally?

Has anyone pointed out any problems with the package to upstream if you
have found them?  If so, what did they say?

greg k-h

Re: [gentoo-dev] Re: linux-firmware

[Greg KH]

On Wed, Feb 20, 2013 at 07:25:14PM +0100, Peter Stuge wrote:
 Greg KH wrote:
   If there really are firmware blobs that are only available via git and
   which cannot be redistributed we might consider whether it makes sense
   to not support them entirely, or to force them to be masked.
  
  Did anyone actually consider the fact that there should not be
  non-redistributable firmware blobs in the upstream git tree in the
  first place, as it is the thing that is doing the redistributing
  originally?
 
 I think non-redistributable in this case means by Gentoo since that
 was identified to be the case for some of the files in the git
 repository. Their license allows them to be distributed in
 linux-firmware.git, but not elsewhere.

Really?  What firmware files are that way, I just did a quick scan
through the upstream linux-firmware.git tree and didn't see anything
that would prevent Gentoo from doing this.

What did I miss?

thanks,

greg k-h

Re: [gentoo-dev] Proper installation path for efi binaries (.efi)

[Greg KH]

On Mon, Feb 04, 2013 at 08:13:58PM +0100, Martin Pluskal wrote:
 Hi
   I am curious what is the proper path for installation of efi binaries
 (such as shim.efi) in gentoo. I don't think that installing them
 directly into /boot/efi... is proper way - it seems to me that
 /usr/lib64/efi or /usr/libexec/efi is more appropriate location for
 them. What's your opinion?

It depends on if you want the bootloader to use the binary or not.  If
you do, it needs to be in /boot/efi/, otherwise it will never be able to
be run by the UEFI system.

Unless you really think that having /usr/ as a vfat filesystem is ok?
:)

thanks,

greg k-h

Re: [gentoo-dev] Proper installation path for efi binaries (.efi)

[Greg KH]

On Mon, Feb 04, 2013 at 11:45:22PM +0100, Martin Pluskal wrote:
 On 4.2.2013 23:34, Greg KH wrote:
  On Mon, Feb 04, 2013 at 08:13:58PM +0100, Martin Pluskal wrote:
  Hi
 I am curious what is the proper path for installation of efi binaries
  (such as shim.efi) in gentoo. I don't think that installing them
  directly into /boot/efi... is proper way - it seems to me that
  /usr/lib64/efi or /usr/libexec/efi is more appropriate location for
  them. What's your opinion?
  
  It depends on if you want the bootloader to use the binary or not.  If
  you do, it needs to be in /boot/efi/, otherwise it will never be able to
  be run by the UEFI system.
 Well, in order to boot you have to place .efi into /boot/efi, I am not
 sure if it is the best idea to directly install everything with .efi
 into /boot/efi. As far as I know, elilo is installed into /usr/lib/elilo
 and grub2 is placed into /boot/efi by grub2-install.

If elilo is in /usr/lib/elilo, the UEFI bios can not run the binary as
it can't even see the filesystem to read the binary from.

So how can anything that is .efi _not_ be in /boot/efi and still work?

Have you tried this out on your system with any success?

What exactly is the issue you are trying to solve here?

thanks,

greg k-h

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Greg KH]

On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote:
 On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge pe...@stuge.se wrote:
  Rich Freeman wrote:
  Not that anybody is taking requests, but it would be really handy
  if serial ports were deterministically labeled.
 
  Does /dev/serial/* solve the problem?
 
 I don't see this directory at all on my system.

Do you have a usb-serial device plugged in?  You need a serial device
for it to show up, and you need to be using udev.

greg k-h

Re: [gentoo-dev] call for testers: udev predictable network interface names

[Greg KH]

On Tue, Jan 15, 2013 at 08:58:59AM -0500, Ian Stakenvicius wrote:
 On 15/01/13 04:16 AM, Michael Weber wrote:
  Hi,
  
  This can have serious security implications [1]
  
  For whom?
 
 I think the idea there is that a user expects eth0 and eth1 to stay
 the same, writes iptables rules on a per-interface basis to control
 what they want, then update the kernel or make some other change
 (upgraded udev, maybe? :D) which swaps them around and poof, the rules
 they thought were correct don't end up protecting them they way they
 assumed it would...
 
 Not saying this is necessarily valid, just saying how I interpreted
 their meaning of serious security implications.

Yes, that is true.

And it's not udev that could rename the interface (hint, it wouldn't),
it's the kernel, it _never_ guarantees the same interface name every
time you boot.  You might just be getting lucky, but really, PCI busses
can be enumerated in different ways, USB devices can come and go and
initialize sometimes slower one boot from another, and lots of other
things can happen.

So anyone who relies on network names right now to be deterministic, and
you have more than one network device in your system, should seriously
reconsider how they are naming their devices, as it will not work if you
only rely on the kernel.

You might have gotten lucky for the past 5 years, but you never know
what could happen if you reboot today.  Seriously, I've seen it happen
all the time.

Hope this helps explain things a bit better.

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

[Greg KH]

On Fri, Dec 21, 2012 at 08:17:59PM +, Robin H. Johnson wrote:
 For further messages in this thread, please keep:
 Reply-To: gentoo-dev@lists.gentoo.org, gentoo-...@lists.gentoo.org 
 
 On Thu, Dec 20, 2012 at 08:08:45PM -0800, Greg KH wrote:
  On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote:
   On Mon, Dec 17, 2012 at 01:16:25PM -0800, Greg KH wrote:
On a personal note, if any copyright assignment was in place, I would
never have been able to become a Gentoo developer, and if it were to be
put into place, I do not think that I would be allowed to continue to be
one.  I'm sure lots of other current developers are in this same
situation, so please keep that in mind when reviewing this process.
   This is a question for gregkh primarily, but I would also like to extend
   it to all other Gentoo developers.
   
   1. Are you party to any *copyright assignment* (eg FSF copyright 
   assignment)?
  You need to rephrase this to be (in order for it to make any sense):
Are you party to any *copyright assignment* that is not part of your
employment agreement?
 No, copyright assignments from your employment agreement are a valid
 answer to question #1.

In the US, almost _all_ employment agreements have such wording, so this
really isn't going to be able to tell you much.

   2. Are you party to any *contributor license agreements* (eg FLA, Google 
   CLA, ...)? [2]
   3. Are you party to any other *license assertions* (eg DCO)? [3]
   4. Are you party to or aware of any other copyright aggregation efforts? 
   [4]
  Note also, anyone who works for any company, might not be allowed to
  answer some of these questions, and, might not want to (i.e. the
  employer is requiring the person to do the work on a specific project,
  despite the fact that the developer doesn't like the copyright
  assignment rules for it.)
 I don't want the specifics, just a yes or no. A I cannot answer this
 for contractual reasons is a very useful red flag as well.

What if those contractual reasons don't even allow you to say that?
(seriously, I've seen contracts like that before, the startup world is
very wierd that way.)

 For yourself, I'm fairly certain you are party to DCO's per #3, because
 you send in work to the kernel with Signed-off-by lines. I don't know
 about your employment contracts, and I was hoping to get that piece of
 clarification.

The wording of most employment agreements (in the US it's not really a
contract at all, only in rare cases), do not allow them to be disclosed
to anyone outside of the company.  So this might not be something that
some people can talk about in public without getting into big trouble.

  I think you want to rephrase this as asking what types of projects, from
  a copyright assignment basis, do people contribute to, on their own
  time.  But even then, you will run into problems with corporate
  restrictions.
  
  Hm, this is a mess.  What are you trying to find out here?  What type of
  projects to people work on based on the copyright assignment rules?  Or
  something else?
 As one of the Foundation trustees, I wanted a rough survey of how
 copyright is handled in other employment and projects for a
 (self-selecting) sample of developers. I don't care what the work or
 projects are - just how it breaks down.
 
 ===
 $W devs are aware/party other copyright aggregation efforts.
 Number of developers already party to:
 copyright assignment - $X devs
 CLAs - $Y devs
 other license assertions - $Z devs
 ===
 (plus looking at useful overlaps).

I think you might be able to infer the answers to your questions if you
ask them in a totally different way.  For example, if you were to say:
  - Have you contributed to a project that requires the DCO?
  - Have you contributed to a project that requires the copyright to be
assigned to the FSF?
and the like.  That information, being that that knowledge is usually
public, can almost always be answered safely, and gets around the
disclosure of company/employer contracts and agreements quite nicely, as
you really don't care about the information in those agreements, right?

Aren't contracts and legal agreements fun?  :)

thanks,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

[Greg KH]

On Fri, Dec 21, 2012 at 12:01:00AM -0500, Rich Freeman wrote:
 On Thu, Dec 20, 2012 at 11:08 PM, Greg KH gre...@gentoo.org wrote:
  On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote:
  1. Are you party to any *copyright assignment* (eg FSF copyright 
  assignment)?
 
  You need to rephrase this to be (in order for it to make any sense):
Are you party to any *copyright assignment* that is not part of your
employment agreement?
 
  Otherwise, everyone in the US, and most other countries, would almost
  always have to just say yes to this, as their employer owns the
  copyright for their work no matter what it is done on (open source or
  not.)
 
 Work done for hire is certainly owned by the employer, unless an
 agreement to the contrary is explicitly documented, but employment
 agreements that purport to assign copyright for works unrelated to
 employment to the employer are rare.  Maybe they're not as rare in the
 software industry, but most people aren't employed in the software
 industry (even if most Gentoo developers might be - though perhaps not
 as a big a majority as you might expect).
 
 Certainly I haven't signed any kind of document that assigns ownership
 of works created on my own time to my employer, and the legality of
 any contract I did sign to that effect would be dubious.

That's not true in the US, in fact, it's the exact opposite.  Your
employer has ownership of all of your work, even done on your own time,
unless you explicitly have permission otherwise, if it is done in an
industry that is related to your employer.  Read the traditional US
employment agreement for details about this.

Yes, some states allow for exceptions to this rule, but those are the
exceptions (California has some unique changes here).

You might have signed these types of agreements when you were hired by a
company, and didn't realize it, it's usually quite well hidden in the
agreement.

Now this is all for the US, Europe has other types of laws, but they
still assign ownership/copyright of what you do while being paid by
those companies, to the company, and not to you.  Again, there are
exceptions, but traditionally that is how they work.

  Remember, in the US, individuals who actually own the copyright on the
  work they do is quite rare once they get out of college, and even then,
  while in college, the school does have the right to assert copyright
  ownership of the work, depending on what it was done on/for (who
  provided the equipment, tasks, etc.)
 
 Ownership of work in the sense of something you're paid to do
 usually does tend to reside with whoever is paying you to do the work,
 unless you're a consultant of some kind or otherwise paid by the
 engagement (in which case it is usually spelled out).  Ownership of
 stuff like the photos everybody will be taking next week with family
 rarely ends up belonging to an employer.

Photos, yes, but all joking aside, go read the agreement, they are
incredibly broad.  As numerous inventors have found out the hard way
over the years when their companies end up owning the rights to things
they have created on their own time.  Again, some states have rules to
try to give rights back to the individuals (like CA), but those are
rare, and only cover limited things.

I speak from person experience about this.  I used to work for IBM, and
IBM's employment agreement is so broad, the joke used to be, the only
thing you could do on your own time that isn't owned by IBM would be to
mow people's lawns for them.  That joke turned into reality when a
coworker of mine started a landscaping company and eventually quit to
run it full time.

The rules involved here are complex, and usually never in an
individual's favor for they don't get to write the rules.

Be mindful that if Gentoo is to go down a assign copyright to the
Foundation type of arrangement, they are going to run smack into a
whole range of people's employment agreements, almost all of them which
will prevent them from participating unless they get explicit agreement
from their employer.

Just ask anyone who has had to get their company to sign the FSF
copyright assignment paperwork, for just how hard that was, and how long
it took.

thanks,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

[Greg KH]

On Fri, Dec 21, 2012 at 02:32:25AM +, Robin H. Johnson wrote:
 On Mon, Dec 17, 2012 at 01:16:25PM -0800, Greg KH wrote:
  On a personal note, if any copyright assignment was in place, I would
  never have been able to become a Gentoo developer, and if it were to be
  put into place, I do not think that I would be allowed to continue to be
  one.  I'm sure lots of other current developers are in this same
  situation, so please keep that in mind when reviewing this process.
 This is a question for gregkh primarily, but I would also like to extend
 it to all other Gentoo developers.
 
 1. Are you party to any *copyright assignment* (eg FSF copyright assignment)?

You need to rephrase this to be (in order for it to make any sense):
  Are you party to any *copyright assignment* that is not part of your
  employment agreement?

Otherwise, everyone in the US, and most other countries, would almost
always have to just say yes to this, as their employer owns the
copyright for their work no matter what it is done on (open source or
not.)

Remember, in the US, individuals who actually own the copyright on the
work they do is quite rare once they get out of college, and even then,
while in college, the school does have the right to assert copyright
ownership of the work, depending on what it was done on/for (who
provided the equipment, tasks, etc.)

 2. Are you party to any *contributor license agreements* (eg FLA, Google CLA, 
 ...)? [2]
 3. Are you party to any other *license assertions* (eg DCO)? [3]
 4. Are you party to or aware of any other copyright aggregation efforts? [4]

Note also, anyone who works for any company, might not be allowed to
answer some of these questions, and, might not want to (i.e. the
employer is requiring the person to do the work on a specific project,
despite the fact that the developer doesn't like the copyright
assignment rules for it.)

I think you want to rephrase this as asking what types of projects, from
a copyright assignment basis, do people contribute to, on their own
time.  But even then, you will run into problems with corporate
restrictions.

Hm, this is a mess.  What are you trying to find out here?  What type of
projects to people work on based on the copyright assignment rules?  Or
something else?

thanks,

greg k-h

Re: [gentoo-dev] Re: eudev project announcement

[Greg KH]

On Tue, Dec 18, 2012 at 08:21:36AM +0100, J. Roeleveld wrote:
 On Mon, December 17, 2012 22:31, Greg KH wrote:
  On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
  Olav Vitters o...@vitters.nl wrote:
 
  On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
   As I said in an earlier email, Lennart Poettering claims that it does
   not work. We are discussing some of the things necessary to make it
  work.
  
  Just to repeat:
  In this thread it was claimed that a separate /usr is not supported by
  systemd/udev.
  
  A case which works with latest systemd on various distributions. I
  checked with upstream (not Lennart), and they confirmed it works. I can
  wait for Lennart to say the same, but really not needed.
  
  I assume this will again turn into a but I meant something else.
 
  Olav.
 
  Lennart has stated that he considers a seperate /usr without init*
  broken.
 
  Yes, as do I, and so do a lot of other developers.
 
 It is only broken, because upstream decided to move everything into /usr
 that was previously in /.

No, not at all, please see the web page that describes, in detail, the
problems that has been going on for quite some time now, with the /usr
and / partitions and packages.
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken

One good solution to this issue is to move everything into /usr, and
that's something that has wonderful benifits in the long run, and is
something that I expect all Linux distros to eventually implement.
Those that don't, will suffer because of it.

Again, see the web page for why moving stuff into /usr is a good idea
for the reasons behind this.
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge

  This has worked correctly in the past.
 
  Define past please.
 
 Recent past, like a few months ago no errors during boot and the system
 running stable.

You have gotten lucky, see the above links for why.

 Please provide a simple way to let me see that it is broken on systems
 that do not use bluetooth keyboards.

Again, see the above link for how to do this.

 The requirement of having userspace working to have input devices working
 seems to be related to bluetooth, not to USB or PS/2 keyboards.

Not at all, see the above link.

 And using a bluetooth connection to access a NFS share is, in my humble
 opinion, a corner case that requires additional work to make it work.

One person's corner case is another person's default operating mode.

  Note, it's still broken, I have yet to see any upstream fixes to resolve
  all of the issues that are involved here with fixing this up.
 
 Reverting back to an older version makes it work.

Because of how we package udev?

 Using mdev also works.

mdev is not recommended for desktop or server systems, but feel free to
use it if you want.

  Yes, as always, for some subset of users, you can be lucky and it will
  work for them, but those systems are getting rarer and rarer these days,
  as the rest of upstream (not systemd here) are moving on and not doing
  anything to change their behavior for this topic.
 
 Why rarer? Any system I can buy in a random shop will work using a
 seperate /usr, provided the software is installed sanely.

Again, see above for why this is not true.

 By moving everything into /usr, this brokenness is forced upon users.

Not at all, but that's a separate topic than what we are talking about
here.

  The direction udev development is going, according to Lennart, is to
  make that impossible and he refuses to fix this regression.
 
  Again, this has NOTHING to do with udev or systemd, as has been pointed
  out numerous times.  I understand your _wish_ that it would have
  something to do with it, but that will not change the facts, sorry.
 
 Then what does it have to do with?
 When it was made public that it is considered broken, the news came from
 udev-upstream. This was before most systems encountered any breakage.

That is because things were failing silently for some people, and not so
silently for others.  Now udev warns about this type of situation,
shooting the messenger is usually a bad idea.

  I am really happy with this project and intend on testing it once
  requests for this appear in the eudev mailing list.
 
  Good luck, the root problems still remain, and nothing that eudev ever
  does can resolve that, sorry.
 
  Can this topic finally be put to rest please?  There is a whole web page
  devoted to this topic, why do people blindly ignore it?
 
 Where is this page?
 I've read the page written by Lennart. Is there a decent (as in, going
 into detail why it is broken and what it is caused by) analysis about the
 problem?

See above for the links and the details.

  Again, a separate /usr without an initrd has NOTHING to do with systemd
  or udev, with the minor exception that Gentoo's packaging of those
  programs _might_ have an issue, but that is Gentoo's issue, NOT
  upstream's issue.
 
  If anyone

[gentoo-dev] Re: [gentoo-dev-announce] Soliciting Feedback: Gentoo Copyright Assignments / Licensing

[Greg KH]

On Mon, Dec 17, 2012 at 10:07:59AM -0500, Rich Freeman wrote:
 Announcing once to -dev-announce due to the general importance of this
 topic to the community, but ALL replies should go to -nfp, or to
 trustees@ if you must, or to /dev/null if you shouldn't.
 
 Before I start, yes, the trustees realize that there are legal issues
 around copyright assignment in general, and that various workaround
 exist and may or may not work, such as various contributor licensing
 agreements that are used by various organizations, especially in
 Europe.  The purpose of this thread isn't really to debate this topic,
 as it might be moot in any case.

I understand your wish to somehow think that the legal issues involved
have no pertinence to this discussion, but that just isn't the case.  In
fact, they will be one of the major factors that control any decision
that is picked, so you can't just ignore them, sorry.

 The question we would like to get feedback from the Gentoo community
 on is this: is copyright assignment (or something like it) something
 Gentoo should even be pursuing, and if so, to what degree?

My personal opinion is, No, the Gentoo Foundation should not be
pursuing any copyright assignment for any code that it creates or
manages.  And my main justification for this goes to the above point,
to do anything other than this is almost a legal impossibility for a
project like Gentoo (i.e. one that spans the world and accepts
contributions from people working for a wide range of companies) that
wishes to continue to accept contributions from as many people as
possible.

This was the main reason that Gentoo gave up on the copyright assignment
clause in the developer agreement all those years ago.

Those who forget history, are doomed to repeat it, let's not go through
all of this again, please.

On a personal note, if any copyright assignment was in place, I would
never have been able to become a Gentoo developer, and if it were to be
put into place, I do not think that I would be allowed to continue to be
one.  I'm sure lots of other current developers are in this same
situation, so please keep that in mind when reviewing this process.

thanks,

greg k-h

Re: [gentoo-dev] Re: eudev project announcement

[Greg KH]

On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote:
 Olav Vitters o...@vitters.nl wrote:
 
 On Mon, Dec 17, 2012 at 09:29:26AM -0500, Richard Yao wrote:
  As I said in an earlier email, Lennart Poettering claims that it does
  not work. We are discussing some of the things necessary to make it
 work.
 
 Just to repeat:
 In this thread it was claimed that a separate /usr is not supported by
 systemd/udev.
 
 A case which works with latest systemd on various distributions. I
 checked with upstream (not Lennart), and they confirmed it works. I can
 wait for Lennart to say the same, but really not needed.
 
 I assume this will again turn into a but I meant something else.
 
 Olav.
 
 Lennart has stated that he considers a seperate /usr without init* broken.

Yes, as do I, and so do a lot of other developers.

But that is a system configuration issue, not a systemd issue, please
don't confuse the two.

 This has worked correctly in the past.

Define past please.

Note, it's still broken, I have yet to see any upstream fixes to resolve
all of the issues that are involved here with fixing this up.

Yes, as always, for some subset of users, you can be lucky and it will
work for them, but those systems are getting rarer and rarer these days,
as the rest of upstream (not systemd here) are moving on and not doing
anything to change their behavior for this topic.

 The direction udev development is going, according to Lennart, is to
 make that impossible and he refuses to fix this regression.

Again, this has NOTHING to do with udev or systemd, as has been pointed
out numerous times.  I understand your _wish_ that it would have
something to do with it, but that will not change the facts, sorry.

 I am really happy with this project and intend on testing it once
 requests for this appear in the eudev mailing list.

Good luck, the root problems still remain, and nothing that eudev ever
does can resolve that, sorry.

Can this topic finally be put to rest please?  There is a whole web page
devoted to this topic, why do people blindly ignore it?

Again, a separate /usr without an initrd has NOTHING to do with systemd
or udev, with the minor exception that Gentoo's packaging of those
programs _might_ have an issue, but that is Gentoo's issue, NOT
upstream's issue.

If anyone involved with eudev, or is involved with the Gentoo Council
thinks that the previous paragraph is incorrect, they are flat out
wrong.

greg k-h

[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
 Handling separate /usr support
 ==
 After the discussion on [1] during the previous meeting, a delay of one
 month due to a new fork of udev was requested.  We need an update on
 what's happened.
 
 Chainsaw reported udev and eudev have moved on, and for both it is now
 possible to have a separate /usr.  The follow-up discussion related to
 the /usr-merge is necessary.

udev was never the problem of having a separate /usr without an initrd.
Have all of the other packages been properly fixed to resolve this issue
correctly?

Also, what's the plan for eudev going forward?

thanks,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
 On 14/12/12 01:28 PM, Greg KH wrote:
  On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
  Handling separate /usr support == 
  After the discussion on [1] during the previous meeting, a delay
  of one month due to a new fork of udev was requested.  We need an
  update on what's happened.
  
  Chainsaw reported udev and eudev have moved on, and for both it
  is now possible to have a separate /usr.  The follow-up
  discussion related to the /usr-merge is necessary.
  
  udev was never the problem of having a separate /usr without an
  initrd. Have all of the other packages been properly fixed to
  resolve this issue correctly?
  
  Also, what's the plan for eudev going forward?
  
 
 
 Eudev's project announcement is coming soon, should answer your questions.

Ok, when is soon?  I'm guessing that the result of the council meeting
ment that things are progressing, right?  If so, in what way?

 In terms of udev's dependencies, yes, the few dependencies that were
 installing only to /usr (ie, kmod and xz-utils) have been switched to
 install to /, and then fixed again due to issues with they way they
 were done the first time so that they also work.  I believe however
 they are still ~arch keyworded.

I am not referring to udev's dependancies, that was never the real
issue with a separate /usr/ partition as those could easily be fixed
with a configuration option for the package.

 There may of course be other entirely independent packages needed at
 boot time prior to localmount, I do not know that status of those.

That's the big problem, those need to be fixed.

 Once eudev (the gentoo package) fully supports separate-/usr (which it
 doesn't at this time as it uses the same init scripts as udev-196), we
 will be sure to resolve them.

Again, udev itself was never an issue, it could work just fine with a
separate /usr/ partition.  Now perhaps our ebuild didn't build it in
that matter, but that's a configuration/ebuild issue, not a upstream
package issue.

 It should be noted that sys-fs/udev (the package) since ..  186 I
 think?  whichever version dropped support for the failed-rules queue
 (and whichever package dropped the udev-postmount init script) does
 not support booting with a separate /usr.  This has more to do with
 how the package installs than the upstream code itself, though; as
 such (WilliamH please correct me if I'm wrong) the plan is still to
 require an initramfs if using sys-fs/udev with a separate-/usr.

If the plan is still to require an initramfs (hint, it's the only way it
can work), then why was the eudev package forked and created?

Please, I'm totally confused now, especially after reading the commits
in the eudev repo, I see nothing that fixed any /usr/ problems, what am
I missing?

Oh, you also slowed the build time of the package down in eudev compared
to udev, but I'm sure you realized that already, and did it for a good
reason.

confused,

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote:
 On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote:
  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
  
  On 14/12/12 01:28 PM, Greg KH wrote:
   On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote:
   Handling separate /usr support == 
   After the discussion on [1] during the previous meeting, a delay
   of one month due to a new fork of udev was requested.  We need an
   update on what's happened.
   
   Chainsaw reported udev and eudev have moved on, and for both it
   is now possible to have a separate /usr.  The follow-up
   discussion related to the /usr-merge is necessary.
   
   udev was never the problem of having a separate /usr without an
   initrd. Have all of the other packages been properly fixed to
   resolve this issue correctly?
   
   Also, what's the plan for eudev going forward?
   
  
  
  Eudev's project announcement is coming soon, should answer your questions.
  
  In terms of udev's dependencies, yes, the few dependencies that were
  installing only to /usr (ie, kmod and xz-utils) have been switched to
  install to /, and then fixed again due to issues with they way they
  were done the first time so that they also work.  I believe however
  they are still ~arch keyworded.
  
  There may of course be other entirely independent packages needed at
  boot time prior to localmount, I do not know that status of those.
  Once eudev (the gentoo package) fully supports separate-/usr (which it
  doesn't at this time as it uses the same init scripts as udev-196), we
  will be sure to resolve them.
  
  It should be noted that sys-fs/udev (the package) since ..  186 I
  think?  whichever version dropped support for the failed-rules queue
  (and whichever package dropped the udev-postmount init script) does
  not support booting with a separate /usr.  This has more to do with
  how the package installs than the upstream code itself, though; as
  such (WilliamH please correct me if I'm wrong) the plan is still to
  require an initramfs if using sys-fs/udev with a separate-/usr.
 
 Greg, can you write back to this message with specific examples of what
 would need to be customized so that separate /usr would work  right
 without an initramfs? I have tried to explain multiple times that this
 is a mis-conception that udev caused it, but I am getting nowhere.

It's not my job to do this, nor yours, or fix any of these issues.  It's
up to the people who wish to keep a separate /usr partition without an
initramfs to do this work.

greg k-h

Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012

[Greg KH]

On Fri, Dec 14, 2012 at 09:00:56PM +, Kevin Chadwick wrote:
   Greg, can you write back to this message with specific examples of what
   would need to be customized so that separate /usr would work  right
   without an initramfs? I have tried to explain multiple times that this
   is a mis-conception that udev caused it, but I am getting nowhere.  
  
  It's not my job to do this, nor yours, or fix any of these issues.  It's
  up to the people who wish to keep a separate /usr partition without an
  initramfs to do this work.
 
 So even though you keep stating things without being specific like
 udev is not a blocker, you have just admitted that the udev package
 does violate the Filesystem Hiearchical Standard as well as the latest
 draft when installing.

Specifically how does udev violate it?  And also note, FHS is a trailing
standard, documenting how things are done, not how they should be done.
It can be changed.

And since when did Gentoo start worrying about FHS and LSB?

 I can understand following the current trend (some of which I agreed
 with) but what is the justification for that which didn't already have
 an optional solution?

I don't understand, what in the udev package, or source, goes against
FHS?

 p.s. embedded does not equal mobile and android uses a leaner init
 than /sbin/init and experiments posted to the buildroot list found
 systemd to be slower, guessed to be due to increased cycles but perhaps
 memory usage on even some mobile level processors which accounts for a
 fraction of linux potential in embedded applications. POSIX compliance
 is also a requirement by some major industries.

What does POSIX have to do with anything here?

And when did I bring up systemd and boot times?  That's not what this
thread is about, sorry.

greg k-h

Re: [gentoo-dev] Re: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)

[Greg KH]

On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote:
 On 14/12/12 03:02 PM, Greg KH wrote:
  I'm guessing that the result of the council meeting meant that
  things are progressing, right?  If so, in what way?
 
 Sounds like you should join us in #gentoo-udev to discuss, or join the
 eudev mailing list.  I'd rather not spend a significant amount of time
 writing about eudev development on gentoo-dev@ given it's not really
 on-topic here.

It was discussed at the Gentoo Council meeting, how could that _not_ be
on topic here?

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 10:31:25AM -0500, Walter Dnes wrote:
 On Sun, Dec 09, 2012 at 06:37:56PM -0800, Greg KH wrote
 
  Not necessarily, as I'm finding out with real hardware.  My only options
  on the box I have is to either zero out all keys, or specifically tell
  the BIOS what binary to run (doesn't need to be signed, and can not be
  changed after telling the BIOS to use it.)
 
   Howsabout the binary being Matthew Garret's chainloader shim as per
 http://mjg59.dreamwidth.org/20303.html

That's a nice one, but note my previous comment about a bug in it at the
moment that prevents it from working on some hardware.  It's also a
valid solution for some implementations, have you tried it yourself?

  I'm working with others to see if we can programatically add keys,
  which we should, and if so we will offer the code up to do so (it's
  published already, we are working on getting it signed by the needed
  Microsoft keys right now.)
 
   He's already done the heavy lifting.  Aren't you re-inventing the
 wheel?

Not at all, we are sharing the same code base here, just two different
frontend implementations that do different things, with the same crypto
backend and local (MOK) key checking functionality, which was done by
SUSE.

Matthew's frontend shim code is nice and tiny, but the one I am
referring to provides the ability to enroll your own keys in the BIOS,
which shim does not.

Don't worry, we are all working together here, it's not like there is a
ton of people involved :)

greg there is no cabal k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote:
 On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes
 likew...@weboperative.com wrote:
  I don't know the details of the issue but I know that I was prevented from 
  using grub on the livedvd.
 
 Well, if some perceived legal constraint is keeping us from doing
 whatever seems to be technically most appropriate we should
 investigate the matter and resolve it.  If, on the other hand, it
 simply makes sense to use something else, then no sense belaboring the
 point.
 
 People just seem to be really paranoid about GPLv3 and Grub.  We're
 already talking to the FSF about how they handle copyright attribution
 on their own projects, so I suppose we could get their opinion on UEFI
 as well.  However, I don't see anything in the language of the license
 that creates a problem when using it with UEFI, unless one wants to
 sell locked-down hardware.  Doing that would be a violation of our
 social contract, let alone the GPLv3.

The FSF has already said that using Grub2 and the GPLv3 is just fine
with the UEFI method of booting, so there is no problem from that side.
There's a statement about this somewhere on their site if you are
curious.

The only one objecting to GPLv3 and UEFI is the current rules for
getting a shim/bootloader signed by Microsoft, but the current
implementations we have all have either a GPLv2 or BSD licensed shim
which then loads GRUB, so all is fine from a licensing and legal
standpoint from everyone involved.

Hope this helps,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 07:46:59PM +0100, Chí-Thanh Christopher Nguyễn wrote:
 Fernando Reyes schrieb:
  That's what meant since we use isolinux on the release media and until 
  syslinux-6 we are forced to use another bootloader and grub seems out of 
  the questions because of licensing issues. I will test new syslinux soon 
  and see how isohybrid and isolinux plau together on an EFI bios.
 
 No, all we need is to enable EFI stub support in the kernel, and
 integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
 some location where UEFI looks for it (/efi/boot/bootx64.efi).
 
 This has the disadvantage of not allowing to pass additional kernel
 parameters during boot. But it might still be an acceptable stopgap
 measure if the alternative is to not boot at all.

No, don't do that for an install kernel, that way is madness, just use
a real UEFI bootloader which can handle an initrd and the like properly
(like gummiboot, which arch is using for their UEFI bootloader, and I've
been using for months quite successfully.)

Only boot a kernel directly from UEFI if you build your own and have
customized it for your hardware.  Some bioses will let you do this in
secure boot mode without having to sign anything, I took a video of this
on Friday showing how easy it can be:
https://plus.google.com/u/0/111049168280159033135/posts/81V5oyzwK63

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 01:35:57PM -0500, Rich Freeman wrote:
 On Sun, Dec 9, 2012 at 1:24 PM, Greg KH gre...@gentoo.org wrote:
 
  The FSF has already said that using Grub2 and the GPLv3 is just fine
  with the UEFI method of booting, so there is no problem from that side.
  There's a statement about this somewhere on their site if you are
  curious.
 
  The only one objecting to GPLv3 and UEFI is the current rules for
  getting a shim/bootloader signed by Microsoft, but the current
  implementations we have all have either a GPLv2 or BSD licensed shim
  which then loads GRUB, so all is fine from a licensing and legal
  standpoint from everyone involved.
 
 Makes sense to me, thanks.
 
 An MS-signed bootloader isn't nearly as critical for Gentoo as it is
 for other distros - we're not really aiming for the
 stick-a-CD-in-and-you're-done  crowd.  If somebody can partition their
 drive, build and install a kernel and grub, configure make.conf, and
 build a system, then I'm not too concerned that they have to run some
 script to generate a key, sign their bootloader, and register that key
 with their firmware, or disable secure boot just to boot the install
 CD (though it sounds like some firmwares just pop up a warning and let
 you proceed, which is what my Chromebook does in dev mode).

The UEFI spec does not allow that mode of operation in secure boot mode,
sorry. You will have to disable it in order to boot a Gentoo image,
which is fine, but there's no reason why Gentoo can't use the MS-signed
shim bootloader like all other distros are using, right?

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 01:24:53AM +0100, Diego Elio Pettenò wrote:
 On 09/12/2012 19:59, Greg KH wrote:
  The UEFI spec does not allow that mode of operation in secure boot mode,
  sorry. You will have to disable it in order to boot a Gentoo image,
  which is fine, but there's no reason why Gentoo can't use the MS-signed
  shim bootloader like all other distros are using, right?
 
 I wouldn't say we have any problem with that. Fabio already got Sabayon
 to support the shim. The only problem is that we'd have to provide a
 shim binary that _is_ signed, rather than building it from source, but I
 don't see it as a mayor problem myself.

I see the shim is checked into Sabayon, with my recent testing on real
hardware, I think there's a bug in the existing shim binary that will
keep it from working on most hardware, so it will need to be updated.

Some of us are currently working with Microsoft to do that right now...

But, if you have access to UEFI secure boot hardware, please test, it
might work for you and if so, please let us know.

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 07:52:16PM -0500, Rich Freeman wrote:
 On Sun, Dec 9, 2012 at 7:24 PM, Diego Elio Pettenò
 flamee...@flameeyes.eu wrote:
  On 09/12/2012 19:59, Greg KH wrote:
  The UEFI spec does not allow that mode of operation in secure boot mode,
  sorry. You will have to disable it in order to boot a Gentoo image,
  which is fine, but there's no reason why Gentoo can't use the MS-signed
  shim bootloader like all other distros are using, right?
 
 I thought I had read something in Google+ posted by somebody who
 mentioned that their firmware was doing exactly that.  It may very
 well be prohibited by the spec though, in which case we shouldn't
 count on it.

I have not seen that at all, any pointers?  Based on my interactions
with the UEFI group, and Microsoft, that's either a bug that will be
fixed up, or some misinformation.

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Sun, Dec 09, 2012 at 08:08:01PM -0500, Rich Freeman wrote:
 On Sun, Dec 9, 2012 at 7:57 PM, Diego Elio Pettenò
 flamee...@flameeyes.eu wrote:
  On 10/12/2012 01:52, Rich Freeman wrote:
   The shim might work, but I'd hardly call it secure boot if every
  motherboard manufacturer and OEM in the world has the ability to sign
  things, even if MS vouched for them all.  Even if I installed Windows
  I'd want the ability to re-sign it with a key I controlled and tell
  the firmware to refuse to boot the MS key.
 
  I don't think it's Gentoo's place to do that kind of stuff especially
  since I think you're in dreamland if you think that's achievable in
  _every_ case. It probably works in some cases, though.
 
 Any Windows-logo-compliant firmware has to support changing the keys.

Not necessarily, as I'm finding out with real hardware.  My only options
on the box I have is to either zero out all keys, or specifically tell
the BIOS what binary to run (doesn't need to be signed, and can not be
changed after telling the BIOS to use it.)

I'm working with others to see if we can programatically add keys,
which we should, and if so we will offer the code up to do so (it's
published already, we are working on getting it signed by the needed
Microsoft keys right now.)

thanks,

greg k-h

Re: [gentoo-dev] borked release media

[Greg KH]

On Mon, Dec 10, 2012 at 12:21:29AM +0100, Chí-Thanh Christopher Nguyễn wrote:
 Greg KH schrieb:
  No, all we need is to enable EFI stub support in the kernel, and
  integrate the initramfs using CONFIG_INITRAMFS_SOURCE and place it in
  some location where UEFI looks for it (/efi/boot/bootx64.efi).
 
  This has the disadvantage of not allowing to pass additional kernel
  parameters during boot. But it might still be an acceptable stopgap
  measure if the alternative is to not boot at all.
  
  No, don't do that for an install kernel, that way is madness, just use
  a real UEFI bootloader which can handle an initrd and the like properly
 
 Can you explain what problems you see with that? How does
 CONFIG_INITRAMFS_SOURCE handle initrd improperly?

Ah, didn't notice that, it might work, have you tried it?

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Thu, Nov 22, 2012 at 08:20:28PM -0600, Donnie Berkholz wrote:
 
 The key misunderstanding here seems to be that initiation of a Gentoo 
 project means that the council explicitly supports it, because in most 
 distributions there is no choice available to end users at this level of 
 detail.
 
 Instead, in Gentoo, the council-level decision typically happens when 
 the *default* changes. Non-default or non-mandatory things are handled 
 in a nearly anarchic, ad hoc manner, where anyone can do pretty much 
 whatever they want as an official Gentoo project.

Yes, that was a big part of the misunderstanding.  And thankfully the
eudev project has now changed their README to not state that this is an
official Gentoo project, which will cut down on the misunderstanding by
others not familiar with the way that Gentoo handles its projects (i.e.
the whole world :)

thanks,

greg k-h

[gentoo-dev] Re: An apology for some of my earlier comments

[Greg KH]

On Tue, Nov 20, 2012 at 10:58:21PM -0500, Richard Yao wrote:
 Dear Greg,
 
 The eudev project has suffered a fair number of psychological attacks
 against project members. I know that you are a strong supporter of
 systemd. When you emailed gentoo-dev@, I assumed that you were trying to
 harm the project and treated you as such. After seeing your responses to
 people on Google+, I have realized that you are a person of greater
 integrity than I had assumed and I must apologize for my defensive
 behavior.

Thanks for the apology, I appreciate it, and accept it.

Good luck with your eudev effort.

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Mon, Nov 19, 2012 at 08:08:38PM -0500, Walter Dnes wrote:
 On Mon, Nov 19, 2012 at 09:08:52AM -0800, Greg KH wrote
 
  Again, any specific pointer to a commit in the tree that caused this?
 
   See http://wiki.gentoo.org/index.php?title=Udev/upgraderedirect=no
 Comments?

As I don't know who made those wiki changes, I don't know, but this
seems to be a choice made by the gentoo udev maintainers, not
necessarily the upstream developer's choice.

Do you see any problems when running udev in such a situation that
points at being a udev package, or udev upstream problem?

  Since this version udev depends on files in /usr. If you have /usr
  on a separate partition, you must boot your system with an initramfs
  which pre-mounts /usr.
 
   I understand that one option being considered is patching the build to
 not depend on files in /usr.  Showing my age here, I remember when IBM
 patched Windows 3.1 on-the-fly, to make it a DPMI client of OS/2.  MS
 released Windows 3.11, which vas very slightly different, and the patch
 broke.  IBM had to rush out a new patch.

Binary patching is worlds different from source/build script patching.
Those of us who have been doing this for a while can handle source
patching quite easily.

   Given how cavalierly Kay  Lennart broke firmware driver loading,

Wait, no, first off, Lennart had nothing to do with this, and secondly,
it was a kernel change that caused this to happen.  Thirdly, it's fixed
now, see my previous comments about this.

Oh, also, did this affect your systems?  Again, it was only for one type
of device that was not used by a lot of people.

That dead horse is long gone, please stop flogging it.

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Mon, Nov 19, 2012 at 07:41:54AM -0500, Anthony G. Basile wrote:
 Thank you for these responses because they did help me understand
 copyright/left better.  I appreciate your expertise in the matter
 and would hope I can draw on it again in the future, because despite
 what you said a few emails ago, copyright/left is not something that
 every software developer understands.

I'm curious as to why this is?  Didn't you learn about this in school
(if you went to school for software development), or from any company
you have worked for?  At numerous companies I have worked for, it was
part of the introduction to company FOO, here's your legal training on
what to do and not to do with regards to open source.  _ANY_ company
dealing with Linux should have this type of thing in place, otherwise,
as I have found out first hand, it can get you in big trouble.

 My fundamental confusion was over the question of what is the
 smallest copyrightable unit.  I think in terms of blame/kudos and
 the unit that comes to mind is one commit, properly isolated.  When
 a project becomes serious, I get careful about the signoffs vs
 authors vs reporters etc. And blame is as much a part of the game
 as kudos.

Yes, an individual unit of contribution is copyrightable, but, and
this is the important part, it doesn't modify the overall copyright of
the whole file unless some other criteria is met (i.e. a major change
to the file overall, this has come to mean at least 1/3 of the
logic/code.)

And then there's the overall copyright for the whole program, which too
depends on the copyrights of the individual files, that is another thing
to determine.

Yes, this isn't obvious at first glance, go consult a copyright lawyer
for the specific details if you are curious about it.

Which, again, I strongly feel that the Foundation needs to do before
anymore Copyright Gentoo Foundation marks get added to _any_ files in
our tree.

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Mon, Nov 19, 2012 at 07:03:12AM -0500, Rich Freeman wrote:
 On Sun, Nov 18, 2012 at 11:30 PM, Greg KH gre...@gentoo.org wrote:
 
  Talk to a lawyer if you disagree with this.  The area of copyright law,
  and software, is very well defined (with one exception of the major
  change to add your copyright, and even then, there's an agreed apon
  standard to follow).  Because of that, I disagree that you think this is
  something that is unknown at all.
 
 I realize that it is illegal to remove a copyright line from a work
 without permission, just as it is illegal to copy a work in the first
 place without permission.  The question is whether the GPL gives such
 permission, whether it is possible to give such permission, or at
 least whether you can give somebody this permission and then sue them
 for following through.
 
 That's my main concern here.  Can somebody say, sure, go ahead and
 remove my name from the copyright line and then sue you for doing it?

Just removing the name doesn't remove the copyright itself, but, and
this is the important thing, it shows intent.  Intent is a very
powerful thing when it comes to legal enforcement.  If you remove a
copyright line, or add your own line, you are showing what you are
wanting to do here.

So if you remove a copyright line, you are showing your intent to
remove the legal notification of the original copyright holders of the
file, which, in numerous juristictions, can be a very serious offence.

Again, talk to a lawyer for all of the details if you are curious.

 I suspect the wisest course of action for the Foundation will be to
 take the conservative approach.  However, I do not believe that this
 is because this is legally required.  It is simply a matter of not
 being wise to spend all that donated money fighting to prove that this
 is the case.  After all, even if I'm completely right, that doesn't
 mean that somebody can't sue me.  Winning a legal case in the US is a
 very expensive proposition.  I'm sure that would be the advice of any
 lawyer we retained.  All that said, a formal policy would be a good
 idea.

No one has to fight at all here, the law is very clear, and a quick
consultation with a copyright lawyer can provide us with a very good set
of rules and boundry conditions that all of us need to follow in order
to ensure that the Foundation does not get into any trouble when it
comes to copyrights.

thanks,

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Mon, Nov 19, 2012 at 11:30:58AM -0500, Walter Dnes wrote:
 On Sun, Nov 18, 2012 at 07:06:04PM -0800, Greg KH wrote
  There isn't anything in udev to change for this.  I don't understand
  why you are thinking that udev has anything to do with this issue
  at all.
 
   Before version 181, udev booted with a separate /usr.  As of 181, it
 doesn't.  If anything, I would argue that udev 181 was deliberately
 broken.  The fact is, udev made new - and insane - rules that are simply
 *invalid*.  Modern udev is broken, and needs to be fixed.

Is that because the 181 package moved files to /usr/ which is under the
control of the Gentoo packager, or because the source release of 181
upstream changed something?

I can't see anything in the 181 source release to cause this to happen,
care to point out the offending commits to me, as I must be missing
soemthing.

  It's other packages that are the problem here.
 
   You mean like systemd?  When udev got rolled into the systemd tarball,
 and started sharing code with systemd, it also inherited its
 restrictions and separate-/usr-brokeness.

Again, any specific pointer to a commit in the tree that caused this?

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Mon, Nov 19, 2012 at 06:23:44PM +, Ciaran McCreesh wrote:
 On Mon, 19 Nov 2012 09:06:53 -0800
 Greg KH gre...@gentoo.org wrote:
  No one has to fight at all here, the law is very clear, and a quick
  consultation with a copyright lawyer can provide us with a very good
  set of rules and boundry conditions that all of us need to follow in
  order to ensure that the Foundation does not get into any trouble
  when it comes to copyrights.
 
 The last time someone from Gentoo spoke to a copyright lawyer, it
 resulted in a year-or-so-long ban on recruiting anyone, and everyone
 was supposed to sign a piece of paper agreeing to turn over all their
 floppy disks and monitors to drobbins upon request.

Yes, that was due to me refusing to sign the old Gentoo copyright
assignment (well, actually, my employer at the time refused to sign it,
rightfully so.)  I thought we had that all worked out since then, as it
was, what, 8+ years ago?

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Mon, Nov 19, 2012 at 01:06:17PM -0500, Rich Freeman wrote:
 On Mon, Nov 19, 2012 at 12:06 PM, Greg KH gre...@gentoo.org wrote:
  On Mon, Nov 19, 2012 at 07:03:12AM -0500, Rich Freeman wrote:
  That's my main concern here.  Can somebody say, sure, go ahead and
  remove my name from the copyright line and then sue you for doing it?
 
  Just removing the name doesn't remove the copyright itself, but, and
  this is the important thing, it shows intent.  Intent is a very
  powerful thing when it comes to legal enforcement.  If you remove a
  copyright line, or add your own line, you are showing what you are
  wanting to do here.
 
  So if you remove a copyright line, you are showing your intent to
  remove the legal notification of the original copyright holders of the
  file, which, in numerous juristictions, can be a very serious offence.
 
  Again, talk to a lawyer for all of the details if you are curious.
 
 So, I give you a file.  Then I tell you IN WRITING that you can go
 ahead and remove my name from the copyright line if you want to.
 
 I think it would be hard for me to argue that I should be able to
 obtain damages when I gave you authorization to remove my name.

You obviously are trying to apply logic to laws.  That can not always
be done, sorry, you should know better :)

Again, if you want details, talk to a copyright lawyer.

You aren't taking my word for it, so I'm not going to try to argue the
point any further.

 That said, I'd be happy to chat with a lawyer about this, and if you
 know of any who wouldn't mind having such a conversation free of
 charge, let me know, or feel free to point them to the list.

Lawyers that work free-of-charge are rare, but the SFLC has some that
might be able to help out.

Again, the Foundation should be doing this, and set up the proper
guidelines/rules that we all follow, and then these discussions will not
need to happen.

thanks,

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Sun, Nov 18, 2012 at 05:35:22PM +0100, Francisco Blas Izquierdo Riera 
(klondike) wrote:
 El 18/11/12 04:39, Greg KH escribió:
  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.
 So I made a mistake coming out from a missunderstanding on a commit on a
 branch that didn't even get merged since I was expecting approval from
 somebody else before that. Cool. The amount of damage caused by this
 action is around the same as publishing a patch and not applying it.

Not really, having it in the repo worried a lot of people, as it was not
an acceptable thing to do.

  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.
 Check european copyright laws please, they are quite different from
 yours. I at least have had to read and understand the spanish copyright
 laws a few times and its not funny. So please don't speak of a normal
 body of copyright law there is not such thing and some of us have enough
 with the normalizations USA based lobbies are trying  to impose on ours.

I know all about European copyright laws, and if you do, I am supprised
that you changed the files in this manner, as you really can't give up
your copyright in Europe like you can in the USA.  So by adding the
Foundation's copyright here, a USA-based company, it is quite strange.

Anyway, the commit is gone, which is good, thank you for deleting the
branch.  Please be more careful about doing such things in the future.
We really don't want to get the Foundation in trouble by doing this type
of thing.

thanks,

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Tue, Nov 20, 2012 at 12:22:14AM +0100, Fabio Erculiani wrote:
 In my humble opinion, the real question is: why systemd got merged into udev?
 I would love to hear a clear technical reason for that.

I recall this was discussed on the systemd mailing list when it
happened, so you might want to look at the email archives there for
details if you are interested.

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 02:54:38AM -0500, Richard Yao wrote:
 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?

Meant by what part of the above response?  Written 6 months ago?

 Your recent comments suggest to me that you did not mean what I thought
 you meant.

What did you think I meant about what?

Again, I have no objection to people forking projects, it's great, and
fun to watch happen.  Fork away on your own site, with whom ever you
want to.

But if this fork is now the official Gentoo fork, owned by the Gentoo
Foundation, and it's the way forward that Gentoo the distro is going to
take with regards to how the boot process works on the system, then I
have something to say about it, as it affects me, a Gentoo developer.

And that is how this thread started, I wanted to know what was the
resolution of the council meeting with the very unclear and vague
meeting minutes.  I have yet to get that answer, which is troubling.

thanks,

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
 You are the one claiming that this is our official fork. None of us are.

It's on the Gentoo github site, and it has the Gentoo Foundation
copyright all over all of the files in one of the branches, reviewed by
you.

I think I would be pretty foolish if I somehow thought it was _not_ an
official fork :)

 This will be an official Gentoo project when we make the announcement in
 the next few days. That makes it one project of many. GLEP 0039 clearly
 states how this works. If you are unhappy with GLEP 0039, then you
 should discuss that with the council.

I fail to see how 0039 has to do with this, please explain.  I also
don't see the copyright issue here, nor do I see where the decision of
the council was made.

Again, that's my original question, What is the decision of the council
regarding this issue?

thanks,

greg k-h

Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]

[Greg KH]

On Sun, Nov 18, 2012 at 12:19:21AM -0800, Greg KH wrote:
 On Sun, Nov 18, 2012 at 03:10:08AM -0500, Richard Yao wrote:
  You are the one claiming that this is our official fork. None of us are.
 
 It's on the Gentoo github site, and it has the Gentoo Foundation
 copyright all over all of the files in one of the branches, reviewed by
 you.
 
 I think I would be pretty foolish if I somehow thought it was _not_ an
 official fork :)

Oh, and the README file says it is a Gentoo project:
This is a Gentoo sponsored project and testing is currently
being done with openrc.  However, we aim to be distro neutral
and welcome contribution from others using a variety of system
initializations.  We also aim towards POSIX compliance.

So why would I think otherwise?

thanks,

greg k-h

[gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Sun, Nov 18, 2012 at 07:06:50AM -0500, Rich Freeman wrote:
 COPYRIGHT
 
 I think this issue is best dealt with on the side - it has no bearing
 on any of the really contentious points here.
 
 I note that the owners of the copyright on udev have announced to the
 world that (emphasis mine):
 You may modify your copy or copies of the Library or ANY PORTION OF
 IT, thus forming a work based on the Library, and copy and distribute
 such modifications or work under the terms of Section 1 above,
 provided that you also meet all of these conditions...
 
 None of those conditions included keeping the copyright line intact.

True, but removing a copyright line doesn't change the real copyright of
a file, although it is generally considered something that you really
should not do at all (see your local copyright laws/rules for details.)

 Anybody can therefore alter the copyright line as they wish, as they
 have been given explicit permission to do so.  They need only comply
 with the other terms in the LGPL to do so (the most important being
 licensing it under the LGPL and making the source available.

Heh, wait, no, you can not do that.  You can not modify a copyright line
to add your own, without first doing one of the two things I discussed
in the beginning.  Otherwise, don't you think that all of those big
companies that are using Linux and other open source projects would have
done something like this already?

 In fact, (L)GPL v3 has an optional attribution clause, and the fact
 that they made this explicit is because some projects might not want
 to give out this authorization.

Changing the lines in the comment block in the code files is not what
attribution clauses are about at all.

I could go into details about copyright, and how it works, and how you
need to treat it if you are a programmer, but I'm not a lawyer, and the
rules are different in different countries and even states.

I have, however, worked with a very large number of lawyers, and
companies, and have the basics down, and none of what you say above is
really allowed at all, sorry.

Also note, if you just remove code from a file, you don't get copyright
of the file, which is a fun thing to think about if you are trying to
remove features from a product, or doing 'git revert' of specific
patchsets.

 So, if you want an official ruling from the trustees we would need to
 meet/vote on it and perhaps discuss with counsel, but my thinking is
 that anybody distributing work under the (L)GPL has waived their right
 to be named on the copyright line of any copies distributed by others,

Again, no, this is flat out not right.  Please discuss with counsel if
you disagree and they can go into the details.

 and as far as I can tell I have found nothing to the contrary from any
 authoritative source.

Talk to a copyright lawyer please.  I'm sure there is one that the
Foundation uses, right?

 Again, that's my two cents and not a license for anybody to do
 anything.  This topic did come up recently with regard to accepting
 some other kind of outside work into Gentoo, and as I recall there was
 some debate over whether the copyright notices could be changed.  I'd
 have to dig up the details - I think the issue might have been mooted
 before any kind of formal decision was reached...

I think this is something that the Foundation's counsel better get set
up properly, as it really is a big deal, and can come back to cause big
problems if done wrong.  I say this as someone who has been part of
lawsuits dealing with this type of thing, and as someone who has worked
with lawyers on copyright issues for open source projects for a very
long time[1].

But as always, talk to a lawyer, I suggest that the Foundation do this
to set up the proper guidelines and rules that all Gentoo developers
need to follow.  That will clear all of this confusion up properly.

thanks,

greg k-h

[1] I've worked with them so much, that I'm a continuing education
credit for lawyers in the USA when I give one of my various talks
about how open source projects are developed, and how the copyright
and license issues work within them.

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Sun, Nov 18, 2012 at 08:50:07PM -0500, Walter Dnes wrote:
 On Sat, Nov 17, 2012 at 11:52:22PM -0800, Greg KH wrote
  
  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.
 
   The fact that they went ahead with changes, knowing full well it would
 break stuff, is reason enough to distrust them in future.  It should not
 require a rant from Linus, or a workaround in the kernel, to get them to
 fix their bugs.

That's the fun of working with people you don't have direct control
over.  Bugs get fixed on different schedules than what you sometimes
like.  This specific issue, as it was hit by only a very small number of
people, and two distros had work-around patches in their udev packages,
was missed by a lot of people, myself included.  I honestly thought that
it had been fixed months ago.

Sometimes a rant, or just reminding people, is all that is needed to get
issues fixed.  And it worked here quite well, don't you think?

Actually, I would argue that it worked even better than if the issue had
been worked-around in udev in the very beginning when it first came up.
Now the kernel has changed to allow udev to remove the whole firmware
loading logic, which arguably, should have been done in the very
beginning.  So you might say that because of people forgetting about
this, and people ranting, everyone is much better off in the end.

It's a bizarre development model, I know. :)

  It's also a pretty simple set of patches that Gentoo can keep around
  if it's really a serious issue for people.
 
   That may be true today.  But as udev gets more tightly integrated into
 systemd, those patches will become a dead end, to use Lennart's words.

What patches?  udevd builds for me just fine without building the
systemd binary.  The developers even have a whole web page set up for
how to do this properly if you need to do so.

  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.
 
     I have 4 broken Gentoo systems running just fine, without an
 initrd, thank you.  There have always been a few edge-case setups that
 won't work with a separate /usr, without an initrd.  What annoys me is
 this dog-in-the-manger attitude that if a separate /usr is broken for a
 few people, then by golly, it should be broken for everybody.

Again, udev isn't the problem here.  It hasn't broken the standalone
/usr issue at all.  There isn't anything in udev to change for this.  I
don't understand why you are thinking that udev has anything to do with
this issue at all.  It's other packages that are the problem here.  Are
people forking and changing them to resolve the problem?  If not, why
not?

thanks,

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Sun, Nov 18, 2012 at 08:13:55PM -0500, Walter Dnes wrote:
 On Sun, Nov 18, 2012 at 01:51:14AM -0600, Canek Pel??ez Vald??s wrote
  
  ... 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
 
   You're missing the point entirely.  Yes, the systemd people are
 working for the good of systemd.  Nobody denies that.  Your post does
 not address the fact that Kay and Lennart hold standalone udev in
 contempt, and treat it as a 2nd-class citizen.  Note that Richard Yao is
 *NOT* forking systemd.  He is forking udev, which addresses the issue of
 Kay's+Lennart's hostility to standalone udev on non-systemd setups.  I,
 and a lot of other people, would like to use a sane standalone udev
 (from the Greg KH days) without systemd's dependancies/restrictions.
 That is the target market for a udev fork.

Heh, you really don't want udev from back in the Greg KH days.
Seriously, if you want that, go use mdev, but even then, it has more
features than when I was still running the udev project.

I find it a bit funny that people are so stuck on using udev now, they
seem to have forgotten all of these same kinds of arguments way back
when udev first came out (No one is going to force me to use udev!).
Thanks to Kay's fine work, that is no longer an issue at all.  Without
him, you wouldn't be arguing to keep using it so much.

And note, Kay and Lennart are _not_ treating udev as a second-class
citizen.  It's required for systemd to work properly, and other distros
(like Ubuntu), use it for their systems to work properly in a
stand-alone manner.  So breaking that will not happen, lots of people
will ensure that that does not happen, myself included.

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Sun, Nov 18, 2012 at 11:05:05PM -0500, Richard Yao wrote:
 On 11/18/2012 09:58 PM, Greg KH wrote:

an on-topic discussion about copyright thread response from me snipped

 We develop open source software in public repositories. A developer
 decided it would be helpful to change the software name systemd to
 eudev, among other things, in various files after misunderstanding what
 the Foundation officers in charge of legal matters had approved. You
 objected to it. I asked for clarification after seeing that your name
 had not been removed from any copyright notices. You explained your
 complaint. I asked you to wait for the person who wrote the commit to
 fix it. It was fixed.
 
 That is all that was necessary. Whining on the list did not wake the
 author of that commit sooner. Furthermore, the changes that you wanted
 would have been made in a few days had you not become involved.

None of the words you wrote here seem to me to be related to my response
about copyright, the Gentoo Foundation, and how copyright works for
software projects at all.  So I'm a bit confused, what are you concerned
about here?

greg k-h

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[Greg KH]

On Sun, Nov 18, 2012 at 07:42:11PM -0800, Diego Elio Pettenò wrote:
 On 18/11/2012 19:38, Joshua Kinard wrote:
  Correct me if wrong, but didn't the issue start with udev wanting to put the
  PCI ID database/file into /usr/share from /etc?  Then kmod was changed to
  link against libs in /usr/lib, and then udev made dependent on kmod?  I
  think that led to a scenario where openrc starts udev up before localmount
  has run, and then things fall apart.
 
 I honestly can't remember if pci.ids was ever in /etc — I always knew it
 in /usr/share/misc...

Yes, it was always in /usr/somewhere.

And the pci.ids file came from the pciutils package, not udev.

But note, we are moving that file out of pciutils (and the usb.ids file
out of usbutils) and they will eventually be generated from the udev
package itself, as it holds the master hardware database.  But that's a
totally different topic than the one at hand, and is still being worked
on by the developers of the different upstream packages.

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Sun, Nov 18, 2012 at 10:29:35PM -0500, Rich Freeman wrote:
 On Sun, Nov 18, 2012 at 9:58 PM, Greg KH gre...@gentoo.org wrote:
 
  True, but removing a copyright line doesn't change the real copyright of
  a file, although it is generally considered something that you really
  should not do at all (see your local copyright laws/rules for details.)
 
 Agreed that removing the line does not change the actual copyright of
 the file, well, aside from anything new you stick on that line.
 
 I'm not convinced that it is something you can't do if you're
 explicitly given permission to do so by the copyright holder.

Talk to a lawyer if you disagree with this.  The area of copyright law,
and software, is very well defined (with one exception of the major
change to add your copyright, and even then, there's an agreed apon
standard to follow).  Because of that, I disagree that you think this is
something that is unknown at all.

But I'm not going to be able to change your mind :)  Please get the
Foundation to write up the rules apon which Gentoo developers need to
handle the copyright mark, so that there's no disagreement as to what to
do, in any type of situation.

thanks,

greg k-h

Re: [gentoo-dev] Copyright issues (Was: udev-ng?)

[Greg KH]

On Sun, Nov 18, 2012 at 11:21:20PM -0500, Richard Yao wrote:
 On 11/18/2012 11:22 PM, Greg KH wrote:
  On Sun, Nov 18, 2012 at 11:05:05PM -0500, Richard Yao wrote:
  On 11/18/2012 09:58 PM, Greg KH wrote:
  
  an on-topic discussion about copyright thread response from me snipped
  
  We develop open source software in public repositories. A developer
  decided it would be helpful to change the software name systemd to
  eudev, among other things, in various files after misunderstanding what
  the Foundation officers in charge of legal matters had approved. You
  objected to it. I asked for clarification after seeing that your name
  had not been removed from any copyright notices. You explained your
  complaint. I asked you to wait for the person who wrote the commit to
  fix it. It was fixed.
 
  That is all that was necessary. Whining on the list did not wake the
  author of that commit sooner. Furthermore, the changes that you wanted
  would have been made in a few days had you not become involved.
  
  None of the words you wrote here seem to me to be related to my response
  about copyright, the Gentoo Foundation, and how copyright works for
  software projects at all.  So I'm a bit confused, what are you concerned
  about here?
  
  greg k-h
 
 Your issue has been resolved. You can stop beating the dead horse now.

I was responding to a discussion about how copyright works, and how it
should be marked as such for Gentoo-related projects, that was not
correct in my knowledge of copyright law.  It had nothing to do with my
issue, or the udev issue at all, which is why I even changed the
subject.

Oh well.

*plonk*

[gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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)

[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

Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)

[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)

[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] Questions about SystemD and OpenRC

[Greg KH]

On Thu, Aug 09, 2012 at 03:47:19PM -0400, Rich Freeman wrote:
 On Thu, Aug 9, 2012 at 3:24 PM, Canek Peláez Valdés can...@gmail.com wrote:
 
  I agree with Greg Kroah-Hartman: I actually like (and want) a
  vertically integrated, tightly coupled way of doing things.
 
 Well, if you completely agreed with him you wouldn't be running Gentoo
 (or Debian, or other general-purpose distros).  He advocates that
 ordinary users should use more purpose-driven distros, where all of
 this stuff is less of an issue.

That is not what I said, or mean at all.

Given that I'm a Gentoo developer, and have been for a very long time, I
find it very strange that you would think otherwise.

greg k-h