[10:26] <cjwatson> skaet: do you think foundations-q-replace-archive-admin-shell-access should be added to topic-quantal-release-management, perhaps?
[10:26] <cjwatson> skaet: possibly also foundations-q-livefs-in-soyuz
[10:39] <cjwatson> tumbleweed: so, your sync-blacklist scripts - can I stick a copyright notice for you and a GPLv3 licence at the top?
[10:39] <cjwatson> tumbleweed: I was thinking of putting them in ubuntu-archive-tools
[11:36]  * ogra_ wonders if someone could update the debootstrap on the arm livefs builders ...
[11:37] <ogra_> P: Running debootstrap (download-only)...
[11:37] <ogra_> E: No such script: /usr/share/debootstrap/scripts/quantal
[11:37] <ogra_> ...
[11:55] <cjwatson> err.  shouldn't they be doing quantal builds in a quantal chroot, which should already be upgraded to a current debootstrap that supports that?
[11:55] <ogra_> well, i would have thought so
[11:55] <ogra_> the errror somehow indicates differently though
[11:56] <ogra_> -r
[11:56] <cjwatson> sure, just saying, not clear a simple upgrade will help as they already auto-upgrade at the start of the build
[11:56] <ogra_> thats -core only, for the other failed builds i havent looked deeper yet
[11:57] <ogra_> nusakan doesnt send me logs for these and i havent looked at people.c.c yet
[11:57] <cjwatson> it's only core/armel, core/armhf works fine
[11:58] <cjwatson> so, uh, wibble
[11:58] <ogra_> heh
[11:58] <cjwatson> maybe there's something that prevents the chroots auto-upgrading for some reason, and so they're effectively stuck on precise
[11:58] <cjwatson> attempting to upgrade the chroots might reveal what that is, I guess
[11:58] <ogra_> well, its not like we urgently need building images right now ... should suffice if infinity takes a look once he is back
[11:59] <cjwatson> but that's my best guess
[11:59] <cjwatson> fixing quantal/armel so that it auto-upgrades cleanly would suffice too, at least temporarily
[12:00] <cjwatson> though http://people.canonical.com/~ubuntu-archive/testing-ports/quantal_probs.html doesn't seem to have anything that obviously matters here
[12:01] <ogra_> well, local dist-upgrades precise->quantal work fine on armel ...
[12:01] <ogra_> at least they did before UDS
[12:02] <ogra_> must be something in quantal armel itself ... i dont think anyone paid much attention to that port anyway yet though
[12:03] <cjwatson> mm, upgrading successfully once should've been sufficient, though bear in mind we weren't doing daily builds before UDS, IIRC
[12:03] <cjwatson> so it matters what they were doing as of the point when I turned on daily builds, not so much what they were doing before
[12:04] <cjwatson> anyway, it's only my best working theory, not actually proven
[12:22] <Daviey> ogra_: you can download the chroot that LP is using from LP, then chroot in and have a poke, if that helps.
[12:27] <cjwatson> Daviey: No, that gets you the package build chroot, not the livefs build chroot.
[12:27] <ogra_> right
[12:27] <cjwatson> Until such time as livefses are built in LP, then they might be the same.
[12:28] <ogra_> all i can do to the livefs builders is get http access to the local webserver instance to read the logs
[12:29] <ogra_> (and indeed trigger builds from nusakan without any direct access)
[12:32] <Daviey> cjwatson: Ah, sorry.. i thought that was what ogra_ was talking about.
[15:43] <skaet> ScottK,  we need to do some cleanup on cdimage,  who should I work with to double check on some of the kubuntu parts of the cleanup?
[15:45] <pitti> darn, we are so close now.. http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html
[15:45] <pitti> I *just* thought I had it down to zero after that publisher run, when samba got broken
[15:45] <pitti> no beer on a Friday evening :(
[15:45] <skaet> :(
[15:46] <cjwatson> skaet: oh, which reminds me, can I enable purging of old images again?  I think we've released everything for precise that we're going to release
[15:46] <skaet> cjwatson,  yes definitely
[15:47]  * skaet thought it had been done already - should have checked.  sorry.
[15:47] <cjwatson> done now
[15:47] <skaet> :)
[15:47] <cjwatson> I'd left it that way pending the Chinese edition being sorted out, but that's done
[15:47]  * skaet nods
[15:47] <cjwatson> what Kubuntu cleanup is required?
[15:48] <skaet> Spads was noting they're taking up 100s of Gigs,  so a scrub/check seemed in order
[15:48] <cjwatson> practically all of that is going to be purge-old-images being left off
[15:49] <skaet> that would indeed explain it.
[15:49] <cjwatson> so the most economic approach might well be just to let the automatic code do its stuff
[15:49] <skaet> yuppers
[16:11] <bjf> can someone copy the Precise kernel package (3.2.0-24.38) from -proposed to -updates? (not a high priority)
[16:12] <cjwatson> incidentally I just fixed a bunch of the daily CD builds (anything that was trying to include dist-upgrader images)
[16:12] <cjwatson> and arranged that purge-old-images will never nuke the target of the 'current' symlink (might have been related ...)
[16:18]  * skaet likes!!  Thanks cjwatson.  :)
[16:40] <tumbleweed> cjwatson: sure, although I just picked up where laney left off. he holds copyright on them too
[16:41] <cjwatson> Laney: ^- ?
[16:41] <cjwatson> 11:39 <cjwatson> tumbleweed: so, your sync-blacklist scripts - can I stick a copyright notice for you and a GPLv3 licence at the top?
[16:41] <cjwatson> 11:39 <cjwatson> tumbleweed: I was thinking of putting them in ubuntu-archive-tools
[17:48] <slangasek> um
[17:48] <slangasek> so the work items handling in launchpad
[17:48] <slangasek> is randomly corrupting my input
[17:50] <slangasek> https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-xorg-lts-updates - I noticed jdstrand's latest change included some seemingly extraneous changes to unrelated work items, so I tried to clean it up... and LP apparently completely replaced *my* intended change with something else
[17:51] <jdstrand> slangasek: weird. all I did was add a comment in the whiteboard, then do s/TODO/DONE/ on something
[17:51] <slangasek> I know
[17:51] <slangasek> the server is clearly doing broken things with the input
[17:51] <jdstrand> that's... suboptimal
[17:52] <jdstrand> I haven't noticed that with the blueprints I have been working on, but will keep an eye out for it
[18:02] <stgraber> skaet: hmm, that Precise 10.04.1 Daily milestone looks weird :)
[18:02] <slangasek> - [mlankhorst] Review the rename script: TODO
[18:02] <slangasek> + [tjaalton] Review the rename script: TODO
[18:02] <slangasek>   [tjaalton] Review the rename script: TODO
[18:02] <slangasek>   [tjaalton] Review the rename script: TODO
[18:02] <stgraber> skaet: first, I think it should be called Precise 12.04.1 Daily :)
[18:02] <slangasek> not cool
[18:03]  * slangasek tries a fourth time to fix up these WIs
[18:03] <stgraber> skaet: and it also had notifications enabled which I turned off to avoid spamming people when we actually get builds pushed daily
[18:05] <stgraber> skaet: actually, is there any reason to use a separate daily milestone for post-release? (wondering if we can't just use the existing Precise Daily for that, then switch to Precise 12.04.1 when we're in freeze like usual)
[18:08] <slangasek> + [mlankhorst] Also review the rename script: TODO
[18:08] <slangasek>   [tjaalton] Review the rename script: TODO
[18:08] <slangasek>   [tjaalton] Review the rename script: TODO
[18:08] <slangasek>   [tjaalton] Review the rename script: TODO
[18:08] <slangasek> that is *also* not what I typed, Launchpad
[18:10] <slangasek> so I think LP can't cope with two work items with the same description but different assignees
[18:18]  * skaet headslams
[18:20] <skaet> stgraber,  yup should have been 12.04.1 *sigh*,  and we could go back to using the precise daily instead.
[18:20]  * skaet goes to fix
[18:20] <stgraber> skaet: ok, let me kill 12.04.1 from the DB then, we'll create it when we're in freeze
[18:21] <stgraber> skaet: gone
[18:21] <skaet> stgraber, or we can just mark it closed for now, and reopen it then?
[18:21] <skaet> hehe
[18:21] <skaet> too late
[18:21] <skaet> no worries.
[18:21] <stgraber> it didn't contain anything so it was still possible to completely remove without causing inconsistencies in the DB
[18:22] <stgraber> I also moved Precise Daily back to testing
[18:22] <stgraber> and will patch my scripts to deal properly with two daily milestones (the auto d-i publishing script just complained by e-mail ;))
[18:22] <skaet> stgraber, sounds good.
[18:23] <skaet> any problem with me just removing the images that aren't part of the LTS?
[18:23] <stgraber> nope, go ahead
[18:23] <skaet> coolio.
[18:24]  * cjwatson sets ~cdimage/.isotracker.conf back to Precise Daily
[18:25] <stgraber> fixed the cronjob, we'll now have d-i images published on all active daily milestones
[18:25] <stgraber> cjwatson: do you already have a way to make it use the right milestone depending on what release it's building?
[18:26] <cjwatson> stgraber: no
[18:26] <cjwatson> though good point
[18:26]  * skaet nods
[18:26] <cjwatson> I'll see about beefing up isotracker_xmlrpc.py to support that
[18:27] <cjwatson> maybe [precise] [quantal] etc. sections
[18:27] <cjwatson> falling back to [general]
[18:30] <stgraber> cjwatson: sounds good for now. In the next release of the ISO tracker, all milestones will have to be linked to a series (required for the new testcase management code) so I'll have the series exported over the API too, should make this easier
[18:30] <cjwatson> I'll bodge for now :)
[18:32] <cjwatson> http://paste.ubuntu.com/994637/
[18:33] <cjwatson> done, I think, let me know if it breaks :)
[18:35] <stgraber> right, and API extended to export the series, so we should have that on production at some point (it's in the testcase management branch, so not expecting this to land real soon)
[18:37] <stgraber> at some point I'll also want to rebase the tools in lp:ubuntu-archive-tools on the "official" python-qatracker at lp:~ubuntu-qa-website-devel/ubuntu-qa-website/python-qatracker/
[18:37]  * cjwatson tests - oops, that broke
[18:39] <cjwatson> there you go, some quantal images now
[18:40] <stgraber> yeah!
[18:41] <stgraber> hmm, someone will have to create all the download links or re-design that feature to be less of a pain to maintain (having to create/update 4 entries per image per series quickly gets annoying)
[18:52] <skaet> :)
[20:25] <Laney> cjwatson: no worries
[20:42] <stgraber> cjwatson: are the precise dailies fully setup? I'm drafting the 12.04.1 spec now and I see that you have a work item for it, wondering if I should mark it done already ;)
[20:46] <slangasek> I didn't see them running yet
[21:24] <cjwatson> stgraber: not yet, will try to sort that out asap
[21:24] <cjwatson> Laney: great, thanks
[21:25] <Laney> so you're planning on moving it over?
[22:12] <cjwatson> Laney: yep - out of time this week now, but more or less next on the archive hit list at last
[22:13] <cjwatson> sorry it's taken quite so long
[22:22] <Laney> never mind :-)
[22:22] <Laney> in other news, update-sources.py in mom is intense


