[14:49] <teward> question on PPAs and alternative archs.  If I have two staging PPAs and two production PPAs, and I want arm builds, do I need to have all four PPAs ARM-enabled, if only two of them are going to do the building and the other two are just going to hold the built binaries?
[14:49] <teward> trying to figure out this before determining if i should go filing a request or not :)
[15:09] <dobey> cjwatson: ^^ do you know the answer to that? i'm not quite sure, but i think it does need to be enabled on all PPAs that will get the binaries
[15:20] <teward> dobey: oh heh, i forgot to ping cjwatson and wgrant xD
[15:26] <cjwatson> Well, it's easy enough to test: copy a random built-everywhere package from the primary archive to a PPA, with binaries.  Wait for publication and inspect the resulting archive.
[15:26] <cjwatson> Anyway, the answer is that you only need the PPAs where packages are built to be ARM-enabled.
[15:27] <teward> cjwatson: and then copying from staging -> production PPA (so users of the PPAs don't end up with crap failed builds) would then have the alternate arch packages copied over as well?
[15:28] <teward> (in theory, anyways)
[15:28] <cjwatson> Right
[15:28] <cjwatson> Certainly as far as I can tell from a quick look over the code, and it appears to work that way in practice with the above experiment (I wanted to confirm rather than relying on my switched-off-for-vacation brain)
[15:28]  * cjwatson -> gone
[15:29] <teward> cjwatson: well when you are back from vacation, we can test, no rush on arm builds for this, but it wouldn't hurt to have at least one test case to confirm this is what goes on at somepoint
[15:29] <teward> enjoy your vacation :)
[15:31] <dobey> oh, didn't realize you were on vacation :)
[15:31] <teward> heheh, i think i saw something on him being on vacation elsewhere, in one of the other chans xD
[17:28] <johnl> hi. is there any way to keep previous versions of packages in a ppa when release a new version?
[17:28] <johnl> I'd like to allow users to explicitly install the older versions of the package, but launchpad seems to replace the old version with the new one (apt does support multiple versions of a package in a repository).
[17:33] <dobey> no. not unless whatever you are packaging supports parallel installability and you version the package names appropriately (like ardour3 vs ardour).
[17:34] <dobey> generally it's not a great idea to do that though, unless there is some specific reason it needs to be supported
[17:34] <johnl> dobey: I don't need to install both versions at once. I just want to be able to be able to choose which one.
[17:34] <dobey> almost always better to get users updated to the newest version
[17:35] <dobey> if you have a "beta" version and a "stable" series, then you need multiple PPAs. one for each series
[17:36] <johnl> dobey: I do have a beta and stable series, but some of my users want to upgrade at their own pace :)
[17:36] <dobey> then they can choose to not install the updates until they are ready :)
[17:37] <johnl> not if they need to build an additional server for a cluster though
[17:37] <johnl> for example
[17:38] <johnl> but if launchpad doesn't support it, then it doesn't support it.
[17:38] <johnl> feels like it'd be a handy thing to be able to switch on for a given ppa.
[17:39] <johnl> I know apt can do it. launchpad just chooses to remove old versions.
[17:40] <dobey> you can always set up your own archive repository server on your own terms on your own host
[17:40] <dobey> launchpad PPAs are a shared resource offered for free as a convenience
[17:41] <dobey> maybe selective deletion could be done like that for commercial license users of launchpad, but i don't think it's something that should be done in general
[17:42] <dobey> and i think it's generally bad practice to even do it on any archive setup; lack of upgraded packages is one of the biggest reasons why the internet is such a security nightmare
[17:43] <johnl> yeah, think I'll just have to setup my own archive then. ta.