=== Guest41065 is now known as StevenK [00:47] infinity: debian-experimental has 2.0-rc1. i'll do either -rc2 or final on monday, whatever is available. (hoping for final, but not optimistic) === maclin__ is now known as maclin === sz0` is now known as sz0 === sz0 is now known as sz0` === sz0` is now known as sz0 [05:04] Good morning [05:13] stgraber: for bug 1307008, i was wondering, should cgmanager/cgproxy stop on starting rcS, or on runlevel [06]? Or something later yet than rcS? Some services might want it around to shut down... [05:13] bug 1307008 in cgmanager (Ubuntu) "cgmanager doesn't stop on shutdown" [High,Confirmed] https://launchpad.net/bugs/1307008 [05:13] * hallyn leaves for the night on that note [06:27] pitti: I know you don't work on this anymore, in theory, but you seem like the sort of person who would know. [06:28] infinity: what's up? [06:28] pitti: Any idea who/what is responsible for brightness keys working these days, and why the ones on my Thinkpad might have suddenly stopped working in the last few days? [06:28] ... he says, testing and they now work... [06:28] WTF. :( [06:28] pitti: So, last night, brightness keys and (worse) lid-close didn't work. [06:29] pitti: Seems that after manually suspending, it's "fixed". That's not comforting. [06:29] infinity: in general, those are both (gnome|unity)-settings-daemon [06:30] infinity: for the brightness keys, X.org translates the evdev keys into XF* events, and (g|u)-s-d listens to them and calls xrandr to set the brightness [06:30] pitti: And lid close? [06:30] infinity: for suspend, -settings-daemon usually controls that as well; unless it's crashed, then logind takes over [06:30] i. e. logind usually listens to the power button and lid close, so that this stuff works on a VT or in the DM; but settings-daemon tells it not to, and listens to those events by itself [06:31] infinity: so it might be that settings-daemon has crashed for you, or got stuck somehow? [06:31] So, lid-close and brightness working (and not) definitely seem to be tied together here, so I guess I get to hunt down what was broken last night and magically fixed after a suspend/resume... [06:31] pitti: More disconcerting, it was after a fresh reboot, so it's not like I'd crashed g-s-d over weeks of hard use or something. [06:32] Oh well. Will experiment today, if I get a chance. [06:32] infinity: if you are able to reproduce the behaviour, the first interesting question is whether it starts working again after re-starting u-s-d [06:32] if so, we at least know the component (but then, harder to debug) [06:32] lid-close not working is one of my least favourite failure modes... So many burned out motherboards and burned-through LCD panels. :/ [06:32] if it still fails after restarting, then we can restart it in the foreground with debugging enabled and see what's going on [06:33] *ack* [06:33] I don't test it very often, only when I'm travelling or working elsewhere [06:33] but I had zero problems with it during last weeks' sprint or in Oakland in March, etc. [06:33] infinity: the main big change that landed fairly recently is that logind now uses cgmanager for cgroup management [06:34] pitti: Yeah, it's been working for me non-stop for a long time, until just last night. So, colour me confused. [06:34] I'll see if I can reproduce or if it was a one-off. [06:34] infinity: that has caused a few crashes, hangs, and high CPU usage before it stabilized [06:34] Not that the latter is any more reassuring, but... Meh. [06:34] otherwise I'm not aware of big changes in the stack; I haven't followed the ubuntu-settings-daemon story, though [06:35] infinity: err, unity-settings-daemon [06:37] infinity: hm, I don't see something obvious at https://launchpad.net/ubuntu/+source/unity-settings-daemon/+changelog which could be the cause [06:38] pitti: My unity-settings-daemon also seems to be the same age as the rest of my session (ie: no indication that it crashed and restarted) [06:38] pitti: So, why I had to manually suspend last night, and it works this morning (under the same session) is a wonderful mystery. [06:40] infinity: indeed; it's not like suspend ought to magically restart services or so [06:40] * infinity needs to eat before caring more about this. [06:41] pitti: Well, suspend invokes gnome-screensaver and other things, so could accidentally trigger restarting problematic helper services. [06:41] pitti: But I don't see any evidence of that at first glance. PIDs all look to be from yesterday. [06:58] good morning [07:05] hey dholbach, wie gehts? [07:06] hey pitti - sehr gut - und dir? [07:06] pitti, HAPPY BIRTHDAY! :) [07:06] dholbach: prima, danke! [07:06] dholbach: yay, thanks! [07:06] * pitti is munching a wonderful rhubarb cake that my wife made me *yummy* [07:18] pitti: good morning! I got a bugreport that gdebi has no translations in 14.04, is it possible that they are still stripped out even though they are no longer part of the language pack? [07:19] mvo: hm, that's a bit odd; the source is in main, the binaries are in universe; I need to check more closely [07:20] pitti: gdebi-core is a dependency of packagekit (aptcc) iirc [07:37] mvo: indeed, no trace of gdebi in the current LP export; I wouldn't know why that is [07:38] pitti: oh, so its supposed to be there but it is not? should I file a bug? aganst LP ? [07:38] so https://launchpadlibrarian.net/172212731/buildlog_ubuntu-trusty-i386.gdebi_0.9.5.3_UPLOADING.txt.gz does build a translation tarball [07:38] 328949 bytes, so it's not empty or so [07:39] mvo: but https://translations.launchpad.net/ubuntu/trusty/+source/gdebi is empty [07:39] mvo: it's odd that this never got imported -- it's an old package; or did you just recently add i18n? [07:39] pitti: it has i18n since ~2005 or so :) [07:39] mvo: so someone with the necessary privs (dpm, wgrant?) needs to do some clickery on https://translations.launchpad.net/ubuntu/trusty/+source/gdebi/+imports [07:39] pitti: but it recently got moved some main to universe or something [07:40] pitti: oh, so that is whats missing? a approval? [07:40] yeah; but I can't do that [07:43] pitti: ok, thanks a lot for finding the root cause - I guess its too late for -final, but we can get updates in the first update? [07:44] mvo: yes, indeed; they'll show up in the autogenerated update packs in teh langpack PPA too, and I expect we'll do an "official" update for .1 at the latest (maybe before if there's enough interest in testing them) [07:46] pitti, mvo: good morning :-) [07:46] hey zyga === maclin_ is now known as maclin === pedronis_ is now known as pedronis [08:02] mvo: hey, it's somewhat a sad story, ever since you left I let c-n-f bitrot as I didn't know how to upload it nor wanted to maintain @home infrastructure to scan the archive all the time [08:02] mvo: but with some new debian proposals (not debtags, the other thing) it might be possible to rewrite c-n-f to be 100% accurate by 14.10 [08:03] mvo: could you help me througout the cycle to understand how to be able to upload a package to ubuntu? [08:03] zyga: no worries - the important one we need to solve is commands that get generated via update-alternatives in the postinst, if that could be marked via some meta-data we should be good [08:03] mvo: (or alternatively, cnf could move to debian, which I already know how to work with) [08:04] mvo: right, and exactly that meta-data can now be expressed and will be processed by the archive system (so the user needs to download one per-archive file and it's good to go) [08:04] * zyga googles for that DEP [08:05] zyga: yeah, totally. I scriped it on one of the ubuntu servers now (the data extraction) and we should simply make this a proper public service - unless we can simply use this DEP which would just be perfect :) [08:05] Can i merge (or SRU) ball, since it will fix the ftbfs [08:07] mvo: DEP-11 [08:07] mvo: https://wiki.debian.org/DEP-11 [08:08] mvo: 'Type-Name: exec', packages could then have meta-data like exec, exec, ec [08:08] mvo: I think that a hybrid approach would be best, for packages that have DEP-11 annotation it takes over entirely (for the source whole package), otherwise the guesstractor is used as today [08:10] zyga: yeah [08:10] mvo: if you look at "Location in the Archive" part you will see a standardized location where compressed component (e.g. exec) indices are to be made available [08:34] infinity: hey can I pull the fix for https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1306897 into the mesa package too? [08:34] Launchpad bug 1306897 in mesa (Ubuntu) "xbmc with vdpau crashes on stop" [Undecided,Confirmed] [08:36] mlankhorst: Is it reviewed/committed upstream, or just a random patch floating on a mailing list? [08:36] xnox: https://pastebin.canonical.com/108412/ [08:40] it's committed upstream [08:41] and cc'd stable [08:41] mlankhorst: Shiny. [08:42] mlankhorst: In thta case, go for it. Be quick like a bunny. [08:42] already copied to the 10.1 branch it seems [08:42] http://cgit.freedesktop.org/mesa/mesa/commit/?h=10.1&id=48fe4c80b356c9d3ca77ec170414ee8df80e6f60 [08:48] do we have anyone looking to libav issues in Ubuntu? [08:49] siretart? [08:49] bug #1288206 could do with somebody looking at it [08:49] bug 1288206 in libav (Ubuntu) "vlc crashed with SIGSEGV in memcpy()" [High,Confirmed] https://launchpad.net/bugs/1288206 [08:49] the Debian bug is closed saying it's a libav issue happening with libav9 only (and not 8 or 10) [08:49] siretart, ^ is there any chance you could look if there is a bugfix we can backport there? [08:49] that's one of the most reported issues on e.u.c [08:50] Weird, I never see that. I must be lucky. [08:50] I'm okay with being lucky for once. [08:52] infinity, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741240#40 [08:52] Debian bug 741240 in libavcodec54 "vlc segfaults while playing MKV files" [Important,Open] [08:52] infinity, you maybe use that option? [08:52] infinity, or maybe you don't play mkv files (those seem to be the ones hitting the bug (or most often doing at least) [08:55] seb128: Well, I don't use vlc, but I do use libav... [08:56] oh ok [08:56] well maybe you don't exerce the codepaths in it that have that issue [09:10] mlankhorst: No mesa for me? [09:10] hi, which package is responsible for bringing up the network on boot? [09:14] bdrung_work: ifupdown (for /etc/network/interfaces), and NetworkManager for everything else [09:14] it's a server, so no network-manager [09:15] ifupdown then [09:15] pitti, on a new install, i get 'waiting up to 60 more seconds for network configuration' message from plymouth [09:16] i get the same message on an old install, but it just continues to boot [09:16] (both 12.04 systems) [09:16] well, everything which triggers on net-device-up or similar won't start; everything which doesn't need network should start [09:17] /etc/network/interfaces have the same content and both system have one network device [09:17] that is, if your /e/n/i defines an interface which doesn't come up (not connected or so) [09:18] one devices comes up, but not additionally defined ones [09:19] on the old install, the boot continues (including showing the tty for log in), but not on a new installation [09:20] but maybe the real problem is that auto-hotplug does not work at all (neither on 12.04, 13.10, nor 14.04) [09:22] ups, i meant allow-hotplug [09:28] yes, /etc/init.d/networking seems to handle this, but not our upstart jobs [09:28] but this should only do additional things, so that still doesn't explain the hang [09:28] ifup -a ought to ignore these [09:30] infinity: hm tjaalton did an upload I think, I'll wait with the fix for 10.1.1 sru :P [09:31] I didn't upload this patch [09:33] pitti: are dbgsym for http://kernel.ubuntu.com/~kernel-ppa/mainline/ ? [09:33] kdeuser56_: apparently not [09:34] pitti: why do some dbgsym depend on dbg? [09:34] the kernel source itself should build these, but apparently not for the mainline ones [09:34] kdeuser56_: for those src packages which already build a -dbg we just generate empty -dbgsym packages that depend on these, to avoid duplicating the symbols [09:35] pitti: thats pretty bad in some cases as some -dbg install unnecessary packages ... [09:35] kdeuser56_: i. e. we only really build -dbgsyms for sources which don't have a -dbg, but for getting one consistent workflow folks asked for these empty "pointer" -dbgsyms [09:35] if these deps are required for debugging, it seems fine; if they are unnecessary, that shoudl be fixed of course [09:36] we don't really notice, as it's certainly not recommended to install many -dbgsym on a "real" system [09:36] pitti: so generally I could simply install -dbgsym as they will install dbg anyway [09:36] mlankhorst: If you'd prefer to wait for an SRU, that works for me. [09:38] pitti: muon-dbg and muon-dbgsym should conflict right? [09:38] kdeuser56_: not "Conflicts:" in the dpkg sense; myon-dbgsym should just Depends: muon-dbg and otherwise be empty [09:38] (except changelog etc.) [09:39] pitti: ah then the wiki should be updated as it says dbg and dbgsym cannot be installed at the same time [09:40] infinity: yeah should be ok, no need to push it 3 days before a release :P [09:41] pitti: which is what it used to be right? [09:41] kdeuser56_: yes, indeed; that got changed perhaps a year or so ago [09:42] pitti: libmagickcore5-extra-dbgsym installs imagemagick-dbg which installs imagemagick which I do not want to be installed, as I only need the library. [09:43] pitti: if dbgsym would be as they used to be in the old times it would work much better in many cases [09:43] pitti, Debian does this in their init script: "if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose" [09:43] pitti: or for example: plasma-dataengines-addons-dbgsym installs "plasma-runners-addons plasma-wallpapers-addons plasma-widget-lancelot kde-wallpapers" [09:43] bdrung_work: right, that led me to believe that ifup -a should ignore the auto-hotplug ones [09:44] pitti, where is ifup -a called? [09:45] bdrung_work: in /etc/init/networking.conf [09:45] pitti: kde-wallpapers are just wallpapers, they are not needed for debugging ... if dbgsym would be generated independently from dbg those issues would not arise [09:46] kdeuser56_: yes, I know; that's what we did in the past, but they take an awful lot of space, so this was a way to reduce that quite a bit [09:46] pitti: why not going away from -dbg and only create automatic dbgsym? [09:47] kdeuser56_: that's a good plan, but as long as we inherit all those -dbg from Debian we need to deal with them [09:47] pitti: why is it difficult to not inherit the -dbg packages? [09:47] pitti, yes, the hotplugged ones probably should come up when they are plugged in [09:48] but they do not [09:48] /etc/init/network-interface.conf does not bring them up [09:48] kdeuser56_: we could probably mangle our dpkg tools to ignore them unless they are python-* ones or so, but that'd be quite an ugly hack; it hasn't really been discussed so far === vrruiz_ is now known as rvr [09:49] pitti: but the current situation is not pretty either if you ask me [09:50] kdeuser56_: certainly not pretty, but good enough; at least nobody has complained in a long time :) [09:50] pitti: dbg often contain stuff not needed to debug only the package you installed the dbgsym of [09:50] apport-retrace surely unpacks more stuff than it needs to into its sandboxes [09:51] pitti: and the dbg packages pull in so much unencessary stuff [09:51] the wallpaper one is really more like the exception; most -dbg packages are just fine [09:51] of course many/all pull in the corresponding application, but that's fine [09:52] pitti: not if you only need a tiny library and it pulls in big programmes [09:53] pitti: call me crazy but I installed dbgsym for all installed packages and encountered many packages which were installed despite being not needed for debugging [09:53] pitti: I know its NOT recommended :-) [09:53] heh yes, they are certainly not designed with that in mind [09:54] pitti: okay lets keep it short: do you think something will change with that in the near future? === sz0 is now known as sz0` [09:55] kdeuser56_: I doubt it TBH; if we'll change it in any way, then probably by going the full route to build IDs and stop having -dbg or -dbgsym packages altogether [09:55] but that's quite a lot of work, and for relatively little gain, so someone who wants to do it and has time for it needs to pick that up [09:55] (i. e. I probably won't soon) === tkamppeter__ is now known as tkamppeter [09:57] pitti: thanks for your support! [09:57] pitti: btw: you said if someone wants to work on it: is there really opportunity for a non-canonical employee to change something in this regard? [09:59] it doesn't need anything canonical specific (except for putting into production and running it on ddebs.u.c.) [10:00] but designing and implementing a new system doesn't need any particular privileges === sz0` is now known as sz0 [10:25] pitti: https://bugs.launchpad.net/software-properties/+bug/1307170 look at #7-#10 despite having all dbgsym of all packages installed gdb reports missing info [10:25] Launchpad bug 1307170 in Software Properties "/usr/bin/software-properties-kde crashed when triggering mirror selection and clicking ok quickly" [Undecided,New] [10:25] pitti: any idea how this can be? [10:26] kdeuser56_: python*-dbg are special; I think you need to run them with the corresponding e. g. python3.4-dbg interpreter to make full use of them [10:26] python-*-dbg isn't just gdb debug symbols, it's also extensions built in a "debug way" (I don't know the details) === sz0 is now known as sz0` [10:31] chrisccoulson: can you upload the patch mentioned in bug 1294666 [10:31] bug 1294666 in xserver-xorg-video-intel (Ubuntu) "[HSW mesa kde needs Xorg-1.15.1] Multiple tiling-esque artifacts in KDE" [High,Fix committed] https://launchpad.net/bugs/1294666 [10:31] i.e. patch the package and upload it [10:32] pitti: I have installed all dbg packages too [10:32] I most certainly don't have upload rights for xserver-xorg-video-intel :P [10:33] pitti: it did not change anything ... right now the siutation looks like this: of all packages name-dbg is installed and name-dbgsym is installed [10:35] pitti: in theory that should be enough right? [10:35] kdeuser56_: yes; however, that's just a theory; I still often see situations where gdb isn't able to figure out symbols for everything [10:36] it's the nature of crashes -- corrupted/invalid pointers, corrupted stack, etc. [10:36] or, more importantly, optimization [10:36] pitti: this crash can be reproduced every time [10:36] pitti: *almost [10:39] oh [10:39] chrisccoulson: sorry, wrong ping :( [10:40] I dealt with a crash just on Friday that was reproducible every time but resulted in a consistently corrupted stack. It happens. [10:41] Corrupted-stack isn't necessarily an unreliable symptom. [10:42] oh okay [10:42] thanks very much for your great support! [10:55] pitti, i filed bug #1307429 [10:55] bug 1307429 in ifupdown (Ubuntu) "Existing allow-hotplug devices do not come up" [Undecided,New] https://launchpad.net/bugs/1307429 [11:05] cjwatson: could you take a look at bug 1306877 please? [11:05] bug 1306877 in openssh (Ubuntu) "sshd stops accepting new connections after configuration reload" [Critical,Triaged] https://launchpad.net/bugs/1306877 [11:05] It seems to me that this should be a regular pattern for "expect stop" if this is what upstart expects. [11:05] (I've attached a patch) [11:06] Thanks, I'll look shortly [11:17] rbasak: looks good thanks, building a Debian upload [11:21] Hi! whenever I login I see apport crash window on my screen, why don't we disable that for the release ? === jamesh_ is now known as jamesh [11:25] om26er_: it seems we want crash reports for stables to go to errors.ubuntu.com [11:25] om26er_: so we only disable submission to LP, not to errors [11:26] pitti, I see a stack of atleast 3 apport windows one above the other every boot, I have cleared /var/crash and now rebooting to report bugs from the new crashers [11:26] brb [11:27] I though we had put code in place to avoid greeting users at login with apport prompts [11:27] * seb128 looks through apport changelog entries, not sure I remember correctly [11:28] we should do that if we didn't ;-) [11:28] we actually do [11:29] seb128: well, we have code to suppress crashes which happen at session logout and from previous sessions [11:29] it could still be that stuff actually crashes during login [11:30] pitti, I wonder if not prompting for " minutes" after login would helps in the user perception [11:30] pitti, I find it myself annoying to have prompt open on screen before unity is ever loaded [11:31] it's like first thing you see in those case is a system error dialog [11:31] pitti seb128 , interestingly now that I cleared /var/crash the dialog never appeared, I have been seeing that dialog for a long time on every boot [11:31] yeah, indeed; I haven't had these in a long time, so didn't notice either [11:31] and would always cancel it [11:31] om26er, that's because you always cancel that they never cleared [11:32] om26er, if you had reported them they would have been flagged as handled and it would have stopped nagging you [11:33] seb128, as a user I would expect it to not keep bugging me till I report it, i'll report a bug for that. [11:34] I would be surprised if there were not reports about that already === maclin__ is now known as maclin === MacSlow is now known as MacSlow|lunch === psivaa is now known as psivaa-lunch === _salem is now known as salem_ [12:16] could somebody build retry https://launchpad.net/~ci-train-ppa-service/+archive/landing-008/+build/5908000 [12:16] ? [12:18] seb128: done [12:18] cjwatson, thanks === MacSlow|lunch is now known as MacSlow === roadmr_afk is now known as roadmr [13:07] hallyn: "stop on runlevel [06]" should do it I guess === psivaa-lunch is now known as psivaa [14:00] stgraber: so long as noone puts cgm commands in post-stop jobs [14:01] jodh: ^ you haven't suggested that anywhere? [14:02] hallyn: missing context - irlogs is 3 hours out of date :) [14:02] hallyn: *irclogs [14:04] jodh: cgmanager currently doesn't have a stop on stanza [14:04] jodh: we need one but we're not sure what's appropriate as anything can use cgmanager... [14:06] jodh: we need to have it happen after lxc and systemd-logind are done but before we reach the umount [14:12] infinity: ok i guess we expect 2.0.0-rc3 today, but not a -final. [14:12] xnox, cjwatson Just to check, do you know about "error: diskfilter writes are not supported"? I am getting that message after a 64bit server install from this mornings iso. Although it says enter to continue it seems to proceed without that and boot seems to go on ok. [14:15] smb: Yes, that happens if your /boot is on something GRUB can't write to directly, like LVM or RAID. Well-known. [14:15] smb: As for the message glitch, see https://lists.gnu.org/archive/html/grub-devel/2014-04/msg00028.html and thread. [14:16] cjwatson, Ok, so lvm in my case. Hm, thought I had that setup before... [14:19] Oh, actually no... for those I end up using bad blocklists but real (extended) partitions. So it would not happen there === tyhicks` is now known as tyhicks [14:32] hallyn: Alright, then probably not rush to try to shove something in pre-release. [14:32] infinity: 2.0 *should* be this week, [14:32] so i'll push that for a 0-day sru? [14:33] hallyn: Right, and as much as I'd love that in release, if 2.0 doesn't get in the release pocket, I don't care which RC is there. :P [14:33] ok [14:33] hallyn: I fully expect us to SRU to 2.0 final regardless. [14:40] infinity, So what do you think of Xen + arm64? Unfortunately my test compile seems to have hit something that broke the porter (do you want any of the pieces?) [14:40] smb: I'm not much interested in shedir being sad. As long as the arm64 build seemed okay. Maybe I should throw it at a devirt PPA quickly. [14:42] infinity, Would be ok with me. I think it should be ok in general, the arm64 was ok and the x86 compiles still seemed to be what I think they should. So it mostly should fly... [14:42] infinity, I put a debdiff there as well, so you can have a quick glance on what I did [14:43] ppisati, Do you want to check on that machine or shall I just ask it to be rebooted? [14:43] smb: do you have a stack trace? [14:44] ppisati, yes [14:55] mvo_: hey, if I declare in foo, Breaks: bar (<< 1.1), in a massive upgrade from say 12.04 to 14.04, can I expect that it is properly honored? there is some question about apt breaking things in to chunks such that it is possible that bar is upgraded and configured in an earlier chunk and foo in a later chunk [14:56] pitti, hey, happy birthday ! [14:56] mvo_: my interpretation of 7.3 of debian policy would suggest that if it did break things in to chunks as described, then that is a bug in apt [14:56] thanks ogra_! [14:56] pitti: happy birthday :) [14:57] jdstrand: cheers! [14:57] mvo_: specifically the case here is lxc and apparmor in trusty. The new apparmor defines a break on the old lxc, lxc itself currently doesn't version depend on apparmor (just plain depend). [14:57] Happy Birthday pitti! [14:58] mvo_: in my understanding, on complex upgrades, it's perfectly possible and allowed for apt to first upgrade lxc on its own in a first run, then upgrade apparmor on its own in the second as that'd respect the apparmor Breaks (new lxc is already there) and since lxc doesn't version-depend on apparmor, it'd be fine too [14:58] mvo_: (I have now uploaded lxc with a version dependency on the new apparmor to fix the problem but jdstrand isn't convinced this should be necessary) [14:59] actually, I'm not saying it isn't necessary-- it might be, I'm saying it shouldn't be necessary [15:00] ie, apt shoudl allow lxc and apparmor to upgrade in different chunks [15:00] err shouldn't* === WebbyIT is now known as rpadovani [15:03] jdstrand: I haven't looked at the exact dependency relations of lxc and apparmor, but what stgraber said is true, apt may break the upgrade into chunks that consist of valid dpkg states, so if the new foo breaks on a old bar, apt may upgrade bar first and then later upgrade foo [15:03] jdstrand: do you have a bug reference with the real world issue? [15:04] mvo_: bug 1307008 [15:04] bug 1307008 in cgmanager (Ubuntu) "cgmanager doesn't stop on shutdown" [High,Confirmed] https://launchpad.net/bugs/1307008 [15:04] oops, wrong one [15:04] one sec [15:04] mvo_: bug 1304167 [15:04] bug 1304167 in lxc (Ubuntu) "syntax error, trusty beta-2 cloud image" [High,Triaged] https://launchpad.net/bugs/1304167 [15:04] that one :) [15:05] mvo_: this one isn't a dist-upgrade but someone who apparently got an older image (beta2) ran an apt-get update and then installed lxc which broke [15:05] mvo_: it's while fixing this that I figured we may see it as well during lts to lts and mentioned this to jdstrand [15:06] stgraber: thanks! this looks indeed like lxc should have a version dependency on apparmor if it has a ruleset that uses new syntax [15:09] jdstrand: so lxc is fixed (in the queue), hallyn is looking at libvirt now (which also calls the parser from postinst), it looks like lightdm may need fixing too and I don't know about easyprof. Can you take care of those last two? [15:10] if they do have the same, calling the parser from postinst problem that is [15:13] sigh [15:13] I specifically asked about this before and was told the Breaks was enough [15:14] mvo_: surely the intent of the Breaks is for it to work in more than just small upgrades? [15:15] mvo_: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-breaks doesn't say anything about chunks, etc. I realize one could argue that apt is doing things ok because each chunk is consistent with itself, but taken as a whole, they are not [15:19] I'm compiling a package used in xubuntu but I keep running into missing dependencies. Is there a collection package of the most common source packages for xubuntu/xfce? [15:24] jdstrand: The behaviour you're describing is precisely aligned with my expectations of Breaks [15:24] jdstrand: sorry for your frustration, but this is version depends is needed for correctness anyway. if e.g. old apparmor is installed and the user only runs apt-get install lxc the postinst will also break because apt does not know that the new lxc also requires it to upgrade apparmor. all it knows is that the new apparmor will break on older lxc [15:26] jdstrand: All that foo Breaks: bar (<< 1.1) says is that (foo unpacked) and (bar << 1.1 in a configured state) can't coexist [15:28] jtaylor: Why did you sync the lz4 from Debian with the SOVER bump? === chuck_ is now known as zul [15:57] fyi, apparmor-easyprof-ubuntu already has that Depends [16:01] stgraber, i responded to bug #1307429 [16:01] bug 1307429 in ifupdown (Ubuntu) "Existing allow-hotplug devices do not come up" [Wishlist,Triaged] https://launchpad.net/bugs/1307429 [16:02] bdrung_work: indeed you're right, though it's been that way for over 3 years now, so not in need of an urgent fix [16:03] stgraber, no urgent pre-release fix, but i like to get it fixed in a SRU [16:03] bdrung_work: ok, I'll get that fixed in 13.10 then we can sru [16:03] stgraber, the proposed fix is derived from the Debian init script behavior [16:04] stgraber, 13.10 or did you mean 14.10? [16:08] cjwatson: ping [16:08] hi [16:09] cjwatson: I was looking at bug 1182784 , and noticed that /usr/lib/ubiquity/console-setup/kbdnames.gz has both "Switzerland" and "Switserland" [16:09] bug 1182784 in ubiquity (Ubuntu) "Install with German / Swiss Keyboard fails: "ubi-console-setup failed with exit code 141" or "Installer Crashed"" [High,Confirmed] https://launchpad.net/bugs/1182784 [16:09] is that intended? [16:10] cjwatson: http://paste.ubuntu.com/7250441/ [16:11] shadeslayer: that looks like a translation [16:12] oh hm [16:12] shadeslayer: specifically to af == Afrikaans [16:12] cjwatson: thx === bfiller is now known as bfiller_afk [16:15] cjwatson: this is what I see in the debuglog http://paste.ubuntu.com/7250467/ [16:18] shadeslayer: I think those are meant to look up untranslated names, but I don't recall just now [16:18] ok [16:25] pitti: would you accept a patch to apport that would introduce a new config option to include the timestamp in the crash files? [16:35] bdrung_work: meant 14.10 :) [16:35] jdstrand: ok, so we need lightdm and libvirt then [16:36] stgraber, okay. i can do the upload myself. i just want someone to have a look at my patch before the upload. [16:36] jdstrand: actually, libvirt is in now, so just lightdm. I'll get that one done real quick. [16:36] stgraber: actually, lightdm doesn't run apparmor_parser in its postinst [16:37] which is probably a bug in and of itself, but it won't be affected by this [16:38] jdstrand: oh yeah indeed, I did a quick grep earlier but that was the freerdp plugin matching, not lightdm itself [16:39] jdstrand: so lightdm-remote-session-freerdp will call apparmor_parser from postinst against the lightdm-remote-session-freerdp profile which loads the lightdm abstraction which uses signal [16:39] jdstrand: however it does so using || true so it won't fail [16:41] infinity: see the ffe, I'll do the redep today [16:42] jtaylor: We're already doing it for you. [16:42] jtaylor: Because $reasons. [16:42] jtaylor: So don't worry about it. [16:42] I want a bugfix release in so I will worry [16:44] I know its kind of late, but the impact on the archive is small, universe unseeded very few rdeps [16:45] jtaylor: I meant don't worry about doing the transition cause we're on it. [16:46] its a one package transition [16:46] or did I overlook something? [16:53] jtaylor: Yeah, it is. [16:53] jtaylor: But we're on it, because we were fixing the ppc64el ftbfs. [16:54] jtaylor: Unless you had a pytables upload to do while you're at it? [16:54] of pytables? [16:54] I wanted to upload pytables within a few hours [16:54] but I'm not fixing ppc64 [16:54] jtaylor: Like, a new version you mean? [16:54] jtaylor: Or just a rebuild? [16:54] yes 3.1.1 [16:55] Ahh, upload away. [16:55] jtaylor: The ppc64el FTBFS is fixed via wgrant's earlier lz4 upload. [16:55] jtaylor: So, yeah, do your thing. [16:55] oh nice [16:56] could we retry pytables now in advance of that upload then? [16:57] It should work [16:57] sure I'm just test building the new upload, that will take a while, my machine is not the fastest [16:57] * cjwatson retries then [16:57] But I wasn't going to bother, since there's going to be a rebuild shortly anyway [16:57] And it takes forever. [16:57] yes its a slow build [16:57] shrug. somebody can cancel if they want [16:57] jtaylor: it builds fine against the new lz4 on both amd64 and ppc64el [16:58] oh, hah, retried the wrong version anyway [16:58] * cjwatson leaves alone [17:01] cjwatson: your lvm snapshot grub fix works for me too, thanks [17:04] though for some reason grub-mount does not die [17:04] and blocks removing the snapshot [17:04] I guess that could cause issues when upgrading? [17:05] Not sure, it's possible that's os-prober's fault [17:05] finishing up for today now though ... [17:06] grub-mount /dev/mapper/lvm-dbbackup /var/lib/os-prober/mount is hanging [17:06] where dbbackup is the snapshot [17:07] jtaylor: does it go away if you just "umount /var/lib/os-prober/mount"? [17:07] not mounted [17:07] mkay, will try to have a look tomorrow [17:23] xnox: did you succeed in wiping a USB stick with the latest usb-creator version you uploaded? I'm getting bug #1307622 [17:23] bug 1307622 in usb-creator (Ubuntu) "Error trying to empty a USB stick: 'NoneType' object has no attribute 'get_cached_property'" [Undecided,New] https://launchpad.net/bugs/1307622 [17:24] Mirv: sticks with no partition table, or GPT partition table do not work. [17:24] Mirv: sticks with an MBR/bios partition table are wipable and installable. [17:25] xnox: oh, right, so those were remaining bugs. the case of no partition table here. I'll mark as duplicate. [17:26] and the previous time I had partition table [17:26] Mirv: i have fixed wiping in last upload... [17:26] Mirv: before last upload it would just fail in trusty. [17:29] right. I had it working in February according to logs. [17:29] with old style partition table I get 'gi._glib.GError: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Error synchronizing after initial wipe: Timed out waiting for object' instead, but still fails === roadmr is now known as roadmr_afk === roadmr_afk is now known as roadmr [17:46] ...which is the bug #1294877 [17:47] bug 1294877 in usb-creator (Ubuntu) "usb-creator fails to wipe usb device" [High,Confirmed] https://launchpad.net/bugs/1294877 === bfiller_afk is now known as bfiller [17:54] I know that this channel isn't meant as the place to ask questions but if there are developers here I figure that I'll more likely get my question answered. http://paste.ubuntu.com/7250828/ http://paste.ubuntu.com/7250837/ [17:57] xnox, hmm, are you sure your seed change is correct ? i just had an image build explode in my face (and all landings for touch need special approval) [17:59] ogra_: ubuntu-desktop is not installed on ubuntu-touch. [17:59] ogra_: thus which change are you talking about? [18:00] xnox, oh, sorry [18:00] i mixed that up [18:00] ogra_: also my change is only in -proposed, and thus does not affect image builds yet at all. [18:00] our meta is uninstallable atm [18:01] ogra_: well, check why or point to logs. [18:01] xnox: right, I needed to ext4 -> vfat and now it works. I summed up to https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1294877/comments/6 [18:01] Launchpad bug 1294877 in usb-creator (Ubuntu) "usb-creator fails to wipe usb device when the device has ext4 partition" [High,Confirmed] [18:02] http://paste.ubuntu.com/7250937/ [18:02] Mirv: thanks. [18:02] luckily 90%+ of USB sticks probably are vfat [18:02] Mirv: yeah, in common case it should work.... [18:15] wgrant: new pytables uploaded [18:15] thanks for fixing ppy64, did you already forward the fix? [18:17]