[00:26] <tsimonq2> Hi, I have a metapackage I built from a guide here: http://askubuntu.com/a/33417/334829
[00:26] <tsimonq2> I used dput to push it to a PPA
[00:26] <tsimonq2> it looks like it worked in the terminal, but it isn't showing up in Launchpad
[00:27] <tsimonq2> and it's been a few hours
[00:27] <tsimonq2> I just tried again
[00:27] <tsimonq2> any suggestions?
[00:43] <wgrant> 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] <tsimonq2> wgrant: oh, well, thank you :)
[03:06] <tsimonq2> wgrant: you would think they would report an error somehow?
[03:10] <wgrant> tsimonq2: since we don't know about the key we don't know who to report the error to.
[03:11] <tsimonq2> wgrant: but the PPA belongs to me?
[03:11] <wgrant> tsimonq2: Doesn't mean that somebody else didn't upload a dodgy package to your PPA to spam you.
[03:13] <tsimonq2> wgrant: aha okay thank you forclarifying :)
[03:13] <tsimonq2> wgrant: so I need an SSH or PGP key in LP?
[03:14] <wgrant> tsimonq2: The .changes file that you upload requires an OpenPGP signature from a key that's linked to your Launchpad account.
[03:21] <tsimonq2> wgrant: how do I confirm this?
[03:22] <wgrant> 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] <tsimonq2> okay thank you :)
[03:49] <tsimonq2> 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] <tsimonq2> *set
[03:51] <wgrant> tsimonq2: Your @u.c email address will forward to your primary address in Launchpad.
[03:51] <wgrant> So I guess the answer is "yes", because that's the only possible scenario.
[03:51] <wgrant> (unless you add a third address)
[03:53] <tsimonq2> 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] <tsimonq2> that really should get further customizability
[03:54] <wgrant> Does it make a difference? The @u.c address is just an alias.
[03:54] <wgrant> Anyway, that's not something Launchpad can change -- Canonical IS manages the aliases, just using the Launchpad API to get the data.
[03:54] <tsimonq2> well sqawesome99@gmail.com is just really stupid :)
[03:55] <tsimonq2> 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] <tsimonq2> do you think IS would be able to do that?
[03:55] <wgrant> I don't think they have that facility. https://wiki.ubuntu.com/UbuntuEmail documents most of this studd.
[03:55] <wgrant> stuff
[03:57] <tsimonq2> you think it would be worth it to ask in #canonical-sysadmin tomorrow?
[03:58] <wgrant> I've never heard of it being done before, but it's possible.
[03:58] <wgrant> Or email RT.
[03:58] <tsimonq2> alright I'll do that :)
[17:44] <mapreri> news on the debian import issue?
[17:44] <cjwatson> mapreri: all patches landed, awaiting deployment
[17:44] <cjwatson> mapreri: (somewhat impeded by my home ADSL being down so that one of the deployment request mails hasn't gone out yet)
[17:45] <mapreri> cjwatson: guess it'll be all settled tomorrow, then.
[17:46] <cjwatson> Should be
[17:46] <mapreri> funny how today dinstall is broken, instead.  so no uploads since yesterday afternoon have been published :)
[17:46] <cjwatson> Schadenfreude
[17:47] <mapreri> hihi
[17:47] <mapreri> (btw, wrong lang, but google translate helped)
[17:48] <cjwatson> Well.  I consider that an (imported) English word too
[17:49] <cjwatson> And while you can express the same concept in a phrase, there's no other single word for it :-)
[17:50] <mapreri> well, never heard of it, but indeed wikipedia en has a page on it
[17:50] <mapreri> 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] <cjwatson> it's a living language, what do you want of me :)
[17:52] <mapreri> 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] <mapreri> I cancelled them yesterday to avoid useless build while testing a thing, fwiw
[17:52] <cjwatson> 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] <mapreri> wow
[17:53] <cjwatson> I fixed a similar thing for livefses a while back
[17:53] <mapreri> suggestion for a title?
[17:54] <cjwatson> 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] <cjwatson> mapreri: see bug 1424672
[17:55]  * mapreri copies the bug
[18:22] <mapreri> btw, why the source pacakge built by a recipe are 3.0 (native) ?
[18:23] <dobey> they aren't necessarily
[18:24] <mapreri> 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] <cjwatson> 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] <dobey> mapreri: anyway, recipes are built as native packages because they don't have the orig tarball
[18:25] <dobey> since they're building from a bzr tree
[18:25] <mapreri> umh, is getting a tarball out of a VCS that hard?
[18:25] <mapreri> but I see.
[18:26] <dobey> i don't see why it matters really
[18:26] <cjwatson> It's a pain to do it properly with bzr
[18:26] <dobey> indeed it is a pain
[18:26] <mapreri> 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] <cjwatson> It's easier with git if set up properly
[18:26] <cjwatson> But it's also an extra chunk of stuff people have to set up ...
[18:26] <dobey> well, bzr export does a decent job
[18:27] <cjwatson> Also: the tools only do this if they can't find a pristine tarball
[18:27] <dobey> but if you have the debian/ dir in the vcs, it gets a bit more annoying
[18:27] <cjwatson> 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] <dobey> more a statement, than a discussion :)
[18:28] <cjwatson> 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] <cjwatson> So nothing to reliably export
[18:29] <cjwatson> Creating such a tag would probably fix it
[18:29] <mapreri> umh, in my case where I have a daily recipe, would just be tarball out the current HEAD
[18:29] <dobey> which is fine if the upstream tree is the bzr repo you're using
[18:29] <mapreri> then you have a .orig,
[18:29] <cjwatson> That's nice, but bzr-builder won't do that
[18:30] <cjwatson> Unless there's an explicit tag
[18:30] <mapreri> and just use the very same directory to `dpkg-soruce -b .` and you'll have every.
[18:30] <mapreri> everything*
[18:30] <cjwatson> And honestly, I'd rather not touch bzr-builder at all ever :)
[18:30] <dobey> if you're building a git->bzr import, tagging gets a bit more complicated
[18:30] <mapreri> here I have a svn → bzr import, where tags are not really a thing :)
[18:30] <cjwatson> Yeah, we'll hopefully have git->git imports pretty soon though, so that'll obviate that
[18:30] <cjwatson> Right, I'm afraid you'll have to cope with 3.0 (native) in that case, sorry
[18:30] <mapreri> a usable thing, at least
[18:31] <dobey> mapreri: is debian/ in the upstream vcs tree, or a separate branch you nest?
[18:31] <mapreri> are we going to have svn→git imports sometime in the future before svn disappear?
[18:31] <cjwatson> Don't know
[18:31] <dobey> svn disappear? haha
[18:31] <dobey> good joke :)
[18:31] <mapreri> 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] <cjwatson> 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] <dobey> mapreri: why not import the git repo to a bzr tree?
[18:32] <mapreri> 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] <dobey> of course i guess that becomes problematic if a patch gets merged upstream or such
[18:33] <mapreri> dobey: I don't know bzr really.  I just add/commit/rm/uncommit/push
[18:33] <mapreri> everything else needs googling.
[18:34] <cjwatson> 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] <mapreri> cool!
[18:34] <mapreri> though I guess everybody is out by this time
[18:34] <mapreri> so it'll need to wait tomorrow?
[18:35] <mapreri> s/out/off/  ← this should be more English
[18:35] <cjwatson> We have American sysadmin coverage
[18:35] <cjwatson> And Asia-Pacific, for that matter
[18:35] <mapreri> ^^
[18:35] <cjwatson> It'll probably be picked up by one of those shifts
[18:36] <dobey> mapreri: do you need to maintain a difference between your bzr packaging branch and the git repo used for debian?
[18:37] <mapreri> dobey: not really a "need", no
[18:37] <mapreri> also, it's not a so live package that needs constant love with lots of releases, etc
[18:38] <dobey> 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] <mapreri> dobey: bzr repo contains only debian (in the root of the directory).  git repo is a standard gbp repo with everything
[18:38] <mapreri> how would you do it?
[18:38] <dobey> mapreri: you can use nest-part in the recipe
[18:39] <mapreri> "shrugs", I don't find this particularly daunting anyway
[18:39] <dobey> well, just a suggestion to make life slightly easier for you :)
[18:40] <mapreri> i'll consider, some other day :)
[18:42] <mapreri> ok, I'll be off now. o/
[18:43] <dobey> cheers