=== charles__ is now known as charles === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [12:12] mooore spammers: https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1324071 [12:12] Ubuntu bug 1324071 in unity8 (Ubuntu) "Acne And The Importance Of Skin Care" [Undecided,Invalid] [12:13] Saviq: dealing [12:13] cjwatson, thanks [12:13] done [14:25] Is this the right channel to discuss PPA's on Launchpad and such? [14:27] 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] Well, not this week they aren't [14:27] cjwatson: oh [14:28] cjwatson: buy them beer then they deserve it :) [14:31] Yeah, we're all in Malta this week. [14:31] 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] 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] doesn't need to be a team PPA unless you need multiple people to upload to it [14:36] you can have one PPA and just upload the source packages for all the apps to the one ppa? [14:36] 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] 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] 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] Yep [14:41] 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] Thanks for the info. I'm sure I'll be back with more questions when things fall over :-) [14:44] 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] trusty 32/64 .. .. [14:47] 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] dobey: so... 12.10 was marked as supported again? https://launchpad.net/ubuntu/quantal [15:56] see #ubuntu-release === Ursinha is now known as Ursinha-afk [18:37] 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] 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] 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] Check the package actually got published before you started the build? [18:59] It did. And I also restarted the build once afterward, just to be sure. [19:00] 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] It's set to "Use all Ubuntu components available" [19:05] You'd better give a link to the PPA and build, then [19:06] https://launchpad.net/~dwink/+archive/gstreamer/+build/6048534 [19:10] TheWaterOnFire: I see no package called 'valac' in that PPA [19:11] I see one called 'valac-0.16', but that's hardly the same thing [19:13] maxb: Aha. That makes some sense. The vala packaging is strange that way. Thanks! === Ursinha-afk is now known as Ursinha === Ursinha is now known as Ursinha-afk [21:53] 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] ki7mt: and convert the program name to lower case [22:02] 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] whoops wspr-4.0~r4155 .. .. [22:07] ki7mt: you don't need that if it isn't in Ubuntu [22:07] And dput does not change version numbers [22:08] Oh, ok, thanks. so i can simply put: wspr-4.0~r4155_source.changes and away it goes? [22:08] 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] You put the version number in the top line of debian/changelog [22:09] Yes, thats there already [22:09] 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] wspr (4.0~r4155) UNRELEASED; urgency=lo [22:09] low [22:10] 4.0~r4155 with no - 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 - part [22:11] Ok, so I need to change the tarball name and changelog to add- as well. [22:11] no [22:11] just the changelog [22:11] 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] if I made a change to the packaging that would become 4.0~r4155-0ppa2 [22:12] if I took a new upstream snapshot that would become 4.0~r4156-0ppa1 (or whatever) [22:12] if upstream made a proper release then that would become 4.0-0ppa1 [22:12] something like that [22:13] as I say, assuming that WSPR is a thing that has an upstream maintainer [22:13] 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] sure, I get that [22:13] Im part of that upstream helper croud :-) [22:14] if it exists in some manner other than a package, though, which it sounds like it does, you should have a -, e.g. 4.0~r4155-0ppa1 [22:14] even if you are part of the upstream maintenance crew [22:14] otherwise there will sooner or later be some confusion between the version numbers you release in your packages and the upstream versions [22:14] 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] sure, I don't need to know :) [22:15] anyway, running out of battery and need sleep, night [22:15] Ok, thanks. === Guest30318 is now known as nesthib [22:42] hello [22:43] 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] however, I don't see the "merge request" button in the web interface, why is that? [22:47] for instance http://derp.co.uk/73999 [23:30] 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] 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] push them to lp:~yourusername/kubuntu-packaging/whatever-you-want-to-name-the-branch [23:46] like lp:~foo/kubuntu-packaging/fix-readme or whatever [23:49] 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] thank you for the help [23:49] yes you do [23:49] anyone can push any branch under a project like that [23:49] oh [23:50] let me check [23:50] the part that deterines the owner of the branch is your username [23:50] anyway, i have to go [23:50] ah, ok [23:50] see you