[00:05] <cjwatson> slangasek: "however, in this case it's critical so it should never not be shown anyway" - except in the noninteractive case ... is that relevant here?
[00:05] <cjwatson> Laney: once broder is ready based on my test run with him, please do go ahead and make that SOP
[00:10] <infinity> RAOF: Cheers.  I'll go back to my flu now.
[00:10] <RAOF> Good luck with that :)
[01:05] <slangasek> cjwatson: dunno... what does db_go return for critical+noninteractive?
[09:19] <cjwatson> slangasek: oh, db_go - sorry, it's db_input that returns 30 for critical+noninteractive, db_go returns 0 unless the last operation was a backup (unlikely in that circumstance)
[14:00] <cjwatson> micahg: I'd like to use your bug 998103 as a test of compatibility glue in ubuntu-archive-tools; would that be OK?
[14:00] <ubot2> Launchpad bug 998103 in precise-backports "Please backport unknown-horizons 2012.1+dfsg1-1 (universe) from quantal" [Undecided,In progress] https://launchpad.net/bugs/998103
[14:03] <cjwatson> similar to the code I already have there to deal with cases where people forget about the new world order and ask archive admins to process syncs for them
[14:21] <Laney> cjwatson: If you're blocking on that, there's another one I can approve
[14:26] <cjwatson> Laney: sounds good, especially if you can confirm whether the backportpackage command my code produces is correct
[14:27] <slangasek> cjwatson: db_go> ok, great :)
[14:27] <Laney> cjwatson: hrm, possibly, but Evan would be better placed. He made some recent changes that I've not fully caught up with.
[14:27] <Laney> bug #999132
[14:27] <ubot2> Launchpad bug 999132 in precise-backports "Please backport widelands 1:17-2 (universe) from quantal" [Undecided,In progress] https://launchpad.net/bugs/999132
[14:30] <cjwatson> DEBEMAIL="iain@orangesquash.org.uk" DEBFULLNAME="Iain Lane" backportpackage -u ubuntu -c 999132 -d precise -s quantal widelands
[14:31] <Laney> LGTM
[14:32] <cjwatson> yeesh, I'd test it but the orig is 167 MiB
[14:33] <Laney> hm, looks like -v isn't hooked up to anything
=== yofel_ is now known as yofel
[14:33] <Laney> I thought it might be safer to pass that too, but clearly not if it does nothing
[14:33] <cjwatson> my current u-a-t diff is http://paste.ubuntu.com/989007/
[14:45] <Laney> I wonder why we treat the backporter as requestor
[14:49] <cjwatson> Laney: I think because they were rather more likely to have a sense of development ownership than your average user requesting a backport is
[14:52] <Laney> It feels a bit more like sponsorship, since we expect others to do the testing now. Maybe that's just me though.
[15:00] <slangasek> Laney: well, I've seen backport requests in the past from people whose launchpad "real name" fields were inappropriate to list in a changelog ;)
[15:08] <slangasek> infinity, stgraber: ad hoc bug report - getaddrinfo() appears to not be doing name resolution of non-FQDNs correctly in precise for IPv6 hosts
[15:11] <infinity> slangasek: Do you mean "not at all", or "incorrectly", as in it returns garbage?
[15:12]  * infinity suspects it might be time to upgrade his home network to v6...
[15:12] <slangasek> skaet: can you send out some announcement to ubuntu-devel this week about how we're supposed to handle release notes in the blueprints this cycle?  It's best to get that announced ASAP since everyone's drafting this week
[15:12] <skaet> slangasek, will do.
[15:12] <slangasek> infinity: "not at all" - I have to stick a . on the end of every hostname to get ping6 to return anything useful
[15:12] <slangasek> skaet: ta :)
[15:13] <stgraber> slangasek: do you have any more detail? looks fine here
[15:13] <stgraber> >>> socket.getaddrinfo("shell01.dmz.dcnue", 22)
[15:13] <stgraber> [(10, 1, 6, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (10, 2, 17, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (10, 3, 0, '', ('2001:470:714b:1025:218:51ff:fec2:289a', 22, 0, 0)), (2, 1, 6, '', ('172.22.25.30', 22)), (2, 2, 17, '', ('172.22.25.30', 22)), (2, 3, 0, '', ('172.22.25.30', 22))]
[15:14] <stgraber> >>> socket.getaddrinfo("dnsr05.dmz", 22)
[15:14] <stgraber> [(10, 1, 6, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (10, 2, 17, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (10, 3, 0, '', ('2607:f2c0:f00f:2725:8837:98ff:fe43:90e6', 22, 0, 0)), (2, 1, 6, '', ('172.17.25.30', 22)), (2, 2, 17, '', ('172.17.25.30', 22)), (2, 3, 0, '', ('172.17.25.30', 22))]
[15:15] <stgraber> right, looks good here (with lan.sherb.stgraber.net sherb.stgraber.net stgraber.net in my search path)
[15:18] <infinity> slangasek: I'm taking another sick day, my flu seems to be intent on trying to kill me, but if you and stgraber figure out a way to blame glibc for your issues, let me know.
[15:29] <slangasek> infinity: bah and ack - throw me a canonicaladmin request?
[15:30] <infinity> slangasek: Done.
[15:34] <stgraber> skaet: http://iso.qa.dev.stgraber.org/qatracker/milestones/216/builds <-- see the (ready) next to Edubuntu and the big "Mark ready" button
[15:36] <skaet> stgraber,  not seeing... permissions?
[15:36] <skaet> (but happy that I should be seeing it... ;) )
[15:37] <stgraber> skaet: are you logged in?
[15:37] <skaet> yup.  :)
[15:37] <stgraber> skaet: in all cases, you should see the (ready) next to Edubuntu
=== jrgifford_ is now known as jrgifford
[15:43] <stgraber> cjwatson: I just saw https://launchpad.net/ubuntu/precise/+source/lxc/0.7.5-3ubuntu55 which looks wrong. -ubuntu54 was moved to updates but AFAIK -ubuntu55 still needs testing
[15:45] <stgraber> cjwatson: hallyn will upload a new ubuntu55 to -proposed to fix that and include an extra change
[15:46] <stgraber> (adding a fix for bug 999187)
[15:46] <ubot2> Launchpad bug 999187 in lxc "lxc-create for armhf fails with error "failed to execute template 'ubuntu'"" [High,New] https://launchpad.net/bugs/999187
[15:49] <cjwatson> stgraber: hm, I guess pending-sru is a bit overenthusiastic there
[15:49] <cjwatson> stgraber: it may have to be ubuntu56 now, sorry
[15:50] <stgraber> yeah, I'll upload ubuntu56 using -v to include ubuntu55
[15:51] <cjwatson> there must have been a race, as pending-sru would only have printed that if -updates were >= -proposed
[15:52] <cjwatson> yeah, published 00:34:39 UTC, removal requested 00:35:06 UTC
[15:52] <cjwatson> so just rotten luck
[16:03] <stgraber> skaet: thanks for the screenshot. So at least the user part of the change "(ready)" is visible there. I can't easily check but it looks like the website doesn't know you're in ubuntu-release. Maybe logging out and back in will fix it (making sure ubuntu-release is ticked on the SSO page)
[16:04] <skaet> stgraber, will do and let you know if that changes anything.
[16:05] <stgraber> skaet: whenever I update to a new DB snapshot from production the SSO is acting a bit weird in Drupal. Sometimes logging me out randomly (that's why I asked) or just not mapping the roles properly, I guess I should be doing something a bit more clever than simply dumping the whole DB (like remove the existing SSO tickets :))
[16:05] <stgraber> the good thing is that it only affects the development/staging environment, not production deployments
[16:05] <skaet> :)
[16:07] <stgraber> cjwatson: can you let that one in? it contains the old -ubuntu55 and adds a cherry-pick from quantal (one line, trivial bug/fix)
[16:10] <stgraber> skaet: I'm working on the ISO tracker blueprint, do you know the LP username for timrc? (LP tells me timrc doesn't exist)
[16:12] <slangasek> stgraber: http://paste.ubuntu.com/989151/
[16:13] <stgraber> skaet: nevermind, found him
[16:13] <slangasek> stgraber: /etc/gai.conf is unmodified
[16:13] <slangasek> mdns is enabled for hosts
[16:14] <stgraber> slangasek: http://paste.ubuntu.com/989160/
[16:14] <slangasek> I do have an IPv4 /etc/hosts entry for this particular host which shadows the DNS, but that has not previously been a problem
[16:17] <stgraber> I'd blame the /etc/hosts entry, I seem to remember seeing a similar behaviour here (and wanted it). Basically putting an IPv4 entry in /etc/hosts will make getaddrinfo() return it and not do any further resolving (so no IPv6 record returned)
[16:17] <slangasek> stgraber: confirmed that this is not a problem with oneiric eglibc
[16:17] <slangasek> hmm
[16:17] <slangasek> well, yuck
[16:17] <slangasek> why do you want this behavior?
[16:17] <stgraber> I use it sometimes when I want to avoid using IPv6 for a specific host (where the IPv6 address doesn't respond)
[16:17] <slangasek> hmm
[16:18] <slangasek> it's definitely a regression for me
[16:19] <slangasek> my /etc/hosts entries are there as a guard against DNS resolution failing so I can still get around the local network during a network outage
[16:19] <slangasek> but I don't want to hard-code IPv6 addresses there
[16:19] <stgraber> slangasek: then you should move "files" after "dns" in /etc/nssswitch.conf?
[16:19] <slangasek> well, I won't do that :)
[16:20] <slangasek> I would sooner remove the entries from /etc/hosts
[16:20] <slangasek> but I would like to know the upstream justification for this behavior change
[16:21] <stgraber> slangasek: http://paste.ubuntu.com/989173/
[16:21]  * slangasek nods
[16:21] <slangasek> doesn't it seem a little odd that the behavior should be dependent on whether an fqdn is used?
[16:22] <stgraber> I don't have Oneiric around but at least Lucid had the same behaviour as Precise
[16:22] <slangasek> oh, you're seeing this with lucid, interesting
[16:22] <slangasek> would a (Canonical) archive admin care to review the fluendo packages in partner/precise/unapproved?
[16:23] <stgraber> I'm not familar with the files nss module but it might be that it simply won't match the fqdn syntax (with the final dot)
[16:24] <slangasek> heh, funny
[16:25] <stgraber> so my guess is that the bug is that it worked at all for you ;)
[16:25] <slangasek> blah
[16:26] <cjwatson> stgraber: ok, done
[16:27] <stgraber> cjwatson: thanks
=== jbicha_ is now known as jbicha
=== Ursinha` is now known as Ursinha
=== Ursinha is now known as Guest8786
[22:06] <slangasek> cjwatson: hmm.  bug #863741 became un-fixed in precise; rpcbind dropped back to priority: optional (was priority: standard in precise).
[22:06] <ubot2> Launchpad bug 863741 in nfs-utils "apt doesn't want to replace portmap with rpcbind on upgrade" [Medium,Fix released] https://launchpad.net/bugs/863741
[22:06] <slangasek> cjwatson: thoughts on how to fix this?  null SRU + priority override? :/
[22:16] <stgraber> skaet: so I tried to get the full changelog in the build notes of the tracker but it's really quite ugly (http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/16074/testcases), I think it'd be best just to give a link (http://iso.qa.ubuntu.com/qatracker/milestones/219/builds/16075/testcases)
[22:17] <stgraber> an alternative is to parse the changes file and only extract the changelog entry which should be quite a bit shorter than the whole changes entry
[22:30] <skaet> stgraber,  link will work for now.   However,  maybe you can reuse the changelog extraction code in: http://people.canonical.com/~cjwatson/lucid-updates.py?
[22:36] <stgraber> skaet: oh yeah, that'd work
[22:36] <skaet> :)
[23:48] <micahg> http://people.canonical.com/~ubuntu-archive/testing/quantal_probs.html doesn't seem to be getting updated, is this known?
[23:53] <cjwatson> slangasek: hmph; if it's meant to be priority standard, shouldn't it be seeded or something?
[23:53] <slangasek> cjwatson: it probably should've been :/
[23:53] <cjwatson> slangasek: I have a feeling that if we ran change-override.py -s precise-updates or whatever it is, that might result in a new publication to precise-updates ...
[23:54] <cjwatson> ICBW
[23:54] <cjwatson> micahg: looking
[23:54] <slangasek> I don't know that it needs to be standard for quantal anyway, it was entirely to try to force the issue with apt not wanting to replace portmap with rpcbind on upgrades
[23:55] <slangasek> 2012-05-15 23:55:25 ERROR   Could not find binaries for 'rpcbind/None' in Primary Archive for Ubuntu: precise-UPDATES
[23:55] <slangasek> looks like I should pocket-copy first
[23:55] <slangasek> cjwatson: ^^ think I should do it?
[23:57] <cjwatson> I think that would make sense, yes
[23:57] <cjwatson> least-bad
[23:59] <slangasek> done