[00:15] how much space should be available for /boot fs in saucy? i have 175MiB [00:16] but i'm getting http://askubuntu.com/questions/298487/not-enough-free-disk-space .. and ihave only 1 kernel installed [00:16] bjv: my /boot currently occupies 207 megabytes, but you might do a better job cleaning out old kernels than I do. [00:21] debfx: Do you want me to (attampt) to merge cdbs or are you going to do that? [00:31] Noskcaj_: is there a bugfix in cdbs that you need? otherwise it's kinda late in the release cycle for that [00:32] jbicha: It's blocking things in -proposed. [00:33] last night cjwatson asked debfx to merge it, i've got nothing to do so i was going to try and help with it [00:34] oh ok [00:43] c [01:21] can someone on the release team have a look at https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1223342 please [01:21] Launchpad bug 1223342 in neutron (Ubuntu) "[FFE] neutron-vpn-agent and neutron-metering-agent" [Undecided,New] [01:42] I just submitted some patches to the distro specific scripts in cryptsetup. It appears as though these are mostly maintained by debian, with perhaps a few modifications by ubuntu. What's the best way to get the patches accepted? Through debian or ubuntu? [02:08] crass: If your fixes aren't Ubuntu-specific, a bug filed in Debian is more generally helpful to all. [02:12] infinity: hey [02:13] infinity: could it be that proposed is off? [02:13] for maintenance work? [02:13] * asac impatient and scared :) [02:13] asac: We're adding arm64 to the archive, everything's temporarily off. [02:13] asac: Shouldn't be much longer at all. [02:14] infinity: what does it mean? [02:14] in time? [02:14] asac: About 30 seconds. [02:14] nice!! [02:14] 30 [02:14] 29 [02:14] :) [02:15] infinity: i will check in 3 minutes ... let meknow if there are any problems [02:15] Well, the next publisher run triggers at 10:18, but close enough. We're re-enabling the world now. [02:15] * asac happy [02:15] we just managed to get unity and stuf fin shape [02:15] were eagerly reloading exuses :) [02:15] * asac goes for a smoke : [02:21] infinity: all going well? [02:22] asac: iz doing publishy tings. [02:22] sounds like its doing the right thing to me [02:23] You just like French accents. [02:24] speaking of French… ;) [02:25] infinity: https://launchpad.net/ubuntu/+source/unity-system-compositor/0.0.1+13.10.20130903-0ubuntu2, I'm surprised this one is building while https://launchpad.net/ubuntu/+source/unity8 isn't even in proposed. Source publishing (or whatever it is) is working differently? [02:25] didrocks: We don't need to publish source to build. [02:26] didrocks: Builds begin as soon as a package is uploaded. [02:26] ah ok, and so binary copy just need a "publish" to appear in proposed I guess [02:27] Indeed. [02:27] great, unity8 now in [02:27] seems like pinging infinity gives hint to the publisher, I should try that more often :) [02:27] *smirk* [02:27] Well, we don't shut off the world and add new architectures very often. [02:28] yeah, it's just that murphy's law loves us ;) [02:29] Nah, this isn't murphy, it's just a group of people who are always impatient. :) [02:29] speaking of being impatient… [02:29] any way to bump priority on https://launchpad.net/ubuntu/+source/unity-system-compositor/0.0.1+13.10.20130903-0ubuntu2/+build/4953829 if possible? [02:30] didrocks: That high enough for you? [02:30] infinity: as long as we don't have buffer overflow, it's high enough to me ;) thanks! [02:31] 5 i386 builders sounds pretty low [02:32] asac: 5 i386 distro buildds, yes. [02:33] There's a whole bunch more for PPAs [02:33] StevenK: are those 5 bare metal machines? [02:33] or 5 VMs on 2 machines? [02:33] asac: Yes [02:33] asac: All of the distro buildds are bare-metal [02:33] StevenK: how are we doing sizing of the builder pool? [02:34] e.g. how do we get to the number of 5? [02:34] I'm not sure how that number was arrived at [02:42] infinity: any idea why mir is a valida candidate and is not going in since 6 days? [02:42] on excuses? [02:43] asac: You want _output [02:43] Trying easy from autohinter: mir/0.0.10+13.10.20130904-0ubuntu1 unity-mir/0.1+13.10.20130904.1-0ubuntu1 platform-api/0.18.3+13.10.20130904-0ubuntu1 [02:44] leading: mir,unity-mir,platform-api [02:44] start: 181+0: i-86:a-32:a-29:p-34 [02:44] orig: 181+0: i-86:a-32:a-29:p-34 [02:44] easy: 184+0: i-87:a-33:a-30:p-34 [02:44] * i386: unity-system-compositor, unity-system-compositor-autopilot [02:44] * amd64: unity-system-compositor [02:44] * armhf: unity-system-compositor [02:44] ie: updating that package set makes unity-system-compositor and unity-system-compositor-autopilot uninstallible. [02:44] hence my recent upload [02:45] infinity: ok, guess a feature missing that excuses cannot give human readable reasons for all cases yet? [02:45] asac: No, excuses and output are two phases in the process. [02:46] Poorly named, perhaps, blame ajt, but they represent two distinct sets of steps. [02:46] output is not really easy to parse [02:46] but ok [02:46] It's not terribly human-friendly. That could be improved by someone who likes writing pretty frontends. [02:46] I'd be happy to teach them how to read it if they wanted to. [02:47] hmm. think having one page that has all the exceuses and reasons that make stuff stuck would be awesome [02:47] but later [02:47] thanks [02:48] I think having one page that's essentially packages.qa.debian.org with little portlets and some friendly info would be nice. [02:48] But, yes, not tonight. :) [02:48] :) [02:48] the night is long :) [02:48] It's been long enough. [02:48] And I'm still working. :P [02:48] So. Nah, the night can suck it. [02:48] infinity: are you in the room? [02:48] asac: Yeah, I'm upstairs. [02:48] we are in the breakfast area if you want fun :) [02:48] lol [02:49] Define "fun". [02:49] Does it involve alcohol? [02:49] infinity: we have plenty [02:49] infinity: yeah... i can allocate more :) [02:49] Cause if this is a way to sucker me into working even more tonight, I'm not biting. [02:49] 5 bottles ready [02:50] infinity: no we just wait for the stuff to enter archive so we can kick image and punch dashboard to green or red for the unity folks [02:50] and have fun :) [02:50] * didrocks refreshes update_excuses to desperatly wait for unity8, unity-mir (latest), unity-api and unity-system-compositor to show [02:51] infinity: i cant guarantee, because ogra_'s keycard is very flalki [02:51] i have to try if i get in his room agian where my beer is [02:51] last time it took 10 attempts [02:51] so let me try that first [02:51] didrocks: This publisher run is a bit longer than usual, we may have upset some postgres index caches a little bit or some such. It's moving along. [02:52] infinity: there is also some pizza here :) [02:52] ok, I hope we won't discover a bad situation and everything will move along ;) [02:52] I already ate. But the beer's appealing. [02:52] seems asac is a good salesman ;) === salem_ is now known as _salem === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying [06:51] good morning [07:49] pitti: re:swap, swap is created and activated during partitioning, whilst plugininstall.py is called much later by ubiquity. Automatically updating UUID in "resume" is probably something we ought to do. From /etc/fstab or by parsing /proc/swaps ? === freeflying is now known as freeflying_away [08:48] ok lts-saucy copied to ppa:ubuntu-x-swat/s-lts-backport -- enjoy! [08:56] what does yellow mean on jenkins? [08:56] I've seen blue and red, but not yellow... [09:01] Laney: unstable [09:01] (either unknown if passed/failed, or uncertain, or flapping) [09:02] https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-firefox/ === freeflying_away is now known as freeflying [09:03] xnox, did you see my latest batch of ubiquity changes? are you ok with these? [09:28] slangasek, latest mountall caused a regression for me (bug 1223745) [09:28] bug 1223745 in mountall (Ubuntu) "Dependency resolver causes hang on boot" [Undecided,New] https://launchpad.net/bugs/1223745 [09:28] apw, FYI, did file it ^ [09:41] xnox: I thought we *did* update the UUID in initramfs-tools resume configuration ... [09:55] cjwatson: i just reformatted my swap, such that it has new UUID and I had to manually edit /etc/initramfs-tools/conf.d/resume. After I did that, updated initramfs, it then got new UUID in conf/conf.d/resume. [09:56] cjwatson: so the /etc/initramfs-tools/conf.d/resume file is not auto-magically-updated. [09:56] hence pitti pointing at bug 50437 [09:57] bug 50437 in initramfs-tools (Ubuntu) "Resume from hibernation may fail because swap partition UUID does not match /etc/initramfs-tools/conf.d/resume" [Medium,Triaged] https://launchpad.net/bugs/50437 [09:57] xnox: I'm not claiming it works, but I'm fairly sure there's code for it :) [09:57] xnox: Oh, in the installer, I mean. Not if you fiddle with things live, sure. [09:57] Hardish problem ... [09:59] cjwatson: well... so after reformatting swap i need to: edit /etc/fstab, edit /etc/initramfs-tools/conf.d/resume, update-initramfs. Not sure why one should repeat oneself with a common case of a single swap partition/file. [10:01] zul: can you please forward your changes to debian ... [10:01] or at least stop messing with packages I care about ._. [10:01] d2to1 this time [10:02] xnox: Sure, it certainly isn't ideal [10:04] xnox, i wonder if we should be recommending setting a UUID when changing swap to simplify things (with --uid ) [10:07] * apw notes he is getting a chromium-browser against chromium-browser-l10n file collision on remoting_locales/th.pak ... known ? [10:07] (on upgrade on saucy) [10:08] apw: bug 1223696 [10:08] bug 1223696 in chromium-browser (Ubuntu) "package chromium-browser-l10n 29.0.1547.65-0ubuntu1 failed to install/upgrade: tentata sovrascrittura di "/usr/lib/chromium-browser/remoting_locales/th.pak" presente anche nel pacchetto chromium-browser 28.0.1500.71-0ubuntu3" [Undecided,New] https://launchpad.net/bugs/1223696 [10:08] cjwatson, thanks [10:21] cjwatson, apw: bug #1222488, qengho said he would have an update ready yesterday but I didn't see it :/ (the current version is quite buggy, it's missing most for the UI components for some users) [10:21] bug 1222488 in chromium-browser (Ubuntu) "package chromium-browser-l10n 28.0.1500.71-0ubuntu3 failed to install/upgrade: trying to overwrite '/usr/lib/chromium-browser/remoting_locales/th.pak', which is also in package chromium-browser 28.0.1500.71-0ubuntu3" [High,Triaged] https://launchpad.net/bugs/1222488 [10:22] seb128, thanks, one of those two are a dup [10:22] apw, I dupped the new one, since the other one was already assigned/used for tracking [10:23] * xnox uses google-chrome [10:23] xnox, freedom hater [10:24] seb128: security cautious === MacSlow is now known as MacSlow|lunch [10:50] xnox: hm, I wonder why the config file is wrong in so many cases then [10:51] pitti: yeah, strange.... it parses /proc/swaps, maybe we fail to activate the just formatted swap? [10:52] dunno, nonetheless it would be nicer to not have to hard-code the one and only swap partition in two places (/etc/fstab & conf.d/resume) [10:52] xnox: I think the least we should do is to have update-initramfs hook check whether that UUID actually exist, and only if it does copy it into the initramfs [10:53] that would still not unbreak hibernation, but at least fix the boot speed delay [10:55] ack. Yeah, a simple test [ -e /dev/disk/by-uuid/...... ] should do it. [10:56] xnox: ah, seems the Debian maintainer already cared about the first step [10:57] pitti: we just need to "merge" initramfs-tools right..... (we have a cherry-pick Frankenstein at the moment) [10:58] .... or cherry-pick again =) [10:58] oooooh [10:58] xnox: initramfs-tools preinst -> that sounds like it would put the buildd's swap UUID into "resume"? [10:59] that might explain where that mysterious UUID comes from [10:59] that would be sad, let me unpack the cd. [10:59] * pitti reads the last three commits in http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/maks/swap [11:00] /var/lib/dpkg/info/initramfs-tools.preinst does that if not in a chroot; but maybe that logic fails there [11:00] pitti: there is no conf.d/resume on the images. [11:01] as I said I'm fairly sure that we nuke conf.d/resume in the installer, and possibly also in livefs building === gusch is now known as gusch|lunch [11:03] ubiquity/scripts/plugininstall.py:Install.configure_hardware for instance [11:04] similar thing in base-installer for d-i [11:05] pitti: in the new commits: if resume file not there, or bogus UUID is specified, then it goes to regenerate the file using the first swap available. So this means one cannot disable resume partition, unless in a chroot. [11:07] not sure if that actually matters at all, tbh. [11:08] xnox: ah, good point; mentioned in my bug reply [11:11] xnox: still, I don't believe that jibel messed with his swap partition manually; I can understand the mismatch on my system as I'm using cryptswap (I guess that's regenerated on every boot or so?), but he doesn't even have that [11:11] I'll do a test install later on when I'm in the office; need to disappear for a bit for breakfast and bus, bbl [11:11] xnox: thanks! [11:12] pitti: yeap cryptswap is random initialised. But normal full-disk encrypt should still work (as swap is static/same, on lvm volume part of the encrypted VG) === freeflying is now known as freeflying_away === freeflying_away is now known as freeflying === doko_ is now known as doko === MacSlow|lunch is now known as MacSlow === _salem is now known as salem_ === dholbach_ is now known as dholbach [13:11] cjwatson, thanks for merging === kentb-out is now known as kentb [13:25] infinity, hey [13:26] seb128: 'sup? [13:26] infinity, do you know if/how we can get https://bugs.launchpad.net/langpack-o-matic/+bug/1201485 on the priority list of somebody? (needs a bit of launchpad work) [13:26] Launchpad bug 1201485 in Ubuntu Translations "Need to import translations for the unity daily builds" [High,Triaged] [13:26] seb128: Oh hey, I even have an open firefox tab for that. [13:26] wgrant: ^ [13:26] infinity, without it we are increasing our untranslated strings in all the components in daily landing (e.g unity, indicators, touch) [13:26] wgrant: Any bright ideas? [13:27] wgrant: If we're losing and/or failing to import translations tarballs from copies, that seems suboptimal. [13:27] wgrant: (Or, I guess, throwing them away for PPA builds, thus not having them available on copy) [13:28] infinity, http://irclogs.ubuntu.com/2013/09/02/%23ubuntu-devel.html#t09:25 [13:28] infinity, that was discussed a bit there by wgrant/cjwatson [13:28] hey. i'm looking at generating a list of packages that are needed for build and runtime depends of a cloud image. [13:28] infinity, I've added that link to the bug report for reference [13:29] as cloud-image is a seed, that seems to make sense getting data from [13:29] http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/ [13:29] but the lists produced there are not complete. (when compared to the actual contents http://cloud-images.ubuntu.com/saucy/current/saucy-server-cloudimg-amd64.manifest). [13:30] i know that some things are done in the build process (installing kernel for example). [13:30] smoser: They'd be complete if you add up all the seed outputs for everything that cloud depends on in STRUCTURE. One would hope. [13:30] i think thats what i was missing. [13:30] i didn't know how cloud-image depended on anything. [13:31] seb128: I'll see if we can find some time for it. Not sure yet what sort of timeline we can guarantee until I've talked it over with William/Steven. [13:31] sturcutre is hand maintained ? where does that come from ? [13:32] smoser: It's in the seed bzr repo. [13:32] infinity, thanks [13:32] ah. i see. in the seeds yeah. [13:32] thanks. [13:32] infinity, our plan B/workaround is to manually checkout those component, update the template manually and upload to launchpad [13:32] infinity, but playing catching with any string change at this game on an hundred components is a bit of madness [13:32] smoser: Gets even more fun when you realise there are seed cross-deps, so that "standard" dep is coming from platform.saucy. [13:33] seb128: That might be your best short-term workaround, but clearly not the ideal going forward, I agree. [13:33] infinity, right, I know, I've been doing that since raring :p [13:33] seb128: If something's wildly out of sync with reality right now, though, that's probably worth a one-shot upload of a few bits. :/ [13:33] infinity, I'm fine doing it again before saucy, but please get it fixed ;-) [13:34] seb128: Yeahp, it's a fundamental flaw, IMO, if we're not copying *all* custom uploads on PPA->PRIMARY copies. [13:34] infinity, well, no need of uploads, you can upload a pot manually to launchpad, I've been doing that for unity/indicators when I see missing strings [13:34] seb128: Translations should just fall out from making sure that's true. [13:34] right [13:35] infinity, is there something that can parse that for me? or i just do it myself. [13:35] smoser: germinate [13:35] :) [13:35] thanks [13:35] infinity: As I said earlier, it should be fairly easy to do in the custom upload copier. [13:36] cjwatson: Sure, assuming we actually still have those custom uploads in the PPAs (I hope the answer is yes?) [13:36] smoser: You can use the Python germinate.seeds module [13:36] If you don't want to run the whole thing [13:37] cjwatson, thanks. mainly i just wanted to use what output there was, but resolve all the deps of cloud-image. [13:37] infinity: It should still be attached to the PackageUpload [13:38] I can't imagine we're going through and deleting those. Would be very unLaunchpaddish. [13:38] cjwatson: That's what I was hoping. So, yeah, one would think this shouldn't be hard to fix at all. And should just be fixed for all custom uploads. [13:38] infinity: It's already fixed for all custom uploads apart from translations. [13:38] Because translations were already weird. [13:38] cjwatson: Certainly works correctly already for EFI (as proven by the kernel SRU process). [13:39] cjwatson: Ahh. Yay, weird. [13:40] infinity: I'd suggest moving PackageUploadCustom.publishRosettaTranslations into a module in lp.archivepublisher (see the way it works for most of the other custom upload types), flipping the switch in CustomUploadsCopier.copyable_types, and then doing whatever other minor tweaks are necessary as revealed by tests. [13:40] * infinity dumps that in the bug. [13:40] (Moving most of the contents of that method, I mean, not the method itself.) [13:42] As it stands it'd wind up doing a bit of unnecessary work to write the translations LFA out to disk. But that'd be easy enough to fix with an extra kwarg to _publishCustom. [13:42] infinity: Are you volunteering? :-) [13:43] cjwatson: Not necessarily, just trying to scope it currently. [14:04] seb128: ooh, I got a proper retracer failure mail now [14:05] * pitti looks and fixes [14:05] pitti, \o/ [14:06] hm, the usual "HTTP Error 503: Service Unavailable" again [14:06] but with notifications working we at least won't have long downtimes any more [14:07] right [14:07] pitti, I wonder if we could just catch the error for those and not stop the retracers [14:07] seb128: it's actually supposed to doing that in many cases ("transient error") [14:08] it doesn't do it for that 503 though? [14:39] cjwatson, hey. before i go and try to do this, is there a way to "flatten" cloud-image.* at http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.saucy/ ? === freeflying is now known as freeflying_away [14:39] by flatten i just mean resolve all task dependencies. for build-depends, build-sources, .depends [14:41] smoser: Well, you could look at what Launchpad does [14:41] smoser: lib/lp/archivepublisher/scripts/generate_extra_overrides.py [14:41] There's nothing canned [14:42] smoser: But, er, isn't cloud-image already a task? You can get the runtime deps out of the Packages file [14:43] well, not flattened. right? [14:43] and i also want build deps [14:44] where is lib/lp/archivepublisher/scripts/generate_extra_overrides.py ? what branch/package? [14:44] How do you mean, not flattened? Fully expanded? [14:44] lp:launchpad [14:44] And fully expanded with respect to what? You generally don't want to do a *full* expansion, only up to some interior seed. [14:45] It would help if I had some idea of what you were actually trying to do. [14:45] (But briefly!) === 3JTAAEL6B is now known as tvoss [14:48] i want a list of all packages required to build cloud-image seed. [14:48] and all packages that are installed by cloud-image seed. [14:49] and why would i not want to do a "full expansion"? === jono is now known as Guest91193 [14:52] smoser: Because most things that actually do this in practice are installing them on top of a debootstrapped image and thus only want to expand relative to minimal (say) [14:53] Also because a full expansion is ridiculously enormous [14:54] Even just the recursive (build-)depends expansion of required pulls in chunks of GNOME, KDE, Mono, ... [14:54] We need to know this to keep main self-contained, but it isn't useful for most other practical purposes [14:55] cjwatson, i'm clearly missing something. [14:55] the end goal is to get a list of packages that have to build in order to produce a given seed ('cloud-image'). [14:56] Well you can do that but I have no idea why. [14:56] That's not so much a reason as a deliverable. [14:57] well if i want to produce alist of what is necessary to reach said deliverable. [14:57] But why? [14:57] [14:57] I mean, practically all of it is already done, unless this is for a new architecture [14:57] (In which case perhaps you could say so) [14:58] :) [14:58] that is exactly it. and i was typing 'architecture' as you hit return. [14:58] So you can cat all the files together if you like. I wouldn't bother building a tool for it if I were you. [14:59] Just extract the seed list and pick out whichever field you want from all the files ... it's not something that's needed very often at all [14:59] smoser: hrm, infinity didn't already do this analysis? [14:59] That said, this is basically a textbook example of useless data generated to satisfy a statement of work [15:00] Very little of the output is actually going to be required to reach the goal, and the data doesn't necessarily continue to represent what needs to be done [15:00] Since the dependency expansions might change between now and completion [15:00] agreed that a one time static list isn't terribly useful. [15:00] So it's pointless work - the goal is "get to the cloud-image seed", not "build all these packages which might not all end up being necessary for that" [15:01] Far easier to just build everything that will autobuild and then worry about what's left [15:01] i dont undersand "which might not all end up being necessary for that" [15:02] of course they're necessary or they would not be build-depends [15:02] They might not REMAIN build-depends [15:02] They're necessary NOW [15:02] But they might be removable without compromising the goal [15:03] Anyway, if you need to do it because of $commercials, that's fine, I just wouldn't care that much about how elegant the tool you use to get there is [15:03] Just scrape it all out of the obvious places and move on :) [15:04] But what I want to avoid is a customer saying that you haven't met your goal because you didn't build one of those intermediate packages, that ended up being removed because it was avoidable [15:04] So just be careful about how you present full expansions like that [15:08] "i want seed X" is the end goal. the intermediate "well, you'll need this list of packages to get there" is what i'm after. [15:09] smoser: right and the full expansion will be very arch specific and many packages are different across i386/amd64/armhf etc. Thus you do want something like - equivalent of ubuntu-core, kernel, bootloader, and the rest of the expansion. [15:09] (excluding the previously mentioned items) [15:15] For a new architecture you just have to pick the most similar architecture and cat together the relevant bits of all the output files in the expansion of whichever seed you want in the structure file. As I say it's doable in a shell pipeline and I don't think it's worth a tool, given that it comes up rarely and there are generally slight variations each time it does come up. [15:29] smb: followed up to the bug; would like some more info from your system before I start trying to assemble a reproducer locally === tkamppeter_ is now known as tkamppeter [16:06] hm [16:06] grub2 broke?: grub-probe: error: failed to get canonical path of . [16:07] cjwatson: ^^ [16:08] dupondje: don't run -proposed [16:08] hmm, haven't we said this before ;) [16:08] A few times. [16:08] dupondje: I blocked it in -proposed quite deliberately and am currently fixing that bug. You only encountered it because you went against recommendations and used -proposed :) [16:09] infinity: I meant to dupondje specifically :) [16:12] I know :) Just wanted to let it know :) [16:12] seb128, pitti: hurray, failure emails! [16:12] I'd noticed myself already but thanks [16:13] slangasek, ;-) [16:13] slangasek: indeed; I restarted them timely now [16:22] jodh: hey, so test-quiesce-cleanup [16:23] jodh: I still haven't had a chance to look at the code and piece my argument together fully, but the rough strokes are this: you're modifying the test code to opportunistically kill() a dangling process, and you should never need to do that in the test suite, because the tests should be *deterministic* about whether there are processes left over [16:24] slangasek: see my latest comments - I changed the branch to do it deterministically. [16:24] jodh: either the shutdown is done in the right order, modeling our normal user session shutdown process, and everything gets cleaned up and there's nothing to kill, in which case it should be an error for the process to be left at the end; or you're modeling an out-of-order shutdown where the session init is being hard-killed from the outside, in which case we know the process should be left behind, and the test should consider it a fail [16:24] ... process *isn't* there [16:24] jodh: oh, hadn't noticed that the branch itself was updated [16:25] let me look things over today then :) [16:25] slangasek: yeah - I've also added in big comments in the test code to explain what we're doing :) [16:31] xnox: so did the cmake cross-compiling you did sidestep the question of qmake upstream divergence? [16:34] slangasek: not really, no. moc / qtchooser are still brain dead and claim that "No Qt installation found". It stopped being on the critical path, but we do need to solve co-installability. [16:34] xnox: for which case is co-installability needed? [16:37] slangasek: e.g. qtbase5-dev is still not co-installable, and neither ubuntu-sdk. E.g. to be able to compile for multiple architectures on your host machine, without using chroots. Or e.g. have one chroot that can compile to i386/amd64/armhf/arm64.... [16:37] slangasek: e.g. iphone 5S is ARM64 are we gonna hook them up as buildds? =) [16:39] blink [16:39] it's arm64? [16:39] xnox: That isn't a blocker, though; I plan to just have one-per-arch chroot management [16:40] but yeah, we can get by for now with one chroot per target arch [16:40] it's not ideal, but it works [16:40] I just wanted to make sure we weren't blocked because we need both native *and* foreign copies of the package installed for cross-building [16:43] slangasek: cjwatson: right. so one-per-arch chroot would work with cmake. [16:45] slangasek: but we do really really want your bugfix debian #722045 applied as e.g. some qt sdk packages depend on python somewhere down the line for scripts et. al. [16:45] Debian bug 722045 in dh-python "Please support python:any dependencies for multiarch compatibility" [Normal,Open] http://bugs.debian.org/722045 [16:45] xnox: yep [16:47] 350494 [16:48] achievement unlocked: two-factor auth IRC [16:49] i was unpluggin it =) === Nisstyre-laptop is now known as nisstyre [17:09] Sigh, four bugs about grub2 2.00-18ubuntu2 already [17:09] Actually five [17:09] * cjwatson drops a little lecture about it being counterproductive to run saucy-proposed into the bug [17:09] it's arm64? <-- yep, apparently apple have crammed it into their "a7" chip. === tiagohillebrandt is now known as tiagoscd === tiagoscd is now known as Guest67365 [18:10] hi all. can i get someone to ack the ubuntuone-client 3.0.2-0ubuntu2 upload to precise-proposed? would like to get that SRU out quickly if possible as it fixes a rather annoying bug :) [18:53] cjwatson: did you freeze saucy until grub2 lands? [18:54] cjwatson: since the grub2 amd64 build is now trapped in "unapproved", I can't make much sense of this [18:54] cjwatson: it's not frozen in LP [18:55] cjwatson: the i386 made it through; I guess we can just approve it from https://launchpad.net/ubuntu/saucy/+queue?queue_state=1 ? [18:55] jibel: ^ FYI [19:03] cjwatson, jibel: the powerpc build got auto-accepted, and there is a propagation block on it, so I took the liberty to accept the amd64 build from unapproved, so that the mayhem in the autopkgtests stop [19:03] (however it ended up in unapproved in the first place) [19:03] pitti: Anything with signed bits lands in unapproved. [19:04] infinity: ah, that's because i386 isn't signed? [19:04] pitti: Only amd64 produces an efi tarball, yes. [19:05] You're meant to take that opportunity to verify the build matches the upload and the upload doesn't contain something that's going to trojan the world. [19:05] I'm sure you did that, right? :) [19:05] I personally identified every single bit [19:06] infinity: more seriously, how is that being done? if we don't trust our buildds, what makes grub special? [19:06] I doubt that anyone can verify the binary results, even a genius like cjwatson? [19:06] pitti: Oh, I verify the trust path from the archive to the buildds. [19:07] pitti: But not from random core-devs uploading to pushing an efi blob signed by Canonical's key. [19:07] pitti: Hence checking the diff to make sure it was sane (or trusted). [19:07] pitti: In this case, it being a Colin upload, the "trust" part probably works. [19:07] infinity: ah; well, I did check the diff, yes [19:08] pitti: This was the compromise between not completely locking down upload rights for the kernel and grub, and still being paranoid about our EFI key so Microsoft doesn't go and revoke us tomorrow. [19:08] infinity: thanks for the heads-up [19:08] * infinity realized this was probably never well communicated to all archive admins. [19:08] s/realized/realizes/ [19:09] infinity: at least my mind now changed from "huh!?!?" to "yes, that makes sense" [19:09] pitti: I'm not sure how much sense it makes to me, but I'm glad it makes sense to someone. ;) [19:09] pitti: Could you or someone have a look at the pyparsing autopkgtest failure? [19:10] Seems like an ADT issue according to jtaylor. [19:10] ScottK: don't worry about them [19:10] ScottK: all tests fail right now due to grub2 [19:10] OK. [19:10] cf. me being anxious go get above fix in ASAP :) [19:11] ScottK: we'll retry all failed tests after ubuntu3 is in the archive [19:11] pitti: Wait, new bootloader uploads to proposed completely break your test infrastructure? [19:11] pitti: This seems suboptimal. :) [19:11] infinity: no, base packages failing to upgrade do [19:11] infinity: well, in a way that's good [19:11] pitti: Oh, the update-grub failure. Check. [19:11] infinity: we do not *ever* want this near saucy, so any possibility of failing the gating is good [19:12] pitti: I forgot that it was actually *broken*. That was, like, an hour ago. [19:12] of course in this case the tests wouldn't actually have held back grub ubuntu2, that was cjwatson's manual block [19:13] grub2 gets held back until someone upload grub2-signed anyway. [19:13] but it worked for cloud-init and other upgrade failures, I think [19:13] (Though, I'm about to do that, since Colin's block will still keep it all out) [19:13] s/upload/uploads/ [19:27] grub2-common | 2.00-18ubuntu3 | saucy-proposed | amd64, i386, powerpc [19:27] jibel: ^ I think we can retry the failures now [19:28] pitti, done [19:28] jibel: I've kicked python-apt, let's make double-sure that works, and then nudge the rest? [19:29] jibel: ah, thanks [19:29] jibel: ah, you were using your new magic script? [19:29] ubiqutiy failed but for a missing dep === Nisstyre-laptop is now known as nisstyre [19:31] pitti, it is just a very basic script that triggers jobs remotely :) [19:32] at least it saves me a few clicks [19:34] pitti, infinity: the point of the efi unapproved queue isn't for you to verify the builder output, but for someone to verify that the source hasn't changed in an inappropriate way - i.e., that the upload wasn't from I. Justgotmotuandnowiownyouall making inappropriate changes to grub [19:34] so yeah, if Colin signed it, it should be good ;) [19:35] slangasek: ack; I did review the debdiff, verifying the binary integrity would be out of scope [19:35] righto [19:35] slangasek: ok, so we're all on the same page [19:46] slangasek: That's what I said. :P [19:47] infinity: ok good :) [19:47] 13:06 < infinity> pitti: Oh, I verify the trust path from the archive to the buildds. [19:47]