| infinity | mdeslaur: Looks like someone else beat me to it. | 03:58 |
|---|---|---|
| Mirv | archive admins around? there's a new mir release that would appreciate an ack from you to add new binaries libmirserver29, libmirplatform6, mir-platform-graphics-mesa, mir-platform-graphics-android, mir-client-platform-mesa-dev - could you take a look? | 06:11 |
| Mirv | the mir source package is built at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages and a summary of debian/ changes (+ build tools diff) is at https://ci-train.ubuntu.com/job/ubuntu-landing-012-2-publish/60/artifact/packaging_changes_mir_0.11.0+15.04.20150209.1-0ubuntu1.diff | 06:12 |
| infinity | Mirv: Looks wrong at first glance, but I'm checking the current state of things before I say that. :P | 06:22 |
| infinity | Mirv: So, mir-platform-graphics-* are replacing libmirplatform5driver-* right? | 06:30 |
| infinity | Mirv: This doesn't affect transaction upgrades like phones, but for apt-get users, you should have the new Conflict/Replace the old to force a smooth upgrade, probably. | 06:33 |
| Mirv | infinity: yes, the commit is https://code.launchpad.net/~mir-team/mir/server-platform-probing/+merge/244982 | 06:40 |
| Mirv | infinity: but the new files are not named the same | 06:41 |
| Mirv | so the upgrade wouldn't break | 06:41 |
| Mirv | infinity: so is it ok or do you want something to be done still? I don't think Conflict/Replaces is needed as it's not conflicting/replacing any of the old files | 07:14 |
| Mirv | I'll give any feedback back to the Mir team | 07:14 |
| infinity | Mirv: The upgrade won't break due to file overlaps, but the old packages will stay installed for no good reason. | 07:59 |
| infinity | Mirv: C/R together is a hint to apt to say "replace this package completely with this other one". | 07:59 |
| infinity | Mirv: But you could just argue that apt-get autoremove will sort it later, if that package is always installed only as a dependency of other packages. | 08:00 |
| infinity | Mirv: So, meh. Not a hard NACK from me, just a style issue. | 08:00 |
| Mirv | ok then | 09:04 |
| LocutusOfBorg1 | cjwatson, can you please sync guidedog from debian? (LP: #1407484) | 09:08 |
| ubot93 | Launchpad bug 1407484 in guidedog (Ubuntu) "[needs-packaging] guidedog needs packaging" [Wishlist,New] https://launchpad.net/bugs/1407484 | 09:08 |
| LocutusOfBorg1 | it should require a manual hint... | 09:08 |
| LocutusOfBorg1 | (or anybody else, please tell me if I'm wrong somewhere) | 09:11 |
| darkxst | can we get ddebs enabled for ppa:ubuntu-gnome-packaging/staging | 10:13 |
| darkxst | moving forward that will become the official bridge between gnome3-staging ppas and the archive, rather than using a mishmash of personal ppa's for that task | 10:14 |
| mvo | hi, could someone please reject the update-manager upload into precise-propsed? there is a incorrect bug reference in there | 10:38 |
| cjwatson | infinity,Mirv: We don't normally use C/R for library transitions, surely; I'd be concerned that for this kind of thing it would make the upgrade unresolvable? | 10:38 |
| cjwatson | or at least over-complex | 10:39 |
| cjwatson | LocutusOfBorg1: done. please check whether any of the changes in https://launchpad.net/ubuntu/+source/guidedog/1.0.0-6ubuntu1 need to be ported forward | 10:42 |
| cjwatson | LocutusOfBorg1: no, it didn't require a manual hint, just required running syncpackage and then some queue processing | 10:42 |
| LocutusOfBorg1 | cjwatson, it is qmake now, so everything is fixed already | 10:43 |
| LocutusOfBorg1 | and BTW that bash-ism is fixed (I fixed it upstream prior to upload) | 10:43 |
| LocutusOfBorg1 | so yes, plain sync should be ok :) | 10:43 |
| LocutusOfBorg1 | thanks a lot | 10:43 |
| cjwatson | ok | 10:44 |
| LocutusOfBorg1 | I'm looking at the diff, there is one patch I'm wondering if needed or not | 10:48 |
| LocutusOfBorg1 | http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/guidedog/vivid/view/head:/debian/patches/alternative_shell_fixes.patch | 10:48 |
| cjwatson | well, generally avoiding the shell in C/C++ code makes for better code; but afaik all /bin/sh providers in Debian/Ubuntu can cope with "export foo=bar", even though some non-POSIX shells require that to be done in two passes | 10:50 |
| LocutusOfBorg1 | so I'll fix in a later release without any hurry :) | 10:51 |
| cjwatson | I might be missing something, try it with /bin/sh pointing to dash and see | 10:51 |
| LocutusOfBorg1 | I have sh pointing to dash already ;) | 10:51 |
| cjwatson | IIRC the default shell on FreeBSD doesn't like "export foo=bar" | 10:51 |
| cjwatson | compare http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=51e3c207a28e6973d034cab241e3c9af64538d22 | 10:52 |
| LocutusOfBorg1 | thanks, I'll fix it :) | 10:52 |
| cjwatson | actually, no, that's something slightly different | 10:53 |
| cjwatson | I was thinking of http://git.savannah.gnu.org/cgit/man-db.git/commit/?id=ce301be3082e376ef73dd079f0389115f619786f and so of course it was old Solaris | 10:53 |
| LocutusOfBorg1 | I had to do something similar once, but I never had such issues again | 10:53 |
| LocutusOfBorg1 | anyway seems worth a change | 10:53 |
| infinity | cjwatson: It's a plugin, not a library, but fair point. | 10:56 |
| === oSoMoN_ is now known as oSoMoN | ||
| cjwatson | infinity: So, how do we want to handle hints for non-devel proposed-migration runs? Should we just share a single hints branch for everything, since versions generally aren't shared and if they are then a shared version is normally QAed for everything at the same time? | 12:18 |
| cjwatson | infinity: Although that might make block-all cumbersome to handle. | 12:18 |
| cjwatson | infinity: So if you'd prefer to create ~ubuntu-sru/britney/hints-ubuntu-$series, perhaps, that'd be good with me. (It should probably be ubuntu-sru, not ubuntu-release) | 12:19 |
| infinity | cjwatson: I think per-series makes more sense, probably owned by SRU, which is cumbersome for you to set up since you recused yourself. :P | 12:28 |
| cjwatson | Yup. :-) | 12:29 |
| infinity | cjwatson: Want to be reactivated for a bit, if this is something you're working on? | 12:29 |
| cjwatson | I guess I could set it up and then immediately leave again. | 12:29 |
| cjwatson | I'll just send you MPs for the britney branches, though (and possibly deploy live anyway) | 12:29 |
| infinity | cjwatson: Reactivated for now; we can talk about it when I'm slightly more available. | 12:29 |
| cjwatson | They shouldn't be complicated | 12:30 |
| cjwatson | Sure. Is it Connect or something? | 12:30 |
| infinity | cjwatson: Yeah. | 12:30 |
| cjwatson | Enjoy. | 12:30 |
| infinity | cjwatson: Owned by SRU means we can make the unblock hints automagic via sru-release, which is the sane way, I think. | 12:30 |
| infinity | cjwatson: Rather than having people actually twiddle files and commit. | 12:30 |
| cjwatson | Yeah, true | 12:31 |
| infinity | cjwatson: Though, in that case, I'll have to think of some way to clean them post-promotion, so people's hint files down grow without bound. | 12:31 |
| infinity | But meh, that's a minor detail. | 12:31 |
| cjwatson | Big hint files aren't a major problem | 12:32 |
| infinity | Yeah, hence the minor detail comment. | 12:32 |
| infinity | They're more messy than anything. | 12:32 |
| cjwatson | I'll probably leave out block-proposed bug support entirely | 12:32 |
| cjwatson | But everything else should be pretty simple | 12:32 |
| infinity | cjwatson: If you can keep it, I think the kernel team wants to use it. | 12:32 |
| infinity | cjwatson: To make their automated testing stop a kernel from being a migration candidate if, say, DKMS builds fail. | 12:33 |
| infinity | cjwatson: Andy and I discussed such a thing last week. | 12:33 |
| cjwatson | Huh, OK. Shall I make it block-$SERIES-proposed in that case? | 12:33 |
| infinity | cjwatson: Yeah, I guess, so we don't get weird overlap with the devel series. | 12:34 |
| cjwatson | And probably make both block-proposed and block-vivid-proposed work so that people don't get confused. | 12:34 |
| cjwatson | Or so that people get differently confused. :P | 12:34 |
| infinity | cjwatson: Though, maybe block-proposed-$series, to match the convention for v-needed-* and v-done-* | 12:34 |
| infinity | (Even if that means the suite is now backwards...) | 12:35 |
| cjwatson | Forwards suite was my thought, but I suppose matching v-* is reasonable | 12:35 |
| * infinity wanders off. | 12:38 | |
| === jpds is now known as Guest49936 | ||
| === pgraner-afk is now known as pgraner | ||
| cjwatson | infinity: Could you go over https://code.launchpad.net/~ubuntu-release/britney/britney1-ubuntu/+activereviews when you get a minute, please? | 14:21 |
| cjwatson | infinity: I've created the SRU hint branches for lucid/precise/trusty/utopic and pre-emptively vivid | 14:22 |
| cjwatson | (actually vivid is because I'm getting either proleptic or forgetful in my old age, but it'll be useful in a bit) | 14:22 |
| mvo | hi, could someone please reject the previous update-manager upload into precise-propsed? there is a incorrect bug reference in there and I uploaded a newer version this morning that fixes a incorrect bug reference | 16:15 |
| mvo | eh, actually - just reject all precise-proposed update-manager upload, just found another typo | 16:38 |
| * didrocks flushes | 17:55 | |
| teward | can a distro manager review and release nginx to precise-proposed and trusty-proposed? There is a bug where the nginx cache manager and a module in nginx-extras don't get along in Trusty and Precise, allowing the cache to (1) not work correctly, and (2) expand beyond maximum set boundaries (i.e. if 1024MB is the max boundaries set, cache can expand beyond that). If you have questions you can direct them at me. https://bugs.launchpad.net/ngi | 18:02 |
| teward | nx/+bug/1216817 is the relevant bug (set to Medium because you could run into an 'out of space' error with the cache allowing to grow beyond maximum bounds on resource-limited servers) | 18:02 |
| teward | blah, whatever, i hate irc truncation. | 18:02 |
| stgraber | would appreciate if those procps uploads could be processed shortly as the previous procps update combined with current LXC is causing upgrade failure to people right now. | 19:20 |
| === elfy is now known as hobgoblin | ||
| === hobgoblin is now known as elfy | ||
| infinity | stgraber: Looking. | 19:57 |
| infinity | stgraber: Did you forward that upstream and/or to Debian as well? Looks like a sane fix. | 19:57 |
| stgraber | infinity: apparently we never upstreamed the previous fix... I'll send a merge request upstream with the two combined | 20:00 |
| infinity | stgraber: Also, I didn't check the constants, but from the naming, wouldn't ERR_PERMISSION_DENIED be more appropriate for ROFS than ERR_UNKNOWN_WRITING? | 20:00 |
| * infinity goes string hunting. | 20:00 | |
| stgraber | infinity: at the top of the same file | 20:01 |
| stgraber | though that's in precise only, more recent version of procps no longer have those strings | 20:01 |
| stgraber | I figured I'd keep printing the exact same thing and just fix the return value in case someone was somehow looking at the output | 20:02 |
| infinity | stgraber: Would explain why I can't find it in vivid. :P | 20:02 |
| infinity | stgraber: So, yeah, permission denied is probably "better", but if it's only precise, I don't care. The generic error is fine too. | 20:03 |
| * infinity looks at trusty and beyond. | 20:04 | |
| infinity | stgraber: Althought, you went generic on the other ones too (ie: matching the default case instead of the eaccess case). It's pure bikeshedding, though, so I'll let you sort it with upstream when you submit. Not worth redoing for the SRUs. | 20:06 |
| stgraber | xwarn does show the errno string, so I'm actually unsure as to why they special case EACCES to begin with | 20:07 |
| stgraber | sysctl: setting key "vm.mmap_min_addr": Read-only file system | 20:08 |
| stgraber | that's what you get with the generic code | 20:08 |
| infinity | stgraber: Ahh, the full string with the errno looks totally sane. | 20:08 |
| infinity | stgraber: So maybe it's the eaccess patch that's wrong. :P | 20:08 |
| stgraber | yeah, very well may be :) | 20:08 |
| stgraber | anyway, will sort it out when I send that branch upstream (waiting on the confirmation e-mail from gitorious) | 20:09 |
| infinity | stgraber: If you can turn around some quick verifications this afternoon, I'll fasttrack releases when I wake up. | 20:10 |
| stgraber | infinity: sure can do, thanks! | 20:11 |
| stgraber | infinity: https://gitorious.org/procps/procps/merge_requests/37 | 20:42 |
| stgraber | hopefully that'll get merged soon | 20:42 |
| === rcj is now known as Guest25083 | ||
| === sturmflut_ is now known as sturmflut | ||
| === pgraner is now known as pgraner-afk | ||
| stgraber | infinity: tested all the SRUs | 21:31 |
| === bluesabre is now known as elty | ||
| === elty is now known as bluesabre | ||
| infinity | stgraber: Ta. | 23:22 |
| infinity | stgraber: All released. | 23:24 |
| stgraber | thanks! | 23:24 |
| infinity | stgraber: NP, thanks for the quick fix. | 23:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!