[00:13] stgraber: ^ [02:24] slangasek, I find the ubuntu kylin team has a pending FFe, bug 1305187, wonder if it can still be approved? I know it's very very late now, but the package is quite self-contained and they think it's valuable to be on the image [02:24] Launchpad bug 1305187 in Ubuntu Kylin "[FFe] upload ubuntu-kylin-docs into archive" [High,New] https://launchpad.net/bugs/1305187 [02:26] ypwong: I'm not going to update the bug at the moment, but in general the only rule about FFes for new packages is "if you can find an archive admin to approve it, it can go in". So the best course is to get it sponsored into the NEW queue where it can be reviewed [02:27] slangasek, let me ping seb128 if he has bandwidth to do that [02:53] Subject says mass respin in progress. Is that still accurate and for how long? [02:54] I may have a good to have, but certainly not worth a respin. [02:56] I guess that kind of tells me. SRU it is. [04:49] hey guys, what happened to minidlna? it seems to be missing from trusty, not sure why. https://launchpad.net/ubuntu/+source/minidlna [04:54] robru: Look at the top entry on https://launchpad.net/ubuntu/+source/minidlna/+publishinghistory [04:55] ScottK, ah, didn't notice that those expanded until just now. Was about to ask "yeah, I see Deleted, but *why*?" kthx [04:59] cjwatson, infinity: is the debian "import" already turned off? unable to sync new debian versions [06:24] !respin [06:24] Factoid 'respin' not found [07:09] Morning release team! Could anyone of you give me some information on why an appmenu-qt5 release I prepared got rejected? Was something wrong? [07:19] doko: The debian import is never switched off. What is missing? [07:37] xnox, language support is working fine now. Thanks! [07:44] xnox, there is just a problem, unrelated to this change, with the keyboard layout. On first login the keyboard indicator shows FR but the real layout is US. [07:53] jibel: in login screen, lock screen or the actual desktop? [07:53] xnox, the actual desktop [07:55] jibel: ack. [08:13] sil2100, if it was rejected there should have been a reject email with reasons in it [08:17] apw: which probably went into ps-jenkins-private mailbox - /dev/null @ some canonistack instance =) [08:19] xnox, man that is just hopeless ... sigh [08:21] Right, as xnox mentioned - I for sure have no access to that mailbox [08:22] xnox, language support is still broken in oem mode, and now gnome-language-selector crashes when I open it from system-settings === tkamppeter_ is now known as tkamppeter [08:35] hi release team, we have uploaded the ubuntukylin-default-settings for the critical bug: Bug #1298237, is there anyone who could help to review the package? [08:35] Launchpad bug 1298237 in ubuntukylin-default-settings (Ubuntu) "Cannot login the system after upgraded from 13.10 to 14.04" [High,In progress] https://launchpad.net/bugs/1298237 [08:37] hi release team, we have uploaded the ubuntukylin-default-settings for the critical bug: #Bug 1298237, is there anyone who could help to review the package? [08:37] Launchpad bug 1298237 in ubuntukylin-default-settings (Ubuntu) "Cannot login the system after upgraded from 13.10 to 14.04" [High,In progress] https://launchpad.net/bugs/1298237 [08:38] this bug is critical for common users when update from 13.10 to 14.04. We have add ubuntu-session dependency to solve it. [08:48] jibel: hm, that's sad. i will rerun both tests now again and troubleshoot. [08:49] xnox, see my last comment on 1307983 [08:49] the language the g-l-s wants to install is not the right one [09:17] maclin: we are investigating it, no everyone is online yet. we will respin kylin for that, and a few other issues already identified in the defects report (keyring missing, and korean fonts missing) [09:29] maclin: slangasek: archive.ubuntukylin.com:10006 is not signed with ubuntukylin-keyring, hence the bug #1306868 [09:29] Launchpad bug 1306868 in Ubuntu Kylin "使用“sudo apt-get update”命令,报没有公钥" [High,New] https://launchpad.net/bugs/1306868 [09:35] xnox, we are updating the archive by rebuilding packages on launchpad for the keyring bug. [09:35] ypwong, ^ in the queue, up to the release team to review/accept it next [09:36] seb128, thanks a lot [09:36] yw! [09:37] maclin: excellent, that's the right way forward I believe. So no need to change anything on the CD, nor respin. [09:40] xnox, yeap, JackYu is working on it:) [09:44] xnox, you mean the ubuntukylin-default-settings will be reviewed later and we do not need to request rebuild on tracker? [09:44] maclin: please don't trigger the builds, cdimage team will. [09:46] xnox, got it, we just wait for it to test^_^ thanks a lot :) [09:47] + "favicon_url": "www.baidu.com", [09:47] + "suggest_url": "www.baidu.com", [09:48] Is it intended that these are host names, not URLs? [09:48] Or should they be "http://www.baidu.com/" instead? [09:49] ypwong: ^- [10:24] Hello release team! Sorry to repoke regarding the same question - does anyone know by any chance why the appmenu-qt5 upload from yesterday has been rejected? [10:25] sil2100: It introduced a dependency on gtk2, afaik [10:26] Yes - is that a problem? [10:26] Er, yes [10:26] appmenu-qt5 does basically the same that qtbase-opensource-src does right now [10:28] Oh, wow, I hadn't seen the hard dep on libgtk2.0-0 in libqt5gui5 [10:28] qtbase-opensource-src also depends on libgtk2.0-dev, as both are now using the same mechanisms [10:28] I expect there was informative text in the reject message, but unfortunately there doesn't seem to be any way to actually feed that back to the requester in the ci-train case [10:28] yeah, i was porting qt5 to gtk3, but didn't get it all ready. [10:29] cjwatson: i think we can pull it back from rejected. [10:29] Well, not as such, the sync would need to be repeated [10:29] unless we still want to do that thing where we stuff all shlibs into suggests. [10:29] I guess I can re-trigger a publishing from the CITrain side [10:29] (which in this case will work, since even gtk2 will be pulled in by any qt5 app) [10:30] sil2100: hold off a minute [10:30] Ok :) [10:30] * xnox goes to propose that patch to appmenus. [10:30] I can, of course, try using gtk3 instead gtk2 as well [10:31] That was my original plan, but then I noticed the Qt platformplugin that we're trying to emulate uses gtk2 [10:31] sil2100: Incidentally the Suggests in appmenu-qt5 is wrong [10:31] libqt5core5 -> libqt5core5a [10:33] Ah! It seems to be a leftover from the Qt 5.2 transition [10:33] sil2100: no, gtk3 support is not yet available upstream, so you can't use gtk3 with qt yet. [10:34] sil2100: OK, yes, I think we're OK with this - could you retrigger publishing? [10:35] cjwatson: thanks! Let me try doing that [10:35] cjwatson: the same version number will be ok, yes? [10:35] xnox, who cares as long as the dependency is gone :P [10:36] sil2100: Yes [10:36] ogra_: In practice right now libgtk2.0-0 is in all the same tasks as appmenu-qt5, so we shouldn't be blocking on that for trusty [10:37] cjwatson, i wasnt serious [10:39] cjwatson, nice haskell writeup btw :) [10:40] haskhell [10:40] haha [10:40] I've already had one local beer offer as a result, so worth the effort of the blog post ;-) [10:41] cjwatson: didrocks will repeat the sync :) [10:42] here you go ^ [10:52] didrocks: thanks a lot =)! [10:53] yw! [10:56] * cjwatson wonders why ubuntu-kylin-docs is spelled thus rather than ubuntukylin-docs ... oh well [10:56] Thank you cjwatson, xnox, release team! [11:05] OK, so we're definitely respinning everything that contains ubiquity, for the OEM thing === pete-woods is now known as pete-woods-lunch [11:11] We're building another webapps-applications to fix launcher icons being re-added for upgrades, also to do runtime detection of the schemas instead of the dependency. [11:11] Going to upload (copy) it once built, could be SRU or go in as you wish [11:12] We're about to go for lunch here; hopefully infinity will be in in a bit [12:00] do we have release notes drafts up somewhere already? [12:00] (guess desktop/server for now) [12:02] hold on, dbarth is just checking that one [12:05] okay, he says it's fine - accept or not as you see fit [12:23] asac: I guess https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes [12:25] o/ [12:47] meh, upgrade from ubiquity failed, I cannot login :( [12:51] can someone from ceilometer rc3 please? [13:07] zul: looking [13:08] cjwatson: thanks [13:13] I filed bug 1308530, any additional info I can provide? I'll retry without an encrypted home to narrow down the test case. [13:13] Launchpad bug 1308530 in ubiquity (Ubuntu) "Cannot login after an upgrade from Saucy to Trusty with Ubiquity" [Undecided,New] https://launchpad.net/bugs/1308530 === pete-woods-lunch is now known as pete-woods [14:29] infinity, cjwatson, Laney: can one of you pretty please review that one? ^ [14:29] we'll need to respin Edubuntu once it lands [14:30] okay [14:30] is that new code? [14:31] stgraber: Full respin about to happen for ubiquity (again) anyway. [14:31] ah yes https://launchpadlibrarian.net/169438232/edubuntu-live_13.09.2_14.03.1.diff.gz [14:31] Accepted [14:31] Ta. [14:32] stgraber: Want to pre-emptively unblock that? [14:33] infinity: I'll push the unblock yeah [14:33] Laney: thanks [14:33] infinity: what's the ubiquity bug this time? [14:33] I don't think it is blocked [14:33] is it? [14:33] Laney: not sure, checking [14:33] stgraber@castiana:~/data/code/hints-ubuntu$ grep -r edubuntu . [14:33] stgraber@castiana:~/data/code/hints-ubuntu$ [14:33] apparently not [14:34] Oh, cool. [14:34] stgraber: Same bug as last night, different bit. [14:34] ok :) [14:34] (If someone wants to review my kexec-tools, that would be lovely) [14:35] I'll do it [14:37] looks good and doesn't appear to be seeded anywhere, accepted [14:37] stgraber: Ta. === jhodapp is now known as jhodapp|brb === jhodapp|brb is now known as jhodapp [14:56] Alright, switched britney to "block-all source" and unblocked a few things that will block. [14:56] Excplicit unblock required from here on in. [14:57] Exciting [15:00] And one more (should be the last, barring something so release-critical we have to delay the release) respin starting now. [15:01] stgraber: You're far enough down the pipe that your -live should make it in before your build starts. [15:01] infinity: good to hear, Edubuntu takes a while to respin so best not to have to do it twice :) [15:01] jibel: not a regression, I've updated the bug with my analysis [15:02] jibel: entering the same password should work though [15:02] I guess I should test that [15:02] infinity: do we have time to get one more fix in or is that it? [15:02] cjwatson, thanks, I just tried with the same password and indeed it works [15:02] ah good [15:02] Riddell: If it only affects you, maybe. [15:02] infinity: if you do block-all source, should we also stop the auto-approve bot? [15:03] Riddell: But pretty much from here on, unless you find something that literally sets computers on fire, I think we're done. [15:03] stgraber: Nah, letting stuff in proposed is fine. [15:03] A bunch of non-image stuff will still probably be fine as long as it has time to build. [15:04] But we should indeed block it anyway to avoid accidental interlocks with stuff that's on images (especially with touch). [15:04] I'm certainly still removing stuff :) [15:05] hey there [15:05] dustin and I just did a fresh trusty install [15:05] and the dash search is failing to find terminal [15:05] ... [15:05] Wait longer? [15:06] It would be better to talk to desktop people about this [15:07] mhr3 in #ubuntu-unity is the guy for this kind of thing [15:07] cjwatson, who should I talk to? [15:07] I reported a similar bug the other day, so this kind of thing is known [15:07] infinity, it's not a waiting problem, no applications are returned in the query at all [15:07] kiko: I don't know [15:07] duh [15:07] But the release team aren't great people to debug dash problems :) [15:09] ... [15:13] cjwatson, okay, but if this is a verified problem it should be release critical [15:13] infinity: we're good to go once user-manager is in the archive ↑ [15:14] kiko: it does not affect installer, it can go in as a 0-day sru, if there is a fix available. [15:16] Riddell: Ugh. I guess you'll get a respin after the respin. :/ [15:16] I tend to agree with xnox [15:21] xnox, I see [15:22] kiko, it works fine here after a fresh install. If I try 'terminal' or 'spinach' it returns something relatively relevant. [15:23] it doesnt return a terminal for me if i search spinach though [15:23] :) [15:24] Sounds worth release-noting if the dash developers can nail down the conditions a bit more precisely. [15:27] kiko, same here after a fresh install (with network) i have a working dash with three results for terminal [15:28] apw: bug #1307105 [15:29] Launchpad bug 1307105 in linux (Ubuntu) "Kernel install fails due PAE checks" [Low,Triaged] https://launchpad.net/bugs/1307105 [15:37] We're going to need to revert the util-linux Depends: initscripts change from yesterday [15:38] It seems to run into an obscure apt bug and (among other things) breaks an upgrade of a saucy minimal build chroot to trusty [15:38] kiko: also tested fully offline case, and dash finds three terminals. [15:44] xnox, fresh install? [15:44] xnox, i.e. first log in? [15:50] cjwatson: do you have the apt output of the bug? I can have a look [15:50] is there anything to be done about bug 1279762? [15:50] Launchpad bug 1279762 in ubuntu-release-upgrader (Ubuntu) "upgrade to 14.04 from 13.10 failed - cinnamon fails to upgrade" [Medium,Triaged] https://launchpad.net/bugs/1279762 [15:50] mvo: https://launchpad.net/~zfs-native/+archive/staging/+build/5914177/+files/buildlog_ubuntu-trusty-amd64.spl-linux_0.6.2-2.1~trusty~10.gbpedccf5_CHROOTWAIT.txt.gz was the one we got in #launchpad [15:51] mvo: http://paste.ubuntu.com/7262204/ was what I got locally [15:51] (to rule out some problem with the mountall in that PPA) [15:51] * shadeslayer taps fingers while waiting for user-manager to migrate [15:51] cjwatson: uh, nasty [15:51] we think it has something to do with mountall being present in the upgrade set, since builds that don't upgrade mountall don't seem to be failing [15:52] shadeslayer: Don't worry, it'll migrate long before we need to respin anyway. Sorting out an upgrade issue. [15:52] yay [15:52] FYI I'm failing to access bzr from nusakan, this may cause germinate and other things to blow up or at least hang [15:52] (mentioned to IS, waiting for someone to look into it, probably related to an earlier LP problem) [15:52] well, not so yay for other people [15:52] stgraber: still? there was a firewall overload problem a few minutes ago [15:52] cjwatson: yeah, still happening now [15:53] oh hm, so that's what that was [15:53] cjwatson: I'm trying a bzr up of /srv/cdimage.ubuntu.com and it's hanging [15:53] mvo: infinity's going to reintroduce a util-linux -> upstart-job dependency, since that's what was present in earlier releases [15:53] kiko: yes. [15:53] Hopefully that'll perturb things back to sanity ... [15:53] mvo: if that doesn't work then we revert entirely and drop the util-linux -> initscripts dependency [15:53] cjwatson: ok, if you or infinity have a chroot that has the packages that cause the error, I would love to get a tar file of that, I try to build one now fwiw [15:55] xnox, okay, can't reproduce then [15:56] mvo: mk-sbuild saucy should be enough, though mine's an upgraded-for-a-while version - tarring it up [15:56] mvo: be quick before Adam reverts this :) [15:57] bzr is happy again [15:58] cjwatson: heh :) I will simply fake the broken one :) [15:59] mvo: This gets so much more fun. [15:59] mvo: If I depend on "upstart-job" instead of "initscripts", the loop unrolling failure moves about 10 packages later in the upgrade. [15:59] mvo: yay for office bandwidth. http://people.canonical.com/~cjwatson/tmp/saucy-amd64.tar.xz [15:59] mvo: My conclusion here is that util-linux can't ever add dependencies. Ever. [16:00] mvo: set up in schroot, start session, saucy->trusty in sources.list, apt-get update, apt-get dist-upgrade [16:00] infinity: I'm sure it is - I have some quick dinner and see what I can do [16:00] cjwatson: thanks, downloading now [16:05] mvo: I assume it relates to util-linux's deps being transitively essential, and maybe you unroll those loops more carefully or something? [16:16] who needs the link to the Mythbuntu release page? [16:16] tgm4883: see the release notes email on ubuntu-release mailing list [16:16] tgm4883: you have a mythbuntu wiki page which you can update [16:17] infinity: so are we currently respinning stuff or waiting for something else to hit (util-linux?)? I'm asking because I'm not seeing nusakan doing much at the moment [16:17] tgm4883: or add #reload stanza to redirect it to wherever you need it to go. [16:17] xnox, I've got our release statement in a draft on our website [16:17] hmm, #reload stanza... [16:17] tgm4883: e.g. #refresh 0 http://example.com/ [16:18] let me test that, sec [16:18] stgraber: Waiting on util-linux, then going for it. [16:18] tgm4883: reload is for internal wiki, refresh is for external urls. [16:18] stgraber: The world kinda blew up with the network blip anyway. :/ [16:18] infinity: ok [16:22] xnox, awesome, thanks I'll do that [16:22] tgm4883: seems to work correctly. [16:23] Yep, I just need to publish now [16:23] On another note, is there a better way for us to get our ISOs on release day? Basically, I have to wait until Ubuntu releases to download our ISO to our rsync server and then our mirrors have to grab it from us [16:25] Fetch current dailies first and then rsync [16:25] Changes will be either small or nil [16:25] cjwatson, and just rename them to their final name when I download them? [16:26] Yes [16:27] I suppose that's doable, still I'd rather not have the chance that lots of people download an old ISO. Our mirrors are all pulling from us, and they only check for udpates a few times a day [16:28] hey [16:28] infinity, slangasek suggested to ping you for an ETA at which time 14.04 will be released. Are you in a position to give a rough estimate? [16:28] I am trying to coordinate a PPA [16:30] olli_: tomorrow, that's pretty much the best estimate you'll get since we're still in the middle of mass respins for critical bugs [16:30] olli_: What stgraber said. [16:30] :) === maclin__ is now known as maclin [16:39] jamespage: wanna have a look at my comment on bug 1294005? we still just about have time [16:39] Launchpad bug 1294005 in jenkins (Ubuntu) "Please remove jenkins from trusty" [Undecided,Incomplete] https://launchpad.net/bugs/1294005 [16:42] cjwatson, generally anything with *jenkins* in it that's a reverse dependency is really actually part of jenkins [16:42] cjwatson, hey, we have a new unity8 in proposed, can you accept it? bump the version number I think needs to be done for that. (not clear to me what it is about unity8 that requires manual acking each time) [16:43] robru: one moment [16:43] cjwatson, sure, no worries === jhodapp is now known as jhodapp|dogwalk [16:43] robru: it's not about unity8 itself, it's a workaround for a dependency in indicator-something (network I think) [16:44] hmm [16:44] we're lying and saying unity8 is available on all arches to avoid having to tear things out above it [16:44] and I haven't yet got round to generalising that to avoid the version [16:44] ahhhhh its the arch issue again [16:45] anyway, bumped [16:45] cjwatson, thank you [16:46] jamespage: can you ack bug 1265920, since you reviewed the initial packaging? it looks valid to me, just double-checking [16:46] Launchpad bug 1265920 in rds (Ubuntu) "RM: rds -- dead upstream" [Undecided,New] https://launchpad.net/bugs/1265920 === psivaa_ is now known as psivaa [16:47] jamespage: jenkins> mm, yeah, I see that those three packages are in fact circularly build-dependent (whee) [16:47] cjwatson, its been fun :-( [16:48] jamespage: do we actually need to tear out basically everything that matches *jenkins*? that's rather more work :) [16:48] cjwatson, I'd probably just pull jenkins plus those two packages you identitified [16:48] right [16:49] cjwatson, it is possible that someone might step up in Debian to pickup maintaining jenkins [16:49] mkay, so I won't blacklist it [16:49] cjwatson, +1 [16:50] cjwatson, +1 on the rds removal as well [16:50] cjwatson, I'd quite forgotten about that [16:51] jamespage: OK, RIP jenkins packaging [16:51] cjwatson, thanks [16:51] I think [16:52] stgraber, is queuebot off ? [16:52] i see unity8 on the changes ml ... [16:53] it may not have liked the earlier network problem [16:53] :) [16:53] infinity: how long before respin? [16:54] Because I'll probably head home within 15-20 minutes [17:03] shadeslayer: A few seconds. [17:03] oh ok === alex_abreu is now known as alex-abreu [17:12] (Respins happening now, if you find any more bugs from here on, too bad...) === jhodapp|dogwalk is now known as jhodapp [17:16] infinity, would you please review the ubuntukylin-default-settings before respins... [17:18] infinity, we add the ubuntu-kylin-docs uploaded today:) [17:19] I can look [17:20] JackYu: ubuntukylin-default-settings accepted, I trust that it will successfully be published before the respin-the-world reaches ubuntukylin ... and if not, we respin again [17:21] slangasek: it should do, from the current respin order [17:22] slangasek, great, I think it would be, lol [17:22] oh, but that requires an explicit unblock too, better do that [17:35] * shadeslayer is waiting for fresh ISO's :) === roadmr is now known as roadmr_afk [17:47] infinity: Hey, when you start pre-publishing - can you give tgm4883 & myself a ping, so we can get the mythbuntu iso into it's own mirror network? [17:50] cjwatson, slangasek: can one of you remove gcj-4.6? https://bugs.launchpad.net/ubuntu/+source/gcj-4.6/+bug/1276540 [17:50] Launchpad bug 1276540 in gcj-4.6 (Ubuntu) "please remove gcj-4.6 in trusty" [Undecided,Fix released] [17:50] doko: I did [17:51] ouch, didn't hit refresh [17:52] can someone give unity8 some love ? [17:52] ah, ignore that [17:52] * slangasek snuggles up against unity8 [17:54] * slangasek gets bitten [17:54] stgraber: is it intentional that "mark as rebuilding" or similar is no longer available on iso.qa? [17:55] I'd like to be able to mark images as rebuilding even in the case where the rebuild was queued directly on nusakan === psivaa is now known as psivaa-afk [17:57] doko: you might actually manage to get mpclib removable, by the looks of it :) [17:59] cjwatson, yep, still trying =) didn't want to keep 4.7 at all, but anyway ... [17:59] Life's cruel. [17:59] doko: Thanks for fixing gnat-4.8. [18:00] cjwatson: I think the old state and behaviour is now called disabled [18:00] cjwatson: in that mode, the build still exists and can be accessed but result reporting is disabled until a new build is published [18:04] * balloons listens to cjwatson and stgraber about marking builds [18:08] stgraber: ok, so if I did "Mark as disabled (prevents result reporting)" on a bunch of builds, that would be fine? [18:09] yep [18:09] ok, cool, thanks [18:09] stgraber, hmm, so i seem to not be able to trigger a touch rebuild via the UI [18:10] at least it doesnt say "currently building" next to the images [18:14] ogra_: ok, just finished fixing a small glitch in the upgrade path of the stable channel, now looking at the tracker [18:14] ogra_: is it fine if I do end up triggering both of the touch builds? [18:14] yep [18:16] stgraber: do you have information about the mass respin? [18:16] infinity: ^^ [18:16] * utlemming tries to figure out if cloud images need re-generating [18:17] utlemming: maas... Respin? [18:17] heh [18:17] utlemming: There's no new maas other than the one that got in yesterday. [18:17] infinity: ah, do you have the bug link? [18:17] infinity: I meant s/maas/mass [18:17] utlemming: Oh, I can't read. [18:17] LA LA LA> [18:17] * ogra_ hands infinity some window cleaner [18:18] ogra_: not seeing any trace of your rebuild request, however when I selected both here and clicked rebuild, I see it queued as expected [18:18] i thought you were joking :) [18:18] utlemming, maas shoul dhave no affect on cloud images. [18:18] utlemming: Yes, you want to regen your cloud images to match current binaries. [18:18] smoser: I can't read. He said mass. [18:18] stgraber, i selected the top checkbox, both rows turned yellow (never had that before) [18:18] util-linux is definitely on cloud images. :-) [18:18] stgraber, and then i just clicked "update rebuild status" [18:19] cjwatson: ack, thanks [18:19] ogra_: same i did here, expected it worked for me :) [18:19] and it returned [18:19] yes, util linux is in cloud image. [18:19] hmm, weird [18:19] as long as it works for others :) i can fall back to nusakan worst case :) [18:20] * utlemming starts re-spinning [18:20] ogra_: not seeing anything from you in the log either. You may want to logout and login again in case it was your SSO creds failing somehow. [18:21] i opened the page afresh ... and got auto logged in [18:21] hmm [18:21] we'll know the next time i try :) [18:22] ogra_: this morning I noticed that the ACLs were wrong and apparently xubuntu was the team with access to the touch build (go figure), so I fixed that but you need to make sure your membership in the touch release team is passed through SSO (you need to tick a box in there) if you want to have access [18:22] ah, k [18:22] i'll make sure to re-login before the next build then === roadmr_afk is now known as roadmr [18:26] infinity: you mean you didn't trigger the mass respin with 'juju respin'? [18:27] doko: did you see that your gcc-4.7-armel-cross upload FTBFS? [18:27] * stgraber grabs Edubuntu [18:43] slangasek, yes, fixed the wrong branch [18:43] * doko would like to do some python work today too ... [18:46] infinity: can you mark the Cloud Images as superceeded, they are being rebuilt and tested now [18:47] utlemming: [18:47] utlemming: Yup. [19:09] cjwatson, infinity: fwiw, bug #1308654 has the needed bits to reproduce the failure, I look into it next (probably in the morning, its getting late here) [19:09] Launchpad bug 1308654 in apt (Ubuntu) "configure order broken for util-linux in saucy->trusty" [Undecided,New] https://launchpad.net/bugs/1308654 [19:10] cool, thanks. there's no huge rush right now [19:10] cjwatson: thanks, good to know [19:10] xnox, wrt. i18n issue in OEM mode, with 16.1, German is proposed for installation in "system settings -> language support" and first on the list, but there is no notification if you don't open language support. [19:11] mvo: Yeah, we backed out the problematic change, but I figure this points to a reasonably nasty bug we want fixed Soon(tm), but not for release. [19:12] infinity: indeed! [19:23] xnox, even after a reboot, no notification to install the missing lang packs [19:43] hey guys, can somebody accept unity-firefox-extension? it's an important (and small) bugfix requested by seb. [19:43] I can accept it, but it isn't going into the trusty release pocket at this point [19:43] it'll have to be updates [19:43] (because we don't have any more respin slots) [19:43] well, not unless somebody discovers that our images burn computers [19:43] om nom nom [19:44] cjwatson, i'm ok with -updates, thanks [19:45] robru: You're aware that there's a release in less than 24h, I assume. ;) [19:45] infinity, yes, that's why it's just a small bugfix ;-) [19:45] it can go to -updates though once it's built [19:45] (I agreed this with dbarth and it's on the whiteboard here) [19:45] robru: Size doesn't matter, it's about respinning and testing images (which we won't do at this point, except for bugs that actually literally violate your mother). [19:45] infinity, oh btw, we're landing some new features in unity7, can you accept those? ;-) [19:46] robru: But yeah, it could go to -updates as a 0-day SRU. [19:46] ah ok [20:15] so, I'm curious what langpacks we have on the images atm, and wondering why we didn't add back german and french for instance when we stopped caring about image size [20:16] look at the manifests [20:16] we do care about image size a bit - somebody reported earlier today that we don't fit on a 1gb usb stick any more, which I think is unfortunate and would have tried to fix it if we had time [20:16] bandwidth isn't unlimited and the bigger the image is the harder it is for people to download it === Ursinha is now known as Ursinha-afk [20:46] cjwatson, infinity, slangasek, stgraber: so for opening the u-series, there won't be many changes from my side (and I'll only be back on Tuesday morning, Fri and Mon bank holidays). [20:46] new binutils would be the only toolchain change [20:47] would be nice if we could open with the same ruby defaults as in debian [20:48] Guys just stumbled across bug 1308752 if you do an oem install in one keyboard layout then a user install of a different layout for some unknown reason the initial login for the user fails, reboot the system then you can login [20:48] Launchpad bug 1308752 in ubiquity (Ubuntu) "Oem install Login fails on first reboot to user when different keyboard layouts are used" [Undecided,New] https://launchpad.net/bugs/1308752 === Ursinha-afk is now known as Ursinha [20:54] I just realized I've missed an old bug and found a new one. [20:54] Updated seeds for Ubuntu Studio [20:55] We would like an update to ubuntustudio-meta [20:55] Bug 1308755 [20:55] Launchpad bug 1308755 in Ubuntu Studio "Two power manager applets in Trusty release" [Undecided,New] https://launchpad.net/bugs/1308755 [20:55] and Bug 1284635 [20:55] Launchpad bug 1284635 in ibus (Ubuntu Trusty) "ibus does not support certain keyboard layouts" [High,Triaged] https://launchpad.net/bugs/1284635 [20:57] infinity: There has been some discussions about the packaging of lmms, but doesn't seem like that has been taken care of, so I doubt that will happen before release. Thanks for your help on that though [20:58] zequence: Kay, lmms can be SRUed. But you need some meta changes? [20:59] infinity: Yeah. Think that should be all (holding my breath) === Ursinha is now known as Ursinha-afk === psivaa-afk is now known as psivaa [21:05] zequence: http://paste.ubuntu.com/7263797/ <-- That look sane? [21:07] infinity: Yep. that looks right [21:07] zequence: Why is the response to an ibus bug to remove it? :P [21:08] infinity, because the bug can't be fixed in time [21:08] knome: Kay. [21:08] infinity, ...and it's a nasty one, not letting you use your own keyboard layout [21:08] infinity, that's what xubuntu did - bail out since it doesn't work [21:09] there is a workaround, but it's not something that is (easily) describable in the release notes, and not something most people would like to do [21:09] most people do not need ibus anyway [21:09] zequence: Uploaded. [21:09] infinity: Thanks! [21:09] and the bug is actually mostly/only affecting those who *don't* use ibus... [21:09] zequence: Might not make it in the current spin set, but if it doesn't, we can just respin again. [21:10] infinity: Yep. I'll be going to sleep soon. But, will have plenty of time to do tests tomorrow (in less than 12h from now) [21:10] zequence: Alrighty. === Ursinha-afk is now known as Ursinha [21:57] cjwatson, infinity: please update the version in the gcc-4.7-armel-cross unblock request [22:01] doko: Already done. [22:01] and for u I get rid off the arm multilibs ... [22:02] doko: A bash merge in the queue? Really? [22:03] doko: I assume that's intended to be an SRU and the bug needs to be updated accordingly? [22:05] speaking of SRUs - infinity how do you feel about a rapid release of whoopsie for bug 1306175? [22:05] Launchpad bug 1306175 in whoopsie (Ubuntu Saucy) "whoopsie should not send some data to daisy" [High,Fix committed] https://launchpad.net/bugs/1306175 [22:11] bdmurray: I'll have an opinion in a sec. [22:11] zequence: Kay, we can respin your images right now. Doing. [22:34] infinity, it's targeted for trusty-proposed [22:35] doko: Well, yes... [22:35] doko: As all uploads are. [22:35] sure, I can re-upload later [22:36] doko: Nah, just convert your bug to an SRU bug with justification, etc. [22:40] infinity, well is fixing a crash a justification? [22:41] doko: Regression potential, etc. But yes, fixing a crash is fine justification. === jhodapp is now known as jhodapp|afk [23:18] infinity: we're probably a good 4 hours off before the Cloud Image respin completes. I'm going to step away while this churns. [23:18] utlemming: Alrighty. [23:18] infinity: I'll have testing done shortly after that. [23:18] utlemming: Turns out we have a hilariously critical desktop bug that's forcing respins anyway, so you win. [23:18] infinity, did you catch my comment about the release notes? [23:19] knome: Probably not. [23:19] infinity, summary: i think we should continue with what we have now, that is, flavors separated; they seem to have ridiculously different ways to do release notes [23:19] some do not list bugs, some do not list new features [23:19] knome: Yeah, I agree. [23:19] and some use large screenshots [23:20] knome: Normalized URLs need to happen though. But that's not hard. [23:20] so that being said, should we purge the multiple flavor subheadings from the release notes, and add some other kind of links for them? [23:20] knome: Linking would be nice, yes. [23:20] ...and that being said, does server count as a flavor, or should it stay on the main page? [23:21] knome: We (Canonical) don't consider it a flavour, so much as just the slightly less graphical Ubuntu. :P [23:22] ok, i'll work on something with that idea in mind [23:22] i'll do it now, so if you are around, i'll ping you in maybe 5-10mins [23:25] evening, is there another mass respin in progress? [23:25] apparently [23:29] infinity: should I test kubuntu images or are new ones going to appear? [23:31] infinity: "we have a hilariously critical desktop bug that's forcing respins anyway", care to share? is that the OEM bug? [23:33] Riddell: Kubuntu is fine, the but I'm talking about it all Unity. [23:33] Riddell: Your images should be final (I hope). [23:33] s/but/bug/ [23:33] ok thanks, time to test! [23:33] infinity, cjwatson: mpclib should be removable now, https://bugs.launchpad.net/ubuntu/+source/mpclib/+bug/1255062 [23:33] Launchpad bug 1255062 in mpclib (Ubuntu) "please remove mpclib, replaced by mpclib3" [Undecided,Incomplete] [23:33] doko: \o/ [23:36] oh, I guess the bug is bug 1308572 (looking at other channel activity since it wasn't listed here nor on the iso tracker...) [23:36] Launchpad bug 1308572 in unity (Ubuntu) "Ubuntu 14.04: security problem in the lock screen" [Critical,In progress] https://launchpad.net/bugs/1308572 [23:37] infinity, https://wiki.ubuntu.com/PasiLallinaho/TrustyReleaseNotesDraft [23:39] knome: I'm going to lose that in backscroll when I sleep. [23:39] infinity, then don't sleep but look at it now ;) [23:39] knome: Can you move your notes to wiki/TrustyTahr/ReleaseNotes/$flavour? [23:40] knome: Oh, that's for the Ubuntu page. [23:40] yep [23:40] and the content is old [23:40] knome: Yeah, that looks sane (I assume you mean the flavours section). [23:40] well, everything really [23:41] but it's not changed much except the flavors section, some headings made smaller (=== instead of ==), and limiting the TOC to 2 levels [23:41] infinity, re: flavor notes, our are at https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes/Xubuntu [23:42] and if we use the new layout, i'm much more happy to link directly to the main page for the known issues... [23:42] (instead of including) [23:43] knome: Yeah, seems sane to me. [23:43] ok, i'll drop it to the main page with (r=infinity) [23:44] :P [23:52] infinity, the page is updated. [23:52] knome: Ta. [23:53] and please at least take a little glance so it's still sane... [23:53] knome: Thanks a lot for helping out with notes, BTW. My least favourite part of release. [23:53] knome: I'll look in the morning. ;) [23:53] i handle bureaucracy enough with xubuntu stuff, i guess it doesn't really hurt to do a little bit more... [23:55] knome: It's greatly appreciated. [23:56] glad i can help :) [23:56] * knome likes squatting messy things, even if it meant frustration and headache, as long as it's clean after...