[00:08] hiho. i've been wondering, is there a way to upload binary builds to launchpad (without commercial subscription)? we're an open source project, but since launchpad is not really able to deal with our project requirements anymore (random build failures, long build times, no access to old builds, ...) we want to migrate to our own infrastructure. [00:08] we would still like to push the builds to launchpad for user convenience. is it possible somehow? [00:27] @slackner: it is possible to provide downlaods https://help.launchpad.net/Projects/FileDownloads [00:30] wxl: it sounds like thats a separate mechanism, and will not help users which have added our PPA, right? [00:30] @slackner: right. if you want to use the ppa, you still can, but lp still does the building. [00:33] slackner: All Launchpad PPA packages must be built from source by Launchpad. [00:33] I haven't seen any mention of the build failures or long build times that you've been experiencing. [00:34] wxl: i fear this isn't really an option. we want to simplify things, not maintain two set of builds [00:34] wgrant: with a commercial subscription it would be allowed, right? [00:34] slackner: Well, you could technically upload a source package that included the binaries, yes. [00:34] But you can't upload debs directly. [00:35] And that's pretty gross. [00:35] wgrant: take a look for another recent build failure: https://launchpadlibrarian.net/309904992/buildlog.txt.gz [00:35] @slackner: sounds like the simplest solution is to pick one system or another. if you'd rather take it all on your server, just set up on your own ppa. [00:37] slackner: Ah, so that's a recipe build. You can easily fix that by using a git recipe directly (rather than a bzr recipe using a bzr mirror of a git repository, which means you're exposed to bzr's performance limitations), or building the source package locally and uploading that. [00:37] wgrant: in this case it took 2 hours until it failed (as you can see here https://code.launchpad.net/~wine/+archive/ubuntu/test-builds/+recipebuild/1328551 ) [00:37] I'd suggest moving to git recipes. They're known to be much more reliable on massive codebases where bzr struggles, and have been supported for about a year now. [00:39] wgrant: thanks for the tip. nevertheless, i fear that wouldn't really help to solve the other issues :/ [00:39] If that doesn't work, I'd like to know because that would be a first, but there's another fallback: just bypass the recipe system, building the source package locally by whatever means you desire and uploading that. Removes some of the automation of daily builds, but looks the same for users and minimises the work you have to do locally. [00:39] slackner: Which? Old builds? [00:40] wxl: setting up a ppa is not the problem, but its difficult to make all of our users aware of the new location [00:40] wgrant: yes, for example [00:41] slackner: What are your specific requirements there? It's difficult, in any apt repository, to expose old versions directly to clients, but there is a mechanism that we can enable on a per-PPA basis in LP to keep old versions for download from the web UI. [00:47] wgrant: that would be much better than it is right now, but i fear repo size would be the next problem we encounter. i appreciate the effort to solve these issues, but in our case we would really prefer to do things in our own infrastructure. [00:48] slackner: OK. I'm afraid there's no way to publish your own prebuilt debs on ppa.launchpad.net. [00:49] But the specific issues you've raised here seem easily solvable with some reconfiguration. [01:01] wgrant: it might be solveable, but not sure if its that easy. for us it is much easier to use the same build mechanism for all distros. nevertheless, thanks for the info. btw, why is the "keep old builds" functionality not mentioned anywhere? [01:05] slackner: Because it can easily consume a lot of disk space, everyone thinks they need it, and it's much easier if we don't have to tell them that it's not worth it for us to keep their old versions around. For complex compatibility cases like Wine it's a clear win. [01:30] (joining late) wgrant: i told slackner that i thought you guys supported binary uploads because i read somewhere that that's how the commercial games worked [01:30] (for commercial accounts only) [01:31] ehoover: Ah, no. It's just that with a commercial subscription you can upload your proprietary stuff, potentially as a tarball of binaries masquerading as a "source" package. [01:32] wgrant: makes sense. i'm not sure we would want do do this, but does that mean we could take our resulting deb and pull everything out and upload the tarball to "build" it? [01:35] ehoover: Yup, if you really wanted. [01:35] wgrant: ok, good to know (trying to give slackner options to achieve his many objectives) === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === benjaomi- is now known as benjaoming === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === nacc_ is now known as nacc === JanC_ is now known as JanC