| smoser | cjwatson, around? | 01:31 |
|---|---|---|
| smoser | anyone know... i have a system with 4 drives, trying to install to it. | 01:33 |
| smoser | the bios has one of them marked as 'boot' | 01:34 |
| smoser | is there any way to know which disk is boot to select that driver. | 01:34 |
| saiarcot895 | smoser: #ubuntu might help | 01:41 |
| lifeless | saiarcot895: lololol | 02:02 |
| lifeless | smoser: UEFI ? | 02:02 |
| lifeless | smoser: or you mean just where to write the grub mbr? | 02:03 |
| smoser | lifeless, yeah, which device to target with 'grub-install' | 02:03 |
| lifeless | smoser: I'm going to guess that /dev/sda didn't work ? | 02:03 |
| smoser | :) | 02:04 |
| smoser | good guess | 02:04 |
| lifeless | smoser: thats very odd | 02:04 |
| lifeless | smoser: is it uefi w/gpt or ? | 02:04 |
| smoser | mbr | 02:05 |
| lifeless | smoser: so what I generally do there is grub-install all drivers | 02:07 |
| lifeless | smoser: and have a mdadm /boot that is mirrored to all drives | 02:07 |
| smoser | right. | 02:07 |
| smoser | that was the first thougt at a solution | 02:08 |
| smoser | but then if we give that drive (later) to something else | 02:08 |
| lifeless | smoser: but... | 02:08 |
| smoser | that blows away the grub on it | 02:08 |
| smoser | then reboot will fail | 02:08 |
| lifeless | smoser: when would you give the drive to something else? | 02:09 |
| smoser | well after boot, but later. | 02:09 |
| smoser | ie, i'd give it to ceph or something | 02:09 |
| lifeless | smoser: I'm still not following the scenario | 02:09 |
| lifeless | 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 |
| lifeless | smoser: you give p2 to ceph. | 02:10 |
| lifeless | smoser: you're looking at automating a robust answer for multi-drive bare metal ? | 02:11 |
| smoser | right. maybe that is right. | 02:11 |
| lifeless | smoser: for getting different setups, you want to pass in a raid descriptor as part of your machine type. | 02:12 |
| lifeless | smoser: or flavor, or whatever your bm cloud calls such things ;) | 02:12 |
| === TheMuso` is now known as TheMuso | ||
| Noskcaj_ | Is there away to find which apps still require python 2 on the iso? | 03:29 |
| stgraber | apt-get remove --purge python2.7 | 03:32 |
| stgraber | that's usually pretty good at giving you a list | 03:32 |
| infinity | 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 |
| infinity | Ahh, I see stgraber beat me to that, sort of. | 03:32 |
| Noskcaj_ | Thanks for the info. I'll get a clean VM and try that | 03:33 |
| pitti | 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 |
| pitti | Good morning | 03:38 |
| pitti | Laney: bzr-builddeb \o/ thanks! | 03:39 |
| slangasek | pitti: right, which isn't going to be the case between a phone and a desktop, so | 04:28 |
| slangasek | 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 |
| pitti | slangasek: right, but we check that at info collection time | 04:30 |
| pitti | 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 |
| pitti | and only do the heavy lifting (querying packages, checking modifications, running hooks) when the user explicitly says "I want to report this" | 04:31 |
| slangasek | 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 |
| slangasek | doesn't it? | 04:31 |
| pitti | 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 |
| pitti | otherwise the binary changed in between and gets rejected | 04:32 |
| pitti | (well, the crash gets rejected, not the binary) | 04:32 |
| slangasek | ah, right | 04:34 |
| slangasek | so it doesn't cause bad reports to be submitted, at least - that's good | 04:34 |
| pitti | it's a compromise | 04:35 |
| pitti | but people complain about the background IO/CPU enough as it is already | 04:35 |
| slangasek | yep | 04:35 |
| infinity | pitti: You stole kmod from me? :P | 04:38 |
| pitti | infinity: oh, were you going to update it? I didn't know you had a lock on it | 04:38 |
| infinity | pitti: Nah, I don't care if you steal it, was just a bit surprised. | 04:38 |
| === jono is now known as Guest95491 | ||
| pitti | infinity: how do you mean "steal"? it wasn't a merge | 04:39 |
| infinity | pitti: I was TIL regardless, I'm not sure "not a merge" is the metric. :) | 04:39 |
| pitti | well, I wish it was, Debian is several versions behind too | 04:39 |
| pitti | infinity: interesting; I don't generally ask the TIL except for merges | 04:40 |
| pitti | are we expected to now/ | 04:40 |
| pitti | ? | 04:40 |
| infinity | I offered to co-maintain it with Md, but he claimed he didn't need the help. :/ | 04:40 |
| infinity | 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 |
| pitti | ok noted, I'll ask you next time about kmod | 04:40 |
| slangasek | infinity: hey do you have plans for eglibc? I was thinking about upgrading it to current CVS ;) | 04:42 |
| infinity | slangasek: If you can find a current glibc in CVS, good luck. | 04:42 |
| slangasek | actually, I just meant I was going to take the cvs source package and upload it in place of eglibc | 04:43 |
| infinity | Oh, that could work. | 04:43 |
| infinity | slangasek: Might need to patch gcc for s/-lc/-lcvs/ while you're at it. | 04:44 |
| slangasek | no problem | 04:44 |
| infinity | LDFLAGS="-liberty" MAKEFLAGS="-justice" CFLAGS="-for=all" make | 04:46 |
| infinity | So sad that only one of those does something. | 04:46 |
| sarnold | lol | 04:46 |
| infinity | I suppose if I had ustice CPU cores. | 04:46 |
| infinity | pitti: I suppose I could take TIL back by fixing your build failure. :P | 04:48 |
| pitti | erk, missing xsltproc, sorry | 04:49 |
| pitti | infinity: well, if you wish, otherwise I'll upload a fix | 04:49 |
| infinity | pitti: I'm poking it now. | 04:49 |
| pitti | thanks | 04:49 |
| infinity | 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 |
| pitti | infinity: hm, why would you install trusty's kmod on a lucid machine/kernel? | 04:55 |
| pitti | infinity: fine for me to put it back in, but it seemed like a rather obsolete extra check to me now | 04:56 |
| infinity | pitti: You'd have it installed in any chroot building on a hardy-based buildd. | 04:57 |
| pitti | (I hope you mean lucid) | 04:58 |
| infinity | pitti: You wish I meant lucid. | 04:58 |
| pitti | ah, I see | 04:58 |
| pitti | infinity: we are running production machines which have been EOLed half a year ago? | 04:58 |
| pitti | nice :) | 04:58 |
| infinity | The function returns cleanly anyway, it's just noisy. But I don't see any point in dropping the patch either. *shrug* | 04:58 |
| tarpman | pitti: infinity's comment made me curious. the sparc buildds (artigas and sejong) both appear to still be running 2.6.24 kernels | 05:03 |
| pitti | tarpman: right, but they don't actually build anything newer than lucid any more | 05:04 |
| tarpman | yeah | 05:04 |
| pitti | (do they even do that?) | 05:04 |
| pitti | I don't remember any more when we dropped sparc and hppa | 05:04 |
| tarpman | https://launchpad.net/builders/sejong/+history seems to still build lucid updates | 05:04 |
| pitti | ah, so we dropped it in karmic | 05:05 |
| infinity | pitti: All the PPA buildds are hardy. | 05:06 |
| pitti | infinity: erk -- then I guess we should reapply the patch to avoid some noise? | 05:06 |
| infinity | pitti: Yeah, already uploaded. But now I'm questioning this static/dynamic thing.. | 05:07 |
| infinity | bin/kmod on my system is dynamically linked. Which is what I'd expect. The new one isn't. That seems suboptimal. | 05:07 |
| pitti | 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 |
| pitti | err, I can't type "udeb" for the life of it | 05:09 |
| infinity | Erm, you what? | 05:09 |
| infinity | udev links to libkmod directly, why would it care how /bin/kmod is linked? | 05:09 |
| infinity | Oh, the udeb always was static. | 05:09 |
| pitti | infinity: "udeb", "udeb", "udeb" | 05:09 |
| infinity | The udeb was static, the deb wasn't. | 05:09 |
| infinity | Which is correct, IMO. | 05:09 |
| pitti | 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 |
| infinity | - kmod binary statically links to libkmod - if distro is only interested | 05:10 |
| infinity | in the kmod tool (for example in an initrd) it can refrain from | 05:10 |
| infinity | installing the library | 05:10 |
| * infinity sighs. | 05:10 | |
| infinity | What if "distro" is interested in not having two copies of the library for no good reason? | 05:10 |
| infinity | Oh well. | 05:11 |
| pitti | 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:12 |
| infinity | I should statically link everything in libc-bin, in case distro is only interested in /usr/bin/iconv | 05:13 |
| infinity | I'll argue this upstream if I find the energy, but no, don't care enough to fix it right now. | 05:14 |
| infinity | 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:15 |
| lifeless | lsof 4 eva? | 05:23 |
| lifeless | bah | 05:23 |
| lifeless | I mean ldd 4 eva | 05:23 |
| infinity | lifeless: Using lsof to discover library linkage could be a bit racy. :) | 05:24 |
| UserError | What compiler flags and platform/march does ubuntu target for the 32 and 64bit platforms? | 05:24 |
| lifeless | infinity: not to mention fatally buggy on platforms that map and close | 05:26 |
| infinity | UserError: -mtune=generic on both, and -march=i686 on i386. | 05:30 |
| UserError | thank you | 05:30 |
| infinity | lifeless: ld.so still has it open for a fraction of a second. lsof faster. | 05:30 |
| lifeless | infinity: :> | 05:31 |
| UserError | Is the add-apt-repository python 3 part going to be backported to LTS for the new features? | 05:37 |
| UserError | on 2.7 or updated entirely | 05:37 |
| lifeless | UserError: The only new features LTS gets are hardware support, anti-virus and similar updates, and firefox | 05:43 |
| UserError | Oh, gotcha | 05:44 |
| sarnold | details here https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions | 05:45 |
| UserError | I don't suppose they would take kindly to asking for apt as an exception ;) | 05:47 |
| UserError | or rather, a .py | 05:47 |
| pitti | rbasak: hey Robie, how are you? | 07:11 |
| pitti | rbasak: do you know when we'll get cloud images for trusty? It's currently rather inconvenient to run trusty autopkgtests | 07:11 |
| ricotz | infinity, hi :), did libept1.4.12 broke abi? seems aptitude isnt happy with 1.0.10 | 07:26 |
| ricotz | aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs | 07:26 |
| jibel | pitti, first images landed yesterday: http://cloud-images.ubuntu.com/trusty/20131023/ | 07:28 |
| pitti | jibel: hm, prepare-testbed still complains | 07:29 |
| pitti | I guess no /current link yet | 07:29 |
| Noskcaj | mdeslaur, Do you mind if i merge tiff? | 07:41 |
| === iahmad is now known as iahmad|afk | ||
| ogra_ | 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 ? | 08:42 |
| === tkamppeter_ is now known as tkamppeter | ||
| pitti | 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 |
| ubottu | bug 1240673 in upower (Ubuntu Saucy) "Reports 0% charged for fully charged batteries" [High,Fix committed] https://launchpad.net/bugs/1240673 | 08:43 |
| pitti | ogra_: what's the crash? | 08:43 |
| ogra_ | pitti, see the first url, there is a .crash file | 08:44 |
| pitti | ogra_: so unless this had a dell battery, it should behave identically | 08:44 |
| ogra_ | well, -1 had changes too | 08:44 |
| ogra_ | oh, that was -1 | 08:44 |
| ogra_ | sorry | 08:44 |
| ogra_ | hmm, or i'm blind :P | 08:44 |
| pitti | ogra_: well, for a few weeks now we had powerd crashes in every other test; is that a new one? | 08:45 |
| pitti | (no data collected on that, so it's fairly useless) | 08:45 |
| === iahmad|afk is now known as iahmad | ||
| ogra_ | pitti, it is the first time we have one in trusty | 08:46 |
| ogra_ | image 1 and 3 didnt have it | 08:46 |
| ogra_ | (2 failed to build) | 08:46 |
| ogra_ | 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:48 |
| pitti | can we fix whichever test runner that is to actually process .crash files? | 08:49 |
| pitti | like that they are mostly useless | 08:49 |
| ogra_ | psivaa, ^^^ ? | 08:49 |
| pitti | I thought we were using /usr/share/apport/whoopsie-upload-all or something similar in most test runners now | 08:50 |
| ogra_ | might be that the sdk test doesnt though | 08:50 |
| psivaa | ogra_: ok if processing crash files is what's needed, ill take it upto doanac and plars about it | 08:53 |
| ogra_ | thanks | 08:53 |
| === doko_ is now known as doko | ||
| doko | xnox, what is triaged in https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1015219 ? | 09:55 |
| ubottu | Ubuntu bug 1015219 in gcc-4.7 (Ubuntu Precise) "Can't install lib64stdc++6 due to unmet dependencies" [Medium,Triaged] | 09:55 |
| === iahmad is now known as iahmad|afk | ||
| xnox | 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? | 09:59 |
| === emma is now known as em | ||
| pitti | 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 |
| ubottu | bug 1244157 in apparmor (Ubuntu) ""Failed name lookup - disconnected path" in dhclient D-BUS access" [Undecided,New] https://launchpad.net/bugs/1244157 | 10:16 |
| === MacSlow is now known as MacSlow|lunch | ||
| pitti | jjohansen: ^ I bisected this to https://launchpad.net/ubuntu/+source/linux/3.11.0-12.18, so something with your patches | 10:50 |
| pitti | jibel: ^ FYI, as you were asking about the NM autopkgtest regression | 10:50 |
| juliank | 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 |
| ubottu | bug 1132918 in python-apt (Ubuntu Raring) "Ubiquity crashes after user creation" [High,Confirmed] https://launchpad.net/bugs/1132918 | 10:50 |
| cjwatson | 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 |
| cjwatson | juliank: I remember it not being at all obvious and taking a while to find | 10:51 |
| xnox | 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:53 |
| juliank | cjwatson: Thanks, that's all I need I think. APT uses sprintf() for printing, it should use snprintf. | 10:54 |
| cjwatson | juliank: Oh maybe it was et_EE.UTF-8 or something | 10:54 |
| cjwatson | I think xnox is right, there was some locale that returned non-ASCII data | 10:54 |
| cjwatson | And apt/python-apt wasn't converting it | 10:54 |
| cjwatson | sprintf/snprintf is probably a red herring | 10:54 |
| juliank | 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:56 |
| juliank | If decoding means calling decode() on it | 10:58 |
| juliank | As that method does not exist in Python 3 for str objects, only for bytes. | 10:58 |
| cjwatson | Yes I know. The relevant code is: | 10:59 |
| cjwatson | current_cps = apt_pkg.size_to_str(self.current_cps) | 10:59 |
| cjwatson | if isinstance(current_cps, bytes): | 10:59 |
| cjwatson | current_cps = current_cps.decode() | 10:59 |
| cjwatson | But it was clearly a workaround | 10:59 |
| * cjwatson tries to remember how he reproduced this | 11:00 | |
| juliank | 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:01 | |
| cjwatson | 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:03 |
| cjwatson | juliank: But it's also possible that code came from the period when we needed to deal with polyglot Python 2/3 | 11:05 |
| cjwatson | And in Python 2 I needed that to be reliably unicode | 11:06 |
| cjwatson | 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:09 |
| cjwatson | Anyhow, the decode is irrelevant, it's after the crash site in this bug | 11:10 |
| cjwatson | 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 |
| juliank | The traceback said: File "/usr/lib/python3/dist-packages/apt/progress/text.py", line 187, in pulse | 11:11 |
| cjwatson | 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:20 |
| cjwatson | (Of course you have to have the et_EE locale generated first; note that that's a non-UTF-8 locale) | 11:21 |
| doko | ScottK, is kgraphview unmaintained? I see you let it build with boost1.49 with your last upload | 11:21 |
| juliank | cjwatson: OK, that makes sense then. But then it's a Python bug, as that is decoding the string. | 11:22 |
| cjwatson | juliank: Seems more likely that there's some other function that would do the right thing | 11:23 |
| cjwatson | I mean, Python certainly *can* decode from such encodings | 11:23 |
| cjwatson | And PyUnicode_FromStringAndSize is *documented* as taking UTF-8-encoded bytes | 11:23 |
| cjwatson | So it is the wrong function to call if the data might be non-UTF-8-encoded | 11:24 |
| juliank | Seems true. | 11:24 |
| cjwatson | I don't know the C API well enough | 11:24 |
| * cjwatson drops a reproducer into the bug | 11:25 | |
| juliank | 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 |
| cjwatson | I'm not sure, I'm afraid | 11:28 |
| === Sweetsha1k is now known as Sweetshark | ||
| juliank | I don't think there's a sane way to support non-utf8 locales | 11:32 |
| === _salem is now known as salem_ | ||
| === MacSlow|lunch is now known as MacSlow | ||
| jdstrand | pitti: re bug #1244157 | 12:19 |
| ubottu | 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 |
| jdstrand | pitti: are the network manager tests running in a container? | 12:19 |
| pitti | jdstrand: no, plain VM or just plainly on my workstation | 12:19 |
| === brainwash_ is now known as brainwash | ||
| jdstrand | that's very strange since I would expect massive bug filings if dhclient didn't work in the generally case | 12:22 |
| jdstrand | s/generally/general/ | 12:22 |
| pitti | jdstrand: right, it doesn't happen with my "normal" NM either | 12:22 |
| pitti | 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 |
| jdstrand | pitti: yeah, I think we need jjohansen for this. if lxc or chroots aren't involved, then we need him | 12:23 |
| === freeflying_away is now known as freeflying | ||
| jdstrand | 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:37 |
| jdstrand | pitti (fyi jjohansen): can you update the profile to have: | 12:38 |
| jdstrand | /usr/lib/NetworkManager/nm-dhcp-client.action flags=(attach_disconnected) { ... } | 12:38 |
| pitti | jdstrand: no, we don't use chroots there; it just calls pbuilder-satisfydepends-classic to install the dependencies | 12:38 |
| jdstrand | pitti (fyi jjohansen): and try again? | 12:38 |
| * pitti sets up VM to avoid losing network | 12:39 | |
| jdstrand | pitti: where is pbuilder-satisfydepends-classic installing the dependencies if not in a chroot? | 12:40 |
| * jdstrand is not a pbuilder expert | 12:40 | |
| pitti | jdstrand: into the currently running syste | 12:40 |
| pitti | m | 12:40 |
| pitti | jdstrand: it's just a helper tool to determine a set of packages from a Depends: line | 12:41 |
| jdstrand | I see | 12:41 |
| pitti | jdstrand: but in the reproduction recipe in comment #2 there's no chroot or pbuilder involved | 12:41 |
| pitti | ok, I'm set up | 12:41 |
| jdstrand | pitti: I think adding attach_disconnected is still worthwhile as a data point | 12:41 |
| pitti | jdstrand: "sudo /etc/init.d/apparmor reload"? | 12:42 |
| jdstrand | pitti: sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient | 12:42 |
| pitti | jdstrand: oh, seems "reload" worked | 12:42 |
| jdstrand | it would too, it is just more heavy-handed | 12:43 |
| pitti | yay, so that's it | 12:43 |
| pitti | what does that flag mean? | 12:43 |
| jdstrand | 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 |
| pitti | jdstrand: oh, I'm running the tests under an unshared file system | 12:44 |
| jdstrand | 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:44 |
| pitti | jdstrand: as I'm mounting tmpfses over /run/NetworkManager and /etc/NetworkManager as to avoid disturbing/destroying files in the production system | 12:45 |
| jdstrand | ah | 12:45 |
| pitti | jdstrand: yes, currently doing that; I was just wondering because even setting the profile to "complain" didn't help | 12:45 |
| ogra_ | 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 |
| ubottu | bug 1231778 in network-manager (Ubuntu) "wifi not working on Saucy Salamander" [Medium,Confirmed] https://launchpad.net/bugs/1231778 | 12:46 |
| jdstrand | well, attach_disconnected is exactly what you want | 12:46 |
| pitti | jdstrand: the test could completely disable apparmor, but I'd rather test the whole thing as closely as possible | 12:46 |
| jdstrand | pitti: I think this is a case for another sed | 12:46 |
| pitti | jdstrand: (it'd be the first sed, but I see what you mean) | 12:47 |
| jdstrand | pitti: oh, I thought we were doing a sed on something else as of a few weeks ago | 12:47 |
| pitti | jdstrand: no, I fixed that properly in dbusmock | 12:48 |
| jdstrand | ah, right | 12:48 |
| pitti | (but that part isn't involved here; that was my first thought) | 12:48 |
| pitti | these tests run without any mocking | 12:48 |
| jdstrand | ogra_: no, that is different. no (relevant) apparmor denials in that bug | 12:48 |
| ogra_ | 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 |
| pitti | 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 |
| pitti | jdstrand: i. e. is this "invalid"/"wontfix", or still a bug and the above is a workaround? | 12:49 |
| jdstrand | jjohansen: fyi, seems that attach_disconnected is exactly what pitti needs-- he is mounting tmpfses over parts of the filesystem | 12:50 |
| jdstrand | jjohansen: I'm not sure if there is another bug there, can you comment in the bug? | 12:50 |
| pitti | jjohansen, jdstrand: not the D-BUSy parts, though; I guess it's the "unshared fs" which upsets it | 12:50 |
| jdstrand | pitti: I'm not sure | 12:50 |
| pitti | jdstrand: anyway, I followed up to the bug with a summary | 12:51 |
| jdstrand | pitti: let's leave it open for now and let jjohansen comment when he gets back | 12:51 |
| pitti | ack | 12:51 |
| jdstrand | pitti: thanks | 12:51 |
| pitti | jdstrand: thanks to you! | 12:51 |
| pitti | Ran 23 tests in 221.487s | 12:51 |
| pitti | \o/ | 12:51 |
| jdstrand | yw :) | 12:51 |
| pitti | I'll come up with some seddery for now | 12:51 |
| ogra_ | jdstrand, there is an intresting line in dmesg of that bug though ... | 12:52 |
| ogra_ | [ 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 |
| ogra_ | (and dhcp/dns is the bit not working apparently) | 12:52 |
| pitti | wow, seems ogra_ and I stumbled over two completely different problems in the very same line of a profile :) | 12:52 |
| ogra_ | heh | 12:53 |
| jdstrand | ogra_: hmm.. I have never seen that error befor | 12:53 |
| ogra_ | jdstrand, that device uses an android kernel without apparmor patches ... (but ubuntu config) | 12:53 |
| ogra_ | could that have any influence ? | 12:53 |
| ogra_ | (and no, this is lubuntu desktop, not touch) | 12:54 |
| ogra_ | :) | 12:54 |
| jdstrand | 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 |
| jdstrand | jjohansen: different issue> can you comment on backscroll between me and ogra_ going back 5 minutes from this message? | 12:56 |
| ogra_ | 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:57 |
| jdstrand | 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:58 |
| ogra_ | right, thats what i suspect | 12:59 |
| ogra_ | note that we have many (if not most) armhf users out there with such setups | 12:59 |
| jdstrand | 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 |
| ogra_ | 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:00 |
| jdstrand | 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:01 |
| ogra_ | jdstrand, 90% of these people just know how to flash their device ... | 13:02 |
| ogra_ | they always used the existing kernel binaries and an ubuntu userspace | 13:02 |
| ogra_ | (often even android binaries) | 13:02 |
| ogra_ | if we add a hard dependency on patching yoour kernel in our userspace we'll likely use that lot | 13:03 |
| jdstrand | 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 | |
| ogra_ | s/in out/to use our/ | 13:03 |
| ogra_ | jdstrand, it works fine with debian, or fedora | 13:03 |
| ogra_ | or whatever other distro they use | 13:04 |
| ogra_ | (though i guess fedora will soon cause similar issues by using systemd) | 13:04 |
| jdstrand | yep | 13:04 |
| cjwatson | doko: I'll take valadoc | 13:05 |
| pitti | cjwatson: FYI, doko and I discussed valadoc | 13:05 |
| doko | cjwatson, pitti was looking at | 13:05 |
| jdstrand | like I said, apparmor_parser should be able to handle that aiui | 13:05 |
| psivaa | pitti: ping | 13:05 |
| cjwatson | "discussed" or "is going to fix"? | 13:05 |
| cjwatson | I assume you need https://mail.gnome.org/archives/commits-list/2013-September/msg08896.html | 13:05 |
| pitti | 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 |
| cjwatson | pitti: Yes, but that didn't obviously help | 13:05 |
| doko | cjwatson, so I re-enabled libgraph again, however it looks like libcgraph and libgraph cannot co-exist in parallel anymore | 13:05 |
| pitti | cjwatson: oh, ok | 13:06 |
| cjwatson | pitti: We need to port everything, I think; it sucks but there it is | 13:06 |
| pitti | so it seems we either port the five-or-so libgraph consumers or don't build cgraph? | 13:06 |
| cjwatson | Let's just port, we already started | 13:06 |
| pitti | at least until Debian gets the new version, so that we don't have to deviate so much | 13:06 |
| pitti | cjwatson: ok | 13:06 |
| psivaa | 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 |
| cjwatson | pitti: so, OK if I cherry-pick the cgraph work from upstream? | 13:07 |
| pitti | 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 |
| cjwatson | Looks like 7b22bc146b318790552aa8ec1ece25a3a06d1316 and 0dcad4e7364c1f7c892ed0c0073a66aefa325b42 | 13:08 |
| pitti | but that's fine, we want 0.20 | 13:08 |
| pitti | psivaa: I have some three conversations and a meeting in 20 mins, after that? | 13:09 |
| psivaa | pitti: sure, thanks :) | 13:09 |
| pitti | psivaa: (or subscribe me to a bug or something) | 13:09 |
| psivaa | pitti: we have not reported any bugs but i'll try and ping you after an hour | 13:09 |
| === liam_ is now known as Guest1997 | ||
| pitti | jdstrand: added another question to the bug, perhaps you know this | 13:14 |
| plars | 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:14 |
| plars | I'll look at it some more today | 13:15 |
| ogra_ | great, thanks | 13:15 |
| pitti | plars: at least after that the crashes should have the packaging information | 13:15 |
| jdstrand | pitti: yeah, just saw it. I don't think so | 13:16 |
| jdstrand | pitti: but let's see what jj says-- there might be a bug and you might not need attach_disconnected | 13:16 |
| pitti | 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:17 |
| ev | plars: is inotify actually working on /var/crash? | 13:19 |
| ogra_ | ev, is inotify working omn bind mounted dirs ? | 13:19 |
| ogra_ | :) | 13:19 |
| ev | you tell me! :-P | 13:19 |
| * ogra_ doesnt know ... but /var/crash is a bindmount | 13:20 | |
| pitti | oh, that woudl explain it | 13:20 |
| pitti | if whoopsie starts first, sets the inotify, and *after* that you do the bind mount | 13:20 |
| pitti | that would explain why restarting whoopsie makes it work | 13:20 |
| ogra_ | the bind mount happens from mountall | 13:20 |
| pitti | as the original inotify is on an inode on the root fs | 13:20 |
| ogra_ | whoopsie surely doesnt start before mountall, does it ? | 13:21 |
| pitti | no | 13:21 |
| pitti | ok, would have been a nice explanation | 13:21 |
| pitti | ogra_: so that's not done by writable-files? | 13:22 |
| ogra_ | writable-files are processed in the initrd | 13:22 |
| ogra_ | to create an fstab | 13:22 |
| ogra_ | eth actual mounting is done by mountall processing the fstab | 13:23 |
| plars | ev: it would appear not since it needs to be restarted, but sometimes even that doesn't seem to be enough | 13:24 |
| ev | hmm | 13:26 |
| doko | 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 |
| cjwatson | doko: Can we just go back to 0ubuntu2 and port everything? | 13:36 |
| cjwatson | Fedora did that | 13:36 |
| doko | yes, we have to | 13:37 |
| xnox | stgraber: can we fix this: http://blog.bofh.it/debian/id_413 | 14:00 |
| xnox | ? | 14:00 |
| seb128 | xnox, stgraber, tedg: with the current upstart jobs, is it possible that unity-panel-service is started before dbus's session job? | 14:11 |
| seb128 | if so can we make it just start when the session bus is ready | 14:11 |
| tedg | seb128, I don't think so. | 14:11 |
| * tedg double checks | 14:11 | |
| seb128 | tedg, you don't think that it's possible... or happening or...? | 14:12 |
| tedg | seb128, No it's starting with gnome-session, which is started after dbus. | 14:12 |
| seb128 | tedg, we are getting indicators that hit g_error() code on init because there is no session bus, that's weird | 14:13 |
| tedg | 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 | |
| seb128 | tedg, what restart bug? | 14:13 |
| tedg | seb128, When upstart restarts it doesn't save the environment variables, so then tasks can't find dbus. | 14:14 |
| tedg | seb128, Looks like 0ubuntu8 is in trusty, but not saucy. | 14:14 |
| seb128 | tedg, "upstart restarts"? is that re-exec on update? | 14:14 |
| tedg | seb128, We put a recoverable error in HUD to detect it: https://errors.ubuntu.com/bucket/?id=DBusSessionAddressNotSet | 14:14 |
| charles | 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 |
| xnox | seb128: it shouldn't, but it can be sometimes. | 14:15 |
| seb128 | xnox, tedg: is somebody working on getting that upstart fix SRUed? | 14:15 |
| xnox | seb128: re-exec on update upstart itself, or any it's dependencies upgraded. you can reproduce it with $ telinit u | 14:16 |
| xnox | seb128: i dont' think that was in trusty yet. | 14:17 |
| tedg | seb128, I assume, but I haven't verified. | 14:17 |
| tedg | xnox, Oh, is that not in ubuntu8? | 14:17 |
| xnox | seb128: tedg: there is merge proposal to fix it, but that's not merged in trunk yet. | 14:17 |
| xnox | tedg: read changelog =) https://launchpad.net/ubuntu/+source/upstart/1.10-0ubuntu8 | 14:17 |
| xnox | tedg: there is no mentioning of the saving/restoring environment =)))) | 14:17 |
| tedg | xnox, Ah, I figured "super important" :-) | 14:18 |
| xnox | (serialising, deserialising and preserving evn acroos restart) | 14:18 |
| tedg | seb128, So apparently not fixed yet :-/ | 14:18 |
| xnox | tedg: ph, desktop stuff =) the host stayed up. | 14:18 |
| xnox | tedg: but yeah, it's important and jodh is working on fixing it. | 14:19 |
| seb128 | tedg, xnox: who is working on it? jodh? | 14:19 |
| seb128 | xnox, ok, thanks | 14:19 |
| xnox | seb128: tedg https://code.launchpad.net/~jamesodhunt/upstart/bug-1238078/+merge/190723 | 14:19 |
| jodh | tedg: I've fixed the issue, but we have a bit of a review backlog atm :) | 14:20 |
| * tedg can click "approve", send me links! ;-) | 14:21 | |
| cjohnston | cjwatson: when you get a chance, could you please ack my email to ubuntu-devel ref a UDS track name change? | 14:22 |
| jodh | tedg: sorry, upstart devs only :). FWIW, that is the top priority branch to be merged. | 14:23 |
| cjwatson | cjohnston: done | 14:23 |
| cjohnston | thanks :-) | 14:23 |
| cjwatson | sigh, it's unfortunate that trusty-proposed is a partial suite. I'm either going to have to make librdf-trine-perl and libtest-rdf-perl uninstallable for a publisher cycle when the rest of the perl transition is done, or else force it in a complex way | 14:24 |
| cjwatson | hm, maybe a faux package would do the job | 14:25 |
| doko | ouch, wth did I package yapgcb for? | 14:26 |
| stgraber | xnox: did you try it on Ubuntu? | 14:27 |
| stgraber | xnox: because it won't work ;) | 14:27 |
| xnox | stgraber: sounds good ;-) let me try it and see what happens. | 14:27 |
| stgraber | xnox: apparmor will prevent you from re-mounting sysfs and will prevent any write under /sys | 14:28 |
| doko | cjwatson, would you mind removing yapgvb? | 14:31 |
| cjwatson | doko: can do, just give me a reason I can type into remove-package | 14:32 |
| doko | based on libgraph, which doesn't exist anymore. last upstream 2009 | 14:32 |
| cjwatson | doko: done | 14:33 |
| doko | two left kgraphview and ggobi | 14:33 |
| cjwatson | I'm chasing the other things p-m is complaining about | 14:33 |
| === elopio_ is now known as elopio | ||
| === pete-woods1 is now known as pete-woods | ||
| saiarcot895 | When backporting a package, if the package depends on a backported package,....well, is this allowed? | 15:00 |
| xnox | saiarcot895: yes. | 15:06 |
| stgraber | cjwatson: can you rescore: https://launchpad.net/ubuntu/+source/ggobi/2.1.10-4ubuntu1/+build/5157602 | 15:12 |
| cjwatson | stgraber: done | 15:13 |
| stgraber | it looks like it'll also need some of that autoconf-dev magic to build on arm64 | 15:13 |
| === Vivek is now known as Guest6309 | ||
| cjwatson | sigh, and massif-visualizer is one of the packages that's uncopyable due to an LP bug | 15:16 |
| rbasak | pitti: I'll check | 15:16 |
| cjwatson | Hm, now proposed-migration seems to have decided that graphviz doesn't need to go in with perl, wtf | 15:30 |
| cjwatson | I guess I could decide not to care about that for now | 15:30 |
| cjwatson | Oh, no it hasn't, it's just that libgv-perl is listed as broken now | 15:31 |
| cjwatson | That'd be the connecting package | 15:31 |
| stgraber | maybe the link between graphviz and perl was one of those packages that got removed/demoted | 15:31 |
| jibel | rbasak, trusty§20131023 is on cloud-images.u.c but there is no current/ directory and image is not listed in daily simplestreams json file | 15:31 |
| jibel | trusty/20131023 | 15:31 |
| cjwatson | stgraber: No, it's just that on the last run graphviz was out of date so it didn't consider it at the output stage | 15:31 |
| cjwatson | It'll reappear next run, I expect | 15:31 |
| rbasak | jibel: I'll check with utlemming when he gets in | 15:35 |
| jibel | rbasak, thanks! Also can you check with him to bring jenkins node ec2-tester back to life? | 15:37 |
| rbasak | Will do | 15:39 |
| mardy | thomi: hi! I'm having some trouble with autopilot, which seems has to do with the D-Bus timeout | 15:42 |
| mardy | thomi: how long is it by default? is it possible to extend it (maybe with some env variable)? | 15:42 |
| cjwatson | ok, working around the massif-visualizer problem | 15:46 |
| borg_ | Hi, the python-qwt5-qt4 package in the current saucy repository is broken. It results in an immediate segfault if used. | 16:21 |
| borg_ | I am pretty sure that there was just some kind of fault while the package was build. | 16:21 |
| borg_ | i rebuild the package from source and it works | 16:21 |
| borg_ | https://bugs.launchpad.net/ubuntu/+source/pyqwt5/+bug/1243102 (see last comment) | 16:21 |
| ubottu | Ubuntu bug 1243102 in pyqwt5 (Ubuntu) "python-qwt5-qt4 segfaults immediately in saucy" [Undecided,New] | 16:21 |
| borg_ | who can i contact to rebuild and reupload the package? | 16:21 |
| xnox | borg_: assigned to ScottK, he is the last one to touch the package, and should now if that is the case and how to deal with it. | 16:29 |
| borg_ | thx | 16:30 |
| infinity | shadeslayer: Can you re-do that grub2-signed SRU without the trusty changelog entry in there? | 17:12 |
| shadeslayer | infinity: sure | 17:12 |
| shadeslayer | Riddell: ^^ still around to upload that for me? | 17:13 |
| Riddell | infinity: shadeslayer: doing | 17:13 |
| shadeslayer | cool | 17:14 |
| infinity | Riddell: Also, please don't set Fix Committed on SRU bugs when you upload something. | 17:19 |
| infinity | Riddell: In Progress is fine, but we use Fix Committed to mean we've actually accepted it to -proposed. | 17:19 |
| Riddell | infinity: I know sorry I think I got confused on which was in -proposed | 17:20 |
| rbasak | pitti, jibel: utlemming is working on it and expects to have something by EOD. Apparently we're not used to having customers this early in the cycle :) | 17:25 |
| slangasek | Mirv: so in the authoritative configuration, the autopilot tests are being executed via phablet-test-run, connected how? adb? | 17:58 |
| seb128 | bdmurray, there? I'm not sure what to do with software-properties to re-inject the version you didn't commit | 17:59 |
| infinity | ricotz: Known bug in 1.0.10, fixed in 1.0.11. On the other hand, 1.0.10 is only in proposed, so the right answer here is in the form of a question: "Why are you running proposed?" | 17:59 |
| seb128 | I wonder if I should uncommit my update, push --overwrite, commit yours and redo mine on top of it | 18:00 |
| seb128 | I don't like much uncommit/overwrite though | 18:00 |
| infinity | seb128: Just fix the changelog and commit? Unless you're concerned about tags being sane too. | 18:00 |
| seb128 | infinity, I would prefer tags to match uploads yes | 18:00 |
| infinity | If I were you, I'd just suffer with his upload being untagged. But your VCS, your call. :P | 18:01 |
| * seb128 shakes fist at people not using the vcs | 18:01 | |
| slangasek | seb128: branch from last common revision; commit bdmurray's changes on new branch and tag; merge that branch into your trunk | 18:01 |
| infinity | seb128: Or, I can just accept your rejected upload, and then your tags will match, and his will just appear to have never happened. | 18:01 |
| slangasek | oh, what you have committed in the VCS doesn't match the archive? | 18:02 |
| seb128 | slangasek, well, trunk has a tag for a version that got rejected now | 18:02 |
| seb128 | so that tag is buggy as well | 18:02 |
| seb128 | infinity, I start thinking that's easier | 18:02 |
| slangasek | right | 18:02 |
| infinity | seb128: Yeah, I'll just do that, and you can pretend none of this ever happened. | 18:02 |
| seb128 | slangasek, it matches my upload to saucy-proposed that Daviey rejected because there was one of bdmurray already in there (which was lower number/not in the vcs) | 18:02 |
| seb128 | infinity, thanks | 18:03 |
| slangasek | gotcha | 18:03 |
| seb128 | infinity, slangasek: thanks | 18:03 |
| infinity | seb128: Done. | 18:04 |
| seb128 | infinity, thanks | 18:04 |
| bdmurray | seb128: sorry about that | 18:04 |
| seb128 | bdmurray, no worry | 18:05 |
| robru | ogra_, ping? can I get you to seed webbrowser-app for trusty? https://code.launchpad.net/~robru/ubuntu-seeds/ubuntu.trusty/+merge/192564 | 18:35 |
| xnox | robru: have the extra dependencies that that pulls in been dropped? | 18:38 |
| xnox | robru: specifically those that get pulled in by qtmultimedia? | 18:38 |
| robru | xnox, i thought so? did mirv not get his updated qtmultimedia in? | 18:39 |
| robru | xnox, if this isn't in, can somebody sponsor it? https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/qtmultimedia-opensource-src_5.0.2 | 18:39 |
| xnox | robru: no it hasn't yet. | 18:40 |
| robru | xnox, well can you sponsor/upload it please? it's ready to go | 18:41 |
| xnox | robru: please wait until that branch is actually uploaded, built in -proposed and migrated to -release. Only then the seed change can go it. | 18:41 |
| xnox | s/it/in/ | 18:41 |
| robru | xnox, so you're not going to upload it then? i don't have upload rights | 18:42 |
| xnox | robru: Mirv didn't request that branch to be properly sponsored. Therefore it didn't appear on any sponsorship queues/reports and none of the sponsors patch pilots looked at it. | 18:49 |
| xnox | robru: so it hasn't landed yet | 18:50 |
| xnox | robru: i openend the task agaisnt qtmultimedia, linked the branched to the bug, made merge-proposal into the default packaging branch, subscribed ubuntu sponsors on the bug report. | 18:50 |
| xnox | robru: soon it should appear on http://reqorts.qa.ubuntu.com/reports/sponsoring/ | 18:50 |
| robru | xnox, thanks | 18:50 |
| xnox | robru: and then one of the sponsors will look into it in due course. I am extremely busy at the moment, and can't look into it. | 18:51 |
| xnox | robru: once qtmultimedia task is "Fix released" then webapps seed proposal can be made. And you should request "ubuntu-core-dev" to review it, then it will also end up on the above sponsorship report to be merged/sponsored. | 18:51 |
| Noskcaj | mdeslaur, | 19:04 |
| Noskcaj | https://code.launchpad.net/~noskcaj/ubuntu/trusty/tiff/tiff/+merge/192569 | 19:04 |
| mdeslaur | Noskcaj: thanks, I'll take a look at it tomorrow | 19:05 |
| Noskcaj | :) | 19:05 |
| Noskcaj | Has anyone looked at bug 1234612 ? | 19:19 |
| ubottu | bug 1234612 in memtest86+ (Ubuntu) "Please update memtest86+ to the latest 5.0.x release - memtest86 in Ubuntu 13.10 is 2 years old (v4.2.0)!" [Undecided,Confirmed] https://launchpad.net/bugs/1234612 | 19:19 |
| cjwatson | Noskcaj: level of interest in touching that at all without the Debian maintainer taking it very low indeed | 19:43 |
| Noskcaj | cjwatson, not suprising. I've emailed the debian maintainer and will let everyone know if i get a reply | 19:44 |
| * cjwatson leaves a bug comment to that effect | 19:44 | |
| cjwatson | Noskcaj: why e-mail directly, rather than filing a Debian bug? | 19:44 |
| cjwatson | no obvious need for privacy here | 19:44 |
| Noskcaj | will do now | 19:44 |
| === liam_ is now known as Guest32295 | ||
| === salem_ is now known as _salem | ||
| seb128 | infinity, can you get the gnome-settings-daemon saucy SRU that is in the queue in? it fixes those keyboard problems a bit harder than the version in proposed is | 20:41 |
| infinity | seb128: With extra gusto? :P | 20:42 |
| infinity | ERROR: Queue has more than one upload of this source, please handle manually | 20:42 |
| * infinity sighs and goes to look. | 20:42 | |
| seb128 | infinity, both are from me, you can reject the older one | 20:43 |
| seb128 | the new one includes the 3 changelog entries | 20:44 |
| sarnold | https://launchpad.net/bugs/1243969 has me confused how to proceed; flightgear needs an update. the reporter who provided a debdiff claims that archive flightgear can't rebuild against archive simgear because of a change in simgear made _after_ the flightgear package was built. flightgear now FTBFS as a result of the change in simgear. | 23:45 |
| ubottu | Ubuntu bug 1243969 in simgear (Ubuntu) "buffer overrun through UDP input" [Undecided,Confirmed] | 23:45 |
| sarnold | what's the next steps? get someone else to fix the ftbfs in an sru so that the security fix would then be small? or try to fix the ftbfs in the security update directly? | 23:47 |
| infinity | sarnold: Fix the FTBFS in the security update, it doesn't make sense to do two uploads just to keep them isolated. | 23:47 |
| sarnold | (does anyone know flightgear well enough to just say "add -lpthread to CFLAGS" or "do not under any circumstance try flightgear with threading"?) | 23:47 |
| infinity | sarnold: Do you have a failed build log? | 23:48 |
| sarnold | infinity: no, not yet | 23:48 |
| * infinity gives it a whirl. | 23:48 | |
| * infinity gives is a very slow whirl... | 23:52 | |
| infinity | That's a lot of build-deps. | 23:52 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!