=== kentb is now known as kentb-out
=== BruceMa is now known as BruceMa_afk
=== BruceMa_afk is now known as BruceMa
[07:50] <ppisati> moin
=== smb` is now known as smb
[09:15] <mitya57> hi all, while trying to fix bug 1157421 I noticed that blktap-dkms depends on linux-headers-generic, which on 12.04.2 pulls in 3.2.x headers, not 3.5 headers
[09:16] <ubot2> Launchpad bug 1157421 in blktap-dkms (Ubuntu Precise) "blktap-dkms version in 12.04.2 is not compatible with the 12.04.2 kernel" [High,Triaged] https://launchpad.net/bugs/1157421
[09:16] <mitya57> my question is: what should I do if I want to make my package build against 3.5 headers?
[09:17] <mitya57> I probably even want it to be 3.5 for those with kernel 3.5 and 3.2 for others
[09:24] <amitk> smb: apw: is there a meta package I can install to get the latest mainline kernels from the mainline PPA? Or is it always a manual process?
[09:24] <amitk> nouveau is horribly broken in 3.8
[09:25] <amitk> and nvidia binary drivers too
[09:25] <smb> amitk, afaik always manual
[09:26] <amitk> smb: is it done on purpose? or did s
[09:26] <amitk> oops
[09:26] <amitk> smb: or was it just lack of time to do this?
[09:28] <smb> amitk, No I suppose it is deliberate
[09:28] <smb> amitk, Those are for testing not for constant use
[09:29] <amitk> smb: -rc2 / -rc3 not fit for constant use?!!! You must be joking...
[09:29] <amitk> ;)
[09:29] <smb> amitk, you know I am never joking :-P
[09:31] <smb> amitk, Would be good to find things to unbreak nouveau at least in the raring kernel
[09:31] <AceLan> mitya57: man dkms and read BUILD_EXCLUSIVE_KERNEL=
[09:34] <mitya57> AceLan: it would *build* against the exclusive kernel, I wondered what should I do with dependencies (which should be installed before building)
[09:35] <mitya57> anyway jamespage sais that that dependency was not actually needed
[09:35] <mitya57> *says
[09:36] <amitk> smb: it must be some interaction between the latest unity and nouveau that breaks it, atleast on my desktop (bug 1154431)
[09:36] <ubot2> Launchpad bug 1154431 in unity (Ubuntu) "Unity doesn't start up" [Undecided,Confirmed] https://launchpad.net/bugs/1154431
[09:39] <smb> amitk, That isn't by chance some dual-monitor setup? Just asking because I had some hilarious effects with that on a laptop with ati graphics.
[09:40] <smb> Otherwise maybe RAOF is interested (if he is not asleep by now)
[09:41] <amitk> smb: I dare not even plugin my second monitor at this point. First X wouldn't start (at all), then unity wouldn't, now it crashes whenever I hit the windows key to bring up the dash (?)
[09:42] <smb> quality...
[09:44] <amitk> smb: to be fair, progress has been made, so i hope to have a useable desktop by release
[09:45]  * cking grabs a screwdriver..
[09:48] <smb> amitk, Yeah, there is always that hope. Just seems that there is quite a lot to cover. apw had a lot of fun with some older i915, I had the (older) ati fun and the cirrus gfx used by VMs by default has issues as well.
[09:49] <ogra_> amitk, its all fine, we will ship a piece of duct tape along with the images so you can lock your win key  to not do that
[09:54] <amitk> ogra_: :) Add Alt+Tab and the browser to that blacklist.
[09:54] <ogra_> yeah, no prob :)
[09:54] <ogra_> with ubuntu touch we have our own browser anyway now 
[09:54] <amitk> ogra_: we do?
[09:55] <ogra_> yep
[09:55] <ogra_> the great thing is it cant do tabs ... one websire is enough for everyone !
[09:55] <ogra_> *website
[09:57] <amitk> ogra_: lol
[09:57] <ogra_> so much less confusion when surfing :)
[09:58] <ogra_> and indeed no bookmarks either, finally something that trains your brain
[09:58] <amitk> we have been getting to lazy, that's true
[09:58] <amitk> *too
[10:08] <amitk> bjf: your bot confirmed the bug I filed, have you seen this elsewhere? I've just posted a link to the 3.9 tree that might fix bug 1158689
[10:08] <ubot2> Launchpad bug 1158689 in linux (Ubuntu) "nouveau and nvidia binary drivers are broken for GeForce 8400 GS" [Undecided,Confirmed] https://launchpad.net/bugs/1158689
[10:10] <apw> amitk, no no meta they arn't in a repo after all
[10:12] <amitk> apw: ack, makes sense (not in a repo). Would be handy though, to allow users to upgrade to the latest crack automatically to find if their problems are fixed (so they can report back when it is fixed)
[10:13] <ppisati> apw: when you're awake and fuly operational
[10:13] <ppisati> apw: i've a quest for you
[10:13] <apw> ppisati, a guest ?
[10:14] <ppisati> apw: a quest
[10:14] <ppisati> apw: have you ever played to D&D?
[10:15] <ogra_> with guests ?
[10:15] <ppisati> ogra_: maybe :)
[10:15] <ppisati> ogra_: not necessarily
[10:23] <apw> ppisati, d&d a long long time ago
[10:24] <ppisati> apw: just kidding
[10:24] <ppisati> apw: well, it's debian packaging question
[10:25] <ppisati> apw: basically, i just noticed that renaming 'omap' to 'generic'
[10:25] <apw> ppisati, yep
[10:25] <ppisati> apw: one of the side effect was that a lot of modules are not part of linux-image anymore
[10:25] <apw> ahh yesh they are in in linux-image-extra
[10:25] <ppisati> apw: but are moved to 
[10:26] <ppisati> apw: right
[10:26] <ppisati> apw: do you exctly know where i should put my hands to fix it?
[10:26] <apw> ppisati, i am not sure as things are you can, generic is either split or it is not
[10:26] <apw> that may be or may not be a problem
[10:27] <apw> we could just ignore it and make the meta for arm -generic the same so it pulls in both
[10:27] <ppisati> apw: uhm ok
[10:27] <ppisati> apw: but in that case i want to do some adjustment first
[10:28] <ppisati> apw: like moving some 'vital' modules to -image
[10:28] <apw> ppisati, yeah that would be sensible indeed, the split is to allow virtual to be smaller
[10:28] <apw> ppisati, and it depends if we will ever have an arm virtual
[10:28] <ppisati> apw: and, besides, image-extra fails to install for some yet unknown reason
[10:29] <ppisati> apw: i mean, if it's easy to put a check like 'apply this split rule on if arch != armhf'
[10:29] <ppisati> apw: then i would like to do it
[10:29] <apw> ppisati, when i have fixed this cve issue henrix has me looking at i'll see how easy it is to do just that
[10:29] <ppisati> apw: ok, thanks
[10:29] <apw> ppisati, yep
[10:40]  * ppisati back in 20
[10:59] <brendand_> henrix, is the lucid kernel in -proposed the last one coming through before end of desktop support?
[11:02] <henrix> brendand_: i don't think so. i believe we'll have another one - there's a regression being worked out at the moment
[11:08] <apw> henrix, ok the matrix is updated, i think that looks better
[11:09] <henrix> apw: yep, it does! cool!
[11:09] <apw> henrix, a heap of raring went to released, which is a good sign
[11:10] <henrix> apw: yeah, i've seen that. uff... finally this is sorted out :)
[11:11] <apw> henrix, we only add versions so very rarely that i always forget
[11:11] <henrix> apw: and soon we'll be *removing* 2 versions ;)
[11:28] <apw> henrix, yeah looking forward to losing those
[11:28] <apw> henrix, are you going to review and push the latest autotriage or shall i
[11:29] <henrix> apw: hmm... push? isn't the push done automagically?
[11:30] <apw> henrix, the autotriager pulls in our stuff and merges their stuff and produces a result, we still have to pull that down review it and push it to where security pulls if we are happy
[11:30] <apw> henrix, someone must be doing that for the thing to be getting to security though
[11:30] <apw> so we maybe missunderstanding each other
[11:31] <henrix> apw: mumble?
[11:31] <apw> henrix, can't from here, not enough bandwidth
[12:08] <apw> henrix, bjf, sconklin, FYI the linux-overlay file is now in the security repo as active/10autotriage.linux
[12:08] <apw> (i didn't chose the name :))
[12:08] <apw> choose
[12:29] <ppisati> bjf: i'm doing the topic branches rebases right now
[12:52] <apw> henrix, what was this latest respin ?
[12:53] <henrix> apw: yep, unless something urgent comes up, this was the last respin
[12:53] <apw> henrix, which series
[12:53] <henrix> apw: Hardy and Oneiric
[12:54] <henrix> apw: from the kt meeting minutes: "Note: This is the week the last Hardy and Oneiric kernels may be built." :)
[12:54] <apw> ahh ok this is a normal spin
[12:55] <henrix> apw: ups, i messed up your question with your pm :)
[12:56] <apw> yeah was asking about the ppisati rebases, to know if i was expecting any lowlatency ones
[12:57] <apw> if it is a normal 3 weekly batch this time, then i guess yes :)
[12:58] <henrix> yep
[13:00]  * henrix -> lunch
[13:15] <stefanct> can someone please give me some up to date pointers to the state of the -realtime kernel? all i find is outdated information referencing bogani's PPA
[13:31] <zequence> stefanct: There's no realtime kernel since 9.10
[13:31] <zequence> stefanct: linux-lowlatency has taken its place, which is not a realtime kernel
[13:34] <stefanct> that's the history of the official repositories only(?) but apparently there were some efforts by bogani regarding 12.04?
[13:35] <stefanct> but essentially... if i want a -rt or -realtime (i.e. ubuntu flavoured or vanilla kernel + rt patches (whatever is left of them/not upstream yet)), i'll have to grab the patch and build it myself, right?
[13:40] <stefanct> -lowlatency does not improve my use case AFAICS
[13:41] <stefanct> my problem is that clock_nanosleep with TIMER_ABSTIME sleeps way too long
[13:42] <stefanct> 		clock_nanosleep(CLOCK_MONOTONIC, TIMER_ABSTIME, &sync_ts, NULL);
[13:42] <stefanct> 		clock_gettime(CLOCK_MONOTONIC, &ts);
[13:42] <zequence> stefanct: There was no effort on getting the -rt in. At least no real one
[13:42] <stefanct> for a sync_ts.tv_nsec of 0
[13:42] <stefanct> results in 00:01:07.000011587
[13:42] <stefanct> i.e. constantly >10us "too late"
[13:42] <stefanct> it never comes even close
[13:43] <stefanct> and that is with cpu shielding, SCHED_RR etc on an idle machine
[13:43] <zequence> I think Bogani kept the door open for that, but no one else was interested at the time. There's a small chance the we in the Ubuntu Studio team might be interested in reintroducing it
[13:43] <stefanct> np, i have to patch my kernel anyway for my project
[13:44] <stefanct> i just need to find out if the -rt patch would help me at all and that would have been easier with a binary
[13:44] <stefanct> need to run now, bbl
[13:44] <zequence> stefanct: Debian has a -rt kernel
[13:44] <zequence> debian wheezy
[13:45] <stefanct> ok, will look into that, thx
[14:17] <ppisati> bjf: the multiple closure in q/master is giving me (actually kteam-tools/maintscripts/verify-release-ready)
[14:18] <ppisati> bjf: i'll have to mangle a bit the syntax
[14:19] <ppisati> bjf: uhm no
[14:20] <ppisati> bjf: during the 'unique release tracking bug'
[14:20] <ppisati> bjf: verify-release-ready tries to parse the last section of debian.master/changelog
[14:20] <ppisati> bjf: and since it can't find the Release Tracking Bugs there
[14:20] <ppisati> bjf: check fails
[14:21] <bjf> ppisati, after you rebase, don't you go into the changelog and add the correct tracking bug information?
[14:22] <ppisati> bjf: yes i do
[14:22] <ppisati> bjf: but it tries to compare my tracking bug
[14:22] <ppisati> bjf: with the one found in master
[14:22] <ppisati> bjf: but since last section in master doesn't contain one
[14:22] <tjaalton> heads-up, bug 140716 is a regression on precise and quantal kernels
[14:22] <ubot2> Launchpad bug 140716 in skktools (Ubuntu) "[Sync request] Sync skktools (1.2+0.20061004-3) from Debian unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/140716
[14:22] <tjaalton> uh
[14:22] <ppisati> bjf: it fails
[14:22] <tjaalton> bug 1140716
[14:22] <ubot2> Launchpad bug 1140716 in linux (Ubuntu Raring) "[regression] 3.5.0-26-generic GPU hangs" [Critical,Confirmed] https://launchpad.net/bugs/1140716
[14:23] <tjaalton> seems to hit sandybridge machines
[14:23] <bjf> ppisati, ok, don't sweat it. if you are happy with your rebase and it builds well pull it in and look at what verify-release-ready is having trouble with
[14:24] <ppisati> bjf: ok, just wnated to prevent an error in the SRU pipeline later
[14:24] <bjf> ppisati, thanks for the heads-up, sconklin will deal with it :-)
[14:24] <ppisati> bjf: ok :)
[14:26] <sconklin> What bus?
[14:34] <bjf> jsalisbury, you want to do some bisecting of kernels to find the issue with ^ that tjaalton just mentioned
[14:50] <bjf> infinity, the regression found in lucid kernel 2.6.32-46.105 was actually introduced in 2.6.32-45.104 how do you feel about pushing .105 into -updates ?
=== kentb-out is now known as kentb
[14:51] <infinity> bjf: Doesn't hurt my feelings terribly, if jjohansen is cool with it too.
[14:51] <infinity> bjf: if so, just update the bug to lie about passing regression testing and let the bot do its thing.
[14:52] <bjf> infinity, ack
[15:09] <rtg> apw, can you have a look at raring master-next tip and tell me why the CONFIG_USB_EHCI_HCD_PLATFORM and CONFIG_USB_EHCI_HCD_PLATFORM enforcement rules are failing ?
[15:10]  * rtg -> back in a bit
[15:35] <jsalisbury> bjf, yes, I'll do a bisect for that bug
[15:35] <bjf> jsalisbury, thanks
[15:37] <josepht> the red/green are reversed
[15:37] <josepht> red for up, green for down
[15:54] <bjf> jjohansen, ?
[16:17] <ppisati> rtg: http://paste.ubuntu.com/5637397/
[16:21] <apw> rtg, yep
[16:22] <rtg> apw, nevermind, ppisatisuggested a fix
[16:23] <apw> ok
[16:25] <rtg> apw, just pushed 3.8.4 rebase plus omap4->generic. off to do some build and boot testing.
[16:25] <apw> rtg, great
[16:29] <apw> rtg, i think the do_extras_package twiddle is probabally 'the wrong thing' we should probabally be cleverer (it is still the right thing for right now) maybe we can brainstorm when we are together
[16:30] <rtg> apw, I actually did it 2 ways. first I thought that we shuold just hard code the logic in the generic debian rules, but then I remembered that Xen is forthcoming for armhf.
[16:31] <apw> yeah, i suspect that logic should be more like 'list per flavour/arch of inclusion lists' or something
[16:31] <rtg> apw, maybe what we ought to do is revisit the extras package and 'generic' name dependency.
[16:31] <apw> anyhow, that is a beer discussion, and whats there is purfectly servicable to get us past here
[16:31] <apw> rtg, right ... i think it is a 'put the contents of this list in this package name for this arch/flavour' thing we need
[16:32] <apw> so extras goes away as a thing and becomes a parameterisation of the new thing
[16:32] <apw> i'll have a thing and bring a propsal to our meet
[16:32] <rtg> get it on the agenda
[16:32] <rtg> (so we look busy) 
[16:33] <bjf> if it isn't written down, it didn't happen
[16:33] <apw> rtg will do
[16:35] <apw> rtg, bjf, done
[16:56]  * ppisati -> gym -> EOW
[17:27] <jjohansen> infinity, bjf: I am fine with pushing 2.6.32-46.105 into updates
[17:27] <infinity> jjohansen: Good, cause I did so about 3 minutes ago.
[17:27] <jjohansen> hehe
=== yofel_ is now known as yofel
[17:33]  * rtg -> lunch
[18:05] <rtg> henrix, is this the result of a stable patch? https://launchpad.net/~canonical-kernel-team/+archive/ppa/+build/4392085/+files/buildlog_ubuntu-lucid-ia64.linux_2.6.32-46.106_FAILEDTOBUILD.txt.gz
[18:05] <henrix> rtg: yes
[18:06] <henrix> rtg: https://lkml.org/lkml/2013/3/20/553
[18:08] <rtg> henrix, it likely affects PPC
[18:08] <rtg> as well
[18:08] <henrix> rtg: no, i don't think it does. let me check...
[18:08] <bjf> sconklin, i guess i'm ok with doing a revert, and pulling in the new patch
[18:09] <bjf> sconklin, after it's reviewed on the mailing list
[18:09] <henrix> rtg: mips, blackfin, ia64, parisc and tile
[18:09] <henrix> (from the discussion in lkml)
[18:09] <rtg> henrix, right, mips was the upstream complaint
[18:09] <henrix> here's ben's proposed patch: https://lkml.org/lkml/2013/3/20/712
[18:10] <henrix> but i'm not sure if that's the solution that will be adopted by stable
[18:10] <sconklin> bjf: it's a fast respin for lucid, there are no dependent or derivative packages
[18:10] <bjf> sconklin, henrix, then i think we just revert and wait for it to come through stable
[18:10] <henrix> bjf: yeah, that's my preferrence too
[18:12] <henrix> bjf: i've seen this prob earlier today and forgot it could affect us. didn't remember we supported ia64 for lucid :p
[18:12] <bjf> sconklin, so let's go with a revert
[18:14] <sconklin> I'll just count this as two acks and apply it?
[18:14] <bjf> rtg, ^ work for you?
[18:14] <rtg> bjf, its a simple patch
[18:14] <rtg> so, yes I'm OK with it
[18:14] <sconklin> I'll let someone else pull and have a look at master-next before I wrap it up
[18:15] <bjf> rtg, you are ok with the revert?
[18:15] <rtg> bjf, or we could just apply the proposed upstream patch, its just an ifdef for various arches
[18:16] <sconklin> ok, next question. One CVE patch hit master-next since I spun it, I plan to include that while I'm respinning
[18:16] <sconklin> everyone ok with that also?
[18:16] <bjf> sconklin, yes with the additional CVE patch
[18:16] <rtg> CVE patches are special :)
[18:16] <kamal> lalalalalala
[18:17] <bjf> sconklin, i agree with rtg now, lets just take the upstream patch for the busted CVE patch
[18:17] <kamal> QA ... Friday-style!
[18:17] <kamal> ;-)
[18:17] <rtg> kamal, racing up on beer time. things get decided quickly.
[18:18]  * kamal gets out of the way
[18:18] <bjf> sconklin, let's run it accross the mailing list but i think you got two acks
[18:18] <bjf> sconklin, so just plow on ahead with it
[18:18] <sconklin> ack, that makes it a lot less pressure
[18:18] <sconklin> mail the patch
[18:18] <henrix> bjf: rtg: please note the comment in ben's patch: "we can use one of the attached (untested) patches..."
[18:19] <rtg> henrix, yeah, but its pretty obvious.
[18:19] <bjf> henrix, i guess we'll be testing it :-)
[18:19] <rtg> its actually a compile time check
[18:19] <henrix> rtg: bjf: ack, i'm ok with that then :)
[18:19] <apw> heh ... cve fun indeed
[18:19] <henrix> apw: its been a *long* day :)
[18:20] <apw> heh seems so indeed
[18:21] <sconklin> long week. I started monday by breaking half the world
[18:26] <sconklin> who's mailing the patch?
[18:28] <henrix> sconklin: i can do that
[18:28] <rtg> sconklin, I thought henrix ...
[18:28] <henrix> but actually you need 2 patches
[18:28] <henrix> give me 1 min to prep it
[18:28] <sconklin> ok, I just didn't want all of us to assume someone else was handling it :-)
[18:35] <henrix> ok, i've just sent the patches to the mailing list
[18:36] <henrix> note that i haven't build tested them
[18:37] <rtg> henrix, I'll handle 'em
[18:37] <henrix> rtg: ack, thanks
[18:40]  * henrix will call it a day before someone finds another broken cve
[18:40] <bjf> quick, run away
[18:40] <henrix> heh :)
[18:43] <apw> jsalisbury, on bug #1157952 ... it might make sense to make a raring kernel for him with that applied to test ... i would be unsure if they can boot non-ubuntu kernels easily in that environment
[18:43] <ubot2> Launchpad bug 1157952 in linux (Ubuntu) "SCSI keysense errors on console with Raring (3.8 kernel) within Windows Azure" [High,Incomplete] https://launchpad.net/bugs/1157952
[18:45] <rtg> bjf, sconklin: pushed lucid master-next if you'd like to start packaging
[18:46] <sconklin> rtg: on it
[18:46] <henrix> rtg: btw, these 2 patches should be aplied to all the other series, /me thinks (i haven't tried to apply them)
[18:46] <rtg> henrix, depends on if we have the affected arches. I don't think we do after lucid
[18:46] <henrix> rtg: otoh we may wait for the stable updates, as we're not breaking builds on them
[18:47] <henrix> rtg: true, i don't think so as well
[18:47] <rtg> henrix, then lets just wait on stable
[18:47] <henrix> rtg: ack
[18:47]  * henrix -> EOD (again)
[18:51] <jsalisbury> apw, ack
[18:59] <arges> hey. when i run 'fdr genconfig', why do I not see the virtual flavor configs? is this a separate command?
[19:01] <rtg> arges, virt is generated from generic using inclusion lists.
[19:02] <rtg> depends on the release. some are a bit different
[19:02] <arges> rtg: yea I noticed 3.2 has the config.flavor.virtual, while Q/R don't have this. I assume Q/R use inclusion lists
[19:02] <rtg> arges, yes IIRC
[19:03] <arges> rtg: so there is there a mechanism to get a config file by using genconfigs... or should I just boot a kernel and the config from there
[19:03] <rtg> arges, for virt ?
[19:03] <arges> rtg: yup
[19:04] <rtg> fdr clean prepare-virtual ?
[19:04] <arges> rtg:  i dont seem to have that target in my raring tree
[19:05] <rtg> arges, ok, for raring the config is the same as generic.
[19:05] <rtg> fdr clean prepare-generic
[19:06] <arges> hmm, dont' see to have that one either
[19:06] <arges> rtg: i'll look it up later. for now getting this from a VM will work
[19:07] <rtg> arges, ok, its working for me
[19:07] <arges> hmm
[19:08] <kamal> ~/src/linux/ubuntu-raring$ fakeroot debian/rules prepare-generic     <--- works for me too
[19:08] <arges> i'm in master-next
[19:08] <arges> not sure if that matters
[19:08] <arges> rtg: ahh in master it works. not master-next
[19:08] <rtg> shouldn't
[19:08] <rtg> it works in master-next as wekk
[19:08] <rtg> well*
[19:09] <arges> probably something i did
[19:27] <rtg> apw, still around ? please review ubuntu-raring-meta 'UBUNTU: Rename omap to generic'
[19:28] <rtg> oh, 7:30 in the UK. apw should be off quaffing a Friday beer.
[19:56]  * rtg -> EOW
=== AlexB is now known as Guest
=== kentb is now known as kentb-out