[00:26] Hi, I have a metapackage I built from a guide here: http://askubuntu.com/a/33417/334829 [00:26] I used dput to push it to a PPA [00:26] it looks like it worked in the terminal, but it isn't showing up in Launchpad [00:27] and it's been a few hours [00:27] I just tried again [00:27] any suggestions? [00:43] tsimonq2: 2016-03-21 00:25:14 INFO Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20160321-002432-010313/~tsimonq2/lxqt-meta/lubuntu-lxqt-metapackage_1.0_source.changes': Signing key CB6CA67C250D4C3CC544C8367A3279337B6D022D not registered in launchpad. [02:54] wgrant: oh, well, thank you :) [03:06] wgrant: you would think they would report an error somehow? [03:10] tsimonq2: since we don't know about the key we don't know who to report the error to. [03:11] wgrant: but the PPA belongs to me? [03:11] tsimonq2: Doesn't mean that somebody else didn't upload a dodgy package to your PPA to spam you. [03:13] wgrant: aha okay thank you forclarifying :) [03:13] wgrant: so I need an SSH or PGP key in LP? [03:14] tsimonq2: The .changes file that you upload requires an OpenPGP signature from a key that's linked to your Launchpad account. [03:21] wgrant: how do I confirm this? [03:22] tsimonq2: dput will list the fingerprint if the file it's uploading is signed. Compare it to the list of OpenPGP fingerprints on your Launchpad profile. [03:24] okay thank you :) [03:49] wgrant: while I'm here, can I have my default email address sent to my gmail address while having all of my email go to my @u.c email? or do I not need to have my @g.c email set as default for my @u.c to be working? [03:50] *set [03:51] tsimonq2: Your @u.c email address will forward to your primary address in Launchpad. [03:51] So I guess the answer is "yes", because that's the only possible scenario. [03:51] (unless you add a third address) [03:53] but LP sends all notifications and such to my @g.c, and it would be awesome if it could send to my @u.c [03:53] that really should get further customizability [03:54] Does it make a difference? The @u.c address is just an alias. [03:54] Anyway, that's not something Launchpad can change -- Canonical IS manages the aliases, just using the Launchpad API to get the data. [03:54] well sqawesome99@gmail.com is just really stupid :) [03:55] OH so if I talk to IS maybe I can just remove my @g.c address altogether and have them point it to that? [03:55] do you think IS would be able to do that? [03:55] I don't think they have that facility. https://wiki.ubuntu.com/UbuntuEmail documents most of this studd. [03:55] stuff [03:57] you think it would be worth it to ask in #canonical-sysadmin tomorrow? [03:58] I've never heard of it being done before, but it's possible. [03:58] Or email RT. [03:58] alright I'll do that :) === heroux_ is now known as heroux === Peng__ is now known as Peng [17:44] news on the debian import issue? [17:44] mapreri: all patches landed, awaiting deployment [17:44] mapreri: (somewhat impeded by my home ADSL being down so that one of the deployment request mails hasn't gone out yet) [17:45] cjwatson: guess it'll be all settled tomorrow, then. [17:46] Should be [17:46] funny how today dinstall is broken, instead. so no uploads since yesterday afternoon have been published :) [17:46] Schadenfreude [17:47] hihi [17:47] (btw, wrong lang, but google translate helped) [17:48] Well. I consider that an (imported) English word too [17:49] And while you can express the same concept in a phrase, there's no other single word for it :-) [17:50] well, never heard of it, but indeed wikipedia en has a page on it [17:50] AND, it's really too new :D https://books.google.com/ngrams/graph?year_start=1800&year_end=2008&corpus=15&smoothing=7&case_insensitive=on&content=schadenfreude&direct_url=t4%3B%2Cschadenfreude%3B%2Cc0%3B%2Cs0%3B%3BSchadenfreude%3B%2Cc0%3B%3Bschadenfreude%3B%2Cc0 [17:51] it's a living language, what do you want of me :) [17:52] cjwatson: back in topic for this chan, i have this thing, where those two "cancelled build" won't go away https://code.launchpad.net/~scribus/+recipe/scribus-daily [17:52] I cancelled them yesterday to avoid useless build while testing a thing, fwiw [17:52] mapreri: probably wrong sort order on the relevant query, will require a code change and possibly also a db index change - please file a bug [17:53] wow [17:53] I fixed a similar thing for livefses a while back [17:53] suggestion for a title? [17:54] in that case it was because the sort order included Greatest(LiveFSBuild.date_started, LiveFSBuild.date_finished) and if one was NULL then that would always sort first [17:55] mapreri: see bug 1424672 [17:55] bug 1424672 in Launchpad itself "LiveFS builds cancelled before they start sort above other builds in history" [Low,Fix released] https://launchpad.net/bugs/1424672 [17:55] * mapreri copies the bug [18:22] btw, why the source pacakge built by a recipe are 3.0 (native) ? [18:23] they aren't necessarily [18:24] dobey: well, they are here, even if my debian repository contains a d/s/format with 3.0 (quilt). also it contains quilt patches which are somehow applied, even. [18:25] bzr-builder/git-build-recipe flatten 3.0 (quilt) to 3.0 (native), I think so that they don't have to deal with getting an orig put in place. [18:25] mapreri: anyway, recipes are built as native packages because they don't have the orig tarball [18:25] since they're building from a bzr tree [18:25] umh, is getting a tarball out of a VCS that hard? [18:25] but I see. [18:26] i don't see why it matters really [18:26] It's a pain to do it properly with bzr [18:26] indeed it is a pain [18:26] just it annoys me, as then I have to deal with a 3.0 (native) when downloading the built source (and try out stuff with it) [18:26] It's easier with git if set up properly [18:26] But it's also an extra chunk of stuff people have to set up ... [18:26] well, bzr export does a decent job [18:27] Also: the tools only do this if they can't find a pristine tarball [18:27] but if you have the debian/ dir in the vcs, it gets a bit more annoying [18:27] If you're seeing this happening, it's an indication that they tried and failed, but needed to fall back [18:28] * mapreri lost where the discussion is going [18:28] more a statement, than a discussion :) [18:28] In the bzr case, it would be because there's no upstream-WHATEVER or upstream/WHATEVER tag corresponding to the orig version in question [18:29] So nothing to reliably export [18:29] Creating such a tag would probably fix it [18:29] umh, in my case where I have a daily recipe, would just be tarball out the current HEAD [18:29] which is fine if the upstream tree is the bzr repo you're using [18:29] then you have a .orig, [18:29] That's nice, but bzr-builder won't do that [18:30] Unless there's an explicit tag [18:30] and just use the very same directory to `dpkg-soruce -b .` and you'll have every. [18:30] everything* [18:30] And honestly, I'd rather not touch bzr-builder at all ever :) [18:30] if you're building a git->bzr import, tagging gets a bit more complicated [18:30] here I have a svn → bzr import, where tags are not really a thing :) [18:30] Yeah, we'll hopefully have git->git imports pretty soon though, so that'll obviate that [18:30] Right, I'm afraid you'll have to cope with 3.0 (native) in that case, sorry [18:30] a usable thing, at least [18:31] mapreri: is debian/ in the upstream vcs tree, or a separate branch you nest? [18:31] are we going to have svn→git imports sometime in the future before svn disappear? [18:31] Don't know [18:31] svn disappear? haha [18:31] good joke :) [18:31] dobey: on a separate repo. under bzr, which makes everything more painful as I'd love to cherry-pick from the git repo I use for debian, instead of manually copy patches [18:32] I imagine it could be fitted into the existing code import infrastructure somehow, but unlikely to be in the next several months at least [18:32] mapreri: why not import the git repo to a bzr tree? [18:32] luckily I don't touch this often, I'm only spending a day on improving everything, probably I won't come back until the next release in 6 months or so [18:33] of course i guess that becomes problematic if a patch gets merged upstream or such [18:33] dobey: I don't know bzr really. I just add/commit/rm/uncommit/push [18:33] everything else needs googling. [18:34] Ah good, my mail server managed to squeeze the mail for my deployment request from earlier up my ADSL line during the few minutes it was back [18:34] cool! [18:34] though I guess everybody is out by this time [18:34] so it'll need to wait tomorrow? [18:35] s/out/off/ ← this should be more English [18:35] We have American sysadmin coverage [18:35] And Asia-Pacific, for that matter [18:35] ^^ [18:35] It'll probably be picked up by one of those shifts [18:36] mapreri: do you need to maintain a difference between your bzr packaging branch and the git repo used for debian? [18:37] dobey: not really a "need", no [18:37] also, it's not a so live package that needs constant love with lots of releases, etc [18:38] mapreri: if you don't need to change anything under debian/, you could just set up an import from the git repo to a bzr branch, instead of having to maintain a bzr branch and copy patches over or whatever [18:38] dobey: bzr repo contains only debian (in the root of the directory). git repo is a standard gbp repo with everything [18:38] how would you do it? [18:38] mapreri: you can use nest-part in the recipe [18:39] "shrugs", I don't find this particularly daunting anyway [18:39] well, just a suggestion to make life slightly easier for you :) [18:40] i'll consider, some other day :) [18:42] ok, I'll be off now. o/ [18:43] cheers