| BenC | It's funny that there isn't even an ext4 filesystem yet...the fs and module are called ext4dev | 00:17 |
|---|---|---|
| lifeless | wow, that dude was nuts | 00:19 |
| wgrant | Wow. | 01:09 |
| wgrant | That was impressive. | 01:09 |
| wgrant | That jdong impersonation... wtf. | 01:09 |
| === prince is now known as Howdy | ||
| === asac_ is now known as asac | ||
| === lifeless_ is now known as lifeless | ||
| === elmo_ is now known as elmo | ||
| === pgraner__ is now known as pgraner | ||
| === emgent_ is now known as emgent | ||
| === dhaval is now known as dhaval_away | ||
| emma | w 30 | 15:44 |
| === dhaval_away is now known as dhaval | ||
| BenC | cking: would you be interested in seeing if there's some way we can pass info to grub about whether a boot failed or not? | 17:28 |
| mjg59 | BenC: You were looking for me on Friday? | 17:28 |
| BenC | cking: I was thinking of something like "grub goes to boot, set dirty boot flag, OS clears flag" | 17:28 |
| BenC | mjg59: yeah, in regards to uvesafb and if there's reason not to use it as opposed to vesafb? | 17:29 |
| mjg59 | None that spring to mind | 17:29 |
| BenC | cking: and if grub comes up and that dirty flag is still set, default to last-good-boot entry | 17:30 |
| BenC | mjg59: I guess the main question is...could it be used as the default? (I have v86d packaged and ready to upload) | 17:34 |
| mjg59 | Default? I wouldn't encourage it | 17:34 |
| mjg59 | Using it instead of vesafb should be entirely safe, though | 17:34 |
| BenC | That's good...at least then we can ditch the modular vesafb patches | 17:36 |
| cking | BenC: I will put it on my grub "to do list". | 17:50 |
| BenC | rtg, pgraner, smb: New abi-check script in git...check the git-log for description | 19:23 |
| BenC | I think you guys will like it | 19:23 |
| * BenC says goodbye to diff based abi checks | 19:23 | |
| zul | BenC: is there a flavours git repo open yet? | 19:23 |
| pgraner | BenC: rock on.... | 19:24 |
| * pgraner runs to pull the latest | 19:24 | |
| BenC | pgraner: I can easily add per module whitelist/blacklist now | 19:27 |
| pgraner | BenC: nice... | 19:28 |
| BenC | pgraner: so if we only want to fail(aka abi-bump) only for certain portions, we can | 19:28 |
| pgraner | BenC: would be nice to get folks like vmware to give us the list of symbols they are using | 19:32 |
| BenC | brb, rebooting | 19:42 |
| kirkland | rtg: hey, i'm doing most of my ecryptfs work against intrepid | 19:56 |
| kirkland | rtg: this fix is already in 2.6.26 | 19:56 |
| kirkland | rtg: but there's a corner case where this problem can cause data loss on an ecryptfs mount in Hardy | 19:57 |
| rtg | kirkland: data loss == bad | 20:01 |
| kirkland | rtg: right, so the test case looks like this.... | 20:01 |
| kirkland | rtg: mount an encryptfs dir, any kind, any key, any algorithm | 20:01 |
| kirkland | rtg: write some data at least 8KB (looks to need to be 1-2 pages) | 20:02 |
| kirkland | rtg: *don't* read that data | 20:02 |
| kirkland | rtg: unmount the dir | 20:02 |
| kirkland | rtg: re-mount, and append some data to it | 20:02 |
| kirkland | rtg: then try to read | 20:02 |
| kirkland | rtg: that file has gone boom | 20:02 |
| kirkland | rtg: fixed by this patch, you can probably see how | 20:03 |
| rtg | kirkland: seems clear enough. is there an LP report open against Hardy for this? | 20:03 |
| kirkland | rtg: nope; want me to open one? | 20:03 |
| rtg | kirkland: that would be nice. thanks. | 20:03 |
| BenC | rtg: Oh, and the new ABI checker will _always_ fail if one of the ABI files is missing :) | 20:14 |
| kirkland | rtg: https://bugs.edge.launchpad.net/linux/+bug/242448 | 20:14 |
| BenC | we really have no excuse to not have ABI's in the tree anymore (no post hppa and ia64) | 20:14 |
| rtg | kirkland: cherry picked 2.6.26-rc7 has some conflicts, but I see its also in 2.6.25 stable. I'll work on getting it backported. Since I use ecryptfs, I am quite interested :) | 20:15 |
| kirkland | rtg: thanks ;-) I thought you might help advocate this | 20:16 |
| kirkland | rtg: on the flip side, i'm interested in learning some of your processes on the kernel side | 20:16 |
| kirkland | rtg: so if there's more I can do to help, or more I can learn, please keep me posted | 20:16 |
| rtg | BenC: did your script check for missing ABI files if 'ignore' exists? | 20:17 |
| kirkland | rtg: I set the importance to "Medium" and targeted it for 8.04.2 | 20:17 |
| rtg | BenC: does it matter? | 20:17 |
| rtg | kirkland: that works. I'll write the SRU justification in a bit. | 20:17 |
| kirkland | rtg: thx | 20:17 |
| BenC | rtg: considering we shouldn't uploading without ABI files (now that we are doing to 2x2 flavours), it fails now when an ABI file is missing, even if ignore exists | 20:22 |
| BenC | I actually should just remove the blanket ignores | 20:22 |
| BenC | they aren't terribly useful either | 20:23 |
| rtg | BenC: they're pretty handy when you have an FTBS for only one arch. | 20:23 |
| BenC | rtg: even in that case, we have better ways to recover than blanket ignores | 20:23 |
| rtg | BenC: like a locally built ABI set? | 20:24 |
| BenC | rtg: well, more like forcing the checker to use the right previous ABI | 20:24 |
| BenC | e.g. if 3.5 exists, and you upload 4.6, and it fails to build | 20:25 |
| BenC | the checker should be comparing 3.5 and 4.7 on the next upload | 20:25 |
| BenC | not just ignoring the ABI all together | 20:25 |
| rtg | BenC: hmm, I was thinking of the case when you've just had an ABI bump, but one arch FTBS's. | 20:26 |
| BenC | isn't that what I described? | 20:26 |
| * BenC checks his example | 20:26 | |
| rtg | BenC: when you've had an ABI bump, what use is comparing the ABI files from the previous ABI version? Only the modules check makes sense. | 20:26 |
| BenC | Yeah, so if you upload 4.6, which contains the 3.5 ABI, and amd64 fails, the 4.7 upload should still compare with 3.5 | 20:26 |
| BenC | rtg: to track things | 20:27 |
| rtg | BenC: so, the tracking new. | 20:27 |
| BenC | the ABI files should exist and be checked...and in all cases show up in the build (the comparison) | 20:27 |
| rtg | s/tracking/tracking is/ | 20:27 |
| BenC | rtg: right, we need to retain history on what/why the ABI bumped | 20:28 |
| rtg | BenC: ok, well that makes more sense. | 20:28 |
| BenC | rtg: so now, even if the result of the check is ignored, the check is still performed and results shown in the build (before, on ignore, the check didn't run at all) | 20:28 |
| BenC | Sorry, my explanation of the importance of that feature was a little slim on the first try :) | 20:29 |
| rtg | BenC: of what use is this information? Just to keep track of why ABI checks are failing? | 20:30 |
| rtg | or rather, why ABI bumps are being forced upon us? | 20:31 |
| BenC | right | 20:31 |
| pwnguin | I see greg k-h is at it again... | 21:25 |
| === emgent is now known as emgent` | ||
| BenC | pwnguin: ? | 21:49 |
| BenC | brb, need to crash my laptop | 21:54 |
| pwnguin | BeC, he's got a petition to nobody that people are signing | 22:09 |
| BenC | pwnguin: hey...what were you referring to with greg k-h? | 22:30 |
| SEJeff | BenC, Probably the Position statement on closed source kernel drivers greg released | 22:32 |
| BenC | SEJeff: where's that at? | 22:33 |
| SEJeff | Just a sec, it was on lwn this morning | 22:33 |
| SEJeff | http://www.linuxfoundation.org/en/Kernel_Driver_Statement | 22:33 |
| BenC | I notice Linus's name is not on the list | 22:35 |
| SEJeff | http://lwn.net/Articles/287056/#Comments Read through those | 22:35 |
| SEJeff | It isn't an overall thing. It is gregkh doing what he does best | 22:35 |
| SEJeff | Try to put his views onto other people | 22:36 |
| mkrufky | ...pasting 4 lines: | 22:39 |
| mkrufky | Oh, one further thing, you will note that Linus's name is not on this statement. He said that he does not sign public statements like this, but in the email thread about it, he did say to one kernel developer who was thinking that closed source drivers are ok, "Binary drivers really _are_ bad for us. No untruths." | 22:39 |
| mkrufky | ok, so it was 1 line :-P | 22:39 |
| BenC | Oh, I don't disagree with the premise at all | 23:11 |
| BenC | I disagree that proprietary drivers are suddenly more of a problem now than they were a few years ago, or even one year ago | 23:12 |
| doko | BenC: is gcc-4.2 still needed to build the kernel in intrepid? | 23:13 |
| BenC | doko: not for our primary linux...if it's needed for linux-ports, the port maintainers will have to fix it up | 23:14 |
| doko | BenC: who are the port maintainers for these archs (powerpc, hppa?)? | 23:15 |
| pwnguin | BenC: well, I don't like closed binaries, but the license is fairly clear that there are exceptions | 23:19 |
| mjg59 | pwnguin: It is? | 23:20 |
| pwnguin | hmm. i thought I had read it in the COPYING, but theres only the obvious note that the syscall API is not grounds for derived works, but clearly I was wrong. all I can find is a thread where torvalds mentions the limits of derived works might not be as clear cut as "modules are derived works" | 23:26 |
| mjg59 | pwnguin: Right, which is almost certainly true | 23:27 |
| mjg59 | But given that it's almost impossible to write a Linux kernel module without including chunks of GPLed code (in the form of macros and inline functions)... | 23:27 |
| pwnguin | ah, thread went on to declare that even the syscalls were some form of linking / derived work, at which point torvalds broke out estoppel that I do recall | 23:30 |
| === macd_ is now known as macd | ||
| BenC | mjg59: I honestly think the kernel devs screwed themselves when they created EXPORT_SYMBOL_GPL()...it infers that other exported symbols are open to use | 23:48 |
| mjg59 | BenC: The stated policy has alwaysbeen clear | 23:49 |
| mjg59 | Which was "Consult a lawyer before you make decisions based on there being a difference here" | 23:49 |
| BenC | mjg59: years of no-action hasn't helped either...as in, they've taken no action against companies creating or providing closed source drivers in source or binary form | 23:50 |
| mjg59 | BenC: My recollection is that there's a reason l-r-m is distributed in the way it is now :) | 23:51 |
| BenC | source form obviously can't be attacked legally (#include <linux/module.h> isn't copyright infringement) | 23:51 |
| BenC | mjg59: I don't see how it helps though...just the .o's are still binary, and the non-GPL wrapper's are still compiled with GPL macros and inline's embeded | 23:52 |
| BenC | even if it isn't linked to the binary blob | 23:53 |
| mjg59 | BenC: Well, it was apparently enough of a difference to remove the immediate problem | 23:53 |
| BenC | and vmware is distributing binary modules (linked and ready to run) for all of their vm products | 23:53 |
| BenC | I guess I'm just frustrated at the indifference of it all...they're bad, yes...can copyright owners sue distributors of binaries compiled against their linux kernel headers? probably...will they? probably not, because then you can't be selective | 23:55 |
| pwnguin | i think l-r-m gets a pass since technically the user is the one doing the linking? | 23:56 |
| pwnguin | at any rate, I think effort is better spent improving nouveau than suing nvidia or users :) | 23:57 |
| BenC | or signing meaningless redundant public statements :) | 23:57 |
| mjg59 | BenC: You're pretty free to be selective | 23:58 |
| pwnguin | So is drm2 anticipated to stabilize in time for intrepid? | 23:58 |
| mjg59 | I suspect that to an extent the concern is losing a case | 23:58 |
| BenC | mjg59: as in if they tried to sue and lost, it was set precedent for other vendors? | 23:59 |
| mjg59 | Yeah | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!