| phillw | stgraber: yikes! | 00:24 |
|---|---|---|
| phillw | not wishing to nag, do you guys have any further thoughts on bug 1007394 ? | 00:25 |
| ubot2 | Launchpad bug 1007394 in mdadm "Quantal daily fails to complete installation" [High,Confirmed] https://launchpad.net/bugs/1007394 | 00:25 |
| infinity | phillw: If I were you, I'd ask BenC if he can reproduce it. If so, he might be rather interested in fixing it. | 00:41 |
| infinity | (Not that others don't appear to be interested in fixing it, but debugging blind is hard) | 00:41 |
| phillw | infinity: is there a way to ask him? | 00:42 |
| infinity | phillw: IRC. | 00:42 |
| infinity | phillw: He's in #ubuntu-devel | 00:42 |
| phillw | infinity: okies, I'll wander into the lions den :P | 00:43 |
| * ScottK wonders why natty isn't moved to old-releases yet? | 06:08 | |
| ScottK | Sigh. Nevermind. | 06:16 |
| ScottK | I can't alphabetize. | 06:16 |
| ScottK | Same question, but maverick. | 06:20 |
| infinity | Crap, who accepted all the highbank stuff? | 07:18 |
| infinity | Oh, RAOF did. | 07:19 |
| infinity | Oh well. I had planned to give that a more thorough review. | 07:20 |
| RAOF | infinity: All the changes looked very clear to me. Is d-i so crazy that I need to significantly raise my threshold for “that looks obvious”? | 07:21 |
| infinity | RAOF: Sometimes, yes. And certainly in the case of flash-kernel. | 07:21 |
| infinity | Actually, likely for libdi and base-installer, too. | 07:22 |
| infinity | But meh. | 07:22 |
| infinity | I can just sleep and pretend I don't care. | 07:22 |
| RAOF | So, if those changes require significant review I think that puts them on the list of packages that I'll not touch in the queue, ever, and ping you instead :) | 07:25 |
| infinity | I might review them in the morning, despite their having been accepted already. | 07:28 |
| infinity | But I could just forget about it and make it SEP. :P | 07:28 |
| cjwatson | Newly uploaded packages should have sensible packagediff links again. | 07:28 |
| infinity | cjwatson: \o/ | 07:28 |
| cjwatson | I'll work on fixing up the past breakage shortly. | 07:29 |
| cjwatson | (What would have been your guess as to what all([]) returns? Though it wasn't entirely due to that ...) | 07:30 |
| RAOF | I don't *particularly* want to have a “all flash-kernel pings get redirected to infinity” policy, but it would make things simpler for me :) | 07:32 |
| Laney | I'd be disturbed if all([]) weren't True, but that's the logician in me. :-) | 08:21 |
| cjwatson | Oh, you're right, but sadly it's about ten years since I did formal logic | 08:21 |
| cjwatson | Actually more | 08:21 |
| cjwatson | If nothing else it makes obvious sense by reverse induction to the base case, if I actually think about it | 08:22 |
| cjwatson | All the incorrectly-private package diffs on Launchpad from the last few days are public now. | 09:04 |
| cjwatson | stgraber: ^- er, there's only one of those in the queue - it shouldn't keep repeating | 11:48 |
| cjwatson | mute mute queue new quantal-release | 11:48 |
| cjwatson | oops | 11:48 |
| cjwatson | unmute mute queue new quantal-release | 11:48 |
| cjwatson | mute queue new quantal-release | 11:48 |
| cjwatson | oops again :( | 11:48 |
| cjwatson | unmute queue new quantal-release | 11:48 |
| cjwatson | mute queue unapproved quantal-release | 11:48 |
| cjwatson | stgraber: FWIW this is a new case - signed UEFI binaries are always held for approval | 11:49 |
| cjwatson | or rather to-be-signed binaries | 11:50 |
| cjwatson | mute queue unapproved precise-proposed | 11:56 |
| cjwatson | It's seriously confused, poor thing | 11:56 |
| didrocks | it really sounds like a fun game TBH :) | 12:04 |
| mdeslaur | cjwatson: could you please release the "tiff" security update in the hardy queue? | 12:08 |
| cjwatson | done | 12:13 |
| mdeslaur | cjwatson: thanks | 12:13 |
| === niceguyj_ is now known as niceguyjames | ||
| stgraber | hmm, wondering what's going on there | 13:31 |
| stgraber | cjwatson: something must have gone wrong with the unapproved monitoring thread, having a look at the logs to check if they were useful for once | 13:34 |
| cjwatson | feel free to drop the mutes once it's fixed | 13:34 |
| stgraber | cjwatson: http://paste.ubuntu.com/1100062/ | 13:35 |
| cjwatson | Huh | 13:37 |
| cjwatson | Please file a Launchpad bug about that | 13:37 |
| stgraber | mute queue unapproved | 13:37 |
| stgraber | I believe that the bug on queuebot's side is that a failure doesn't flush the notification queue, it just keeps adding notifications to it, spamming the channel in the process... | 13:38 |
| cjwatson | Now where did the code for that go ... | 13:38 |
| cjwatson | WTF. There is code that's supposed to make this work, and it's even tested | 13:41 |
| stgraber | cjwatson: what queuebot is doing is roughly: lp.packagesets.setsIncludingSource(distroseries=lp.distributions['ubuntu'].getSeries(name_or_version="quantal"), sourcepackagename=lp.distributions['ubuntu'].getSourcePackage(name='efilinux')) | 13:42 |
| cjwatson | Oh, wait, maybe this isn't an LP bug | 13:42 |
| cjwatson | Can you remind me where the queuebot source is? | 13:42 |
| stgraber | lp:~ubuntu-core-dev/+junk/queuebot/ | 13:43 |
| cjwatson | Yeah, not an LP bug, give me a few minutes | 13:44 |
| cjwatson | well - arguably. it's being triggered because the title for PackageUploadCustomFormat.UEFI doesn't start with "raw-". A quick and stupid fix is http://paste.ubuntu.com/1100090/ | 13:47 |
| cjwatson | But really it would be better to use the new-improved interfaces here | 13:47 |
| stgraber | yeah, looking at the new interface is on my list, should make things quite a bit easier and more reliable | 13:49 |
| cjwatson | Hm, except that there isn't really an alternative to display_name that gives you the source package name without messing about | 13:49 |
| cjwatson | since AIUI you want to be able to get the source package name for binary uploads too | 13:50 |
| stgraber | yep, to query for the packagesets | 13:50 |
| cjwatson | There'd be an argument for a little extension to package_name to do that | 13:51 |
| cjwatson | It'd be about two lines of code and one line of test | 13:51 |
| stgraber | sounds reasonable ;) | 13:52 |
| cjwatson | Feel free to file a bug if that would make your life easier, and I may manage to fit it in | 13:53 |
| stgraber | so the workaround works (tested in another channel), but now efilinux isn't listed at all... will update queuebot to better deal with it after the 12.04.1 meeting (and will file a bug to get the source package name exported) | 13:53 |
| cjwatson | It's exported, just not for binary uploads | 13:54 |
| stgraber | cjwatson: how long are you planning to keep efilinux in unapproved? (so I make sure to run my tests before it disappears) | 13:54 |
| cjwatson | You could run tests against it in done after that | 13:55 |
| cjwatson | I asked Steve to have a look at it when he's next around | 13:55 |
| cjwatson | (Or we could arrange for you to be able to run tests against dogfood) | 13:55 |
| === niceguyj_ is now known as niceguyjames | ||
| micahg | is there any reason why palmer was reenabled? | 14:07 |
| cjwatson | maybe ask on #launchpad-ops (internal) | 14:08 |
| stgraber | cjwatson: queuebot seems to deal fine with efilinux now, just had to fix a bug where freenode would ignore some of the notices when posting a very large number of them without responding to a PING | 15:09 |
| stgraber | (it's now building a queue of notices to post and processes it by batch of 10. Should also allow to better cope with disconnects by simply reconnecting and continuing from where it was) | 15:10 |
| cjwatson | stgraber: thanks | 15:14 |
| bdmurray | why is the diff for udev still pending for precise? | 15:34 |
| bdmurray | or how can I deal with that? | 15:35 |
| stgraber | you can probably do a manual dget + pull-lp-source + debdiff? | 15:36 |
| cjwatson | bdmurray: udev is blacklisted because it causes debdiff to hang | 15:37 |
| cjwatson | Yes, you'll have to pull it by hand | 15:38 |
| bdmurray | okay, thanks | 15:38 |
| cjwatson | https://bugs.launchpad.net/launchpad/+bug/532904 | 15:38 |
| ubot2 | Ubuntu bug 532904 in launchpad "source package diffs missing for udev" [Low,Triaged] | 15:38 |
| cjwatson | Really https://bugs.launchpad.net/ubuntu/+source/diffutils/+bug/314436 | 15:39 |
| ubot2 | Ubuntu bug 314436 in diffutils "package-diff can generate infinite output" [High,Confirmed] | 15:39 |
| stgraber | yay, no crash ;) | 15:44 |
| === akgraner` is now known as akgraner | ||
| bdmurray | stgraber: will there be release notes for the point release? | 16:03 |
| bdmurray | stgraber: I'm looking at mdadm and bug 1002357 | 16:04 |
| ubot2 | Launchpad bug 1002357 in mdadm "sort out udev rules madness (3 editions installed into 4 files)" [Undecided,Fix released] https://launchpad.net/bugs/1002357 | 16:04 |
| skaet | bdmurray | 16:08 |
| skaet | yes, there will be release notes for the point release. They'll be under each of the product pages. | 16:08 |
| bdmurray | I'd feel better about accepting mdadm if there were release notes for the point release. Should that happen before it moves to -proposed or to -updates? | 16:10 |
| skaet | bdmurray, ?? there will be release notes for the point release. | 16:11 |
| stgraber | skaet: does the release note page already exist or should we add an ubuntu-release-notes task for now (so we remember to add it)? | 16:11 |
| skaet | stgraber, add to the ubuntu-release-notes task for now, so it doesn't get overlooked. | 16:12 |
| stgraber | bdmurray: can you do that? (add an ubuntu-release-notes task targeted to the point release) | 16:12 |
| skaet | 12.04.1 will need to be populated with the changelogs per product, and still sorting out the best way to do that. | 16:12 |
| bdmurray | stgraber: sure, no problem | 16:13 |
| utlemming | we have a criticial kernel regression that kills EC2 instances on oneiric. Do we have a way to pull bad SRU's? https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/1026690 | 16:25 |
| ubot2 | Ubuntu bug 1026690 in linux-meta "3.0.0.-23.38-virtual kernel regression kills EC2 instances" [Critical,Confirmed] | 16:25 |
| skaet | utlemming, please work with bjf to figure out best path | 16:31 |
| utlemming | skaet: thank you kindly | 16:31 |
| skaet | utlemming, what's the scope of impact on this? | 16:32 |
| utlemming | skaet: any user who updates has a dead EC2 instance | 16:32 |
| utlemming | skaet: instance-store users will lose all data. EBS users will have a very painful recovery path. | 16:32 |
| skaet | utlemming, ok, we probably need to start an incident report on this. Will start the discussion off with arosales | 16:33 |
| tseliot | hi, can anybody approve my upload of jockey in precise-proposed? pitti is ok with the changes | 17:19 |
| tseliot | I forgot to say please ;) | 17:30 |
| infinity | tseliot: Oh, you pinged me earlier? | 17:31 |
| infinity | tseliot: My context got wiped by the kernel drama, but I vaguely recall a nick highlight. | 17:32 |
| dobey | is alpha3 done? | 17:39 |
| tseliot | infinity: yes, so, the cedarview packages are in NEW and I have jockey in precise-proposed which needs to be approved | 17:39 |
| infinity | tseliot: s/are/were/ ... Someone rejected on earlier, my INBOX tells me. Unless there was a new upload already? | 17:40 |
| * infinity looks. | 17:40 | |
| infinity | Ahh, rejected and reuploaded. | 17:41 |
| tseliot | infinity: I asked pitti to do that for me, yes | 17:42 |
| tseliot | I had to reupload to fix a detail | 17:42 |
| tseliot | infinity: it all works correctly now | 17:43 |
| infinity | tseliot: Kay. Not sure when I'll get a chance to poke at it, but you could bribe any AA to do so. ;) | 17:43 |
| tseliot | infinity: such as? | 17:44 |
| dobey | is it safe for me to upload straight to quantal now for stuff that's in the image? | 17:44 |
| infinity | dobey: alpha3 hasn't started, so no, not done. :P | 17:45 |
| infinity | dobey: But yeah, it's as safe as it ever is. If you're uploading things that will break installability with skew, proposed first is still a nice idea. | 17:45 |
| dobey | not yet. i do have a new binary package though; which adds a python3 package :) | 17:51 |
| dobey | oh right, alpha3 is next week. well then :) | 17:52 |
| infinity | tseliot: jdstrand probably likes cookies. But volunteering other people isn't my thing. :P | 17:57 |
| tseliot | :) | 17:58 |
| infinity | tseliot: I'll find time to poke it, just can't make delivery promises today, I'm headless chickening. | 17:58 |
| tseliot | infinity: ok, thanks | 17:58 |
| micahg | he's not around until tomorrow and then will be playing catchup | 17:59 |
| dobey | oh, i am an idiot. | 18:15 |
| infinity | dobey: Can we quote that? | 18:17 |
| infinity | dobey: I'd say "out of context", but you were kind enough not to provide any. ;) | 18:17 |
| dobey | heh | 18:18 |
| dobey | i checked that upload thrice, and now just realized i forgot the new .install files | 18:18 |
| dobey | i wish debuild would complain more loudly about that | 18:19 |
| micahg | dobey: yeah, I've missed that before, sbuild displays the package manifest at the end which is nice, but you have to remember to check it | 18:20 |
| infinity | dobey: Will something in main be depending on this soonish? | 18:28 |
| infinity | dobey: (ie: if I promote it, will it stick?) | 18:28 |
| dobey | infinity: dirspec 3.99.2-0ubuntu2 fixes the missing .install files. and yeah, we need it for some of the other uploads i'm about to do | 18:38 |
| infinity | dobey: Right, I already accepted it to main, upload away. | 18:39 |
| dobey | ah ok | 18:39 |
| dobey | thanks | 18:40 |
| stgraber | skaet: I'm confused by the work item in https://blueprints.launchpad.net/ubuntu/+spec/other-q-ubuntu-flavors regarding packageset for flavours (I wasn't in that meeting) | 19:08 |
| stgraber | I now added support for notifications to flavours in queuebot so that their ISO tracker builds and packages in their set get them notified | 19:08 |
| stgraber | but from what I understand of the action item, we want queuebot to also send notifications when a package is added/removed from their packageset by cjwatson's script? | 19:09 |
| skaet | stgraber, yes, that's what was requested. | 19:10 |
| stgraber | hmm, fun, will have to add a new plugin for that then, it's not difficult to do but it's really slow, the script I have on chinstrap doing that takes around 15min to run IIRC | 19:11 |
| stgraber | glad I added multi-threading support to queuebot otherwise that'd be a bit problematic to run ;) | 19:11 |
| === yofel_ is now known as yofel | ||
| skaet | stgraber, ok. If some aren't going to be possible this release, please go ahead and mark them POSTPONED | 19:13 |
| stgraber | well, that one should just take an hour or so to implement as I already have that code on chinstrap, just need to queuebot-ify it. I'll be messing with the packagesets a bit to confirm it works | 19:14 |
| stgraber | sorry for that, trying to get the bot to join a channel with some ACLs ;) | 19:27 |
| ScottK | stgraber: ^^^ was on my must have for 12.04.1 for server upgrades list. That's done. | 19:47 |
| highvoltage | nice | 19:48 |
| highvoltage | (oh, unapproved, oops) | 19:48 |
| stgraber | ScottK: yay, one less on the list :) thanks | 19:51 |
| micahg | awesome, 12.04.1 is right before Firefox/Thunderbird 15, so people will get a huge update the next week, I guess that's still the best place for it, otherwise, if it was right after, we'd have the fear of needing a respin for upstream respins :) | 19:53 |
| infinity | micahg: They get huge upgrades every week anyway, oh well. | 19:54 |
| stgraber | packageset monitoring added, I'll be doing a test during the next hour, so you should see lxc being added to the edubuntu packageset then removed later on | 20:09 |
| stgraber | the packagesets are parsed every 15min | 20:09 |
| ScottK | To whom do these announcements get sent? | 20:10 |
| stgraber | #ubuntu-release + #ubuntu-dmb for all changes and to #edubuntu for the edubuntu packageset | 20:11 |
| stgraber | there's a flood protection set at 25 entries, so when introducing a new packageset, we shouldn't get spammed | 20:12 |
| skaet | infinity, am working through the nusakan crontab, looking for good spots to insert precise builds, and am a bit perplexed that we don't have problems with: | 20:14 |
| skaet | 22 0 * * * buildlive kubuntu-active daily-live && for-project kubuntu-active cron.daily-live | 20:14 |
| skaet | 24 0 * * * buildlive edubuntu-dvd dvd && for-project edubuntu cron.dvd | 20:14 |
| skaet | thoughts? | 20:15 |
| skaet | (or more precisely, its the cdimage crontab on nusakan) | 20:16 |
| ScottK | stgraber: Could Kubuntu ones go to #kubuntu-devel? | 20:16 |
| stgraber | ScottK: sure. do you also want build notifications and queue notifications for kubuntu packages and images? | 20:16 |
| ScottK | How about just for images for now. | 20:16 |
| stgraber | ok, configured for packageset + images matching kubuntu (I don't really expect much changes going to the packagesets and images are only posted during milestones) | 20:19 |
| infinity | skaet: Curious, that's 44,0 for edubuntu in the canonical version. | 20:24 |
| infinity | Or... it was until someone changed it very recently. :P | 20:25 |
| stgraber | I changed it, did I forget to push it somewhere? | 20:25 |
| * stgraber checks local branches | 20:25 | |
| infinity | skaet: Anyhow, it all has locking, it's not a "problem", per se, to run them all at exactly the same time, except that it makes it unpredictable what order they'll spit out in. | 20:25 |
| infinity | skaet: For dailies, that really isn't a huge deal. They finish when they finish. | 20:25 |
| infinity | stgraber: You changed it in 1450, I didn't have a current checkout. | 20:26 |
| infinity | stgraber: But you changed it to be 2 minutes after kubuntu-active, that's all. | 20:26 |
| infinity | Ultimately, none of it matters nearly as much as people think it does. | 20:26 |
| skaet | infinity, if the locking is in place, then yeah, not a problem. Was wondering why it wasn't fussing/causing issues. | 20:27 |
| skaet | and that would explain it. | 20:27 |
| infinity | We could just run all the daily jobs at the exact same time, and let the mystery of when the images spit out the other end be fun and exciting every day. | 20:27 |
| stgraber | infinity: yeah, I aligned it to start as soon as an armhf builder is free. IIRC kubuntu-active is mostly failing so it hasn't been a problem so far | 20:27 |
| stgraber | I don't mind if Edubuntu has to wait an hour to start building on i386 as we have a two hours long arm build in the same batch | 20:28 |
| skaet | infinity, nah, but it might be nice to get all of the auto tester ones built early, so results are waiting when we get up. ;) | 20:28 |
| infinity | To be fair, "we" all get up at different times. | 20:29 |
| infinity | So, I assume you mean when *you* get up? :) | 20:29 |
| skaet | infinity, actually was think that it would be nice so it would be ready when babyface gets up, since he's doing first pass on the auto test results. ;) | 20:30 |
| skaet | but more orienting to Europe actually. ;) | 20:30 |
| skaet | stgraber, am not seeing Edubuntu armhf on the iso tracker under quantal. Should it be added? | 20:31 |
| infinity | Anyhow, it's not something we'll ever get perfect. We could try to align the ubuntu and server images to a specific "good time", and just make all the others wait for "some reasonable amount of time later". | 20:31 |
| infinity | But I suspect that the more we try to mangle it all, the more we just realise it breaks someone else's expectations. | 20:32 |
| stgraber | skaet: I was waiting to have it build for the right hardware before doing that as we don't plan on releasing an omap4 image but an a10/zatab one. Though I'm still waiting on the kubuntu folks to know how to get the hardware to actually boot the kernel... | 20:32 |
| skaet | agree, will never be perfect | 20:32 |
| infinity | stgraber: Do we actually have an A10 kernel in the archive? I missed that memo. | 20:33 |
| bdmurray | stgraber: bug 929092 is missing sru information | 20:33 |
| ubot2 | Launchpad bug 929092 in ubiquity "ubiquity crashed with DBusException in call_blocking(): org.freedesktop.DBus.GLib.UnmappedError.NmSettingWirelessSecurityErrorQuark.Code1: Failed to determine AP security information" [Medium,In progress] https://launchpad.net/bugs/929092 | 20:33 |
| stgraber | infinity: nope, it's on my todo once I actually get it to boot somewhere :) | 20:33 |
| stgraber | bdmurray: oops, missed that one. fixing | 20:34 |
| infinity | stgraber: AFAIUI, AllWinner's being even worse about upstreaming than most SoC vendors traditionally are, so it's going to be a stupidly massive patchset (and hard to keep in sync with our fast-moving kernel team). :/ | 20:34 |
| skaet | stgraber, then why were you waiting on the arm builders in doing the scheduling? | 20:35 |
| infinity | skaet: Because he's building test images, he's just not "releasing" them. | 20:35 |
| stgraber | bdmurray: done | 20:35 |
| skaet | infinity, ack | 20:35 |
| stgraber | ^ one more "removed" to show up in 5 minutes and I'll be done with my tests of the packageset monitoring | 20:36 |
| stgraber | infinity: yeah, linux-allwinner is a bit scary, we're going with that hardware platform as a tech preview (because we can easily get unlocked hardware with developer prices). Kubuntu is going with the same hardware too and some others have interest in getting a10 support (rsalveti has some a10-based tablet too). | 20:40 |
| infinity | stgraber: Oh, tons of people are interested in A10 support. Their pricing is hard to beat, so there will be a metric crap-ton of devices. I just wish they'd learn to upstream sanely. :/ | 20:40 |
| infinity | stgraber: Or throw some money at Linaro to do it for them. | 20:41 |
| infinity | (I also wish both Apple and AllWinner hadn't decided to name their cores A[int]... So friggin' confusing in the ARM landscape) | 20:41 |
| infinity | I've already seen one vendor (not a random user, an OEM) calling it the AllWinner Cortex-A10. | 20:42 |
| stgraber | hehe, yeah, that's quite confusing. IIRC the box had something along the lines of "Allwinner Cortex A8 A10" written on it, which isn't technically wrong, but still... | 20:43 |
| micahg | seb128: component-mismatches exploded due to webkit, you might want to drop the recommends on gstreamer0.10-plugins-bad | 21:10 |
| seb128 | micahg, I'm not touching webkit again, whoever cares can do it | 21:11 |
| micahg | heh | 21:11 |
| seb128 | I'm not even running quantal | 21:12 |
| seb128 | the only reason I did it was because other updates broke software-center and other stuff and nobody was going to do it | 21:12 |
| seb128 | but I don't have time nor will to maintain webkit | 21:12 |
| cjwatson | stgraber,skaet: um - I only run the packageset update script every so often, and it typically makes on the order of one or two hundred changes | 22:04 |
| cjwatson | who requested this, and did they really know what they were asking for? I'm really not convinced that this is a good fit for IRC notifications | 22:05 |
| stgraber | cjwatson: yeah, that's why I found the feature request a bit odd in the spec, but well... it didn't take long to implement, it won't flood on update (limit of 25 similar to the tracker) and is useful at least to the DMB | 22:05 |
| cjwatson | I can't see it being useful in this channel, at least ... | 22:06 |
| cjwatson | I can understand why people asked for it. I just don't think they'll actually like it. :-) | 22:07 |
| stgraber | it was in the infrastructure for flavours session, the comment says "packageset updates every hour with colin's script, any changes need to go there." which doesn't really match your "every so often" :) | 22:08 |
| cjwatson | that's an utter myth | 22:18 |
| cjwatson | I don't know who said that but they were making it up | 22:18 |
| rsalveti | infinity: cool, cortex A10 :-) | 23:17 |
| rsalveti | newer than what we have :P | 23:17 |
| ajmitch | if only that were true in my tablet | 23:26 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!