| slangasek | xnox: what's the expected behavior with debian/patches/no-print-empty-description.patch ? does this cause no information to be printed at all for these jobs, or does it instead print the job name? The latter would seem to be what we would want, but I can't see at a glance how this patch would have that effect | 00:03 |
|---|---|---|
| slangasek | xnox: ubuntu-logo-scale-factor-2.patch - man, I really wish we had patched the script plugin a long time ago to be able to take variable settings from the .plymouth config... | 00:06 |
| slangasek | feh, apparently I should really not use sru-review for trusty-proposed | 00:26 |
| slangasek | that's too bad | 00:26 |
| jpds | Could someone approve daq for me? | 00:56 |
| infinity | jdstrand: Why would you copy from your PPA to a "silo" and then to proposed? Other than the buzzwordiness of it, and needing approval from an entirely orthogonal team, it's y'know, just another PPA. | 01:19 |
| jdstrand | I noticed cause I need to do a landing | 01:19 |
| jdstrand | err | 01:19 |
| jdstrand | cause I need to do a landing | 01:19 |
| jdstrand | and that is their process | 01:20 |
| jdstrand | nothing will be rebuilt | 01:20 |
| jdstrand | I am testing the binaries in the ppa | 01:20 |
| jdstrand | err, the seurity-proposed ppa | 01:20 |
| slangasek | stgraber: ifupdown - did you test that this actually fixes the issue? the previous version being upgraded from won't actually be 0.7.5ubuntu4 anymore, will it? | 01:45 |
| stgraber | slangasek: I tested that the sed works as expected, I however could not check that the upgrade works with it since I wasn't provided with a way to reproduce this problem to begin with... | 01:46 |
| stgraber | but that version is indeed unlikely to be the source version, so the upload should be rejected while we figure this out | 01:47 |
| stgraber | 0.7.5ubuntu4 was probably raring's version (quick guess from rmadison) | 01:47 |
| infinity | Oh, I should have looked here before accepting it. | 01:48 |
| slangasek | infinity: tsk | 01:49 |
| infinity | Derp. Sorry. | 01:49 |
| stgraber | well, it won't hurt, it just won't be very useful unless someone is upgrading from raring | 01:49 |
| slangasek | stgraber: so, please get from elmo a package manager log that shows what previous version of ifupdown he had | 01:49 |
| slangasek | you probably also want a copy of the old conffile from his system | 01:52 |
| stgraber | slangasek: actually, both mpt and elmo reported the bug with an identical source confile, so I should be able to hunt it down in the history, find the source and then just check that the init script exists and matches the checksum and if so, update it, ignoring the source version check entirely | 01:53 |
| stgraber | unless you can find a good reason to care about the version check? | 01:53 |
| stgraber | (sure the user could revert the change afterwards in which case the next update would re-apply it again, but I don't see why anyone would do that and I'd argue that it's most likely wrong) | 01:54 |
| slangasek | stgraber: hmm. I suppose it's sufficiently unlikely that anyone would deliberately choose to have the old version of the conffile that we can do without the version check | 01:55 |
| stgraber | slangasek: so maybe I'm just tired and should look at that tomorrow but I'm confused again, as you pushed the preinst fix in saucy, shouldn't anyone using saucy have a sane /etc/init.d/ifupdown? if so, why is elmo and mpt filing bugs with a conffile prompt showing the diff from saucy's current init script to trusty's? | 01:58 |
| slangasek | stgraber: oh augh | 01:59 |
| slangasek | stgraber: because you must go through *two* updates of the package once it's been brought in sync, in order for the dpkg database to be synced with reality | 02:00 |
| slangasek | this was why I said we needed the conffile to not be changed until the LTS... | 02:00 |
| slangasek | this was the issue with the dpkg database listing the wrong checksum for the conffile, because it had spent time as a symlink | 02:00 |
| stgraber | ok, so if I update the sed again to properly upgrade current saucy to current trusty and drop the version check, we should be good right? | 02:02 |
| slangasek | stgraber: I think so | 02:03 |
| stgraber | ok, I'll do that then... | 02:03 |
| * infinity stops the kernel review halfway through and decides that breakfast is more important than crazy last-minute Mellanox backports. | 02:04 | |
| slangasek | stgraber: however, what I'm remembering now is that to fully clear up this issue required two successive installs of the package with the conffile unchanged... I'm not sure if fixing it now will be enough to save constantly-upgrading users from future pain post-trusty as well | 02:04 |
| slangasek | jpds: E: libdaq-dev: non-empty-dependency_libs-in-la-file usr/lib/libdaq.la | 02:15 |
| stgraber | slangasek: uploaded the one that matches saucy's current conffile | 02:16 |
| slangasek | stgraber: cheers | 02:17 |
| jpds | slangasek: My fault, only ran lintian against the library package. | 02:20 |
| slangasek | stgraber: is bug #1302270 recognizeable as a symptom of the earlier logind issue? | 03:34 |
| ubot2 | Launchpad bug 1302270 in xorg (Ubuntu) "[regression] Poor performance with recent update with i965: libGL error: failed to open drm device: Permission denied" [High,Confirmed] https://launchpad.net/bugs/1302270 | 03:34 |
| stgraber | slangasek: no, it's recognizable as one of the usual failure modes of logind when it restarts | 03:35 |
| RAOF | Man, I'm glad we switched from that unmaintained ConsoleKit... :) | 03:36 |
| stgraber | I've seen this happen a few times in the past here though never in a reliable enough way that I could report a bug and that was way before we even thought about cgmanager | 03:36 |
| stgraber | my best guess is that when logind restart if it fails to somehow get its state back, it doesn't know who's currently at the console and so flushes the ACLs | 03:37 |
| stgraber | switching VTs may be enough to get it back to a sane state (if it's just the current vt that's confusing it somehow), if it lost track of the whole seat, then you need to logout and login again which should do the trick | 03:38 |
| stgraber | my understanding of how logind works is that it reads its state back from /run/systemd/... not from the cgroups (which can't really store much information anyway), so my best guess is that this is unrelated to the bugfix we pushed today and more of a general issue. | 03:40 |
| jdstrand | stgraber: logout/login didn't seem to do it | 03:49 |
| stgraber | jdstrand: hmm, now that's pretty weird... can you pastebin /var/log/upstart/systemd-logind.log and the output of "loginctl"? | 03:50 |
| jdstrand | I did try it systematicall though. I logged in to a vt at some point | 03:50 |
| jdstrand | stgraber: does it matter that I temporarily added myself to the vido group? | 03:51 |
| jdstrand | $ loginctl | 03:51 |
| jdstrand | Failed to issue method call: Cannot launch daemon, file not found or permissions invalid | 03:51 |
| stgraber | oh, now that's really quite bad :) | 03:51 |
| stgraber | ok, so is logind even running on that system? | 03:52 |
| jdstrand | $ ps auxww|grep logind | 03:52 |
| jdstrand | jamie 18580 0.0 0.0 11744 896 pts/24 S+ 22:52 0:00 grep logind | 03:52 |
| jdstrand | no | 03:52 |
| stgraber | that'd explain some things :) | 03:52 |
| stgraber | anything in /var/log/upstart/systemd-logind.log or /var/crash which may explain that? | 03:52 |
| stgraber | anyway, "start systemd-logind" will hopefully bring things back to normal then | 03:53 |
| jdstrand | http://paste.ubuntu.com/7201679/ | 03:53 |
| stgraber | oh, that's really not good | 03:53 |
| jdstrand | /var/crash doesn't have anything for logind | 03:53 |
| jdstrand | $ sudo start systemd-logind | 03:54 |
| jdstrand | that created a crash | 03:54 |
| stgraber | ok, can you get apport to submit it? the backtrace should be pretty useful | 03:54 |
| jdstrand | yes, I'm doing that now | 03:55 |
| stgraber | based on those crashes, I expect you have cgmanager installed on that system? | 03:55 |
| stgraber | (systems without cgmanager shouldn't hit that code path at all, but best to check) | 03:55 |
| jdstrand | $ dpkg -l|grep cgm | 03:55 |
| jdstrand | ii libcgmanager0:amd64 0.24-0ubuntu2 amd64 Central cgroup manager daemon (client library) | 03:55 |
| jdstrand | ii libcgmanager0:i386 0.24-0ubuntu2 i386 Central cgroup manager daemon (client library) | 03:55 |
| jdstrand | just the lib | 03:56 |
| stgraber | ok, so you shouldn't be going through that code path at all... | 03:56 |
| stgraber | that explains why I'm not seeing this here and why anyone who has LXC installed won't either | 03:56 |
| * stgraber kind of wishes hallyn was around at the moment | 03:56 | |
| stgraber | jdstrand: are you around for a little while? I'll try to figure out what happened in hallyn's change and will provide test binaries for you to test hopefully in a tiny bit | 03:58 |
| jdstrand | stgraber: well, sorta. it is hard for me to leave my session | 03:59 |
| jdstrand | weird, i was prompted to report, but it went away | 04:00 |
| * jdstrand tries again | 04:00 | |
| stgraber | jdstrand: if you can't submit it, it's not the end of the world, there's only one nih_error_get call in there and it was added in today's upload, so that's quite likely the problem | 04:01 |
| * jdstrand clicks 'report problem' and nothing | 04:01 | |
| jdstrand | stgraber: seems it is this: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1302264 | 04:05 |
| ubot2 | Launchpad bug 1302264 in systemd (Ubuntu) "systemd-logind assert failure: error.c:319: Assertion failed in nih_error_get: context_stack != NULL" [Medium,Confirmed] | 04:05 |
| jdstrand | stgraber: do you need more from me? | 04:06 |
| stgraber | jdstrand: I'll have a package up in a few minutes for testing (currently building) | 04:06 |
| jdstrand | ok | 04:07 |
| stgraber | jdstrand: https://dl.stgraber.org/bug1302264/ | 04:15 |
| stgraber | installed it here, restarted the service and things still work | 04:16 |
| jdstrand | ack | 04:16 |
| jdstrand | hrmm | 04:20 |
| jdstrand | I had a bunch of i386 packages installed cause of ubuntu-emulator | 04:22 |
| jdstrand | removing | 04:22 |
| stgraber | oh yeah, systemd tends to have pretty strict dependencies, that may be a problem. I noticed that above but since it takes me almost 10min to build that stuff (as it technically builds twice) I figured I'd just do amd64 | 04:23 |
| jdstrand | ok, it starts. let me restart my session | 04:24 |
| jdstrand | stgraber: ok, I removed myself fromthe video group, logged out, back in and still have 3D. /lib/systemd/systemd-logind is running | 04:27 |
| jdstrand | I didn't reboot | 04:28 |
| stgraber | jdstrand: cool, loginctl shows your session and /var/log/upstart/systemd-logind.log doesn't show anything scary? | 04:28 |
| jdstrand | $ loginctl | 04:28 |
| jdstrand | SESSION UID USER SEAT | 04:28 |
| jdstrand | c3 1000 jamie seat0 | 04:28 |
| jdstrand | 1 sessions listed. | 04:28 |
| jdstrand | /var/log/upstart/systemd-logind.log is still scary, but it was last changed 30 minutes ago | 04:29 |
| stgraber | ok good | 04:29 |
| jdstrand | so no new scary | 04:29 |
| stgraber | uploaded | 04:29 |
| jdstrand | thanks | 04:29 |
| stgraber | slangasek: if you're still around, it'd be great if you could quickly review that systemd upload. | 04:30 |
| jdstrand | infinity: was there anything you needed for the apparmor ffe? | 04:32 |
| stgraber | slangasek, infinity, ScottK (or anyone else from the release team waking up early): can you accept systemd ASAP, without that 3 lines fix, it's pretty much crashing for everyone, causing quite a few weird problems... | 04:37 |
| jdstrand | erf | 04:38 |
| jdstrand | who uploaded libvirt-bin? | 04:38 |
| stgraber | hallyn | 04:38 |
| jdstrand | happyaron: I thought you said you didn't have a pending upload? | 04:39 |
| jdstrand | happyaron: sorry, nm | 04:39 |
| jdstrand | can you not accept libvirt until I talk to hallyn? | 04:42 |
| stgraber | I rejected it | 04:42 |
| jdstrand | thanks | 04:43 |
| stgraber | infinity, slangasek (as you are the usual qemu suspects): per #ubuntu-devel, I've rejected both libvirt and qemu from the queue due to timing problem with jdstrand's apparmor stuff. Those uploads are probably fine (didn't review them) but should land after apparmor, so just rejecting them so they don't get accepted by mistake. | 04:54 |
| stgraber | I suspect qemu is a pretty massive diff, so you may want to pre-review that from rejected so that it's already ready to get accepted whenever the apparmor stuff is dealt with. | 04:54 |
| jdstrand | infinity: ok, everything is retested with the ppa packages for desktop/server. I will be back online in <7 hours | 05:10 |
| slangasek | stgraber, jdstrand: here now, and reviewing | 05:12 |
| jdstrand | slangasek: oh, are you reviewing the apparmor stuff? | 05:14 |
| slangasek | jdstrand: no, I'm reviewing systemd | 05:14 |
| jdstrand | ah, ok | 05:14 |
| jdstrand | that's fine. infinity has a handle on it | 05:14 |
| stgraber | slangasek: thanks! | 05:14 |
| stgraber | hopefully not too many people updated to the broken one and those who did will get the update quickly... | 05:15 |
| * stgraber really heads to bed now... | 05:15 | |
| slangasek | stgraber: why is the qemu upload rejected in connection with libvirt? | 05:16 |
| jdstrand | slangasek: cause of me | 05:16 |
| slangasek | stgraber: g'night :) | 05:16 |
| slangasek | jdstrand: you mentioned libvirt, but I don't understand why this led to the qemu reject | 05:17 |
| slangasek | ah, but I see scrollback on #ubuntu-devel now | 05:17 |
| slangasek | ... which is where stgraber told me to look | 05:17 |
| jdstrand | slangasek: libvirt needs to be uploaded with apparmor changes, and libvirt needs to be uploaded to support the new qemu | 05:17 |
| jdstrand | we attempted coordination earlier, but it didn't work perfectly | 05:18 |
| slangasek | right, so | 05:18 |
| jdstrand | I was attempting to not invalidate my testing | 05:18 |
| slangasek | you said infinity had a handle on the apparmor review, but maybe it would be useful to get this done sooner rather than later? | 05:18 |
| jdstrand | I'm ready for it now. jjohansen is available for questions on the patches if you have any | 05:19 |
| jdstrand | I don't care who does it, I had just been working iwth infinity on it | 05:19 |
| slangasek | ok | 05:20 |
| slangasek | so what does this "fix committed" here mean? | 05:20 |
| jdstrand | it is in the security-proposed ppa | 05:20 |
| slangasek | (FFe == process bug, should be left as 'new' until it's approved) | 05:20 |
| jdstrand | ok, sorry | 05:21 |
| slangasek | so has any of this been acked by infinity so far? | 05:21 |
| jdstrand | linux is the only one that is approved and it is in the archive | 05:21 |
| slangasek | ok | 05:21 |
| jdstrand | the others got a 'conceptual ack', meaning I told him what was coming and asked if it would be rejected outright. that answer was 'no' | 05:22 |
| slangasek | is there an order in which I should be looking at these? | 05:22 |
| jdstrand | but the actual review hasn't happened | 05:22 |
| slangasek | (e.g., libvirt first?) | 05:22 |
| jdstrand | slangasek: apparmor first. the others are only minor policy updates | 05:22 |
| slangasek | ok | 05:22 |
| slangasek | ftr I expect to turn into a pumpkin before too long here; probably won't make it to any of the other package reviews beyond apparmor itself | 05:26 |
| jdstrand | slangasek: I don't think the others need an FFe. there are no code changes and the only updates are policy changes to work with the new userspace. they just need to happen at the same time | 05:28 |
| jdstrand | slangasek: they are tested to work with and without a kernel that support signal/ptrace mediation | 05:28 |
| jdstrand | slangasek: libvirt could possibly be seen as FFe-worthy. regardless, those debdiffs are tiny | 05:29 |
| slangasek | jdstrand: to be clear, "need to happen at the same time" means they're broken if the new apparmor goes in without them, or not? | 05:29 |
| jdstrand | slangasek: they are broken if apparmor goes before or after | 05:29 |
| jdstrand | slangasek: they are in the ppa so they can be copied together | 05:30 |
| slangasek | jdstrand: so what enforces that the packages are upgraded at the same time? the apparmor debdiff doesn't include any breaks/replaces | 05:30 |
| slangasek | jdstrand: this should be enforced at the packaging level, not just the archive level | 05:30 |
| slangasek | (indeed, copying them together to trusty-proposed doesn't ensure they'll arrive in trusty at the same time, even) | 05:30 |
| jdstrand | we haven't typically done that in the past | 05:30 |
| jdstrand | there is a Depends in apparmor-easyprof-ubuntu | 05:31 |
| slangasek | well, I consider that a historical bug that we have an opportunity to correct ;) | 05:31 |
| slangasek | if the new apparmor breaks the old policies, versioned Breaks: is warranted | 05:31 |
| jdstrand | but libvirt only has Suggests and lightdm doesn't mention apparmor at all | 05:31 |
| jdstrand | I can correct it. that will set testing back about 6 hours | 05:32 |
| slangasek | right, so it's fine to omit any versioned depends, but if the new apparmor + old policy is broken, that's a poster child for apparmor declaring a Breaks on the old policy-providing packages | 05:32 |
| slangasek | really? why so much? | 05:33 |
| jdstrand | have you seen our TestPlan? it is extensive | 05:33 |
| slangasek | this is a minor change to debian/control, surely it doesn't require a full retest | 05:33 |
| jdstrand | well, I can only do upgrade testing | 05:33 |
| jdstrand | and smoke | 05:33 |
| slangasek | which is more than sufficient, for a one-line change to the package metadata | 05:34 |
| * jdstrand prepares the package | 05:36 | |
| jdstrand | slangasek: actually, to be clear, the old policy is still valid policy, it just isn't sufficient for functionality of the package | 05:39 |
| slangasek | jdstrand: so the package will fail to work because apparmor blocks it from doing things it needs to do, no? | 05:40 |
| jdstrand | yes-- it wasn't an argument against the Breaks, it was a clarification | 05:40 |
| slangasek | ok | 05:40 |
| jdstrand | this is what I have: | 05:41 |
| jdstrand | Package: apparmor | 05:41 |
| jdstrand | ... | 05:41 |
| jdstrand | Breaks: ..., libvirt-bin (<< 1.2.2-0ubuntu9~), lightdm (<< 1.9.14-0ubuntu2~), lxc (<< 1.0.2-0ubuntu2~) | 05:41 |
| jdstrand | those are the versions in the ppa | 05:41 |
| slangasek | yes, LGTM | 05:41 |
| jdstrand | k. I left out apparmor-easyprof-ubuntu since it already dealt with it in its Depends | 05:42 |
| slangasek | technically the depends and breaks are complementary, and both should be versioned | 05:43 |
| jdstrand | alright, I added it. apparmor-easyprof-ubuntu is much less of a concern since it is touch and the touch kernels don't have signal/ptrace yet (they will soon) | 05:45 |
| slangasek | ok | 05:47 |
| slangasek | jdstrand: otherwise, I don't see any issues (not that I'd be likely to catch anything in looking at this diff that you guys didn't find already) | 05:54 |
| jdstrand | slangasek: cool. it has received extensive testing, has been running on several systems and peer review. we feel confident in the changes (otherwise we wouldn't be asking for it) | 05:55 |
| jdstrand | s/and peer/and received a lot of peer/ | 05:56 |
| jdstrand | and of course, you know where to find us :) | 05:56 |
| slangasek | yeah, but for the next 8 hours where you'll find /me/ is asleep, so it'll be somebody else's problem to deal with the breakage ;) | 05:57 |
| jdstrand | hehe | 05:58 |
| jdstrand | it was a royal you | 05:58 |
| jdstrand | slangasek: so, do you feel the non-apparmor packages need a review or am I ok to pursue the silo to land this? | 06:10 |
| jdstrand | slangasek: and huge thanks for the review :) | 06:10 |
| slangasek | jdstrand: "pursue the silo" - hasn't this been through the silo already? | 06:10 |
| slangasek | or were you waiting for FFe approval before pushing it there? | 06:11 |
| slangasek | jdstrand: if you say that the other packages don't break FF, I trust your judgement | 06:11 |
| jdstrand | slangasek: no. I know it is weird. we put in the ppa. we tested from the ppa. this affects touch so we need a silo for the landing. this will be a pocket copy without rebuild. then I can do the whole landing bit | 06:11 |
| slangasek | ok | 06:11 |
| jdstrand | slangasek: again, thanks a lot! | 06:12 |
| dholbach | hiya | 07:07 |
| dholbach | can somebody take a look at bug 1299015 please? | 07:07 |
| ubot2 | Launchpad bug 1299015 in Ubuntu "[needs-packaging] FFe: please package fluxbox-light-themes" [Wishlist,New] https://launchpad.net/bugs/1299015 | 07:07 |
| jdstrand | fyi, apparmor, lxc, libvirt, lightdm and apparmor-easyprof-ubuntu are all part of the approved apparmor ffe, are tested and made it through the landing silo | 07:21 |
| dholbach | jdstrand, up late? | 07:30 |
| jdstrand | heh, yes | 07:31 |
| jdstrand | but not for long | 07:31 |
| jdstrand | :) | 07:31 |
| dholbach | jdstrand, sleep tight! | 07:31 |
| * dholbach hugs jdstrand | 07:31 | |
| jdstrand | thanks! :) | 07:31 |
| * jdstrand hugs dholbach :) | 07:31 | |
| jdstrand | that's a nice way to end the day :) | 07:31 |
| jdstrand | g'night! | 07:32 |
| dholbach | :) | 07:33 |
| psivaa_ | infinity: cjwatson: d-i and archive kernel version mismatch is impacting precise d-i installs for a few days now. just if hasn't been noticed | 09:13 |
| === psivaa_ is now known as psivaa | ||
| xnox | slangasek: i didn't want to change default plymouth-label, as that does use dejavu as default/fallback font. I only changed the ubuntu theme. | 09:17 |
| xnox | slangasek: no-print-empty-description - is not suppose to print anything, to hide e.g. "startpar bridge starting/stopping" messages | 09:18 |
| xnox | slangasek: the job names however are substitueted if description is empty.... can't remember if that's in upstart or plymouth, and if that ends up in details/text mode or not. | 09:20 |
| xnox | slangasek: yeah, i didn't see a way to accept variables from script plugin, hence statically generated x2 theme. When we discussed high-dpi for 14.04 bregma suggested that having x1 and x2 fonts/themes would be more than sufficient to handle current dpi ratios. | 09:21 |
| infinity | psivaa: That would be because someone updated d-i and not the seeds. Will fix. | 09:50 |
| psivaa | infinity: ack, thank you | 09:58 |
| infinity | psivaa: Fixed in bzr, next builds should be happier. | 09:58 |
| psivaa | infinity: ack, thx | 10:05 |
| === doko_ is now known as doko | ||
| cjwatson | Laney: FWIW bug 1290997 can't possibly *just* have been from url-dispatcher, as the url-dispatcher hook wasn't added until well after that original report. So maybe that needs another task | 10:10 |
| ubot2 | Launchpad bug 1290997 in url-dispatcher (Ubuntu) "click crashed with gi._glib.GError in run(): Child process exited with code 139" [High,Triaged] https://launchpad.net/bugs/1290997 | 10:10 |
| Laney | cjwatson: Fair enough. All 3 of the duplicates have the url-dispatcher error in them though, so I guess wait and see if any more turn up | 10:14 |
| Laney | Unless you noticed anything different on errors? | 10:14 |
| cjwatson | not particularly, just saying the original clearly wasn't that :) | 10:18 |
| cjwatson | errors isn't very good at handling GErrors bridged over into python | 10:19 |
| doko | infinity, is there a reason why the arm64 buildds still run 3.8 kernels? | 10:21 |
| infinity | doko: Because it's the most stable kernel we've had for ages. I plan to do some testing of the 3.13 distro kernel soon and see if it's good enough for the buildds, but that's a pretty recent development. | 10:25 |
| infinity | doko: Is this causing you any actual issues, or just curious? | 10:25 |
| doko | infinity, yes, GCC testsuite hangs the machine, but works locally with a 3.13 kernel | 10:28 |
| infinity | doko: Which machine did you hang? :P | 10:29 |
| doko | it is disabled now so you won't see it | 10:29 |
| infinity | doko: When is the last time you hung a machine? | 10:30 |
| infinity | doko: I twiddled some things long ago in response to a report from mwhudson about some issues on 3.8... | 10:30 |
| doko | well, I'll enable it again | 10:30 |
| infinity | doko: If it kills a machine, consider that my problem, and I'll sort it out. | 10:31 |
| infinity | (I need to test the distro kernel anyway) | 10:31 |
| xnox | http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu-touch.trusty/touch.sources lists firefox, yet i'm pretty sure firefox, nor any of its binaries are in the touch seed. Is that a bug/config error in germinate or src:firefox is somehow part of the touch seed? | 11:23 |
| infinity | xnox: language-packs. | 11:33 |
| jamespage | Daviey (or any other SRU team member): assuming the TB is OK with the approach I'm suggesting in bug 1262712 how would the SRU team like me to proceed? | 11:33 |
| ubot2 | Launchpad bug 1262712 in iscsitarget (Ubuntu Precise) "[SRU] Backport iscsitarget 1.4.20.3+svn499 into Precise" [High,Triaged] https://launchpad.net/bugs/1262712 | 11:33 |
| xnox | infinity: duh! | 11:33 |
| Daviey | jamespage: My understanding was that a oneoff update didn't require TB approval and could be handled at ~ubuntu-sru level. If there is desire to track versions onwards, then a formal MRE should be raised. | 12:10 |
| Daviey | jamespage: Either way, extended confidence needs to be achieved for something like this - especially the first time. There doesn't seem to be a well defined test path yet? | 12:11 |
| jamespage | Daviey, I can pull something together re testing | 13:05 |
| jamespage | Daviey, and I'd suggest an extended -proposed stay as well | 13:05 |
| jamespage | Daviey, hmm - now you have me thinking "If there is desire to track versions onwards" | 13:06 |
| jamespage | not for 12.04 but I can see the same thing happening for 14.04 over the next two years | 13:06 |
| jamespage | Daviey, any chance you could accept the swift rc1 upload into trusty please? | 13:32 |
| jamespage | its the laggart of the openstack family this milestone | 13:32 |
| Daviey | jameapage, done | 13:38 |
| jamespage | Daviey, ta | 13:43 |
| === Ursinha-afk is now known as Ursinha | ||
| slangasek | xnox: right, FWIW I think we should just switch to the ubuntu font everywhere and not worry about the plymouth-label fallback. btw, I didn't notice any changes to the initramfs hook to pull the ubuntu font in for that case? | 14:55 |
| === Ursinha is now known as Ursinha-afk | ||
| === brendand_ is now known as brendand | ||
| === Ursinha-afk is now known as Ursinha | ||
| === bschaefer_ is now known as bschaefer | ||
| Laney | ^^^ I wanted to get that to build over the weekend (assuming it builds, haven't test built it to completion yet) but have also put a migration block in to do manual testing | 16:53 |
| === jackson is now known as Guest23530 | ||
| === Guest23530 is now known as Noskcaj_ | ||
| chrisccoulson | is there anyone who can approve that oxide upload ^^ ? | 18:55 |
| cyphermox | hi, can I get a FFE for https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch/+bug/1280546 ? I've just finished porting the changes in the versions leading to 2.1.1 to the rewrite patch we have | 20:00 |
| ubot2 | Launchpad bug 1280546 in usb-modeswitch (Ubuntu) "[FFe] merge usb-modeswitch 2.1.1+repack0-1 from Debian unstable" [Wishlist,In progress] | 20:00 |
| cyphermox | this should also unblock the current usb-modeswitch-data stuck in proposed for a while | 20:00 |
| cyphermox | ah, actually no it wouldn't, means we also need a new usb-modeswitch-data synced from unstable | 20:01 |
| robru | infinity, around? ubuntu-html5-theme and unity-settings-daemon seem to be stuck in proposed (3+ hours) but neither are mentioned in excuses. | 22:57 |
| infinity | robru: Looks like proposed-migration hasn't run for hours. Lemme see why. | 22:58 |
| robru | thanks | 22:59 |
| infinity | robru: laney was crashing it with a broken hint. Fixed. | 23:04 |
| robru | infinity, great, thanks! | 23:04 |
| infinity | robru: Looks happier now. | 23:20 |
| robru | infinity, I also look happier now. Thanks again! | 23:20 |
| Laney | oops | 23:30 |
| infinity | Laney: To be fair, britney's failure mode for poorly-formatted hints isn't exactly stellar. :P | 23:32 |
| infinity | (And maybe we should also spam a few people with annoying email when it exits non-zero) | 23:32 |
| Laney | I always forget that block doesn't take a version | 23:32 |
| Laney | but yeah, crashing is bad | 23:32 |
| infinity | Ow, wow. Spring came back while I slept earlier today. | 23:34 |
| infinity | From negative temperatures and snow to 13 above and sunny. | 23:34 |
| * infinity decides to go walk in the fresh air for a few minutes. | 23:34 | |
| stgraber | infinity: heh, I should look outside more often :) | 23:36 |
| stgraber | in my mind it was still cold and snowy out there, but google tells me it's 8C and rainy instead (not sure if that's an improvement though) | 23:37 |
| slangasek | we've had spring for a whole three days already | 23:42 |
| * slangasek taunts Canada | 23:42 | |
| infinity | slangasek: We had it a month ago, and then winter decided to make a comeback. | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!