=== psivaa_ is now known as psivaa === JoseeAntonioR is now known as jose === tsimonq2alt is now known as tsimonq2- === tsimonq2- is now known as tsimonq2 === pavlushka_ is now known as pavlushka === maclin1 is now known as maclin === yofel_ is now known as yofel [15:15] Is there a way for me to know how many times a specific version of a package was downloaded off a PPA? i.e. the number of active users [15:21] sidi: Dig through the API until you get the right binary_package_publishing_history object, and then you have getDownloadCount and getDownloadCounts methods: https://launchpad.net/+apidoc/devel.html#binary_package_publishing_history [15:27] cjwatson, thanks, is that also part of the Python API for launchpadlib? If not I wouldn't mind a documentation outlining what the package names, distro and id ought to be for a PPA package [15:27] sidi: +apidoc is the specification of the webservice API which you can access through launchpadlib, yes [15:28] Alright. Thanks, I'll have a go at it before I pester you then :-) back to C for now. [15:28] sidi: you generally get at BPPH records for a PPA by first loading the PPA object and then using getPublishedBinaries on that [15:29] https://launchpad.net/+apidoc/devel.html#archive-getPublishedBinaries [15:30] Cheers [15:31] The URL spec for BPPH is informational - you won't know the ID, in general, so you can't construct it manually that way === JoseeAntonioR is now known as jose === JanC_ is now known as JanC === caraka_ is now known as caraka [19:37] hey, does `bzr branch ubuntu:` not work anymore? [19:38] if not, what's the correct way to get the branch for the archive package? [19:39] there are no branch imports for xenial [19:39] use pull-lp-source to pull a source package [20:03] dobey: that doesn't give me a bzr branch though, so how would a change get submitted back? [20:06] mhall119: submitted back to where? most packages in ubuntu are not managed via bzr branches. to submit it back to the archive, you'd attach a debdiff to the bug report, or if you have upload rights, upload the new package; or if the package has Vcs-Bzr: listed in debian/control, and lands via ci train for example, then make a branch against that branch, and propose it so it can land via silo [20:07] dobey: ok, last time I tried it was all in bzr [20:08] the branch import stuff was very unreliable [20:08] so it was turned off for xenial [20:08] ack [20:08] there was a mail on the list back in october i think, where cjwatson or wgrant explaind this and why :) [20:08] so where's the documentation for how to submit patches to Ubuntu packages now? [20:09] dobey: yeah, not being normally involved in that I probably just ignored it [20:09] https://wiki.ubuntu.com/UbuntuDevelopment [20:10] I've been saying for ages (long before we stopped the importer) that the bzr workflow was in practice not fit for purpose and the docs should be changed to recommend working with source packages [20:10] I was ignored [20:10] i'm not sure which exact sub-part of that wiki tree is relevant to whatever you're trying to do [20:10] cjwatson: I'm not disagreeing with the change, just trying to figure out the new way [20:10] One part of the problem was that the bzr workflow worked OK until you uploaded a package using it [20:10] The new way is the old way. Should be in the doc history somewhere :) [20:10] the new way isn't the new way; it's the old way :) [20:10] well, ok, the new-to-me way [20:11] I really want to get the corresponding git workflow working [20:11] But our priorities right now are snappy snappy snappy [20:11] mhall119: grab source package, make changes, generate a debdiff, attach it to the bug, subscribe ubuntu-sponsors; generally [20:11] So it's hard to slot in [20:12] cjwatson: you should make a snappy app for the git workflow, that'll solve everything :) [20:12] You joke, but we've been able to slot in more than one git improvement with that strategy ;-) [20:12] mhall119: https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews maybe more specifically relevant to your question now [20:12] cjwatson: heh [20:13] launchpad.snap [20:13] thanks dobey [20:14] snappy install launchpad [20:14] or has "install" been changed to "deploy" this week? ;) [20:15] You joke, but it's actually "snap install" now. [20:16] clearly this all should be in a juju charm too, so you can juju deploy your snap install of a git workflow [20:17] and it hurts me just a little that what I just say is actually a valid technical approach [20:17] lol [20:17] "valid" [20:17] possible :-) [20:17] ok, possible :) [20:18] oh, wait, damn, I forgot to involve LXC