[11:59] <hanno> Hello. I have a few PPA related questions. Is this the right place?
[12:02] <xnox> depends on the question
[12:03] <hanno> My PPA is filling up, 22% use of 2GB: https://launchpad.net/~hzulla/+archive/ubuntu/sonic-pi/+packages
[12:03] <hanno> However, I cannot remove obsolete packages.
[12:03] <hanno> The package deletion only allows me to choose the current versions of the packages, not the outdated ones.
[12:04] <maxb> No, that's not the case, you just have to change one of the filter options
[12:05] <xnox> and deletion is not instant.
[12:05] <xnox> it's a cronned type of thing.
[12:05] <hanno> I did change the filter option.
[12:06] <xnox> hanno, try https://launchpad.net/~hzulla/+archive/ubuntu/sonic-pi/+packages?field.name_filter=&field.status_filter=&field.series_filter=
[12:06] <xnox> the drop down to "Any status" rather than just published
[12:06] <hanno> Yes. Now if I click "delete packages" as the admin, the superseded packages aren't listed and thus cannot be deleted.
[12:06] <hanno> But maybe I just have to wait.
[12:07] <hanno> ...for the cron to kick in.
[12:07] <xnox> hanno, can you filter by status again, in the delete packages section?
[12:08] <xnox> url should end in +delete-packages?field.name_filter=&field.status_filter=&field.series_filter= e.g.
[12:08] <xnox> https://launchpad.net/~hzulla/+archive/ubuntu/sonic-pi/+delete-packages?field.name_filter=&field.status_filter=&field.series_filter=
[12:08] <xnox> if it's not listed there, it's scheduled to be deleted.
[12:09] <hanno> https://launchpad.net/~hzulla/+archive/ubuntu/sonic-pi/+delete-packages?field.name_filter=&field.status_filter=superseded&field.series_filter= comes up empty.
[12:09] <hanno> So I'll wait for deletion.
[12:09] <xnox> cool.
[12:14] <cjwatson> Right, deleted packages are garbage-collected daily.  If you're only at 22% then you don't need to worry.
[12:17] <hanno> Thanks.
[12:18] <hanno> Is there a PPA-like service to build .deb for Debian?
[12:19] <hanno> I'd like to test these packages in my PPA on vanilla Debian, too.
[12:24] <hanno> Also, same for Raspbian.
[12:24] <cjwatson> Not operated by us, I'm afraid.
[12:25] <cjwatson> I don't know of one, which isn't to say it doesn't exist.
[15:12] <hanno> Another PPA question. I have a source tarball with valid debian/ rules. But I have to tell the specific name of the distribution (wily/vivid/trusty) in the changelog and cannot use one .changes file for all three?
[15:14] <cjwatson> hanno: If the exact same binaries will work on all three, then you can just upload to the oldest (trusty) and then copy the package with binaries forward to vivid and wily once everything's built
[15:15] <cjwatson> hanno: If that condition does not hold, then you're going to need different version numbers for each set of binaries, so the source package needs to differ anyway
[15:15] <cjwatson> (even if only in the first line of the changelog)
[15:18] <hanno> I don't know if the same binary works. But the same source package and build instructions work on all three.
[15:18] <cjwatson> Well, find out if the same binary works.
[15:19] <cjwatson> If your dependencies aren't too fast-moving then it may well.
[15:20] <cjwatson> Let's say your binary package is called "foo" and is version 1.0-1, built for amd64.  That will land in pool/main/f/foo/foo_1.0-1_amd64.deb in the published archive tree.  Only one version of that file can exist in a given archive - attempts to build it twice with the same package name, version, and architecture would result in a file name clash, so Launchpad forbids that.
[15:21] <cjwatson> So *if* you need to build it multiple times, it needs a distinct version number.
[15:22] <cjwatson> Otherwise, the target series in the changelog only specifies where it's initially uploaded to, and you can copy it around elsewhere (as long as it's either to a different archive, or you include binaries in the copy).
[15:27] <dobey> i've taken to just setting up recipe builds off trunk when i can, since a) they're automated b) ~14.04.1 ~12.04.1 etc get appended to version automatically c) always have latest version of whatever
[15:43] <hanno> Thanks.
[15:44] <hanno> Ok, so now I have a collection of patches for my .deb, let's call them 01 to 05. For i386 and amd64, I need all five of them. But for RPi, I only need the first four and not the fifth.
[15:45] <hanno> Can I specify that in some way or do I need to maintain two different versions of the debian/ directory?
[15:49] <dobey> patches should generally be applicable regarldess of the arch it is building on
[15:49] <cjwatson> hanno: While it's possible to do conditional patch application, it's a pain and makes it harder to use good patch management tools.  I would very very very strongly recommend making the patches themselves have conditional behaviour if for some reason 01-04 actually break RPi.
[15:49] <dobey> a different set of patches is a different source
[15:49] <cjwatson> hanno: Take it from one who has been there and done that.
[15:50] <dobey> two
[15:50] <dobey> :)
[15:50] <hanno> The source is for an RPi program. Patch 05 removes RPi specific behaviour.
[15:50] <cjwatson> Er, right, I read your comment backwards, but basically the same statement holds.
[15:50] <cjwatson> Make patch 05 detect the platform instead.
[15:52] <dobey> Launchpad has no notion of what is and isn't an RPi though. armhf packages are just armhf packages
[15:52] <hanno> I'll see how I can do that.
[15:56] <dobey> best would be to just get the changes upstream
[15:57] <dobey> and RPi specific stuff should be runtime detected or something
[15:58] <hanno> thanks everyone.
[21:25] <retrojeff> I have a question about PPA's and ubuntu
[21:26] <retrojeff> so I just upgraded from 14.04 trusty to 16.04
[21:26] <retrojeff> is there a way to change all my PPA up to 16.04 quickly
[21:27] <retrojeff> I tried using sed to replace trusty with xenial
[21:27] <teward> retrojeff: 'change all my PPA' how?
[21:27] <retrojeff> now over 1/2 my PPA are 404
[21:27] <teward> retrojeff: all the PPAs you use need to support Xenial for it to reliably work, but you need #ubuntu+1, not here
[21:27] <cjwatson> Right, this is up to the PPA owners, you can't do it without their help.
[21:27] <teward> at least, for changing everything on your Xenial system to update
[21:27] <retrojeff> that channel is dead as a doornob
[21:28] <teward> retrojeff: well, you have two problems:
[21:28] <teward> (1) not every PPA supports Xenial, so
[21:28] <teward> (2a) the PPA owners need to update their PPAs to support Xenial, or
[21:28] <teward> (2b) you have to remove those PPAs from your repository list
[21:28] <cjwatson> Or you can continue to use the trusty packages.
[21:28] <teward> ^ that
[21:28] <retrojeff> can I force the non working PPA back to an earlier working one
[21:28] <teward> with potentially mixed results.
[21:28] <cjwatson> If they still work, which they may well do.
[21:28] <teward> right
[21:29] <cjwatson> You can replace "xenial" with "trusty" again for the ones that don't support xenial.
[21:29] <cjwatson> Or try wily or vivid, perhaps.
[21:29] <teward> retrojeff: edit the individual sources.list or sources.list.d files' entries as cjwatson just said
[21:29] <teward> though you may wish to NOT use Xenial just yet since it's still in development
[21:30] <teward> (if you care about stability, anyways)
[21:30] <retrojeff> is there a bash script that can step through all the PPA and check for Xenial and if not found set it to trusty
[21:30] <teward> probably a sed script, but it won't discern between ppas that work and those that don't
[21:30] <teward> s/sed script/sed command/
[21:30] <retrojeff> yes
[21:30] <retrojeff> I would need to check for a Xenial folder on the website
[21:30] <teward> retrojeff: that should be asked in #ubuntu+1 though i bet there's answers on the net for it xD
[21:30] <retrojeff> and if its missing report back false
[21:31] <dobey> perl -p -i -e "s/xenial/trusty/" foo.list
[21:31] <teward> thank you dobey
[21:31] <teward> retrojeff: erm, that's a lot more work
[21:31] <teward> i'd either edit them all, or manually edit the ones that're 404ing
[21:31] <cjwatson> After an "apt-get update" with partial failures, you can look in /var/lib/apt/lists/
[21:31] <teward> ^ that
[21:31]  * teward goes away to poke the nginx packages in his PPA 'cause he thinks they froze up
[21:32] <cjwatson> It'll have ppa.launchpad.net_blah files, and you can compare against those
[21:32] <retrojeff> ty teward
[21:34] <teward> are the PPA uploaders working?  i have 3 out of 6 recent uploads that've been sitting as 'waiting to publish' for a while with that green gear icon
[21:34] <teward> just sitting there
[21:35] <cjwatson> teward: seems to be happily chugging away, would be easier with an example
[21:35] <cjwatson> teward: but I just noticed nginx in the log tail
[21:35] <teward> cjwatson: yeah that just pushed in
[21:35] <teward> i blame either my end caching data
[21:35] <teward> or lag
[21:35] <teward> or a combination therein
[21:36] <teward> cjwatson: thanks for checking it though :)
[21:36] <teward> now that it built i can push it to the MASTER PPA
[21:36] <teward> yay resource-consuming data :P
[21:36] <teward> s/data/data processes/
[21:37] <teward> and i said 6 uploads earlier, meant 5, stupid keyboard
[21:37] <cjwatson> teward: The PPA publisher cycles somewhere around every 15 minutes, depending on load; it just has a lot to do
[21:37] <teward> makes sense
[21:37] <teward> :)
[21:38] <teward> although i discovered something nice about the PPAs...
[21:38] <cjwatson> (And isn't ideally efficiently written - needs to be converted to a diskless model, in our copious free time)
[21:38] <teward> they're not afflicted by the libuuid1 bug that afflicts my sbuild schroots
[22:25] <wxl> hey folks. there's no such thing as private branches on lp is there?
[22:58] <sergio-br2> hi
[22:58] <sergio-br2> g++-4.9 : Depends: gcc-4.9-base (= 4.9.3-5ubuntu1~14.04) but 4.9-20140406-0ubuntu1 is to be installed
[22:58] <sergio-br2> .
[22:58] <sergio-br2> from here:  https://launchpadlibrarian.net/227630573/buildlog.txt.gz
[22:59] <sergio-br2> from where this 4.9-20140406-0ubuntu1 come from?
[22:59] <sergio-br2> it's not in the repo
[23:00] <sergio-br2> I'm using this ppa as a dependence: https://code.launchpad.net/~dolphin-emu/+archive/ubuntu/gcc-for-dolphin/+packages
[23:07] <sergio-br2> uh, 4.9-20140406-0ubuntu1 is higher than 4.9.3-5ubuntu1~14.04 ?
[23:08] <tumbleweed> dpkg --compare-versions is your friend
[23:14] <sarnold> the error you pasted here included an = instead of the >= or > choices..
[23:15] <sergio-br2> i don't understand, 4.9-20140406-0ubuntu1 is less than 4.9.3-5ubuntu1~14.04, why it's waiting for the deps?
[23:16] <sergio-br2> http://bazaar.launchpad.net/~dolphin-emu/dolphin-emu/debian-master-trusty/view/head:/control
[23:16] <sergio-br2> do I need to put gcc-4.9 (>= 4.9.3) in the control?
[23:21] <sarnold> sergio-br2: looks like that version may be available from https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test but you'd have to ask the gcc-for-dophin owner why that specific version of gcc, and if there's something about the version inthe ppa that's different from the ubuntu-toolchain ppa..
[23:22] <sergio-br2> gcc-for-dolphin is mine
[23:22] <sarnold> oh :)
[23:22] <sergio-br2> I pick that package from the ubuntu-toolchain
[23:23] <sergio-br2> I pick from ppa:ubuntu-toolchain-r/test
[23:23] <sergio-br2> I just re-built it
[23:24] <sergio-br2> I need this version 4.9 because dolphin don't compile with 4.8
[23:26] <sergio-br2> seems launchpad is being a little dumb with this dep
[23:26] <sarnold> sergio-br2: this is a guess; try replacing gcc-4.9 and g++-4.9  in your control file with gcc-4.9 (= 4.9.3-5ubuntu1~14.04) and g++-4.9 (= 4.9.3-5ubuntu1~14.04)
[23:27] <sergio-br2> maybe  gcc-4.9 (>= 4.9.3)  ?
[23:28] <sarnold> might also work
[23:31] <sergio-br2> let's see