| infinity | stgraber: If they're already supporting those packages in trusty, it shouldn't be hard to convince them. | 00:34 |
|---|---|---|
| === doko_ is now known as doko | ||
| cjwatson | . | 09:04 |
| cjwatson | bah | 09:04 |
| pete-woods | cjwatson: hi, I've finally managed to get HUD through ci-train again (apparently my packages were "in no known space and time" for a while) | 10:41 |
| pete-woods | cjwatson: really hoping I've cleaned up the changelog suitably for you now :) | 10:41 |
| cjwatson | pete-woods: hopefully somebody else can look today as I'm on leave | 12:08 |
| pete-woods | cjwatson: no problem, sorry for the holiday nag! | 12:08 |
| === fginther` is now known as fginther | ||
| mlankhorst | any sru admins here? part of the xorg-lts-trusty stack is still unapproved | 12:29 |
| Riddell | you want the ~ubuntu-sru team mlankhorst | 12:39 |
| rcj | stgraber, libdumbnet was promoted to main with open-vm-tools in trusty. Let me find the MIR for that for more history | 12:39 |
| rcj | stgraber, MIR for libdumbnet was bug #1220950. Only dependency is libc6 | 12:41 |
| stgraber | rcj: ok, sounds like it should be fine to promote then (same upstream version so shouldn't be much work to update in case of a security problem) | 13:05 |
| rcj | stgraber, yeah. Sorry I didn't mention it earlier. We knew about the dependency and I was told that it would get pulled along since we had done the MIR before. That wasn't correct so sorry for the extra work. | 13:06 |
| stgraber | infinity: so just to confirm because I've never done this before, if I want to promote libdumbnet from universe to main in precise and it never had any SRU there, I need a no change rebuild, right? | 13:08 |
| stgraber | or do we do weirder magic like copy the version from the release pocket to the update pocket just so we can override it to main? | 13:09 |
| doko | stgraber, when is 14.04.1 scheduled? | 13:24 |
| stgraber | doko: first or second week of August IIRC | 13:29 |
| doko | stgraber, thanks! | 13:32 |
| infinity | stgraber: No, you can copy it to -updates and promote it there. | 14:27 |
| stgraber | ok, doing that then | 14:27 |
| infinity | stgraber: Have you gotten a security person or two to sign off on the precise version being supportable? | 14:28 |
| infinity | (Like, maybe the trusty MIR involved an audit, fixing some things, etc) | 14:28 |
| seb128 | hey SRU team, could you pocket copy to utopic when you move things to -updates? (I noticed some packages are outdated in utopic compared to trusty because they didn't get copied) | 14:29 |
| stgraber | infinity: precise and trusty have the same upstream version, only changes that happened in between are switch to dh_python2, change of Debian maintainer and a no change rebuild by doko. | 14:30 |
| stgraber | mdeslaur, jdstrand: any objection to me promoting libdumbnet to main in precise for use by open-vm-tools-lts-trusty? (as I said above, same upstream version as trusty, minor packaging changes between the two but nothing that looks security-related) | 14:31 |
| mdeslaur | stgraber: no objection from me | 14:34 |
| === marrusl_ is now known as marrusl | ||
| infinity | stgraber: A switch to dh_python2 from what? | 14:42 |
| infinity | stgraber: If it was python-support in precise, that change needs to be made there too. | 14:43 |
| infinity | seb128: We're a bit far into the cycle to be doing that for every SRU. | 14:43 |
| seb128 | infinity, what's the issue with pocket copies? | 14:44 |
| seb128 | that's not different from having those copied when the new serie open | 14:44 |
| stgraber | infinity: just grabbed the diff, it was python-central back in precise, so yeah, we need that change in there before promoting | 14:44 |
| infinity | seb128: The issue is three things. (1) If we have new toolchain changes (we don't, currently), we want as much stuff organically rebuilt as possible, but yes, not necessary. | 14:45 |
| infinity | seb128: (2) If there's a library transition or some such, the old one just plain won't work on the new series. | 14:46 |
| infinity | seb128: (3) we're lacking tooling to actually track sanely when something is a newer version in an older series (yes, our fault, but it means we rely on people who expect an SRU to get copied to notify us of that, not just expect it) | 14:47 |
| stgraber | rcj: can you prepare an SRU of libdumbnet for precise which makes it an equivalent of what we have in trusty? (we at least need the switch to dh_python2 but the --add-missing change seems useful too, so I'd just make the SRU be identical to trusty's current version) | 14:47 |
| mdeslaur | utopic now has -fstack-protector-strong by default | 14:47 |
| seb128 | infinity, do we have tooling telling us what is outdated in utopic compared to trusty? | 14:47 |
| infinity | seb128: No, we don't, which I mentioned above. | 14:48 |
| seb128 | k | 14:48 |
| infinity | (I mean, it's doable, obviously, but we don't have any reports that tell us) | 14:48 |
| seb128 | well, I assumed the SRUs would be copied and I didn't keep track of those | 14:48 |
| seb128 | I guess things are going to sort themself over time | 14:48 |
| seb128 | I just noticed this morning because somebody had an issue due to trusty-updates having a newer gtk2 than utopic | 14:49 |
| infinity | mdeslaur: Ahh, did that happen? I missed that. So, that's a fine argument for not copying wholesale every time. | 14:49 |
| seb128 | well, we do copy on the opening | 14:49 |
| mdeslaur | infinity: oh, actually we didn't switch to gcc-4.9 yet | 14:49 |
| seb128 | if we wanted to rebuild eveyrthing we wouldn't | 14:49 |
| infinity | seb128: Sure, we don't want to rebuild everything. We just generally want uploads to go to the devel series first. | 14:50 |
| infinity | seb128: Also so that fixes don't get lost. | 14:50 |
| infinity | seb128: So, yeah, if people indicated that something was also meant to go to devel-proposed, sometimes that's perfectly reasonable. | 14:50 |
| * infinity copies that gtk2... | 14:50 | |
| seb128 | infinity, thanks, I'm going to have a look to my other SRUs to see which ones are in the same case | 14:51 |
| infinity | seb128: Other than the (admitedly shaky) toolchain argument, it's mostly just a lack of tooling/tracking that makes it onerous right now. | 14:51 |
| infinity | seb128: Also, you don't need an SRU or AA person to do this. If you have a list, you can just "for i in $seb_list; do copy-package -s trusty-updates --to-suite=utopic-proposed -b $i; done" | 14:52 |
| seb128 | infinity, going to do that (I'm archive admin as well, so I've no excuse anyway ;-) | 14:53 |
| infinity | seb128: Sure, I know you're an AA, just saying. Uploaders should be able to do this themselves (except people who were sponsored and would need to poke their sponsor). | 14:54 |
| seb128 | infinity, but I might be wanting to join the SRU team/help with reviews, if you guys are interested (not sure if I should "apply" somewhere and how, so just mentioning it) | 14:58 |
| infinity | seb128: There's no real application, per se, it's a combination of interest and invite, and a bit of 1-on-1 training and glaring from someone who picks apart your slack reviews until they measure up. ;) | 15:00 |
| seb128 | infinity, well, I stated my interest then I guess ... ;-) (I feel like it's only fair, for all the desktop SRUs I keep sending for review ... and it might help taking other stuff out of the queue and help getting my desktop stuff reviewed as well ;-) | 15:02 |
| infinity | seb128: Indeed, that's sort of how we like to see it work. Cross-team code review is a Good Thing too, IMO. When you're reviewing code you've never seen and may not understand, you tend to be pickier and ask more "stupid" questions, that gets the uploader thinking about intent, code flow, etc. | 15:03 |
| rcj | stgraber, I'll get to work on those changes | 15:12 |
| rcj | stgraber, what is the right version for the SRU'd libdumbnet in precise if the current version is 1.12-3.1? 1.12-3.2 or 1.12-4? | 15:21 |
| stgraber | rcj: 1.12-3.1ubuntu0.1 | 15:22 |
| rcj | stgraber, good thing I asked. Thanks.. | 15:23 |
| rcj | stgraber, I have an SRU bug #1326025 for the libdumbnet updates and an MP #221919 for the change. | 16:32 |
| niedbalski__ | Can https://bugs.launchpad.net/ubuntu/+source/biosdevname/+bug/1324558 be reviewed for -proposed ? | 16:35 |
| niedbalski__ | thanks! | 16:35 |
| infinity | zequence: Your desktop-minimal seed change crashes germinate. | 16:36 |
| ogra_ | we have a desktop-minimal seed ? | 16:36 |
| infinity | ogra_: studio. | 16:37 |
| ogra_ | oh | 16:37 |
| ogra_ | k | 16:37 |
| infinity | zequence: I reverted your last two studio seed commits, since they're crashing germinate in production. You might want to test locally first before reapplying. :) | 16:41 |
| ScottK | Bad commits or germinate bug? | 16:43 |
| infinity | ScottK: Undecided. But reverting them for now was the fastest way to a happy publisher. | 16:52 |
| ScottK | Sure. | 16:54 |
| infinity | Also, in a fit of "I'm an adult, I can do whatever stupid thing I want", I bought a bunch of butterscotch pudding last night, so nothing can get me down today. Even exploding infrastructure. | 16:55 |
| ScottK | Lol. | 16:57 |
| mdeslaur | lol | 16:58 |
| zequence | infinity: My lack of knowledge for seeds. But, I'm not too worried about ISO building problems. More about getting those changes through correctly | 17:07 |
| zequence | infinity: Are you saying other projects are affected as well, besides Ubuntu Studio? | 17:07 |
| infinity | zequence: Yeah, it crashed germinate in production, which wreaks havoc with the publisher. | 17:07 |
| zequence | infinity: Could I see the error log somehow? | 17:12 |
| infinity | zequence: http://paste.ubuntu.com/7581273/ <-- Obviously only the last two lines matter, the rest is launchpad exploding because of it. :P | 17:13 |
| zequence | infinity: Thanks | 17:14 |
| rcj | stgraber, the libdumbnet upload in bug #1326025 is complete for precise thanks to smoser. | 18:56 |
| stgraber | rcj: thanks. I'll take a look in a few minutes. I'll let it into precise-proposed, promote it to main then build open-vm-tools-lts-trusty against it. We'll need both tested and released together. | 18:58 |
| rcj | stgraber, absolutely. Thanks. | 18:58 |
| infinity | stgraber: Keep in mind that if there's even the slightest chance of a security update being done to open-vm-tools-lts-trusty in the future, libdumbnet will need to end up in both updates and security when it's released. | 18:59 |
| stgraber | infinity: good point. I'll make sure to do that. We could wait until we actually get a security update but it's probably going to be less confusing to just do it now instead (and the package doesn't have any user visible change, so it's fine to push to -security anyway) | 19:01 |
| infinity | stgraber: Assuming it's installible in security despite having been built in proposed against updates. | 19:01 |
| infinity | stgraber: Worth a check on that before copying. :) | 19:01 |
| * stgraber does some SRU queue review, seems like we're a bit behind with all that sprinting | 20:19 | |
| cjwatson | ScottK: I'd call them bad commits. There was a seed that was undeclared in their STRUCTURE file. | 20:38 |
| ScottK | Fair enough. Thanks. | 20:39 |
| cjwatson | zequence: ^- that, and also there was an "ububuntustudio" or some such typo in there | 20:39 |
| zequence | cjwatson: Ah, thanks | 21:02 |
| zequence | just started reading through some about the build process. Seems like most of the docs are in ubuntu-cdimage? Though, I could just do a germinate command to test our seeds specifically? | 21:03 |
| cjwatson | ubuntu-cdimage won't help you with germinate | 21:04 |
| cjwatson | Yeah, just run it by hand against your seeds and you'll see it | 21:04 |
| cjwatson | It has a man page or --help | 21:04 |
| zequence | Alright | 21:06 |
| stgraber | infinity, cjwatson: do we have some kind of stable release exception for gcc-snapshot? We've got one in the queue with a 175.7MB large diff, I don't really feel like reviewing it ;) (bug 1315378) | 21:15 |
| infinity | stgraber: No. | 21:15 |
| infinity | stgraber: I'm still not sure I see the point of that bug. We don't want things build-depending on gcc-snapshot, and if people want to "build and test gnat on arm64" they can do so in 14.10, where gnat works. | 21:16 |
| infinity | stgraber: Oh, and since you seem to be queue happy today, I have context on the walinuxagent stuff (I've sent it back a few times already), so I'll deal with that. | 21:17 |
| stgraber | infinity: yeah, I noticed it getting rejected a few times so I wasn't going to touch it. | 21:18 |
| stgraber | auto-apt, audacity, tracker and ubuntu-touch-meta are all waiting for bug updates or feedback from uploaders. | 21:19 |
| stgraber | walinuxagent is yours and I'll take a look at those syncs now (cjwatson said something about one of our tools knowing how to diff them, I'll try to figure out which now :)) | 21:20 |
| cjwatson | stgraber: I misspoke slightly; what I was remembering was that "queue fetch" knows how to fetch them via the copy, so you can at least pull-lp-source; queue fetch; debdiff | 21:24 |
| cjwatson | stgraber: The logic in queue fetch would still be useful for any other tool that wants to do this kind of thing before the Soyuz redesign, though | 21:24 |
| stgraber | ah, that's already much better than what I used to do (clicking through 3 pages on LP to grab the dsc) | 21:24 |
| infinity | Can queue fetch do only-source now? Cause having it fetch all the binaries made it pretty awful. | 21:25 |
| cjwatson | Yes, I fixed that shortly after noticing the same thing | 21:25 |
| infinity | --source I guess? | 21:25 |
| cjwatson | Right | 21:25 |
| infinity | I'll have to try to remember that. I've been doing the click, click, click, dget dsc thing. | 21:26 |
| cjwatson | Fixed a bit over a year ago by the looks of things | 21:26 |
| infinity | Learning new tools takes me a while. :) | 21:26 |
| cjwatson | It's almost enough that I don't have much impetus to care about an easier diff tool, except for large packages | 21:27 |
| infinity | And sometimes lets me down. Like, shotly after learning that dget works on .changes, my hopes and dreams for using it were dashed by launchpad's .changes being incomplete (due to translations and ddebs). | 21:27 |
| cjwatson | But for large packages it would only really help if it were in LP | 21:27 |
| infinity | I suppose dget could use an --ignore-missing option. | 21:28 |
| stgraber | rcj: libdumbnet accepted. I'll let it build and publish, then override to main, then retry the open-vm-tools-lts-trusty build, hopefully all of that before I have to run away from here ;) | 21:39 |
| infinity | stgraber: Should have overridden it to main before it built, to make sure it doesn't have any build-deps in universe (unless you carefully checked). | 21:40 |
| infinity | Ahh, looks good anyway. | 21:41 |
| stgraber | infinity: yeah, I should have, but indeed, the two non-obviously correct ones are both main, so that's all fine | 21:43 |
| stgraber | done with SRUs for now, queues should be much more reasonable now (hopefully people will reply to my pings and I can process the rest of trusty tomorrow) | 22:09 |
| gaughen | thanks stgraber! | 22:16 |
| infinity | stgraber: Since you've been in a queue mood today, want to review my d-i upload in trusty (or just tell me to self-accept since it's obvious)? | 23:08 |
| === Sarvatt_ is now known as Sarvatt | ||
| === pitti_ is now known as pitti | ||
| === tyhicks` is now known as tyhicks | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!