=== mwhudson is now known as zz_mwhudson [03:08] q === zz_mwhudson is now known as mwhudson === mwhudson is now known as zz_mwhudson [07:20] good morning [08:46] 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] Launchpad bug 1060543 in software-properties (Ubuntu) "Additional Drivers is not discoverable in Quantal" [Critical,In progress] [08:46] Unit193, hey, I'm not working on software-properties, maybe try mvo when he's around? [08:47] 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] if you have a patch just subscribe ubuntus-sponsors to the bug === psivaa-afk is now known as psivaa [09:04] seb128: Just a "mockup" of a desktop file. === Ursinha is now known as Ursinha-afk [09:33] ok so all upgrade bugs from lts to lts are fixed \o/ [09:49] does anyone know of any good information on the file POTFILES.in? what is it used for , and information on the format [09:54] brendand, did you try man intltool-update? [09:56] seb128, that's the tool i was looking for, thanks [09:57] brendand, yw! === Ursinha-afk is now known as Ursinha [10:00] seb128, sorry - what about the format? does it support globs? [10:02] seb128, and also types. some of the files i want to translate are qt/qml [10:06] brendand, not sure about those, I guess so [10:06] brendand, you should maybe look at some project using similar techs to yours as an example. [10:06] ? [10:09] hum [10:09] the ppc64el seem all on "manual", is that normal? [10:10] seb128: Yeah, it's temporary. [10:10] seb128: We're rebootstrapping the entire archive. Nothing to see here. [10:10] infinity, does it mean things are sutcked in trusty-proposed until that's resolved? [10:10] seb128, hmm seems qml apps avoid using POTFILES.in [10:10] (Should be back to autobuilding in an hour or so) [10:11] seb128, i guess intltool-update only supports gettext [10:11] seb128: For a little bit, but not long (see above). [10:11] brendand, could be, I'm not the best person to ask about that [10:11] infinity, thanks [10:12] dpm ? ^ [10:42] brendand, could you give me more context on your question about POTFILES.in? [10:43] dpm, i'm trying to figure out the best way to set up translations for my c++/qml package [10:44] dpm, i guessed intltool-update would be best to use, but it seems to not support qml [10:45] dpm, are there ubuntu touch core apps that have a c++ component? [10:45] brendand: take a look at ubuntu-system-settings [10:48] 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] 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] seb128, i'm not the guy to make that happen though :) [10:50] well, you were looking at it, who knows, maybe you would have found a way [10:50] seb128, we're trying to get this package into main so we need translations set up [10:51] 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] dpm: it's in lp:checkbox but in the checkbox-gui directory [10:53] 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] with qmake it was a bit easier, but still not optimal [10:54] seb128: compiz and bamf built, were those the ones you were worrying about? [10:54] infinity, I'm watching the builds, nux and unity still [10:54] infinity, but yeah, those 2 were part of the unity update [10:55] seb128: yeah, but I think the problem is that intltool just doesn't support qml at all, let alone ubuntu sdk qml [10:55] the xgettext call we have encodes 'tr' as a thing to look for [10:56] 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] dholbach, the cordova binaries are a bit weird, they install their .so in /usr/share ... is that wanted? [10:57] It's never wanted. [10:57] Unless those are magical arch-indep libraries. [10:57] that package is quite hackish, I don't like much [10:57] 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] If they're not following FHS, that's absolutely a reason to reject. [10:58] infinity, they are not, but that package is weird, it's basically a "provide files for clicks to copy/embed" [10:59] Ahh, binaries in /usr/share make sense in that context. But they still shouldn't overlap between arches, if they currently do. [10:59] /usr/share/cordova-ubuntu-3.4/www/libcoreplugins.so [10:59] so yeah, they do [11:00] Yeah, so no indication of what arch that .so is for... [11:00] dholbach, can we get that fixed? [11:01] 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] 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] but if it does the job/unblock people... [11:03] 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] infinity, yeah, you should get some sleep! [11:05] infinity, have a good night [11:05] seb128: I'll try. :) [11:15] seb128, AFAIK (I'm just trying to help the team get things landed): the SDK will download : from the archive and bundle that the runtime in the click package [11:16] dholbach, what if you try to dev for e.g i386 and armhf on the same machine? [11:16] those conflict atm [11:16] seb128, AFAIK they're not necessarily required to be installed on the developers machine, but I might be wrong [11:17] well, they are in the archive, so nothing prevent you to apt-get install them [11:17] dbarth and team would be the people to answer this - maybe we should discuss it on https://launchpad.net/bugs/1279814? [11:17] Launchpad bug 1279814 in Cordova Ubuntu "[needs-packaging] Get cordova-ubuntu-3.4 into trusty release" [Critical,Fix committed] [11:18] well, as said before, I'm busy enough with other things and I don't know much about the cordova thing [11:18] ok [11:18] 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] they are a bit hackish/wrong but that's not the end of the world imho [11:20] thanks seb128, infinity [11:21] yw [11:22] 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] done [11:22] cjwatson, thanks [11:23] (not really here, just going again) [11:23] (good timing for not being here, thanks again ;-) [11:24] That really wasn't necessary... [11:24] 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] oh, that was a release pocket build? [11:25] right, matters not [11:25] *shrug* it'll all churn through anyway [11:26] I expect seb128 actually identified the wrong build from proposed-migration [11:26] shrug, indeed [11:26] I wanted https://launchpad.net/ubuntu/+source/unity/7.1.2+14.04.20140214.1-0ubuntu1/+build/5607904 [11:26] The proposed one is dep-waiting for a publisher cycle. [11:26] which is needs-build now and about to start [11:26] Or, was. [11:26] I got confused by the lp table lines order and clicked on the wrong version [11:26] everything in -proposed will build before anything in the release pocket [11:26] cjwatson, infinity: thanks [11:26] oh, nice [11:26] so actually your request slowed more important things down [11:26] oh well, not by much [11:26] :-( [11:27] sorry about that [11:27] S'ok. I'm still banking on main being done in just over a day. [11:27] I cancelled the build of the other version [11:27] you still planning to commandeer more hardware? [11:27] seb128: just leave it please [11:27] cjwatson: Yeah, but not until Tuesday, when I can get pinky to twiddle some cables. [11:27] And main will probably be done by then. [11:28] too late, sorry again :-( [11:28] seb128: rule of thumb for today: don't try to micromanage ppc64el :) [11:28] yeah, I just learnt that I think [11:28] I've retried that cancelled build for consistency's sake [11:28] * seb128 justs wants that unity in trusty :p [11:29] anyway, we should be good once the proposed build finish [11:29] so I'm staying away from builders now [11:29] thanks again ;-) [11:40] infinity: I'd certainly expect the whole thing to be quicker than the predicted five days [11:45] cjwatson: I gave myself a lot of padding in my estimates. [11:45] cjwatson: Years of "5-minute-fix" engineering estimates have taught me some valuable lessons. [11:46] 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] 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] 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] Plus the failures, which I'll work out in a moment. [11:54] 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] Yep [11:55] And if we don't need 'em, whatever. But handy to have them. [11:58] Looks like about 950 if we include failures. [11:58] Still, not very many days. [11:59] 4 days, plus an extra for proposed churn, I'd say... [11:59] Hits my 5 day mark almost on the head. But 8 more VMs will win the day. [12:01] doko_, infinity .... why does libgcc nowadays depend on gcc-4.9 ? [12:01] seems a recent change pulled the compiler into the touch image [12:01] ogra_: It doesn't. [12:01] ogra_: gcc-4.9-base isn't a compiler. [12:01] ogra_: You already had gcc-4.8-base [12:01] http://people.canonical.com/~ogra/touch-image-stats/20140214.3.changes [12:02] ah [12:02] why isnt 4.8 not dropped then ? [12:02] -not [12:02] ogra_: libgcc1 is 4.9, but you still have other libs from 4.8 (probably libstdc++6, at least) [12:02] hmm, k [12:02] ogra_: because 4.8 is default for C/C++, whilst 4.9 is default for Go on armhf/arm64/ppc64el [12:02] ogra_: So, you need both -base packages. They're tiny, no big deal. [12:02] ok === doko_ is now known as doko [12:07] neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change? [12:07] they are on oakland iirc [12:08] should come online in a while [12:08] right, QA is in Oakland this week === MacSlow is now known as MacSlow|lunch [12:29] 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] cjwatson, doko, seb128 ^ [12:30] infinity, noted, thanks === tkamppeter_ is now known as tkamppeter === Pici` is now known as Pici [13:45] dpm, hello again [13:45] dpm, all the packages you pointed to seem to involve cmake at some stage [13:45] dpm, can we avoid introducing cmake into the chain? [13:46] 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] that was before the cmake switch [14:07] doko, any ideas? https://launchpadlibrarian.net/166508215/buildlog_ubuntu-trusty-ppc64el.gccgo-go_1.2-0ubuntu5_FAILEDTOBUILD.txt.gz [14:07] that upload failed with the same error on armhf, powerpc and ppc64el [14:07] yes, known [14:07] doko, ok [14:13] Good morning [14:14] neither pitti nor jibel online ... and python2.7, python3.3, python3.4 autopkg tests are failing. did the test env change? [14:14] I just saw [14:14] I added proxy vars so that tests can talk to the network [14:15] but apparently that's confusing some things [14:15] pitti, when did you add them? [14:15] I wanted to revert that for now, but now I can't build any fresh VMs any more [14:15] pitti: morning :) [14:15] it seems the latest cloud-image upload from Feb 14 broke VM building entirely, looking at that now [14:15] seb128: Feb 11 or so [14:15] k [14:16] 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] I guess the software-properties tests started failing for another reason [14:17] pitti: which apparently requires a script to be added, wouldn't that be needed in main auto-upgrade-testing? [14:18] 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? === MacSlow|lunch is now known as MacSlow [14:23] pitti: so, any thoughts? [14:23] shadeslayer: sorry, stack overflow [14:24] hah :D [14:24] tons of IRC scrollback, and I mostly wanted to see whether I can catch smoser before Europe goes EOD [14:25] 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] 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] doko: so in short, it's on my radar, I'll fix it today [14:27] cool, tanks [14:27] 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] 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] pitti: ack, I'll try and update the branch [14:33] smoser: last known working image is from Freb 14 [14:33] Feb [14:36] 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:36] bug 1278822 in plainbox-provider-checkbox (Ubuntu) "[MIR] plainbox-provider-checkbox" [Undecided,Fix committed] https://launchpad.net/bugs/1278822 [14:36] bug 1277408 in checkbox-ng (Ubuntu) "[MIR] checkbox-ng" [Undecided,Fix committed] https://launchpad.net/bugs/1277408 [14:37] doko: Ideally we'd like to see both of them in main before Thursday [14:42] 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] pitti, check your serial cable [14:43] * ogra_ grins [14:50] did anyone notice that gpg-agent has stopped saying which key it's prompting you for? [14:51] Laney: is it the result of using ssh-agent, instead of gnome-keyring secrets agent? [14:51] doubt it, this is inside a container [14:52] Godd afternoon! I'm wondering why 4.5.0-2 is stuck in proposed https://launchpad.net/ubuntu/+source/insighttoolkit4 .... [14:54] (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] mapreri: stale library left around in -proposed, looking [14:55] cjwatson: great, thank you! [14:55] plastimatch will need to be rebuilt against the new version [14:56] let me quickly do that now [14:56] cjwatson: can I know how do you find it? (just to learn something new...) [14:56] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#insighttoolkit4 [14:56] plus experience [14:58] and checkrdepends against an archive mirror to find the reverse-deps of that library in -propsoed [14:58] *-proposed [14:59] uh [14:59] * mapreri takes note.... [14:59] 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] cjwatson: I'll check in a few hours, thanks again === freeflying is now known as freeflying_away [15:14] does anyone know what is missing to make indicator-datetime/unity-control-center migrates? [15:14] indicator-datetime stopped building unity-control-center-datetime [15:14] unity-control-center C,R,P it [15:14] so the binary should be NBS and provided by u-c-c [15:14] that should be enough no? [15:35] 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] 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] seb128: sounds like it now grew a missing gir1.2-gtk-3.0 test dep? [15:37] (or perhaps binary dep, not sure) [15:37] pitti, looks like [15:37] darkxst, ^ can you look at that/get it sorted out (since you did that update) === vibhav is now known as Guest49842 [15:56] 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] does britney consider those two packages together or each for it's own if it can transition? [16:01] rbasak, could you have a look at the php5 merge? [16:07] geser, each one it seems [16:07] Laney, can you hint britney to consider both together? [16:09] worth a try [16:10] Laney, thanks [16:16] doko: ack. [16:18] seb128: if it doesn't work I guess you can remove the package and fix the seeds to not pull it in [16:19] 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] jus' saying, that'll probably help with the migration [16:20] right [16:20] let's see at the next run with the hint [16:22] 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] doko: you mean 5.5.9, right? 5.6 is in experimental, but I'm not sure that's a good idea. [16:31] 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] geser, Laney: britney hint worked ;-) [16:50] neat [16:52] 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] 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] and not in the system === FliesLik1ABrick is now known as FliesLikeABrick [16:59] pitti, huuuummm [16:59] pitti, why did gtk migrate to the release pocket while gjs tests are still red? [16:59] pitti, not that complain about gtk migrating, but that seems buggy [17:00] adt migration bugs are usually jibel [17:00] seb128: we had the same problem last week with the libgcc bug [17:00] he was looking into it iirc [17:00] cjwatson, seems to only affect my 32bit box ... amd64 seems happy === jasoncwarner__ is now known as jasoncwarner [17:04] jibel, ^ [17:10] rbasak, yes, 5.5.9, please not an alpha ;) [17:18] stgraber: can you leave in the lxc proxy hack? I'm going to revert it from the VMs for now [17:18] stgraber: it breaks too many things, and e. g. glib and python have different ideas about how these variables work [17:21] pitti: ok [17:22] 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, any hint about https://launchpad.net/ubuntu/+archive/test-rebuild-20140127/+build/5518972 ? there are about 100 build failures like this one [17:22] stgraber: I don't currently have any plan of changing what we have in a major way [17:22] rbasak, ^^^ [17:23] 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] 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] oh, nice [17:24] 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] stgraber: yes, agreed [17:25] stgraber: but TBH I'd leave that to 14.10 [17:25] 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] 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] 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] 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 === jono is now known as Guest43181 [17:50] 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] 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] stgraber: we still want the shim to work properly for Debian, though, right? [17:53] 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] cjwatson, ahhh yes this is the machine i got rid of the separate /boot from because it was far toooo small [18:08] 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] (also some other side-effects of similar kinds, but that's the one you're most likely to notice) [18:09] 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] dunno about that [18:11] stgraber: hi, can you approve bug #1279229 please? I've verified the fix [18:11] bug 1279229 in jockey (Ubuntu Precise) "Jockey is unable to check Saucy's xserver ABI" [High,Fix committed] https://launchpad.net/bugs/1279229 [19:02] 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] stgraber: but of course that rips out the underlying FS for any running containers [19:03] stgraber: are you aware of an existing solution how to provide daily updated containers when they also might be running? === TheLordOfTime is now known as teward [19:05] pitti: as in, you have containers using that one as a base with overlayfs or aufs? [19:05] right, with ephemeral [19:05] stgraber: I want to use that on the machines that run autopkgtests (arm/ppc64el) [19:05] hmm, best guess would be to create your .new, then rsync the rootfs [19:06] stgraber: I can of coure add some lock file mechanism so that the update job always runs alone [19:06] so you'll never end up with an empty underlay, and it should update pretty quickly [19:07] stgraber: but if I rsync the new rootfs into the old container, doesn't that also create inconsistent file systems? [19:07] (rsync -A --numeric-ids --sparse --hard-links --delete trusty.new/rootfs/ trusty/rootfs/) [19:07] yeah, it'd be inconsistent for a tiny bit of time [19:08] it's a tradeoff, either you have an update script as yours which will only apply to new containers [19:08] 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] or you have something using rsync which will also apply to running containers [19:09] right, no reason to copy a new config, fstab, ... those don't change, you only really care about the rootfs [19:09] stgraber: ack [19:09] stgraber: many thanks! [19:20] 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] bug 1279048 in cgmanager (Ubuntu) "[MIR] cgmanager" [Undecided,New] https://launchpad.net/bugs/1279048 [19:20] 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] pitti, glibc didn't change yet. (I mean glibc-2.19 wasn't yet uploaded) [19:30] 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] 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] 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] robru, yes, thats why i ping you, because i know you were involved [19:59] robru, G+ does definitely not work with that [20:00] oh... [20:00] (most likely needs a hacked user agent) [20:00] ogra_, is there a bug filed? [20:00] not by me, i just noticed it before i pinged you [20:01] ogra_, ok, please file a bug and assign it to justinmcp [20:03] anyone know why I am getting: can't build with source format '3.0 (quilt)' [20:04] robru, against what, webapp-contsainer ? [20:04] *container [20:04] ogra_, nah, unity-webapps-googleplus [20:05] ok [20:05] nvm, got it [20:19] robru, ogra_ g+ app is owned by xnox [20:19] robru, ogra_ nvm, wrong channel :-) just the click one ;-) [20:19] sergiusens: well, i've submitted g+ app update, but it got rejected [20:20] * sergiusens checks [20:23] xnox, just add --webappUrlPatterns [21:29] I dput a new build in my ppa for tahr and it isn't showing up, what should I check? [21:29] if I try to reupload it says package exists [21:29] I don't see it in my build queue etc [21:33] nvrpunk: Which PPA? [21:33] tim.l.nelson/ppa [21:33] err [21:34] tim-l-nelson/ppa [21:34] nvm [21:34] i think i got it [21:35] Mmkay. [21:36] i think i need to create a new ppa, my first one was for Saucy [21:37] You can use the same PPA for trusty, saucy, precise, etc. [21:38] ^ that [21:39] nvrpunk: What matters is what distribution is in the .changes file. [21:39] nvrpunk: (Or, alternately, the magic path you dput to, but that's a bit sketchier) [21:41] Version: 8.6.1-4ubuntu1ppa1 [21:41] Distribution: trusty [21:41] looks like my versioning and distribution are correct, I just don't see it queued to build etc [21:41] I dput it an hour ago or so [21:42] it should show in my "recent activities" correct? [21:43] nvrpunk: did you upload the same version before and then delete the packages from your ppa? [21:43] no [21:43] unless I uploaded 8.6 months ago and forgot, but I don't recall doing that [21:44] and if I did it was most likely rejected because I had no clue what I was doing months ago [21:54] yeah, I am at a loss [21:54] never had this happen [21:54] i have installed gnome-shell package in my kubuntu box ==> unable to login [21:55] this is not nice [22:03] nvrpunk: You signed the .changes file with an OpenPGP key that isn't associated with your Launchpad account. [22:03] 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] wgrant: are the PPA uploaders lagged at the moment? [22:04] oops i meant to point to #launchpad but I hate laptop touchpads, they clicked me to here [22:04] >.> [22:04] teward: No, no issues. [22:07] teward: Are you seeing delays? [22:07] wgrant: yeah, 5 - 10 minute upload gap between amd64 and i386 [22:07] was causing bug triage problems for an upstream project, hence why i meant this to go to #launchpad [22:07] it *just* resolved itself [22:07] teward: Oh, binary uploads? [22:07] mhm [22:08] wgrant: yeah, the upload of the built binaries [22:08] not the upload of the source package [22:08] * teward was imprecise in his explanation of the issue [22:08] wgrant: well I imported my keys from my old install ~/.gnupg [22:08] 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] wgrant: then set my DEBFULLNAME and DEBEMAIL and I assume that should be my old key? [22:09] if I no longer have my key how do I update that? [22:09] 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] but you're right the completion was a different issue [22:10] nvrpunk: debuild will have told you which key it used. Compare that to the one at https://launchpad.net/~/+editpgpkeys [22:10] teward: You can hover over an "X minutes ago" timestamp to get the precise time. [22:10] wgrant: still, it took a while even *after* building to upload, and it seemed uncharacteristically slow === sem is now known as Peace- [22:10] Nothing's been delayed by more than two minutes in several hours. [22:11] * teward shrugs [22:11] 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] i shouldn't be doing packaging stuffs while tired >.< [22:13] Heh === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [22:27] wgrant, thanks I updated my key [22:27] will that cause them to build now? [22:27] or will i have to wait on some form of rejection? [22:28] nvrpunk: No, you'll need to upload the package again [22:28] ok lol [22:28] All your existing uploads were rejected. [22:28] Because the key was unverifiable. [22:29] Package has already been uploaded to ppa on ppa.launchpad.net [22:29] dput -f [22:29] does that matter?> [22:29] ok [22:29] it's like you read my mind :D [22:30] or saw my failure [22:30] The latter, I'm not that good. [22:37] infinity: Holy crap, the rebuild finished main already. [22:38] (Modulo builds in progress.) [22:39] Yeah [22:39] I didn't believe it, but I can't see that anything went wrong. [22:40]