[00:29] jamiebennett: I'm an SRU team member; if you coordinate with mwhudson about an SRU bug & upload, I'm happy to review. [05:09] infinity: I hadn't noticed you acked the lts drivers already, so I've no uploaded the last missing bit, xorg-lts-xenial.. === s8321414_ is now known as s8321414 [07:49] tjaalton: Danke. [07:49] tjaalton: Is that the list bit? [07:49] last, yes [07:51] Err, yes. last. :P [07:51] I'll review it this morning, flip the dailies over, and people can get to testing, hopefully. [07:53] there's an image building for an oem team right now, with this from the ppa [08:04] Ttrying nto load that site [08:06] argh === ant_ is now known as Guest59427 [08:11] python-cryptography (1.3.1-2 to 1.4-1) [08:11] Maintainer: Tristan Seligmann [08:11] 13 days old [08:11] python-cryptography/amd64 unsatisfiable Depends: python-cffi-backend-api-min (<= 9729) [08:11] python-cryptography/amd64 unsatisfiable Depends: python-cffi-backend-api-max (>= 9729) [08:11] are we not able to handle versioned provides? [08:14] Possibly not. [08:15] which package to file an issue? [08:15] Not sure if we have a project to track britney issues. [08:15] Odd are we just need to merge with Debian, unless this package is stuck there too. [08:18] yes, migrated [09:35] infinity: should be a merge, yes [09:35] possibly a complicated one [09:35] that support was added in Debian relatively recently [10:42] pitti: Could you look into merging britney from Debian, so we can haz versioned provides support? [10:42] infinity: yeah, that's been on my list for a while; they dropped the RDEPENDS list though, I need to see whether there's a replacement (I think there is) [10:43] infinity: that's because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-cryptography ? [10:44] pitti: Yeah. [10:44] we have such an enormous delta, that's going to take some effort [10:45] maybe I should convert our bzr branch to git first, so that I can do some sensible rebasing; would you mind moving to git? [10:45] pitti: All for it. [10:59] tjaalton: [10:59] -Package: xserver-xorg-video-all [10:59] +Package: xserver-xorg-video-all-lts-xenial [10:59] Architecture: any [10:59] Depends: [10:59] xserver-xorg-video-amdgpu [!hurd-any !kfreebsd-any !s390x], [10:59] - xserver-xorg-video-ati [!hurd-any !s390x], [10:59] - xserver-xorg-video-fbdev [!s390x], [10:59] + xserver-xorg-video-ati-lts-xenial [!hurd-any !s390x], [10:59] + xserver-xorg-video-fbdev-lts-xenial [!s390x], [10:59] tjaalton: What's wrong with that first depends line? [11:00] ha [11:00] tjaalton: input has similar issues. [11:00] tjaalton: For synaptics. [11:02] and can drop kbd/mouse [11:03] tjaalton: Drop or not, doesn't matter, since it's arch-qualified to oblivion. [11:03] tjaalton: Rejected for the other two issues, though. [11:03] true [11:04] infinity: awesome, bzr fast-export crashes on a UnicodeDecodeError *sigh* [11:05] pitti: Watch me be shocked. [11:07] infinity: uploaded a new one [11:07] tjaalton: Ta. [11:08] pitti: I hope your infra is happy today, I'm going to copy over a glibc to -proposed in a few minutes. [11:08] infinity: yes, it is [11:08] infinity: not for long :) [11:08] Heh. [11:08] I can upload perl and kdelibs too, if that will help? [11:09] infinity: please, and new pythons [11:09] * pitti goes to clean up the armhf runners then [11:10] infinity: one s390x machine is AWOL again (10.100.0.12), it would help if you could resussitate that? [11:10] cpaelzer: ^ [11:11] pitti: I keep forgetting how. I'm a bad mainframe user. [11:11] infinity: ? ... reading [11:12] infinity: I won't have the logins needed but you surely have - let me try to help sorting out what needs to be done :-) [11:13] infinity: I guess you want to log into the z/VM host and "restart" it, that means knowing the disk it is bootet from and ipling from it - is that what you want to do? [11:13] cpaelzer: Probably? :P [11:13] infinity: ok, let me try how far I get without asking you for passwords to foundation/LP machines [11:13] I thought you bounced it for pitti last time. Maybe it was xnox. [11:13] yes, usually xnos, and sometimes tinoco [11:14] they both have the logins needed for your z/VM host [11:15] I might. But not sure. [11:15] I have a logon here for something. ;) [11:15] Not the right something. [11:17] steps that have to be taken: 1. find which guest that IP belongs to - it was (?intentionally?) not added to the systemz HW doc [11:17] So maybe we want an xnox or tinoco. [11:17] I guess it is LM120C (C=12) [11:17] then log into the z/VM Host and IPL it from there - yes you want one of the two [11:17] and you can ask them that they share the logins with me so I can help another day if you have trouble early in the day [11:18] infinity: well if you sign it off I can ask them, but I'd need some sort of authorized ack for that request [11:18] not to say I could shred all your disks, but at least I couldn't read them - so it's safe [11:19] cpaelzer: If all you ever do is handle reboot requests, I'm sure I can trust you to do that. :P [11:19] lol [11:21] tjaalton: That looks more plausibly correct. [11:23] infinity: great, thx [11:23] pitti: I'm curious how you're killing yours. Other than the posixtestsuite vs. kernel thing, I've not been able to kill my z/VM buildds. [11:23] pitti: And I sure try. [11:24] heh, I wish I'd know [11:24] as soon as it dies, I have no access to it whatsoever [11:24] but we did install kerneloops back then [11:24] And no reasonable logging to see what it was doing right before death? [11:24] maybe it left a pile of poo somewhere [11:24] well, we do have the worker logs, so we know which test ran [11:25] but that's not very insightful, as it happens with several different ones which also run fine at other times [11:25] Irksome. [11:50] infinity: https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu \o/ [11:51] (just a straight import, no rebase/merge yet -- I'll start that after lunch) [12:04] [ubuntu/yakkety-proposed] glibc 2.23-1ubuntu1 (Accepted) [12:05] pitti: ^-- Enjoy. [12:06] would it be far-fetched to presume July 22nd is the EOL date for 15.10? [12:07] going by 9 months' time, and the date of its initial release [12:07] teward: Might be a bit later than that, but ish. [12:08] infinity: just trying to ballpark it - over on Ask Ubuntu I have a habit of trying to give 1 months notice about the EOL date :p [12:08] teward: I give 3 weeks. [12:08] For non-LTS. [12:08] ack [12:09] Usually. [12:09] I suppose I could cut this one down a bit. [12:09] But I think I'll EOL on the 28th. [12:09] Which means an announce todayish. [12:11] * infinity goes copy-and-pasting. [12:12] heh === s8321414_ is now known as s8321414