| 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:26 |
| tsimonq2 | and it's been a few hours | 00:27 |
| tsimonq2 | I just tried again | 00:27 |
| tsimonq2 | any suggestions? | 00:27 |
| 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. | 00:43 |
| tsimonq2 | wgrant: oh, well, thank you :) | 02:54 |
| tsimonq2 | wgrant: you would think they would report an error somehow? | 03:06 |
| wgrant | tsimonq2: since we don't know about the key we don't know who to report the error to. | 03:10 |
| 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:11 |
| tsimonq2 | wgrant: aha okay thank you forclarifying :) | 03:13 |
| tsimonq2 | wgrant: so I need an SSH or PGP key in LP? | 03:13 |
| wgrant | tsimonq2: The .changes file that you upload requires an OpenPGP signature from a key that's linked to your Launchpad account. | 03:14 |
| tsimonq2 | wgrant: how do I confirm this? | 03:21 |
| 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:22 |
| tsimonq2 | okay thank you :) | 03:24 |
| 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:49 |
| tsimonq2 | *set | 03:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| tsimonq2 | you think it would be worth it to ask in #canonical-sysadmin tomorrow? | 03:57 |
| 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 :) | 03:58 |
| === heroux_ is now known as heroux | ||
| === Peng__ is now known as Peng | ||
| 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:44 |
| mapreri | cjwatson: guess it'll be all settled tomorrow, then. | 17:45 |
| 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:46 |
| mapreri | hihi | 17:47 |
| mapreri | (btw, wrong lang, but google translate helped) | 17:47 |
| cjwatson | Well. I consider that an (imported) English word too | 17:48 |
| cjwatson | And while you can express the same concept in a phrase, there's no other single word for it :-) | 17:49 |
| 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:50 |
| cjwatson | it's a living language, what do you want of me :) | 17:51 |
| 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:52 |
| mapreri | wow | 17:53 |
| cjwatson | I fixed a similar thing for livefses a while back | 17:53 |
| mapreri | suggestion for a title? | 17:53 |
| 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:54 |
| cjwatson | mapreri: see bug 1424672 | 17:55 |
| ubot5 | 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 | 17:55 | |
| mapreri | btw, why the source pacakge built by a recipe are 3.0 (native) ? | 18:22 |
| dobey | they aren't necessarily | 18:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| * 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| dobey | mapreri: do you need to maintain a difference between your bzr packaging branch and the git repo used for debian? | 18:36 |
| 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:37 |
| 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:38 |
| 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:39 |
| mapreri | i'll consider, some other day :) | 18:40 |
| mapreri | ok, I'll be off now. o/ | 18:42 |
| dobey | cheers | 18:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!