[07:37] <ppisati> moin
[07:40] <cking> morning ppisati
[07:40] <smb> morning
[07:45] <brendand> hi - where do i get the so called 'precise+' packages from?
[07:56] <cking> brendand, sorry, I have no idea what precise+ means
[07:56] <ohsix> precise-proposed?
[07:56] <cking> who knows
[07:59] <brendand> cking, i've heard it used as shorthand for the Q -> P backports
[08:00] <brendand> cking, not widely used yet i guess
[08:00] <brendand> anyway i found the ppa
[08:01] <brendand> https://launchpad.net/~ubuntu-x-swat/+archive/q-lts-backport
[08:02] <cking> brendand, well, it sounds reasonable, but personally I am not sure about this
[08:02] <brendand> cking, maybe some management speak ;)
[08:04] <brendand> cking, i didn't make it up, but maybe whoever i heard it from did. anyway Q series LTS backport is a bit long for many purposes so i hope there's some shorthand for this construct
[08:04] <ohsix> i've seen that in git, from the generated versions; if you've modified a tree at a certain tag it will be 'tag+whatever'
[08:05] <brendand> cking, on other news we're about to start weekly testing so hoping to see some new fwts bugs opened soon
[08:05] <brendand> cking, can you remind me what was agreed?
[08:06] <brendand> cking, where do they need to be raised?
[08:06] <cking> brendand, I think that's a vanhoof question
[08:06] <brendand> cking, sure thing
[08:07] <cking> brendand, but I'm OK also to view any bugs found
[08:41]  * apw is out for a bit to handle a flat handover
[10:04] <sss> hello :) I have a strange question and I Hope that sombody will be able to help me :) How can I calculate the number of pthread_mutexes in running kernel? All mutexex, not only holded.
[10:51] <janimo> is maint-startnewrelease applicable to all ubuntu kernel packaging processes (i.e. SRU) and where can I find this script?
[11:00] <janimo> nm, found kteam-tools
[11:26] <tjaalton> sbuild/schroot is broken with 3.4 kernel, I get "Use of uninitialized value $chroot_arch in chomp at /usr/share/perl5/Sbuild/Build.pm line 2020."
[11:27]  * apw enjoys a panini
[12:14] <tjaalton> schroot fails due to pam_loginuid failing (from auditd)
[12:14] <tjaalton> wonder what that has to do with the newer kernel
[12:19] <apw> tjaalton, hmmm, that i've not heard of
[12:20] <tjaalton> Jun  1 15:08:10 eldon sudo: pam_loginuid(sudo:session): set_loginuid failed
[12:20] <apw> jjohansen, any idea if we have changed semantics of set_loginuid() or if AA could be involved there?
[12:31] <apw> tjaalton, looks like a kernel change ... and a deliberate one
[12:31] <tjaalton> apw: alright
[12:31] <apw> +#ifdef CONFIG_AUDIT_LOGINUID_IMMUTABLE
[12:31] <tjaalton> so userspace should adjust?
[12:31] <apw> +       if (task->loginuid != -1)
[12:31] <apw> +               return -EPERM;
[12:31] <apw> +#else /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
[12:31] <apw> +       if (!capable(CAP_AUDIT_CONTROL))
[12:31] <apw> +               return -EPERM;
[12:31] <apw> +#endif  /* CONFIG_AUDIT_LOGINUID_IMMUTABLE */
[12:31] <apw> +
[12:31] <apw> tjaalton, specifically that added ...
[12:32] <apw> tjaalton, we have LOGINUID_IMMUTABLE enabled ... i think we need to refer this to security for their advice
[12:32] <tjaalton> apw: ok, thanks for digging this up
[12:32] <apw> tjaalton, we may be able to just turn it off, but even so it might be something we want on by release and something we need to cope with somehow
[12:33] <tjaalton> I'm using the backport kernel on precise ;)
[12:33] <apw> tjaalton, i could make you a kernel with it off and see if that helps for testing?
[12:33] <tjaalton> sure
[12:33] <apw> oh erp
[12:33] <tjaalton> I've got a laptop to break
[12:34] <apw> tjaalton, can you file a bug so we have somewhere to track this ... 
[12:34] <tjaalton> but on the desktop i'm using 3.4 until the gpu hang fix is found and backported to 3.2..
[12:34] <tjaalton> sure
[12:34] <tjaalton> the kernel?
[12:34] <apw> excellent thanks, yes against the kernel
[12:34] <tjaalton> ok on it
[12:34] <apw> title it with the schroot symptoms for now
[12:34] <tjaalton> yeah
[12:35] <tjaalton> note that uninstalling auditd makes it work again, since pam_loginuid doesn't barf
[12:36] <tjaalton> or just commenting it out from common-session
[12:36] <tjaalton> might break something but meh
[12:37] <tjaalton> at least I have a workaround for building packages..
[12:38] <apw> yeah thats something
=== chuck__ is now known as zul
[12:52] <tjaalton> apw: bug 1007396
[12:52] <ubot2`> Launchpad bug 1007396 in linux "sbuild/schroot broken with 3.4 kernel if auditd installed and pam_loginuid in common-session" [Undecided,New] https://launchpad.net/bugs/1007396
[12:59] <ppisati> and even the nic is dead.. f$*$*(#@...
[12:59] <apw> ppisati, ?
[13:02] <ppisati> omap3
[13:02] <ppisati> the network card is not working
[13:02] <ppisati> the module is built
[13:02] <ppisati> but it doesn't get loaded
[13:02] <ppisati> and even if i manually load it
[13:03] <ppisati> the nic is dead
[13:03] <apw> yay
[13:03] <ppisati> for some uknown reason
[13:03] <apw> ppisati, has a long week ahead of him
[13:03] <ppisati> right
[13:19] <ogra_> ppisati, is USb working at all ?
[13:20]  * ogra_ heard about USb issues with recent kernels in #beagle but i didnt pay very much attention to it
[13:21] <ppisati> ogra_: Q kernel didn't even boot on omap3 so i dout they tested usb
[13:21] <ppisati> doubt
[13:22] <ogra_> well, i only heard that from a certain mainline version on USb broke ... ask in #beagle for more info ...
[13:22] <ppisati> ack
[14:37]  * ogasawara back in 20
[14:39] <apw> ogasawara, i have a heap more highbank config in my tree, please say no to anything in debian.master/configs :)
[15:00] <ogasawara> apw: go ahead and push em.  I was going to do some test builds and boots today and possibly upload
[15:01] <ogasawara> apw: I can wait to upload on Monday if there's more you want in
[15:02] <apw> ogasawara, will do shortly want to make sure it boots for highbank before i do
[15:03] <apw> ogasawara, expect some powerpc fallout, so doing a power build is worth the effort
[15:03] <ogasawara> apw: ack
[15:03] <apw> (not from the highbank merge, but the previous cleanups already in)
[15:03] <ogasawara> apw: I think I might wait till Monday anyways to upload in case anything else comes in we need for Alpha-1
[15:04] <apw> ogasawara, but yeah doing some test builds would be worthy
[15:04] <apw> ogasawara, i have done basics but its easy to bust things
[15:04] <ogasawara> apw: ack, will definitely do test builds and boots regardless today
[15:05] <apw> ogasawara, ok will get what i have tested by hwe, and push this snapshot
[15:05] <ogasawara> apw: ack
[15:15] <diwic> ogasawara, it looks like the kernel team stopped providing l-b-m for alsa, huh?
[15:16] <diwic> ogasawara, not saying you have to provide it - now is the first time I noticed it - but just wondering if that was concious
[15:16] <ogasawara> diwic: it indeed has been a while since we provided an updated alsa in lbm
[15:17] <ogasawara> diwic: I can't remember an exact reasoning for why though
=== orated_ is now known as orated
[15:54] <apw> ogasawara, ok a heap of config boot tested on highbank and pushed to quantal master-next
[15:54] <apw> ogasawara, will continue on for a bit, but thats a good baseline
[15:54] <ogasawara> apw: ack thanks
[16:58] <apw> ogasawara, hows the testing going ?  did powerpc build ?
[16:59] <ogasawara> apw: I haven't yet kicked it off, got sidetracked and just coming back around to it now
[16:59] <apw> ogasawara, ahh np
[16:59] <ogasawara> apw: will keep you posted though
[17:00] <apw> ogasawara, thanks ... i have a couple of changes pending so let me know if it breaks
[17:00] <ogasawara> apw: ack
[17:44] <jjohansen> bjf, sconklin: CVE-2012-2663 has had a clarification, and its been assigned to the userspace components of iptables, a different CVE will likely be assigned to the kernel bug. The cve has been updated in the tracker, and I have invalided all the tasks on bug 1007091. I am not sure how this is going to affect your tracker so watch for it
[17:44] <ubot2`> Launchpad bug 1007091 in linux-ti-omap4 "CVE-2012-2663" [Low,Invalid] https://launchpad.net/bugs/1007091
[17:44] <ubot2`> jjohansen: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2663)
[17:45] <sconklin> jjohansen: ack
[17:45] <bjf> jjohansen: i guess we won't apply that patch i submitted yesterday
[17:45] <jjohansen> bjf: yeah hold off on that for a bit :)
[17:47] <jjohansen> apw: hrmm, I am unaware of any changes to the semantics of set_loginuid(), and I doubt AA is involved because of the limited way in which it is being used
[17:48] <apw> jjohansen, no there is indeed a strictification of that interface, that i think you may need to be aware of
[17:48] <apw> jjohansen, it is turned on in our Q kernel, and makes it immutible
[17:48] <jjohansen> oh!
[17:49] <apw> jjohansen, and we'd like to know what to do :)  should it be on or off debian.master/config/config.common.ubuntu:CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
[17:50] <jjohansen> apw: got it, I'll poke
[17:50] <apw> jjohansen, cirtainly if it is on then we have issues in userspace which is all confused so we may even need a _plan_ (god forbid)
[17:52] <jjohansen> apw: a first poke at this seems to be systemd driven. It breaks directly launching login utilities, so they must all go through init
[17:53] <jjohansen> apw: anyways will get back to you
[17:55] <apw> jjohansen, ahh ok, then i suspect we want if off by default till we think about it
[17:56] <jjohansen> apw: yes turn it off, we will look at it more but I don't think this option is viable with how upstart currently works
[17:56] <apw> jjohansen, ok thank
[17:56] <apw> s
[17:56] <jjohansen> apw: if an admin ever directly restarts a daemon it will break
[17:57] <apw> jjohansen, ack
[17:58] <apw> ogasawara, i am turning off CONFIG_AUDIT_LOGINUID_IMMUTABLE as per jj's initial analysis
[17:58] <apw> ogasawara, will be in my next push
[17:58] <ogasawara> apw: ack
[17:58] <ogasawara> apw: feel free to push whenever you're ready
[17:59] <apw> ogasawara, actually ... pushed now ... thats more tested highbank and that jjohansen fix
[17:59] <apw> ogasawara, one sec
[18:01] <apw> ogasawara, ok i've just pushed over it adding an enforcer rule for it
[18:01] <ogasawara> apw: thanks
=== orated_ is now known as orated
[18:58]  * ogasawara lunch
[19:03] <greearb> Hello!  Anyone know if there is an easy way to get the /lib/modules/*/ files that go on the initrd?  It does not seem to be the full set of modules that comes with the normal kernel...
=== yofel_ is now known as yofel
[19:22] <apw> greearb, they are chosen by the initramfs-tools scripting
[19:22] <apw> that package will tell you how it decides
[19:24] <greearb> thanks, looking now
[19:27] <greearb> hrm, seems you have to tell it what to do....happen to know if there are instructions on how the ramdisk is initially build for Ubuntu?
[19:27] <greearb> (I know how to re-spin it...but hopefully the original-build instructions show how it calls initramfs-tools)
[19:28] <apw> greearb, update-initramfs know how to incant at it
[19:32] <greearb> ok, I'm a bit leery of messing with that now, but will try that for my next respin attempt.
[19:57] <dileks> greearb: put specific modules (not in MODULES=most) into /etc/initramfs-tools/modules and do update-initramfs 
[20:13]  * cking --> EOD
[20:39] <greearb> dileks, my problem is that I don't know what modules are needed or not, and I didn't want to think to hard about it.  I could probably just copy over every module that is in the upstream initrd...
[20:40] <dileks> dunno where "most" is defined
[20:40] <dileks> /etc/initramfs-tools/initramfs.conf says... most - Add most filesystem and all harddrive drivers.
[20:41] <greearb> ok, that sounds about right
[20:41] <dileks> you can inspect an upstream initrd.img
[20:42] <greearb> nod
[20:43] <dileks> to see what modules are already shipped
[20:44] <greearb> dileks, btw, would you happen to be someone who could push casper patches upstream?
[20:44] <greearb> I have some fixes that I think are worth considering..makes persistent-usb work a lot better.
[20:45] <greearb> I posted stuff to ubuntu bug trackers and such, but mostly to silence.
[20:46] <dileks> dunno much about casper... I checked sidux/fll and debian/debian-live but thats a while ago
[20:48] <greearb> it's discouraging to have trouble even figuring out where to send patches...just putting them in the bug trackers for Ubuntu projects doesn't get much response.
[20:49] <greearb> anyway, google can find it, so maybe next person to have troubles will have slightly better luck that I did :P
[20:50] <dileks> whats casper - a ubuntu product?
[20:51] <greearb> it's the initial boot-up logic for live-cds..and it *seems* to be headed by Ubuntu, but I'm not certain of that.
[20:51] <greearb> I think Debian might use it too
[20:52] <greearb> deals with 'aufs' mounts and so forth
[20:52] <dileks> hmm, in ancient times for debian, maybe :-)
[20:53] <greearb> debian-live is the modern equivalent?
[20:53] <dileks> yeah
[20:54] <greearb> Might have to try it out sometime..but I have very good notes on how to re-spin Ubuntu, so hesitant to change :)
[20:54] <dileks> btw, I forgot grml-live (sort of debian-live plus fai)
[20:54] <dileks> grml project*
[20:55] <dileks> as the team decided to switch to debian/testing as base - and me wants sid :-)
[20:55] <JanC> you could try the ubuntu-devel-discuss mailing list
[20:56] <dileks> greearb: isnt ubuntu now using overlayfs for live-medium?
[20:56] <greearb> I did, and CC'd the maintainer, and no response to the patches.
[20:56] <greearb> it isn't in 12.04
[20:56] <greearb> but supposedly it will use overlayfs for the next release
[20:57] <greearb> well, maybe didn't CC them on that post..but tried elsewhere :P
[21:12] <apw> greearb, we have used overlayfs in our live media for at least the last two releases
[21:13] <greearb> I can promise you that aufs is used by default in 12.04
[21:14] <greearb> maybe overlayfs is supported too..there is code related to it in casper, but it's not used by default.
[21:18] <apw> greearb, if it is it is a bug, the default in the code _i_ added should be overlayfs
[21:19] <greearb> I saw a mention on some list where at the last moment they switched back to aufs because of overlayfs bugs...
[21:20] <apw> greearb, well all i can say to that is why didn't they tell me
[21:21] <greearb> I'm on the outside looking in....I really have no idea of who is doing what with that stuff
[21:21] <greearb> is there even a git (or svn or whatever) tree for that code somewhere?
[21:21]  * apw ensures aufs is disabled in the next release so they can't do that to him again
[21:22] <apw> greearb, well i just booted a stick here with the release day image, and its using overlayfs
[21:23] <greearb> ummm, 12.04?
[21:23] <apw> the overlayfs code is in the ubuntu kernel repo
[21:23] <apw> greearb, yes 12.04 LTS indeed
[21:23] <apw> which matches my expectation
[21:23] <apw> you may be thinking of lxc
[21:24] <greearb> no..I spent weeks on this..I'm sure I was dealing with aufs
[21:24] <greearb> and I took a virgin 12.04 image as my baseline
[21:25] <greearb> For git repo, I was thinking of the casper initrd scripts..that is what chooses aufs or other and sets things up.
[21:55] <greearb> apw, do you happen to have an md5sum for the cdimage you used?
[22:06] <greearb> well, that's interesting..it *is* using overlayfs
[22:06] <greearb> I wonder what I did!
[22:12] <greearb> anyone reporting problems with Radeon in the latest Ubuntu 12.04 kernel? 
[22:16] <greearb> my persistent USB image is definately using aufs...I created it with the Universal USB Installer...wonder if it somehow twiddles something that makes it use aufs?
[22:23] <vanhoof> ogasawara: hi
[22:23] <greearb> gah, looks like this bug came to Ubuntu:  https://bugzilla.redhat.com/show_bug.cgi?id=785375
[22:23] <ubot2`> greearb: Error: Could not parse XML returned by bugzilla.redhat.com: HTTP Error 404: Not Found (https://bugzilla.redhat.com/xml.cgi?id=785375)
[22:58] <greearb> ok, created new usb image from virgin 12.04 cd and that doesn't use aufs either.  So, I must have done something that caused it to switch to aufs...gah!
[23:00] <greearb> ahh, I bet I know..I probably didn't upgrade the modules properly, so overlayfs failed to load, and it defaults to aufs :P