| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| maclin | cjwatson, hi | 02:19 |
|---|---|---|
| maclin | we find the bug(Bug #1226441) about ubuntukylin wallpaper, the problem is we change the default wallpaper name in default-settings from "ubuntukylin-default-settings.jpg" to "warty-final-ubuntukylin.jpg" according to name rules. But the ubiquity-dm use "ubuntukylin-default-settings.jpg". | 02:33 |
| infinity | maclin: It's getting close to too late to fix that for the beta, can you live with that being broken and fixing it right after? | 02:38 |
| maclin | infinity, ok, we will fix it and solve it after beta2, thanks:) | 02:40 |
| infinity | plars: Stop finding bugs, we don't want any more. | 03:25 |
| plars | infinity: it's a nasty addiction | 03:25 |
| plars | infinity: you saw the rescue mode thing I take it? | 03:25 |
| infinity | plars: Yeah. Kinda weird. | 03:26 |
| plars | infinity: yeah, I wasn't expecting to see a problem there | 03:27 |
| infinity | plars: Neither was I. Definitely one to look at, definitely too late for beta. | 03:27 |
| infinity | plars: Did the oem-config fail go away with the respin at least? | 03:27 |
| plars | infinity: well, yes, but hopefully at least this serves to raise some awareness that more needs to be done in the last few weeks we have | 03:27 |
| infinity | plars: Lots needs to be done. Including finding a lot more bugs, I imagine. Such is release month. | 03:28 |
| infinity | plars: And, historically, everyone seems to find 98% of the installer bugs in the last two weeks before release. | 03:28 |
| plars | infinity: yes, but oem installs are still not quite right - see https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1231166 | 03:28 |
| infinity | (Which is weird since, in theory, people claim to be installing through the whole cycle) | 03:28 |
| plars | infinity: somehow, I doubt that | 03:28 |
| plars | infinity: we do have automated tests for a lot of this stuff, and the oem one on the previous build was absolutely caught by it | 03:29 |
| infinity | plars: Yeah, not calling out QA on this, more just the pain of upgradeitis as things get closer to the end of the cycle. | 03:29 |
| plars | infinity: but a lot of these seem to rely on odd things being on the disk before hand, not on having a clean slate (as is normally the case in automation for making it consistent) | 03:29 |
| infinity | plars: Lots more testers, lots more fuzz, lots more corner cases. | 03:29 |
| infinity | plars: Your bugs though, I dunno. Just bad timing? :P | 03:30 |
| plars | infinity: more eyes, and more frequency would help for certain. At least it would hopefully distribute the pain a bit | 03:31 |
| plars | rather than loading it all at milestone time | 03:32 |
| bdrung | hi. should i try to get a freeze exception for a new upstream release of manpages? | 08:25 |
| infinity | bdrung: Not right now, you shouldn't, but in 12h, sure. :P | 08:51 |
| diwic | Hi, is pulseaudio 1:1.1-0ubuntu15.4 expected into precise-proposed soon? I uploaded it two months (!) ago. | 08:52 |
| ogra_ | slow DSL ? | 08:52 |
| infinity | Har har. | 08:53 |
| bdrung | infinity: i am working on my master thesis (using the kernel API) and will file the bug on monday after handing in the thesis. | 08:53 |
| diwic | infinity, it would ease our OEM enablement if it was accepted... | 08:53 |
| infinity | diwic: Yeah, the har har was for ogra. | 08:54 |
| ogra_ | :) | 08:54 |
| diwic | if I didn't have to patch the OEM machines manually and they could just use the updated version in the repository | 08:54 |
| diwic | infinity, okay :) | 08:54 |
| diwic | infinity, thanks for accepting it \o/ | 08:59 |
| infinity | diwic: NP. Went crosseyed a bit at the fact that the patches all refer to each other, but oh well. | 09:00 |
| infinity | diwic: Looks sane enough when taken as a whole. | 09:00 |
| infinity | diwic: When you're verifying, do me a favour and test on 3.2, 3.5, 3.8, and 3.11 (the saucy kernel debs should install on precise without any modification) to make sure it always does what you think it should. | 09:01 |
| diwic | infinity, I'll try to do so; however, as usual I'm not the person with the hardware... | 09:01 |
| infinity | diwic: Yeah, I realize you might not have the affected kit, though you should be able to test locally to make sure it doesn't do anything unexpected too. :) | 09:02 |
| diwic | infinity, I took the patches from upstream as unchanged as I could, hence the third one changing the other two | 09:03 |
| diwic | infinity, yeah, I could run a quick check on some hardware that should remain unaffected | 09:04 |
| infinity | diwic: Yeah, nothing wrong with applying a patch stack. I've done much more unreadable things in glibc SRUs. It's just harder to review. :) | 09:04 |
| infinity | diwic: (Which could be why people kept passing it over... We're all guilty of cherry-picking the "easy" queue items first) | 09:05 |
| infinity | diwic: Anyhow, all accepted now, so yay. | 09:05 |
| diwic | infinity, yeah, on to the next person to poke for testing. :-) | 09:07 |
| * Laney eyes ogra_ | 09:09 | |
| Laney | In gst-bad you edited control but not control.in | 09:09 |
| ogra_ | Laney, ugh | 09:13 |
| ogra_ | Laney, sorry, will fix | 09:13 |
| Laney | no, don't | 09:13 |
| Laney | I'm uploading 1.2.0 | 09:13 |
| ogra_ | hmm, did anyone test the hybris stuff against it ? | 09:13 |
| Laney | to a ppa | 09:13 |
| Laney | never fear | 09:14 |
| ogra_ | k | 09:14 |
| === brainwash_ is now known as brainwash | ||
| infinity | What the... | 09:23 |
| infinity | https://bugs.launchpad.net/ubuntukylin/+bug/1230108 | 09:24 |
| infinity | ^-- Has anyone seen this before? | 09:24 |
| ogra_ | heh, lovely | 09:27 |
| infinity | I can only assume that's a pretty specific driver/hardware combination doing that, but. Special. | 09:27 |
| ogra_ | hah, i knew we had something similar before | 09:31 |
| ogra_ | https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/496363 | 09:31 |
| ogra_ | infinity, ^^ | 09:31 |
| infinity | ogra_: This one's Intel, mind you. | 09:32 |
| ogra_ | ah, k | 09:32 |
| infinity | ogra_: My guess, without further info, is that it's a convertible laptop/tablet that thinks it's in tablet mode when it's not, or something along those lines. | 09:33 |
| ogra_ | hmm, yeah, wrong DPMS info or some such | 09:33 |
| knome | infinity, any schedule for releasing? | 09:34 |
| infinity | knome: No firm schedule, but it'll be today. ;) | 09:34 |
| knome | infinity, mhm. also, any idea why the xubuntu images were respun? | 09:35 |
| infinity | knome: The whole world was respun for a new ubiquity and some other bits. Sorry about that. :/ | 09:35 |
| infinity | knome: A quick smoketest of each should be good enough to make sure I didn't blow up your world, I wouldn't bother going too in-depth with re-testing. | 09:35 |
| knome | infinity, that's what i thought as well. thanks, i'll boot up a test and check if everything seems in place :) | 09:36 |
| infinity | knome: Do you have a xubuntu-specific release announce link for me to link from the collective announce? | 09:37 |
| infinity | (we really need a better way to collect these, this really doesn't scale with all the flavours we have...) | 09:38 |
| knome | infinity, can guarantee it'll pop up at http://xubuntu.org/news/saucy-salamander-b2/ | 09:38 |
| knome | infinity, heh, yeah... | 09:38 |
| knome | infinity, have you set the notes up in the wiki? :) | 09:38 |
| infinity | knome: Working copy looks to be at https://wiki.ubuntu.com/SaucySalamander/ReleaseNotes | 09:41 |
| infinity | I'll fork that to something more Beta-appropriate when the time comes, so we can re-use it for final release. | 09:41 |
| knome | aha | 09:41 |
| knome | will you look at the flavor-specific wikipages too? | 09:42 |
| infinity | Irritatingly, I only just noticed that was already there, as I'd been working on the stale TechnicalOverview last night. :P | 09:42 |
| knome | awwh :< | 09:42 |
| infinity | knome: We can link to the flavour-specific pages from there. | 09:42 |
| knome | sure, but will you set those up or should i do that for us? | 09:42 |
| infinity | knome: Feel free. :) | 09:43 |
| knome | oki | 09:44 |
| infinity | I should find some caffeine and re-read these notes to see how they differ from the bits I changed in the stale ones. | 09:45 |
| infinity | And people wonder why I hate wikis. :P | 09:45 |
| knome | good luck | 09:45 |
| knome | infinity, umm, there is at least one problem with the new ubiquity in vbox... the wallpaper is not shown, it's just black background; until you wiggle the window around which then "erases" the black stuff and makes the wallpaper appear | 09:56 |
| knome | infinity, ok, i couldn't reprouduce. weird. | 09:59 |
| infinity | I tend to blame "it broke in virtualbox" bugs on virtualbox until proven otherwise... | 10:00 |
| infinity | cjwatson: Any idea who's to blame for cdimage/www.old? | 10:01 |
| cjwatson | infinity: Nope | 10:06 |
| cjwatson | infinity: I assume it's a hardlink farm? | 10:06 |
| infinity | cjwatson: Yep. | 10:07 |
| infinity | cjwatson: I assume it's someone preserving a previous www.prev instead of deleting it. | 10:07 |
| * infinity shrugs. | 10:07 | |
| Laney | Me, probably. Go ahead and kill it. | 10:09 |
| infinity | Laney: Alrighty. | 10:09 |
| knome | infinity, set up https://wiki.ubuntu.com/SaucySalamander/Beta2/Xubuntu | 10:09 |
| infinity | Hah. So, in random wiki searching, I found Beta11 (yes, eleven) release notes for Ubuntu GNOME. Someone's planning ahead. :) | 10:10 |
| apw | infinity, not me indeed, that is an odd one, ask RAOF perhaps | 10:12 |
| apw | infinity, not me indeed, that is an odd one, ask RAOF perhaps | 10:13 |
| apw | bah | 10:13 |
| infinity | apw: I was going to ask RAOF yes, but he's not around. | 10:13 |
| infinity | apw: I was going to ask RAOF yes, but he's not around. | 10:13 |
| apw | ;) | 10:14 |
| infinity | knome: Feel like being helpful to other flavours? :) | 10:14 |
| psivaa | infinity: one of our post upgrade tests check if all the python modules can be imported in the default version.. and PAMmodule fails to import after saucy upgrade | 10:24 |
| psivaa | is that serious | 10:24 |
| psivaa | ? | 10:24 |
| infinity | psivaa: That's a known bug, I believe, that is definitely an issue, but not a showstopper for Beta. | 10:25 |
| infinity | psivaa: xnox and slangasek were talking about it last night. | 10:25 |
| psivaa | infinity: ok, missed the back log.. quite a bit to catch up during the nights i guess :) | 10:25 |
| xnox | psivaa: it should be "import PAM" not "import PAMmodule" | 10:26 |
| xnox | psivaa: and I believe it's fixed in latest python-pam upload. | 10:26 |
| psivaa | xnox: great thanks | 10:26 |
| infinity | Oh, indeed. Fixed 19h ago. But then that should have worked in his tests, I'd assume. | 10:26 |
| psivaa | infinity: xnox yea, i had a failure about an hour ago | 10:27 |
| infinity | Did it get renamed? | 10:27 |
| xnox | psivaa: not if in raring it tests "import PAMmodule" and tries the same in saucy, which is "import PAM". basically in python2 both PAM & PAMmodule used to work, with "PAM" being the correct one. In python3 neither worked, until new dh-python was used that auto-renamed the module.so to "PAM" | 10:28 |
| xnox | infinity: it's weird, the module declared as "PAM" yet was getting installed as PAMmodule, which worked in python2 but never in python3 =/ | 10:28 |
| xnox | now it's declared and installed as PAM. | 10:28 |
| infinity | xnox: Hrm. But this could mean there's code out there (and maybe in the archive) that expects PAMmodule | 10:29 |
| xnox | infinity: correct, let me do a quick search on codesearch.debian.net | 10:29 |
| infinity | xnox: Is there any way to have it be correctly "PAM" in python3 (since it never worked there anyway, as you say), but still be both for python2, to not gratuitously break people's stuff? | 10:29 |
| infinity | Also, I would pay good beer for an Ubuntu version of codesearch. | 10:30 |
| xnox | infinity: Laney has one running in cannonistack, not sure if he made it public yet. | 10:31 |
| Laney | seems to be down | 10:31 |
| cjwatson | it's canonistack, down is the default state :P | 10:32 |
| xnox | infinity: i did codesearch & did a src grep on all reverse dependencies, they all do "import PAM" | 10:32 |
| infinity | xnox: Mmkay. I wonder how psivaa's scripts autogenerated (at least, I ASSUME it was automagic) the other import. | 10:33 |
| infinity | Based on filename or something, I guess? | 10:33 |
| infinity | psivaa: Can you just quirk around that in your test setup to s/PAMmodule/PAM/ and carry on with life? | 10:33 |
| psivaa | infinity: that's autogenerated but i'll try.. this is happening on a fresh install as well fwiw | 10:34 |
| xnox | infinity: going by file names on disk is the only way one can find out about PAMmodule quirk name in the first place. | 10:34 |
| infinity | xnox: Of course, random humans still could have done the wrong thing locally, but I suppose people expect that sort of minor breakage of code on dist upgrades. | 10:34 |
| * xnox ponders if one can ask python about all modules | 10:35 | |
| infinity | psivaa: Sure, upgrade or fresh install, the point is that PAMmodule will not work (and never should have, but accidentally did). | 10:35 |
| xnox | psivaa: dist-upgrade can remove packages, so surely you need to generate the list of packages to try import afresh after dist-upgrade, instead of assuming it will all work?! | 10:35 |
| cjwatson | Oh, I no-change-uploaded fso-gsmd entirely unnecessarily. Oops. | 10:36 |
| infinity | xnox: python -c "help('modules')" | 10:36 |
| infinity | xnox: Or "pydoc modules" | 10:37 |
| * cjwatson sorts out the arch-specific NBS instead | 10:39 | |
| xnox | infinity: i get a hang and a bucket and a half of Emacs Lisp code out =/ http://paste.ubuntu.com/6158198/ | 10:40 |
| infinity | xnox: Your python is possessed. | 10:41 |
| Laney | there we go, it is back up: http://162.213.35.4/search?weighted=1&q=import+PAM | 10:42 |
| psivaa | xnox: infinity: this is what i get in a fresh saucy install http://paste.ubuntu.com/6158224/ (line 16-19) | 10:52 |
| xnox | psivaa: hm, did i fix python3-pam by breaking python-pam ?! | 10:53 |
| infinity | xnox: Probably. :P | 10:53 |
| xnox | psivaa: have you opened a bug about it already? if not, please do. | 10:53 |
| * infinity tests quickly here. | 10:53 | |
| infinity | (saucy-amd64)root@cthulhu:/home/adconrad# dpkg -l python\*pam | awk '/^i/ {print $2"_"$3}' | 10:55 |
| infinity | python-pam_0.4.2-13ubuntu5 | 10:55 |
| infinity | python3-pam_0.4.2-13ubuntu5 | 10:55 |
| infinity | (saucy-amd64)root@cthulhu:/home/adconrad# python -c 'import PAM' | 10:55 |
| infinity | Traceback (most recent call last): | 10:55 |
| infinity | File "<string>", line 1, in <module> | 10:55 |
| infinity | ImportError: No module named PAM | 10:55 |
| infinity | (saucy-amd64)root@cthulhu:/home/adconrad# python3 -c 'import PAM' | 10:55 |
| xnox | infinity: use pastebinit ;-) | 10:55 |
| infinity | (saucy-amd64)root@cthulhu:/home/adconrad# | 10:55 |
| infinity | xnox: ^-- Definitely 2 broken, 3 fine. | 10:55 |
| infinity | xnox: It was only barely over 5 lines, you'll live. | 10:55 |
| infinity | Well, okay, 4 over. | 10:56 |
| xnox | infinity: psivaa: fixed locally will upload. | 10:56 |
| psivaa | xnox: thanks | 10:56 |
| psivaa | xnox: i'll skip the bug then? | 10:56 |
| xnox | psivaa: yes. | 10:56 |
| psivaa | xnox: ack | 10:57 |
| debfx | is an archive admin willing to review steam in NEW (bug #1229045)? It's already in Debian, the only diff would be adding an epoch to the version. | 10:58 |
| xnox | psivaa: infinity: uploaded 0.4.2-13ubuntu6 | 11:00 |
| infinity | xnox: Danke. | 11:01 |
| xnox | infinity: Bitte Schon ;-) | 11:01 |
| infinity | debfx: I can review it against the Debian source, sure. | 11:02 |
| infinity | debfx: Would be nicer if you reupload to Debian with the epoch and sync, though. | 11:02 |
| smartboyhw | So, we still haven't got a page like https://wiki.ubuntu.com/SaucySalamander/Beta1 ? | 11:06 |
| infinity | smartboyhw: We could do, if you like. I was just going to link all the flavour notes from the main release notes. | 11:07 |
| infinity | smartboyhw: But I can copy that page if people want to dump stuff in there. Whatever. :P | 11:07 |
| debfx | infinity: yep, I'll poke the maintainer | 11:08 |
| smartboyhw | infinity, Ubuntu Studio's release notes are at /SaucySalamander/Beta2/UbuntuStudio | 11:08 |
| smartboyhw | (I just copied it from Beta1) | 11:08 |
| infinity | smartboyhw: Lovely. That'll do, then. | 11:08 |
| infinity | smartboyhw: If you're feeling helpful and wikiful, want to copy the other flavours' Beta1 pages to Beta2 as well, and if they don't get around to editing them, they'll just have stale info? :) | 11:13 |
| infinity | smartboyhw: Looks like Edubuntu, Kubuntu, Lubuntu, UbuntuGNOME still need to do theirs. | 11:13 |
| smartboyhw | infinity, OK, since I've got to zsync the i386 image and got nothing to do:P | 11:13 |
| smartboyhw | Riddell, time to update the Kubuntu release notes though;) | 11:14 |
| infinity | smartboyhw: Thanks. You're a champion. (Can you tell I hate wikis?) | 11:14 |
| smartboyhw | infinity, yes I can tell:) | 11:14 |
| smartboyhw | infinity, can you update the CommonInfrastructure page though? | 11:15 |
| infinity | smartboyhw: There is no CI. I moved that stuff to the Release Notes where it belongs. | 11:16 |
| smartboyhw | infinity, ouch | 11:17 |
| infinity | smartboyhw: We made that decision last cycle. Someone resurrected it mistakenly this cycle. :P | 11:17 |
| smartboyhw | That needs a full update everywhere... | 11:17 |
| smartboyhw | infinity, how should I point to it then? | 11:17 |
| smartboyhw | Ah, got it | 11:18 |
| infinity | smartboyhw: Oh, were people using wiki includes to pull it in? Ugly. | 11:18 |
| smartboyhw | infinity, cry, now I don't know how to link:( | 11:21 |
| infinity | It was just being used for the Known Problems section, right? | 11:22 |
| smartboyhw | infinity, yes | 11:23 |
| infinity | Meh, I can break that back out for now. I don't want to break everyone's brains when I'm trying to release. | 11:23 |
| infinity | smartboyhw: Better? | 11:27 |
| smartboyhw | infinity, yes, very:) | 11:28 |
| smartboyhw | infinity, I think I done all of them | 11:33 |
| infinity | Oh, and someone copied the Beta1 page to Beta2 too... | 11:33 |
| infinity | That was you as well. | 11:33 |
| infinity | It's all pointing to the wrong locations, of course. | 11:34 |
| infinity | I can fix that up, unless you're already in there. | 11:34 |
| smartboyhw | infinity, already done:P | 11:35 |
| smartboyhw | Do make sure you update the Ubuntu and Ubuntu Touch bits. | 11:35 |
| smartboyhw | Cloud, Server also | 11:35 |
| * infinity nods. | 11:35 | |
| infinity | Thanks a bunch. | 11:35 |
| smartboyhw | infinity, :) | 11:37 |
| * infinity raises his brow at #ubuntu-testing being invite-only. | 12:03 | |
| smartboyhw | infinity, #ubuntu-quality | 12:04 |
| smartboyhw | The -testing channel is abandoned:) | 12:04 |
| infinity | Yeah, I'm in -quality apparently, I just forgot about the rename. :P | 12:05 |
| smartboyhw | infinity, LOL | 12:05 |
| smartboyhw | infinity, asked phillw | 12:06 |
| infinity | I thought he stepped down. | 12:06 |
| infinity | Or does that not take effect until after release or something? | 12:06 |
| smartboyhw | infinity, well, apparently gilir isn't here-.- | 12:07 |
| infinity | Maybe I'll grab a quick nap for a few hours while I wait for more tests to roll in. | 12:09 |
| pkern | An update to liblockfile is stuck in precise-proposed despite the bug being tagged verification-done-precise | 12:21 |
| pkern | Bug is https://bugs.launchpad.net/ubuntu/+source/liblockfile/+bug/941968 | 12:21 |
| pkern | Could somebody release it properly, please? | 12:21 |
| pkern | Hm, ok, the last update is not that great. | 12:22 |
| pkern | Nevermind then. | 12:22 |
| pkern | It does solve my immediate problem, though. |: | 12:27 |
| cjwatson | pkern: That upload closes two bugs, only one of which is verified. | 12:33 |
| cjwatson | bug 1011477 | 12:33 |
| cjwatson | And indeed bug 941968 is only really a qualified success | 12:34 |
| cjwatson | adam_g: ^- could you please look at those? | 12:34 |
| doko_ | cjwatson, looking at python-werkzeug. do we really want to add two other memcaching servers into main, just for running the tests? | 13:21 |
| cjwatson | I don't know, honestly I was just drive-bying to try to clean up the breakage Daviey introduced | 13:22 |
| cjwatson | So instead of flask alone it's now flask + python-werkzeug that are stuck | 13:23 |
| cjwatson | It does seem a bit excessive | 13:23 |
| doko_ | ok, the tests succeed without these, will drop these b-d's | 13:24 |
| === doko_ is now known as doko | ||
| xnox | infinity: so my broken python-pam broke openstack-ci, can the 0.4.2-13ubuntu6 upload be unblocked into saucy please? | 15:18 |
| didrocks | infinity: cjwatson: we start to have chroot issues on amd64, is that known? | 15:47 |
| didrocks | https://launchpadlibrarian.net/151543330/buildlog_ubuntu-saucy-amd64.content-hub_0.0%2B13.10.20130926.1-0ubuntu1_CHROOTWAIT.txt.gz | 15:47 |
| didrocks | before we had https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5051948/+files/buildlog_ubuntu-saucy-amd64.content-hub_0.0%2B13.10.20130926.1-0ubuntu1_CHROOTWAIT.txt.gz | 15:47 |
| * didrocks retries again then | 15:53 | |
| didrocks | (same) | 15:54 |
| roaksoax | howdy! Anyone know if there are any issues with the archive builders? | 15:59 |
| Riddell | kubuntu is good to go :) | 15:59 |
| didrocks | roaksoax: confirmed as well | 15:59 |
| lool | roaksoax: reported minutes ago by didrocks | 15:59 |
| roaksoax | :) | 15:59 |
| roaksoax | awesome then! | 15:59 |
| roaksoax | thank you guys! | 15:59 |
| === tkamppeter_ is now known as tkamppeter | ||
| stgraber | infinity, slangasek: so we've got a bunch of pretty annoying bugs in Edubuntu that I believe I all fixed in the archive now, we'll still release the beta as it's (installation works, all bugs are related to the live session) and tomorrow's image will hopefully be perfect :) | 16:16 |
| stgraber | just finishing a test install here and I'll mark both edubuntu images as ready | 16:16 |
| cjwatson | didrocks: looking | 16:30 |
| cjwatson | didrocks: FWIW, please give the +build link on launchpad.net rather than the log link on launchpadlibrarian.net when reporting this kind of thing | 16:30 |
| cjwatson | it's strictly more useful | 16:30 |
| didrocks | cjwatson: ok, sorry about it, it's fixed as per webops now | 16:31 |
| lool | cjwatson: I guess it was https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5051948 | 16:31 |
| lool | unless that got a new build id now | 16:32 |
| cjwatson | build IDs don't change on retry | 16:34 |
| infinity | stgraber: Kay, shiny. | 16:47 |
| infinity | xnox: The world will unblock soon enough. | 16:47 |
| xnox | infinity: cool, thought so. | 16:47 |
| infinity | cjwatson: You have the 403 sorted? | 16:48 |
| cjwatson | infinity: Yeah, ChrisS sorted it on #webops before I noticed, and I've retried all affected builds. | 16:49 |
| cjwatson | Via the crufty script I wrote on Tuesday morning to trawl through builder histories. I should expose that properly on the webservice ... | 16:50 |
| infinity | Heh. I wonder how those firewall rules suddenly regressed. | 16:51 |
| ogra_ | NSA made a typo ? | 16:51 |
| cjwatson | infinity: Freaks me out, but I'm going to ignore it unless it happens again, I think. | 16:52 |
| stgraber | cjwatson: I believe what happened is that xnox asked IS to block direct access to snakefruit, which they did, that in turn broke image builds and package builds as both access stuff from archive-team.internal. Adding the local buildd subnet to the reverse proxy config solved that. | 16:55 |
| xnox | sorry about that =/ | 16:55 |
| xnox | bad timing. | 16:55 |
| infinity | Erm, it shouldn't be using the reverse proxy at all. | 16:55 |
| Laney | It isn't | 16:56 |
| Laney | It was the archive-team.internal config on snakefruit | 16:56 |
| stgraber | infinity: bah, the end of my explenation was wrong, IS had to add a Allow from to snakefruit's apache config | 16:56 |
| infinity | Ahh, okay, they 403d the world in Apache, not a firewall thing. That makes more sense. | 16:56 |
| stgraber | infinity: the change they did earlier was block any access to snakefruit's http server that doesn't come from lillypilly (through the rproxy) | 16:56 |
| infinity | Was there actually a reason to do that? Given that archive-team.internal's content is the same as what one can see via the rproxy anyway? | 16:57 |
| xnox | hiding implementation detail, and have people.canonical.com/~ubuntu-archive as the canonical location as it was before. | 16:58 |
| stgraber | not really, just xnox mentioned that snakefruit.canonical.com was accessible from the outside and cjwatson saying (may correct me) that this isn't the intended way for people to access it and that it may be worth asking IS to block direct access | 16:58 |
| cjwatson | stgraber: Oh, sigh, OK | 16:58 |
| cjwatson | Right, I certainly didn't mean to block archive-team.internal from inside the DC, that *totally* defeats the purpose | 16:59 |
| cjwatson | Just snakefruit.canonical.com from outside | 16:59 |
| infinity | Sure, it shouldn't be serving on the snakefruit hostname, only the other, which is obviously defeated by DNS when outside the DC. | 17:00 |
| stgraber | cjwatson: right, IS apparently thought of that and allowed Canonical's /21 to connect, they just didn't think of the buildd subnet :) | 17:00 |
| infinity | archive-team.internal used to have its very own IP for this reason. | 17:01 |
| infinity | I guess that got lost in the move. | 17:01 |
| cjwatson | infinity: Right, it did; I only noticed part-way through, but decided I wasn't that bothered since it was much more important when we were sharing with people | 17:03 |
| infinity | Yeah. | 17:04 |
| infinity | I'm not fussed, really. This works. Just differently. | 17:04 |
| infinity | And since there were already firewall rules for the IP case, it would have been a cleaner cutover to just steal the IP. But oh well. | 17:05 |
| cjwatson | snakefruit's on a different network, so they couldn't just pull the old IP across. | 17:05 |
| cjwatson | Apparently. | 17:05 |
| infinity | Ahh. | 17:05 |
| cjwatson | I did suggest that :-) | 17:05 |
| infinity | darkxst: Is anyone going to mark the UbuntuGNOME images ready? | 17:06 |
| infinity | gilir: Around? | 17:07 |
| infinity | ogra_: Do you (or anyone, for that matter) still test lubuntu/ac100? | 17:08 |
| * xnox doesn't | 17:08 | |
| * infinity doesn't still OWN an ac100, which makes it tough. | 17:08 | |
| ogra_ | infinity, i promised a test for the final image (and potential fixes) | 17:08 |
| ogra_ | i wont be able to invest more time thought ... | 17:09 |
| xnox | infinity: are we still building it? i thought we gave up on it. and on plumbers it was said that our linux-ac100 kernel is suboptimal and hallyn was looking into updating it's config in the archive. | 17:09 |
| ogra_ | i guess i should do that next week some time | 17:09 |
| infinity | xnox: It's still being built, yeah. | 17:09 |
| xnox | infinity: maybe we can trick hallyn into testing it =) | 17:09 |
| ogra_ | xnox, its a universe kernel maintainerd by a community guy | 17:09 |
| infinity | Though, I won't release it with beta-2 if literally no one has tested it. | 17:10 |
| infinity | (Which also implies no one uses it) | 17:10 |
| ogra_ | infinity, see #ac100 ... there are plenty of users | 17:10 |
| ogra_ | but they usually are actual users | 17:10 |
| infinity | Looks like it didn't release with beta-1 either. *shrug* | 17:10 |
| ogra_ | or arch hackers | 17:10 |
| xnox | ogra_: oh, is there git tree on kernel.ubuntu.com or not even that? | 17:10 |
| ogra_ | infinity, right, as i said, final image or bust | 17:10 |
| xnox | ogra_: is there one on github or some such? | 17:10 |
| infinity | ogra_: I meant users of this specific image, not of Linux on the ac100. | 17:10 |
| ogra_ | xnox, ask marvin24 in #ac100, i think janimo pulled his stuff from github regulary in the past | 17:11 |
| ogra_ | infinity, yes | 17:11 |
| infinity | gilir: Based on test results, I'm going to go ahead and mark everything but your ac100 image as ready. | 17:11 |
| ogra_ | infinity, me too | 17:11 |
| ogra_ | infinity, the ones testing it see issues | 17:11 |
| ogra_ | infinity, the ones who would be able to fix them prefer to hack arch | 17:11 |
| === infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: open | Saucy Salamander Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis | ||
| === infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: open, FF | Saucy Salamander Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis | ||
| knome | beta 1? | 17:23 |
| knome | you mean final beta/beta 2 for flavors which participated in beta 1 | 17:23 |
| infinity | knome: I just changed the archive state. | 17:23 |
| infinity | knome: topicdiff is your friend. :) | 17:23 |
| knome | oh, okay. | 17:23 |
| knome | is not ;) | 17:23 |
| infinity | 11:22 -!- Irssi: Topic: -: Archive: beta freeze | 17:24 |
| infinity | 11:22 -!- Irssi: Topic: +: Archive: open | 17:24 |
| infinity | ^-- It's my friend! :) | 17:24 |
| infinity | darkxst: Based on test results, I'm going to mark UbuntuGNOME's images ready too, and start turning cranks. | 17:24 |
| infinity | Aww crap, and need to build source. Why does that always seem to not be on the checklist? | 17:26 |
| infinity | ... and also not commented out in crontab. | 17:27 |
| infinity | cjwatson: What's the current correct invocation to build source ISOs? I don't think I've done it since the python rewrite. | 17:27 |
| * infinity is guessing something like "for-project ubuntu cron.source" would do it. Or maybe just cron.source on its own. | 17:29 | |
| cjwatson | just cron.source | 17:29 |
| cjwatson | infinity: just for the record, the agreement last Thursday was not to lift the migration block after beta release, but to selectively unblock things | 17:29 |
| infinity | Mmkay. | 17:30 |
| infinity | cjwatson: Err, really? | 17:30 |
| cjwatson | just because that would be bad if we found out we disagreed later :) | 17:30 |
| cjwatson | 13:10 <ScottK> cjwatson: With no unblock of migration after the beta is out, I would hope. | 17:30 |
| cjwatson | 13:10 <cjwatson> ScottK: I think that's what we did last cycle, isn't it? | 17:30 |
| cjwatson | 13:10 <ScottK> Yes. | 17:30 |
| infinity | cjwatson: I missed that memo. | 17:30 |
| cjwatson | 13:11 <ScottK> cjwatson: It's one of those things we end up doing every cycle, but it seems like it's never part of the "standard" way things are going so we end up relitigating it twice a year. | 17:30 |
| cjwatson | 13:12 <cjwatson> ScottK: it's in the process now; hopefully that will stick a bit better | 17:30 |
| infinity | What we did last cycle was a freeze after beta... | 17:30 |
| cjwatson | that sounds like the same thing as ScottK said. what do you mean, if it's different? | 17:31 |
| infinity | Selective unblocks are actually much more irksome from the AA/release standpoint, TBH. | 17:31 |
| cjwatson | you mean as in saucy.status = FROZEN? | 17:31 |
| infinity | cjwatson: I mean what we did last cycle was an archive freeze. | 17:31 |
| infinity | Which comes with its own problem of copies being opaque and the autolander being a pain because of it. | 17:32 |
| infinity | But I don't see the point in selective unblocks. | 17:32 |
| cjwatson | maybe we should take the opportunity to make unblocks less effort (diff-selection tool etc.) | 17:32 |
| infinity | Anything uploaded should be destined for the release pocket right now. This isn't Debian, -proposed isn't unstable. | 17:33 |
| cjwatson | but I'm not hugely bothered as long as we don't open the floodgates again | 17:33 |
| infinity | Stopping stupid uploads before they land in the archive is good. | 17:33 |
| infinity | Stopping them after they're in the archive is less useful late in the cycle, IMO. | 17:33 |
| cjwatson | you seem to have unblocked everything now though | 17:34 |
| cjwatson | did I speak up too late? | 17:34 |
| infinity | Anyhow, I could set it to frozen or restore the block or do nothing (the third option was what I got from slangasek when we discussed this, and a hard freeze for final). | 17:34 |
| infinity | cjwatson: I unblocked when the topic changed. So, yeah, might have been too late. | 17:34 |
| infinity | cjwatson: But setting the archive frozen wouldn't change that, since proposed was already proposed... | 17:34 |
| cjwatson | mkay | 17:35 |
| infinity | I guess I just don't get the argument that we want things in proposed and then no, actually, we don't. | 17:35 |
| lool | you could perhaps stop the publisher run still? | 17:35 |
| cjwatson | well, fine, I don't think it's actually cause for panic | 17:35 |
| cjwatson | as long as we do actually progressively lock down from here on in | 17:35 |
| infinity | Well, what would people like to see happening? I actually appreciate the archive freeze from beta->final in past cycles. I'm sure others would disagree. | 17:36 |
| cjwatson | I do as well | 17:36 |
| infinity | But I think the britney block is too late in the assembly line to actually stop damage, since a bad upload to proposed can still require a painful revert. | 17:37 |
| cjwatson | although I think migration freezes are very useful in that they let things build and be tested before we make a decision on them | 17:37 |
| infinity | So, I'd prefer it be at the queue stage. | 17:37 |
| cjwatson | I'm happy to go for the queue stage, and if some things need to be migration-blocked too (e.g. by touch) then that's fine | 17:37 |
| infinity | Most of the decisions being made here should be of the higher level "no, don't push a transition in 2 weeks before release", not a fine-grained "this introduced a bug I don't like, fix it before I let it slip in", surely? | 17:38 |
| infinity | Except for whatever touch wants to do, fine. :P | 17:38 |
| infinity | If touch wants to block all their stuff wholesale, that could be a hackish solution to the autlander transparency problem. | 17:39 |
| infinity | As I can accept those opaque uploads with a bit more confidence. | 17:39 |
| cjwatson | well, that's what I've been agitating for ... | 17:39 |
| infinity | Alright, let me freeze the archive for now, and we can carry on this discussion after I've injected drugged beverages. | 17:40 |
| Laney | Didn't we make queuediff work for those? | 17:40 |
| === infinity changed the topic of #ubuntu-release to: Released: 13.10 Beta 1, 13.04, and 12.04.3 | Archive: frozen | Saucy Salamander Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | we accept payment in cash, check or beer | melior malum quod cognoscis | ||
| stgraber | FWIW, I'm in favor of a standard archive freeze instead of a huge britney block | 17:40 |
| infinity | One of my least favourite "features" of copies is how the binaries completely bypass NEW. | 17:42 |
| infinity | Anyhow. All frozen now. Need to find something to drink. | 17:43 |
| infinity | stgraber: You built source ISOs recently. How many months does it take? | 17:43 |
| stgraber | infinity: just a couple ;) IIRC it took around 45min last time | 17:44 |
| infinity | Kay. I'll find a large beverage. :P | 17:44 |
| slangasek | so are we releasing touch images with the beta? they don't seem to be marked on http://iso.qa.ubuntu.com/qatracker/milestones/303/builds | 17:45 |
| slangasek | hmm, and why is this milestone called "Beta 2"? It's supposed to be called "Final Beta"... I'd change it but I fear breaking the publishing scripts | 17:45 |
| ogra_ | slangasek, nope | 17:46 |
| stgraber | that one is mine, would be nice if someone could review, it's breaking LTSP ^ | 17:48 |
| slangasek | ogra_: "nope"? | 17:49 |
| slangasek | ogra_: --verbose? | 17:49 |
| infinity | slangasek: I think we did it as beta-2 in 13.04 too, for fear of breaking many fragile parts. But I could be wrong. | 17:50 |
| ogra_ | slangasek, no beta for touch ... it is far from feature complete | 17:50 |
| slangasek | ogra_: ok; who made that call? | 17:50 |
| ogra_ | slangasek, i belive asac thinks the new hyper controlled way of landing code keeps sus safe here | 17:50 |
| ogra_ | so that we can land stuff til near the end | 17:51 |
| ogra_ | slangasek, i dont think anyone even considered doing a beta | 17:51 |
| ogra_ | so nobody made a call to not do one | 17:51 |
| slangasek | ogra_: that's not true, I certainly discussed it with folks | 17:52 |
| ogra_ | well, didnt come through to my level from anywhere higher | 17:52 |
| slangasek | infinity: yeah, I think the filenames were 'beta2' everywhere... just making sure it doesn't leak into public-facing announcements anywhere that way | 17:53 |
| slangasek | ogra_: it's standing policy that to be included in a release, an Ubuntu flavor must participate in the final beta; I'll talk to asac | 17:53 |
| ogra_ | yeah | 17:53 |
| stgraber | slangasek: how would a touch beta work anyway? Would that be a blessed "old flipped" image being published as beta? | 17:54 |
| ogra_ | since we usually dont regress in the images i think any of the recent builds should be good if you want oen for beta | 17:54 |
| stgraber | ^ thanks | 17:54 |
| slangasek | stgraber: why would it be "old flipped"? | 17:54 |
| ogra_ | stgraber, it would go in the saucy-beta channel :) | 17:54 |
| stgraber | slangasek: because we don't have milestones on system-image? | 17:55 |
| ogra_ | stgraber, have fun implementing that ;) | 17:55 |
| stgraber | ogra_: oh, it's easy to create a channel and copy a single image to it, it'd just be pretty useless as people usually want to get updates ;) | 17:55 |
| slangasek | stgraber: doesn't the initial install come from cdimage? | 17:55 |
| ogra_ | slangasek, nope | 17:56 |
| slangasek | ok | 17:56 |
| ogra_ | cdimage is only for ports nowadays | 17:56 |
| slangasek | well, I don't see why that should be the case | 17:56 |
| stgraber | slangasek: system-image monitors daily-proposed for any new image, anything that shows up there for the right series gets imported into the matching -proposed channel | 17:56 |
| stgraber | slangasek: then once that's tested, the image gets copied between channels | 17:56 |
| slangasek | stgraber: sure, but what does that have to do with where phablet-tools pulls the initial image from? | 17:56 |
| stgraber | slangasek: phablet-tools pulls the latest full image from system-image (defaults to the stable channel) | 17:57 |
| stgraber | slangasek: phablet-tools in system image mode never accesses cdimage.u.c | 17:57 |
| slangasek | ok; I don't see why that should be the case | 17:57 |
| ogra_ | slangasek, theoretically we would hide the cdimage images as an interim product | 17:57 |
| slangasek | I would expect the base images to still be distributed from cdimage | 17:57 |
| stgraber | slangasek: why? | 17:58 |
| ogra_ | the fact that ports need to use them makes us keep them public though | 17:58 |
| slangasek | because that's where we distribute images from | 17:58 |
| ogra_ | but thats not the image setup we support | 17:58 |
| slangasek | I expected system-image.u.c to be used for the updates only | 17:58 |
| ogra_ | all app code and image tests are only against system-image images | 17:58 |
| infinity | Sort of makes sense for it to all be in one place with the same channel thing, IMO. | 17:59 |
| ogra_ | we even ask developers to use it in writable mode | 17:59 |
| stgraber | slangasek: well, the problem is that system-image uses repacked versions of what we have on cdimage, so if we wanted that, we'd need to either push the repacked files to cdimage only for the initial flash or we'd need to duplicate the repacking code in the client | 17:59 |
| ogra_ | to not be hit by bugs the underlying hacked together filesystem setup could cause | 17:59 |
| stgraber | slangasek: (we can't simply switch cdimage to publish .tar.xz directly as the ports still need the old .tar.gz, .zip and .img) | 17:59 |
| slangasek | stgraber: but system-image is syncing from nusakan anyway, so I don't see why we aren't publishing the .tar.xz from cdimage | 18:00 |
| ogra_ | well, they actually only need the armhf.zip file | 18:00 |
| slangasek | alongside the .tar.gz/.zip/.img | 18:00 |
| ogra_ | slangasek, that would need a bunch of code changes i suppose | 18:00 |
| infinity | slangasek: Speaking of leaking B2 in announces: https://lists.ubuntu.com/archives/ubuntu-announce/2013-April/000170.html | 18:00 |
| ogra_ | in the updater app etc | 18:00 |
| * infinity will not do that in his. :P | 18:01 | |
| slangasek | infinity: thanks ;) | 18:01 |
| gilir | infinity, thanks, I was going to do the same anyway :-) | 18:01 |
| slangasek | ogra_: of course it wouldn't | 18:01 |
| ogra_ | you mean it would just know it needs to pull from cdimage instead of system image ? | 18:02 |
| stgraber | slangasek: we could do that, but I really don't see what would be the benefit of this, besides attending a dependency on cdimage to the system-image code (which I'm trying to avoid as we need private servers and extra servers for carriers and ports) and the end result would be just extra cdimage disk use for files we can retrieve from system-image | 18:02 |
| slangasek | but ok, if the point is that the full .tar.xz needs to be published from system-image.u.c *anyway* to handle the case where we need to do a full-tarball update, then yeah, it makes sense to not publish at all to cdimage | 18:02 |
| slangasek | stgraber: right, I think we're on the same page then - sorry for not understanding | 18:02 |
| stgraber | slangasek: right, I'm not publishing anything extra just for phablet-flash, I've got the full tarballs on system-image.u.c anyway :) | 18:03 |
| slangasek | so I think that implies that there's no milestone directory etc. that we need to push for Touch on the supported devices | 18:03 |
| slangasek | however, that doesn't mean we shouldn't declare Touch to be "at beta" | 18:03 |
| ogra_ | yeah, given we do an actual milestone every day since weeks ... | 18:04 |
| stgraber | slangasek: agreed, we could bless a set of version numbers (one per device) as being beta | 18:04 |
| slangasek | stgraber: I don't think we even need to do that | 18:04 |
| slangasek | it's the stable channel, it's supposed to be guaranteed good every day, and if it's good enough for a beta, we just say "here's the beta" | 18:04 |
| ogra_ | stgraber, i think he just means an announcement | 18:04 |
| infinity | slangasek: Hrm. Can you look over the upstart bits in TechnicalOverview and ReleaseNotes and consolidate them. Things seem to have gone out of sync there. I suspect the version in TO is what we want, but RN is ahead of the curve for everything else. | 18:04 |
| stgraber | slangasek: wfm | 18:04 |
| slangasek | infinity: nuke the TechnicalOverview page from orbit | 18:04 |
| infinity | slangasek: Gladly, but I figured you might care about preserving those bits first (or maybe you don't, and they were from last release, I'm not sure). | 18:05 |
| slangasek | infinity: and why is https://wiki.ubuntu.com/SaucySalamander/TechnicalOverview redirecting me to ../ReleaseNotes? | 18:06 |
| stgraber | ogra_: btw, I've been talking with the guys working on the customizations for touch and they'll be the first to run a private system-image server which imports stuff from the public one. Once we've got that figured out and working, the exact same setup will work for ports. | 18:06 |
| ogra_ | |o? | 18:06 |
| ogra_ | err | 18:06 |
| ogra_ | \o/ | 18:06 |
| infinity | slangasek: It's.. Not for me. | 18:06 |
| slangasek | infinity: but no, the stuff on the TO page is WAY too verbose and I didn't even attempt to carry any of it over | 18:06 |
| ogra_ | stuck shift | 18:06 |
| * ogra_ hugs stgraber | 18:06 | |
| stgraber | ogra_: basically ports will be able to run the code on their own server, the ubuntu rootfs will auto-import from cdimage, the gpg keys will be swapped with theirs and their device tarball will be generated from their own code. | 18:06 |
| slangasek | infinity: ok, it's better now - wonder what that was about | 18:06 |
| ogra_ | yeah, sounds good | 18:07 |
| stgraber | ogra_: I guess we'll just need to grow a --server parameter in phablet-flash to support that and we'll be good | 18:07 |
| asac | whats going on? | 18:07 |
| ogra_ | right | 18:07 |
| asac | slangasek: ? :) | 18:07 |
| ogra_ | asac, touch beta release announcement | 18:07 |
| lool | heya | 18:42 |
| lool | so IIUC, archive is frozen for now, which means all uploads have to be reviewed by release team, but you guys are considering using hints instead and selectively approving package uploads this way? | 18:42 |
| stgraber | lool: no | 18:43 |
| lool | stgraber: no to which part? :-) | 18:44 |
| stgraber | lool: there was a discussion earlier and the result was that britney is too late in the pipeline (package already got built) for us to really control what goes in, so we're going with a standard full archive freeze with everything being reviewed by the release team | 18:44 |
| lool | so you've really excluded the hints entirely then, sounds bad | 18:45 |
| lool | then I'd love getting the two packages above (unity-scope-click/0.1+13.10.20130926.2-0ubuntu1 and ubuntu-download-manager/0.2+13.10.20130926.2-0ubuntu1) approved! trying to get them in a touch image | 18:45 |
| infinity | lool: If certain people (ie: touch) want to put blocks in place, then can. For most uploads, blocking twice is likely just a waste of time. | 18:45 |
| stgraber | damn, I hate syncs... | 18:46 |
| lool | infinity: so should I go setup a bunch of blocks for sources only in Touch? | 18:46 |
| asac | will this mode go away after the beta is out? | 18:47 |
| stgraber | asac: no, we'll remain frozen till release | 18:47 |
| infinity | lool: If you want that, yes. I'm not sure that you do, but that's up to you guys. | 18:47 |
| stgraber | infinity: can't remember, do we now have a magic way of getting a debdiff for a sync? | 18:47 |
| lool | infinity: ah but that wouldn't change anything about the frozen state | 18:48 |
| lool | infinity: we'd still have to ping you folks for every single upload? | 18:48 |
| asac | lool: why do we need to add blocks? thought our first problem would be how to get stuff in (and not how to keep it out)? | 18:48 |
| infinity | lool: We tend to be fairly responsive but if something's hung up, yes. | 18:48 |
| infinity | I'm fine with handwaving anything that's not in a package set until we get near final release. | 18:50 |
| infinity | stgraber: Not that I know of. I believe it involves stabbing yourself in the face repeatedly and cursing the autolander. | 18:50 |
| stgraber | infinity: yeah... I just went to the PPA, grabbed the stuff from there and diffed with the archive but that's a real waste of time... I may get bored of that rather soon and hack something together... | 18:52 |
| stgraber | lool: anyway, both approved | 18:52 |
| lool | stgraber: thanks | 18:53 |
| infinity | stgraber: The queue knows the origin, queudiff could be tought to perform that same waste of bandwidth. | 18:54 |
| stgraber | infinity: yeah, that's what I meant by "hack something together" :) | 18:55 |
| slangasek | infinity: hi. archive freeze? | 18:56 |
| slangasek | as I said last week, I don't think we should be freezing the archive. I feel very strongly that we should be using britney instead | 18:56 |
| ogra_ | ++ | 18:56 |
| slangasek | a) the release team should not have to be micromanaging uploads, b) we really don't want to be on the critical path for touch work | 18:57 |
| seb128 | can we get | 18:58 |
| ogra_ | yeah, it would be one slowdown more in an already awfully slow process | 18:58 |
| seb128 | c) uploads shouldn't have to go through some stupid weird google document workflow | 18:58 |
| stgraber | seb128: c) isn't the release-team's fault ;) | 18:59 |
| stgraber | slangasek: I think infinity's plan is to treat ubuntu-touch as unseeded and let them through directly until final freeze like we've been doing in the past for any unseeded package | 18:59 |
| infinity | slangasek: See scrollback. Some people think we should have a full britney block, some an archive freeze. If the choice is between those two things, a freeze is more sane. | 18:59 |
| slangasek | I don't agree | 19:00 |
| slangasek | as stated last time we discussed this | 19:00 |
| infinity | slangasek: If we *only* want to block touch, that's different. | 19:00 |
| mdeslaur | release team: can I upload a fix for LP: #1226509? | 19:00 |
| slangasek | we want to block all seeded things, not just touch | 19:00 |
| infinity | slangasek: Okay, and if we seed all things, I disagree with you wholeheartedly. A britney block is the wrong place to stop broken uploads. | 19:01 |
| stgraber | mdeslaur: looking | 19:01 |
| infinity | slangasek: Once someone inadvertently starts a transition or introduces a massive changeset, reverting is much more annoying than just rejecting. | 19:01 |
| slangasek | infinity: what is the purpose of the freeze? | 19:01 |
| slangasek | philosophically speaking | 19:01 |
| stgraber | mdeslaur: looks like a bugfix to me, so sure, go ahead | 19:01 |
| mdeslaur | stgraber: thanks | 19:01 |
| slangasek | I would say it's to be a safety net to prevent accidental regressions as a result of devs not coordinating appropriately prior to upload | 19:02 |
| infinity | slangasek: I could turn that around and say "what's the purpose of blocking all seeded things?" | 19:02 |
| slangasek | infinity: the exact same thing | 19:02 |
| infinity | slangasek: Okay, but people not coordinating prior to upload doesn't get fixed by letting them upload. | 19:03 |
| slangasek | except one requires active management by the release team at time of upload for every package, and one can let us delegate part of that work | 19:03 |
| slangasek | for proposed-migration | 19:03 |
| slangasek | also | 19:03 |
| slangasek | who was saying we want a full-archive block? | 19:03 |
| slangasek | that might be the easiest to implement, but it's not consistent with our historic post-beta freeze policy | 19:04 |
| slangasek | what we want is "unseeded gets waved through, seeded gets a closer look" | 19:04 |
| stgraber | really? I'm pretty sure we stayed frozen post-beta for the past 2-3 cycles | 19:04 |
| slangasek | stgraber: as a matter of mechanism, not of policy | 19:04 |
| stgraber | and yes, ~ubuntu-release is assumed to just click accept on any unseeded package | 19:04 |
| infinity | stgraber: Yeah, but spiritually, he's right, in that we just let unseeded through. Ish. | 19:04 |
| slangasek | the *policy* is "unseeded is officially unfrozen, but we can't selectively freeze the archive so we have to poke them manually" | 19:05 |
| infinity | (Though, I did still check for obvious "dude, you're doing a library transition 3 days before release, really?" things) | 19:05 |
| slangasek | infinity, stgraber: did we rule out a britney block for all-seeded on practical grounds? | 19:05 |
| infinity | slangasek: I don't have massively strong opinions on it, but I actually find blocks more annoying to manage, not less, and it's indisputable that they don't offer the same level of protection against flat out stupid and FFe-breaking uploads. | 19:06 |
| infinity | Because you can't un-upload something once it's in the archive. | 19:06 |
| slangasek | but you can certainly rm it from proposed | 19:06 |
| slangasek | which is all the same to me | 19:07 |
| stgraber | slangasek: yeah, I think the biggest issues with britney are: no notification, no tooling to grab diffs, painful to push new unblocks and pretty hard to revert things in case something's actually broken in the upload (as things will already have built against it in proposed) | 19:07 |
| infinity | slangasek: Still forces version constraints, could need rdep rollbacks, etc. | 19:07 |
| slangasek | infinity: whereas the other way we have to have somebody on the release team always on call to avoid holding up touch development | 19:07 |
| infinity | slangasek: Someone uploads libfoo_2.0 over libfoo_1.0, you want to put your foot down, you now have an epoch. HAND. | 19:08 |
| slangasek | and while we could send queuebot notices to your phone, I don't think that's actually what we want ;) | 19:08 |
| stgraber | so doing a full freeze, dropping the blocks and having us wave through unseeded+touch seemed much easier, then the touch guys can use britney as they usually do, the only extra overhead is on ~ubuntu-release to check the packageset field and click accept | 19:08 |
| slangasek | infinity: I think that's the tail wagging the dog | 19:08 |
| slangasek | we can certainly deal with such cases without epochs if we care about that (the ugly upstream+really-oldupstream mocking trick) | 19:09 |
| slangasek | that's assuming it happens at all | 19:09 |
| infinity | slangasek: I think every time someone says "oh, we can just delete what we don't like from proposed", they're missing fundamental concepts of how this all works. | 19:10 |
| slangasek | I think I know how -proposed works | 19:10 |
| infinity | slangasek: Sure, you don't need an epoch, that was just an illustration. | 19:10 |
| infinity | slangasek: I think you do too, so I'm a bit confused by the statement. ;) | 19:10 |
| infinity | The only way forward once something is in the archive is forward. Always. | 19:10 |
| slangasek | yep | 19:11 |
| infinity | This isn't a big deal when forward is just some bug fixes. | 19:11 |
| slangasek | and the cases where we actually need to back things out is *so rare* that putting a full archive freeze in place to prevent it is tail-dog-wag | 19:11 |
| infinity | It's irksome when forward is rolling back a complex accidental transition (yes, this happens, yes, I've rejected last-month uploads for this, it's not a strawman to prove a point). | 19:11 |
| lool | can we automate accepting packages without a packageset? | 19:12 |
| slangasek | yes, I understand it's not hypothetical - but it's still sufficiently rare that I don't believe it's a better use of the release team's time to have to hand-approve every package in the queue | 19:12 |
| infinity | We have pretty good timezone coverage, is it really so onerous to just have an AA/RM wave through non-packageset stuff? | 19:12 |
| seb128 | infinity, I don't know about this cycle, but every other cycle we had annoy delays at times with that | 19:13 |
| stgraber | lool: I tend to not trust the absence of a packageset as a green flag instead relying on seeded-in-ubuntu instead, but yes, we could automate something to look at the queue for packages without packageset set, then check using seeded-in-ubuntu and if that's clean, let it through | 19:13 |
| stgraber | lool: most of us already deal with the queue using the API, not the webUI | 19:14 |
| infinity | seb128: You were almost always uploading seeded stuff in previous releases. And yes, we were reviewing those. | 19:14 |
| infinity | There's a third option here. | 19:15 |
| infinity | cu2d runs as a bot with AA permissions. If it has a concept of "safe to slam in" and "not so much" sets, it can do its copies with --auto-approve. | 19:15 |
| infinity | And entirely bypass the queue for touch. | 19:16 |
| stgraber | it'd have to be clever enough to know if something's seeded or not | 19:16 |
| stgraber | I certainly don't want unity, indicators, ... any of those cu2d packages to bypass the queue | 19:16 |
| infinity | stgraber: No more clever than whatever hackish script generates the massive block (and then gets out of date as people swap deps around in a last minute rush to upset people who like feature freezes). | 19:17 |
| stgraber | infinity: sure, that's why I'm in favor of the archive freeze and not the massive block too, I try to be consistent in my opinions ;) | 19:17 |
| slangasek | infinity: yes, it is onerous, and it slows down the development of Touch. | 19:18 |
| stgraber | infinity: and why I suggested that I'd be fine with us scripting auto-accepts if the source isn't in any packageset and that the binaries aren't seeded anywhere (using seeded-in-ubuntu) as those are the two checks I do before letting an unseeded package through | 19:19 |
| slangasek | infinity: would you be happy with scripted auto-accepts, like stgraber suggests? | 19:21 |
| slangasek | and would we be able to do such scripting for packages in touch? | 19:22 |
| stgraber | slangasek: sure, I believe touch should be unseeded and only be on the ubuntu-touch image, so should be easy enough to check (that's how I reviewed the list of standing FFes for touch the other day) | 19:22 |
| * slangasek nods | 19:23 | |
| infinity | I'd be alright with that. | 19:23 |
| infinity | It's basically the same as my cu2d suggestion, but with checks at a different spot. | 19:24 |
| infinity | And a spot stgraber trusts more, so I'm fine with that. | 19:24 |
| slangasek | ok, seems like that's a way forward then | 19:25 |
| slangasek | should it be part of cu2d for the touch packages? | 19:25 |
| slangasek | (the --auto-approve) | 19:25 |
| stgraber | I'd really prefer it doesn't, too much potential for troubles and not something owned by the release-team or a release team member | 19:26 |
| slangasek | ok | 19:26 |
| slangasek | stgraber: would you have time today to put something together to drive the auto-accepts for touch-only + unseeded? | 19:27 |
| stgraber | slangasek: yep, should be easy with a bit of copy/paste from queuebot. I'll let people know once I've got something so they can stop accepting things in the queue (need something to test against ;)) | 19:28 |
| slangasek | stgraber: ok, thanks :) | 19:28 |
| infinity | stgraber: To be fair, while note technically owned by release, cu2d is effectively owned by archive admin. But I'm happy enough with your proposed solution. | 19:29 |
| infinity | s/note/not/ | 19:29 |
| infinity | Anyhow, I'm going to go back to crossing my eyes at trying to verify this beta release mirror layout. | 19:29 |
| infinity | And lunch, while mirrors settle. | 19:37 |
| infinity | Or breakfast. Or whatever this is. | 19:37 |
| infinity | zul: Is there an FFe for this python-ceilometerclient? | 19:41 |
| zul | infinity: its just bug fixes i believe | 19:45 |
| infinity | zul: Commit 3499631b1a32b2125bd89de2e7ce45d9dd19a7c4 is definitely more than a bugfix. | 19:49 |
| infinity | And a couple others. | 19:49 |
| stgraber | slangasek, infinity: I've got a script now, please keep stuff in the queue so I can test it :) | 19:58 |
| infinity | stgraber: You say, after I accept a bunch of stuff... | 19:58 |
| stgraber | (currently been testing against precise-proposed but that's not ideal since seded-in-ubuntu doesn't work against older series) | 19:58 |
| infinity | stgraber: libunity-webapps is still there (was about to review it), but that's an "is seeded" test, at least. | 19:59 |
| infinity | stgraber: Sadly, I accepted all the seeded stuff before you asked. :P | 19:59 |
| slangasek | stgraber: great! | 19:59 |
| stgraber | stgraber@castiana:~$ ./auto-accept | 19:59 |
| stgraber | Skipping 'libunity-webapps' because it's in the following packagesets: ubuntu-desktop | 19:59 |
| stgraber | Skipping 'python-ceilometerclient' because it's in the following packagesets: ubuntu-server | 19:59 |
| stgraber | (it first looks at packagesets, then goes to check for seeds as that's a costly check) | 20:00 |
| infinity | stgraber: Does snakefruit have everything you need to run it there, cronned at * or something? | 20:00 |
| slangasek | stgraber: so, what frequency can this run with? and, is it bound to your home network? | 20:00 |
| bdmurray | slangasek: does the verification of bug 1210447 look okay to you? It seems fine to me | 20:00 |
| slangasek | right, that's where I was going with that question | 20:00 |
| infinity | slangasek: Jinx. :P | 20:00 |
| stgraber | infinity: no seeded-in-ubuntu on snakefruit :( | 20:01 |
| infinity | stgraber: Throw a dev-tools checkout in ~ubuntu-archive for now, request the package be installed if precise is good enough for your uses? | 20:02 |
| infinity | (Might also have firewall issues) | 20:02 |
| stgraber | infinity: oh, and we need network access to ubuntuwire | 20:02 |
| infinity | In fact, we have a dev-tools checkout. | 20:03 |
| infinity | Arguably, we should be running these ubuntuwire services ourselves, a bit closer to the archive. | 20:05 |
| infinity | seeded and reverse-depends and whatever else. | 20:05 |
| infinity | But for now, I've requested a firewall hole. | 20:05 |
| stgraber | infinity: squid.internal lets me access ubuntu-wire, so that should be good enough | 20:05 |
| infinity | stgraber: Ahh, that works. | 20:05 |
| infinity | stgraber: I'm happy with the libunity-webapps review, BTW. Feel free to accept it blind once you're finished your tool testing. | 20:08 |
| * infinity really goes to find food now, before he passes out. | 20:08 | |
| slangasek | bdmurray: isn't that covered by an MRE? | 20:10 |
| slangasek | in which case, yes | 20:10 |
| stgraber | infinity: gah, just reviewed ceilometer for nothing (didn't see your comment above) :) I'll reject for now | 20:11 |
| lool | stgraber: powerd should be a good test | 20:11 |
| stgraber | lool: yep | 20:11 |
| bdmurray | slangasek: well, its a provisional MRE but yeah | 20:11 |
| slangasek | bdmurray: right, then LGTM | 20:11 |
| stgraber | ubuntu-archive@snakefruit:~$ ./auto-accept | 20:12 |
| stgraber | Accepting: powerd | 20:12 |
| stgraber | Accepting: mediascanner | 20:12 |
| stgraber | Accepting: mediaplayer-app | 20:12 |
| stgraber | Skipping 'libunity-webapps' because it's in the following packagesets: ubuntu-desktop | 20:12 |
| slangasek | bdmurray: btw, would you happen to have time today to look at the gnu-efi + sbsigntool packages in the queue? I'd like to get that out the door so I can forget all about SecureBoot again :) | 20:12 |
| stgraber | so confirmed it DTRT with both the packageset and seeds check, will get the script out of dry-run mode now | 20:12 |
| slangasek | hurray, made bug #1205075 someone else's problem | 20:13 |
| bdmurray | and is it just me or does the schooltool-book upload to raring look like a mistake? | 20:13 |
| stgraber | and ran for the first time, we should see 3 accepts nowish | 20:15 |
| slangasek | tada | 20:16 |
| stgraber | ok, now we just need to run that thing every, say, 5 minutes? | 20:16 |
| slangasek | every minute, please | 20:16 |
| stgraber | ok | 20:16 |
| slangasek | unless you know precisely which minute out of every 5 to run it to ensure it sees the queue updates :) | 20:17 |
| infinity | The queue updates every minute. | 20:17 |
| slangasek | ok | 20:17 |
| infinity | And so should the auto-accept. | 20:17 |
| * slangasek nods | 20:17 | |
| infinity | lool / asac: So if you guys also want to do blocks for touch, you have that power delegated. But this compromise here should blance quick accepts of unseeded uploads with late-cycle paranoia for other images. | 20:20 |
| infinity | s/blance/balance/ | 20:20 |
| stgraber | I have a tiny concern about the script hammering LP and ubuntuwire a bit more than it should since I'm not doing any caching for past entries, but I guess it won't be that bad and if someone complains, it's just a matter of sticking a cache on the thing | 20:20 |
| infinity | stgraber: Thanks for the quick hack. Love your work, crazy tool man. :P | 20:20 |
| infinity | stgraber: It won't hammer LP any appreciable amount. ubuntuwire could be another story. But you ARE grabbing the json via a squid proxy. If you're not forcing cache invalidation, that should catch the hammering. | 20:21 |
| slangasek | "crazy tool man" -- the best of the MegaMan mods | 20:21 |
| stgraber | alright, it's been cronned and the output redirected to a .log file. I've commented all the "skipping..." ones to avoid getting a mile long log file after an hour, we can always turn those back on if we need to figure out why something didn't get auto-accepted | 20:24 |
| ogra_ | ^^^ this ubuntu-touch-meta introduces two new binaries, can someone guide them out of binary NEW please ? | 20:30 |
| infinity | stgraber: Say, did your script already fail? :) | 20:33 |
| stgraber | infinity: I'm looking at it :) | 20:33 |
| infinity | ogra_: And yes, once it's built, I'll jam it through. | 20:34 |
| ogra_ | thanks | 20:34 |
| stgraber | infinity: now to figure out why it works fine when ran manually and fails under cron... | 20:34 |
| infinity | Environment? | 20:35 |
| stgraber | that's my guess, but it's not writing anything to stderr so it's failing in a rather silent way... | 20:35 |
| stgraber | put it into verbose mode for now so I can see whether it at least gets to the queue properly | 20:36 |
| infinity | stgraber: Need PYTHONPATH=/home/ubuntu-archive/python maybe? | 20:37 |
| stgraber | Skipping 'android' due to Invalid output from seeded-in-ubuntu. | 20:37 |
| stgraber | that typically means it's not happy with my http_proxy, which weirdly enough I don't have in my env either... anyway, easy enough to fix | 20:38 |
| stgraber | let's see if the next run accepts android | 20:39 |
| infinity | stgraber: Just call it with http_proxy=http://squid.internal:3128/ like the autosync above? | 20:39 |
| infinity | Ahh, you did. :) | 20:39 |
| stgraber | yep :) | 20:41 |
| infinity | stgraber: Same problem. Also, s/>/>>/ | 20:41 |
| stgraber | infinity: I just s/>/>>/ :) but yeah, same problem, so maybe not a proxy problem after all, I'll get the code to print the actual error | 20:42 |
| bdmurray | slangasek: shouldn't bug 1066038 have a raring task? | 20:43 |
| stgraber | infinity: you were correct earlier, I needed the PYTHON_PATH, I just didn't think I did because it was set by default in ~ubuntu-archive's environment | 20:46 |
| stgraber | android got accepted, so looks like it's working fine now | 20:47 |
| infinity | stgraber: I'd suggest timestamps in the log too, so reading it once it gets large isn't quite so hard. | 20:51 |
| infinity | stgraber: (And maybe package_version, so we don't end up with 37 androids, all alike) | 20:51 |
| infinity | And I really need to do the eating thing now. | 20:52 |
| infinity | slangasek: I'll be double-checking mirror health and putting together the final announce as soon as I get back from food, if you have touch verbage for me by then. | 20:53 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| Riddell | are we there yet? | 21:00 |
| slangasek | bdmurray: 1066038> precise/quantal/raring, you mean? Good question; I wasn't intending to do any separate SRU verification for that change, which is why I didn't open tasks | 21:10 |
| slangasek | infinity: sorry, got caught by an unhelpful OOM condition here that made everything go wonky and am now piecing my desktop back together... and I need food too before I go on | 21:11 |
| slangasek | infinity: so it'll be a little bit before I can have anything for you | 21:11 |
| darkxst | infinity, thanks ;) | 21:48 |
| slangasek | Riddell: so unfortunately, even though we ran into this problem last cycle already and /thought/ we had addressed the issue by fixing our checklists, apparently we missed a spot and are again in the situation of being unable to change the website redirect outside of UK business hours :P | 23:17 |
| slangasek | so I believe everything is /published/, and flavors can feel free to announce etc., but the Ubuntu announcement won't go out until we can fix the web redirect so that we're not flooding the pipe | 23:17 |
| slangasek | i.e., "when London wakes up" | 23:18 |
| lool | mdeslaur: dsc0t-make-check FAIL status: 0, stderr: ../../test-driver: line 95: 29235 Aborted (core dumped) "$@" > $log_file 2>&1 | 23:20 |
| lool | mdeslaur: systemd autopkgtest failed | 23:20 |
| lool | mdeslaur: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html for details | 23:20 |
| lool | and link to jenkins jobs | 23:20 |
| lool | mdeslaur: to clarify, it's an autopkgtest of a package depending on systemd | 23:21 |
| slangasek | lool: looks like there are two adt failures? one for colord, one for systemd itself | 23:22 |
| slangasek | cp: cannot create regular file ‘/tmp/mkinitramfs_QeYyHu//lib/modules/3.11.0-8-generic/kernel/drivers/net/ethernet/natsemi/natsemi.ko’: Input/output error | 23:24 |
| slangasek | ... ok then | 23:24 |
| slangasek | lool: that appears to be a pre-existing bug in colord, it's been failing continuously since July and apparently no one has cared :/ | 23:26 |
| lool | I think infinity forced the colord side | 23:27 |
| lool | but the other failure probably prevented it from migration | 23:27 |
| slangasek | the other failure looks like a random jenkins slave failure | 23:27 |
| slangasek | the dmesg on that one implies fs corruption | 23:28 |
| slangasek | plars: ^^ is that something you would be able to fix? | 23:28 |
| slangasek | plars: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-systemd/85/ARCH=amd64,label=adt/ | 23:29 |
| knome | slangasek, what are you suggesting for flavors? | 23:29 |
| slangasek | knome: that you should feel free to proceed with any per-flavor announcements you had planned without waiting for the central mail to go out | 23:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!