[02:28] wgrant: blr: is it possible to trigger a rebuild of a package in a PPA (in order to pick up new versions of a build-dep in the same PPA) without re-uploading? [02:29] there's a 'rebuild' button if the build failed, but not one if it succeeded it seems? [02:29] thomi: No, that's not possible. It's not quite clear how it would work, as it would need to change the version. Bug #245594 tracks this request. [02:29] bug 245594 in Launchpad itself "Rebuilds of binary packages without source changes" [Low,Triaged] https://launchpad.net/bugs/245594 [02:29] ahh, thanks [02:29] The feature is often known as "binNMUs" as that's how they're referred to in Debian. [02:30] ok.. re-upload time for me! [02:30] thankfully my webkit2gtk package built OK - that thing took hours :( [02:33] webkit is a horrid creature. [02:38] I just noticed my PPa is 1.8GiB... ahh well [02:39] I can always increase the quota :) [02:39] WebKit quickly fills 2GiB :/ === tasdomas` is now known as tasdomas === \b is now known as benonsoftware === frankban__ is now known as frankban [14:21] when doing a release is it supposed to change all fix committed bugs to fix released or do i still have to manually set those? [14:21] i marked all the bugs for a specific milestone [14:24] stokachu: Launchpad only has any auto-closing machinery for packages uploaded to distributions. For projects, you have to close them manually. [14:24] cjwatson: boo ok [14:25] or set up your own bot [14:25] Marking bugs for a milestone wouldn't be terribly accurate, as people often schedule bugs for fixing in a milestone but then they slip. [14:25] And that sort of detail is often only cleaned up post-release, so we wouldn't want to auto-close based on that. [14:26] would be a nice to have feature that when a new release is done it'll close all bugs associated with that release [14:28] stokachu: there's several people including myself who go through via the API and close things based on the release status - a lot of times when I run through it's stuff that's still Triaged, New, etc. against that release - there's a lot of times where it's not that simple, in packages I watch, and I have to close manually (because against devel release instead of the specific series, or such) [14:29] teward: gotcha [14:30] i may use the api to automate some of it then [14:30] stokachu: and as cjwatson mentioned, it only exists for packages uploaded to distributions - you have to close manually for projects. [14:31] (and most of my stuff is nginx anyways, and has corresponding Project *and* Package bugs, so it's a one-two knockout on what I watch) [14:31] s/one-two/two-for-one/ [14:31] We close Launchpad bugs by hand after deployments. [14:31] Bugs in Launchpad itself, I mean. [14:31] yep [14:31] It's often a bit subtle what a release means ... [14:32] cjwatson: if not ambiguous - "release" means different things project to project [14:33] Ubuntu, it's a new version. nginx, well... upstream and in ppas, it's either stable or mainline release, so 'release' alone is ambiguous [14:33] (just a case in point is all) [14:38] cjwatson: the API hasn't changed since the last time I went poking at it, has it? (In terms of getting a list of bugs for a specific release with specific statuses, then changing the status en masse and putting a standard notification of why it was changed) [15:14] teward: release> indeed, for Launchpad it can depend which set of hosts need to be updated, for instance [15:15] teward: I can't think of any changes in that area === Mission-Critical is now known as MissionCritical [20:11] does launchpad pull in submodules when importing a git repo? [20:13] apparently not :( http://launchpadlibrarian.net/198196868/cloud-installer-cloud-installer-stable.log [20:20] no, git submodules are not supported [20:34] hmm, i think branch scanner hanged or something [20:39] does anyone know where i can get the package id for https://api.launchpad.net/1.0//+archive//+binarypub/ ? [21:31] wgrant: around?