[10:52] <silverlion> o/ everybody
[15:45] <miltos211> hi
[15:45] <miltos211> i need some help with ubuntu
[15:46] <silverlion> what kind of help?
[15:46] <silverlion> and most of all which flavour of it ;)
[15:46] <miltos211> idk i need to know the basics of terminal
[15:46] <miltos211> xD
[15:47] <silverlion> try google ;)
[15:47] <miltos211> yech suggestions?
[15:48] <silverlion> http://lmgtfy.com/?q=Basics+of+ubuntu+terminal
[15:48] <silverlion> how about that?
[15:48] <miltos211> thx man :D
[15:48] <silverlion> brings you tons of youtube vids about the usage and scripting
[15:48] <silverlion> ;)
[15:49] <miltos211> i kinda know who to script in like the most basic of ways :P
[15:49] <miltos211> but am tryin to learn
[15:50] <miltos211> thx for ur help cya


[17:16] <dbungert> doko: I have a question about pytest and the allow-stderr restriction.  I went back to the old pytest just before we started allowing stderr and can't reproduce the stderr failure, do you remember what was happening there?
[17:43] <vorlon> doko: can you tell me why https://launchpad.net/ubuntu/+source/firmware-microbit-micropython/1.0.1-3/+build/23574016 is failing because of a crash in lto1 in gcc-arm-none-eabi?  I don't understand why lto1 is invoked at all given that we know we don't want LTO for armhf
[17:44] <vorlon> dbungert: fwiw if it's not obvious, I'd suggest dropping the allow-stderr delta, uploading, and seeing empirically if it's still needed
[17:46] <dbungert> vorlon: sounds good, that means we can sync now
[17:57] <vorlon> doko: ignore above question, libstdc++-arm-none-eabi is to blame and I'll see about sorting it
[18:19] <ginggs> dbungert: https://autopkgtest.ubuntu.com/packages/p/pytest/hirsute/amd64 you can see the pytest/6.0.2-2 failures, but the logs are gone
[18:20] <ginggs> i'd guess it was some deprecation warnings