| straemer | Hey, I'm trying to build ubuntuone-android-music, and am getting a build error | 00:24 |
|---|---|---|
| straemer | BUILD FAILED | 00:24 |
| straemer | /home/stephen/.android-sdk-linux/tools/ant/build.xml:574: ../../ubuntuone-android-sso/ubuntuone-android-sso resolve to a path with no project.properties file for project /home/stephen/Programs/ubuntuone-android-music | 00:24 |
| === echeve is now known as echevemaster | ||
| dobey | xnox: software-center pkg import has been broken for quite some time. | 00:43 |
| === lifeless_ is now known as lifeless | ||
| === achiang` is now known as achiang | ||
| kenvandine | @pilot out | 00:56 |
| === udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| fdfdfd | HI ALL | 01:33 |
| fdfdfd | anyone here | 01:33 |
| sarnold | fdfdfd: 300+ .. though who is awake and around may vary. | 01:34 |
| fdfdfd | sarno;d may i quayr you please it a lot earier for me | 01:35 |
| sarnold | fdfdfd: it'd be best to ask questions in the channel, that way other people can learn, or correct me if I'm wrong :) | 01:36 |
| === Guest63061 is now known as StevenK | ||
| === _salem is now known as salem_ | ||
| fdfdfd | i got a quick question sence i reinstall windows xp on to my computer will and from linux be on my computer now | 02:43 |
| fdfdfd | STILL | 02:43 |
| fdfdfd | opps caps on still LOL | 02:43 |
| fdfdfd | sorry | 02:43 |
| straemer | fdfdfd: I think you want the #ubuntu channel | 02:44 |
| fdfdfd | ths is unbuntu channle | 02:44 |
| straemer | no, this is #ubuntu-devel | 02:44 |
| fdfdfd | you cant get help from here | 02:45 |
| straemer | well the ubuntu channel is dedicated to support, so you'd have better luck there | 02:46 |
| fdfdfd | in this room youall just caht about bull s **** | 02:47 |
| fdfdfd | and talk about what ever | 02:49 |
| fdfdfd | ok thank you streamer | 02:49 |
| pitti | Good morning | 03:52 |
| === salem_ is now known as _salem | ||
| mlankhorst | gday! | 05:44 |
| === FlannelKing is now known as Flannel | ||
| dholbach | good morning | 06:30 |
| caribou | slangasek: infinity: thanks for expediting the rsyslog regression fix | 06:40 |
| jdoles | How can I backport a package? | 06:42 |
| maxb | jdoles: Need more context - to build locally, to build in a PPA, or the process for getting something into raring-backports etc. | 06:48 |
| jdoles | maxb: locally | 06:49 |
| Versable | Hey, vala troubles | 06:50 |
| Versable | Package `webkitgtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories | 06:50 |
| Versable | I know to cp webkit-1.0.vapi to webkitgtk-3.0.vapi and webkit-1.0.deps to webkitgtk-3.0.deps | 06:50 |
| Versable | But I am trying to package, what's the workaround | 06:50 |
| jdoles | maxb: I installed backportpackage, but that doesn't do anything useful when used in the obvious way. | 06:50 |
| maxb | jdoles: Well, that's a very very broad question. It's easy to answer "modify the package source appropriately and build it", but that's not very helpful to you | 06:50 |
| maxb | Ah, you mean in reference to a specific helper scirpt | 06:51 |
| jdoles | maxb: https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport | 06:51 |
| jdoles | maxb: I am just following instructions. | 06:51 |
| jdoles | maxb: and they don't work. | 06:51 |
| maxb | I think they work, they just aren't as detailed as you'd like | 06:52 |
| jdoles | maxb: I don't see why I can't just run a tool which downloads the right source package, drops me in a directory where I can run make buildpackage and then get a deb out. | 06:52 |
| jdoles | maxb: as detailed? The program tells me that I need to specify an upload target or something else. | 06:53 |
| jdoles | maxb: both options are not applicable. | 06:53 |
| jdoles | maxb: hence, the program has a bug. | 06:53 |
| jdoles | maxb: since the wiki is wrong, I ask here. | 06:53 |
| maxb | I get that you're frustrated, but it doesn't help to claim the instructions are wrong when they're not | 06:56 |
| maxb | They identify a specific helper script, with the expectation that users will refer to its help and/or manpage | 06:57 |
| jdoles | Usage: backportpackage [options] <source package name or .dsc URL/file> | 06:57 |
| jdoles | Source package name: I choose bc. | 06:58 |
| jdoles | backportpackage bc | 06:58 |
| jdoles | backportpackage: error: Please specify either a working dir or an upload target! | 06:58 |
| jdoles | Documentation is simply wrong. | 06:58 |
| jdoles | maxb: why do you make up excuses? | 06:58 |
| maxb | So now you actually go read the help message and specify one of those things (-w or -u options) | 06:58 |
| jdoles | maxb: it's -U | 06:59 |
| maxb | No it isn't | 06:59 |
| jdoles | maxb: and the USAGE doesn't say I need to specify it. | 06:59 |
| jdoles | maxb: ok, so indeed it's -u, but still irrelevant. | 06:59 |
| jdoles | maxb: so, whoever wrote USAGE was plain unambiguously WRONG. | 07:00 |
| jdoles | maxb: you should talk to whoever wrote that script, because it wastes the time of people. | 07:00 |
| jdoles | maxb: you should *not* point at me saying that I did something wrong. | 07:00 |
| maxb | You say "wrong" I say "omitted a small detail which you easily discover via a reasonably helpful error message on first use" | 07:01 |
| jdoles | I frankly don't get why you even endorse such broken programs. | 07:01 |
| jdoles | But then again, you also developed Unity. | 07:01 |
| maxb | I frankly don't get why you seem to think it's worth typing this diatribe. | 07:01 |
| jdoles | maxb: the error message is *not* helpful. | 07:02 |
| * maxb stops feeding the troll | 07:02 | |
| jdoles | maxb: I have no idea what to do, because I matched the required inputs. | 07:02 |
| jdoles | maxb: I read USAGE, gave valid values and the program returns an error. | 07:02 |
| jdoles | That means that the problem is on the side of the author of said program. | 07:03 |
| Versable | Ouch | 07:04 |
| jdoles | I am now doing it via a different method, a less high-level approach such that I don't need to work with this broken sh*t. | 07:04 |
| * maxb wonders if ubuntu-dev-tools really needs to recommend debian-keyring (what with it being a 42MB .deb) | 07:06 | |
| jdoles | I managed to get the broken program to sort of work, but I don't want to upload anything. | 07:06 |
| jdoles | maxb: yes, it does. | 07:06 |
| maxb | Hmm, Move debian-keyring from Suggests to Recommends (LP: #717245) | 07:08 |
| ubottu | Launchpad bug 717245 in ubuntu-dev-tools (Ubuntu) "[pull-debian-source] Please recommend debian-keyrings" [Wishlist,Fix released] https://launchpad.net/bugs/717245 | 07:08 |
| pitti | yolanda: FYI, the squid3 autopkgtest keeps timing out; it's accessing some network sites, which mostly doesn't work from the DC | 07:12 |
| pitti | yolanda: would be better to rewrite it using a local apache/ftp server or something like that | 07:13 |
| yolanda | hi pitti | 07:13 |
| yolanda | ok, i'll take a look | 07:13 |
| pitti | yolanda: accessing www.ubuntu.com is probably okay (jibel?), but not the more elaborate stuff | 07:13 |
| yolanda | pitti, i just took the code from QA there, is ok if i modify that only in the package then? | 07:14 |
| pitti | yolanda: sure | 07:15 |
| === mmrazik is now known as mmrazik|afk | ||
| pitti | yolanda: I guess it's still worth keeping the current tests somewhere, though | 07:15 |
| pitti | they can run on a local box without a restrictive firewall/proxy in front of it | 07:15 |
| pitti | and with that it's more useful for actually testing security updates and the like | 07:15 |
| jibel | yolanda, *.ubuntu.com, *.canonical.com, *.launchpad.net and few others are ok | 07:17 |
| yolanda | great | 07:17 |
| pitti | jibel: but only http, right? | 07:18 |
| pitti | the test also uses ftp and perhaps other | 07:18 |
| pitti | s | 07:18 |
| jibel | pitti, right http and https. I used ftp and smb servers inside the lab for JDK testing, we could setup one for autopkgtest | 07:23 |
| === davidcalle_ is now known as davidcalle | ||
| === Guest9557 is now known as Lutin | ||
| yolanda | jibel, pitti, so it's better to enable ftp and leave the tests like that? | 07:33 |
| yolanda | the other tests under http or https are just under ubuntu.com | 07:34 |
| pitti | yolanda: the ftp or some other test makes the whole test hang forever, and adt kills it | 07:34 |
| pitti | I can't say for sure as I don't get logs from these | 07:34 |
| === mmrazik|afk is now known as mmrazik | ||
| yolanda | mm, how can we confirm it? | 07:35 |
| pitti | yolanda: I'll try running it in the DC, to see what's hanging | 07:36 |
| yolanda | ok | 07:38 |
| pitti | yolanda: oh, I get http://paste.ubuntu.com/5738082/ | 07:53 |
| pitti | yolanda: I'm not sure why the test is hanging forever, that seems to be a bug in our adt scripts | 07:53 |
| yolanda | pitti, and you also get this error locally? | 07:54 |
| pitti | yes, I do | 07:54 |
| pitti | and the hang, too | 07:54 |
| pitti | run-adt-test -s squid3 | 07:55 |
| pitti | /etc/init.d/squid3 ← this doesn't exist | 07:56 |
| pitti | yolanda: ah, it was converted to an upstart script, so the tests need to be adjusted to use "start squid3" and the like | 07:56 |
| pitti | yolanda: I'll check why run-adt-test hangs forever in the meantime, ok? | 07:56 |
| yolanda | mm, i tested that locally before pushing anything and that worked, is that a recent change? | 07:56 |
| yolanda | ok | 07:57 |
| pitti | I was fairly sure I tested it as well (always do when sponsoring) | 07:57 |
| pitti | I don't see it as a recent change | 07:57 |
| yolanda | i'll test it again | 07:57 |
| sil2100 | jamesh: ping | 08:20 |
| jamesh | sil2100: pong | 08:20 |
| === mmrazik is now known as mmrazik|ofp | ||
| === mmrazik|ofp is now known as mmrazik | ||
| === ckpringle_ is now known as ckpringle | ||
| ogra | hmm, is /etc/fstab.d supposed to work ? | 09:17 |
| * ogra sees it in saucy, but files i put there done seem to be respected at all | 09:18 | |
| ogra | oh, upstream removed it from mount .... how helpful | 09:19 |
| pitti | removed? perhaps it's in a less ancient util-linux? | 09:19 |
| ogra | sadly it has no reference to the discussion http://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fstab-d | 09:21 |
| ogra | the answer is from 2012 ... i dont really want to roll back that far :) | 09:21 |
| ogra | (on the phone where we ship fstab snippets it would be extremely helpful to have it working) | 09:22 |
| xnox | dobey: lp:ubuntu/software-center is now up to date. | 09:23 |
| apw | pitti, yo ... we have a boot speed regression and we think udevd is to blame | 09:34 |
| apw | pitti, (the systemd version) ... having poked it a bit the initrd seems to have bloated by likr 14Mb | 09:34 |
| pitti | apw: oh? it's actually supposed to be faster now, as it drops all those external programs | 09:35 |
| apw | pitti, 16104k freed -> 30508k freed | 09:35 |
| apw | pitti, yeah i don't doubt it is quicker in the real world but the initrd has become massive and loading and unpacking it is eating a lot more time | 09:35 |
| apw | pitti, i am assuming it is not meant to be 14M of new code | 09:36 |
| pitti | apw: certainly not | 09:36 |
| pitti | sounds like a new dependency crept in or so | 09:36 |
| apw | in better news, QAs boot charts found it, in not so better news we only noticed the regression by luck | 09:36 |
| pitti | I'm still fighting with vala, will look after that | 09:37 |
| apw | pitti, oh and i think it may have gotten a bit better a couple of days ago | 09:37 |
| apw | pitti, will confirm for you | 09:37 |
| xnox | apw: where are the bootcharts? | 09:37 |
| apw | xnox, reports.qa.ubuntu.com, and hit the Bootspeed tab | 09:39 |
| apw | pitti, ok confirmed, two days back it dropped back from 30m to 23m which has recovered about 1/2 the regression | 09:39 |
| pitti | hm, 202-0ubuntu10 was the last thing to really change the initramfs, but that was from May 29 already | 09:41 |
| pitti | apw: anyway, I'll dissect the initramfses and compare | 09:41 |
| apw | pitti, i have both here, so while you are looking at vala, i'll see what i can see | 09:41 |
| pitti | apw: indeed, my initrd.img-3.9.0-2-generic is 31 MB, initrd.img-3.9.0-3-generic is 23 | 09:47 |
| pitti | initrd.img-3.9.0-2-generic is from May 28, thus before udev 202-0ubuntu10 | 09:47 |
| apw | pitti, that was the shrink which gives us back half of it | 09:47 |
| pitti | apw: 14 MB was from raring? | 09:48 |
| apw | pitti, hmm that is hard to tell with qa's stuff | 09:49 |
| xnox | apw: so in my -2, there is icu added, which was an unwanted temporary dependancy of harfbuzz & pango. But that was fixed. (harfbuzz build without icu) | 09:49 |
| pitti | apw: filed bug 1188108 to track, FYI | 09:49 |
| ubottu | bug 1188108 in systemd (Ubuntu) "saucy initramfs ballooned, causing bootspeed regression" [Undecided,New] https://launchpad.net/bugs/1188108 | 09:49 |
| apw | pitti, thanks | 09:49 |
| xnox | apw: the regression was noted by d-i team, since sudently icu-udebs were required. | 09:49 |
| apw | xnox, yeah ... good | 09:50 |
| xnox | 1/2 the regression is revert of extra icu baggage. | 09:50 |
| xnox | (recovery)?! | 09:50 |
| xnox | cause icudata is ~19MB unpacked. | 09:51 |
| apw | pitti, oh yeah so locally my 16M ones are raring yes, so that is likely true for QA | 09:51 |
| apw | pitti, so ... we have an initial delta 16->30 from raring->saucy, and 30->23 from fixing icu | 09:51 |
| apw | ugg | 09:51 |
| pitti | $ diff -Nur <(zcat initrd.img-3.9.0-2-generic | cpio -t | sort -u | sed 's/3.9.0-2/3.9.0-3/') <(zcat initrd.img-3.9.0-3-generic | cpio -t | sort -u) | 09:53 |
| pitti | indeed, that's the removal of icu and libstdc++.so.6 | 09:53 |
| pitti | but it added +usr/lib/x86_64-linux-gnu/libgraphite2.so.3 | 09:53 |
| apw | pitti, by the looks of it we have a heap more kernel modules in the new ones, like possibly all of them | 09:54 |
| pitti | apw: I think libgraphite2-3 is a dep of libharfbuzz0a is a dep of libpangoft2-1.0-0 is a dep of plymouth | 09:54 |
| apw | pitti, i think we have a modules issue primarily | 09:55 |
| pitti | so at least there isn't anything udev-ish between -2 and -3 | 09:55 |
| pitti | apw: yeah | 09:55 |
| apw | 5.2MAc/lib/modules | 09:57 |
| apw | 31MBc/lib/modules | 09:57 |
| apw | pitti, not good | 09:57 |
| apw | pitti, so not all of them, but a heck of a lot more of them | 09:57 |
| pitti | apw: so is that due to udev somehow? | 09:58 |
| apw | pitti, seems unlikely to me | 09:58 |
| apw | pitti, you were fingered cause the one which was small was udev, and the one which was big was systemd-udev, but actually that might be raring -> saucy cut over .. | 09:59 |
| apw | pitti, let me poke it for a bit, and update the bug while you vala yourself to death | 10:00 |
| pitti | heh; effing buildds.. | 10:00 |
| apw | what did the eff ever do to you :) | 10:01 |
| pitti | not reproduce in sbuild or debuild | 10:03 |
| pitti | so I keep banging new versions onto the buildds until they submit | 10:03 |
| apw | pitti, so if i rebuild an old kernel it expands, kmod, initramfs-tools and the kernel (in that case) are all identicle ... this is going to be 'fun' | 10:11 |
| apw | pitti, ok my 16M ones are actuall made with MODULES=dep in /etc/initramfs-tools/initramfs.conf | 10:14 |
| apw | pitti, can you confirm whether you have like /etc/initramfs-tools/initramfs.conf.dpkg-old on the machine you checked | 10:14 |
| apw | pitti, as my other raring machine they are all 31M | 10:14 |
| apw | pitti, did your machine by any chance have the kmod stuff installed on it, the early kmod testing we did | 10:17 |
| apw | pitti, and the problem with that is i cannot account for how the initrd on a virgin install would be 16M on raring | 10:19 |
| apw | (in the QA scenario | 10:19 |
| pitti | apw: re | 10:20 |
| pitti | so with "if i rebuild an old kernel it expands,.." you mean that if you build raring's kernel in current saucy you get a big (23 MB) or small (16 MB) initrd? | 10:21 |
| apw | pitti, i get a 23 M one now indeed | 10:21 |
| pitti | apw: ok, so it's not the new kernel then | 10:21 |
| apw | pitti, and that is because i got a new initramfs-tools, which switched my conf from =dep to =most | 10:21 |
| apw | pitti, now that was cause i had a test kmod one on, on this other machine i have it was =most all the time, and is 30M for raring as well | 10:22 |
| pitti | /usr/sbin/mkinitramfs:# MODULES=most is default | 10:22 |
| pitti | /usr/sbin/mkinitramfs:echo "W: mkinitramfs: Falling back to MODULES=most." | 10:22 |
| apw | pitti, so the confusing thing is how this test box was _ever_ 16M | 10:22 |
| apw | pitti, right ... i know, and that worries me about the machine which did the testing | 10:22 |
| apw | pitti, in reality i think we have had 31M initrd's for raring, and your recent fix for ics has made it 23, win | 10:22 |
| apw | and there is no regression, but i am going to chat to QA to confirm the older results | 10:23 |
| apw | pitti, but you have a 16M one as well and want to confirm you got that with =dep somehow | 10:23 |
| pitti | on that note, what happened to the really useful automatic creation of initramfs .bak files by update-initramfs ? | 10:23 |
| apw | that your machine is a poor example as mine is | 10:23 |
| pitti | apw: 9554231 Jun 6 12:23 initrd.img-3.9.0-3-generic | 10:24 |
| apw | pitti, i don't recall ever seeing those, though it does sound useful | 10:24 |
| pitti | that's with "dep" in /etc/initramfs-tools/initramfs.conf | 10:24 |
| pitti | but I just changed that | 10:24 |
| apw | yep so nice and small | 10:24 |
| pitti | apw: I didn't have a 16 MB one on my machine; it's all saucy | 10:24 |
| pitti | apw: I was just quoting your number | 10:24 |
| apw | ok, so 16M in the bug, was my number, ok, so that is a false number, just happening to match nearly exactly QAs | 10:24 |
| apw | but i am now suspicious of | 10:25 |
| pitti | apw: so either /etc/initramfs-tools/initramfs.conf really had "dep" at some point, or someone poked that into the QA machine? | 10:25 |
| apw | their number ... right ... so ... off to qa to ask | 10:25 |
| pitti | apw: you had manually configured that as well? | 10:25 |
| apw | pitti, yeah seemingly when i was doing the kmod testing | 10:25 |
| apw | i probabally change it to confirm i had done the right thing in the merge i did for initramfs tools for that | 10:25 |
| apw | (one we didn't use in the end) and tested both modes, and left it in the wrong one, sigh | 10:25 |
| pitti | well, "dep" doesn't seem exactly "wrong", but it might indeed not be enough if you use root on a network fs | 10:27 |
| pitti | (but yuck) | 10:27 |
| pitti | having all those HID and network drivers in initramfs seems like a waste | 10:27 |
| pitti | at least if update-initramfs sees that the root fs is on a local disk | 10:27 |
| apw | pitti, is is so concidentally similar (the size in the testing) and the size my machine has for =dep that i am deeply suspicious of the results on this machine | 10:28 |
| apw | pitti, yeah this is the disk portability problem, i have long argued (and probabally should implement) that we should build two, one thin (=dep) and one fat (=most) and use the thin for 'normal' boots and 'fat' for recovery | 10:28 |
| apw | so you can recover in a disk moved to different h/w scenario | 10:29 |
| pitti | apw: I was just speaking about the network drivers, but indeed we could downsize the block drivers, too | 10:30 |
| apw | pitti, ahh i see what you mean, make the decision that the disk is only portable as a disk | 10:36 |
| apw | which makes a lot more sense | 10:36 |
| pitti | apw: I was thinking to not include any network stuff if your root dev is on any /dev/ | 10:36 |
| pitti | as opposed to some nfs device or so | 10:36 |
| apw | pitti, yeah i think that makes sense, and doesn't break the main point, unscrew disk move to new machine screw in disk | 10:37 |
| pitti | (I have no idea how that would look like; the whole idea of having your system partition on a network device seems crazy and utterly slow to me) | 10:37 |
| pitti | apw: yes, I fully support having at least the most common disk drivers in the initramfs | 10:37 |
| pitti | lib/firmware/matrox/g200_warp.fw | 10:38 |
| pitti | lib/firmware/r128/r128_cce.bin | 10:38 |
| pitti | lib/firmware/radeon/PITCAIRN_mc.bin | 10:38 |
| pitti | wow, we have a lot of stuff in our initramfs | 10:38 |
| pitti | (for KMS, I guess) | 10:39 |
| pitti | apw: so we ship 9.9 MB of network drivers | 10:42 |
| pitti | that's a third of the size of drivers/net | 10:42 |
| === mmrazik is now known as mmrazik|lunch | ||
| === MacSlow is now known as MacSlow|lunch | ||
| hrw | does someone here use saucy? pulseaudio (in pauvcontrol) lists no sound cards | 11:22 |
| xnox | does for me on saucy/amd64 | 11:26 |
| hrw | xnox: saucy/amd64 here as well but no cards ;( | 11:27 |
| hrw | xnox: heh.. I am not in audio group | 11:29 |
| ogra | hrw, the audio group shouldnt be used unless you dont use a DM | 11:35 |
| ogra | i assume there is a bug in systemd-logind | 11:35 |
| ogra | (or in pluse talking to it) | 11:35 |
| hrw | ogra: DM? | 11:35 |
| zul | cjwatson: ping is it possible for you to de-binary new python3-mimeparse please? | 11:35 |
| ogra | displa/login manager | 11:35 |
| hrw | ah | 11:35 |
| hrw | ogra: kdm is broken, lightdm+kde-greeter not yet work for me - working on it now | 11:36 |
| === mmrazik|lunch is now known as mmrazik | ||
| cjwatson | zul: done | 11:41 |
| zul | cjwatson: thanks | 11:41 |
| === hrww is now known as hrw | ||
| === seb128_ is now known as seb128 | ||
| === doko_ is now known as doko | ||
| === Mez_ is now known as Mez | ||
| ogra | so i have this upstart job http://paste.ubuntu.com/5738554/ | 12:04 |
| alexbligh1 | If a package I am installing requires the en_GB locale to be installed (always), then should it Depend: on language-pack-en or language-pack-en-base? | 12:05 |
| ogra | it doesnt start on boot at all, even though syslog shows | 12:05 |
| ogra | Jun 6 12:00:11 ubuntu-phablet upstart-file-bridge[460]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofon | 12:05 |
| ogra | does anyone have an idea why ? | 12:05 |
| ogra | the file is there (and the syslog entry actually reacts to it) | 12:05 |
| ogra | running "start ofono" manually works fine too | 12:06 |
| ogra | i have the feeling that "on started dbus" doesnt do what it should | 12:08 |
| xnox | ogra: can you increase debugging, to get the full log of all events? that way it should be easier to see why it's not starting. | 12:21 |
| ogra | hmm | 12:22 |
| xnox | add "--debug" to kernel command-line | 12:22 |
| ogra | that needs cmdline changes | 12:22 |
| ogra | thats fiddly | 12:22 |
| xnox | or add a very early job to "exec initctl log-priority debug" | 12:23 |
| ogra | ah, it seems the file i wait for is created twice in a row | 12:24 |
| ogra | (which is weird | 12:24 |
| ogra | ) | 12:24 |
| xnox | start on (starting file-bridege and starting dbus) or something like that. | 12:24 |
| ogra | additionally to file FILE= ? | 12:25 |
| xnox | upstart-file-bridge emits event if the file added event, and then again if it's changed/added/removed. | 12:25 |
| xnox | ogra: no, that was start on condition for a job that does "initctl log-priority" tweak. | 12:25 |
| ogra | oh, i could look for the added event | 12:25 |
| xnox | ogra: yeah, so there is FILE= which is path to file and EVENT= which is create|modify|delete | 12:26 |
| ogra | right ... | 12:27 |
| === MacSlow|lunch is now known as MacSlow | ||
| ogra | i'm not 100% that i dont have a dangling file there before it gets newly created | 12:27 |
| ogra | so lets see if that helps | 12:27 |
| ogra | sigh ... | 12:28 |
| ogra | if rebooting would only work reliably | 12:28 |
| xnox | ogra: does /dev/socket exist when file-bridge starts? see limitations on recursive inotify watches in upstart-file-bridge manpages.... | 12:28 |
| ogra | oh, it might not | 12:29 |
| ogra | not sure when the file bridge starts, let me take a look | 12:29 |
| ogra | ah. well, "emits file" | 12:30 |
| ogra | so i should be starting before it | 12:30 |
| ogra | *shouldnt | 12:30 |
| ogra | sigh | 12:31 |
| ogra | so now i see it starting and then stopping | 12:31 |
| xnox | ogra: did "stopping dbus" kick in?! | 12:31 |
| ogra | i dont see why it woould on boot | 12:32 |
| ogra | i removed it | 12:32 |
| ogra | heh, now it doesnt start at all | 12:32 |
| * xnox is not sure why you have "stop on stopping dbus" there at all though. | 12:32 | |
| ogra | because ofonod needs dbus | 12:33 |
| ogra | if thats gone we want to go away as well | 12:34 |
| xnox | ogra: but when dbus comes back, ofono will not come back. | 12:34 |
| ogra | thats true for the file too ... i added a stop sequence for it | 12:34 |
| xnox | ogra: since a file event for the socket will not be emitted ever again. | 12:34 |
| ogra | let me drop the on stop line | 12:35 |
| ogra | hmm, nope | 12:36 |
| ogra | doesnt start at all anymore | 12:36 |
| ogra | even if it cant find dbus it should just respawn ... i dont see it doing that either | 12:37 |
| ogra | all i get is | 12:38 |
| ogra | Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/ofono | 12:38 |
| ogra | Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/ofono | 12:38 |
| ogra | Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono | 12:38 |
| ogra | Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono | 12:38 |
| ogra | why does it have that "_2fdata_2fubuntu/ofono"! thing there ? | 12:38 |
| xnox | ogra: i really want "--debug" output from upstart =) can you divert init -> init.real and make init a shell script "/sbin/init.real --debug" ? | 12:39 |
| ogra | well, let me fiddle with the cmdline | 12:39 |
| ogra | just takes a bit | 12:39 |
| === greyback is now known as greyback|food | ||
| xnox | ogra: above are just funny upstart-file-bridge logs which are "things that file-bridge is tracking / watching / emited / finished dealing with" | 12:40 |
| ogra | well, i dont get why there seems to be a proper "ofono" job but also the two others | 12:40 |
| * ogra wonders why pastebinit hangs | 12:42 | |
| ogra | ah, well, 200000 lines was probably a bit much | 12:44 |
| ogra | http://paste.ubuntu.com/5738646/ | 12:44 |
| xnox | ogra: i see dbus running, yet no starting nor started dbus events?! | 12:46 |
| ogra | weird | 12:46 |
| xnox | init: Error while reading from descriptor: Bad file descriptor | 12:47 |
| xnox | looks scary. | 12:47 |
| * ogra wonders where that might come from | 12:48 | |
| xnox | ogra: can I see output of `dmesg` ? | 12:48 |
| ogra | hmm, thats filled with trash already ... i can get you /var/log/dmesg | 12:49 |
| xnox | ogra: | grep init | 12:49 |
| ogra | http://paste.ubuntu.com/5738654/ | 12:49 |
| ogra | there is no init: in it anymore ... | 12:50 |
| ogra | if the ringbuffer is full dmesg deletes | 12:50 |
| xnox | ogra: create a "custom logger" =))) http://paste.ubuntu.com/5738665/ | 12:54 |
| xnox | ogra: and then /var/log/upstart/customlog.log will have just the events we are interested in, and we will notice if ofono started or not. | 12:55 |
| xnox | ogra: also add "or started/starting/stopped/stopping ofono" if you want to notice those as well. | 12:55 |
| xnox | ditto dbus. | 12:55 |
| ogra | ugh | 12:57 |
| ogra | /bin/sh: 0: Can't open /proc/self/fd/9 | 12:57 |
| ogra | all over the place | 12:57 |
| ogra | http://paste.ubuntu.com/5738679/ | 13:01 |
| jbicha | should packagekit-qt be removed also? (it unfortunately migrated out of -proposed) | 13:01 |
| ogra | i see 4 create events for the file | 13:02 |
| === _salem is now known as salem_ | ||
| === ckpringle_ is now known as ckpringle | ||
| xnox | ogra: weird, but the ofono job should be running then. Was that booted two times? as dbus/file-bridge are started twice. | 13:13 |
| ogra | yeah | 13:14 |
| === Zic is now known as Guest97647 | ||
| * ogra tries something els | 13:17 | |
| ogra | e | 13:17 |
| === funkyHat_ is now known as funkyHat | ||
| === Trevinho__ is now known as Trevinho | ||
| === schwann is now known as gusch | ||
| === sil2100__ is now known as sil2100 | ||
| === greyback|food is now known as greyback | ||
| === tkamppeter_ is now known as tkamppeter | ||
| === mardy_ is now known as mardy | ||
| tedg | mardy, Hey, is there a way to turn off UOA in Evolution? | 13:46 |
| mardy | tedg: open the account in the System Settings, there should be switches next to the various services | 13:47 |
| tedg | mardy, With Google I have photo search, shotwell, empathy and Google Drive plugin. But no Evolution. | 13:48 |
| === henrix_ is now known as henrix | ||
| seb128_ | tedg, mardy: not sure if you got that before | 13:54 |
| seb128_ | mardy, that's not listed evolution, Laney mentioned that there was an error about no matching .desktop yesterday iirc | 13:54 |
| Laney | eds should supply a .desktop file for it | 13:55 |
| tedg | Yeah, I also just did a dist-upgrade and I'm getting an account-plugin-google. | 13:55 |
| tedg | Curious if part of my problems were that I didn't have the right provider. | 13:55 |
| Laney | it's basically broken with accounts that require 2fa | 13:56 |
| Laney | https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1187699 | 13:57 |
| ubottu | Launchpad bug 1187699 in evolution-data-server (Ubuntu) "Timeout retreiving Google calendar" [Undecided,New] | 13:57 |
| === seb128_ is now known as seb128 | ||
| ogra | xnox, so dropping the file stuff and instead depending on the job that creates the file makes it work reliable | 13:58 |
| ogra | the file is a symlink to a socket which originally lives in /proc ... i guess the file bridge doesnt really get along with that | 13:59 |
| === wedgwood_away is now known as wedgwood | ||
| xnox | ogra: ah. there is a socket bridge as well, but it's reverse, to start a job when something starts talking to the socket. | 14:01 |
| ogra | xnox, yeah, that wont help, the thing talking to the socket is the thing i'm starting :) | 14:02 |
| xnox | ogra: to be honest i'd only use file-bridge to track _regular_ files on _normal_ filesystems, and not things in /dev, /proc and etc. But I guess that's not everyone's prerogative. | 14:02 |
| ogra | well, ofono needs the link to be there to start properly | 14:03 |
| ogra | else it cant talk to the daemon inside the container | 14:03 |
| xnox | i see. | 14:03 |
| zul | how long does it take to get somehting out of -proposed? | 14:07 |
| tumblewed | it needs to be installable | 14:08 |
| jdoles | Does anyone know how the cc_version is determined in this string (avahi output for distcc)? txt = ["cc_machine=x86_64-linux-gnu" "cc_version=4.7" "gnuhost=x86_64-pc-linux-gnu" "distcc=3.1" "cpus=2" "txtvers=1"] | 14:15 |
| xnox | zul: fully build on all arches, it previously managed to build on. + does not cause more packages to be uninstallable. See http://people.canonical.com/~ubuntu-archive/proposed-migration/ | 14:15 |
| jdoles | In particular why does it select just one number when multiple compilers are installed on the system? | 14:16 |
| xnox | jdoles: my guess it comes from the compiler it self. and whichever one is the "cc" or "gcc" compiler?! | 14:16 |
| jdoles | xnox: the compiler being? | 14:16 |
| jdoles | xnox: (there is no 'the') | 14:16 |
| xnox | jdoles: type $ cc --version | 14:16 |
| jdoles | xnox: unless you mean that it has been hardcoded to use cc. | 14:17 |
| xnox | jdoles: that's the default c-compiler on any system (hence "cc") you can update that symlink if you wich. | 14:17 |
| xnox | wish. | 14:17 |
| xnox | and I'm sure distcc can be configured to use alternative compilers. | 14:17 |
| jdoles | xnox: after apt-get install gcc-4.7, I don't have a gcc-4.7 on my path. Why not? | 14:18 |
| xnox | jdoles: i do. what's your path?! =) | 14:19 |
| xnox | zul: unless you are talking about SRUs verification from $stable-proposed -> $stable-updates ?! | 14:19 |
| zul | xnox: nah im good thanks | 14:19 |
| jdoles | xnox: the default PATH + some site specific ones. | 14:20 |
| jdoles | xnox: actually I only have gcc-4.7-base. | 14:21 |
| jdoles | xnox: and that is a very small package which doesn't seem include an actual compiler. | 14:21 |
| ev | pitti: is there a historical reason why we don't include a timestamp in the apport report path? Otherwise we're replacing whatever crash already existed every time, even if they're crashes in different places. | 14:22 |
| ev | tedg is running into this right now with recoverable problems | 14:22 |
| ev | why this didn't occur to me sooner, I have no idea | 14:22 |
| ev | I noticed that bzr does the right thing here for its crashes | 14:22 |
| xnox | jdoles: dlocate /usr/bin/gcc-4.7 tells me you want: gcc-4.7: /usr/bin/gcc-4.7 | 14:23 |
| xnox | jdoles: as in $ apt-get install gcc-4.7 | 14:23 |
| jdoles | xnox: I did that. | 14:23 |
| jdoles | xnox: Note, selecting 'gcc-4.7-base' for regex 'gcc-4.7' | 14:24 |
| jdoles | xnox: alternatively, how can I make distcc use an older compiler? | 14:25 |
| dobey | xnox: thanks for fixing the software-center package branches! | 14:28 |
| jdoles | xnox: is your other nickname nox? | 14:28 |
| xnox | jdoles: no. | 14:28 |
| xnox | (not for more than 12 years now anyway) | 14:29 |
| apw | pitti, ok after much poking, we seem to have gotten the right initrds off the machine. the 16m size is right becuase that machine has no plymouth, and indeed when it jumps to 23 it is plymouth appearing in there that did it | 14:29 |
| pitti | aah | 14:29 |
| pitti | apw: so cryptsetup and the like | 14:29 |
| pitti | that would drop a lot indeed | 14:30 |
| apw | pitti, there is also some cryptsetup in there, so it seems that something in the recent image is pulling that in | 14:30 |
| apw | > lib/libcryptsetup.so.4 | 14:30 |
| apw | is added in the later image | 14:30 |
| apw | (in its initrd) | 14:30 |
| xnox | jdoles: install whichever compiler you want, and adjust your path appropriatly for it to be called as "cc" and distcc will use that. if there are problems, try googling. I don't use distcc at all myself. | 14:30 |
| apw | pitti, how the heck would one figure that out | 14:31 |
| xnox | pitti: apw: whilst images have cryptsetup, the default unencrypted/lvm-less desktop shouldn't have cryptsetup in the initramfs. | 14:31 |
| dobey | does distcc not support doing "CC=/usr/bin/foo-cc distcc" or something? | 14:31 |
| apw | xnox, as soon as cryptsetup is installed we will add plymouth and junk into the initramfs | 14:32 |
| xnox | dobey: i mostly saw it use wrappers & diverts everytime I had to use distcc. | 14:32 |
| apw | xnox, regardless of whether it is used for root or not | 14:32 |
| xnox | apw: sure. which I was meant to fix, and only add it if "/" and/or "/usr" is encrypted. | 14:32 |
| apw | xnox, ok but as things are has cryptsetup been added to the default images | 14:33 |
| apw | as in the last two weeks the sizes of the initrd's have jumped | 14:33 |
| xnox | apw: in quantal we added full-disk encryption to the desktop image, but it should be removed from the installed system at the end of installation if one chose defaults and is not using encrypted rootfs. | 14:33 |
| apw | xnox, ahhh, so this could be a bug in the bit which removes it then | 14:34 |
| xnox | apw: .... if for example initramfs is last regenerated before and not after removing packages. | 14:34 |
| * apw goes find something to scratch install | 14:35 | |
| cjwatson | jdoles: If apt falls back to regex search, it must be because gcc-4.7 isn't available. 'apt-cache policy gcc-4.7' does a lower-level check | 14:36 |
| xnox | apw: but i don't think we touched that code since.... quantal. So it doesn't explain regression from a few weeks ago. | 14:36 |
| * xnox is checking daily saucy. | 14:36 | |
| apw | xnox, nope, but i should scratch this test box and see if it stays on, and eliminate it | 14:36 |
| jdoles | cjwatson: that only shows the base (this is precise-updates) | 14:37 |
| apw | and if it is there find out what is holding it on | 14:37 |
| jdoles | cjwatson: I think it's simply not in precise. | 14:37 |
| xnox | jdoles: yeah, quantal and up. | 14:38 |
| cjwatson | Indeed. GCC 4.7.0 was released in March 2012, only barely before precise released. | 14:38 |
| cjwatson | gcc-4.7-base is there because there was a gccgo-4.7 source package in precise that built it, because people wanted to experiment with the Go compiler early. | 14:40 |
| pitti | rbasak: ugh, that became a loong reply :) | 14:42 |
| ev | tedg: give this a bash: http://paste.ubuntu.com/5738948/ | 14:46 |
| tedg | ev, Sorry, catching up. I figured that that's what the "1000" was for. | 14:46 |
| ev | that's the uid | 14:46 |
| tedg | Ah, I thought it was a counter :-) | 14:46 |
| ev | I *think* the intent was to keep the reports to a minimum, back in the day | 14:47 |
| ev | but with errors.ubuntu.com, it seems like we're just potentially overwriting some problems (assuming an application can crash twice before the first report is processed) | 14:47 |
| ev | which would be fairly easy with recoverable_problem. Harder with Crash ProblemTypes | 14:48 |
| tedg | ev, Can you just send me the whole file? I've hacked it too much for debugging... diffs won't apply :-) | 14:50 |
| ev | tedg: sure | 14:50 |
| ev | http://paste.ubuntu.com/5738958/ | 14:51 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| tedg | ev, Hah, was trying to figure out what happened. It wrote multiple files, but in my home directory :-) | 14:57 |
| ev | :) | 14:57 |
| ev | any idea why? | 14:57 |
| tedg | ev, I'm guessing reportfile there needs an "/var/crash" in front of it. | 14:58 |
| ev | hmm, so it does :) | 14:59 |
| ev | os.path.join(report_dir, reportfile) | 14:59 |
| tedg | ev, Woot! I can make lots of crash files ;-) http://paste.ubuntu.com/5738984/ | 15:01 |
| ev | heh, I'm working on a variant that uses a short hash of the crash/duplicate signature | 15:02 |
| ev | which would at least not break "ignore future problems of this type" box | 15:03 |
| tedg | That makes more sense. Each type once. | 15:03 |
| ev | yeah | 15:03 |
| barry | bdmurray: ping | 15:05 |
| bdmurray | barry: hey | 15:05 |
| didrocks | barry: hey, do you know why python-support is in universe? | 15:07 |
| barry | didrocks: it's deprecated in debian. ubuntu is a little farther ahead in switching to dh_python2, but we really don't want anyone using py-support or (even worse) py-central any more | 15:07 |
| barry | didrocks: it's usually pretty easy to switch to dh_py2 | 15:07 |
| barry | didrocks: http://wiki.debian.org/Python/TransitionToDHPython2 | 15:08 |
| cjwatson | die die die python-support | 15:08 |
| didrocks | barry: ok, I need gtester2xunit in main | 15:08 |
| didrocks | barry: which build-dep on python-pyruntest | 15:08 |
| cjwatson | didrocks: somebody needs to convert it then | 15:08 |
| didrocks | which build-dep on subunit | 15:08 |
| didrocks | cjwatson: yeah, but for sure, everything is melt down and it seems people don't care about that to have touch and unity 7 in distro | 15:09 |
| cjwatson | we very carefully went to the effort of converting everything in main that used python-central or python-support to dh_python2 | 15:09 |
| * didrocks *sigh* | 15:09 | |
| cjwatson | they have to care, python-support is not going back into main :) | 15:09 |
| didrocks | I know, why I'm asked | 15:09 |
| didrocks | asking* | 15:09 |
| cjwatson | python-pyruntest doesn't build-dep on subunit here though | 15:10 |
| === racedo` is now known as racedo | ||
| didrocks | cjwatson: wrong line copied: python-junitxml, | 15:10 |
| cjwatson | Nor does subunit use python-support | 15:11 |
| cjwatson | Right, python-junitxml needs to be converted | 15:11 |
| didrocks | cjwatson: yeah, I copied the wrong line when pasting here :) | 15:12 |
| cjwatson | It's usually about a 15-minute job. Want me to have a look then? | 15:12 |
| Laney | I heard the maintainer's a nice guy | 15:13 |
| cjwatson | He is, but he might also like to take patches rather than doing it himself :) | 15:13 |
| didrocks | cjwatson: seeing the christmas period that is my IRC right now, I'll greatly appreciate :) | 15:13 |
| didrocks | (thanks for the offer) | 15:13 |
| Laney | was suggesting that he'd probably be quite willing to take them :P | 15:15 |
| apw | xnox, ok a clean install with todays saucy iso, selecting a normal install, leave cryptsetup installed | 15:23 |
| apw | xnox, whats the best way to find out why it is still on | 15:24 |
| === jbicha_ is now known as jbicha | ||
| dobey | anyone have any idea why the branch import of a package would have succeeded for saucy-proposed, but doesn't seem to have gotten copied to saucy, even though the package has already been copied over, and there's nothing on the branch imports status page for it? | 15:25 |
| xnox | apw: it's installed because it gets copied across like everything else. It is left on the install either because it's in whitelist, dependancy of something in whitelist, explicetly "marked" to be install with apt-install. | 15:26 |
| apw | xnox, ok so this was a default install all options defaulted, and its still on there, so is the information on why still on the system so i can find out | 15:26 |
| xnox | apw: I can take from here, and hunt it down. Also it's a good excuse to simply implement "do not pull cryptsetup+plymouth+friends into initramfs, unless root partition is encrypted". | 15:26 |
| apw | xnox, i would love to see that for my purposes as i use cryptsetup in that mode, not for / | 15:27 |
| apw | xnox, ok thanks, there is a bug out there, which is currently against, systemd | 15:27 |
| apw | xnox, LP#1188108 | 15:28 |
| apw | bug #1188108 | 15:28 |
| ubottu | bug 1188108 in Ubuntu "saucy initramfs ballooned, causing bootspeed regression" [Medium,Incomplete] https://launchpad.net/bugs/1188108 | 15:28 |
| slangasek | caribou: just doing our duty ;) | 15:41 |
| jdoles | Are you also switching to systemd now? | 15:42 |
| jdoles | Switching initialization system every release seems like not so fruitful idea. | 15:43 |
| jdoles | +a | 15:43 |
| seb128 | jdoles, we don't plan to use systemd init no | 15:44 |
| cjwatson | The mention of systemd above is because we're using some pieces of systemd (e.g. udev is built out of that tree now), but not the actual init daemon | 15:45 |
| barry | bdmurray: actually, let me ask cjwatson and/or slangasek if they know whether update-motd scripts can generally write to stderr. the manpage is a bit silent on that although it does say: "MOTD fragments must be scripts in /etc/update-motd.d, must be executable, and must emit information on standard out." | 15:46 |
| cjwatson | I think that would be up to pam_motd | 15:47 |
| * cjwatson punts to slangasek | 15:47 | |
| barry | slangasek: context is bug #982082 | 15:48 |
| ubottu | bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged] https://launchpad.net/bugs/982082 | 15:48 |
| Laney | h | 15:49 |
| barry | what we think is happening is that something mysterious is breaking lsb_release causing it to exit non-zero. not sure what that is, but if that *does* happen, then check-new-release will write an error message to stderr, but stderr doesn't exist and we get the IOError. that gets run under an update-motd.d script so the guess is that stderr isn't available to those scripts | 15:50 |
| slangasek | barry: the pam_motd integration doesn't capture stderr to the motd (which it shouldn't); it also doesn't redirect it anywhere, which may be a bug since it means the scripts can pollute the stderr of the invoking service | 15:50 |
| slangasek | barry: so arguably, pam_motd should redirect stderr to /dev/null unconditionally, but I'm not sure if that helps you | 15:50 |
| cjwatson | didrocks: pyjunitxml done | 15:51 |
| barry | slangasek: it does somewhat. the question is whether to fix this bug we should really install a more general fix to pam_motd. the other options are narrower, e.g. either redirect stderr to stdout in this specific motd.d script, or fake stderr in the python bits that get invoked | 15:51 |
| jdoles | I managed to get distcc --show-hosts to show proper output, but when I run a compilation it doesn't actually use multiple hosts :/ | 15:52 |
| jdoles | Anyone with an idea what can still be wrong? | 15:52 |
| didrocks | cjwatson: thanks a lot! we're doing sphinx on the same base right now :) | 15:52 |
| barry | slangasek: the narrower fixes are safer for an sru, and also probably easier to test and complete ;) | 15:52 |
| bdmurray | barry: I'd imagine saucy is still affected though | 15:53 |
| barry | bdmurray: could be, yes. probably the easiest/quickest fix is to redirect stderr in the motd script | 15:53 |
| slangasek | barry: wasn't there some suggestion in the other master lsb_release bug that invoking lsb_release itself with stderr closed was causing failures? Maybe fixing lsb_release to handle that case kills two birds with one stone? | 15:55 |
| barry | slangasek: i don't think this is directly related to lsb_release writing to stderr. the problem happens because lsb_release exits non-zero and it's the do-release-upgrader code that then tries to write a message to stderr in that case. | 15:56 |
| barry | slangasek: we have seen cases where lsb_release can exit non-zero, which is why we sru'd the -Es shebang line fix. i am requesting more information in the bug about that, which would be the root cause (and about the only reason why lsb_release would exit non-zero) | 15:57 |
| slangasek | ok | 15:57 |
| slangasek | well, except if lsb_release is raising an unhandled exception because stderr is closed (which is the reported symptom in that bug), wouldn't that also translate to exiting non-zero? | 15:57 |
| slangasek | and if do-release-upgrader's stderr is closed, that obviously triggers this path | 15:58 |
| barry | slangasek: for precise, lsb_release will only write to stderr if it crashes or gets bogus command line options. in the context of the tracebacks i've seen, the latter isn't happening, so it has to be the former, which leads to the guess that they don't have the -Es fix. | 16:00 |
| barry | lsb_release will obviously write to stdout in normal usage, but that's okay | 16:00 |
| caribou | slangasek: I was a bit annoyed to let that regression in; never saw any issue with my own tests | 16:01 |
| pitti | apw: so should we move #1188108 to ubiquity/confirmed then? | 16:01 |
| slangasek | barry: are we talking about bug #1094218 here (or rather, https://errors.ubuntu.com/bucket/?id=%2Fusr%2Fbin%2Flsb_release%3AIOError%3A%3Cmodule%3E%3Amain%3Acheck_modules_installed%3Agetoutput%3Agetstatusoutput)? that bucket clearly shows that lsb_release *does* have the -Es fix, and the invocation is a correct one; so this all adds up to "lsb_release crashes reliably when stderr is closed". Have you tried to run lsb_release with stderr | 16:03 |
| ubottu | bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [Medium,Confirmed] https://launchpad.net/bugs/1094218 | 16:03 |
| slangasek | ... see what happens? | 16:03 |
| barry | slangasek: let's try it! :) | 16:04 |
| === mmrazik is now known as mmrazik|afk | ||
| barry | slangasek: okay, so yes, this will crash: | 16:12 |
| barry | lsb_release -a exec 2>&- | 16:12 |
| barry | slangasek: but here's the difference: in the context of the original bug, it's only running `lsb_release -c -s` which *doesn't* crash when stderr is closed | 16:12 |
| barry | slangasek: so i'll claim this is two different bugs :) | 16:13 |
| barry | hmm, actually, no i ran this in two different ways. maybe it does crash | 16:14 |
| barry | okay, so that explains the root cause | 16:14 |
| apw | pitti, perhaps so for the moment, xnox is in the frame right now; it may move somewhere else when we figure out what it really is but yes i think so | 16:15 |
| slangasek | barry: ok :) | 16:17 |
| barry | slangasek: so, short of doing $something w/stderr in pam_motd, perhaps we should just redirect stderr to stdout in the update-mod.d script | 16:18 |
| barry | slangasek: anyway, i'm going to get some lunch and ponder some more :) | 16:19 |
| slangasek | barry: lsb_release needs to be fixed to not fail when stderr is closed, because that's a legitimate way to invoke it and the cause of our *top* crasher on errors | 16:20 |
| slangasek | barry: if we fix lsb_release to not fail in this case, does that fix all the knock-on effects? | 16:20 |
| barry | slangasek: it probably will, although there will still be a lurking bug here because if for some other reason lsb_release fails, check-new-release will still try to print to stderr under update-motd | 16:22 |
| slangasek | right | 16:22 |
| rbasak | pitti: np. Thanks :) | 16:22 |
| slangasek | barry: so I think pam_motd redirecting 2>/dev/null, and fixing lsb_release, should cover us | 16:22 |
| cjwatson | I'm not arguing against making lsb_release robust against this, but I don't think that "stderr closed" is a legitimate way to invoke any process, maybe with some special-purpose exceptions between cooperating processes | 16:23 |
| cjwatson | (as opposed to "stderr redirected to /dev/null", of course) | 16:23 |
| barry | cjwatson: you have a point, in that we can't expect to make every command robust against stderr being closed | 16:24 |
| slangasek | cjwatson: well, ok. In practice, this seems to be the environment teamviewer is giving us, leading to that top crash in question :P | 16:24 |
| cjwatson | Is pam_motd actually closing stderr itself, or is that the fault of something further up the stack? | 16:24 |
| cjwatson | teamviewer | 16:24 |
| cjwatson | Christ | 16:24 |
| stgraber | barry: wow, so you finally managed to track that bug down? that took a while ;) | 16:24 |
| slangasek | cjwatson: pam_motd doesn't close stderr, but even if stderr *isn't* closed, I don't think we want these scripts' output leaking to the pam service's stderr | 16:24 |
| cjwatson | slappity slap buggy proprietary software :-/ | 16:24 |
| cjwatson | We should let the teamviewer people know about this, since we have no way to fix it - I don't think we should omit that part since it might bite some other innocent process later | 16:25 |
| slangasek | how do you mean, no way to fix it? | 16:25 |
| cjwatson | no way to fix teamviewer | 16:26 |
| slangasek | lsb_release can simply reopen stderr as /dev/null to work around | 16:26 |
| slangasek | oh | 16:26 |
| cjwatson | we can fix the collateral damage | 16:26 |
| cjwatson | but this is definitely teamviewer doing an invalid thing | 16:26 |
| slangasek | well, AFAIK lsb_release is the only tool it's invoking | 16:26 |
| slangasek | ok | 16:26 |
| barry | but wait. teamviewer might be the culprit in bug #1094218 but i don't think it is in bug #982082 | 16:26 |
| ubottu | bug 1094218 in lsb (Ubuntu) "lsb_release crashed with IOError in getstatusoutput(): [Errno 10] No child processes (called by teamviewerd)" [Medium,Confirmed] https://launchpad.net/bugs/1094218 | 16:26 |
| ubottu | bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged] https://launchpad.net/bugs/982082 | 16:26 |
| slangasek | barry: correct | 16:26 |
| slangasek | so I don't know how do-release-upgrade is being invoked there | 16:27 |
| barry | slangasek: from update-motd | 16:27 |
| slangasek | barry: there's no top-level tool called update-motd any more | 16:27 |
| slangasek | the question is, who closed stderr :) | 16:27 |
| barry | slangasek: on precise, what runs /etc/update-motd.d/* scripts? | 16:28 |
| slangasek | barry: pam_motd | 16:28 |
| slangasek | so some /service/ must invoke it | 16:29 |
| slangasek | and the only obvious candidates are login and sshd | 16:29 |
| * slangasek bounces the bug back to cjwatson ;) | 16:29 | |
| cjwatson | pam_open_session doesn't do any generalised fd fiddling? | 16:30 |
| barry | slangasek: so i think i misunderstood your earlier comment about pam_motd and stderr. | 16:30 |
| cjwatson | I'm reasonably sure that sshd never closes stderr - it would make its own debug output unusable which would be a pretty obvious thing | 16:32 |
| cjwatson | and do_pam_session is post-auth, ruling out the really weird stuff that goes on with the pre-auth network monitor | 16:32 |
| barry | i think this is happening at login not ssh | 16:33 |
| barry | https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/982082/comments/3 | 16:33 |
| ubottu | Launchpad bug 982082 in ubuntu-release-upgrader (Ubuntu) "do-release-upgrade crashed with IOError in init_proxy(): [Errno 5] Input/output error" [Medium,Triaged] | 16:33 |
| cjwatson | login doesn't seem to close much of anything | 16:34 |
| cjwatson | Shame we don't have a process tree here | 16:35 |
| rbasak | Do we have any kind of policy of when we move a Debian package to upstart by adding an upstart job in our delta? | 16:36 |
| rbasak | Whenever anyone's prepared to write one? Only when we have a reason and a delta anyway? Etc. | 16:36 |
| cjwatson | Mostly when it's possible and somebody's prepared to write one | 16:37 |
| cjwatson | But we should be forwarding all those deltas now :) | 16:37 |
| rbasak | So we'd prefer to an upstart job for all daemons, even when we have to maintain deltas just for that? | 16:38 |
| rbasak | (including universe?) | 16:38 |
| cjwatson | I'm finding it really unlikely that 982082 is sshd, based on the bug description. Are we sure there's no desktopy thing that would be using pam_motd there? | 16:38 |
| cjwatson | Well, it's been a tradeoff of benefit vs. cost of maintaining the delta | 16:38 |
| cjwatson | Now that we have a way to get such jobs into Debian, hopefully the tradeoff will tilt | 16:38 |
| barry | cjwatson: i concur about sshd. no clue about the desktop thing | 16:38 |
| cjwatson | Or something that's running update-motd in some other way? It used to be a bit more ad-hoc ... | 16:39 |
| rbasak | I'm not sure I understand the benefit for random daemons in universe that don't need to interact with anything else for startup (ie. there's no other enumerated reason) | 16:39 |
| cjwatson | Management (upstart will keep it running more reliably); consistency across the system | 16:40 |
| rbasak | OK, thanks | 16:41 |
| barry | slangasek, cjwatson well, wouldn't this pastebin be a stupidly horrible way to at least verify whether stderr-being-closed is the problem? http://paste.ubuntu.com/5739278/ maybe that's even A Fix (if not a particularly good one) | 16:43 |
| cjwatson | It would avoid that particular problem. I think the only thing that qualifies as a true fix is not starting the process in that state, though :) | 16:46 |
| cjwatson | (As I say, given that it's a top crasher, I don't object to workarounds) | 16:47 |
| barry | cjwatson: agreed on both counts ;) | 16:47 |
| slangasek | cjwatson: pam_open_session() definitely doesn't fiddle fds | 16:47 |
| * cjwatson evilly wonders how much he could confuse everyone by writing something that launches processes with an envp pointing out of their mapped memory space | 16:48 | |
| slangasek | rbasak: why should you have to maintain a delta for an upstart job now? These should all be upstreamable to Debian | 16:48 |
| cjwatson | Or maybe just one of the pointers in argv | 16:48 |
| yolanda | pitti: https://code.launchpad.net/~yolanda.robla/ubuntu/saucy/squid3/fix-squid3-startstop/+merge/167804 | 16:48 |
| barry | cjwatson: that sunny disposition never fooled me. i knew you had an evil streak. :) | 16:49 |
| cjwatson | O:-) | 16:49 |
| rbasak | slangasek: I was asking in response to review a debdiff to introduce an upstart job in our delta, to override an init.d from Debian. bug 1187742. mvo doesn't appear to be here right now. | 16:49 |
| ubottu | bug 1187742 in freeradius (Ubuntu) "[patch] upstart job for freeradius" [Wishlist,Triaged] https://launchpad.net/bugs/1187742 | 16:49 |
| rbasak | slangasek: I can ask that he send this up to Debian, of course. | 16:50 |
| * barry -> lunch | 16:50 | |
| slangasek | rbasak: right, it should definitely be sent there in parallel | 16:50 |
| cjwatson | It's a pretty recent development that it's possible to upstream these; mvo may just not be aware of it | 16:50 |
| cjwatson | (Well, possible sanely, as opposed to the crazy thing openssh used to do) | 16:50 |
| rbasak | yolanda: ^^ led me to look at your dep8 test. Would it be an idea to package and include testlib.py somewhere, rather than include it in every test individually? Or are we intentionally duplicating the code here in every test for some reason? | 16:53 |
| yolanda | rbasak, we were talking about that with jdstrand, we agreed that at the moment we will pack it in every file | 16:54 |
| rbasak | yolanda: OK, fair enough. Good to know - thanks. | 16:54 |
| yolanda | because testlib.py wasn't intented to be a production code | 16:54 |
| yolanda | and to package it, more tests and verification is needed | 16:54 |
| rbasak | slangasek, cjwatson: thanks. I'm much clearer on what do with upstart jobs now. | 16:55 |
| cjwatson | Is there some kind of main promotion or something needed for http://people.canonical.com/~ubuntu-archive/testing/precise-updates_probs.html ? | 16:58 |
| slangasek | cjwatson: hmm, the maas SRU seems to have been published before its dependencies | 17:05 |
| slangasek | these were SRUs of new packages | 17:05 |
| slangasek | so... let's see about getting celery published | 17:06 |
| slangasek | cjwatson: ok, celery promoted to -updates; python-pyparsing and freeipmi-tools look like they need a copy to precise-updates & promotion to main? | 17:09 |
| jcastro | slangasek: cjwatson: thanks for sorting this, maas has been a real pain point for users | 17:10 |
| slangasek | roaksoax: can you please remind me what the expected outcome for the maas SRU was wrt python-pyparsing, python-txtftp, freeipmi-tools? Did we have agreement to retroactively promote these to main for 12.04 and have them security supported? | 17:14 |
| slangasek | these are each obviously in main in quantal and later, but I don't see that these were explicitly discussed as part of the maas SRU... I want to make sure the security team knows about this before I pull the trigger on promoting | 17:15 |
| slangasek | mdeslaur: ^^ | 17:15 |
| mdeslaur | uh...what now? is there a bug# for that SRU? | 17:16 |
| slangasek | mdeslaur: this is wrt bug #1109283 | 17:17 |
| ubottu | bug 1109283 in maas (Ubuntu Quantal) "[SRU] maas to Quantal and Precise" [Undecided,Fix released] https://launchpad.net/bugs/1109283 | 17:17 |
| roaksoax | slangasek: howdy! it was my understanding that these were discussed long ago and agreed upon | 17:20 |
| roaksoax | mdeslaur: more specifically, bug #1020267 | 17:21 |
| ubottu | bug 1020267 in python-redis (Ubuntu Precise) "[MIR] celery, pyparsing, python-cl, python-gevent, python-mailer, python-pytyrant, python-redis" [Undecided,New] https://launchpad.net/bugs/1020267 | 17:21 |
| slangasek | roaksoax: it's possible that this was all discussed, I just want to make sure I know where since it's the security team picking up the tab here, not me ;) | 17:21 |
| roaksoax | IIRC, we initially intended to do this for precise, but since we were not gonna be able to release maas as fast, we re-targetted to quantal | 17:22 |
| mdeslaur | ok, since it gets rid of cobbler, I'm ok with those being promoted | 17:22 |
| mdeslaur | I'll comment in #1020267 | 17:22 |
| roaksoax | mdeslaur: thanks! :) | 17:22 |
| mdeslaur | slangasek, roaksoax: ok, commented in 1020267. I'm ok with promoting them since it gets rid of embedded cobbler code. Thanks for the ping. | 17:25 |
| === smb` is now known as smb | ||
| smb | infinity, <pester>Could you have a look (and sponsor) at chinstrap:~smb/4infinity for saucy</pester> | 18:04 |
| infinity | smb: Maybe. I'm trying to salvage some kernel PPA messes right now. | 18:05 |
| smb | infinity, Ok, yeah. Just remembered that yesterday I forgot your/my daily pester-ilence | 18:06 |
| === Guest97647 is now known as Zic | ||
| smoser | xnox, ping | 18:20 |
| smoser | bug 1124384 | 18:20 |
| ubottu | bug 1124384 in cloud-init (Ubuntu Saucy) "Configuration reload clears event that others jobs may be waiting on" [High,Confirmed] https://launchpad.net/bugs/1124384 | 18:20 |
| smoser | never mind | 18:24 |
| === josepht_ is now known as josepht | ||
| === mmrazik|afk is now known as mmrazik | ||
| === Quintasan_ is now known as Quintasan | ||
| === jussi01 is now known as jussi | ||
| === fginther is now known as fginther|afk | ||
| === jtaylor_ is now known as jtaylor | ||
| === odifis_ is now known as oDiafanos | ||
| === salem_ is now known as _salem | ||
| shadows | How to fix a kernel panic when Bluetooth DUN disconnects? | 21:06 |
| shadows | is there a procedure to bisect for Ubuntu... what do I do | 21:06 |
| infinity | shadows: -> #ubuntu-kernel | 21:10 |
| infinity | jbicha: I take it you didn't test-build your gdm FTBFS fix? :P | 21:13 |
| shadows | thanks infinity | 21:23 |
| shadows | infinity: topic fail btw, http://bit.ly/lv8soi is 404 | 21:26 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| === tumblewed is now known as tumbleweed | ||
| dobey | wgrant: ping. are you around now? wondering if you could take a quick look at some udd branch import weirdness for me. thanks | 21:59 |
| wgrant | dobey: What needs fixing? | 22:04 |
| dobey | wgrant: lp:ubuntu/ubuntuone-control-panel doesn't seem to have been updated, though saucy-proposed branch was updated. and there is nothing on the import status page about it | 22:07 |
| bdmurray | mpt: could you have a look at bug 1186376 again? | 22:13 |
| ubottu | bug 1186376 in software-properties (Ubuntu) "should support setting of whether or not to include phased updates" [Medium,Triaged] https://launchpad.net/bugs/1186376 | 22:13 |
| === wedgwood is now known as wedgwood_away | ||
| === wedgwood_away is now known as wedgwood | ||
| wgrant | dobey: That's fixed. | 23:12 |
| slangasek | cjwatson, infinity: so with this maas stuff, it seems that copying these packages from precise to precise-updates and change-override'ing them to main is insufficient. I guess we need no-change SRUs? | 23:16 |
| === wedgwood is now known as wedgwood_away | ||
| wgrant | slangasek: What's insufficient about it? | 23:23 |
| infinity | slangasek: Hrm, what? | 23:26 |
| infinity | slangasek: Did I miss something exploding? | 23:27 |
| infinity | E: Package 'freeipmi-tools' has no installation candidate | 23:28 |
| infinity | E: Package 'python-celery' has no installation candidate | 23:28 |
| infinity | Oh, that. Fun. | 23:28 |
| wgrant | Ah, promoting stuff post-release? | 23:28 |
| wgrant | That usually works fine... | 23:29 |
| infinity | Why wouldn't it work? | 23:29 |
| wgrant | Exactly. | 23:29 |
| infinity | slangasek: Where's the evidence that this doesn't work? | 23:29 |
| wgrant | AFAIK it works. | 23:29 |
| wgrant | Don't see why it wouldn't. | 23:29 |
| infinity | slangasek: It just looks to me like none of it's been promoted, that's all. | 23:30 |
| infinity | slangasek: I'd fix, but not if you've been mucking with overrides in the same publisher cycle. | 23:30 |
| infinity | slangasek: Let me know if your finger's removed from the pie, and I'll fix it. | 23:32 |
| === RAOF_ is now known as RAOF | ||
| straemer | anyone here have experience getting ubuntuone-android-music to build? | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!