| psusi | how do you reassign a bug via email? wasn't there an unaffects command or something? | 00:59 |
|---|---|---|
| dobey | i'm not sure it's possible to mark something as no longer affected in a bug, via e-mail. i think you need to hit the red (-) icon on the web site. | 01:10 |
| psusi | I could have sworn there was a way to reassign a bug to another package via email... hrm... | 01:15 |
| psusi | say... can someone help me sort out launchpad with my gpg key? I made a new subkey last night since the old pair are about to expire, and pushed them to keyserver.ubuntu.com, and they show up when I search there, but lp is still saying it can't verify signatures made with the new key | 01:16 |
| psusi | ugh.. nevermind, it's just thunderbird being stupid with line wrapping and enigmail | 01:29 |
| psusi | nope, I am going to need some help debugging this because it's really fscked up | 02:13 |
| psusi | launchpad keeps saying it can't verify the signature... I thought it was thunderbird's fault because when I opened the source, copied it, and pasted it into a gpg -v, it also said bad signature... but when I save the message and run gpg on the saved file, it says the signature is good | 02:14 |
| psusi | I noticed that when I copy/paste, an extra space gets inserted into the message at a certain point so something is causing tbird to corrupt the data when it copies it... don't know if it is related or not to why lp doesn't like it | 02:15 |
| sergio-br2 | getting segfault in qemu... | 04:38 |
| sergio-br2 | https://launchpadlibrarian.net/188661519/buildlog_ubuntu-trusty-armhf.libretro-picodrive_1.91%2Br5~ubuntu14.04.1_FAILEDTOBUILD.txt.gz | 04:38 |
| sergio-br2 | qemu: uncaught target signal 11 (Segmentation fault) - core dumped | 04:38 |
| wgrant | sergio-br2: Have you tried building it on armhf yourself? It could be a qemu bug, or potentially a bug in your software when built on armhf. | 04:39 |
| sergio-br2 | i don't have arm board yet... | 04:40 |
| === karni is now known as karni-brb | ||
| === karni-brb is now known as karni | ||
| delcypher | I'm having an issue reuploading a package to my PPA. I made a mistake in the original version I uploaded which caused the build to fail. I deleted the package from the web interface but when I try to repupload using dput I get an e-mail saying "Rejected: File z3_4.3.1-0ubuntu1~trusty1.debian.tar.gz already exists" | 10:11 |
| delcypher | I should say that the reuploaded package source is modified. I don't understand why launchpad is keeping the *.debian.tar.gz file after I removed my broken package from the PPA | 10:12 |
| geser | because you can't reuse package versions once they got accepted | 10:13 |
| delcypher | That would make sense if I hadn't deleted the broken package from my PPA but I've deleted it so surely the *.debian.tar.gz should be deleted too no? | 10:15 |
| wgrant | They are remembered forever to avoid confusion. | 10:15 |
| wgrant | If you change the package, you must change the version. | 10:16 |
| delcypher | wgrant: Okay I'll change the version then | 10:16 |
| delcypher | by the way should I be using the "ubuntu1" inside my version? I haven't made any ubuntu specific changes to my package so maybe it should not be part of the package version. | 10:18 |
| cjwatson | delcypher: Versioning in your own PPA is essentially up to you, except for a few fixed constraints like can't-reuse, and if your package derives from a version somewhere else or might later be incorporated into other archives then there are some considerations there. https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning has some general advice. | 10:22 |
| delcypher | cjwatson: Thanks | 10:30 |
| delcypher | Is it possible to have a PPA contained multiple versions of a package e.g. 4.3.1 and 4.3.2 ? I originally uploaded version 4.3.2 of a package but I discovered that I needed 4.3.1 too. I tried uploading 4.3.1 put launchpad refused to accept an older package so I found I had to delete 4.3.2 from my PPA first. | 10:32 |
| maxb | No, uploading a newer package automatically supersedes older versions | 10:33 |
| cjwatson | Not in a single series. | 10:33 |
| cjwatson | But you can trivially have multiple PPAs. | 10:33 |
| delcypher | Okay. I now have version 4.3.1 in my PPA so if I upload 4.3.2 to my PPA 4.3.1 will no longer be available (even if someone does apt-get install mypackage==4.3.1)? | 10:34 |
| maxb | What you choose to do depends mostly on whether the multiple versions are supposed to be installable side by side on a single system or not. Is that the case here? | 10:34 |
| maxb | (installed simultaneously, that is) | 10:35 |
| delcypher | maxb: The packages are not intended to be installed side by side but it would be nice is multiple versions of the package were available from the same PPA. If that is not possible I guess multiple PPAs are an option. | 10:36 |
| maxb | Multiple PPAs are the easy way for you. Doing it in one PPA would require using distinct package names for each release series. i.e. mypackage-4.3.1 version 4.3.1-1 | 10:37 |
| maxb | Which is entirely possible but more work to vary the package build files | 10:38 |
| maxb | You can see a similar approach used in Debian/Ubuntu for the python packages | 10:39 |
| delcypher | maxb: Sorry for my ignorance but aren't the package names already distinct? I would have mypackage-4.3.1 and mypackage-4.3.2 so those are distinct right? | 10:39 |
| delcypher | maxb: or is the part after "mypackage-" not considered part of the name? | 10:40 |
| maxb | When I say name, I'm referring literally to just the name, not the version. So the package file on disk would be mypackage-4.3.1_4.3.1-1_amd64.deb | 10:41 |
| maxb | (Debian/Ubuntu use _ for the component separator) | 10:42 |
| delcypher | maxb: Okay that makes sense. It's a little more work as I would need to add "Conflicts" to my control file but the package I'm building does not make frequent releases so this probably acceptable. | 10:49 |
| cjwatson | It is not currently possible to have multiple versions of a single package name available in a single series from the same PPA. It's true that apt supports this, but we don't want PPAs to be growing without bound as people upload more and more superseded versions, so this would need to be off by default with some kind of management interface, which would be a fair amount of work to design and implement. | 10:50 |
| delcypher | cjwatson: Fair enough. | 10:51 |
| delcypher | Okay thanks for the help :) | 10:51 |
| lifeless | cjwatson: wouldn't quotas take care of the bounds thing? | 10:55 |
| cjwatson | lifeless: It would still be cumbersome to maintain without a fair bit of extra work. | 10:59 |
| wgrant | And it's useful in very few scenarios. | 10:59 |
| cjwatson | And it wouldn't be ideal to have a bunch of what would normally be 100MB archives all bumping up against quotas due to unpruned binaries that nobody actually cares about, either. | 10:59 |
| lifeless | fair enough | 11:00 |
| cjwatson | But, true, "without bound" was sloppy phrasing. | 11:00 |
| lifeless | I just think LP sometimes overthinks things | 11:01 |
| lifeless | and was wondering whether the low-key approach might work | 11:01 |
| cjwatson | True to some extent, but unpruned binaries really would be a very common case if we never dominated PPAs ... | 11:01 |
| cjwatson | Even the relatively rare case of unpruned NBS kernel binaries is fairly awkward to deal with right now, IIRC | 11:02 |
| lifeless | right, midnight. I must off. | 11:02 |
| === karni is now known as karni-lunch | ||
| === karni-lunch is now known as karni | ||
| === mpt__ is now known as mpt | ||
| === dpm is now known as dpm-afk | ||
| nickoe | Is there any way to mark already fix committed bugs with fix released without spamming people? | 22:21 |
| dobey | nickoe: anyone subscribed to the bug will get an email with the change notice. | 22:48 |
| nickoe | dobey: yeah, and that means a lot of mails. | 22:57 |
| nickoe | dobey: hundreds of mails, if there are hundreds of bugs marked with fix committed. | 22:57 |
| dobey | yes, well | 23:01 |
| dobey | i guess people might want to know if the bug was fixed, that's why they subscribed to it | 23:01 |
| nickoe | dobey: Is there an easy way to mark all fix commited bugs as fix released? | 23:05 |
| dobey | nickoe: a python script using the API | 23:05 |
| nickoe | ok | 23:06 |
| nickoe | dobey: Do launchpad have a playground for playing around with api, not to change anything live or the ned for creating a sandbox project? | 23:06 |
| dobey | nickoe: staging.api.launchpad.net server | 23:07 |
| dobey | or api.staging.launchpad.net | 23:07 |
| dobey | it's one of those two | 23:07 |
| nickoe | Ok, thank you. | 23:07 |
| * nickoe thinks it is annoying that there is no option in lp to auto subscribe to a bug that I have written or changed anything in. | 23:09 | |
| dobey | file a bug :) | 23:12 |
| nickoe | dobey: Does that staging copy the data from the real once in a while or? | 23:12 |
| nickoe | dobey: It was there last time I searched, and it was like five years old. | 23:13 |
| dobey | nickoe: i don't think so | 23:13 |
| nickoe | seems to be copied at least from 2014-07-03 | 23:13 |
| dobey | maybe it is. i don't recall | 23:14 |
| dobey | but you can create a set of bugs (and milestone, etc if needed) with the same structure, and test with those | 23:14 |
| nickoe | ok | 23:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!