=== Ursinha is now known as Ursinha-afk
=== doko_ is now known as doko
=== Ursinha-afk is now known as Ursinha
[16:28] <slangasek> hrm.  why is syncpackage telling me that freetype is blacklisted, when precise has 2.4.7-1?
[16:30]  * slangasek forgets where the webpage is that shows the LP blacklist
[16:30] <Laney> https://launchpad.net/ubuntu/precise/+localpackagediffs?field.name_filter=freetype&field.package_type=all&field.package_type-empty-marker=1
[16:30] <slangasek> ta
[16:30] <Laney> as for "why", no idea
[16:30] <Laney> but archive admins can turn it off there
[16:31] <tumbleweed> there's a bug in the auto blacklisting
[16:31] <Laney> probably because it ahead of wheezy
[16:31] <slangasek> tumbleweed: is there a bug #?
[16:31] <tumbleweed> bug 841372
[16:31] <ubot4> Launchpad bug 841372 in launchpad "Incorrect auto-blacklisting in DSD? (affects: 1) (heat: 27)" [Low,Triaged] https://launchpad.net/bugs/841372
[16:31] <slangasek> Laney: I didn't get this previously for packages I synced from unstable
[16:33] <tumbleweed> yeah it happens randomly with some packages
[16:33] <Laney> ok, maybe that bug then
[16:33] <tumbleweed> well presumably not randomly :)
[16:33] <tumbleweed> if this goes on for too long, we should make syncpackage spit out that bug number
[16:34] <Laney> why do we care about blacklisted_current in ubuntu?
[16:34] <tumbleweed> yeah, maybe we shouldn't. We certainly aren't using it yet
[16:35] <tumbleweed> I could see it being handy for saying "nothing interesting here"...
[16:36] <Laney> given that only archive admins can set it ...
[16:37]  * tumbleweed notices that syncs aren't greyed out on oneiric's +localpackagediffs page. I hope that doesn't mean pressing sync will do anything
[16:38] <Laney> it'll get rejected if it goes through
[16:38] <Laney> ime
[16:39] <slangasek> Laney: "given that only archive admins can set it" - er, but that's exactly how blacklisting of packages has always happened?
[16:40] <Laney> slangasek: we were talking about the "these versions" bit
[16:40] <slangasek> but then I don't know what "blacklisted_current" means either
[16:40] <Laney> which is what blocked your sync
[16:40] <slangasek> ok
[16:40] <Laney> and whether it has any meaning for ubuntu
[16:40] <slangasek> right, I can't figure out what that would mean
[16:40] <slangasek> (conceptually within Ubuntu)
[16:41] <tumbleweed> this version is bad, don't sync it
[16:41] <Laney> yeah
[16:41] <tumbleweed> IIRC it goes away as soon as either side changes
[16:41] <cjwatson> which in itself suggests that it's useless for the stated use case
[16:42] <cjwatson> somebody uploads something unrelated, you lose your note
[16:42] <Laney> it seems like we should just ignore it for ubuntu as long as it has no use for us
[16:43]  * slangasek concurs
[16:43]  * tumbleweed makes that happen
[16:43] <Laney> we could make syncpackage print out the comments if there are any
[16:43] <Laney> i can't remember if they are tied to version pairs?
[16:43] <tumbleweed> Laney: it currently prints the comments when there's a blacklist, but noth otherwise
[16:44] <tumbleweed> no, comments are just a list. There's no knowing what comment applies to which decade :/
[16:45] <Laney> display the date so that at least people can see how stale it is?
[16:45] <Laney> and ask LP to please let us delete or hide old comments
[19:55] <tumbleweed> looks like dssi & nautilus-image-converter don't need to be blacklisted any more. No more mismatch
[20:54] <stgraber> skaet, cjwatson, Daviey: So looking at Drupal's xmlrpc support, authentication is something the module would have to implement itself which I'd rather avoid doing at the moment. Would we be fine restricting write access to the API by IP?
[20:55] <stgraber> I guess the biggest use would be to push new builds and to push new results, I'm pretty sure IP based restriction is fine for the former, not sure for the later.
[20:57] <skaet> stgraber, case that's worrying me is community testers logging test results.  Is this just for the admin interface or user too?
[20:59] <stgraber> skaet: that's for the scripting API. Adding a build is definitely an admin task, pushing results could be used by a regular user though I don't think it'd be that useful.
[20:59] <stgraber> I think the "add build" API is really for pushing new builds from antimony and the "add result" API is for jenkins/automated testing posting results automatically
[21:00] <skaet> stgraber,  if that's the case, then I can't think of a reason why we can't live with that for now.
[21:00] <skaet> jibel, ^^  can you see any issues?
[21:01] <stgraber> I think it's a reasonable limitation for now and if we get pressure from the community to have access to the API, I can then spend the time to implement proper authentication in there
[21:01]  * skaet nods
[21:23] <stgraber> >>> import xmlrpclib
[21:23] <stgraber> >>> rpc_srv = xmlrpclib.ServerProxy("http://192.168.122.172/xmlrpc.php")
[21:23] <stgraber> >>> rpc_srv.qatracker.builds.add(3, '12345', False)
[21:23] <stgraber> True
[21:24] <stgraber> cjwatson: ^ that's what the new API looks like from python
[21:24] <stgraber> with the parameters being: product_id, version, email_notify
[21:54] <jdstrand> skaet: hey. so I just added a bunch of tags to things, and wouldn't you know it, they showed up on everyone elses list
[21:54] <jdstrand> skaet: the kernel is fine, but it seems http://status.qa.ubuntu.com/reports/kernel-bugs/reports/rls-p-tracking-bugs.html is not aware that my team will handle apparmor
[21:55] <skaet> jdstrand,  hmm,   tool probably needs to pull a refresh from the spreadsheet again.
[21:55] <skaet> will look into it.
[21:56] <jdstrand> skaet: thanks
[21:56] <jdstrand> otherwise Daviey will come knocking on my door
[21:57] <skaet> chuckle,  and we can't have that.  ;)
[21:57] <jdstrand> nooo!
[21:57] <skaet> lol
[22:49] <tumbleweed> grumble, we have a missed (tiny) transition in oneiric, bug 882265. Uploaded botan1.8, should I wait for it to be NEWed before uploading the 3 rebuilds?
[22:49] <ubot4> Launchpad bug 882265 in botan1.8 (Debian) (and 8 other projects) "libbotan-1.8.2.so not found (affects: 9) (dups: 4) (heat: 44)" [Unknown,Unknown] https://launchpad.net/bugs/882265
[22:50] <micahg> tumbleweed: it was Debian's fault for not bumping soname I think
[22:51] <tumbleweed> the debian maintainer screwed up royally, then spent 2 uploads fixing it :P
[22:51]  * micahg is glad someone else took care of it :)
[22:52] <tumbleweed> I only saw it because it was filed against mercurial by accident, and I get python team e-mail...