[04:38] doko (and slangasek): I can and did pick openjdk-7 from rejected. it is building in the security-proposed ppa (along with trusty and precise) [04:40] jdstrand: Ta. [05:19] Mass rebuild in progress for a new kernel, and other bits. === jzheng is now known as jzheng_afk [10:26] SRU team, please release xfce4-weather-plugin into trusty-updates, https://bugs.launchpad.net/ubuntu/+source/xfce4-weather-plugin/+bug/1377612 [10:26] Launchpad bug 1377612 in Xfce4 weather plugin "[SRU] Plugin needs updated for locationforecast-1.2" [Medium,Confirmed] [10:47] cjwatson, with the utopic server iso and installing over an existing install (standard using LVM) I run into the situation of first partition (which contains /boot) of the disk still mounted to /media. The installer acts correctly and asks to unmount and from there all is normal. So nothing fatal but just odd. Should I file a bug about it or do you already have one? [11:17] ^ cloud images marked ready [11:32] smb: I have no idea whether we have a bug about that. I'll give it a try a bit later. [11:34] infinity: In case you notice the build failure when you get up, I manually respun server from nusakan; it looks like rebuild-requests is confused about whether it needs to do a live filesystem build in the server case or not [11:34] infinity: ubuntustudio/i386 failure still needs investigating, possibly from a better network [11:41] cjwatson, Ok, I am using the dailies from the 18th (which seem to be the most current). A cobbler netboot install with pre-seeding was ok. Hm, the mini iso there dates from the 17th. Manual update got them to todays date. [11:41] Will re-run the netboot install [11:42] smb: Yeah, see above comment to infinity for why the server dailies are old [11:44] cjwatson, Doh. Ok I read the message but it sounded Japanese to me. Meaning I did not get its meaning. :) [11:46] OK, it was intended to be meaningful mainly to Adam, but "previous rebuild didn't work, I did it differently" :-) [12:23] heh. ok. so with more recent image, netinstall still seems ok. good [12:31] smb: ah, so I don't need to investigate this now? [12:33] cjwatson, Well it was the full iso install that showed the issue. But let me repeat that with the newer isos when they show up. As long as only manual cd install has it there is someone to press yes for unmount. [12:34] there already. just need to sync now [12:50] cjwatson, I would still see the unmount dialog with latest iso. But since the netbook variant seems unaffected it does not seem to warrant that you look at it urgently. You likely have enough other things to do and are caught in the wrong timezone. [12:50] I meant netboot [12:50] ok, well let me queue it up for if/when I get a moment, thanks [12:54] cjwatson, may I ask you a trivial sync? [12:54] please ask don't ask to ask [12:54] kbuild... one single line [12:55] one fatal error changed to error, because otherwise virtualbox won't build with newer kernels, fixing also a debian RC [12:55] http://anonscm.debian.org/cgit/pkg-virtualbox/kbuild.git/commit/?id=0437af2183faedf5b9b065bc0910242afba1e53e [12:55] this is the bit [12:56] LocutusOfBorg1: done [12:56] thanks! [12:56] modulo queue and such [12:57] LocutusOfBorg1: well I would have closed it, I was just waiting for the auto-accept [12:58] ops I though you didn't noticed the bug ;) [12:58] I did although it would have been nicer if you had directed me to it [12:59] indeed, sorry for that, I wrote it today on #devel IIRC [12:59] fairly little brainspace right now [13:00] #-devel was the right place to ask really, just bear in mind that a lot of us are on US/Eastern time right now [13:01] ack ;) I asked on 9AM CEST lol [13:01] anyway thanks, I hope one day I'll be able to do the sync by myself, at least for packages I maintain :) === pete-woods is now known as pete-woods-afk === Guest45646 is now known as kirkland [14:16] cjwatson: The studio failure looks like an apt loop-breaking bug, but this is a rather inconvenient time for it to pop up. [14:17] infinity: I couldn't reproduce it locally, so I've tried just mashing retry and hoping [14:17] (It does, yes) [14:18] infinity: I have unicorn SVGs. Shall I mail you them (or indeed come up to the room and we can mess about with gimp)? [14:18] cjwatson: Sure. [14:19] cjwatson: Either of those things, or both. === pete-woods-afk is now known as pete-woods [14:20] jibel: Did you file a bug for your qemu -vga std' [14:20] jibel: ... issue? [14:24] infinity, bug 1383851 [14:24] bug 1383851 in linux (Ubuntu) "Cannot enter LVM encryption password in qemu with -vga std" [Medium,Confirmed] https://launchpad.net/bugs/1383851 [14:25] infinity, this one? [14:25] jibel, when you boot it in that mode, what do you see? black screen? [14:25] jibel: Yep. [14:25] apw: You get the proper screen, it just seems "frozen". [14:25] jibel, actually come into my parlour [14:25] apw: No amount of hammering the keyboard does anything. [14:26] apw, you see the lvm encryption password prompt but cannot type anything [14:26] apw, like it doesn't receive kb input at all [14:27] jibel: Did you narrow it down at all between -17 and -22? [14:29] infinity, not yet, I'm verifying latest images [14:40] slangasek: https://bugs.launchpad.net/ubuntu-website/+bug/1384291 [14:40] Launchpad bug 1384291 in Ubuntu Website "Ubuntu download thank you page links to documenation team information" [Undecided,New] [14:45] infinity, cjwatson: what is the rough chance between "go away" and "yeah, fine" of uploading two fixes to autopkgtest which fixes running autopilot tests on phones? [14:46] (not seeded anywhere) [14:46] pitti: since not seeded, the chance is somewhere in the middle [14:50] slangasek: thanks, I'm taking that :) [14:50] it's not really that important, in CI we'll need to run a backport anyway; but it's making things more convenient for touch devs on utopic [14:52] so if you folks are in washington, what's the ETA for release tomorrow? [14:54] Riddell: No specific time set, but aiming for more or less our usual timeline adjusted for local timezone. [14:55] Riddell: (ie: we shoot for noonish, with acceptable slippage into the afternoon and early evening, and see how we do) [14:55] Riddell: There's always the hope (dream) that everything's ready on Wednesday and Thursday is just mindless button pushing, but... ;) [14:55] infinity: noonish on +5? [14:56] Riddell: No earlier than noon on +5, I'd say, but definitely could be quite a bit later if the world doesn't go our way. [14:57] Err, +5? Wrong direction. :P [14:57] We're in -0400 right now. [14:58] And you're +1, so -5 total for your math. [15:02] infinity: gotcha, thanks :) [15:02] people should just use UTC... [15:04] pitti: stuff not on images has a while yet, yeah [15:06] knome: apply biiiig hammer to earth → no time zones any more [15:10] pitti, lol, worksforme [15:12] I'm easy with timezones - would rather not see enormous hammer :p [15:24] balloons: hey, so would there be a problem with a mass respin soon? we have a new linux-firmware and a new ubiquity-slideshow-ubuntu, so would be good to get that lot through; there are some test results on the tracker [15:26] cjwatson, I would rather see a respin sooner rather than later on this. I haven't checked the critical bug list yet this morning, so I'm not sure what's outstanding (in other words if another respin would happen or not) [15:27] sooner> yeah so would we [15:28] respin cycles are much faster now, an hour or two [15:29] I see a few red bugs but (from a quick skim) I suspect they're mostly fairly long-standing installer issues, not something likely to be fixed in a respin at this point [15:29] but second opinions welcome [15:29] * balloons loos [15:29] I'd look instead balloons [15:29] elfy, :-) [15:31] cjwatson, ack, I agree. Good, if that works out we're in good shape [15:52] cjwatson, if you respin is needs to be very very soon. cloud images will take > 14 hours [15:53] yeah, I'm just going to get linux-firmware in [15:53] you can start right after that I guess? [15:54] oh we need d-i [15:55] rcj, cjwatson: actually if it only linux-firmware, it does not require a respin [15:55] rcj, cjwatson: cloud images don't ahve linux-firmware [15:55] do they have debian-installer? [15:57] cjwatson: negative. However, it looks like the arm builds have it [15:57] cjwatson: for linux-firmware [15:58] cjwatson, utlemming: I see a new linux-virtual in proposed, is that coming in too? [15:58] cjwatson, utlemming: nevermind, wrong release. [16:01] utlemming: ok, so do you need to respin just the arm ones? [16:14] cjwatson: we would have to respin everything, otherwise the serials are off [16:14] ok, you should be good to go quite soon, linux-firmware is migrating as I type [16:15] we're just waiting for argh why have I never QAed the faster apt-ftparchive [16:15] (answer: because 19000 things to do) [16:33] smb: your bug is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745717, which includes a workaround [16:33] Debian bug 745717 in di-utils "di-utils: fetch-url runs mountmedia without cleaning up; blocks partitioner preseeding" [Important,Open] [16:35] cjwatson, Ah yes. [16:42] cjwatson, anything else or can I let the cloud publication begin? [16:44] rcj: go go go [16:45] cjwatson, thanks === rtg is now known as Guest70449 [17:41] infinity: can we get the owncloud package removed from utopic? [17:42] (and blacklisted so it doesn't get synced) [17:44] robertk_: soooo close [17:44] this will be tight but nearby [17:58] mdeslaur: Do you have a bug for that? [17:58] damnit amd64 hit a raid-card-less builder [17:59] no wonder it took ages :-( [17:59] infinity: one sec, I'll open one [18:02] infinity: bug 1384355 [18:02] bug 1384355 in owncloud (Ubuntu) "ownCloud should be removed from Utopic" [Undecided,New] https://launchpad.net/bugs/1384355 [18:08] mdeslaur: removed and blacklisted. [18:08] thanks infinity [18:09] mdeslaur: A solution for trusty and precise would be nice, though. [18:09] mdeslaur: Note that precise-updates has a (now old) backport, so someone was originally going the "just toss in the latest version" route. [18:10] infinity: yes, having someone update to the latest versions regularly would be ideal...perhaps someone on the list will step up [18:12] cjwatson: nice! [18:13] yep it's there now [18:13] depending on which cdimage mirror you hit, but will be there by the time IBM look [18:13] robertk_: http://cdimage.ubuntu.com/ubuntu-server/daily/20141022.2/ [18:13] thank you! [18:57] new images? [18:58] updated linux-firmware, debian-installer, ubiquity-slideshow-ubuntu; was hard to get that lot in without respinning everything [18:59] cjwatson: but we have had two respins today? [18:59] though pretty minor changes so from your point of view should just need very quick smoke-tests if you already tested earlier iterations [18:59] this is the second yeah [18:59] AFAIK we should be done from here [18:59] missed something in the first/ [18:59] yes [18:59] I mean that goes without saying right? :) [19:00] well yeah but i thought we had it done [19:00] i don't remember balloons mentioning ubiquity-slideshow-ubuntu, though [19:00] we did tell him today [19:00] like I say should just require very quick smoke testing [19:00] also nobody ever promised that the last respin was done, or if they did they were wildly optimistic [19:01] hahahah okie dokie [19:01] if you've already tested the previous version, just make sure that this one passes a quick install test or similar and call it good [19:01] cool thanks cjwatson [19:01] *already tested the previous version more thoroughly [19:02] if only lubuntu desktop would hurry up already [19:02] * wxl scowls [19:02] shouldn't be long, https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu/+build/9493 and https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu/+build/9498 [19:03] the estimates should be fairly plausible by this point [19:03] then just the quick bit on nusakan [19:03] oooh nice [19:03] i didn't even know about that [19:03] you are a plethora of wonderful info cjwatson :) [19:03] most recent ones are linked from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/utopic/lubuntu [19:04] unfortunately panlong is one of the builders without a raid card (in progress, I filed the ticket four months ago but it's been stalled on hardware acquisition) so it's a bit slower [19:04] but still should be quick enough, respins aren't an eight-hour proposition any more [19:04] yes but having that estimated time is awesome [19:04] even if it is slower XD [19:04] mdeslaur: security problems in owncloud? [19:04] Riddell: upstream asked for it to be removed due to security issues, yeah [19:05] Riddell: upstream wants us to remove the packages [19:05] it's the median of the last nine successful builds, as an approximation [19:05] not the mean, eh? [19:06] I tend to prefer median for this kind of thing to reduce the effect of outliers [19:06] though not a statistician [19:06] shame but fair enough [19:07] cjwatson: is there a general non-release-specific link i can use to see build status or get to it? [19:07] wxl: afraid not [19:07] I didn't quite finish a proper livefs index in LP, maybe at some point [19:07] cjwatson: same general layout, though? [19:08] Yeah [19:08] e.g. https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/codename/flavor [19:08] Yeah [19:08] cool thanks :) [19:10] cjwatson: I can reproduce the bug now, thanks for your help with the buildlivefs [19:10] mvo: oh fantastic [19:11] wonder what the relevant different was [19:11] *difference [19:11] cjwatson: next thing is to get it into a state so that I can debug it, I am trying this now [19:11] oh yeah buildlivefs possibly nukes it [19:11] actually it shouldn't if you run it on its own [19:12] only if run from the full launchpad-buildd state machine [19:12] cjwatson: the chroot is still here, but I want the dpkg status and /var/lib/apt/lists/* status before the apt-get operation starts [19:14] right [19:14] hack it to use a stunt live-build that has a big sleep in there maybe [19:14] cjwatson: yeah, good idea [19:15] cjwatson: the track is not updating despite the fact that amd64 is uploaded [19:15] wxl: it'll get there, there's a final assembly stage [19:15] cjwatson: ah ok [19:15] logs of that are at http://people.canonical.com/~ubuntu-archive/cd-build-logs/lubuntu/utopic/ but it's only updated periodically rather than cronned [19:15] so unfortunately you can't see that live [19:16] wxl: also, it's waiting for the i386 one to finish before it does the assembly [19:16] cjwatson: that's interesting [19:17] yeah I might have done this differently if I were writing the code from scratch but it's quite hard to disentangle now [19:18] anyway will be less of an issue in this case once the buildd hardware is normalised [21:18] cjwatson: "Dpkg::MaxArgs" defaults to 8k and "Dpkg::MaxArgBytes" to 32k - we can increase this for the failing build, I will also investigate now how to drive dpkg in a different way to avoid this limit entirely === beisner is now known as beisner-afk [21:22] mvo: thanks! infinity ^= [21:29] mvo: Ta. [21:30] infinity: it should be fine to multiply the current values by 4 - _SC_ARG_MAX is big enough (and the code is stupid *sigh*) [21:31] mvo: Sure, just need to find a clever place to hack that in temporarily. [21:31] * mvo nods [21:39] cjwatson: I assume that if I'm happy with the testing we've done already - the newest respin just needs a check to make sure it doesn't do anything bad [21:40] elfy: Yeah, pretty much. Very few things changed. [21:41] infinity: thought as much - just wanted to make sure I could get to bed tonight :D [21:41] elfy: Check that we didn't accidentally break your slideshow (we didn't, but check), and that linux-firmware seems sane to you, and the usual boot/install/reboot smoketest. [21:42] infinity, i'm sure you put in pink unicorns in it :( [21:42] elfy: right, smoke-test [21:43] knome: I was going to, but didn't have time. [21:43] infinity, damn. [21:43] then it must've been somebody else [21:44] mvo: configure-index.gz claims the defaults are much lower. Is that out of sync with reality? [21:44] pretty sure it's the same as it was - just the vbox issue and black try/install background we know about [21:44] elfy, and the pink unicorns! [21:44] http://sixgun.org/files/utopic-unicorn.jpg [21:44] that was last night knome [21:44] i'm sure you've all seen that already [21:44] but if not you're in for a TREAT [21:45] wxl: wow [21:45] wxl: I have... No words. [21:45] hgahahahahah [21:45] good lord [21:45] gosh [21:46] seriously though i can't wait for unicorn shirts [21:48] * knome was referring to http://temp.knome.fi/xubuntu/.pink-unicorns/slideshow.png though [21:49] pretty cute [21:49] infinity, ^ that must've been you, eh? :P [21:51] infinity: its out of sync, yeah [21:51] infinity: thanks for letting me know [21:51] mvo: Couldn't that be autogenerated somehow? [21:51] mvo: And why doesn't "apt-config dump | grep DPkg" show those options at all? :/ [21:51] infinity: the configure-index.gz? maybe, yes. [21:52] unsigned int const MaxArgs = _config->FindI("Dpkg::MaxArgs",8*1024); [21:52] unsigned int const MaxArgBytes = _config->FindI("Dpkg::MaxArgBytes",32*1024); [21:52] mvo: Alright, the code probably isn't lying. ;) [21:58] infinity: the configure-index is not lying in git anymore now too [22:18] infinity, cjwatson: so core built fine this time but didn't publish because the build needs to be triggered using daily-live but the resulting artifact is daily-preinstalled and triggering and publishing from/to the tracker uses a single file [22:18] so the fix would be to make cdimage consistent then we should be good :) [22:18] until then we've got the choice between ability to trigger from the tracker or having the images publish there [22:18] err that's weird [22:18] it's daily not daily-preinstalled [22:19] http://cdimage.ubuntu.com/ubuntu-core/daily/pending/ [22:19] daily-preinstalled is your stuff :) [22:19] oh right [22:19] so uh yeah, that's going to be not quite trivial (maybe not hard, but not release day - 1 stuff) to disentangle, suggest just building by hand for now [22:19] still, same problem, triggered with daily-live, then we get: [22:19] No iso.qa.ubuntu.com product found for ubuntu-core/daily/utopic-core-powerpc; skipping. === adam_g is now known as adam_g_gone [22:19] By hand works for me. [22:20] yeah, my plan once I'm done with my current meeting is to revert my change and just hardcode daily-live in rebuilt-triggers [22:20] which is ugly but will do the trick [22:20] ok [22:23] stgraber: As long as I have all my core builds in time to test them in the morning, that's good enough for me. :P [22:23] It's not like they take more than a few seconds to validate.