[00:01] skaet: ack [00:04] * skaet --> dinner [00:56] all for -proposed, I guess? [00:58] slangasek: They were all for -release, I rejected them all and asked Robert to reupload to -proposed. [00:58] ah, ok [00:58] I think he missed the "we're staging GNOME 3.4.0 in proposed" memo. [00:58] ah, well, I missed it too [00:58] :) [00:59] Yeah, seb was doing gnome 3.4 in proposed so that it would all build and stage and they could just release it on Friday after Beta with no fuss. [00:59] Which seems vaguely sensible. [00:59] * slangasek nods [01:06] stgraber: I give up for now; I'm not getting anywhere with this bisect / trawl through gnome-keyring/gcr history and I need sleep. Sorry. [01:13] cjwatson: thanks for trying for so long, good night! [01:20] heya, who let all the packages through? [01:22] * skaet goes and reads the backscroll [01:22] skaet: Those are all in proposed. [01:22] yup, just saw that, adrenaline levels subsiding. [01:22] skaet: :) [01:23] stgraber: queuebot could perhaps announce "$dist-$pocket", both on accept and removal. [01:23] stgraber: Might reduce heart attacks. [01:23] stgraber: Err, on in and out, I guess, don't want to overload "accept" in this context. [01:24] stgraber: It would also be awesome if there was a way to identify how something was removed from the queue (accept or reject), but I'm guessing you don't have that info to work with, just that it's gone? [01:28] infinity: yeah, I guess I could look in the Done queue if the package is there and announce it as approved then [01:29] problem is, that "queue" (or status) is kind of long to list ;) so I'd have to check if there's an easier way in the API [01:29] Oh, yeah, scanning done or rejected is a losing battle. Don't bother. [01:29] I forgot that queubot's just polling. [01:29] But if you could change (component) to (dist-pocket/component), that would be awesome. [01:29] when we have the audit changes implemented it should be easy to just pull that record and show who accepted/rejected it [01:30] And duplicate that info on Removed. [01:30] (I assume you still have the info when you remove, as you're just pulling a member from a list or something?) [01:33] stgraber: Or put it on a role account on one of your machines, so I can add cute little features when I'm bored. :P [01:36] let's try that [01:38] looks like it's working [01:38] infinity: happy? :) [01:39] infinity: you can always send merge proposals for lp:~stgraber/+junk/queuebot [01:41] stgraber: You're missing dist. Though, I guess that only matters if you have it scan non-release dists. [01:41] stgraber: (Which would actually be really handy, as I often don't notice when something's uploaded to, say, lucid-proposed) [01:41] s/non-release/non-devel/ [01:42] stgraber: Would be cool if it ran 24/7, and was useful for old dists too. I'm being picky, aren't I? ;) [01:42] should be doable but would make it a bit slower as unfortunately we can't call getPackageUploads() on a distribution, it needs to be on a distro_series [01:43] so the bot would need to call if for every supported release [01:43] Yeah, so you iterate through all supported series. [01:43] Doesn't need to poll as often for non-devel. [01:45] Shouldn't be too much slower, since you could call them all in parallel. [01:45] I've heard pretty neat things about threaded programming. It's all the rage, I hear. [01:45] Ooo, but pocket on the removal message is already a huge win. [01:45] skaet: Less heart-attack inducing? ---^ [01:45] I'm sure we can get cjwatson to implement the threading ;) [01:46] I'm not a python wizard, but it must have some really dead easy callback conventions, right? [01:46] Seems like the sort of thing a modern high level language should have. [01:47] infiniity, stgraber - thanks. :) [01:48] queuebot: What, not going to spam us with the current queue status on connect this time? [01:48] nope, it usually doesn't do it, I'm just forcing it to do it when I want to make sure it works [01:49] Ahh. [01:49] :) [01:49] otherwise it doesn't do anything then the first entry it sees I get a backtrace and it dies ;) [01:49] Poor bot. [01:50] I still need to make it's irc implementation a bit more standard compliant so it doesn't get killed for excess flood [01:50] though ignoring all the langpacks definitely helped there :) [01:50] Yeah, there shouldn't be much call for rate-limiting most of the time. [01:50] langpacks are a bit special. [02:36] infinity: implemented (watching all series) [02:36] just need a restart to make sure it works (and flood the channel some more ;)) [02:37] stgraber: Does it already do both NEW and UNAPPROVED? [02:37] stgraber: I've never paid attention. [02:37] infinity: it can, but it's currently restricted to Unapproved [02:38] stgraber: I'm guessing from the interleaved output there that you went multithreaded? [02:38] stgraber: Looks good. [02:39] infinity: nope, single thread but once the set is built it's sorted by package name, that's why series are mied [02:39] *mixed [02:39] Ahh. [02:40] I guess it'd make sense to change the order to first sort by series, then pocket, then package name, but it's only really useful when I get the bot to print everything at once [02:40] Yeah, printing everything at once shouldn't be a common use-case. :P [02:41] Unless you want to implement /msg ... [02:41] At which point, I think we're missing the point of the bot. ;) [02:42] right :) [02:43] I've also started implementing the ISO tracker api in the bot so it can show in #ubuntu-release and #ubuntu-testing when a new build is published during milestone testing [02:43] as the builds are automatically published from nusakan that should be useful for both the release team and testers [02:44] but I need to cleanup the code a bit first to properly handle that... ideally keeping the code somewhat readable [03:03] infinity: I have a version of the bot now monitoring both Unapproved and New for all supported releases [03:04] infinity: http://paste.ubuntu.com/901523/ [03:06] I think I'll need to add some logic to the bot to figure out if it's source or binary New and change what it shows [03:06] stgraber: You can probably 's/ package//' from that to make the lines a bit shorter, but otherwise awesome. [03:06] as showing /none and non-existent => is a bit pointless :) [03:06] stgraber: And yeah, could do "New (source)" or "New (amd64)", etc. [03:07] stgraber: And the bits you mentioned too. [03:20] infinity: http://paste.ubuntu.com/901540/ [03:22] stgraber: The anal retentive alignment freak in me wants to point out that if you remove the brackets from binary and source, it'll align perfectly with Unapproved. :P [03:25] oh, weird I didn't notice... /me fixes ;) [03:26] stgraber: I guess it's also collapsing multiple binNEW entries into one? [03:26] stgraber: (There are 3 for slphone right now, but only one on your list) [03:27] yeah, launchpad apparently does that for me [03:27] infinity: http://paste.ubuntu.com/901546/ <-- there, properly aligned now ;) [03:27] Pretty! [03:27] Shame about the collapsing behaviour. Means we can't watch all 5 arches trickle in, we'll only know about the first. [03:28] But it's still a good enough cue to go watch the queue. [03:28] Which is mostly what I want it for. I always forget to poll NEW, and end up surprised when there's 5-day-old binNEW stuff in there. [03:29] hmm, actually I might be able to separate the architectures looking at .display_arches [03:30] ubuntu studio needs their default-settings-package above in and respun with it (can wait if other fixes are needed to be respun with it) [03:30] s/default-settings-package/-default-settings package/ [03:30] micahg: Will review shortly. [03:31] infinity: thanks, do you need a pad update? [03:31] oh, sweet, display_arches actually tells you if it's a source upload or a sync too [03:31] stgraber: Interesting. [03:32] micahg: If studio's already been respun today, I'll just do it again. [03:32] infinity: thanks [03:32] infinity, ubuntustudio's just emerging now, so a respin will be necessary [03:32] Hahaha, indeed, it's actually building as we speak. [03:32] TIMING. [03:33] I'll kick off another build before I go to bed. ;) [03:33] * skaet nods... [03:33] * skaet likes stgrabers changes in the paste.bin too. :) [03:33] skaet: I won't be able to get to the onboard fix for xubuntu until the morning, the fix isn't needed for ubuntu or edubuntu, but they'd pick it up if they were respun afterwards [03:35] micahg, please update the pad then, and we'll pick it up/respin as necessary. [03:35] skaet: it wasn't on the pad to begin with [03:36] micahg, s/update/add it to/ :) [03:36] I can add it though :) [03:37] skaet, infinity: http://paste.ubuntu.com/901559/ [03:37] I simply added "(sync)" at the end if it's a sync, not sure if we want it more visible than that (it doesn't matter so much I guess) [03:38] stgraber: My alignment! [03:38] or I could make it "Unapproved sync" [03:38] infinity: you can't have both the architecture and your alignment ;) [03:39] stgraber: s,binary (amd64): wesnoth-1.10,binary: wesnoth-1.10/amd64,' [03:39] stgraber, looking lovely to me. :) lots of lovely info without having to go look up. [03:39] stgraber: Keeps source packages aligned with each other. ;) [03:40] infinity: true but then the format is no longer consistent :) [03:40] stgraber: Well, there only one case that shows arch, it's never consistent. [03:40] there's... [03:41] stgraber: The perhaps more LP-consistent place to show it would be in the dist/comp brackets (maverick-backports/universe/amd64) [03:42] But it's less immediately obvious there than it is tacking it right after the source package. [03:42] * infinity shrugs. [03:42] I'm picky about quickly parsable data. ;) [03:42] (And slightly dyslexic) [03:42] infinity: what do you think of me seeding mousetweaks in xubuntu for beta 2 vs this onboard bug fix [03:43] current format is basically: []: (pkg_pocket[/]) [current_version => pkg_version] (pkg_pkgsets) [(sync)] [03:43] micahg: I'm completely not caught up on what's up with onboard. [03:43] infinity: without mousetweaks it seems to barf without unicode encoding [03:43] infinity: but yeah, moving the architecture after the binary package name should be fine :) [03:43] trunk was fixed to use unicode encoding, there's a point release in progress that will include that fix amongst others [03:44] stgraber: Yeah, I'd just make that [], and pull arch out of entry type, but again, I'm dyslexic, every bit of alignment helps me track. [03:45] micahg: Not something you can easily backport/cherry-pick? [03:45] micahg: I don't like the idea of seeding packages as a workaround on our last Beta before release. It's not a particularly good way to represent the final product. [03:45] infinity: there is a fix and it looks innocuous enough, but as there seems to be a less risky fix... [03:45] micahg: (And means anyone installing with Beta keeps mousetweaks FOR EVA) [03:46] * micahg wonders if apt-get autoremove would DTRT once it's unseeded [03:46] No. [03:46] Not unless we changed something recently. [03:47] ok, I"ll try try to fix the patch in the morning, it doesn't apply cleanly ATM [03:47] Either way, I'd still prefer to look at the cherry-pick, since that represents what the actual fix will be before final, right? [03:47] infinity: http://paste.ubuntu.com/901570/ [03:47] infinity: http://bazaar.launchpad.net/~onboard/onboard/0.91/revision/764 [03:47] stgraber: <3 [03:47] stgraber: You just couldn't live with source/arch, could you? ;) [03:48] infinity: no, wasn't consistent with the other messages ;) [03:49] micahg: Looks remarkably straightforward. [03:49] infinity: right :) [03:49] There really needs to be a way to just tell python "all strings are unicode unless I cast them differently". [03:50] Having to cast it for every string is ridiculous. [03:50] infinity: you could try to PEPify that [03:50] Ew, no. [03:50] I'll just use C, like a sane person. [03:50] And stop worrying about high level laguages only holding my hand sometimes. [03:51] languages, too. [03:51] GIVE ME POINTER ARITHMETIC OR GIVE ME DEATH. [03:52] stgraber: Actually, to be consistent with other messages, I'd say the arch should be in square brackets, like the version is. ;) [03:52] stgraber: (I may just be messing with you now) [03:52] stgraber: It looks like a drastic improvement. [03:54] I'm just looking forward to it rolling out... and seeng the first message sow up. :) [03:54] infinity: square brackets actually sounds like a good idea ;) [03:54] Well here, have some messages. [03:54] infinity: would match the syntax used for Depends: [03:54] stgraber: That too, yeah. [03:55] *\o/* [03:56] square brackets upgrade ^ [03:56] * infinity hugs queuebot. [03:57] btw, why do we have new source packages in oneiric-proposed and oneiric-release? [03:57] the gnome:NextVersion thing didn't work right with gnome-shell, it's trying to depend on libmutter0 (>= 3.3), libmutter0 (<< 3.4) [03:58] stgraber: NEW in proposed isn't unheard of. [03:58] stgraber: NEW is release, let me look. [03:58] stgraber: partner. [03:59] ah, that'd explain it indeed [03:59] stgraber: The bot not showing component for source new would be why we didn't notice. :P [03:59] infinity, I'm reading the backscroll right in that when ubuntustudio-defaults-settings finishes building, a respin of ubuntustudio is being looked for? [04:00] I ignored the component for new source uploads as it'll default to universe for everyone, but apparently we're using it for patner, so I probably should show it anyway then [04:00] stgraber: Actually, it shouldn't default to universe for EVERYTHING. [04:00] stgraber: non-free maps to multiverse, and multiverse and restricted are left alone, if I recall. [04:00] stgraber: Just that things that don't declare a component end up in universe. [04:01] skaet: It's already done building, but when it's published in ~20 minutes, yeah. [04:02] infinity, ok, wubi's just about done, so that should line up nicely. Sticking it on the pad. [04:02] skaet: Pad away, if you want to drive, I'll wash my hands of it, then. ;) [04:02] I was going to just be a rebel and spin it when you weren't looking. :P [04:03] infinity, if you're feeling rebelious, I can go to bed. ;) [04:03] skaet: Works for me. I'm up for a while. [04:04] infinity, coolio. Will ping you when the wubi's done and you can kick it when it comes out of the publisher. [04:13] stgraber: No new queuebot with source components? Did bed happen? ;) [04:16] infinity: it's actually tricky to implement ;) [04:16] stgraber: Oh. I figured it would be the same as unaproved. Silly me. ;) [04:17] nope, for anything that's been published once, getPublishedSources will give me the data [04:17] but for something that never was published I still haven't found a way to get it [04:17] Ahh. The queue entry itself has no hint? [04:17] * infinity wonders where the web UI is pulling it from. [04:18] no, the queue entry is pretty limited: https://launchpad.net/+apidoc/devel.html#package_upload [04:18] I guess I could use archive_link which should work for partner [04:22] I'm guessing source_package.latest_published_component_name is nothing for NEW sources? [04:23] well, for that you'd need a source_package record [04:23] infinity, typo on the wubi build, exec: 111: cron.wub: not found *sigh* [04:23] skaet: *slow clap* [04:24] skaet: I can just do that with ubuntustudio. :P [04:24] 04:23 -queuebot42:#stgraber-release- New source: swauth (oneiric-proposed/primary) [1.0.2+git20111128-0ubuntu1.1] [04:24] infinity, do you want me to kick it off again now, or you want to fit it in with ubuntu-studio. [04:24] 04:23 -queuebot42:#stgraber-release- New source: jonas-full-5.2 (oneiric-release/partner) [5.2.1-0ubuntu1] [04:24] skaet: It already did the buildlive? [04:24] infinity: that's what I have currently, basically showing the name of the archive instead of the component for new sources (so primary or partner) [04:24] infinity, yup [04:24] kapok.buildd starting at Tue Mar 27 03:45:52 UTC 2012 [04:24] cardamom.buildd starting at Tue Mar 27 03:45:52 UTC 2012 [04:24] kapok.buildd finished at Tue Mar 27 04:17:01 UTC 2012 (success) [04:24] cardamom.buildd finished at Tue Mar 27 04:19:52 UTC 2012 (success) [04:24] stgraber: That'll have to do for now. [04:25] skaet: Kay, I'll finish up. [04:25] infinity, thanks. [04:27] skaet: Done. [04:27] infinity, on the arm builder side, mx5/ac100 are just finishing up, then its kubuntu's turn, and that's about it. [04:27] skaet: Check. I'm got IS working on some parallelisation love for me. [04:28] skaet: Probably won't have it before we're done with B2, but we should right after. [04:28] s/I'm/I've/ [04:29] Though, I guess it is only Monday. [04:29] Maybe I can shake up the world before your last Beta spin. ;) [04:29] skaet: I'll spend a few minutes tomorrow to have the bot also poll the ISO tracker for new milestone (non-daily) builds and announce them here + #ubuntu-testing [04:29] oooh, stgraber that would be very nice indeed. :) [04:29] stgraber: New builds in general might be nice, though with milestone versus daily tagging? [04:30] Or maybe that would seem too spammy. [04:30] We do build a lot of image. [04:30] images, too. [04:30] infinity, fingers crossed for that parallelization. :) [04:30] infinity: yeah, turning it on for dailies too will be easy, but I suspect we don't want that kind of spam between milestones :) [04:30] skaet: Oh, it's GOING to happen. Just not sure it'll be before your last spin on Wednesday/Thursday. [04:31] just hear from pgraner that the workaround seems to be effective, so on that note of good news, zzz time. [04:31] infinity: having the bot read image build failures would be kind of nice though as not everyone receives the e-mails [04:31] Well, we can put the bot in the mail loop. [04:31] So it doesn't need to poll. [04:32] all seems ok with light testing, QA will did deep in a few hours when europe comes online [04:32] pgraner: Sounds good. [04:32] infinity, hasta get some rest [04:33] What is this "rest" you speak of? ;) [04:33] * skaet --> zzz (can take a hint) [04:34] micahg: studio respinning now. [04:56] micahg: And done. [05:08] Good morning [05:09] kirkland: that script would also fit into update-manager, for example [05:09] morning pitti [05:10] skaet: still there? I'm confused by the pad [05:11] pitti: What's the confusion? *goes to look* [05:11] rebuild reasons 1, 6, and 13 do not exist in the list any more [05:12] but some images are still marked for rebuild [05:12] I look into the gnome-keyring FTBFS now, to unblock stgraber's fix [05:12] Well, everything was literally just respun. [05:13] So, I imagine she just didn't clear ac100/mx5 because they were in progress. [05:13] ah, ok [05:13] stgraber: ah, that timeout [05:13] stgraber: unfortunately we hit that sometimes, due to builders running very old kernels [05:17] pitti: Oh, I also just did studio. Removed that trigger from the pad. [05:18] pitti: But yeah, I think the stale ARM ones on the pad are because she went to bed while the build was still running. ;) [05:18] pitti: If they all succeeded, that can be removed. [05:18] infinity: ack, thanks [05:19] Oh, crap, but the studio and wubi builds I did weren't run with the autopost environment. [05:19] * infinity sighs. [05:19] infinity: is that even necessary? [05:19] I don't know. The pad implies such. [05:19] I forgot it as well the other day, and they were posted just fine [05:19] Maybe it lies. [05:20] if you confirm that as well, we can remove that from teh pad [05:20] * infinity looks. [05:20] yeah, the builds I just did autoposted. [05:20] That info is stale. [05:20] Delete away. [05:21] * infinity wanders off to do $something_else. [05:22] infinity: updated [05:37] gah, gnome-keyring hanging again; we need to find a buildd with a non-hardy kernel, it seems [05:39] I wasn't aware that any of the distro buildds had hardy kernels? [05:40] Most of them do. [05:40] hmm [05:41] why is that? I thought the distro builds were at lucid, and it was only the virtualized builders that were on hardy [05:41] I asked for cancelling them [05:41] but might get no response [05:41] it might be easier to do a no-change upload and assign thhem to zirconium and allspice manually [05:41] I don't know if any of the x86 ones are !hardy. [05:41] roseapple's one of the newest machines, and it's hardy. [05:41] * slangasek scratches his head [05:41] oh, I thought they were; darn [05:42] so we just need to keep retrying until they succeed, or disable the tests on amd64/i386 [05:43] so, no response on launchpad-ops [05:43] I guess we are blocking new rebuilds on that, right? so want me to do a no-change upload? [05:43] hang on, got response [05:45] * ScottK just did a qwtplot3d upload. It's unseeded universe. I'd appreciate it if someone would wave it through when it appears. [05:45] Thanks. [05:45] * ScottK tries to go to sleep (again). [05:45] *nod*, good night ScottK [05:45] There it is. [05:45] Thanks pitti. [05:50] pitti: zirconium and allspice are still hardy. Are you just hoping that a slightly newer SRU rev will do it? [05:50] it's mostly just luck [05:50] it doesn't usually fail twice in a row [05:50] but now it does because we are waiting for it, and looking at it [05:57] both built now, *phew* [05:57] Special. [05:57] so I guess I'll do some respins once that's published [06:01] so what changed to make g-k ftbfs on hardy kernels? was it doing that before? [06:03] slangasek: it's a sheer matter of luck [06:03] so this was a known problem before? [06:03] yes [06:03] it affects quite a few glib based packages, when they run tests [06:03] alrighty [06:04] But it's definitely not reproducible on recent kernels? [06:04] nope [06:04] Yeah. [06:04] we never experienced it locally [06:04] Chalk up another argument for upgrading buildds. [06:04] and we never got it on arm builds [06:04] I'd rather fix the few packages that break for older releases than the other way around. [06:05] (And lp-buildd is already employing the uname-2.6 hack to minimise the worst damage that 3.0 kernels will bring to old releases) [06:05] Well, it would be employing it if it was running on precise. :P [06:05] But the code is there and tested and rolled out. [06:06] Hrm, I wonder if I should double the header in build logs to show both "real kernel version" and "kernel version reported to sbuild". [06:35] gnome-keyring is published; rebuild galore, I figure === doko_ is now known as doko [06:43] image builds running, pad updated, time for breakfast [06:43] bon appetit [07:18] stgraber: nice work on the bot! [07:19] infinity: python all strings unicode> that's what python 3's for ... [07:20] good morning cjwatson [07:20] pitti: um. g-k hung reproducibly for me in a local sbuild, albeit in a different test, and also for stgraber. have you tried it recently? [07:21] not 50 builds in a row or something such, just during normal package updates [07:21] I mean, aside from the builds that just succeeded. :) [07:22] I did wonder why we were a cycle back on g-k (and don't have the new split gcr), but I guess it's too late for that now [07:22] we did investigate a hang in glib's test suite which also used GIOChannels, and found that it was due to the hardy kernel; I never got the keyring one locally, so so far I could just assume it was a similar problem [07:22] cjwatson: LTS conservativism mostly [07:22] * cjwatson nods [07:22] cjwatson: g-keyring 3.4 got quite a dramatic rewrite in 3.4 [07:23] and while it's mostly working, we did get some regressions; these should be fixed now, but still.. [07:24] cjwatson: so, pad is up to date, respins are running for keyring [07:25] need to run out for 30 mins [07:28] * cjwatson hasn't really started yet, just looked in from phone [07:28] but baby is asleep \o/ [08:40] stgraber: ^- "New: removed syslinux-legacy" should've had the arch names maybe? [08:42] haskell-yesod is the last of that stack [08:42] should allow the rest of those packages to be zapped [08:42] yeah, I was just looking [08:42] i'll do the partial removal bug later [08:44] stgraber: are you relying on http://people.canonical.com/~ubuntu-archive/queue/ in any way? I guess not since it doesn't have precise. I was wondering if we should decommission that [08:44] not as if it's up to date anyway [08:45] (it was always a pre-API hack anyway ...) [09:03] Daviey: http://people.canonical.com/~ubuntu-archive/component-mismatches.txt - wanna reseed a bunch of stuff before this falls out? [09:31] cjwatson: yep! [10:50] Laney: i commented bug #965659 [10:50] Launchpad bug 965659 in shunit2 "FFe: Sync shunit2 2.1.6-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/965659 [10:51] bdrung: thanks, it was a gentle prod that the FFe was a bit bare :-) [10:51] * pitti accepts the GNOME 3.4 -proposed uploads [10:51] pitti, \o/ [10:56] oh, it now shows SRUs, too [10:56] yep, stgraber had a hacking spree [11:00] what's the analog of http://people.canonical.com/~ubuntu-archive/testing/precise_outdate_all.txt for ports? [11:00] s/testing/testing-ports/ [11:01] ta [11:01] can i sync eclipse 3.7.2-1 from Debian? according to upstream 3.7.2 is a maintenance release of the 3.7 branch. [11:01] shouldn't armel and armhf be switched there? [11:02] probably :) [11:02] I thought pitti said something about doing that [11:02] hm, I did switch it for _probs.html [11:02] apparently I missed a spot for outdate [11:07] would someone on the release team please weigh in on whether they think bug 964508 is worth having in precise? [11:07] Launchpad bug 964508 in whoopsie-daisy "whoopsie uploads crash reports, including core dumps, when on a 3G connection" [Medium,Confirmed] https://launchpad.net/bugs/964508 [11:08] ah, all my rebuilds are done, updating pad [11:11] ev: responded in the bug [11:11] pitti: any thoughts on a better way of handling that at_console bit, or is touch /var/run/console/whoopsie the best way forward? [11:11] and cheers! [11:22] ev: oh, I haven't looked at the patch, just at the description [11:22] bbl, lunch === greyback is now known as greyback|bia === greyback|bia is now known as greyback [12:24] ev: eww -- can't we just fix NM's dbus policy to also allow root? [12:59] pitti: it's not running as root [12:59] it's running as the unprivileged whoopsie user [13:00] running as root will work just fine, but keeping root around just so we can use nm over dbus is a bit scary. [13:00] ah, just saw your comments in the bug === bladernr_afk is now known as bladernr_ [13:11] good morning [13:12] cjwatson: the new bot is using the LP API directly [13:13] indeed showing the architecture on removal of a binary package would make sense, I'll fix that one quickly [13:13] OK, I'll nuke the old queue view then [13:19] old queue view is gone [14:09] good morning pitti, cjwatson [14:10] thanks for the updates to the TechnicalOverview last night scott-work! looks good. :) [14:10] cjwatson: ^ happy with the new removal message? [14:14] stgraber: great, thanks [14:14] can it show seeds too, or would that be too much? [14:15] cjwatson, any new fixes beyond the server ones looming on the horizon? [14:15] it'd have to be germinate output not seeds [14:16] yeah, transitively [14:16] and supported [14:16] skaet: I'm not aware of anything just at the moment [14:17] tumbleweed generates that data i think, if it's not in machine-readable form elsewhere [14:17] Laney, did you see the version in the backscroll (ref's to core, edubuntu, etc.)? [14:18] skaet: yes, I see packagesets in there [14:18] Laney, okie. :) [14:19] http://qa.ubuntuwire.org/ubuntu-seeded-packages/seeded.json.gz [14:24] ltsp is broken. Client session doesn't start [14:25] * stgraber is looking into it [14:26] install is running now, should know more in 10-15min [14:26] pitti, release note https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/963470? [14:26] Launchpad bug 963470 in compiz "[regression] Unity 5.8+Compiz 0.9.7.2: Pressing Super+Tab or Super+W works, but unity does not respond to when Super is released." [High,Fix committed] [14:27] or should we try for a cherry pick? [14:28] jibel: FWIW, I'm also doing a quick ltsp-live check to see if it's limited to alternate or also applies to Edubuntu [14:30] skaet, Laney: lp:~stefanor/+junk/ubuntu-seeded-packages [14:30] ty [14:31] reads germinate output for supported seed, and manifests+lists for ISO contents [14:32] how often is it regenerated? [14:32]