[03:08] <edwin> q
[07:20] <dholbach> good morning
[08:46] <Unit193> seb128: Hello.  Sorry to bother you again, but is there a chance you can take a look at https://bugs.launchpad.net/bugs/1060543 ?
[08:46] <seb128> Unit193, hey, I'm not working on software-properties, maybe try mvo when he's around?
[08:47] <Unit193> Ah, sorry.  Saw your name on last uploader.  He's been quite busy and normally is on the wrong timezone for me. :P
[08:50] <seb128> if you have a patch just subscribe ubuntus-sponsors to the bug
[09:04] <Unit193> seb128: Just a "mockup" of a desktop file.
[09:33] <mlankhorst> ok so all upgrade bugs from lts to lts are fixed \o/
[09:49] <brendand> does anyone know of any good information on the file POTFILES.in? what is it used for , and information on the format
[09:54] <seb128> brendand, did you try man intltool-update?
[09:56] <brendand> seb128, that's the tool i was looking for, thanks
[09:57] <seb128> brendand, yw!
[10:00] <brendand> seb128, sorry - what about the format? does it support globs?
[10:02] <brendand> seb128, and also types. some of the files i want to translate are qt/qml
[10:06] <seb128> brendand, not sure about those, I guess so
[10:06] <seb128> brendand, you should maybe look at some project using similar techs to yours as an example.
[10:06] <seb128> ?
[10:09] <seb128> hum
[10:09] <seb128> the ppc64el seem all on "manual", is that normal?
[10:10] <infinity> seb128: Yeah, it's temporary.
[10:10] <infinity> seb128: We're rebootstrapping the entire archive.  Nothing to see here.
[10:10] <seb128> infinity, does it mean things are sutcked in trusty-proposed until that's resolved?
[10:10] <brendand> seb128, hmm seems qml apps avoid using POTFILES.in
[10:10] <infinity> (Should be back to autobuilding in an hour or so)
[10:11] <brendand> seb128, i guess intltool-update only supports gettext
[10:11] <infinity> seb128: For a little bit, but not long (see above).
[10:11] <seb128> brendand, could be, I'm not the best person to ask about that
[10:11] <seb128> infinity, thanks
[10:12] <brendand> dpm ? ^
[10:42] <dpm> brendand, could you give me more context on your question about POTFILES.in?
[10:43] <brendand> dpm, i'm trying to figure out the best way to set up translations for my c++/qml package
[10:44] <brendand> dpm, i guessed intltool-update would be best to use, but it seems to not support qml
[10:45] <brendand> dpm, are there ubuntu touch core apps that have a c++ component?
[10:45] <Laney> brendand: take a look at ubuntu-system-settings
[10:48] <dpm> brendand, yes, that or lp:reminders-app or lp:ubuntu-weather-app (the latter has an up-to-date README.translations file that provides more context)
[10:49] <seb128> Laney, dpm: just for the record I didn't point him to e.g u-s-s because it would be handy to have intltool working, our current setup is inferior in several ways (including the fact that we can't simply update the template by running intltool-update, we need to generate a build tree to run the make command and copy manual back)
[10:50] <brendand> seb128, i'm not the guy to make that happen though :)
[10:50] <seb128> well, you were looking at it, who knows, maybe you would have found a way
[10:50] <brendand> seb128, we're trying to get this package into main so we need translations set up
[10:51] <dpm> brendand, can you point me to the lp project? I can try to help, but this week is rather full, so unfortunately I can't make any promises
[10:52] <brendand> dpm: it's in lp:checkbox but in the checkbox-gui directory
[10:53] <dpm> seb128, yeah, I see it that way too. But I couldn't figure out a way to replicate intltool-update with cmake without calling cmake and make, either :/
[10:53] <dpm> with qmake it was a bit easier, but still not optimal
[10:54] <infinity> seb128: compiz and bamf built, were those the ones you were worrying about?
[10:54] <seb128> infinity, I'm watching the builds, nux and unity still
[10:54] <seb128> infinity, but yeah, those 2 were part of the unity update
[10:55] <Laney> seb128: yeah, but I think the problem is that intltool just doesn't support qml at all, let alone ubuntu sdk qml
[10:55] <Laney> the xgettext call we have encodes 'tr' as a thing to look for
[10:56] <seb128> Laney, right, I need to look at making our "make pot" at least not output the fullpath in the template, that makes the whole template change every time we run the command
[10:56] <seb128> dholbach, the cordova binaries are a bit weird, they install their .so in /usr/share ... is that wanted?
[10:57] <infinity> It's never wanted.
[10:57] <infinity> Unless those are magical arch-indep libraries.
[10:57] <seb128> that package is quite hackish, I don't like much
[10:57] <seb128> but I'm not wanting to fight over details since I don't have a better suggestion/I'm not interested enough into the topic to spend efforts on it
[10:58] <infinity> If they're not following FHS, that's absolutely a reason to reject.
[10:58] <seb128> infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed"
[10:59] <infinity> Ahh, binaries in /usr/share make sense in that context.  But they still shouldn't overlap between arches, if they currently do.
[10:59] <seb128> /usr/share/cordova-ubuntu-3.4/www/libcoreplugins.so
[10:59] <seb128> so yeah, they do
[11:00] <infinity> Yeah, so no indication of what arch that .so is for...
[11:00] <seb128> dholbach, can we get that fixed?
[11:01] <infinity> It's not multi-arch:same, of course, so there's allowed to be overlap.  It just seems like a bit of a messy design.
[11:01] <seb128> infinity, feel free to accept the binaries from the queue if you are fine with them ;-)
[11:01]  * seb128 has no strong opinion, as said that package is a bit hackish
[11:02] <seb128> but if it does the job/unblock people...
[11:03] <infinity> I'd probably want to talk to the people behind it to get more context before I accepted them.  Which I'm unlikely to do at 4am after working all weekend.
[11:05] <seb128> infinity, yeah, you should get some sleep!
[11:05] <seb128> infinity, have a good night
[11:05] <infinity> seb128: I'll try. :)
[11:15] <dholbach> seb128, AFAIK (I'm just trying to help the team get things landed): the SDK will download <package>:<arch> from the archive and bundle that the runtime in the click package
[11:16] <seb128> dholbach, what if you try to dev for e.g i386 and armhf on the same machine?
[11:16] <seb128> those conflict atm
[11:16] <dholbach> seb128, AFAIK they're not necessarily required to be installed on the developers machine, but I might be wrong
[11:17] <seb128> well, they are in the archive, so nothing prevent you to apt-get install them
[11:17] <dholbach> dbarth and team would be the people to answer this - maybe we should discuss it on https://launchpad.net/bugs/1279814?
[11:18] <seb128> well, as said before, I'm busy enough with other things and I don't know much about the cordova thing
[11:18] <dholbach> ok
[11:18] <seb128> so I'm going to letting infinity a chance to comment on that later on, and if he doesn't I think I'm just going to wave the binaries in
[11:18] <seb128> they are a bit hackish/wrong but that's not the end of the world imho
[11:20] <dholbach> thanks seb128, infinity
[11:21] <seb128> yw
[11:22] <seb128> do we have any buildd admin around to bump the score of https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20131106.1-0ubuntu5/+build/5606463 ?
[11:22] <cjwatson> done
[11:22] <seb128> cjwatson, thanks
[11:23] <cjwatson> (not really here, just going again)
[11:23] <seb128> (good timing for not being here, thanks again ;-)
[11:24] <infinity> That really wasn't necessary...
[11:24] <infinity> seb128: Everything in the release pocket is being rebuilt, there's no particular reason to score any of it up, as we still have all the old binaries.
[11:25] <cjwatson> oh, that was a release pocket build?
[11:25] <cjwatson> right, matters not
[11:25] <cjwatson> *shrug* it'll all churn through anyway
[11:26] <cjwatson> I expect seb128 actually identified the wrong build from proposed-migration
[11:26] <seb128> shrug, indeed
[11:26] <seb128> I wanted https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20140214.1-0ubuntu1/+build/5607904
[11:26] <infinity> The proposed one is dep-waiting for a publisher cycle.
[11:26] <cjwatson> which is needs-build now and about to start
[11:26] <infinity> Or, was.
[11:26] <seb128> I got confused by the lp table lines order and clicked on the wrong version
[11:26] <cjwatson> everything in -proposed will build before anything in the release pocket
[11:26] <seb128> cjwatson, infinity: thanks
[11:26] <seb128> oh, nice
[11:26] <cjwatson> so actually your request slowed more important things down
[11:26] <cjwatson> oh well, not by much
[11:26] <seb128> :-(
[11:27] <seb128> sorry about that
[11:27] <infinity> S'ok.  I'm still banking on main being done in just over a day.
[11:27] <seb128> I cancelled the build of the other version
[11:27] <cjwatson> you still planning to commandeer more hardware?
[11:27] <cjwatson> seb128: just leave it please
[11:27] <infinity> cjwatson: Yeah, but not until Tuesday, when I can get pinky to twiddle some cables.
[11:27] <infinity> And main will probably be done by then.
[11:28] <seb128> too late, sorry again :-(
[11:28] <cjwatson> seb128: rule of thumb for today: don't try to micromanage ppc64el :)
[11:28] <seb128> yeah, I just learnt that I think
[11:28] <cjwatson> I've retried that cancelled build for consistency's sake
[11:28]  * seb128 justs wants that unity in trusty :p
[11:29] <seb128> anyway, we should be good once the proposed build finish
[11:29] <seb128> so I'm staying away from builders now
[11:29] <seb128> thanks again ;-)
[11:40] <cjwatson> infinity: I'd certainly expect the whole thing to be quicker than the predicted five days
[11:45] <infinity> cjwatson: I gave myself a lot of padding in my estimates.
[11:45] <infinity> cjwatson: Years of "5-minute-fix" engineering estimates have taught me some valuable lessons.
[11:46] <infinity> cjwatson: Of course, it's also feature freeze week, which means everyone and their dog will be vomiting their last two months of pending local changes to every package ever, so that churn will slow us down a tiny bit.
[11:53] <wgrant> cjwatson, infinity: There's were ~700 buildd-hours of successful builds in the release pocket at the time of the purge, from what I can see.
[11:54] <infinity> wgrant: So, 3 days on the current setup.  Add a couple for proposed churn, subtract for extra hardware on Tuesday, carry the 1...
[11:54] <wgrant> Plus the failures, which I'll work out in a moment.
[11:54] <infinity> Right, well.  I'll set up the other two machines tomorrow "just in case", so they can be lit up as soon as they have a network.
[11:54] <wgrant> Yep
[11:55] <infinity> And if we don't need 'em, whatever.  But handy to have them.
[11:58] <wgrant> Looks like about 950 if we include failures.
[11:58] <wgrant> Still, not very many days.
[11:59] <infinity> 4 days, plus an extra for proposed churn, I'd say...
[11:59] <infinity> Hits my 5 day mark almost on the head.  But 8 more VMs will win the day.
[12:01] <ogra_> doko_, infinity .... why does libgcc nowadays depend on gcc-4.9 ?
[12:01] <ogra_> seems a recent change pulled the compiler into the touch image
[12:01] <infinity> ogra_: It doesn't.
[12:01] <infinity> ogra_: gcc-4.9-base isn't a compiler.
[12:01] <infinity> ogra_: You already had gcc-4.8-base
[12:01] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/20140214.3.changes
[12:02] <ogra_> ah
[12:02] <ogra_> why isnt 4.8 not dropped then ?
[12:02] <ogra_> -not
[12:02] <infinity> ogra_: libgcc1 is 4.9, but you still have other libs from 4.8 (probably libstdc++6, at least)
[12:02] <ogra_> hmm, k
[12:02] <xnox> ogra_: because 4.8 is default for C/C++, whilst 4.9 is default for Go on armhf/arm64/ppc64el
[12:02] <infinity> ogra_: So, you need both -base packages.  They're tiny, no big deal.
[12:02] <ogra_> ok
[12:07] <doko> neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change?
[12:07] <ogra_> they are on oakland iirc
[12:08] <ogra_> should come online in a while
[12:08] <seb128> right, QA is in Oakland this week
[12:29] <infinity> Oh, one more rebuild-related thing: archive admins, please ignore the heck out of component-mismatches for the next few days, it'll be full of lies.
[12:30] <infinity> cjwatson, doko, seb128 ^
[12:30] <seb128> infinity, noted, thanks
[13:45] <brendand> dpm, hello again
[13:45] <brendand> dpm, all the packages you pointed to seem to involve cmake at some stage
[13:45] <brendand> dpm, can we avoid introducing cmake into the chain?
[13:46] <dpm> brendand, you can try with qmake, which for translations was pretty lightweight. Have a look at the weather app, 3 or 4 revisions back from trunk
[13:47] <dpm> that was before the cmake switch
[14:07] <jamespage> doko, any ideas? https://launchpadlibrarian.net/166508215/buildlog_ubuntu-trusty-ppc64el.gccgo-go_1.2-0ubuntu5_FAILEDTOBUILD.txt.gz
[14:07] <jamespage> that upload failed with the same error on armhf, powerpc and ppc64el
[14:07] <doko> yes, known
[14:07] <jamespage> doko, ok
[14:13] <pitti> Good morning
[14:14] <doko> neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change?
[14:14] <pitti> I just saw
[14:14] <pitti> I added proxy vars so that tests can talk to the network
[14:15] <pitti> but apparently that's confusing some things
[14:15] <seb128> pitti, when did you add them?
[14:15] <pitti> I wanted to revert that for now, but now I can't build any fresh VMs any more
[14:15] <shadeslayer> pitti: morning :)
[14:15] <pitti> it seems the latest cloud-image upload from Feb 14 broke VM building entirely, looking at that now
[14:15] <pitti> seb128: Feb 11 or so
[14:15] <seb128> k
[14:16] <shadeslayer> pitti: so regarding the upgrade tests for Kubuntu + Backports PPA , we have http://bazaar.launchpad.net/~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing/files/head:/share/profiles/kubuntu-full-backports/
[14:16] <seb128> I guess the software-properties tests started failing for another reason
[14:17] <shadeslayer> pitti: which apparently requires a script to be added, wouldn't that be needed in main auto-upgrade-testing?
[14:18] <pitti> smoser: so since Feb 14 (new cloud-init), ssh connections to the cloud images keep timing out; did you hear any report about this already and already have an idea why?
[14:23] <shadeslayer> pitti: so, any thoughts?
[14:23] <pitti> shadeslayer: sorry, stack overflow
[14:24] <shadeslayer> hah :D
[14:24] <pitti> tons of IRC scrollback, and I mostly wanted to see whether I can catch smoser before Europe goes EOD
[14:25] <shadeslayer> pitti: tl;dr http://bazaar.launchpad.net/~kubuntu-dev/auto-upgrade-testing/auto-upgrade-testing/files/head:/share/profiles/ < has some kubuntu profiles, thoughts on getting that merged into auto-upgrade-testing since we have some scripts in there too that can't be added to jibel's branch
[14:26] <pitti> yes, if we want to run them, we'll merge that; jibel wanted to merge his +junk branch into lp:a-u-t, too
[14:27] <pitti> doko: so in short, it's on my radar, I'll fix it today
[14:27] <doko> cool, tanks
[14:27] <pitti> as soon as I find out what changed in cloud-init and I get working VMs again, I'll fix or revert the proxy settings and retry all failing tests
[14:30] <pitti> smoser: do the current cloud images (with latest cloud-init) work for you at all? they just hang eternally in qemu for me, with no useful output or possibility of logging in
[14:32] <shadeslayer> pitti: ack, I'll try and update the branch
[14:33] <pitti> smoser: last known working image is from Freb 14
[14:33] <pitti> Feb
[14:36] <spineau> doko: hello, we've uploaded checkbox 0.17.4 but surprisingly, that didn't trigger any component mismatches, two mir'ed dep are still not in main (bug 1278822 and bug 1277408)
[14:37] <spineau> doko: Ideally we'd like to see both of them in main before Thursday
[14:42] <pitti> smoser: http://paste.ubuntu.com/6949086/ is the output from ttyS0; this still worked with the very same cloud-init iso until Feb 14; any idea?
[14:43] <ogra_> pitti, check your serial cable
[14:43]  * ogra_ grins
[14:50] <Laney> did anyone notice that gpg-agent has stopped saying which key it's prompting you for?
[14:51] <xnox> Laney: is it the result of using ssh-agent, instead of gnome-keyring secrets agent?
[14:51] <Laney> doubt it, this is inside a container
[14:52] <mapreri> Godd afternoon! I'm wondering why 4.5.0-2 is stuck in proposed https://launchpad.net/ubuntu/+source/insighttoolkit4 ....
[14:54] <mapreri> (Architecture field in the control file state only "amd64 i386", so builds are ok http://sources.debian.net/src/insighttoolkit4/4.5.0-2/debian/control )
[14:54] <cjwatson> mapreri: stale library left around in -proposed, looking
[14:55] <mapreri> cjwatson: great, thank you!
[14:55] <cjwatson> plastimatch will need to be rebuilt against the new version
[14:56] <cjwatson> let me quickly do that now
[14:56] <mapreri> cjwatson: can I know how do you find it? (just to learn something new...)
[14:56] <cjwatson> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#insighttoolkit4
[14:56] <cjwatson> plus experience
[14:58] <cjwatson> and checkrdepends against an archive mirror to find the reverse-deps of that library in -propsoed
[14:58] <cjwatson> *-proposed
[14:59] <mapreri> uh
[14:59]  * mapreri takes note....
[14:59] <cjwatson> mapreri: ok, I've uploaded a no-change rebuild of plastimatch and removed the stale libinsighttoolkit4.4/i386 binary from -proposed, so that should clear it up shortly assuming plastimatch builds
[15:01] <mapreri> cjwatson: I'll check in a few hours, thanks again
[15:14] <seb128> does anyone know what is missing to make indicator-datetime/unity-control-center migrates?
[15:14] <seb128> indicator-datetime stopped building unity-control-center-datetime
[15:14] <seb128>  unity-control-center C,R,P it
[15:14] <seb128>  so the binary should be NBS and provided by u-c-c
[15:14] <seb128>  that should be enough no?
[15:35] <pitti> doko: I re-ran python2.7, that failed many tests, but they don't sound network/proxy related; I'll have a look later after breakfast
[15:37] <pitti> seb128: so it seems gjs is due to the new version? Error: Requiring GjsPrivate, version none: Typelib file for namespace 'Gtk', version '3.0' not found
[15:37] <pitti> seb128: sounds like it now grew a missing gir1.2-gtk-3.0 test dep?
[15:37] <pitti> (or perhaps binary dep, not sure)
[15:37] <seb128> pitti, looks like
[15:37] <seb128> darkxst, ^ can you look at that/get it sorted out (since you did that update)
[15:56] <seb128> is britney supposed to resolve provides?
[15:56]  * seb128 wonders why it doesn't consider the unity-control-center providing unity-control-center-datetime as valid/enough
[16:01] <geser> does britney consider those two packages together or each for it's own if it can transition?
[16:01] <doko> rbasak, could you have a look at the php5 merge?
[16:07] <seb128> geser, each one it seems
[16:07] <seb128> Laney, can you hint britney to consider both together?
[16:09] <Laney> worth a try
[16:10] <seb128> Laney, thanks
[16:16] <rbasak> doko: ack.
[16:18] <Laney> seb128: if it doesn't work I guess you can remove the package and fix the seeds to not pull it in
[16:19] <seb128> Laney, right, the seed need fixing anyway, but robert_ancell and pitti stacked work, and robert_ancell wants to transition to unity-settings-daemon as well, so I was sort of letting one of them deal with an upload
[16:19] <Laney> jus' saying, that'll probably help with the migration
[16:20] <seb128> right
[16:20] <seb128> let's see at the next run with the hint
[16:22] <apw> cjwatson, just updated an old clunker, and am getting "diskfilter writes are not supported" with a press any key to continue, from grub2, expected ?
[16:27] <rbasak> doko: you mean 5.5.9, right? 5.6 is in experimental, but I'm not sure that's a good idea.
[16:31] <hakermania> Can anyone remind me the process of updating a package from the repos? I want to update Wallch to the version 4.0. I remember that I have to post a bug report somewhere and link to the ppa but I don't clearly remember the process...
[16:50] <seb128> geser, Laney: britney hint worked ;-)
[16:50] <Laney> neat
[16:52] <brendand> dpm, do you have any more detail on how translations work with sdk apps? are the qml files installed with the translations merged in, or does it work some other way?
[16:53] <dpm> brendand, it's quite similar to e.g. python apps on the desktop. We're using gettext: the qml files load the translations at runtime, and translations are shipped as .mo files in the .click packages, using the same gettext paths as in the desktops, with the difference that they are installed within the click package's installation folders
[16:53] <dpm> and not in the system
[16:59] <seb128> pitti, huuuummm
[16:59] <seb128> pitti, why did gtk migrate to the release pocket while gjs tests are still red?
[16:59] <seb128> pitti, not that complain about gtk migrating, but that seems buggy
[17:00] <Laney> adt migration bugs are usually jibel
[17:00] <pitti> seb128: we had the same problem last week with the libgcc bug
[17:00] <Laney> he was looking into it iirc
[17:00] <apw> cjwatson, seems to only affect my 32bit box ... amd64 seems happy
[17:04] <seb128> jibel, ^
[17:10] <doko> rbasak, yes, 5.5.9, please not an alpha ;)
[17:18] <pitti> stgraber: can you leave in the lxc proxy hack? I'm going to revert it from the VMs for now
[17:18] <pitti> stgraber: it breaks too many things, and e. g. glib and python have different ideas about how these variables work
[17:21] <stgraber> pitti: ok
[17:22] <stgraber> pitti: oh and I was just about to ping you about logind, any chance you can get me a PPA build or something of the systemd version we'd like to have for Trusty?
[17:22] <doko> doko, any hint about https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5518972 ?  there are about 100 build failures like this one
[17:22] <pitti> stgraber: I don't currently have any plan of changing what we have in a major way
[17:22] <doko> rbasak, ^^^
[17:23] <pitti> stgraber: unless you plan on landing the cgroupmanager and compat API? But even then, upgrading to systemd 208 would be quite a bold step at this point IMHO
[17:24] <stgraber> pitti: right, I was asking specifically because of that. We have cgmanager working fine now and I'm looking at the next steps.
[17:24] <pitti> oh, nice
[17:24] <stgraber> pitti: if you don't plan on updating systemd at this point, then that's fine, I'll just patch logind directly to talk to cgmanager, if you plan on updating systemd, then I should be working on the shim instead.
[17:24] <pitti> stgraber: yes, agreed
[17:25] <pitti> stgraber: but TBH I'd leave that to 14.10
[17:25] <stgraber> well, I can't, we need logind to do the right thing for unprivileged containers in 14.04... so I guess I'll just patch our current logind to talk to cgmanager and look at systemd-shim for 14.10 instead.
[17:26] <pitti> doko: hm, I get all kinds of failures even locally now ("cannot allocate memory" and other  strange stuff); could that be related to the new glibc?
[17:32] <stgraber> pitti: I'll try and get the logind patching done this week and will send you a patch or branch so you can sanity check it
[17:33] <pitti> stgraber: thanks; we are on a sprint this week, so I probably won't have too much bandwidth for large patches; but I guess if that's only against 204 it should not be too big
[17:50] <stgraber> pitti: right, it should really just be some code to detect cgmanager and do 3 dbus calls (per controller) instead of the matching cgroupfs writes
[17:51] <cjwatson> apw: won't have much to do with 32-bit, I expect that's because it's trying to write to a /boot/grub/grubenv on RAID or LVM
[17:52] <cjwatson> stgraber: we still want the shim to work properly for Debian, though, right?
[17:53] <stgraber> cjwatson: right and for 14.10 (probably) but I'm not going to rush into doing that for 14.04 if our logind doesn't use that API anyway
[18:00] <apw> cjwatson, ahhh yes this is the machine i got rid of the separate /boot from because it was far toooo small
[18:08] <cjwatson> apw: it's a relatively harmless error - main side-effect is that the logic to display the boot menu if the previous boot failed won't work
[18:08] <cjwatson> (also some other side-effects of similar kinds, but that's the one you're most likely to notice)
[18:09] <apw> cjwatson, yeah and it makes teh boot ugly suddenly, i assume it is something new with the beta?  anyhow this setup is a very odd one i am sure
[18:09] <cjwatson> dunno about that
[18:11] <tseliot> stgraber: hi, can you approve bug #1279229 please? I've verified the fix
[19:02] <pitti> stgraber: I'm writing a little script which is supposed to run every day to create a fresh container and (almost) atomically replacing the previous one with the new one: http://paste.ubuntu.com/6950426/
[19:02] <pitti> stgraber: but of course that rips out the underlying FS for any running containers
[19:03] <pitti> stgraber: are you aware of an existing solution how to provide daily updated containers when they also might be running?
[19:05] <stgraber> pitti: as in, you have containers using that one as a base with overlayfs or aufs?
[19:05] <pitti> right, with ephemeral
[19:05] <pitti> stgraber: I want to use that on the machines that run autopkgtests (arm/ppc64el)
[19:05] <stgraber> hmm, best guess would be to create your .new, then rsync the rootfs
[19:06] <pitti> stgraber: I can of coure add some lock file mechanism so that the update job always runs alone
[19:06] <stgraber> so you'll never end up with an empty underlay, and it should update pretty quickly
[19:07] <pitti> stgraber: but if I rsync the new rootfs into the old container, doesn't that also create inconsistent file systems?
[19:07] <stgraber> (rsync -A --numeric-ids --sparse --hard-links --delete trusty.new/rootfs/ trusty/rootfs/)
[19:07] <stgraber> yeah, it'd be inconsistent for a tiny bit of time
[19:08] <stgraber> it's a tradeoff, either you have an update script as yours which will only apply to new containers
[19:08] <pitti> stgraber: ah, and I would never actually move/rename the .new container to the old one, but just always keep the one existing "trusty" container?
[19:08] <stgraber> or you have something using rsync which will also apply to running containers
[19:09] <stgraber> right, no reason to copy a new config, fstab, ... those don't change, you only really care about the rootfs
[19:09] <pitti> stgraber: ack
[19:09] <pitti> stgraber: many thanks!
[19:20] <stgraber> jdstrand, doko, infinity: any of you (probably security) has time to review bug 1279048? I'm going to release LXC 1.0 this week and I'd very much like it to use cgmanager by the time I upload it...
[19:20] <stgraber> this is also very soon going to become a blocker for landing of logind, libvirt, libcgroup and upstart features, so would be nice if we could have this processed soonish
[19:29] <doko> pitti, glibc didn't change yet. (I mean glibc-2.19 wasn't yet uploaded)
[19:30] <pitti> doko: ah, so what triggered the run was only the two ppc64 patches in https://launchpad.net/ubuntu/+source/eglibc/2.18-0ubuntu7
[19:48] <ogra_> robru, hmm, seems since the last update the G+ webapp on the desktop uses the QML browser ... which just tells me that the browser is unsupported after login
[19:59] <robru> ogra_, hmmm? my understanding is that all the webapps are supposed to be using the qml container on the desktop. that was a transition that we tried to get in last cycle, but it wasn't ready before feature freeze, so it got delayed until this cycle...
[19:59] <ogra_> robru, yes, thats why i ping you, because i know you were involved
[19:59] <ogra_> robru, G+ does definitely not work with that
[20:00] <robru> oh...
[20:00] <ogra_> (most likely needs a hacked user agent)
[20:00] <robru> ogra_, is there a bug filed?
[20:00] <ogra_> not by me, i just noticed it before i pinged you
[20:01] <robru> ogra_, ok, please file a bug and assign it to justinmcp
[20:03] <nvrpunk> anyone know why I am getting:  can't build with source format '3.0 (quilt)'
[20:04] <ogra_> robru, against what, webapp-contsainer ?
[20:04] <ogra_> *container
[20:04] <robru> ogra_, nah, unity-webapps-googleplus
[20:05] <ogra_> ok
[20:05] <nvrpunk> nvm, got it
[20:19] <sergiusens> robru, ogra_ g+ app is owned by xnox
[20:19] <sergiusens> robru, ogra_ nvm, wrong channel :-) just the click one ;-)
[20:19] <xnox> sergiusens: well, i've submitted g+ app update, but it got rejected
[20:20]  * sergiusens checks
[20:23] <sergiusens> xnox, just add --webappUrlPatterns
[21:29] <nvrpunk> I dput a new build in my ppa for tahr and it isn't showing up, what should I check?
[21:29] <nvrpunk> if I try to reupload it says package exists
[21:29] <nvrpunk> I don't see it in my build queue etc
[21:33] <infinity> nvrpunk: Which PPA?
[21:33] <nvrpunk> tim.l.nelson/ppa
[21:33] <nvrpunk> err
[21:34] <nvrpunk> tim-l-nelson/ppa
[21:34] <nvrpunk> nvm
[21:34] <nvrpunk> i think i got it
[21:35] <infinity> Mmkay.
[21:36] <nvrpunk> i think i need to create a new ppa, my first one was for Saucy
[21:37] <Unit193> You can use the same PPA for trusty, saucy, precise, etc.
[21:38] <teward> ^ that
[21:39] <infinity> nvrpunk: What matters is what distribution is in the .changes file.
[21:39] <infinity> nvrpunk: (Or, alternately, the magic path you dput to, but that's a bit sketchier)
[21:41] <nvrpunk> Version: 8.6.1-4ubuntu1ppa1
[21:41] <nvrpunk> Distribution: trusty
[21:41] <nvrpunk> looks like my versioning and distribution are correct, I just don't see it queued to build etc
[21:41] <nvrpunk> I dput it an hour ago or so
[21:42] <nvrpunk> it should show in my "recent activities" correct?
[21:43] <Ampelbein> nvrpunk: did you upload the same version before and then delete the packages from your ppa?
[21:43] <nvrpunk> no
[21:43] <nvrpunk> unless I uploaded 8.6 months ago and forgot, but I don't recall doing that
[21:44] <nvrpunk> and if I did it was most likely rejected because I had no clue what I was doing months ago
[21:54] <nvrpunk> yeah, I am at a loss
[21:54] <nvrpunk> never had this happen
[21:54] <sem> i have installed gnome-shell package in my kubuntu box ==> unable to login
[21:55] <sem> this is not nice
[22:03] <wgrant> nvrpunk: You signed the .changes file with an OpenPGP key that isn't associated with your Launchpad account.
[22:03] <wgrant> nvrpunk: If you get no email from Launchpad at all, that usually means that there was no signature, or the signature was unable to be verified.
[22:04] <teward> wgrant: are the PPA uploaders lagged at the moment?
[22:04] <teward> oops i meant to point to #launchpad but I hate laptop touchpads, they clicked me to here
[22:04] <teward> >.>
[22:04] <wgrant> teward: No, no issues.
[22:07] <wgrant> teward: Are you seeing delays?
[22:07] <teward> wgrant: yeah, 5 - 10 minute upload gap between amd64 and i386
[22:07] <teward> was causing bug triage problems for an upstream project, hence why i meant this to go to #launchpad
[22:07] <teward> it *just* resolved itself
[22:07] <wgrant> teward: Oh, binary uploads?
[22:07] <teward> mhm
[22:08] <teward> wgrant: yeah, the upload of the built binaries
[22:08] <teward> not the upload of the source package
[22:08]  * teward was imprecise in his explanation of the issue
[22:08] <nvrpunk> wgrant: well I imported my keys from my old install ~/.gnupg
[22:08] <wgrant> A couple of minutes of lag there is normal at high-traffic times. Are you sure it wasn't rather different build times?
[22:09] <nvrpunk> wgrant: then set my DEBFULLNAME and DEBEMAIL and I assume that should be my old key?
[22:09] <nvrpunk> if I no longer have my key how do I update that?
[22:09] <teward> wgrant: since Launchpad doesn't report the actual timestamp of when the build started, both i386 and amd64 show the same build start time
[22:09] <teward> but you're right the completion was a different issue
[22:10] <wgrant> nvrpunk: debuild will have told you which key it used. Compare that to the one at https://launchpad.net/~/+editpgpkeys
[22:10] <wgrant> teward: You can hover over an "X minutes ago" timestamp to get the precise time.
[22:10] <teward> wgrant: still, it took a while even *after* building to upload, and it seemed uncharacteristically slow
[22:10] <wgrant> Nothing's been delayed by more than two minutes in several hours.
[22:11]  * teward shrugs
[22:11] <teward> wgrant: maybe i'm impatient because the bug is a High priority bug that prevents installation of the nginx PPAs but meh
[22:11]  * teward yawns
[22:11] <teward> i shouldn't be doing packaging stuffs while tired >.<
[22:13] <wgrant> Heh
[22:27] <nvrpunk> wgrant, thanks I updated my key
[22:27] <nvrpunk> will that cause them to build now?
[22:27] <nvrpunk> or will i have to wait on some form of rejection?
[22:28] <wgrant> nvrpunk: No, you'll need to upload the package again
[22:28] <nvrpunk> ok lol
[22:28] <wgrant> All your existing uploads were rejected.
[22:28] <wgrant> Because the key was unverifiable.
[22:29] <nvrpunk> Package has already been uploaded to ppa on ppa.launchpad.net
[22:29] <wgrant> dput -f
[22:29] <nvrpunk> does that matter?>
[22:29] <nvrpunk> ok
[22:29] <nvrpunk> it's like you read my mind :D
[22:30] <nvrpunk> or saw my failure
[22:30] <wgrant> The latter, I'm not that good.
[22:37] <cjwatson> infinity: Holy crap, the rebuild finished main already.
[22:38] <cjwatson> (Modulo builds in progress.)
[22:39] <wgrant> Yeah
[22:39] <wgrant> I didn't believe it, but I can't see that anything went wrong.
[22:40] <wgrant> I've given back various plausible retries, and they've mostly worked now that the deps are rebuilt.
[22:41] <wgrant> Still several -O3 failures, though
[22:42] <cjwatson> Imagine my surprise :-/
[22:42] <wgrant> All the errors have been the same, but who knows how many miscompilations have gone unwarned :)
[22:43] <nvrpunk> wgrant: does debuild create binaries?
[22:43] <wgrant> nvrpunk: It does by default, but you can tell it to build only the source package with -S
[22:44] <nvrpunk> ok
[22:44] <wgrant> You must use -S for a Launchpad upload.
[22:44] <nvrpunk> yes
[22:44] <nvrpunk> hence why I asked, thanks :)
[23:02] <cjwatson> wgrant: The firefox and thunderbird failures are a bit suspicious.  I guess some dependency isn't really rebuilt yet
[23:02] <stgraber> hmm, so who screwed up tha indicator-datetime upload? it wants to pull half of the archive on my machine including unity8
[23:05] <stgraber> ah, looks like it's failing to find unity-control-center 14.04.3 and so fallbacks to ubuntu-system-settings which in turns pulls all of the touch stuff on my machine
[23:05] <wgrant> cjwatson: Oh, I didn't look at them since they never worked.
[23:05] <stgraber> robert_ancell: ping
[23:06] <wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-trusty-ppc64el.html is the pre-purge page, for reference.
[23:06] <robert_ancell> stgraber, hello
[23:07] <stgraber> robert_ancell: hey, that last indicator-datetime is trying to pull half of ubuntu touch on my machine, can you please fix ASAP?
[23:07] <robert_ancell> stgraber, do you have gnome-control-center-datetime installed? Do you normally?
[23:07] <stgraber> robert_ancell: you put a recommend on unity-control-center >= 14.04.3 but only 14.04.2 exists in the archive, so apt then fallsback to ubuntu-system-settings which in turns pull all of touch on my system
[23:08] <infinity> cjwatson: That firefox failure is the same one we always had.
[23:08] <robert_ancell> stgraber, this is edubuntu right?
[23:08] <stgraber> robert_ancell: I appear to have this package installed, yes, though I certainly didn't install it manually
[23:08] <wgrant> cjwatson: The firefox failure looks the same as http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-failure-logs/buildlog_ubuntu-trusty-ppc64el.firefox_25.0+build3-0ubuntu0.13.10.1_FAILEDTOBUILD.txt.gz
[23:08] <cjwatson> oh right, ok
[23:08] <cjwatson> I didn't check prepurge :)
[23:08] <stgraber> robert_ancell: nope, that's my laptop, so standard Ubuntu desktop
[23:08] <robert_ancell> stgraber, ok
[23:08] <infinity> cjwatson: IBM has patches for it, we're trying to talk them into upstreaming it, so we don't have to maintain it.
[23:09] <cjwatson> k
[23:09] <stgraber> robert_ancell: so I guess the question is, are we supposed to have indicator-datetime on our desktops?
[23:09] <robert_ancell> stgraber, ok, will fix it. Yeah, we're off by one for the version
[23:09] <robert_ancell> stgraber, yes
[23:09] <stgraber> ok, good, so yeah, get that down to 14.04.2 and we should be fine
[23:16] <infinity> cjwatson, wgrant: http://paste.ubuntu.com/6951641/
[23:16] <infinity> Probably easier than hunting for "failures that matter".
[23:17] <infinity> binutils is intentionally scored down, and the cross toolchain will need fixing later anyway.
[23:17] <wgrant> A couple of them are pretty weird
[23:18] <infinity> modemmanager is fairly obviously -O3 fallout.
[23:18] <infinity> dbus-test-runner is a mystery to me.
[23:18] <wgrant> squid3 is -O3 too
[23:18] <wgrant> And a few others that I forget
[23:19] <wgrant> I don't see how libecap ever worked.
[23:22] <infinity> Oh, erm.  It's just symbols out of whack?  Yeah, that's weird.  Have an old log handy?
[23:22] <wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-all-logs/
[23:22] <wgrant> Beware, the listing is large
[23:23] <wgrant> http://people.canonical.com/~wgrant/ppc64el-prepurge-logs/primary-all-logs/buildlog_ubuntu-trusty-ppc64el.libecap_0.2.0-1ubuntu3_UPLOADING.txt.gz
[23:23] <wgrant> Oh
[23:23] <wgrant> Warnings are there, but non-fatal
[23:23] <infinity> Okay, so it's just that one symbol that went byebye.
[23:24] <wgrant> Could be -O3, I suppose
[23:24] <infinity> I wonder if it disappeared on all arches due to a dep changing.
[23:24] <infinity> Or possibly -O3...
[23:24] <wgrant> Given what it is.
[23:24] <infinity> iterator?  Yeah, maybe.
[23:24] <infinity> Looks like something that should be ignored anyway.
[23:24] <infinity> C++ symbols, for the loss.
[23:25] <infinity> Lemme have a poke at it.
[23:25] <infinity> So, handily, the only thing that links to it is squid3, which is FTBFS.
[23:26] <infinity> So, dropping the symbol is pretty much a non-issue even if it was referenced before.
[23:27] <infinity> But, for kicks, let's see if squid3 uses that symbol on x86...
[23:28] <wgrant> aptitude's link failure is somewhat disturbing, and not reproducible on amd64
[23:29] <infinity>   2567: 0000000000175e10   179 FUNC    WEAK   DEFAULT   13 _ZNSs12_S_constructIPcEES
[23:30] <infinity> Looks optional to me.
[23:33] <infinity> wgrant: aptitude is probably -O3, but unwinding why makes my head hurt.
[23:33] <wgrant> Indeed, I can't see what else it could be.
[23:33] <wgrant> But it's still pretty weird that it breaks like that.
[23:38] <pitti> infinity: hm, no binutils on ppc64el?
[23:38] <infinity> pitti: There will be.
[23:38] <pitti> dpkg-dev is uninstallable on ppc64el apparently
[23:38] <infinity> wgrant: Testing aptitude now.
[23:38] <infinity> pitti: I'll get it built in a sec.
[23:39] <infinity> Actually, I guess it can happen now.
[23:39] <pitti> infinity: ah, I wondered how I ran those autopkgtests on ppc64 yesterday; I re-bootstrapped the containers today, and it now magically got broken
[23:39] <pitti> but from what you say it has never existed yet
[23:40] <infinity> pitti: It existed in the previous incarnation of the archive. :P
[23:40] <pitti> infinity: ah, so I'm not going mad :)
[23:40] <infinity> pitti: You might also be doing that.
[23:40] <pitti> infinity: well, I'm going mad for a lot of other reasons, yes :)
[23:41] <pitti> (not to the least about killing two of my four ppc64el nodes already..)
[23:41] <infinity> pitti: Right.  So, I may not have warned everyone.  By the way, I broke ppc64el last night.
[23:41] <infinity> (Blame RedHat)
[23:42] <pitti> infinity: with the eglibc upload?
[23:42] <pitti> infinity: oh, perhaps that's the reason what killed wolfe04..
[23:42] <infinity> pitti: Yeah.  Dropped all the symbol versions from @2.18 to @2.17, dumped the contents of the archive, and rebuilt the world.
[23:42] <pitti> hah
[23:43] <pitti> infinity: so that explains the binutils lobotomy, thanks
[23:43] <wgrant> So the ppc64el linker is currently a complete hack.
[23:43] <infinity> COMPLETE HACK.
[23:43] <infinity> MORE UPPER CASE NEEDED.
[23:43] <wgrant> It remaps @GLIBC_2.18 to @GLIBC_2.17
[23:44] <pitti> ah, I've seen a complaint about that symbol earlier on
[23:44] <wgrant> So we don't have to do a full cross rebootstrap, just rebuild everything with the new eglibc
[23:44] <infinity> (And a hacked binutils)
[23:44] <wgrant> Some builds will explode until their build-deps are sane
[23:44] <wgrant> But it's been reasoanbly well behaved so far.
[23:44] <infinity> It's all working remarkably well, to be fair.  Not just reasonably well.
[23:45] <infinity> I'm waiting for the other shoe to drop.
[23:45] <wgrant> Indeed
[23:45] <infinity> pitti: Check the diff for 2.18-0ubuntu7 if you want to lose a small portion of your remaining sanity.
[23:49] <infinity> wgrant: aptitude happy with -O2, uploading hack^Wfix.
[23:50] <infinity> Well, it passed that link failure anyway.  Watch it fail later, now that I've uploaded.
[23:50] <wgrant> Heh
[23:51] <infinity> I need a way to tell soyuz "don't accept the binaries for this upload until I've looked at the build log because the maintainer doesn't believe in failing on testsuite breakages".
[23:51]  * infinity stares at binutils.
[23:54] <wgrant> :(
[23:54] <infinity> Kay, looks good.  Yay.
[23:55] <infinity> So, binutils in the archive should work fine for linking against any NEW binaries.
[23:55] <infinity> But will have an incredible sad trying to link against old stuff.
[23:56] <wgrant> You have a greater version in bootstrap, right?
[23:56] <infinity> wgrant: Yeahp.
[23:56] <infinity> wgrant: 3.1 instead of 3
[23:56] <infinity> wgrant: And doko's agreed not to upload binutils until I say it's cool (or will warn me first so I can reapply my hack)
[23:57] <infinity> But the way we're going, we probably only have a couple of days left, at most.
[23:57] <infinity> Assuming I get those other 8 VMs online tomorrow morning.
[23:57] <infinity> wgrant: And yeah, per our previous discussion, this seems to be the only "clean" way to change optimisation in a dh(1) package:
[23:58] <infinity> http://launchpadlibrarian.net/166583882/aptitude_0.6.8.2-1ubuntu3_0.6.8.2-1ubuntu4.diff.gz
[23:58] <wgrant> ew
[23:58] <wgrant> But yeah, another 8 VMs will have us done by Thursday.
[23:58] <wgrant> Easily.
[23:58] <infinity> wgrant: Which is just so many forms of icky.  Must see if we can do something less gross in debhelper or dpkg.