[11:16] <GMMigge> Hi guys, question related to launchpadlib. In the browser I can get the archivesubscriptions, and when I view one of the subscriptions I get an id, .e.g. ...+archivesubscriptions/28726
[11:16] <GMMigge> Using the launchpadlib APIs I can get the subscriptions via getArchiveSubscriptionURLs(), and from the URLs figure out the PPA and then get the actual archive link.
[11:16] <GMMigge> But how would I go about to extract the id from above (i.e. 28726)
[15:06] <lfaraone> If someone is hosting proprietary software (just binaries) on Launchpad, to whom should that be reported?
[15:06] <czajkowski> lfaraone: please file a question on lp
[15:07] <czajkowski> linking the project in question and it'll be looked into
[15:07] <lfaraone> czajkowski: Okay. If I'd rather not do this publicly?
[15:07] <lfaraone> or is that the only mechanism.
[15:09] <czajkowski> lfaraone: you can also mail help@launchpad.net
[15:10] <lfaraone> meh, whatever. https://answers.launchpad.net/launchpad/+question/237445 reported.
[15:11] <czajkowski> well you asked for one privately that was the reply :)
[15:47] <philsf> hello, I published code for two projects in lp, but in my innocence I used (bzr) tags to identify release versions. what is the best practice to track those in lp? do I need to branch at each version?
[15:55] <JonnyJD> philsf: I personally also only have tags for versions and create branches only when I need to backport some fixes
[15:56] <philsf> JonnyJD, I'm new at lp hosting. Does this mean I'll only see the trunk timeline, not the versions?
[15:58] <JonnyJD> philsf: you can track the versions when you add "milestones"
[15:58] <JonnyJD> philsf: you can also add a regex to your branch for the downloads and it will track versions from that
[16:01] <JonnyJD> philsf: "Release URL pattern:" in the settings for a "series" is what I am talking about (automatic version import)
[16:01] <JonnyJD> importing milestones/versions by tag isn't possibly afaik
[16:06] <JonnyJD> lfaraone: what do you mean? this is a python package and the code isn't even obfuscated
[16:06] <shadeslayer> curious, do Launchpad builders not allow files in /usr/local
[16:08] <JonnyJD> lfaraone: or are you talking about xflux, which is included in binary from (in fluxgui), but probably shouldn't?
[16:14] <philsf> JonnyJD, my projects are perl apps, I create deb packages locally with debian tools. if I keep an updated debian/ dir in the trunk, can lp automatically create the deb for me?
[16:14] <philsf> JonnyJD, or is there a better place for debian/* ?
[16:15] <JonnyJD> philsf: yes you can keep "debain" in your trunk and you can crate a recipe that builds this automatically or by request (automatically taking version info from debian/changelog)
[16:16] <JonnyJD> philsf: I personally keep the packaging in a different repository
[16:16] <JonnyJD> philsf: because when somebody else wants to package your software for debian and doesn't want to use your packaging he has to remove your "debian" folder
[16:17] <JonnyJD> well, you can have both in a repository. My point is rather that a repository without "debian" should be available
[16:19] <philsf> JonnyJD, by "repository" you mean another branch associated with the project?
[16:19] <philsf> JonnyJD, can you show me an example?
[16:20] <JonnyJD> philsf: https://code.launchpad.net/~musicbrainz-developers/+recipe/python-discid
[16:21] <JonnyJD> this recipe takes a bzr branch with "debian" packaging and code in one branch. However, it was created by merging packaging and code. The original code is in https://code.launchpad.net/~jonnyjd/python-discid/master
[16:22] <JonnyJD> philsf: another recipe can then take only your code and mix it with only the packaging part of that repository: https://code.launchpad.net/~musicbrainz-developers/+recipe/python-discid-daily
[16:32] <philsf> JonnyJD, cool
[16:38] <philsf> JonnyJD, I think I found some more documentation about deb packaging and recipes. but what about tarballs? can lp generate that from the bzr tags?
[16:40] <JonnyJD> philsf: from what I grasp, orig.tar.gz are allways created
[16:40] <JonnyJD> but if you do want to use automatic milestone generation you normally already have versioned tar.gz archives
[16:43] <JonnyJD> philsf: like I said, launchpad doesn't care much about the tags themselve. But you can add "milestones" to list versions on the launchpad page and include versions in "debian/changelog".
[16:44] <philsf> hmm, I'm looking at the milestone creation page now. trying to wrap my tiny brain around all this stuff, lol
[16:44] <philsf> JonnyJD, much thanks for all the help!
[16:45] <philsf> last question: is "register a new series" the same as creating a milestone in trunk?
[16:53] <dobey> philsf: no, trunk itself is a series.
[17:07] <JonnyJD> https://answers.launchpad.net/launchpad/+question/237445 says "answered" as the status, but isn't actually dealt with (the propriatary software from above). Is there anything I can do to reset this?
[17:25] <czajkowski> JonnyJD: you can't no, but the admins can if they need to
[17:25] <czajkowski> as they are based in AU they'll review it tomorrow
[17:26] <czajkowski> JonnyJD: also to answer your question non open source projects can be hosted on LP, they just pay commercial  hosting
[17:26] <lfaraone> JonnyJD: I reopened it.
[17:27] <lfaraone> JonnyJD: I'm talking about xflux, which (to the user) is presented as part of the app.
[17:27] <dobey> czajkowski: this is about putting non-free code from other people in PPAs, not hosting full projects
[17:28] <lfaraone> regardless of whether they are technically separate, as a user I wouldn't know the difference.
[17:28] <lfaraone> dobey: well, they could purchase a commercial subscription and still publish proprietary code in their PPAs :)
[17:28] <czajkowski> dobey: yes they are seperate issues. was also just clarifying about hosting also.
[17:28] <czajkowski> wgrant: and StevenK are hopefuly asleep at this hour and they review the questions
[17:29] <dobey> lfaraone: sure. except the person in question probably also doesn't have explicit permission to redistribute the xflux binary anyway
[17:29] <dobey> lfaraone: so they'd still be in violation of whatever the xflux license is in that respect
[17:29] <lfaraone> Entirely unrelated, if I were part of an org interested in using Launchpad PPAs / project management, if I had a commercial subscription is there any support for offering packages built for Debian in the same PPA?
[17:30] <lfaraone> dobey: they appear to have tacit approval from http://justgetflux.com/linux.html, but there's no license grant
[17:30] <dobey> no, PPAs only support building for ubuntu at the moment
[17:30] <cjwatson> lfaraone: https://bugs.launchpad.net/launchpad/+bug/188564 applies to commercial-subscription PPAs too
[17:47] <philsf> I just created milestones for my project past releases. how can I link particular bzr revisions for the code hosted there, so I can offer download tarballs?
[17:48] <JonnyJD> philsf: you can specify which revision to build: https://help.launchpad.net/Packaging/SourceBuilds/Recipes#Specifying_revisions
[17:48] <JonnyJD> you can also use tags there.
[17:49] <JonnyJD> You will need either one recipe per tag or you just change your recipe for every version
[17:49] <JonnyJD> (I would just change/update the recipe for every version)
[17:50] <philsf> JonnyJD, oooohh, THAT'S what I was look for. thanks, mate!
[18:38] <philsf> i renamed my tags (create new tag, delete old tag), but after I pushed to lp, now I have both tags in the repo. If I branch to a test dir, I get both the new and old ones. what did I miss?
[18:43] <JonnyJD> philsf: hm, I don't remember how to delete a tag remotely in bzr
[18:43] <cjwatson> bzr tag -d lp:blah --delete TAG
[18:43] <cjwatson> generally bzr is pretty transport-agnostic - you can give it remote URLs anywhere it might be able to take a local branch
[18:50] <philsf> cjwatson, thanks
[23:17] <jderose> can anyone shed any light on why so many of the UDD saucy packaging branches are out of date currently? gnome-settings
[23:17] <jderose> er, gnome-settings-daemon and qemu, for example
[23:21] <cjwatson> Straight answer?  Because udd is a really hard thing to do right and there's been very little maintenance effort available for it.
[23:22] <cjwatson> The problems show up on package-import.ubuntu.com and I think most of them at least have bugs
[23:24] <jderose> cjwatson: gotcha... yeah, i know you folks are all kinds of busy, np :)
[23:25] <jderose> cjwatson: so what's the recommended workflow with UDD is possible for a package?
[23:25] <jderose> er, *when* UDD isn't possible
[23:26] <cjwatson> Get the source package directly
[23:26] <cjwatson> TBH that's the workflow I use with the bulk of packages at least for drive-by fixes
[23:27] <jderose> and then debdiff to propose a change/fix?
[23:27] <cjwatson> Yep
[23:28] <cjwatson> You can throw it into a local repository if you like although it wouldn't necessarily be mergeable into others'
[23:28] <cjwatson> Depending on the complexity of your changes
[23:28] <cjwatson> This is in the category of "things that would be much easier if we used git"
[23:28] <jderose> okay. i'm realizing how naked and vulnerable I feel without VCS for this... and shows how awesome UDD can be, when working :)
[23:28] <jderose> hmm, okay
[23:28] <cjwatson> If you're feeling really keen you could try to fix udd, but I don't have much specific advice to offer there
[23:29] <cjwatson> It's lp:udd
[23:29] <jderose> no time at the moment, but maybe next week i'll have a keen feeling moment or two, and will take a look
[23:31] <jderose> cjwatson: anyway, thanks. and thanks again for the last minute ubiquity fixes... huge help for system76
[23:32] <cjwatson> [6~[6~[6~you're welcome.  been a busy week or two
[23:32] <cjwatson> (gah, lag)
[23:33] <jderose> hehe
[23:33] <jderose> and congrats on the 13.10 release, and ubuntu touch 1.0! not sure if you're celebrating yet, or still working :)
[23:38] <cjwatson> still working I fear
[23:39] <jderose> yeah, me too... so i'll let you get back to it, and i'll do the same. thanks again!