[gentoo-dev] Re: [gentoo-kernel] Dropping stable USE flags for 4.14
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
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
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
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
On Thu, Oct 27, 2016 at 10:11:45AM -0400, Rich Freeman wrote: > On Thu, Oct 27, 2016 at 9:29 AM, Greg KH 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
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
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
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
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
On Mon, Jun 30, 2014 at 04:15:55PM +0200, Jeroen Roovers wrote: > On Mon, 30 Jun 2014 09:25:27 -0400 > Rich Freeman 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?
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 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 (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
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)
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] [OT] pkgcore bikeshed (was Portage team)
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] Re: Portage QOS
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
On Fri, Aug 09, 2013 at 09:46:43PM +0200, Tom Wijsman wrote: > On Fri, 9 Aug 2013 12:30:42 -0700 > Greg KH 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
On Fri, Aug 09, 2013 at 10:34:58AM +0200, Tom Wijsman wrote: > On Thu, 8 Aug 2013 15:32:45 -0700 > Greg KH 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 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
On Fri, Aug 09, 2013 at 03:28:54PM +0200, Tom Wijsman wrote: > On Fri, 9 Aug 2013 06:38:56 -0400 > Rich Freeman 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] Gnome Stabilization 3.6 or 3.8
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
On Thu, Aug 08, 2013 at 04:37:32AM +0200, Tom Wijsman wrote: > On Wed, 7 Aug 2013 15:44:34 -0700 > Greg KH 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] Vanilla sources stabilization policy change
On Thu, Aug 08, 2013 at 04:43:09AM +0200, Tom Wijsman wrote: > On Wed, 7 Aug 2013 16:19:43 -0700 > Greg KH 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
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] Vanilla sources stabilization policy change
On Wed, Aug 07, 2013 at 11:37:21AM +0200, Tom Wijsman wrote: > On Wed, 24 Jul 2013 16:09:11 -0700 > Greg KH 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] newsitem: Kernel Team vanilla-sources policy
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
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.
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
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
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 > . 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 > ker
Re: [gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
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.
On Mon, Jul 01, 2013 at 09:25:42PM +0200, Tom Wijsman wrote: > On Mon, 1 Jul 2013 14:09:57 -0500 > Matthew Summers 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.
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.
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
[gentoo-dev] Re: [gentoo-kernel] Proper distribution integration of kernel *-sources, patches and configuration.
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] Temporary DevRel actions for CoC violations
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
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
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
Re: [gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
On Mon, Mar 11, 2013 at 07:12:43PM -0400, Rich Freeman wrote: > On Mon, Mar 11, 2013 at 6:40 PM, Rich Freeman 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
[gentoo-dev] Re: Forming Gentoo Policy - Copyright Assignment and Attribution
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] maintainer-wanted: x11-drivers/nvidia-drivers
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 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
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
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
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
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] Re: linux-firmware
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ò > 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] Proper installation path for efi binaries (.efi)
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] Proper installation path for efi binaries (.efi)
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] call for testers: udev predictable network interface names
On Wed, Jan 16, 2013 at 06:36:59AM -0500, Rich Freeman wrote: > On Tue, Jan 15, 2013 at 10:42 PM, Peter Stuge 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
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
On Fri, Dec 21, 2012 at 12:01:00AM -0500, Rich Freeman wrote: > On Thu, Dec 20, 2012 at 11:08 PM, Greg KH 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
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
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
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 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. > > > > Go
Re: [gentoo-dev] Re: eudev project announcement
On Mon, Dec 17, 2012 at 09:03:40PM +0100, J. Roeleveld wrote: > Olav Vitters 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] Soliciting Feedback: Gentoo Copyright Assignments / Licensing
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: [e]udev , and please let's move this to a better location (was: Summary Council meeting: Tuesday 11 December 2012)
On Fri, Dec 14, 2012 at 04:09:34PM -0500, Ian Stakenvicius wrote: > On 14/12/12 03:02 PM, Greg KH wrote: > > I'm guessing that the result of the council meeting meant that > > things are progressing, right? If so, in what way? > > Sounds like you should join us in #gentoo-udev to discuss, or join the > eudev mailing list. I'd rather not spend a significant amount of time > writing about eudev development on gentoo-dev@ given it's not really > on-topic here. It was discussed at the Gentoo Council meeting, how could that _not_ be on topic here? greg k-h
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 09:00:56PM +, Kevin Chadwick wrote: > > > Greg, can you write back to this message with specific examples of what > > > would need to be customized so that separate /usr would work right > > > without an initramfs? I have tried to explain multiple times that this > > > is a mis-conception that udev caused it, but I am getting nowhere. > > > > It's not my job to do this, nor yours, or fix any of these issues. It's > > up to the people who wish to keep a separate /usr partition without an > > initramfs to do this work. > > So even though you keep stating things without being specific like > udev is not a blocker, you have just admitted that the udev package > does violate the Filesystem Hiearchical Standard as well as the latest > draft when installing. Specifically how does udev violate it? And also note, FHS is a trailing standard, documenting how things are done, not how they should be done. It can be changed. And since when did Gentoo start worrying about FHS and LSB? > I can understand following the current trend (some of which I agreed > with) but what is the justification for that which didn't already have > an optional solution? I don't understand, what in the udev package, or source, goes against FHS? > p.s. embedded does not equal mobile and android uses a leaner init > than /sbin/init and experiments posted to the buildroot list found > systemd to be slower, guessed to be due to increased cycles but perhaps > memory usage on even some mobile level processors which accounts for a > fraction of linux potential in embedded applications. POSIX compliance > is also a requirement by some major industries. What does POSIX have to do with anything here? And when did I bring up systemd and boot times? That's not what this thread is about, sorry. greg k-h
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote: > On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 14/12/12 01:28 PM, Greg KH wrote: > > > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: > > >> Handling separate /usr support == > > >> After the discussion on [1] during the previous meeting, a delay > > >> of one month due to a new fork of udev was requested. We need an > > >> update on what's happened. > > >> > > >> Chainsaw reported udev and eudev have moved on, and for both it > > >> is now possible to have a separate /usr. The follow-up > > >> discussion related to the /usr-merge is necessary. > > > > > > udev was never the problem of having a separate /usr without an > > > initrd. Have all of the other packages been properly fixed to > > > resolve this issue correctly? > > > > > > Also, what's the plan for eudev going forward? > > > > > > > > > Eudev's project announcement is coming soon, should answer your questions. > > > > In terms of udev's dependencies, yes, the few dependencies that were > > installing only to /usr (ie, kmod and xz-utils) have been switched to > > install to /, and then fixed again due to issues with they way they > > were done the first time so that they also work. I believe however > > they are still ~arch keyworded. > > > > There may of course be other entirely independent packages needed at > > boot time prior to localmount, I do not know that status of those. > > Once eudev (the gentoo package) fully supports separate-/usr (which it > > doesn't at this time as it uses the same init scripts as udev-196), we > > will be sure to resolve them. > > > > It should be noted that sys-fs/udev (the package) since .. 186 I > > think? whichever version dropped support for the failed-rules queue > > (and whichever package dropped the udev-postmount init script) does > > not support booting with a separate /usr. This has more to do with > > how the package installs than the upstream code itself, though; as > > such (WilliamH please correct me if I'm wrong) the plan is still to > > require an initramfs if using sys-fs/udev with a separate-/usr. > > Greg, can you write back to this message with specific examples of what > would need to be customized so that separate /usr would work right > without an initramfs? I have tried to explain multiple times that this > is a mis-conception that udev caused it, but I am getting nowhere. It's not my job to do this, nor yours, or fix any of these issues. It's up to the people who wish to keep a separate /usr partition without an initramfs to do this work. greg k-h
Re: [gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: > On 14/12/12 01:28 PM, Greg KH wrote: > > On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: > >> Handling separate /usr support == > >> After the discussion on [1] during the previous meeting, a delay > >> of one month due to a new fork of udev was requested. We need an > >> update on what's happened. > >> > >> Chainsaw reported udev and eudev have moved on, and for both it > >> is now possible to have a separate /usr. The follow-up > >> discussion related to the /usr-merge is necessary. > > > > udev was never the problem of having a separate /usr without an > > initrd. Have all of the other packages been properly fixed to > > resolve this issue correctly? > > > > Also, what's the plan for eudev going forward? > > > > > Eudev's project announcement is coming soon, should answer your questions. Ok, when is "soon"? I'm guessing that the result of the council meeting ment that things are progressing, right? If so, in what way? > In terms of udev's dependencies, yes, the few dependencies that were > installing only to /usr (ie, kmod and xz-utils) have been switched to > install to /, and then fixed again due to issues with they way they > were done the first time so that they also work. I believe however > they are still ~arch keyworded. I am not referring to udev's dependancies, that was never the real issue with a separate /usr/ partition as those could easily be fixed with a configuration option for the package. > There may of course be other entirely independent packages needed at > boot time prior to localmount, I do not know that status of those. That's the big problem, those need to be fixed. > Once eudev (the gentoo package) fully supports separate-/usr (which it > doesn't at this time as it uses the same init scripts as udev-196), we > will be sure to resolve them. Again, udev itself was never an issue, it could work just fine with a separate /usr/ partition. Now perhaps our ebuild didn't build it in that matter, but that's a configuration/ebuild issue, not a upstream package issue. > It should be noted that sys-fs/udev (the package) since .. 186 I > think? whichever version dropped support for the failed-rules queue > (and whichever package dropped the udev-postmount init script) does > not support booting with a separate /usr. This has more to do with > how the package installs than the upstream code itself, though; as > such (WilliamH please correct me if I'm wrong) the plan is still to > require an initramfs if using sys-fs/udev with a separate-/usr. If the plan is still to require an initramfs (hint, it's the only way it can work), then why was the eudev package forked and created? Please, I'm totally confused now, especially after reading the commits in the eudev repo, I see nothing that fixed any /usr/ problems, what am I missing? Oh, you also slowed the build time of the package down in eudev compared to udev, but I'm sure you realized that already, and did it for a good reason. confused, greg k-h
[gentoo-dev] Re: [gentoo-dev-announce] Summary Council meeting: Tuesday 11 December 2012
On Fri, Dec 14, 2012 at 11:43:41AM +0100, Fabian Groffen wrote: > Handling separate /usr support > == > After the discussion on [1] during the previous meeting, a delay of one > month due to a new fork of udev was requested. We need an update on > what's happened. > > Chainsaw reported udev and eudev have moved on, and for both it is now > possible to have a separate /usr. The follow-up discussion related to > the /usr-merge is necessary. udev was never the problem of having a separate /usr without an initrd. Have all of the other packages been properly fixed to resolve this issue correctly? Also, what's the plan for eudev going forward? thanks, greg k-h
Re: [gentoo-dev] borked release media
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
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] borked release media
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ò > 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
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ò > 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
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
On Sun, Dec 09, 2012 at 01:35:57PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 1:24 PM, Greg KH 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
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
On Sun, Dec 09, 2012 at 01:13:38PM -0500, Rich Freeman wrote: > On Sun, Dec 9, 2012 at 1:07 PM, Fernando Reyes > 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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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
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)
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/upgrade&redirect=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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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] Copyright issues (Was: udev-ng?)
On Mon, Nov 19, 2012 at 01:06:17PM -0500, Rich Freeman wrote: > On Mon, Nov 19, 2012 at 12:06 PM, Greg KH 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] Copyright issues (Was: udev-ng?)
On Mon, Nov 19, 2012 at 06:23:44PM +, Ciaran McCreesh wrote: > On Mon, 19 Nov 2012 09:06:53 -0800 > Greg KH 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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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?)
On Mon, Nov 19, 2012 at 07:03:12AM -0500, Rich Freeman wrote: > On Sun, Nov 18, 2012 at 11:30 PM, Greg KH 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] Copyright issues (Was: udev-ng?)
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?)
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: > > > > > > > >> 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*
Re: [gentoo-dev] Copyright issues (Was: udev-ng?)
On Sun, Nov 18, 2012 at 10:29:35PM -0500, Rich Freeman wrote: > On Sun, Nov 18, 2012 at 9:58 PM, Greg KH 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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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?)
On Sun, Nov 18, 2012 at 11:05:05PM -0500, Richard Yao wrote: > On 11/18/2012 09:58 PM, Greg KH wrote: > 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)
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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
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
[gentoo-dev] Copyright issues (Was: udev-ng?)
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] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
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
Re: [gentoo-dev] Tightly-coupled core distro [was: Council meeting summary for 3 April 2012]
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]
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] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:02:19PM -0800, Alec Warner wrote: > 1) systemd-udev will require systemd. Stated by the systemd > maintainers themselves as a thing they want to do in the future. Some > users don't want to use systemd. We could go into detail as to why; > but I think that is not as important as one may think. The point is > that the desire is there, and thusly there are users who want to make > other systems (namely openrc) work. > > People like openrc. My VMs for instance, boot reasonably quickly. > Booting 5 seconds faster may be super duper, but not at the cost of an > existing reliable solution. So is this the goal? Great, someone say that then, that's all I'm asking for here. > > That's wonderful, seriously. But why is this suddenly an official > > Gentoo project? When did that happen, and why? Why not just do a > > "normal" project and if it matures and is good enough, then add it to > > the distro like all other packages are added. > > > > My main point here is the fact that this is now being seen as an act by > > Gentoo, the distro / foundation. And that happened in private, without > > any anouncement. Which is not good on many levels. > > I'm unsure on what grounds you disapprove. People start (and abandon) > projects often in Gentoo. Suddenly you dislike one such project and > object to this practice? Certainly if we had to get some sort of > Foundation consensus (for anything) nothing would happen. We can't > even get more than 40% of foundation members to vote. I object if this is seen as a "Gentoo blessed" fork of a community project that is worked on by all other major Linux distros. That is the type of decision that can be made by the Gentoo Council, which is fine, but it sure would be nice if it were publicly stated, instead of having to see it on the Gentoo github site instead. And if that is the decision of the council, I would expect the ability to have some type of discussion about it, wouldn't you? Also, the whole issue with the copyrights is very serious, for the reasons I've stated before. Don't mess with copyrights, developers, and companies, take them very serious, as they are the basis for our licenses. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 02:05:39AM -0500, Walter Dnes wrote: > On Sat, Nov 17, 2012 at 07:29:22PM -0800, Greg KH wrote > > > But, along those lines, what is the goal of the fork? What are you > > trying to attempt to do with a fork of udev that could not be > > accomplished by: > > - getting patches approved upstream > > or: > > - keeping a simple set of patches outside of the upstream tree and > > applying them to each release > > That approach would be viable if upstream were co-operative or gave a > damn about anybody else. They've broken people's sytems with the "new > and improved" udev, and claimed that people's systems were already > broken. Kay Sievers got Linus angry enough to go on a rant. See > https://lkml.org/lkml/2012/10/3/484 Yes, I know all about the firmware issue with media drivers. It's now resolved and fixed, in two different ways (the kernel now loads firmware directly, and on older kernels, udev has fixed the issue.) So that's no longer an issue for anyone. > In short, the systemd-udev people are hard to work with in general, > and have a dislike for Gentoo. Good luck with getting patches accepted > by them. The fact that Gentoo is alone in wanting to build udev, without systemd dependencies being on the system, is something that if I were the systemd maintainer, I would reject. It's also a pretty simple set of patches that Gentoo can keep around if it's really a serious issue for people. > > Oh, and if _anyone_ thinks that changing udev is going to "solve" the > > "no separate /usr without an initrd" issue, I have a bridge I want to > > sell them. > > If udev-systemd merely broke a filesystem layout that functioned very > well in linux for 2 decades, you would not be seeing this rebellion. Note, a separate /usr has been broken for a while now, udev is just pointing the issue out. And again, if you want a separate /usr, just use an initrd, the solution is simple. > udev-systemd is also breaking media drivers. The entire thread > https://lkml.org/lkml/2012/10/2/194 gives an idea of just how badly Kay > has screwed up udev. You participated in that thread. Again, this is now resolved, no need to keep beating it :) > How many people have read Siever's post? > http://lists.freedesktop.org/archives/systemd-devel/2012-July/006065.html > > We promised to keep udev properly *running* as standalone, we never > > told that it can be *build* standalone. And that still stands. > > > > We never claimed, that all the surrounding things like documentation > > always fully match, if only udev is picked out of systemd. > > > > I would welcome if people stop reading that "promise" into the > > announcement, it just wasn't written there. > > You (the former udev maintainer) are saying that a standalone udev > *WITHOUT SYSTEMD* will always be possible. The current maintainer is > saying that isn't necessarily true. Who do you expect me to believe? They are saying it as well. It's Gentoo that is unique in wanting to build it without the rest of the systemd package as well. Two different things here. > You also wrote... > > > And is something that small really worth ripping tons of code out of > > a working udev, causing major regressions on people's boxes (and yes, > > it is a regression to slow my boot time down and cause hundreds of > > more processes to be spawned before booting is finished.) > > Some people are finding firmware drivers not loading, and the cards > not functioning. Don't you consider that a regression? Again, been a bug for 6 months, hit by very few people, now resolved, not an issue. > Seiver's response is basically the same as for people with separate > /usr; telling them that they have to re-write their drivers to > accomadate the "new and improved" udev. And people whose drivers > don't fail entirely now get a 60-second delay while udev times out > before loading the firmware in another manner. Those people have seen > their bootup times increased by a full minute. Do you not consider > that a regression? Again, now resolved, not an issue. > > You need to have a real solid goal in place in order to be able to keep > > this up in the long-run. Otherwise you are going to burn yourself out, > > and end up alienating a lot of people along the way. > > Howsabout a standalone udev, with no dependancies on systemd, and it > won't break people's systems? If that is the goal, great, it would be wonderful if someone would say that. But from looking at the commits so far in the repo, it really doesn't look like that is the goal. Or if it is, it's getting there in a very odd way. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On 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&
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:13:37AM -0500, Richard Yao wrote: > We do not need to justify the need for our project before it is > announced or even after it is announced. It is free to conflict with > RedHat's systemd project. If we find next year that we can reconcile > with Kay Sievers and Lennart Poettering, then we are free to do that. > These projects need not be long term commitments. systemd is not a "Red Hat" project at all. It just happens to have some of the developers of it working for them. If that is their job to develop it or not, is unknown to all of us. Also, in the beginning of systemd, a lot of the code, and research, was done by someone working for a distro different than Red Hat. systemd is a freedesktop.org project, that is all, please don't play this as a distro-vs-distro issue, otherwise it will end up looking like it is a "Gentoo vs. the world" thing, and I, as a long-term Gentoo developer, do not want that at all. So, I'll say this again, why is this project getting the copyright of the Gentoo Foundation? Is it an "official" project of Gentoo in some manner? And, to all of you who have emailed me privately saying they don't want to talk about this on-list, that's what gentoo-core is for, I'd be glad to take it there if you feel gentoo-dev is to "public" for stuff like this. Otherwise, this is opensource, we do development in the open, not in private. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 12:00:52AM -0500, Richard Yao wrote: > > I'm genuinely interested in your goals, in detail, otherwise I would > > not have asked about them. Perhaps I am totally wrong and your fork > > makes sense, perhaps, to me, not. But without knowing such goals, > > there's no way that anyone can get an idea about this. > > I am afraid that I have to disappoint you. If we were using the > waterfall model, I could outline some very nice long term goals for you, > but we are doing AGILE development, so long term goals have not been > well defined. Some short term goals have been defined, but I imagine > that you are already familiar with them. I suggest asking again after > our first tag. I'll ignore the fact that project goals have nothing to do with waterfall or agile, and ask, what are your short-term goals? Why is this an "official" Gentoo project without this being discussed in an open manner? > A consequence of being open source means that everyone can see what we > do, so people are able to send us their opinions on things that have not > been officially announced, much like this project. Given that the Gentoo Foundation is claiming copyright on this project now, not announcing it seems a bit rude to the rest of us who make up this foundation, don't you think? That's not very open :( > > I understand the bizarre need of some people to want to build the udev > > binary without the build-time dependencies that systemd requires, but > > surely that is a set of simple Makefile patches, right? And is > > something that small really worth ripping tons of code out of a working > > udev, causing major regressions on people's boxes (and yes, it is a > > regression to slow my boot time down and cause hundreds of more > > processes to be spawned before booting is finished.) > > See the following: > > https://github.com/gentoo/eudev/issues/3 > >>> > >>> You moved from an explicit to an implicit dependency. It's not > >>> inspiring any sense of confidence from me that there is an understanding > >>> of how things work here. > >>> > >>> Seriously, the codebase you are working with isn't that large, or > >>> complex, at all. To go rip stuff out, only to want to add it back in > >>> later, wastes time, causes bugs, and goes against _any_ software > >>> methodology that I know of. > >> > >> I can say the same about the manner in which these changes were > >> introduced. Ripping them out to get the codebase back into a state from > >> which we are comfortable moving forward is the only sane way of dealing > >> with them. > > > > Wait, what? The kmod introduction was deliberate and solves a real > > problem. kmod itself was created _because_ of these issues that had > > been seen and found. It was written for the systemd/udev projects to > > use, and had been worked on for a long time by a number of developers. > > By removing it, you have now negated that solution and we are back to > > the old problems we had before. That doesn't seem very wise to me, does > > it to you? > > > > thanks, > > > > greg k-h > > Having a builtin is a good idea, but the implementation as a mandatory > dependency on kmod is not. The plan is to reintroduce it as an optional > dependency, so that distributions (and Gentoo users) that do not want it > can avoid it. None of us want to force dependencies on others and there > is no need for this one. You do realize that you didn't really drop the dependency at all, right? > With that said, Linux distributions are victims of people continually > trying to reinvent the wheel with no formal planning. Huh? Really? It's as if you think we all are just throwing stuff against the wall and seeing what sticks? We aren't responding to real users, customers, research, history, and competitors? Your dismissal of the people who create the system you are using seems pretty bold. > At some point, someone has to enforce a form of structure where > further change occurs in a well defined manner and change because we > can is rejected as being pointless. That is what we want and that is > what we feel that our users want. Ok, what is that structure you are wishing were present? What problems do you have with systemd on a technical level that are not being addressed? What technical problems with udev do you have that caused this to be forked? What problems are you wishing to solve, and what goals do you have by doing all of this? Have you studied the problem area for booting, process monitoring, system isolation, device creation and notification, persistant naming, multiple users with multiple displays, and the like, and found that Linux is lacking in this area? If so, I would love to learn more, as I want Linux, and Gentoo, to succeed. Without knowing the problems you are having, there's no way anyone will ever change. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: > On 11/17/2012 10:39 PM, Greg KH wrote: > > Anyway, I now see a _very_ dangerous commit in the "Copyright" branch > > that better not get merged into the tree, as it's wrong, and illegal > > under all countries that follow the "normal" body of Copyright Law. It > > should be removed right now before someone gets into trouble, not the > > least of which would be the orginization that the copyright is now being > > attributed to. > > > > Come on people, this is basic copyright law, it's not something > > radically new. It's something that _all_ software developers should > > know, either from school, or any company they have ever worked at. > > > > Please fix this now. > > klondike discussed the copyright branch changes with robbat2 before they > started and there was no problem at the time. We have retained all > copyright notices and looking at the branch, I find nothing objectionable. Why is this getting a Gentoo Foundation copyright in the first place? Why is that necessary? greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:26:41PM -0500, Richard Yao wrote: > > Thanks for clarifying that. It will be fixed before it goes into HEAD. I recommend deleting the branch and starting over, having that commit floating around like that could cause trouble. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sun, Nov 18, 2012 at 04:28:00AM +, Robin H. Johnson wrote: > On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: > > On 11/17/2012 10:39 PM, Greg KH wrote: > > > Anyway, I now see a _very_ dangerous commit in the "Copyright" branch > > > that better not get merged into the tree, as it's wrong, and illegal > > > under all countries that follow the "normal" body of Copyright Law. It > > > should be removed right now before someone gets into trouble, not the > > > least of which would be the orginization that the copyright is now being > > > attributed to. > > > > > > Come on people, this is basic copyright law, it's not something > > > radically new. It's something that _all_ software developers should > > > know, either from school, or any company they have ever worked at. > > > > > > Please fix this now. > > klondike discussed the copyright branch changes with robbat2 before they > > started and there was no problem at the time. We have retained all > > copyright notices and looking at the branch, I find nothing objectionable. > To note here, since I was CC'd directly: > I said changed files should get the modified notice, as Gentoo should have > copyright on the changes that are explicitly new by Gentoo. I didn't say to > add > it to every file in the repo (but I will admit that I didn't tell him not to > either). > > I'll state it clearly what should be the case: > - the s/systemd/eudev/ line, and insertion of "From prior code in systemd and > pre-systemd udev" being added now is fine. > - WHEN substantial changes are made to an existing file, the copyright > attribution should be amended to include the Gentoo Foundation. The > attribution should NOT be changed before this. Better text given the > existing > wording would be: > Portions Copyright 2012 Gentoo Foundation. > > - Files that have no copyright notice should NOT be touched until such time as > a major addition is added to them. > > http://dpaste.com/832634/ is what I approved with klondike (his 2nd paste to > me > in the discussion). That makes sense, but is not what ended up in that commit. The commit needs to be removed. Also, how can any new work be assigned to the Gentoo Foundation? Is there an explicit copyright assignment happening somewhere that I am not aware of? thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:25:11PM -0500, Richard Yao wrote: > On 11/17/2012 11:19 PM, Greg KH wrote: > > On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: > >> On 11/17/2012 10:29 PM, Greg KH wrote: > >>> I see an "entertaining" fork of udev on github at the moment (-ng, > >>> really? What happens when someone wants to fork that, -ng-ng? Be a bit > >>> more original in your naming please, good thing I never trademarked > >>> "udev" all those years ago, maybe I still should...) > >> > >> That was a placeholder name. If you checked before you sent your email, > >> you would see that we had settled on eudev. > > > > The name change still doesn't make it any less "entertaining" :) > > > > What does the "e" stand for? > > That is a common question. Someone associated with Canonical suggested > that e stand for embedded. Others consider the "eu" prefix to be the > greek root for "true". Honestly, we don't care. It is just a name. I wouldn't pick "embedded" as the embedded world is now using systemd as it meets their requirements much better than anything else :) > >>> But, along those lines, what is the goal of the fork? What are you > >>> trying to attempt to do with a fork of udev that could not be > >>> accomplished by: > >>> - getting patches approved upstream > >>> or: > >>> - keeping a simple set of patches outside of the upstream tree and > >>> applying them to each release > >> > >> The goal is to replace systemd as upstream for Gentoo Linux, its > >> derivatives and any distribution not related to RedHat. > > > > Wait, really? You want to replace systemd? Then why are you starting > > at udev and not systemd? > > > > What is wrong with systemd that it requires a fork? All other distros > > seem to be participating in the development process of systemd quite > > well, what is keeping Gentoo developers from also doing the same? > > > > What are your goals, specifically, in detail. > > Is there any way that the answer to your inquiry would result in a > productive conversation where you would not attempt to dictate what we do? The only thing I'm "telling" anyone to do is to fix the copyright mess they created, as it is a legal liability for the Gentoo Foundation, which I care about. That HAS to be resolved. I'm genuinely interested in your goals, in detail, otherwise I would not have asked about them. Perhaps I am totally wrong and your fork makes sense, perhaps, to me, not. But without knowing such goals, there's no way that anyone can get an idea about this. > >>> I understand the bizarre need of some people to want to build the udev > >>> binary without the build-time dependencies that systemd requires, but > >>> surely that is a set of simple Makefile patches, right? And is > >>> something that small really worth ripping tons of code out of a working > >>> udev, causing major regressions on people's boxes (and yes, it is a > >>> regression to slow my boot time down and cause hundreds of more > >>> processes to be spawned before booting is finished.) > >> > >> See the following: > >> > >> https://github.com/gentoo/eudev/issues/3 > > > > You moved from an explicit to an implicit dependency. It's not > > inspiring any sense of confidence from me that there is an understanding > > of how things work here. > > > > Seriously, the codebase you are working with isn't that large, or > > complex, at all. To go rip stuff out, only to want to add it back in > > later, wastes time, causes bugs, and goes against _any_ software > > methodology that I know of. > > I can say the same about the manner in which these changes were > introduced. Ripping them out to get the codebase back into a state from > which we are comfortable moving forward is the only sane way of dealing > with them. Wait, what? The kmod introduction was deliberate and solves a real problem. kmod itself was created _because_ of these issues that had been seen and found. It was written for the systemd/udev projects to use, and had been worked on for a long time by a number of developers. By removing it, you have now negated that solution and we are back to the old problems we had before. That doesn't seem very wise to me, does it to you? thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:06:38PM -0500, Richard Yao wrote: > On 11/17/2012 10:39 PM, Greg KH wrote: > > Anyway, I now see a _very_ dangerous commit in the "Copyright" branch > > that better not get merged into the tree, as it's wrong, and illegal > > under all countries that follow the "normal" body of Copyright Law. It > > should be removed right now before someone gets into trouble, not the > > least of which would be the orginization that the copyright is now being > > attributed to. > > > > Come on people, this is basic copyright law, it's not something > > radically new. It's something that _all_ software developers should > > know, either from school, or any company they have ever worked at. > > > > Please fix this now. > > klondike discussed the copyright branch changes with robbat2 before they > started and there was no problem at the time. We have retained all > copyright notices and looking at the branch, I find nothing objectionable. Seriously? Look at the comment I made on that commit for details, but here it is again: You can not claim copyright on a file you did not do one of the two things: - create yourself - modify in a "major" manner Adding a comment at the top saying it is part of the eudev project and covered under the LGPL2+ does not meet either of these requirements at all. By merely importing a file into a new project, you can not claim copyright on it. That's the law. The fact that this was reviewed by someone makes me seriously wonder about the copyright policies of the Gentoo Foundation. Also, you can not assign copyright to a third party, unless you have a copyright assignment form. Do the developers doing this work have such a form assigned? And in what country and state is that form valid for? Different countries, and states, have different laws here, and one-form-fits-all is not true anywhere. So blindly adding a Gentoo Foundation copyright to _any_ file in this repo, that has not met one of the two above rules, is illegal, and grounds for opening the Gentoo Foundation up to big trouble. > Would you mind joining us in IRC to discuss your concerns? I don't do IRC anymore, sorry. Email is the best way to reach me. thanks, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 11:02:00PM -0500, Richard Yao wrote: > On 11/17/2012 10:29 PM, Greg KH wrote: > > I see an "entertaining" fork of udev on github at the moment (-ng, > > really? What happens when someone wants to fork that, -ng-ng? Be a bit > > more original in your naming please, good thing I never trademarked > > "udev" all those years ago, maybe I still should...) > > That was a placeholder name. If you checked before you sent your email, > you would see that we had settled on eudev. The name change still doesn't make it any less "entertaining" :) What does the "e" stand for? > > But, along those lines, what is the goal of the fork? What are you > > trying to attempt to do with a fork of udev that could not be > > accomplished by: > > - getting patches approved upstream > > or: > > - keeping a simple set of patches outside of the upstream tree and > > applying them to each release > > The goal is to replace systemd as upstream for Gentoo Linux, its > derivatives and any distribution not related to RedHat. Wait, really? You want to replace systemd? Then why are you starting at udev and not systemd? What is wrong with systemd that it requires a fork? All other distros seem to be participating in the development process of systemd quite well, what is keeping Gentoo developers from also doing the same? What are your goals, specifically, in detail. > > I understand the bizarre need of some people to want to build the udev > > binary without the build-time dependencies that systemd requires, but > > surely that is a set of simple Makefile patches, right? And is > > something that small really worth ripping tons of code out of a working > > udev, causing major regressions on people's boxes (and yes, it is a > > regression to slow my boot time down and cause hundreds of more > > processes to be spawned before booting is finished.) > > See the following: > > https://github.com/gentoo/eudev/issues/3 You moved from an explicit to an implicit dependency. It's not inspiring any sense of confidence from me that there is an understanding of how things work here. Seriously, the codebase you are working with isn't that large, or complex, at all. To go rip stuff out, only to want to add it back in later, wastes time, causes bugs, and goes against _any_ software methodology that I know of. confused, greg k-h
Re: [gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 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
[gentoo-dev] udev-ng? (Was: Summary Council meeting Tuesday 13 November 2012)
On Sat, Nov 17, 2012 at 08:02:07PM +0100, Fabian Groffen wrote: > Handling separate /usr support > == > WilliamH requested approval for two methods to support separate /usr > systems[2]. The discussion is closely related to recent opinons on udev, such > as e.g. [1], because the main reason to force a system without separate /usr > during boot is to allow newer versions of udev to be used. > The originally announced item of discussing the removal of gen_usr_ldscript > has been retracted[4]. > - approve/disapprove plan (forcing everyone to take action, and > implement one of the two "supported" solutions) > > WilliamH requests a council vote to allow migrating everyone after bugs > [5,6,7] are resolved. He proposes a news item to announce this that allows to > assume after a given period of time that everyone who is using split /usr is > using a method to mount /usr before boot. The focus is purely on this topic. > > rich0 prefers to move on until suport for separate /usr becomes a > barrier, and handle things from there. This allows for alternative > solutions to be developed and put forward. He favours waiting somewhat > to see developments of the udev fork. > > Chainsaw is a strong proponent for waiting a month and see how the new > udev fork develops itself. If within a month no solution is provided by > the udev fork, things need to be moved forward in WilliamH's proposed > way. > > scarabeus approves the plan. > > betelgeuse likes to ensure users won't be caught off guard, but has no > preference for any direction taken in particular. > > graaff's main concern is how the problem is tied to udev, or not. A fork of > udev may not change the situation regarding separate /usr, hence delaying a > decision now is not sensical. Opt-in system for people to ensure they can > boot is pre-requisite. If this cannot be ensured, we have to wait. > > grobian disapproves the plan, since there will be systems that cannot easily > be changed to ensure /usr being mounted at boot, and it is no good to expel > users of (security) updates just because of that. With the use of a special > profile (masks/unmasks, variables and/or use-flags), users that want to move > on, can opt-in to getting packages that require non separate /usr. So, that's a nice summary, but, what is the end result here? I see an "entertaining" fork of udev on github at the moment (-ng, really? What happens when someone wants to fork that, -ng-ng? Be a bit more original in your naming please, good thing I never trademarked "udev" all those years ago, maybe I still should...) The commits so far in that repo are fun to watch for a variety of reasons, none of which I should repeat hear less I get a bunch of people mad at me :) But, along those lines, what is the goal of the fork? What are you trying to attempt to do with a fork of udev that could not be accomplished by: - getting patches approved upstream or: - keeping a simple set of patches outside of the upstream tree and applying them to each release I understand the bizarre need of some people to want to build the udev binary without the build-time dependencies that systemd requires, but surely that is a set of simple Makefile patches, right? And is something that small really worth ripping tons of code out of a working udev, causing major regressions on people's boxes (and yes, it is a regression to slow my boot time down and cause hundreds of more processes to be spawned before booting is finished.) As I posted elsewhere, working on a project based on "hate" only lasts so long. I should know, that's the reason I started udev in the first place over 9 years ago[1]. You need to have a real solid goal in place in order to be able to keep this up in the long-run. Otherwise you are going to burn yourself out, and end up alienating a lot of people along the way. Oh, and if _anyone_ thinks that changing udev is going to "solve" the "no separate /usr without an initrd" issue, I have a bridge I want to sell them. thanks, greg k-h [1] Long story, best told over beers, take me up on it the next time you see me, I'll buy.
Re: [gentoo-dev] Questions about SystemD and OpenRC
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 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
