[07:35]  * smb tries to wake up
[07:40] <RAOF> This sounds like a job for bees!
[07:40] <smb> Nah, more like very strong coffee...
[07:41] <RAOF> Infused with bees?
[07:41] <RAOF> Everything is better with bees ☺
[07:41]  * smb wonders about the bee thing that seems to go on....
[07:42] <smb> B B B
[07:42] <smb> Still not better...
[07:43] <RAOF> B-)
[07:43] <RAOF> See?  Much better!
[07:43] <smb> Heh :)
[07:54] <smb> Seems one way to tell that apw is awake is to watch for new tracker mails pouring in ... ;)
[07:54] <smb> apw, morning
[07:59] <apw> smb, heh tracker emails ?
[07:59] <smb> apw, modifying the cve-bzr-tracker that I am still subscribed to 
[08:00] <apw> smb, heh yeah thats first thing normally cause it kills my machine stone dead ... as it pays the 'its 24 hours so acces timess needs to change' pain on alll my repos
[08:00] <apw> i then make some tea in parallel while it runs :)
[08:01] <smb> Heh, yeah sounds like a good way to not to actually pay that time in person... :)
[08:02] <apw> literally takes 10 minutes of heavy crunching the first time, disk burried
[08:02]  * apw notes that this one shows a huge heap of updates on arm like we haven't rebased arm in agaes, i guess with all the regressions on master thats not unexpected
[08:04] <smb> If its Lucid, then sort of. At least ec2 skipped 3 or 4 versions. But only the first had a lot of changes. Still could have been one or two stable ubdates
[08:07] <apw> yeah most likley that much behind.
[08:08] <apw> smb, though 78 CVSs moved from pending to pending (x), so something was very very behind
[08:08] <apw> kees will be pleased indeed to see them all go out
[08:14]  * smb shouts
[08:14] <apw> smb are you "there" or is pulse bust at my end
[08:15] <smb> yes :-P
[08:15]  * apw cries
[08:15] <smb> Not much more joy
[08:16] <apw> smb, can you see my lips even ?
[08:16] <smb> apw, were making fun of you
[08:16] <smb> well we hear you
[08:16] <cking> we can here you
[08:16] <smb> but you cannot hear us
[08:16] <smb> we won't repeat that
[08:19] <cking> smb, you can see how many writes you did to the fs using: cat /sys/fs/ext4/sda1/lifetime_write_kbytes
[08:30] <smb> cking, Hm, I guess that would require it to pass the recovery phase which it fails because any writes seem to fail...
[11:33]  * ppisati -> lunch
[12:35] <zul> can we get CONFIG_BLKIO_CGROUP turned on for omap4, i already opened bug #831954 about it
[12:35] <ubot2> Launchpad bug 831954 in linux "CGROUPS_BLKIO need to be enabled on omap4" [Undecided,Incomplete] https://launchpad.net/bugs/831954
[12:37] <apw> zul on which release
[12:37] <zul> oneiric
[12:37] <tgardner> apw, on it
[12:37] <apw> tgardner, seems you read even faster than i
[12:38] <smb> zul, Another thing for lxc?
[12:38] <apw> tgardner, we might want to see that *_CGROUP_* are the same in master and there
[12:38] <apw> tgardner, as i suspect there will be something else missing tommorrow
[12:38] <zul> smb: yeah wheee
[12:38] <apw> zul i assume lxc works on i386/amd64 ?
[12:38] <smb> apw, Sounds quite reasonable... 
[12:38] <bjf> ##
[12:38] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[12:38] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[12:38] <bjf> ##
[12:38] <zul> apw: pandaboard
[12:39] <apw> zul, i know you need ti-omap4, i mean if the config is right in x86 then its worth syncing all cgroup things over at the same time
[12:39] <smb> apw, And the other answer should be yes
[12:39] <tgardner> apw, funny, I was just thinking the same thing.
[12:39] <zul> apw: agreed
[12:39] <apw> smb, so lxc does work yes ?
[12:40] <smb> apw, Yes, and I was thinking that it seemed to work with the last other cgroup change. But seems not all of it
[12:56]  * bjf -> morning walk
[13:44] <tgardner> ogasawara, pushed rebase to v3.1-rc3 plus makefile patches to ubuntu-p
[13:44] <ogasawara> tgardner: sweet, was just about to start that
[13:45] <tgardner> ogasawara, now you can take an extra 20 minutes :)
[13:45] <ogasawara> heh
[13:46]  * apw isn't sure she can take a full 40 minutes of that
[13:46]  * ogasawara cringes at the thought
[13:54]  * bjf -> back
[13:57] <ppisati> have we ever had arm vexpress kernel built?
[13:57] <ppisati> it seems the server/arm people need it
[13:57] <ppisati> and they are asking to had this arm flavour
[13:58] <tgardner> ppisati, linaro agreed to supply that flavour
[13:59] <ppisati> tgardner: we supply or they supply?
[13:59] <tgardner> ppisati, tey, as in linaro
[13:59] <tgardner> they*
[13:59] <ppisati> uhm
[13:59]  * ogasawara back in 20
[14:00] <ppisati> tgardner: it seems they need it for the cloud images (that they will run on qemu in this case)
[14:00] <ppisati> anyway, i'll reroute them to linaro
[14:06] <tgardner> bjf, are you deaf ?
[14:07] <bjf> must be, can you hear me?
[14:07] <smb> yes
[14:07] <bjf> huh
[14:07] <smb> killall pulseaudio
[14:12] <Daviey> ppisati: Thanks for the heads up
[14:12] <ppisati> Daviey: ah, you are here :)
[14:13] <Daviey> tgardner: Did linaro agree to provide it "in ubuntu archive" ?
[14:15] <tgardner> Daviey, IIRC they were going to do that. contact John Rigby.
[14:16] <Daviey> tgardner: ta
[14:16] <apw> Daviey, it is rather late in the day to be noticing you don't have a kernel isn't it?
[14:17] <tgardner> Daviey, of course there might be a maintenance issue. Linaro typically abandons a release as soon as its out.
[14:17] <amitk> tgardner: Daviey: John (for the config) and Ricardo Salveti (for uploads to archive if necessary)
[14:17] <Daviey> apw: who uses THAT?
[14:17] <apw> that ?
[14:17] <Daviey> a kernel.. we just ride along the userspace.
[14:18] <smb> and we likely have no need for a vexpress thing... :-P
[14:18]  * smb at least has no hw for that
[14:18] <Daviey> The reason for wanting it, is that we were advised that the vexpress platform is better to virtualise than the ones we were using.
[14:19] <amitk> smb: very few people in the world do and most are concentrated around a place called cambridge, UK
[14:19] <Daviey> this is really purely for using full virt.
[14:19] <Daviey> smb: you do have hardware for that!  it's called qemu-system-arm :)
[14:19] <tgardner> Daviey,  actually, I thought it was the only armel flavour that worked with qemu
[14:19] <amitk> tgardner: there is now basic omap support too
[14:20] <Daviey> Other people know much more about this crap than i do :)
[14:20] <apw> i thought we dropped versatile cause qemu did omap support now
[14:20] <tgardner> amitk, Daviey: well we _do_ have omap2 support in oneiric
[14:20] <tgardner> or omap3 rather
[14:22] <smb> bjf, If that was intended to be speed it did not work
[14:22] <ppisati> yep, qemu should grok the omap3 kernel nicely now
[14:22] <smb> err speech
[14:31] <Daviey> NCommander / ogra_ / lool: Should we use omap3 as our favoured qemu-system-arm platform?
[14:32] <ogra_> Daviey, well, that limits you to 512M
[14:33] <apw> so what have you been testing with for the last 4 months
[14:33] <ogra_> and makes your image creation more complex 
[14:34] <Daviey>    mm   mmmmm    mmm  m    m
[14:34] <Daviey>    ##   #   "# m"   " #    #
[14:34] <Daviey>   #  #  #mmmm" #   mm #mmmm#
[14:34] <Daviey>   #mm#  #   "m #    # #    #
[14:34] <Daviey>  #    # #    "  "mmm" #    #
[14:34] <ogra_> mmm ?
[14:34]  * apw wonders why your R is lifting its foot
[15:02] <lool> Daviey: There are pros and cons; vexpress has some network issues, but otherwise mostly works; OMAP supports emulation of a bunch of different boards and will actually emulate the OMAP3 boot ROM (vexpress just starts into an ELF binary from the cmdline); vexpress goes up to 1 GiB, beaglexm up to 512 MiB; network, keyboard and mouse emulation on OMAP is tricky, but you get flash
[15:03] <Daviey> lool: tgardner seemed to think that linaro was working on a vexpress kernel, is this intended to be in the archive, do you know?
[15:04] <lool> Daviey: it's in the archive
[15:04] <lool> Daviey: as well as our omap kernel
[15:05] <lool> Daviey: the d-i flavor for vexpress is temporarily disabled as it lacks a couple of modules in the config which are now required
[15:05]  * Daviey is now really quite confused.
[15:05] <lool> Daviey: rmadison linux-linaro-vexpress
[15:05] <lool> Daviey: rmadison linux-linaro-omap
[15:05] <Daviey> Gah.
[15:06] <Daviey> There seems to be pockets of unknowns floating around.
[15:06] <lool> Daviey: Note that there are 3 OMAP kernels in Ubuntu ATM; linux-ti-omap4 for OMAP4 only (not supported in qemu), linux builds an OMAP3-only flavor (should work in QEMU), and linux-linaro-omap builds and OMAP2+ flavor which works on OMAP3 + OMAP4 and in QEMU
[15:07] <Daviey> lool: So you think linux-linaro-vexpress is our best bet, for most memory support?
[15:07] <lool> Daviey: that seems right, but the network issue is a big deal for a cloud usage
[15:07] <lool> Daviey: for a local run, it's fine though; but you can't test network install for the same reason
[15:08] <tgardner> Daviey, as is the maintenance window
[15:08] <lool> one thing I didn't try is setting up the network over serial; that's really ugly, but it would be reliable and slow
[15:08]  * Daviey sobs.
[15:14] <jibel> apw, bug 827197 is not fixed on today's desktop images.
[15:14] <ubot2> Launchpad bug 827197 in linux "/usr/bin/ecryptfs-setup-private fails with exit status 1 during install - User's home directory not encrypted" [High,In progress] https://launchpad.net/bugs/827197
[15:15] <apw> jibel, what kernel is on the CD you have
[15:15] <ogra_> lool, but the beaglexm vm needs a proper vfat, vexpress can just run with vmlinuz and .img file ... its quite some extra effort to add partitons etc
[15:16] <jibel> apw, 3.0.0-9.13
[15:17] <jibel> apw, it was fixed on .12 according to changelog
[15:17] <apw>  jibel looking at it now
[15:17] <jibel> apw, thanks
[15:18] <lool> ogra_: I don't think it's an obvious disadvantage; for instance with vexpress you have to keep the kernel up-to-date inside the installed system and on the host, while with OMAP you just apt-get update
[15:18] <lool> just... different, both with advantages and disadvantages depending on the load
[15:18] <ogra_> sure, omap is also better supported, but you still have to do more implementation work in the beginning
[15:25] <cr3> hi folks, do some drivers take different code paths for some pci devices depending on their revision number? ie, is the revision important to know when troubleshooting a pci device?
[15:25] <apw> ogasawara, about?  seems something odd has happend to the ecryptfs fix, it seems to have undone itself, even though you had to disable module checks... 
[15:25] <ogasawara> apw: eh?
[15:25] <apw> cr3, yep, some quirks only apply to specific revisions or chip revs or any number of other things
[15:26] <apw> ogasawara, seems although all the pre-requisite changes are in the commit, as of now ecryptfs itself is still =m in some cases.
[15:26] <apw> ogasawara, i cannot fathom how that is possible
[15:26] <kirkland> apw: why's ecryptfs so much trouble this cycle?
[15:27] <apw> kirkland, some idiot added TPM based key support to it :/
[15:27] <cr3> apw: awesome, thanks for the confirmation! And, just to be extra sure, like wearing a belt and suspenders, the class of a device is not likely to change between revision numbers of a pci device, right?
[15:27] <tgardner> cr3, you mean like changing from a network device to a disk device ?
[15:27] <apw> cr3, i'd have not thought it was possible no
[15:27] <apw> ogasawara, shall i push the fix to that onto master-next
[15:28] <ogasawara> apw: yes please
[15:28] <ogasawara> apw: will prep the upload asap
[15:28]  * ogasawara tries to figure out what happened
[15:28] <apw> ogasawara, done ... its utterly dumbfounding
[15:28] <kirkland> apw: okay, how's that complicate things for us?
[15:29] <cr3> tgardner: maybe not as drastic as that but perhaps change from "RAM memory" to "FLASH memory", assuming a Memory controller
[15:29] <apw> kirkland, it added a huge dependancy pile which has to be =y to allow ecryptfs to be =y and cause we don't autoload it it has to be =y
[15:29] <tgardner> cr3, perhaps in the prototype or development phse, but certanily not after a production release.
[15:29] <tgardner> phase*
[15:29] <apw> and it silently moved itself =m to fix the depenancy issues and we didn't notice
[15:30] <apw> ogasawara, perhaps i should add erypt_fs =y to the enforcer
[15:30] <cr3> tgardner: that's a reasonable use case, thanks, exactly what I needed to know!
[15:30] <ogasawara> apw: yep, that would be a good idea
[15:30] <kirkland> apw: ugh, that's nasty;  tyhicks will be on board next Monday;  perhaps he can help out
[15:30] <tgardner> ogasawara, don't commit the makefile changes on master just yet.
[15:30] <ogasawara> tgardner: ack
[15:31] <ogasawara> tgardner: I'm just gonna do the ecryptfs bits and upload
[15:31] <tgardner> ogasawara, good thinking
[15:32] <apw> ogasawara, ok pushed the enforcer bits too, feel free to rebase them after the upload if thats easier
[15:32] <ogasawara> apw: ack, thanks.
[15:33] <apw> ogasawara, did we get the seccomp bits in time ?
[15:33] <ogasawara> apw: I could actually sneak them in now, kees sent a pull request this morning
[15:33] <tgardner> apw, I'm looking at them right now
[15:34] <tgardner> ogasawara, I'd say wait on seccomp. ecryptfs is more important
[15:34] <ogasawara> tgardner, apw: am thinking we should just wait till post beta-1 though
[15:38] <apw> ogasawara, it feels like a first upload after beta-1 material to me, gives a few weeks to rip it out if its pants
[15:38] <ogasawara> apw: agreed
[15:42] <tgardner> apw, hey mr perl wizard. when you have time look at ubuntu-p.git. 'Missing argument in printf at debian/scripts/abi-check line 174.' implies that the ABI checker needs some love.
[15:42] <apw> tgardner, sure, been seeing that for some time i think
[15:43] <tgardner> apw, ack
[15:43] <apw> tgardner, added to my todo
[15:57] <sconklin> hey apw, can you confirm that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/805494 is fixed? I'll do the bug updates if you say it's good for Lucid and Maverick
[15:57] <ubot2> Ubuntu bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed]
[16:00] <bjf> ##
[16:00] <bjf> ## Kernel team meeting in one hour
[16:00] <bjf> ##
[16:03] <tgardner> sconklin, I think its pretty obviously a fix since it wouldn't build otherwise. I'll check again with a quick test build
[16:35] <tgardner> sconklin, updated to  verification-done-lucid on bug #805494
[16:35] <ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed] https://launchpad.net/bugs/805494
[16:56] <apw> sconklin, indeed that is a build test if it built its ok
[17:44]  * tgardner --> lunch
[17:45] <bjf> ogasawara, we're just going with the moin text that the bot pukes out?
[17:45] <bjf> ogasawara, for the meeting notes
[17:45] <ogasawara> bjf: that's what I did last week, seemed easier
[17:46] <bjf> ogasawara, not sure what that buys us may as well just point at the irc log
[17:46] <ogasawara> bjf: I added a blurb to the meeting README in kt-tools about it as an alternative to running the minutes through the irc2moin script
[17:46] <ogasawara> bjf: true
[17:51] <herton> tgardner, apw, sconklin: bug 805494 needs to be marked verified for maverick as well. I did build tests under 3.x kernel with maverick sources just in case, will mark verified for it as well.
[17:51] <ubot2> Launchpad bug 805494 in linux "ubuntu/rtl8192se driver breaks build when running 3.0 and above kernels" [Low,Fix committed] https://launchpad.net/bugs/805494
[18:18] <tgardner> herton, ack
[18:19] <herton> sforshee: we got positive feedback from testing bug 828550, can you send your patch to the mailing list to be reviewed/applied?
[18:19] <ubot2> Launchpad bug 828550 in linux "kernel BUG at /build/buildd/linux-2.6.32/drivers/gpu/drm/i915/i915_gem_evict.c:183!" [High,Incomplete] https://launchpad.net/bugs/828550
[18:21] <herton> *on bug
[18:27] <sforshee> herton, ack
[19:39] <cking> yawn
[21:01] <ogasawara> tgardner: just fyi, i ran updateconfigs for the seccomp config changes and pushed over the top of master-next
[21:01] <tgardner> ogasawara, did it just resort ?
[21:01] <ogasawara> tgardner: yep, just moved em to ubuntu.common
[21:02] <tgardner> ah, thanks.
[21:04] <jjohansen> rebooting
[21:34] <bdmurray> This is indicative of something bad right?
[21:34] <bdmurray> [  423.586548] aufs au_xino_do_write:378:python[4582]: I/O Error, write failed (4294967268)
[21:51] <soren> bdmurray: You're out of space.
[21:51] <soren> bdmurray: 4294967268 == -28
[21:52] <bdmurray> soren: not me but thanks!
[21:52] <soren> ENOSPC = 28.
[21:52] <soren> bdmurray: It's guesswork, but it sounds plausible to me.
[21:53] <bdmurray> soren: aufs                   3097704   2522256    415552  86% /
[21:55] <soren> bdmurray: Hm.
[21:55] <soren> bdmurray: pass
[21:55] <soren> bdmurray: All I know is that 4294967268 is -28 written as an unsigned int.
[21:55] <soren> bdmurray: and -28 is what you'd get if made a system call that failed due to not enough space.
[21:56] <soren> bdmurray: ..and then I put two and two together.
[22:10] <gswallow1> Hiya, dumb question I think. First, I asked #ubuntu and got crickets.  Is there a better place between there and here?  And second, I have been trying to install 10.04.2/3 on an HP BL460g7, with some cursed ServerEngines CNA.  So far the only thing I can get to bring up the network on this card is Maverick.  I have read on teh Googlez that there is a way to choose a "Maverick backports" kernel or something and still install Lucid.  Do
[22:14] <gswallow1> oh, hey. https://answers.launchpad.net/ubuntu/+source/ubiquity/+question/164536