[01:31] cjwatson, around? [01:33] anyone know... i have a system with 4 drives, trying to install to it. [01:34] the bios has one of them marked as 'boot' [01:34] is there any way to know which disk is boot to select that driver. [01:41] smoser: #ubuntu might help [02:02] saiarcot895: lololol [02:02] smoser: UEFI ? [02:03] smoser: or you mean just where to write the grub mbr? [02:03] lifeless, yeah, which device to target with 'grub-install' [02:03] smoser: I'm going to guess that /dev/sda didn't work ? [02:04] :) [02:04] good guess [02:04] smoser: thats very odd [02:04] smoser: is it uefi w/gpt or ? [02:05] mbr [02:07] smoser: so what I generally do there is grub-install all drivers [02:07] smoser: and have a mdadm /boot that is mirrored to all drives [02:07] right. [02:08] that was the first thougt at a solution [02:08] but then if we give that drive (later) to something else [02:08] smoser: but... [02:08] that blows away the grub on it [02:08] then reboot will fail [02:09] smoser: when would you give the drive to something else? [02:09] well after boot, but later. [02:09] ie, i'd give it to ceph or something [02:09] smoser: I'm still not following the scenario [02:10] smoser: don't give ceph the full drive; give the drive two partitions - p1 is a 1G mdadm - part of /boot - p2 is a big blank device. [02:10] smoser: you give p2 to ceph. [02:11] smoser: you're looking at automating a robust answer for multi-drive bare metal ? [02:11] right. maybe that is right. [02:12] smoser: for getting different setups, you want to pass in a raid descriptor as part of your machine type. [02:12] smoser: or flavor, or whatever your bm cloud calls such things ;) === TheMuso` is now known as TheMuso [03:29] Is there away to find which apps still require python 2 on the iso? [03:32] apt-get remove --purge python2.7 [03:32] that's usually pretty good at giving you a list [03:32] Noskcaj_: If you don't want to fiddle with germinate to answer the question, a simple way would be to "apt-get install ubuntu-desktop^ ubuntu-live^" in a clean chroot, and then remove python. [03:32] Ahh, I see stgraber beat me to that, sort of. [03:33] Thanks for the info. I'll get a clean VM and try that [03:38] slangasek: FTR, for crash reports that you didn't feed through apport-cli yet, you can run apport-retrace with -R; but then you need the same package versions installed there as on the system where the crash happened [03:38] Good morning [03:39] Laney: bzr-builddeb \o/ thanks! [04:28] pitti: right, which isn't going to be the case between a phone and a desktop, so [04:30] pitti: I think I assumed the package information was all gathered at the time apport runs for the crash; since to do otherwise means the files may change out from underneath before the data is gathered, resulting in skew in the reports... [04:30] slangasek: right, but we check that at info collection time [04:31] slangasek: the goal was to do as little as possible at crash time as you can't really control/suppress it as a user [04:31] and only do the heavy lifting (querying packages, checking modifications, running hooks) when the user explicitly says "I want to report this" [04:31] understood, but it does mean there's the possibility of fuzz in the data being submitted as a result of package updates racing crash retracing [04:31] doesn't it? [04:32] slangasek: apport does several checks for that, like "crash time must be > ELF modification time" and "ELF time at the time of crash must be equal ELF time at the time of data collection" [04:32] otherwise the binary changed in between and gets rejected [04:32] (well, the crash gets rejected, not the binary) [04:34] ah, right [04:34] so it doesn't cause bad reports to be submitted, at least - that's good [04:35] it's a compromise [04:35] but people complain about the background IO/CPU enough as it is already [04:35] yep [04:38] pitti: You stole kmod from me? :P [04:38] infinity: oh, were you going to update it? I didn't know you had a lock on it [04:38] pitti: Nah, I don't care if you steal it, was just a bit surprised. === jono is now known as Guest95491 [04:39] infinity: how do you mean "steal"? it wasn't a merge [04:39] pitti: I was TIL regardless, I'm not sure "not a merge" is the metric. :) [04:39] well, I wish it was, Debian is several versions behind too [04:40] infinity: interesting; I don't generally ask the TIL except for merges [04:40] are we expected to now/ [04:40] ? [04:40] I offered to co-maintain it with Md, but he claimed he didn't need the help. :/ [04:40] pitti: I don't ask TIL for bugfixes (clearly, I do a lot of them), but I tend to for things like a new upstream, since maybe they had plans. [04:40] ok noted, I'll ask you next time about kmod [04:42] infinity: hey do you have plans for eglibc? I was thinking about upgrading it to current CVS ;) [04:42] slangasek: If you can find a current glibc in CVS, good luck. [04:43] actually, I just meant I was going to take the cvs source package and upload it in place of eglibc [04:43] Oh, that could work. [04:44] slangasek: Might need to patch gcc for s/-lc/-lcvs/ while you're at it. [04:44] no problem [04:46] LDFLAGS="-liberty" MAKEFLAGS="-justice" CFLAGS="-for=all" make [04:46] So sad that only one of those does something. [04:46] lol [04:46] I suppose if I had ustice CPU cores. [04:48] pitti: I suppose I could take TIL back by fixing your build failure. :P [04:49] erk, missing xsltproc, sorry [04:49] infinity: well, if you wish, otherwise I'll upload a fix [04:49] pitti: I'm poking it now. [04:49] thanks [04:55] pitti: Hrm, are you sure we can drop check_builtin_kver? I'd have to sort out how and when that's executed, but if it could ever be run and break on a buildd, we still need it. [04:55] infinity: hm, why would you install trusty's kmod on a lucid machine/kernel? [04:56] infinity: fine for me to put it back in, but it seemed like a rather obsolete extra check to me now [04:57] pitti: You'd have it installed in any chroot building on a hardy-based buildd. [04:58] (I hope you mean lucid) [04:58] pitti: You wish I meant lucid. [04:58] ah, I see [04:58] infinity: we are running production machines which have been EOLed half a year ago? [04:58] nice :) [04:58] The function returns cleanly anyway, it's just noisy. But I don't see any point in dropping the patch either. *shrug* [05:03] pitti: infinity's comment made me curious. the sparc buildds (artigas and sejong) both appear to still be running 2.6.24 kernels [05:04] tarpman: right, but they don't actually build anything newer than lucid any more [05:04] yeah [05:04] (do they even do that?) [05:04] I don't remember any more when we dropped sparc and hppa [05:04] https://launchpad.net/builders/sejong/+history seems to still build lucid updates [05:05] ah, so we dropped it in karmic [05:06] pitti: All the PPA buildds are hardy. [05:06] infinity: erk -- then I guess we should reapply the patch to avoid some noise? [05:07] pitti: Yeah, already uploaded. But now I'm questioning this static/dynamic thing.. [05:07] bin/kmod on my system is dynamically linked. Which is what I'd expect. The new one isn't. That seems suboptimal. [05:09] according to upstream NEWS they did that to ease running from initramfs or other limited environments; and in the udev we want a static link anyway [05:09] err, I can't type "udeb" for the life of it [05:09] Erm, you what? [05:09] udev links to libkmod directly, why would it care how /bin/kmod is linked? [05:09] Oh, the udeb always was static. [05:09] infinity: "udeb", "udeb", "udeb" [05:09] The udeb was static, the deb wasn't. [05:09] Which is correct, IMO. [05:10] in a sense, "udev" wasn't totally wrong as it's built very similarly; udevd and udevadm themselves don't link to libudev [05:10] - kmod binary statically links to libkmod - if distro is only interested [05:10] in the kmod tool (for example in an initrd) it can refrain from [05:10] installing the library [05:10] * infinity sighs. [05:10] What if "distro" is interested in not having two copies of the library for no good reason? [05:11] Oh well. [05:12] I didn't find a switch to make /bin/kmod dynamically linked again, but I don't think it's a biggie so I didn't bother patching around [05:13] I should statically link everything in libc-bin, in case distro is only interested in /usr/bin/iconv [05:14] I'll argue this upstream if I find the energy, but no, don't care enough to fix it right now. [05:15] I find "I don't know how to do library reduction to build an initrd" a pretty lousy reason for statically linking everything. :P [05:23] lsof 4 eva? [05:23] bah [05:23] I mean ldd 4 eva [05:24] lifeless: Using lsof to discover library linkage could be a bit racy. :) [05:24] What compiler flags and platform/march does ubuntu target for the 32 and 64bit platforms? [05:26] infinity: not to mention fatally buggy on platforms that map and close [05:30] UserError: -mtune=generic on both, and -march=i686 on i386. [05:30] thank you [05:30] lifeless: ld.so still has it open for a fraction of a second. lsof faster. [05:31] infinity: :> [05:37] Is the add-apt-repository python 3 part going to be backported to LTS for the new features? [05:37] on 2.7 or updated entirely [05:43] UserError: The only new features LTS gets are hardware support, anti-virus and similar updates, and firefox [05:44] Oh, gotcha [05:45] details here https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions [05:47] I don't suppose they would take kindly to asking for apt as an exception ;) [05:47] or rather, a .py [07:11] rbasak: hey Robie, how are you? [07:11] rbasak: do you know when we'll get cloud images for trusty? It's currently rather inconvenient to run trusty autopkgtests [07:26] infinity, hi :), did libept1.4.12 broke abi? seems aptitude isnt happy with 1.0.10 [07:26] aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs [07:28] pitti, first images landed yesterday: http://cloud-images.ubuntu.com/trusty/20131023/ [07:29] jibel: hm, prepare-testbed still complains [07:29] I guess no /current link yet [07:41] mdeslaur, Do you mind if i merge tiff? === iahmad is now known as iahmad|afk [08:42] pitti, hmm, seems we have a new powerd crash during tests of image #4 (http://reports.qa.ubuntu.com/smokeng/trusty/touch/mako/4:20131023:20131015/4795/sdk/) ... and i noticxe upower was the one suspicious change ... http://people.canonical.com/~ogra/touch-image-stats/20131023.changes ... any idea if your update could have caused that crasher ? === tkamppeter_ is now known as tkamppeter [08:43] ogra_: unlikely; upower fixed bug 1240673 with a very simple change (http://launchpadlibrarian.net/154787650/upower_0.9.23-1_0.9.23-2.diff.gz) [08:43] bug 1240673 in upower (Ubuntu Saucy) "Reports 0% charged for fully charged batteries" [High,Fix committed] https://launchpad.net/bugs/1240673 [08:43] ogra_: what's the crash? [08:44] pitti, see the first url, there is a .crash file [08:44] ogra_: so unless this had a dell battery, it should behave identically [08:44] well, -1 had changes too [08:44] oh, that was -1 [08:44] sorry [08:44] hmm, or i'm blind :P [08:45] ogra_: well, for a few weeks now we had powerd crashes in every other test; is that a new one? [08:45] (no data collected on that, so it's fairly useless) === iahmad|afk is now known as iahmad [08:46] pitti, it is the first time we have one in trusty [08:46] image 1 and 3 didnt have it [08:46] (2 failed to build) [08:48] hmm, sad, i was hoping to find an overseen g_type_init() or some such in the code, but seems that was removed in june [08:49] can we fix whichever test runner that is to actually process .crash files? [08:49] like that they are mostly useless [08:49] psivaa, ^^^ ? [08:50] I thought we were using /usr/share/apport/whoopsie-upload-all or something similar in most test runners now [08:50] might be that the sdk test doesnt though [08:53] ogra_: ok if processing crash files is what's needed, ill take it upto doanac and plars about it [08:53] thanks === doko_ is now known as doko [09:55] xnox, what is triaged in https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1015219 ? [09:55] Ubuntu bug 1015219 in gcc-4.7 (Ubuntu Precise) "Can't install lib64stdc++6 due to unmet dependencies" [Medium,Triaged] === iahmad is now known as iahmad|afk [09:59] doko: a warm fuzzy feeling of the requester. Is it actually a bug that was fixed, or simply multi-arch was not properly available/enabled in 12.04? === emma is now known as em [10:16] tyhicks, jdstrand: do you have any idea about bug 1244157 by chance? I'm pulling my hair out on that one, and it's not clear to me what changed on Oct 9 to break it [10:16] bug 1244157 in apparmor (Ubuntu) ""Failed name lookup - disconnected path" in dhclient D-BUS access" [Undecided,New] https://launchpad.net/bugs/1244157 === MacSlow is now known as MacSlow|lunch [10:50] jjohansen: ^ I bisected this to https://launchpad.net/ubuntu/+source/linux/3.11.0-12.18, so something with your patches [10:50] jibel: ^ FYI, as you were asking about the NM autopkgtest regression [10:50] cjwatson: You wrote that bug 1132918 is a python-apt bug; but I don't see how size_to_str can return a non-unicode string in Python 3. Do you know what's happening there? [10:50] bug 1132918 in python-apt (Ubuntu Raring) "Ubiquity crashes after user creation" [High,Confirmed] https://launchpad.net/bugs/1132918 [10:51] juliank: I can't remember. IIRC it's a string overflow or otherwise busted string data rather than non-unicode in any normal way [10:51] juliank: I remember it not being at all obvious and taking a while to find [10:53] juliank: as far as I remember one needed to use a funky locale to reproduce it, e.g. fi_FI.UTF-8 or some such. [10:54] cjwatson: Thanks, that's all I need I think. APT uses sprintf() for printing, it should use snprintf. [10:54] juliank: Oh maybe it was et_EE.UTF-8 or something [10:54] I think xnox is right, there was some locale that returned non-ASCII data [10:54] And apt/python-apt wasn't converting it [10:54] sprintf/snprintf is probably a red herring [10:56] cjwatson: I just wonder, because if you can decode the return value of size_to_str in Python 3 (which the changelog for ubiquity mentions), it cannot be a (unicode) 'str'. But size_to_str returns unicode here. [10:58] If decoding means calling decode() on it [10:58] As that method does not exist in Python 3 for str objects, only for bytes. [10:59] Yes I know. The relevant code is: [10:59] current_cps = apt_pkg.size_to_str(self.current_cps) [10:59] if isinstance(current_cps, bytes): [10:59] current_cps = current_cps.decode() [10:59] But it was clearly a workaround [11:00] * cjwatson tries to remember how he reproduced this [11:01] The Python object is generated by CppPyString which calls PyUnicode_FromStringAndSize(), I doubt that one returns a bytes object. [11:01] * cjwatson resorts to grepping IRC logs [11:03] juliank: At the time there was a non-breaking space in the thousands separator in at least some locales, but we may have dropped that which would make this harder to reproduce [11:05] juliank: But it's also possible that code came from the period when we needed to deal with polyglot Python 2/3 [11:06] And in Python 2 I needed that to be reliably unicode [11:09] juliank: However, the syslog in that bug postdates ubiquity switching to Python 3, so it can't be as simple as "just works in Python 3". [11:10] Anyhow, the decode is irrelevant, it's after the crash site in this bug [11:11] juliank: I think this bug occurs when you get non-ASCII text from the locale's numeric representation and try to feed it to PyUnicode_FromStringAndSize. [11:11] The traceback said: File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 187, in pulse [11:20] juliank: Well, I don't know if this was the original problem (it's weird that ubiquity would ever be in this locale), but here's a reproducer: http://paste.ubuntu.com/6294362/ [11:21] (Of course you have to have the et_EE locale generated first; note that that's a non-UTF-8 locale) [11:21] ScottK, is kgraphview unmaintained? I see you let it build with boost1.49 with your last upload [11:22] cjwatson: OK, that makes sense then. But then it's a Python bug, as that is decoding the string. [11:23] juliank: Seems more likely that there's some other function that would do the right thing [11:23] I mean, Python certainly *can* decode from such encodings [11:23] And PyUnicode_FromStringAndSize is *documented* as taking UTF-8-encoded bytes [11:24] So it is the wrong function to call if the data might be non-UTF-8-encoded [11:24] Seems true. [11:24] I don't know the C API well enough [11:25] * cjwatson drops a reproducer into the bug [11:28] So, do I really have to lookup the message encoding of the locale and then use that one for decoding? There's no easy function for this available; I'd expect that to be a normal issue in Python development. [11:28] I'm not sure, I'm afraid === Sweetsha1k is now known as Sweetshark [11:32] I don't think there's a sane way to support non-utf8 locales === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow [12:19] pitti: re bug #1244157 [12:19] bug 1244157 in linux (Ubuntu) "[3.11.0-12.18 regression] "Failed name lookup - disconnected path" in dhclient D-BUS access" [Undecided,Confirmed] https://launchpad.net/bugs/1244157 [12:19] pitti: are the network manager tests running in a container? [12:19] jdstrand: no, plain VM or just plainly on my workstation === brainwash_ is now known as brainwash [12:22] that's very strange since I would expect massive bug filings if dhclient didn't work in the generally case [12:22] s/generally/general/ [12:22] jdstrand: right, it doesn't happen with my "normal" NM either [12:23] jdstrand: I'll still try to reduce the reproducer, but I asked jjohansen in case he already has an idea from that message [12:23] pitti: yeah, I think we need jjohansen for this. if lxc or chroots aren't involved, then we need him === freeflying_away is now known as freeflying [12:37] pitti, jjohansen: I'm looking in https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/job/trusty-adt-network-manager/1/ARCH=i386,label=adt/artifact/results/log and it looks like pbuilder (ie, a chroot) is involved [12:38] pitti (fyi jjohansen): can you update the profile to have: [12:38] /usr/lib/NetworkManager/nm-dhcp-client.action flags=(attach_disconnected) { ... } [12:38] jdstrand: no, we don't use chroots there; it just calls pbuilder-satisfydepends-classic to install the dependencies [12:38] pitti (fyi jjohansen): and try again? [12:39] * pitti sets up VM to avoid losing network [12:40] pitti: where is pbuilder-satisfydepends-classic installing the dependencies if not in a chroot? [12:40] * jdstrand is not a pbuilder expert [12:40] jdstrand: into the currently running syste [12:40] m [12:41] jdstrand: it's just a helper tool to determine a set of packages from a Depends: line [12:41] I see [12:41] jdstrand: but in the reproduction recipe in comment #2 there's no chroot or pbuilder involved [12:41] ok, I'm set up [12:41] pitti: I think adding attach_disconnected is still worthwhile as a data point [12:42] jdstrand: "sudo /etc/init.d/apparmor reload"? [12:42] pitti: sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient [12:42] jdstrand: oh, seems "reload" worked [12:43] it would too, it is just more heavy-handed [12:43] yay, so that's it [12:43] what does that flag mean? [12:44] so the paths are disconnected from a filesystem (ie, the leading '/' is missing). attach_disconnected will just put them on '/' and hopes for the best [12:44] jdstrand: oh, I'm running the tests under an unshared file system [12:44] pitti: can you update the bug that adding attach_disconnected helps as a workaround? the thing is, we shouldn't need attach_disconnected here [12:45] jdstrand: as I'm mounting tmpfses over /run/NetworkManager and /etc/NetworkManager as to avoid disturbing/destroying files in the production system [12:45] ah [12:45] jdstrand: yes, currently doing that; I was just wondering because even setting the profile to "complain" didn't help [12:46] jdstrand, hmm, could it be that we borke netwporking for armhf desktop users who have to use a kernel with old apparmor ? bug 1231778 [12:46] bug 1231778 in network-manager (Ubuntu) "wifi not working on Saucy Salamander" [Medium,Confirmed] https://launchpad.net/bugs/1231778 [12:46] well, attach_disconnected is exactly what you want [12:46] jdstrand: the test could completely disable apparmor, but I'd rather test the whole thing as closely as possible [12:46] pitti: I think this is a case for another sed [12:47] jdstrand: (it'd be the first sed, but I see what you mean) [12:47] pitti: oh, I thought we were doing a sed on something else as of a few weeks ago [12:48] jdstrand: no, I fixed that properly in dbusmock [12:48] ah, right [12:48] (but that part isn't involved here; that was my first thought) [12:48] these tests run without any mocking [12:48] ogra_: no, that is different. no (relevant) apparmor denials in that bug [12:49] jdstrand, well, i just had someone debug it and he noticed that dns doesnt work at all with NM, while it works with /e/n/i ... seems i need to poke cyphermox then [12:49] jdstrand: so the patches in -12.18 weren't really a regression but this is supposed to not work with an unshared fs namespace? [12:49] jdstrand: i. e. is this "invalid"/"wontfix", or still a bug and the above is a workaround? [12:50] jjohansen: fyi, seems that attach_disconnected is exactly what pitti needs-- he is mounting tmpfses over parts of the filesystem [12:50] jjohansen: I'm not sure if there is another bug there, can you comment in the bug? [12:50] jjohansen, jdstrand: not the D-BUSy parts, though; I guess it's the "unshared fs" which upsets it [12:50] pitti: I'm not sure [12:51] jdstrand: anyway, I followed up to the bug with a summary [12:51] pitti: let's leave it open for now and let jjohansen comment when he gets back [12:51] ack [12:51] pitti: thanks [12:51] jdstrand: thanks to you! [12:51] Ran 23 tests in 221.487s [12:51] \o/ [12:51] yw :) [12:51] I'll come up with some seddery for now [12:52] jdstrand, there is an intresting line in dmesg of that bug though ... [12:52] [ 59.264921] type=1400 audit(1380291018.856:28): apparmor="STATUS" info="failed to unpack profile" error=-71 pid=781 comm="apparmor_parser" name="/usr/lib/NetworkManager/nm-dhcp-client.action" offset=155 [12:52] (and dhcp/dns is the bit not working apparently) [12:52] wow, seems ogra_ and I stumbled over two completely different problems in the very same line of a profile :) [12:53] heh [12:53] ogra_: hmm.. I have never seen that error befor [12:53] jdstrand, that device uses an android kernel without apparmor patches ... (but ubuntu config) [12:53] could that have any influence ? [12:54] (and no, this is lubuntu desktop, not touch) [12:54] :) [12:56] ogra_: I would think that would be an influence, yes. I don't know this error condition-- that is coming from the kernel. normally the parser isn't run on profiles when apparmor is disabled/not available [12:56] jjohansen: different issue> can you comment on backscroll between me and ogra_ going back 5 minutes from this message? [12:57] jdstrand, well, i think it is enabled (as the device copies the panda kernel config with HW specific adjustments) ... but only the version that is shipped in this kernel by default [12:58] ogra_ (fyi jjohansen): ah, well that is probably explained by an old kernel with new userspace and new apparmor policy (nm-dhcp-client.action has dbus rules) [12:59] right, thats what i suspect [12:59] note that we have many (if not most) armhf users out there with such setups [13:00] ogra_ (fyi, jjohansen): the parser I think should be able to handle that though since it is examining apparmor features in the running kernel though. there might be a bug there or for some reason what it needs to determine the feature set isn't present [13:00] the majority of our arm community uses their own kernels just with an ubuntu-core rootfs where they then install the desired -desktop package [13:01] ogra_: honestly, if they are using their own kernel, it seems like they should really also be pulling back the new apparmor like the porters for touch do [13:02] jdstrand, 90% of these people just know how to flash their device ... [13:02] they always used the existing kernel binaries and an ubuntu userspace [13:02] (often even android binaries) [13:03] if we add a hard dependency on patching yoour kernel in our userspace we'll likely use that lot [13:03] that seems problematic for a bunch of reasons. anhyhoo, like I said, there might be a bug there or something isn't setup right for that confiugration [13:03] * jdstrand needs jjohansen to comment [13:03] s/in out/to use our/ [13:03] jdstrand, it works fine with debian, or fedora [13:04] or whatever other distro they use [13:04] (though i guess fedora will soon cause similar issues by using systemd) [13:04] yep [13:05] doko: I'll take valadoc [13:05] cjwatson: FYI, doko and I discussed valadoc [13:05] cjwatson, pitti was looking at [13:05] like I said, apparmor_parser should be able to handle that aiui [13:05] pitti: ping [13:05] "discussed" or "is going to fix"? [13:05] I assume you need https://mail.gnome.org/archives/commits-list/2013-September/msg08896.html [13:05] cjwatson: trunk builds against cgraph, but apparently too many other packages would need porting as well, so doko was going to bring back libgraph [13:05] pitti: Yes, but that didn't obviously help [13:05] cjwatson, so I re-enabled libgraph again, however it looks like libcgraph and libgraph cannot co-exist in parallel anymore [13:06] cjwatson: oh, ok [13:06] pitti: We need to port everything, I think; it sucks but there it is [13:06] so it seems we either port the five-or-so libgraph consumers or don't build cgraph? [13:06] Let's just port, we already started [13:06] at least until Debian gets the new version, so that we don't have to deviate so much [13:06] cjwatson: ok [13:07] pitti: hey, we are seeing some issues with running webapps AP tests and appear to hit some dbus issues. so wondering if you'd be able to help [13:07] pitti: so, OK if I cherry-pick the cgraph work from upstream? [13:08] cjwatson: I just tried a trunk build, not a cherry-pick; but you need to disable the 0.16 bits (i. e. drop the libvala0.16 build deps), I didn't get that one to build [13:08] Looks like 7b22bc146b318790552aa8ec1ece25a3a06d1316 and 0dcad4e7364c1f7c892ed0c0073a66aefa325b42 [13:08] but that's fine, we want 0.20 [13:09] psivaa: I have some three conversations and a meeting in 20 mins, after that? [13:09] pitti: sure, thanks :) [13:09] psivaa: (or subscribe me to a bug or something) [13:09] pitti: we have not reported any bugs but i'll try and ping you after an hour === liam_ is now known as Guest1997 [13:14] jdstrand: added another question to the bug, perhaps you know this [13:14] pitti, psivaa, ogra_: yes, there seems to be some issue with inotify in whoopsie. I was looking at this recently and had some limited success with restarting whoopsie, then calling whoopsie-upload-all. But most of the time it seems like it will still timeout after failing for 30 minutes to see that the .crash file has uploaded [13:15] I'll look at it some more today [13:15] great, thanks [13:15] plars: at least after that the crashes should have the packaging information [13:16] pitti: yeah, just saw it. I don't think so [13:16] pitti: but let's see what jj says-- there might be a bug and you might not need attach_disconnected [13:17] jdstrand: I guess I could copy the whole /etc/apparmor.d into a tmpfs and move it over; but I'm not sure that would even work [13:19] plars: is inotify actually working on /var/crash? [13:19] ev, is inotify working omn bind mounted dirs ? [13:19] :) [13:19] you tell me! :-P [13:20] * ogra_ doesnt know ... but /var/crash is a bindmount [13:20] oh, that woudl explain it [13:20] if whoopsie starts first, sets the inotify, and *after* that you do the bind mount [13:20] that would explain why restarting whoopsie makes it work [13:20] the bind mount happens from mountall [13:20] as the original inotify is on an inode on the root fs [13:21] whoopsie surely doesnt start before mountall, does it ? [13:21] no [13:21] ok, would have been a nice explanation [13:22] ogra_: so that's not done by writable-files? [13:22] writable-files are processed in the initrd [13:22] to create an fstab [13:23] eth actual mounting is done by mountall processing the fstab [13:24] ev: it would appear not since it needs to be restarted, but sometimes even that doesn't seem to be enough [13:26] hmm [13:36] cjwatson, pitti: looks like my graphviz upload re-enabling libgraph was not a good idea. you can't have these in parallel anymore. and configuring graphviz --without-cgraph doesn't seem to work either [13:36] doko: Can we just go back to 0ubuntu2 and port everything? [13:36] Fedora did that [13:37] yes, we have to [14:00] stgraber: can we fix this: http://blog.bofh.it/debian/id_413 [14:00] ? [14:11] xnox, stgraber, tedg: with the current upstart jobs, is it possible that unity-panel-service is started before dbus's session job? [14:11] if so can we make it just start when the session bus is ready [14:11] seb128, I don't think so. [14:11] * tedg double checks [14:12] tedg, you don't think that it's possible... or happening or...? [14:12] seb128, No it's starting with gnome-session, which is started after dbus. [14:13] tedg, we are getting indicators that hit g_error() code on init because there is no session bus, that's weird [14:13] seb128, I don't think the restart bug is fixed in distro yet though. [14:13] * seb128 wonders how that's possible if thing are correctly ordered [14:13] tedg, what restart bug? [14:14] seb128, When upstart restarts it doesn't save the environment variables, so then tasks can't find dbus. [14:14] seb128, Looks like 0ubuntu8 is in trusty, but not saucy. [14:14] tedg, "upstart restarts"? is that re-exec on update? [14:14] seb128, We put a recoverable error in HUD to detect it: https://errors.ubuntu.com/bucket/?id=DBusSessionAddressNotSet [14:15] we're seeing this can't-get-bus-so-let's-crash happen in multiple indicators, and there are similar crashes that go back years in LP [14:15] seb128: it shouldn't, but it can be sometimes. [14:15] xnox, tedg: is somebody working on getting that upstart fix SRUed? [14:16] seb128: re-exec on update upstart itself, or any it's dependencies upgraded. you can reproduce it with $ telinit u [14:17] seb128: i dont' think that was in trusty yet. [14:17] seb128, I assume, but I haven't verified. [14:17] xnox, Oh, is that not in ubuntu8? [14:17] seb128: tedg: there is merge proposal to fix it, but that's not merged in trunk yet. [14:17] tedg: read changelog =) https://launchpad.net/ubuntu/+source/upstart/1.10-0ubuntu8 [14:17] tedg: there is no mentioning of the saving/restoring environment =)))) [14:18] xnox, Ah, I figured "super important" :-) [14:18] (serialising, deserialising and preserving evn acroos restart) [14:18] seb128, So apparently not fixed yet :-/ [14:18] tedg: ph, desktop stuff =) the host stayed up. [14:19] tedg: but yeah, it's important and jodh is working on fixing it. [14:19] tedg, xnox: who is working on it? jodh? [14:19] xnox, ok, thanks [14:19] seb128: tedg https://code.launchpad.net/~jamesodhunt/upstart/bug-1238078/+merge/190723 [14:20] tedg: I've fixed the issue, but we have a bit of a review backlog atm :) [14:21] * tedg can click "approve", send me links! ;-) [14:22] cjwatson: when you get a chance, could you please ack my email to ubuntu-devel ref a UDS track name change? [14:23] tedg: sorry, upstart devs only :). FWIW, that is the top priority branch to be merged. [14:23] cjohnston: done [14:23] thanks :-) [14:24]