[12:12] <Saviq> mooore spammers: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1324071
[12:13] <cjwatson> Saviq: dealing
[12:13] <Saviq> cjwatson, thanks
[12:13] <cjwatson> done
[14:25] <ki7mt> Is this the right channel to discuss PPA's on Launchpad and such?
[14:27] <davmor2> ki7mt: ask your question.  Most of the devs are in the Australian/New Zealand timezone so you might not get a response immediately
[14:27] <cjwatson> Well, not this week they aren't
[14:27] <davmor2> cjwatson: oh
[14:28] <davmor2> cjwatson: buy them beer then they deserve it :)
[14:31] <wgrant> Yeah, we're all in Malta this week.
[14:31] <ki7mt> davmor2, Ok, understand, I'm working on several applications, though related, separate repo branches.  Is the best practice to create one PPA for each application or set up a team PPA or something?
[14:35] <dobey> it's up to you how to deal with it. but best practice is to do the thing that best suits how you want your users to get our apps from a PPA
[14:35] <dobey> doesn't need to be a team PPA unless you need multiple people to upload to it
[14:36] <dobey> you can have one PPA and just upload the source packages for all the apps to the one ppa?
[14:36] <cjwatson> it's certainly entirely reasonable to put multiple packages in one PPA, if they'll be used by roughly the same set of people
[14:36] <cjwatson> you'd use multiple PPAs when they have radically different audiences, require different access control for uploads, and/or have conflicting packages in the different archives
[14:39] <ki7mt> Ok, they are all very close is use, just different parts of the radio spectrum. Sounds like one PPA, then add the packages to that is a reasonable approach.
[14:41] <wgrant> Yep
[14:41] <wgrant> If they're new packages, rather than changes to packages in Ubuntu, users can add your PPA and then just choose which packages to install.
[14:42] <ki7mt> Thanks for the info. I'm sure I'll be back with more questions when things fall over :-)
[14:44] <ki7mt> Yes, I'm new to packaging for Debian/Ubuntu .. I have the first package building on sid 32/64 and trust 32/64 with pbuilder, lintian is ok also.
[14:44] <ki7mt> trusty 32/64 .. ..
[14:47] <ki7mt> And yes, 3 of the apps are not in Debian or Ubuntu, then two others are but they need to be brought up to date for py3 and numpy 1.8 etc etc.,
[15:41] <tgm4883> dobey: so... 12.10 was marked as supported again?  https://launchpad.net/ubuntu/quantal
[15:56] <cjwatson> see #ubuntu-release
[18:37] <ki7mt> Hello all, I have a package, not currently in Debian/Ubuntu, that I've create the PPA page, tested builds etc,  and I'm ready to dput, but I'm a bit confused on the version / naming conversion. Program name is WSPR, version is 4.0. How should I name this for uploading to LP
[18:56] <TheWaterOnFire> Is there any reason I should get a "Missing build dependency" for a package that is part of the PPA I am building in?
[18:57] <TheWaterOnFire> i.e., building umockdev, need valac (>= 0.16.1); so added vala 0.16.1 to the PPA, but umockdev still won't build.
[18:59] <maxb> Check the package actually got published before you started the build?
[18:59] <TheWaterOnFire> It did. And I also restarted the build once afterward, just to be sure.
[19:00] <maxb> It could be a component issue, if "Use the same components used for each source in the Ubuntu primary archive." is the selected option for that PPA
[19:01] <TheWaterOnFire> It's set to "Use all Ubuntu components available"
[19:05] <maxb> You'd better give a link to the PPA and build, then
[19:06] <TheWaterOnFire> https://launchpad.net/~dwink/+archive/gstreamer/+build/6048534
[19:10] <maxb> TheWaterOnFire: I see no package called 'valac' in that PPA
[19:11] <maxb> I see one called 'valac-0.16', but that's hardly the same thing
[19:13] <TheWaterOnFire> maxb: Aha. That makes some sense. The vala packaging is strange that way. Thanks!
[21:53] <cjwatson> ki7mt: I would probably use 4.0-0ppa1 or something like that, in order that any future upload to Ubuntu will supersede it
[21:53] <cjwatson> ki7mt: and convert the program name to lower case
[22:02] <ki7mt> cjwatson, Thanks, the .org is all lower case, iv'e got the front half sorted out .. wspr-4..0~r4155 .. now I just need to figure out the 0ubuntu1 part, it's not clear on the site how that is assigned I guess it's done with the dput command.
[22:03] <ki7mt> whoops wspr-4.0~r4155 .. ..
[22:07] <cjwatson> ki7mt: you don't need that if it isn't in Ubuntu
[22:07] <cjwatson> And dput does not change version numbers
[22:08] <ki7mt> Oh, ok, thanks. so i can simply put: wspr-4.0~r4155_source.changes and away it goes?
[22:08] <cjwatson> don't need that> that is, "-0ubuntu1" indicates specifically a version of a package modified in Ubuntu - something like -0ppa1 would be better probably
[22:08] <cjwatson> You put the version number in the top line of debian/changelog
[22:09] <ki7mt> Yes, thats there already
[22:09] <cjwatson> If the package has a separate upstream existence (that is, there's already a wspr tarball released, or similar) then it should probably be 4.0~r4155-0ppa1 or something like that
[22:09] <ki7mt> wspr (4.0~r4155) UNRELEASED; urgency=lo
[22:09] <ki7mt> low
[22:10] <cjwatson> 4.0~r4155 with no -<something> indicates that the package in question *only* exists as a package - this is usually only appropriate if you're working on something quite core to the distribution itself, so for example dpkg doesn't have a -<revision> part
[22:11] <ki7mt> Ok, so I need to change the tarball name and changelog to add-<somthing> as well.
[22:11] <cjwatson> no
[22:11] <cjwatson> just the changelog
[22:11] <cjwatson> So I would usually do "wspr (4.0~r4155-0ppa1) UNRELEASED; urgency=low" (and of course set "UNRELEASED" to the actual target release (using dch -r) before actually uploading)
[22:12] <cjwatson> if I made a change to the packaging that would become 4.0~r4155-0ppa2
[22:12] <cjwatson> if I took a new upstream snapshot that would become 4.0~r4156-0ppa1 (or whatever)
[22:12] <cjwatson> if upstream made a proper release then that would become 4.0-0ppa1
[22:12] <cjwatson> something like that
[22:13] <cjwatson> as I say, assuming that WSPR is a thing that has an upstream maintainer
[22:13] <ki7mt> That what this is, a snapshot, as we're in the process of getting tar's generated on releases, jsut not there yet.
[22:13] <cjwatson> sure, I get that
[22:13] <ki7mt> Im part of that upstream helper croud :-)
[22:14] <cjwatson> if it exists in some manner other than a package, though, which it sounds like it does, you should have a -<revision>, e.g. 4.0~r4155-0ppa1
[22:14] <cjwatson> even if you are part of the upstream maintenance crew
[22:14] <cjwatson> otherwise there will sooner or later be some confusion between the version numbers you release in your packages and the upstream versions
[22:14] <ki7mt> It does, but it's in Windows, a few of us are converting things to *Nix thus the 4.0, that's the actual release version.
[22:15] <cjwatson> sure, I don't need to know :)
[22:15] <cjwatson> anyway, running out of battery and need sleep, night
[22:15] <ki7mt> Ok, thanks.
[22:42] <santa> hello
[22:43] <santa> I have started recently trying to get some changes in the kubuntu kde framworks 5 packaging, so I made some personal bzr branches with my changes
[22:43] <santa> however, I don't see the "merge request" button in the web interface, why is that?
[22:47] <santa> for instance http://derp.co.uk/73999
[23:30] <dobey> santa: +junk branches are not part of a project or distribution. you need to push your branch to a location under a project or distribution, to propose it.
[23:39] <santa> dobey: thanks. well the idea would be able to merge them here https://code.launchpad.net/kubuntu-packaging how do you suggest me to proceed? the person willing to review my changes told me it would be better - and I agree - if I could use the "merge request" thing (in order to avoid poking on irc)
[23:46] <dobey> push them to lp:~yourusername/kubuntu-packaging/whatever-you-want-to-name-the-branch
[23:46] <dobey> like lp:~foo/kubuntu-packaging/fix-readme or whatever
[23:49] <santa> ok, I'm not sure if I will have permissions to do that. I guess I don't so I will discuss it with the kubuntu guys tomorrow
[23:49] <santa> thank you for the help
[23:49] <dobey> yes you do
[23:49] <dobey> anyone can push any branch under a project like that
[23:49] <santa> oh
[23:50] <santa> let me check
[23:50] <dobey> the part that deterines the owner of the branch is your username
[23:50] <dobey> anyway, i have to go
[23:50] <santa> ah, ok
[23:50] <santa> see you