| clivejo | wgrant: how would you build a python project then? | 00:08 |
|---|---|---|
| wgrant | clivejo: There are thousands of examples -- depend on python-foo | 00:09 |
| clivejo | and if the requirement isnt packaged ? | 00:10 |
| wgrant | clivejo: That you'll need to package it. | 00:10 |
| clivejo | inject it via the packaging? | 00:11 |
| wxl | clivejo: he means package the requirement | 00:11 |
| wgrant | clivejo: That's not acceptable for the Ubuntu archive. If you require another piece of software that isn't packaged in Ubuntu, you must first package that piece of software before you can depend on it. | 00:11 |
| wxl | and then package what you want to package that needs the requirement :) | 00:11 |
| wgrant | Fortunately, packaging most Python libraries is trivial. | 00:12 |
| clivejo | wgrant: is there a channel deals with this kind of thing? | 00:12 |
| wxl | clivejo: #packaging on oftc is fairly useful | 00:13 |
| clivejo | or group ? | 00:13 |
| wgrant | clivejo: http://packaging.ubuntu.com/html/ is probably the best resource | 00:13 |
| clivejo | I mean is there a LP team who primarily deal with python packaging? | 00:15 |
| wgrant | clivejo: Most of that work is done in Debian, with the Debian Python Modules Team. | 00:16 |
| * nacc thinks there is also #ubuntu-packaging and #debian-packaging -- not sure | 01:22 | |
| === jamesh_ is now known as jamesh | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| ePierre | Hi! Can anyone from the Launchpad project have a look at this request? → https://answers.launchpad.net/launchpad/+question/566017 Thanks in advance! | 07:39 |
| wgrant | ePierre: Done. | 07:41 |
| ePierre | wgrant, thanks a lot! | 07:43 |
| caribou | Hi, what's the best place to ask questions about python's launchpadilb ? | 08:53 |
| wgrant | caribou: Here. | 08:57 |
| caribou | wgrant: thought so | 08:57 |
| caribou | I'm having difficulties with the API : I'm building a script that will search all bugs with the 'sts-sru' tag. So far it works when I use distribution['ubuntu'].getSeries | 08:58 |
| caribou | but I'm not fetching bugs like this one : LP: #1664203 | 08:58 |
| ubot5 | Launchpad bug 1664203 in neutron-lbaas (Ubuntu Trusty) "[SRU] v1 driver does not delete namespace when pool deleted" [High,New] https://launchpad.net/bugs/1664203 | 08:58 |
| caribou | even if I loop through all the 'ubuntu' series | 08:59 |
| caribou | wgrant: my guess is that it is caused by the fact that the bug was not created for Ubuntu but for the cloud-archive project | 08:59 |
| wgrant | caribou: What is the specific call you're making that is not returning the bug? | 09:00 |
| wgrant | The original task shouldn't change things. | 09:00 |
| caribou | wgrant: http://pastebin.ubuntu.com/24227378/ | 09:02 |
| wgrant | caribou: Which API version are you using? | 09:03 |
| caribou | wgrant: devel, here is the whole script : https://github.com/karibou/sts_tag_queries/blob/master/BugTasks.py | 09:03 |
| wgrant | caribou: Bug 1664203 definitely shows up in trusty and xenial searches (though not in yakkety, since it's closed there) | 09:06 |
| ubot5 | bug 1664203 in neutron-lbaas (Ubuntu Trusty) "[SRU] v1 driver does not delete namespace when pool deleted" [High,New] https://launchpad.net/bugs/1664203 | 09:06 |
| caribou | wgrant: yep, maybe I picked up a bad example, let me find one that matches | 09:08 |
| caribou | wgrant: This one is listed if I use the Web search on tag but doesn't come up in the query : LP: #1602057 | 09:13 |
| ubot5 | Launchpad bug 1602057 in Ubuntu Cloud Archive mitaka "(libvirt) KeyError updating resources for some node, guest.uuid is not in BDM list" [Medium,Triaged] https://launchpad.net/bugs/1602057 | 09:13 |
| wgrant | In [4]: 1602057 in [task.bug.id for task in list(lp.load('/ubuntu/xenial').searchTasks(tags='sts-sru', created_since='2017-01-01', order_by='id'))] | 09:15 |
| wgrant | Out[4]: True | 09:15 |
| wgrant | caribou: ^^ | 09:15 |
| apw | i see Aa-series sorts in the wrong place on the "nominate for release" page .. | 09:16 |
| apw | i assume we have bugs galore filed for that kind of thing. | 09:17 |
| wgrant | apw: No bugs on that sort of thing yet. We know nothing core will actually break, but I imagine we'll run into cosmetic sorting issues around the place. | 09:17 |
| wgrant | apw: Hm, sorts OK for me. | 09:17 |
| wgrant | The list is in descending order of release date, so aa-series is first, followed by zesty. | 09:18 |
| apw | wgrant, oh i am so blind it is criminal | 09:18 |
| wgrant | Good :) | 09:19 |
| caribou | wgrant: indeed, it's there. I must be dropping it along the lines, sorry for the noise | 09:19 |
| wgrant | caribou: np, let me know if you run into anything else. | 09:19 |
| caribou | wgrant: sure, thanks! | 09:20 |
| wgrant | caribou: (and make sure to stick to devel -- the 1.0 API has some quirks that would affect you here) | 09:20 |
| caribou | wgrant: yeah, I found out the hard way when I first wrote this script | 09:20 |
| wgrant | Heh | 09:20 |
| * apw idly wonders if devel will ever spawn a new stable api | 09:21 | |
| wgrant | apw: No. | 09:21 |
| wgrant | The LP API versioning strategy was a terrible mistake. | 09:22 |
| wgrant | You can't give an API with a thousand distinct operations and even more fields a single version number. | 09:23 |
| apw | i guess you need to expose feature bits if anything | 09:23 |
| wgrant | It might have been possible to stabilise API versions if we could, for example, say this is Bugs API 2.0. | 09:23 |
| wgrant | And Archive API 3.0. | 09:23 |
| apw | that does sound more plausible | 09:24 |
| wgrant | Oh, only 2200 fields, it seems. | 09:26 |
| apw | wgrant, i more expect api versioning to tell me when i have to worry about intefaces going away, so i expect 1.0 to grow new foo2 foo3 variants as we go, but when we remove something then it changes | 09:26 |
| apw | but hey ... if devel is the one, the only, then i am good | 09:27 |
| wgrant | apw: Yeah, that's similar to the strategy we're using in the services we're working on atm. APIs are versioned in smaller subsets, and feature flags can be a thing before a new release is rolled. | 09:28 |
| === shadeslayer_ is now known as shadeslayer | ||
| === morphis_ is now known as morphis | ||
| === chihchun is now known as chihchun_afk | ||
| === JanC_ is now known as JanC | ||
| neutrino__ | Hi. I'm experimenting with building recipes on launchpad and noticed that the build logs include email addresses in clear. Is there any way to disable that? | 12:51 |
| === chihchun_afk is now known as chihchun | ||
| om26er | Hi! How can I check version of a package available in a repository ? example: I need to check what version of snapd is available in xenial-proposed while the release I am running is zesty. | 17:13 |
| nacc | om26er: rmadison | 17:13 |
| nacc | om26er: `rmadison snapd -s xenial-proposed` | 17:13 |
| nacc | om26er: or you can look on the package page on lp | 17:14 |
| om26er | nacc: that is it. that command helps. -- I needed that info for a script so can't go to lp. | 17:14 |
| dobey | well | 17:16 |
| dobey | there's also the API you can use from python with launchpadlib :) | 17:17 |
| === acheronUK is now known as acheronuk | ||
| === grumble is now known as grumble2 | ||
| === grumble2 is now known as grumble | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!