[06:30] <ppisati> moin
[07:27] <smb> morning
[07:28] <ppisati> ciao Stef :)
[07:31] <smb> Tach Paolo :)
[08:05] <ppisati> have you ever tried to raise the compilation flags? it's an experience you'll never forget... never...
[08:12] <smb> I am not sure I would even know what you mean to start with... but even if it sounds I would not want to do either...
[08:15] <ppisati> but for what i'm doing it's panacea, i can't beleive some much shit pass unnoticed
[08:15] <ppisati> i just hit a problem where a funcion in a patch was changed to accept a pointer to a struct instead of an uint
[08:16] <ppisati> and guess what? the code still compiled, even with such a big change!!!
[08:16] <ppisati> i mean, really, i want the compilation to break in such cases
[08:17] <ppisati> so i went to raise the compiler flags to a simple "-Werror", hell, now i cleaning all kind of crap
[08:17] <smb> Ah, good ol' -Werror
[08:17] <ppisati> and i already got two bugs that would go unnoticed without stricter compilation
[08:17] <ppisati> there was a variable that was used WITHOUT any initialization
[08:17] <ppisati> i mean, something like val &= ...
[08:18] <smb> Yeah, I guess it might be a good idea in general to grab the compile log once in a while and look at the warnings
[08:18] <ppisati> again, i want the compilation to break in this case
[10:10] <ppisati> brb
[10:13] <henrix> that's funny... i'm unable to clone ubuntu-hardy.git using as --reference a local mainline git tree.
[10:13] <henrix> for ex, in tangerine:
[10:13] <henrix> git clone --reference /usr3/ubuntu/linux.git/ git://kernel.ubuntu.com/ubuntu/ubuntu-hardy.git
[10:13] <henrix> this command hangs forever
[10:15] <_ruben> heheh
[10:15] <_ruben> err, wrong window had focus
[10:15]  * _ruben needs focus-follows-eyes feature
[11:02] <apw> henrix, that is odd indeed
[11:03] <henrix> apw: yeah, but i was able to clone it
[11:03] <henrix> apw: it just takes a loooong time
[11:03] <henrix> apw: which is odd, as with other releases it's quite fast
[11:03] <apw> ppisati, you may be able to raise specific warnings to error rather than all of them
[11:04] <apw> henrix, strange indeed
[11:04] <apw> perhaps it needs packaing
[11:04] <henrix> yep, that's probably the reason
[11:05] <apw> smb, i thought it was that no cpu didn't have that feature ?
[11:27]  * henrix -> food
[11:39]  * ppisati -> food too
[12:12] <cooloney> infinity: hey, adam, i'm going to build the package you listed on my imx6 board.
[12:12] <cooloney> so i'm running apt-get install buildd
[12:12] <cooloney> is that correct way to do that?
[12:13] <smb> apw, Oh dear, what did I write now?
[12:14] <apw> smb, i've replied to the email anyhow, it makes more sense there (the intel kvm one)
[12:15] <smb> apw, Yeah, I would be replying there as well right now
[12:15] <smb> apw, Of course itr was the other way
[12:16] <apw> smb, i see now avi has said he is happy and sent it on, which is also good
[12:16] <smb> apw, yep
[12:16] <smb> apw,  And it should read "every real cpu *has* the feature"
[12:17] <smb> apw, Which makes much more sense
[12:17] <apw> smb, yeah that was what i was trying to say also :)
[12:17] <smb> Yeah, I apparently cannot do a !! today... :-P
[12:19] <apw> heh ... it is very hot for not-not
[12:26] <infinity> cooloney: There's no buildd package in the archive, I'd hope.
[12:26] <infinity> cooloney: What you want is sbuild.
[12:27] <infinity> cooloney: apw can probable give you pointers on mk-sbuild and having two reasonably identical setups on your iMX6 and PandaES.
[12:28] <cooloney> infinity: oh, it's installing 170M packages on my board after i ran "apt-get install buildd", sh*t
[12:29] <cooloney> infinity: pandaES just supports SD card, i'm afraid i can't install too many packages, my largest SD card is just 16MB
[12:29] <infinity> cooloney: Oh, hey, we do have "buildd" in the archive, look at that.  That's the Debian buildd, has nothing to do with how we do things.
[12:29] <infinity> cooloney: Err, what?
[12:29] <infinity> cooloney: "Just supports SD"?
[12:30] <infinity> cooloney: That's in direct contradiction of all of us who have Pandas with USB hard drives.  And all the Panda buildds in the DC.
[12:30] <cooloney> infinity: yeah, pandaES doesn't support SATA harddisk, only SD card
[12:30] <cooloney> infinity: ok, i can setup USB hard drive on my panda ES
[12:30] <infinity> cooloney: And if we're not benchmarking this against a PandaES setup that's similar, there's no reason in running these benchmarks AT ALL.
[12:30] <infinity> cooloney: Cause it tells us nothing.
[12:31] <infinity> cooloney: In both cases, you should be running everything from the hard drives, nothing from SD.
[12:31] <cooloney> infinity: got it. so i need to setup sbuild on both PandaES and imx6, right?
[12:31] <apw> cooloney, yeah you want to use the 'kees' method so they get reset after each build
[12:32] <cooloney> infinity: yeah, right now, I just boot from SD for loading kernel and run rootfs on SATA harddrive for my imx6
[12:33] <infinity> cooloney: Right, same thing for Panda then, which is the setup you'd get by default if you run a netboot install.
[12:33] <cooloney> apw: thanks, that recalls me i wrote a wiki section before about using sbuild for building kernel. 
[12:33] <infinity> apw: The kees method? :P
[12:33] <infinity> apw: sbuild's default behaviour is that.
[12:33] <infinity> apw: Or do you mean hard-resetting the machines too? (which isn't a bad idea for benchmarking)
[12:34] <cooloney> infinity: yeah, got it. my imx6 board is based on linaro precise system and our own 3.2 kernel. it's that ok?
[12:34] <cooloney> infinity: for panda, i probably will use latest quantal image
[12:34] <infinity> cooloney: Everything important will be happening in a pure precise chroot anyway, thanks to mk-sbuild, I assume.
[12:34] <infinity> cooloney: So, as long as it's our kernel, the userspace doesn't matter too much.
[12:35] <infinity> cooloney: And no, benchmark precise versus precise, we're not going to be running quantal (or some Linaro thing, or whatever) in the DC.
[12:42] <infinity> cooloney: Also, can I get this magical Ubuntu 3.2 kernel for the mx6?  It seems as though it never fell in my lap.
[12:42] <ogra_> oh, there is a 3.2 for mx6 ?
[12:42]  * ogra_ wants that too 
[12:42] <ogra_> (i havent had the time yet to play with my mx6 though)
[12:43] <cooloney> infinity and ogra_, please clone the branch http://kernel.ubuntu.com/git?p=rtg/ubuntu-precise.git;a=shortlog;h=refs/heads/imx6-sabre
[12:44] <cooloney> and i just found latest building with latest gcc 4.7 will fail due to some GPU driver, as for our buildd usage, I just disable that GPU driver. but you guys can try that
[12:45] <infinity> Well, it wouldn't be built with gcc-4.7 for precise anyway...
[12:45] <smb> henrix, bjf A heads up: I think I have a odd regression with current precise-proposed
[12:45] <henrix> smb: do you have a bug #?
[12:46] <smb> henrix, Not yet, I was just closing in on the kernel part this morning (after ruling out some other changes)
[12:47] <henrix> smb: ok. let me know once you have a bug filed
[12:47] <henrix> smb: thanks
[12:47] <smb> just on it
[12:47] <cooloney> infinity: i'm running gcc-4.7 on quantal now.
[12:48] <infinity> cooloney: Yes... But the above is for precise, where kernels are built with 4.6
[12:49] <cooloney> infinity: yeah, i will rebuild the kernel on imx6 board right now
[12:52] <apw> cooloney, on chinstrap.ubuntu.com:~apw/HINTS are my notes of how to setup chroots under sbuild correctly
[12:53] <apw> cooloney, obviously for your purposes you want armel and armhf chroots
[12:54] <cooloney> apw: thanks, that saves me lot of time. 
[12:55] <cooloney> infinity: do you need to test SSD? or just hard disk is enough
[12:55] <apw> cooloney, we are talking about buildd comparisons here
[12:55] <apw> cooloney, so you need to have the config which they have
[12:56] <apw> cooloney, which is a USB disk in the existing setup i believe, and sata disk for the new one
[12:56] <infinity> cooloney: Rotary disks, no sane person runs a buildd on SSD, unless they hate themselves.
[12:56]  * apw pops out for some supplies
[12:57] <cooloney> apw, got it. i just found a spare SATA HD, if you wanna SSD, i might need to order it in advance.
[12:58] <cooloney> infinity: lol, ok, let me setup the sbuild and file the building on HD
[12:58] <smb> henrix, bug 1034885 is filed but I just had another idea of what could be wrong beside the kernel... Unfortunately it is "this" machine I need to test on... 
[12:58] <ubot2> Launchpad bug 1034885 in linux "[precise] Proposed kernel does not automatically load usb-storage for card-reader" [Undecided,New] https://launchpad.net/bugs/1034885
[12:59] <henrix> smb: let me take a look...
[13:00] <smb> henrix, One of the things also changed is initramfs-tools config from most to dep... So it also could be that...
[13:01] <infinity> smb: It's almost certainly not the kernel, but something userspacey.  Unless something's gone HORRIBLY wrong.
[13:02] <smb> infinity, Yeah, I was already curious because there were no real changes in usb that could do that
[13:04] <henrix> smb: infinity: yeah that makes sense, there's nothing in the kernel changelog that caught my attention
[13:04] <henrix> but i just did a very quick look
[13:05]  * smb reboots with the full blown initrd
[13:09] <henrix> smb: please, satisfy my curiosity! :)
[13:09] <smb> henrix, Bah, ok. It was the initrd
[13:10] <henrix> smb: ack, thanks :)
[13:50] <apw> smb, interesting, we are clearly missing something we do need in 'dep'
[13:51] <smb> apw, Maybe. I first want to make sure it was not a failing to rebuild after I reverted back from your kmod (which was not intended for that release anyway).
[13:51] <smb> apw, But I wanted to leave that for another day (s reboot)
[13:51] <apw> indeed
[13:52] <smb> At least the kernel is not at fault. Which was the major concern. Of course it took me until I filed the bug to realize the initrd hint
[14:33] <hggdh> bjf: failed Natty SRU, please see bug 1034930
[14:33] <ubot2> Launchpad bug 1034930 in linux "QRT failed on test_101_proc_fd_leaks (__main__.KernelSecurityTest)" [Critical,New] https://launchpad.net/bugs/1034930
[14:42] <henrix> hggdh: i guess this test used to pass before, right?
[14:43] <henrix> hggdh: because there are only a few changes in natty, and none seem to be related...
[14:43] <henrix> hggdh: but i'll take a closer look
[14:43] <bjf> henrix: i'd expect a bad exit code rather than a traceback
[14:44] <apw> 08/08 22:02:52 ERROR|base_utils:0114| [stderr] AssertionError: Got exit code 10. Looking for text " 0x"
[14:44] <apw> bjf, it is complaining about a bad exit code 
[14:47] <bjf> apw, i guess. i wouldn't throw an exception if i was checking for an exit code and know that i didn't get the one expected. but i'm odd i guess.
[14:56] <hggdh> henrix: it used to pass, yes
[14:56] <henrix> hggdh: ack, thanks
[14:59] <ericm|ubuntu> ppisati, ping
[15:00] <ppisati> ericm|ubuntu: pong
[15:09]  * ogasawara back in 20
[16:06] <ogra_> cooloney, hmm, i cant boot the mx6 kernel (just buiolt a package from your tree not changing anything and put the uImage in place of the original one on the mmc)
[16:06] <ogra_> Error: unrecognized/unsupported machine ID (r1 = 0x00000eb9).
[16:06] <ogra_> Available machine support:
[16:06] <ogra_> ID (hex)        NAME
[16:06] <ogra_> ffffffff        Freescale i.MX6 Quad (Device Tree)
[16:14] <mjg59> sforshee: Ok, I have working patches for gmux on the retina
[16:15] <mjg59> sforshee: ...which is also lacking VBT, so I'll poke on that a little
[16:17] <sforshee> mjg59, awesome. I'm still waiting for the retina to arrive
[16:18] <sforshee> mjg59, I should get back to working on dealing with no vbt in i915 later today, if you make progress let me know
[16:18] <mjg59> sforshee: http://fpaste.org/U05X/ and http://fpaste.org/WhLZ/
[16:21] <sforshee> mjg59, re the first patch, that might break some macs. You might ask Andreas about it, but some of the information I got from him indicated that breaking up the writes was necessary for some machines.
[16:22] <sforshee> mjg59, and looks like an unrelated change to nouveau snuck in ;)
[16:24] <mjg59> sforshee: It... does break up the writes?
[16:24] <mjg59> sforshee: Also, the retina is edp and not lvds, so it's going to be separate fixes
[16:24] <mjg59> Yeah, ignore the nouveau thing
[16:25] <sforshee> mjg59, it changes the series of write8s to a write32 in gmux_update_status
[16:25] <mjg59> sforshee: write32 breaks up the writes
[16:25] <mjg59> It's not an outl
[16:25] <sforshee> mjg59, okay, I obviously didn't really look at write32
[16:28] <sforshee> mjg59, so you used directhw to reverse engineer this?
[16:28] <mjg59> sforshee: Partially, yeah
[16:28] <mjg59> sforshee: But it turns out that the ACPI backlight uses the gmux
[16:28] <mjg59> So I could work out most of the register writes from there
[16:29] <mjg59> sforshee: [  531.579739] [drm] bad panel power sequencing delays, disabling panel
[16:29] <mjg59> sforshee: Yeah ok this is going to be more awkward
[16:30] <sforshee> mjg59, yuck
[16:31] <sforshee> mjg59, Did you try https://lkml.org/lkml/2012/8/8/410 for the nointremap issue? Just curious if it's the same issue.
[16:32] <mjg59> sforshee: No, but I expect it will be
[16:39] <bjf> henrix, did you find anything with that natty qrt issue?
[16:39] <henrix> bjf: still looking. i'm able to reproduce it
[17:11] <bjf> sforshee: have you seen any status on the macbook-air wireless issue? (i have not)
[17:43]  * smb -> EODish
[17:52] <sforshee> bjf, no, I haven't seen any updates at all. I saw it one time last week, but once again couldn't reproduce it after that.
[18:10] <dileks> if I only install linux-image-3.5.1-030501-generic (amd64) I get wrong resolution (guess 1024x768), no working mouse and no networking.
[18:11] <dileks> installing appropriate linux-image-extra solves them all
[18:11] <dileks> for whom is the small linux-image good for :-)?
[18:11] <dileks> ...and the splitting into 2 packages
[18:13] <bjf> dileks: it is good for vms and cloud instances
[18:14] <bjf> dileks, we no longer have separate "virtual" and "server" flavours
[18:14] <dileks> everywhere the cloud
[18:14] <bjf> dileks: didn't you get the memo, PCs are dead
[18:15] <dileks> I remember painting network diagrams with "the Internet" as a cloud
[18:15] <dileks> decades ago
[18:15] <dileks> damn marketing asses
[18:35] <ogasawara> bug 1023566
[18:35] <ubot2> Launchpad bug 1023566 in linux-meta "Update Precise LBM to include v3.4 compat-wireless stack" [Medium,In progress] https://launchpad.net/bugs/1023566
[18:35] <ogasawara> bjf, herton: ^^ just fyi, that's what I was looking at
[19:29]  * ogasawara lunch
[20:02] <mjg59> sforshee: Yeah, your patch fixes nointremap
[20:02] <sforshee> mjg59, thanks for letting me know. I suspected it was the same problem but it's good to know for sure.
[20:03] <adam_g> hi. is grabbing the desired .debs from http://kernel.ubuntu.com/~kernel-ppa/mainline/ the correct way to test more recent kernels on 12.04? 
[20:18] <henrix> bjf: hggdh: i finally root caused the natty failure
[20:18] <henrix> it looks like its a bug in the test itself
[20:18] <henrix> more specifically, in the qrt framework
[20:19] <hggdh> heh
[20:19] <henrix> basically, the test checks if a kernel has a CVE fix by looking at the changelog
[20:19] <henrix> the prob is that the changelog is truncated
[20:19] <hggdh> ugh
[20:20] <henrix> so, basically the CVE fix check has to be done in a different way
[20:20] <hggdh> so the kernel does not have this fix?
[20:20] <hggdh> or does it?
[20:20] <henrix> the kernel *has* the fix. but since the test fails to detect that, it inverts the pass/fail logic
[20:21] <henrix> better to point you to the code:
[20:21] <henrix> let me pastebin it
[20:22] <henrix> here: http://pastebin.ubuntu.com/1138451/
[20:24] <henrix> i guess this has never triggered before because the changelog has just been truncated in the place where it contained the reference to CVE-2011-1020 :)
[20:24] <ubot2> henrix: The proc filesystem implementation in the Linux kernel 2.6.37 and earlier does not restrict access to the /proc directory tree of a process after this process performs an exec of a setuid program, which allows local users to obtain sensitive information or cause a denial of service via open, lseek, read, and write system calls. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1020)
[20:26] <hggdh> ah, OK. Can you please add in your findings to the bug?
[20:27] <henrix> sure. will do that in a minute
[20:27] <hggdh> I can then move it from failed to passed, and open a task for the QRT
[20:27] <henrix> sounds good to me
[20:27] <hggdh> bjf ^ 
[20:30] <ogasawara> adam_g: it is if you are wanting to test a more recent upstream vanilla kernel.  If you want to try the latest Quantal in Precise, use the ubuntu-x-swat/q-lts-backport PPA
[20:32] <henrix> hggdh: comment added. let me know if you want more details
[20:32] <hggdh> henrix: will do
[20:47] <hggdh> henrix: tag updated, bug 1027821 is ready to resume work
[20:47] <ubot2> Launchpad bug 1027821 in linux "linux: 2.6.38-15.65 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1027821
[20:48] <henrix> hggdh: great, thanks. and this means EOD for me ;)
[20:48] <hggdh> henrix: boas noites
[20:49] <henrix> hggdh: heh, ate amanha :)
[21:55] <dannf> should the rtc driver for a platform's rtc be statically linked normally? debugging an issue w/ highbank where system clock at boot is the epoch - looks like the rtc driver is a module, and not in the initramfs
[21:56] <dannf> (manual hwclock -s works fine later)