[10:23] <apw> LocutusOfBorg1, hiya, i see the new 5.0 virtual box doesn't yet have 4.2 support, is that coming soon or should i patch ubuntu up for it
[10:24] <apw> LocutusOfBorg1, i have a patch here i am using for the kernel import which fixes the symlink api in it, if thats of use
[10:28] <LocutusOfBorg1> hi apw answering there
[10:28] <LocutusOfBorg1> sorry for the late answer
[10:28] <LocutusOfBorg1> you can mail at locutusofborg@d.o
[10:28] <apw> (heh no late answer)
[10:29] <LocutusOfBorg1> s/d/debian
[10:29] <LocutusOfBorg1> s/o/org
[10:29] <apw> LocutusOfBorg1, will do indeed
[10:29] <LocutusOfBorg1> but wait please
[10:29]  * apw waits
[10:29] <LocutusOfBorg1> I'm opening an RC right now on Debian
[10:29] <LocutusOfBorg1> I wont virtualbox kicked out of Debian and Ubuntu
[10:29] <apw> oh ... why?
[10:35] <LocutusOfBorg1> I'll link it there ;)
[10:35] <LocutusOfBorg1> as soon as I finish the mail
[10:35] <apw> :)
[10:47] <LocutusOfBorg1> bug sent
[10:47] <LocutusOfBorg1> let BTS do the job and I'll post the link
[10:47] <LocutusOfBorg1> anyway, which files are changed?
[10:48] <LocutusOfBorg1> because as usual upstream should have already patched the sources
[10:48] <LocutusOfBorg1> and I usually update virtualbox with the latest release after the freeze, to be syncd with the kernel
[10:50] <apw> LocutusOfBorg1, vbox/vboxsf/lnkops.c they ahve changed the follow_link()/put_link() api, rather radically
[10:50] <apw> though the fixes are not big if that makes sense
[10:51] <apw> that is what i am using against what is in the 5.0.0 package for the kernel modules we have sucked in http://paste.ubuntu.com/11992242/
[10:53] <LocutusOfBorg1> https://github.com/mdaniel/virtualbox-org-svn-vbox-trunk/commit/78627d149e35f21b689dec7977c9d6c386ad71e6
[10:53] <LocutusOfBorg1> apw, ^^^ ?
[10:54] <apw> LocutusOfBorg1, yep that looks to be equivalent indeed, and better
[10:57] <apw> LocutusOfBorg1, so this is about opaque oracle, sigh
[11:50] <LocutusOfBorg1> bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
[11:50] <LocutusOfBorg1> apw, ^^^ yes (sorry I was lunching)
[11:59] <apw> heh np
[15:52] <apw> tseliot, guess what ... dkms packages for 4.2 are all unhappy (again)
[15:53] <tseliot> apw: yay for breaking the API. What kernel version are you using?
[15:54] <apw> 4.2-rc4 i think, though we have an upload about to land
[15:54] <tseliot> also why does dkms report building for both amd64 and x86_64 in the same chroot???
[15:54] <tseliot> dkms status
[15:54] <tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, amd64: installed
[15:54] <tseliot> fglrx-core, 15.200.1, 4.1.0-3-generic, x86_64: installed
[15:55] <apw> gurgle :)
[15:55] <tseliot> oh, and BTW, I won't be able to fix nvidia for Linux 4.2, as kernel devs keep making functions GPL only...
[15:56] <apw> tseliot, fun
[15:56] <tseliot> oh, you have no idea ;)
[15:56] <apw> they need to start loadin the binary driver itself as a firmware blob
[15:56] <apw> then their driver can be GPL
[15:58] <tseliot> yes, that's probably the only way to do it, other than open sourcing everything (in our dreams)
[15:59] <apw> my very wet dreams
[16:03] <tseliot> hehe
[16:04] <apw> the _GPL is an utter farce whoever added that deserves a beatng
[16:04] <tseliot> +1000
[16:05] <apw> tseliot, actually it is not at all clear to me that they couldn't write a wrapper which was propriatry which literally only exported the binary interfaces in the binary blobs as wrap_name 1 for 1
[16:06] <apw> and then the existing GPL bits be a second module which is self contained and therefore GPL
[16:06] <apw> which uses both sets ... which demonstrates how the _GPL is a farse
[16:07] <ohsix> intent isn't ambiguous
[16:07] <ohsix> someone could do that, but it would be an overt action for 'reasons'
[16:08] <apw> ohsix, the intent is that only GPL things can link to that interface
[16:08] <apw> the intent isn't to make ordinary users lives vile
[16:10] <tseliot> :)
[16:10] <apw> and if one could not allow GPL code to talk to proprietaory blobs, then we couldn't talk to the bios
[16:10] <apw> nor to disk drives with firmware, or nics or ...
[16:11] <ohsix> that's not even remotely the same, heh; the question is over whether something is a derived work or not and symbol licenses make it unambiguous in certain places
[16:11] <ohsix> if there was an eula or literally anything that said you couldn't talk to the firmware on something then you'd be bound by that too
[16:12] <apw> ohsix, except that i am not sure you'd find that the licence exactly says any of the things either of us think is does, because lawyers
[16:12] <apw> none of the clarity we think is there, really is
[16:13] <ohsix> the question is of whether it is a derived work
[16:13] <ohsix> and the hazard with figuring that out in court
[16:13] <apw> indeed, and i'd contend "we don't know" is the only correct answer
[16:13] <ohsix> that's pretty clear
[16:13] <ohsix> you do know if the developer knows it is a significant feature of linux and states the symbol is gpl
[16:13] <apw> ohsix, i'd also contend that the intent of the writer of the _GPL in the main is to punish the _vendor_
[16:13] <apw> ohsix, but in the main they are punishing the end user
[16:14] <apw> but then i have a modicom of pragmatism for a geek
[16:14] <ohsix> if the vendor cared about the user so much they wouldn't feel threatened by such a silly scheme ;]
[16:14] <apw> i make not comment on how stupid vendors can be
[16:15] <apw> i claim that the effort upstream only hurts users
[16:15] <ohsix> the derived work thing regarding the gpl is pretty well understood, what it means for the kernel is not
[16:15] <apw> as here, we likley won't have binary drivers fo nvidia going forward, and that makes users lives hard
[16:16] <ohsix> companies may end up creating derived works when they use the thing and at least the right parties will know it is happening
[16:17] <apw> i contend that we won't know any more than we do now, as they can cheat, and cheat in hidden code and you can't tell
[16:17] <apw> which is what makes it a farse
[16:17] <ohsix> drivers from staging taint the kernel for other reasons
[16:17] <apw> this isn
[16:17] <apw> isn't about taint, this is about not being able to do things
[16:17] <ohsix> you can tell, though; and if it comes down to it you can demonstrate intent to work around things
[16:17] <ohsix> it is about disclosure
[16:18] <ohsix> with symbol license statements every party knows what is up with respect to that symbol
[16:18] <apw> it is a legally questionable farse imo, but then my opinion counts for almost nothing
[16:18] <apw> take for example the case where we have an EXPORT_SYMBOL for something
[16:18] <apw> and someone changes the implementation and adds a dependancy which is _GPL
[16:19] <apw> now you have made that interface break the inner one, and if you fix it you break
[16:19] <apw> people who had every right to think they could use it
[16:19] <apw> its just stupid
[16:19] <apw> as happened with locks recently, so nothing could use locks
[16:19] <apw> its just not sustainable
[16:20] <apw> IMO the point of GPL code is to let people do what they want with their computers without big companies getting rich off it
[16:20] <apw> and _this_ is not served at all by this mess
[16:20] <ohsix> people don't have a problem with published shims and a blob, or having any given user being the one to knowingly put them together
[16:20] <apw> a case where the implementation does _not_ meet the goal and all because of the wording of a licence
[16:21] <apw> ohsix, except you can't use an _GPL symbols in such a case because the rules are blakc and white
[16:21] <apw> this is the exact case that the nvidia shim plus clearly and demonstrably externally created blob faces
[16:21] <apw> this is not the intent (imo) of the gpl
[16:22] <apw> yes its what the words say, but it is not the intent
[16:22] <ohsix> the shim creates an environment that is stable for the code to run in, you essentially need it regardless of whether there's a blob somewhere
[16:23] <apw> indeed, but that it links to the blob makes it not GPL and by becoming not GPL it cannot use the kernel any more
[16:23] <apw> so that makes the whole thing pointless, even though you are doing waht is recommended as a solution
[16:23] <apw> this is why _GPL is a bad solution to any problem
[16:25] <ohsix> well there is an analogy to a very american thing, you can buy the lower receiver for an m16, that part 'is' the gun, but it is not a 'gun' until you put the other 95% on it, the barrel, trigger mechanism, butt stock
[16:25] <apw> all my non-lawyer personal opinion
[16:25] <ohsix> people can freely sell and buy the receiver, but at some point after that what is done with it can be highly illegal
[16:25] <apw> but the point here is if you buy all the bits of that you can put them together, and if you do you get a gun
[16:26] <apw> whereas i can't put the bits together
[16:26] <ohsix> you can't unknowingly put the bits together
[16:26] <apw> oh and actually putting them together isn't illegal in my case
[16:26] <apw> i just am not allowed to do it by the tooling
[16:27] <apw> even though what i want to do is allowed and i am permitted to do it by the licence
[16:27]  * apw gets grumpy
[16:27] <ohsix> you're also allowed to remove the _GPL part from all those statements, as long as it is never distributed, because you can't give that right to anyone else
[16:28] <apw> tseliot, so to perperuate this farse, i would contend you could make the shim copy and and all source it needs out of the originals, with the _GPL attached, ship that, and in dkms sed -e 's/_GPL//g' and then compile the result, and be lega
[16:28] <apw> legal
[16:29] <ohsix> sure
[16:29] <ohsix> but you show intent, and if some legal question comes up over that later, you knowingly did it :]
[16:29] <apw> which i thing completly makes my point, the only person you are penalising is the end-user
[16:29] <apw> which is not the intent of the GPL or GPL code in general
[16:29] <ohsix> the end user has the right to do such a thing
[16:30] <apw> and you make his life a living hell to make a pont
[16:30] <apw> point, a point you should be making to someone else
[16:30] <ohsix> the end user isn't distributing the code, generally, most things are binding when the code is distributed
[16:31] <ohsix> distributing a binary is distributing the code, and i'm not a lawyer but i'm pretty sure that it's clear the binary counts as a derived work
[16:31] <ohsix> you can talk to the fsf and stuff, doesn't canonical have staff lawyers? :D
[16:31] <apw> i don't dispute that reading of the words, i mearly contend we punish the wrong person
[16:32] <apw> i don't need to talk to a lawyer to know my opinion on the situation
[16:32] <ohsix> i think your opinion may be different if you knew how important it is legally to remove ambiguity by just stating the license for a symbol vs. the alternative
[16:32] <ohsix> but fair enough
[16:33] <apw> no i don't see how _GPL does a thing, the kernel is licenced en-toto under the GPL
[16:33] <ohsix> there have been debates over whether using _GPL was even appropriate, and they favor not
[16:33] <apw> adding or removing _GPL does nothing to change that not adds anything to that story
[16:33] <ohsix> it is, but what is a 'derived work'
[16:34] <ohsix> that's the thing at question in any case dealing with this
[16:34] <apw> the licence does not add meaning to that wording therefore it being or not being in the code has no meaning
[16:34] <ohsix> _GPL is used where an author considers that anything that would touch that symbol is likely a derived work
[16:34] <apw> i would contend that i can do whatever the GPL says i can with either interchangably
[16:35] <apw> it is unlikely they are qualified to make that judgement any more than the lawyer who will
[16:35] <apw> under a strict legal reading
[16:35] <apw> as anyone who has spent time with a lawyer will tell you
[16:35] <apw> any more than _i_ am qualfied
[16:36] <ohsix> sure
[16:36] <apw> nor would i want to be of course
[16:36] <ohsix> but it shows intent
[16:37] <ohsix> i wiped out a line i decided not to say, but it was like, anything very generally for dealing with virtual memory pages wouldn't be _GPL, per-se; but a function that was basically considered internal to linux' specific vm might be
[16:37] <apw> i am not sure you can show intent of an action i perform
[16:38] <apw> anyhow, all academic in real terms
[16:39] <tseliot> the only intent I can see is that to make my life miserable as a maintainer when they change functions to GPL only :P
[16:39] <apw> and that is their intent i am sure :)
[16:40] <apw> if our source packages were co-installable you might just be able to use that as a base
[16:40] <apw> so you'd not need to include your source
[16:41] <ohsix> it's also not unlike highly visible and deliberately placed 'no tresspassing' signs
[16:41] <apw> placed on a public park entrance
[16:41] <tseliot> :D
[16:42] <ohsix> police won't have to speak to property owner to know that they intend to have anyone that doesn't belong there removed, but 'belong there' and everything can happen at a different time
[16:42] <apw> yes, except in this case end users are allowed to do whatever they like in the park
[16:42] <ohsix> provided they don't then have to share the park with someone else ;]
[16:43] <apw> yes, and the signs don't say "don't share the park" they say "don't enter the park"
[16:43] <apw> which is my entire point
[16:43] <ohsix> 'dont share the park' is implied by 'dont enter the park'
[16:43] <apw> i don't think you can really mean that
[16:43] <ohsix> you can't share a park you can't be in
[16:44] <ohsix> nor ice cream you don't have
[16:44] <apw> yes but i have the right to be in the park
[16:44] <apw> so telling me "don't enter the park" is just rude and obnoxious
[16:44] <apw> because you want the park for yourself, no ?
[16:44] <ohsix> the park was your thing, i was talking about where clear markers can be placed and be relevant
[16:44] <ohsix> you can't smoke in the park, how about that
[16:44] <apw> if you want me to not share the park licence it to me that way, oh thats exactly what you did
[16:45] <apw> on the GPL lets me do what i want to the park as long as i don't share it
[16:45] <apw> i can burn it to the ground, wahtever
[16:45] <apw> the GPL already tells me i cannot do these things, i _KNOW_ i can't do them
[16:45] <apw> and i don't do them, take DKMS as fine example
[16:45] <apw> that follows the rules, it is doing the right thing, and _GPL stops it doing something
[16:45] <apw> it is allowed to do
[16:46] <apw> it is the wrong tool for the job
[16:46] <apw> stop hitting the screw with a hammer i say
[16:47] <apw> anyhow, this is not going to solve my problem, doing something utterly stupid is going to do that
[16:47] <ohsix> 'the gpl' also stops it from doing a lot of things, and the user too
[16:47] <apw> yes, it does, but not this thing
[16:48] <ohsix> it existing at all is a sign of that, you can't then go on and say that _GPL is the problem
[16:48] <apw> well as an end user i actually can
[16:48] <ohsix> if not for 'the gpl', dkms wouldn't have a 'the _GPL' problem
[16:48] <apw> dkms doesn't have a GPL problem it has only an _GPL prolem
[16:48] <apw> problem
[16:48] <tseliot> BTW, the function that breaks nvidia is flush_workqueue(). Why wasn't it originally _GPL ? And why is it now?
[16:49] <apw> according to lawyers anyhow
[16:49] <ohsix> dkms wouldn't exist if you could distribute the built modules
[16:49] <apw> right we're not talking about the fact dkms is required as part of the GPL
[16:49] <apw> we're talkin about the fact that even though it does something which is allowed, the tools prevent it
[16:50] <ohsix> the tools wouldn't exist if it wasn't for the license that it is bound to eventually by extra technical measures and point of fact problems
[16:50] <ohsix> it's just not a logical sequence of things that makes any sense
[16:50] <apw> i don't dispute they exist, i dispute they implement the intent of the limitations
[16:51] <apw> i don't have technological limitations preventing me speeding in my car, its still illegal
[16:51] <apw> ths is like having a speed regulator at 55 becuase once in the past the speed limit was that
[16:53] <apw> ohsix, and in the nicest posible sense we are wasting each others time, we are not going to agree here :)
[16:54] <ohsix> we don't disagree
[16:54] <apw> not indeed does it matter what either of us believe as what is is and what lawyers think is what they think
[16:54] <ohsix> but i don't think the legal situation here is too fine a point to understand
[16:54] <ohsix> if the license were BSD this really really wouldn't be a problem, would it
[16:55] <ohsix> it's just matter of fact 'problems' that are implied with what the situation actually is
[16:55] <ohsix> tseliot: do you have some idea when it changed? (flush_workqueue)
[16:56] <ohsix> i'm git log'ing but this machine has slow disks and not much memory
[16:57] <apw> tseliot, yeah interestingly there is a commit back on schedule_work which reversed a GPLification of a symbol because it was previously something else
[16:58] <ohsix> it looks like it was before historical git epoch, not looking that up, huhuhu
[16:58] <ohsix> that stuff lives in kernel/ tho
[16:59] <apw> tseliot, so i don't think you calling that direct as it has always been _GPL i assume its now called from something else newly
[17:00] <tseliot> I really hope it has a non-GPL_ wrapper
[17:01] <ohsix> the discussion would really be moot and silly if it came down to a symbol that didn't even matter much
[17:03] <tseliot> it's already as silly as it gets. This is not the first time that happens. I've seen much worse
[17:04] <tseliot> the dma_buf code though was probably one of the best examples of how pointless GPL_ is
[17:05] <tseliot> with NVIDIA eventually adding non-GPL_ wrappers in the kernel and ending the argument
[17:05] <apw> tseliot, does this use its own workqueue or the system one ?
[17:06] <ohsix> again that's not really what the point is, nor is it 'the gpl'
[17:06] <apw> whats the flush_workqueue incantation if it has one
[17:06] <apw> ohsix, the GPL is fine and dandy and i support its intent intensly
[17:06] <ohsix> all the workqueue symbols are gpl and have been for like 10 years
[17:07] <tseliot> apw: I haven't really checked that, or maybe I have and I forgot about it. It's been a while.
[17:08] <apw> ohsix, well half of them are, "delayed" work isn't, most inconsistant
[17:08] <tseliot> there were non-GPL_ wrappers for the workqueue though...
[17:08] <tseliot> if I remember correctly
[17:09] <apw> tseliot, right, i am sure there were for some operations
[17:09]  * tseliot nods
[17:11] <apw> tseliot, i can see why you go mad updating this thing ... uggg
[17:12] <tseliot> yes, at least we're going to get rid of fglrx, so it's going to be just nvidia (sooner or later)
[17:14] <apw> tseliot, does this really contain a shar file containing a binary installer, i am going to barf
[17:16] <tseliot> apw: fglrx does not (if you're referring to my tarballs), nvidia's certainly does
[17:16] <apw> tseliot, the latter indeed, uggg
[17:17] <tseliot> apw: yes, you might want to run $INSTALLER_NAME -x , then enter the kernel directory
[17:18] <tseliot> all right, time for me to go
[17:18]  * tseliot -> away
[17:41] <unixabg> apw: Greetings, just checking on casper and overlayfs.
[17:43] <apw> unixabg, was there a bug number on that, so i can put it on my todo and make sure i get to it
[17:45] <bdmurray> apw: every iproute2 crash I can find uses the latest trusty kernel.
[17:45] <apw> bdmurray, hmmm interesting
[17:45] <apw> bdmurray, do we have any idea where/what it is exploding in
[17:45] <bdmurray> apw: that's with the release pocket version of iproute2 or the -updates version
[17:46] <apw> bdmurray, ok so definatly not the userspace tools i'd say then
[17:47] <bdmurray> apw: Oh, I didn't realize 3.13.0-59 was superceded. I haven't looked for the latest kernel yet.
[17:47] <unixabg> apw: no I had just tested and multiple overlayfs did not work on my test environment. I do not think it hard
[17:47] <unixabg> to reproduce and I am not sure if it is a casper thing or not.
[17:48] <bdmurray> apw: the vast majority of the crashs are when running /sbin/ip route fwiw
[17:48] <apw> unixabg, ack, thats fine, i suspect i know exactly whats up, and just need to keep a handle on it, i'll file something to remind me
[17:48] <apw> bdmurray, hmmm ... ok
[17:48] <apw> bdmurray, i think we need to file a bug against linux with all this info in
[17:49] <apw> bdmurray, as i don't think it can be userspace if -releaase and -update are fingered, and its all since that kernel went out
[17:49] <bdmurray> apw: Okay, I'll open a bug.
[17:50] <apw> bdmurray, thanks, let us know the number here and we'll get someone to look at what you have, include any links to traces you have
[17:56] <apw> bdmurray, or of ocurse add a task for the existing iproute2 bug for linux, and let us know the number
[18:09] <bdmurray> apw: bug 1481038 I'm still adding more details though
[18:09] <unixabg> apw: humble appreciation and if you push something to test I shall do my best to test it.
[18:10] <apw> bjf, this looks like it might be a kernel issue in routing, though it causes userspace to explode i think
[18:12] <bjf> apw, are you going to work that bug or do you want jsalisbury to start bisecting it?
[18:13] <apw> bjf, i thnk i am not gonig to look at it today, i am slightly unsure if we cna reproduce it atm whihc would be necessary
[18:13] <apw> it might be worth seeing if jsalisbury can figure out a reproduce by for sure
[18:13] <bjf> jsalisbury, ^ is that ok with you?
[18:14] <jsalisbury> apw, bjf, ack, I'll take a look
[18:15] <bdmurray> I'm still running some database queries and let me know if I can help at all.
[18:16] <apw> bdmurray, anything you can tell us about what combos do and don't show this is good
[18:16] <jsalisbury> bdmurray, do you have the steps you used in comment #1 to reproduce the bug?
[18:17] <bdmurray> jsalisbury: I was just testing to make sure that apport generated good crashes by manually killing the "ip monitor" process.
[18:17] <jsalisbury> bdmurray, ahh, ok.  I'll take a look at the oops once you attach them
[18:17] <apw> jsalisbury, this seems to be a userspace crash, but it is shown with old and new userpace, and only with the latest kernel
[18:18] <apw> so it might be a userpace bug being exposed by a kernle change or something
[18:18] <bdmurray> jsalisbury: unfortunately there is no stacktrace or coredump with these crashes.
[18:19] <jsalisbury> bdmurray, ok, I'll review whatever data we can get
[18:19] <bdmurray> I've added the oopses from 20150729
[18:19] <bdmurray> oh, its all on amd64 too
[18:22] <jsalisbury> bdmurray, I'll spin up a VM with that kernel and play with iproute to see if I can reproduce the issue
[18:23] <bdmurray> jsalisbury: sounds good, I wonder if (because the crashes are incomplete) it might be happening during boot up or shutdown.
[18:24] <jsalisbury> bdmurray, ack, that should be easy to find out
[18:24] <apw> jsalisbury, do let me know how you get on
[18:24] <jsalisbury> apw, sure will
[18:26] <jsalisbury> bdmurray, apw, nice, I already have a physical machine running Trusty with the -58 kernel, so I'll just install that kernel and start testing
[18:28] <apw> jsalisbury, yeah you might want to put a few reboots in your world
[18:29] <jsalisbury> apw, I'll do that with just upgrading the kernel and try some other things out.  Then apply the full updates and try again.
[18:43] <jsalisbury> bdmurray, what's the best way to confirm if this bug is reproduced?  Will an oops be written to syslog or anything else in another log file?  
[18:54] <jsalisbury> bdmurray, I guess I can look for whoopsie messages in syslog and that dialog box will pop up
[18:58] <jsalisbury> bdmurray, apw, upgrading just the kernel brings me up to -61, so I'll roll back to -58 to try and reproduce just in case it might have been fixed
[18:58] <apw> jsalisbury, ack
[19:20] <bdmurray> jsalisbury: look for an iproute2 crash file in /var/crash/
[19:28] <jsalisbury> bdmurray, thanks