[00:24] Hey, I'm trying to build ubuntuone-android-music, and am getting a build error [00:24] BUILD FAILED [00:24] /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 === echeve is now known as echevemaster [00:43] xnox: software-center pkg import has been broken for quite some time. === lifeless_ is now known as lifeless === achiang` is now known as achiang [00:56] @pilot out === 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: [01:33] HI ALL [01:33] anyone here [01:34] fdfdfd: 300+ .. though who is awake and around may vary. [01:35] sarno;d may i quayr you please it a lot earier for me [01:36] fdfdfd: it'd be best to ask questions in the channel, that way other people can learn, or correct me if I'm wrong :) === Guest63061 is now known as StevenK === _salem is now known as salem_ [02:43] 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] STILL [02:43] opps caps on still LOL [02:43] sorry [02:44] fdfdfd: I think you want the #ubuntu channel [02:44] ths is unbuntu channle [02:44] no, this is #ubuntu-devel [02:45] you cant get help from here [02:46] well the ubuntu channel is dedicated to support, so you'd have better luck there [02:47] in this room youall just caht about bull s **** [02:49] and talk about what ever [02:49] ok thank you streamer [03:52] Good morning === salem_ is now known as _salem [05:44] gday! === FlannelKing is now known as Flannel [06:30] good morning [06:40] slangasek: infinity: thanks for expediting the rsyslog regression fix [06:42] How can I backport a package? [06:48] jdoles: Need more context - to build locally, to build in a PPA, or the process for getting something into raring-backports etc. [06:49] maxb: locally [06:50] Hey, vala troubles [06:50] Package `webkitgtk-3.0' not found in specified Vala API directories or GObject-Introspection GIR directories [06:50] 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] But I am trying to package, what's the workaround [06:50] maxb: I installed backportpackage, but that doesn't do anything useful when used in the obvious way. [06:50] 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:51] Ah, you mean in reference to a specific helper scirpt [06:51] maxb: https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport [06:51] maxb: I am just following instructions. [06:51] maxb: and they don't work. [06:52] I think they work, they just aren't as detailed as you'd like [06:52] 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:53] maxb: as detailed? The program tells me that I need to specify an upload target or something else. [06:53] maxb: both options are not applicable. [06:53] maxb: hence, the program has a bug. [06:53] maxb: since the wiki is wrong, I ask here. [06:56] I get that you're frustrated, but it doesn't help to claim the instructions are wrong when they're not [06:57] They identify a specific helper script, with the expectation that users will refer to its help and/or manpage [06:57] Usage: backportpackage [options] [06:58] Source package name: I choose bc. [06:58] backportpackage bc [06:58] backportpackage: error: Please specify either a working dir or an upload target! [06:58] Documentation is simply wrong. [06:58] maxb: why do you make up excuses? [06:58] So now you actually go read the help message and specify one of those things (-w or -u options) [06:59] maxb: it's -U [06:59] No it isn't [06:59] maxb: and the USAGE doesn't say I need to specify it. [06:59] maxb: ok, so indeed it's -u, but still irrelevant. [07:00] maxb: so, whoever wrote USAGE was plain unambiguously WRONG. [07:00] maxb: you should talk to whoever wrote that script, because it wastes the time of people. [07:00] maxb: you should *not* point at me saying that I did something wrong. [07:01] You say "wrong" I say "omitted a small detail which you easily discover via a reasonably helpful error message on first use" [07:01] I frankly don't get why you even endorse such broken programs. [07:01] But then again, you also developed Unity. [07:01] I frankly don't get why you seem to think it's worth typing this diatribe. [07:02] maxb: the error message is *not* helpful. [07:02] * maxb stops feeding the troll [07:02] maxb: I have no idea what to do, because I matched the required inputs. [07:02] maxb: I read USAGE, gave valid values and the program returns an error. [07:03] That means that the problem is on the side of the author of said program. [07:04] Ouch [07:04] 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:06] * maxb wonders if ubuntu-dev-tools really needs to recommend debian-keyring (what with it being a 42MB .deb) [07:06] I managed to get the broken program to sort of work, but I don't want to upload anything. [07:06] maxb: yes, it does. [07:08] Hmm, Move debian-keyring from Suggests to Recommends (LP: #717245) [07:08] Launchpad bug 717245 in ubuntu-dev-tools (Ubuntu) "[pull-debian-source] Please recommend debian-keyrings" [Wishlist,Fix released] https://launchpad.net/bugs/717245 [07:12] yolanda: FYI, the squid3 autopkgtest keeps timing out; it's accessing some network sites, which mostly doesn't work from the DC [07:13] yolanda: would be better to rewrite it using a local apache/ftp server or something like that [07:13] hi pitti [07:13] ok, i'll take a look [07:13] yolanda: accessing www.ubuntu.com is probably okay (jibel?), but not the more elaborate stuff [07:14] pitti, i just took the code from QA there, is ok if i modify that only in the package then? [07:15] yolanda: sure === mmrazik is now known as mmrazik|afk [07:15] yolanda: I guess it's still worth keeping the current tests somewhere, though [07:15] they can run on a local box without a restrictive firewall/proxy in front of it [07:15] and with that it's more useful for actually testing security updates and the like [07:17] yolanda, *.ubuntu.com, *.canonical.com, *.launchpad.net and few others are ok [07:17] great [07:18] jibel: but only http, right? [07:18] the test also uses ftp and perhaps other [07:18] s [07:23] pitti, right http and https. I used ftp and smb servers inside the lab for JDK testing, we could setup one for autopkgtest === davidcalle_ is now known as davidcalle === Guest9557 is now known as Lutin [07:33] jibel, pitti, so it's better to enable ftp and leave the tests like that? [07:34] the other tests under http or https are just under ubuntu.com [07:34] yolanda: the ftp or some other test makes the whole test hang forever, and adt kills it [07:34] I can't say for sure as I don't get logs from these === mmrazik|afk is now known as mmrazik [07:35] mm, how can we confirm it? [07:36] yolanda: I'll try running it in the DC, to see what's hanging [07:38] ok [07:53] yolanda: oh, I get http://paste.ubuntu.com/5738082/ [07:53] yolanda: I'm not sure why the test is hanging forever, that seems to be a bug in our adt scripts [07:54] pitti, and you also get this error locally? [07:54] yes, I do [07:54] and the hang, too [07:55] run-adt-test -s squid3 [07:56] /etc/init.d/squid3 ← this doesn't exist [07:56] 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] yolanda: I'll check why run-adt-test hangs forever in the meantime, ok? [07:56] mm, i tested that locally before pushing anything and that worked, is that a recent change? [07:57] ok [07:57] I was fairly sure I tested it as well (always do when sponsoring) [07:57] I don't see it as a recent change [07:57] i'll test it again [08:20] jamesh: ping [08:20] sil2100: pong === mmrazik is now known as mmrazik|ofp === mmrazik|ofp is now known as mmrazik === ckpringle_ is now known as ckpringle [09:17] hmm, is /etc/fstab.d supposed to work ? [09:18] * ogra sees it in saucy, but files i put there done seem to be respected at all [09:19] oh, upstream removed it from mount .... how helpful [09:19] removed? perhaps it's in a less ancient util-linux? [09:21] sadly it has no reference to the discussion http://askubuntu.com/questions/168290/why-cant-mount-read-files-in-etc-fstab-d [09:21] the answer is from 2012 ... i dont really want to roll back that far :) [09:22] (on the phone where we ship fstab snippets it would be extremely helpful to have it working) [09:23] dobey: lp:ubuntu/software-center is now up to date. [09:34] pitti, yo ... we have a boot speed regression and we think udevd is to blame [09:34] pitti, (the systemd version) ... having poked it a bit the initrd seems to have bloated by likr 14Mb [09:35] apw: oh? it's actually supposed to be faster now, as it drops all those external programs [09:35] pitti, 16104k freed -> 30508k freed [09:35] 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:36] pitti, i am assuming it is not meant to be 14M of new code [09:36] apw: certainly not [09:36] sounds like a new dependency crept in or so [09:36] in better news, QAs boot charts found it, in not so better news we only noticed the regression by luck [09:37] I'm still fighting with vala, will look after that [09:37] pitti, oh and i think it may have gotten a bit better a couple of days ago [09:37] pitti, will confirm for you [09:37] apw: where are the bootcharts? [09:39] xnox, reports.qa.ubuntu.com, and hit the Bootspeed tab [09:39] pitti, ok confirmed, two days back it dropped back from 30m to 23m which has recovered about 1/2 the regression [09:41] hm, 202-0ubuntu10 was the last thing to really change the initramfs, but that was from May 29 already [09:41] apw: anyway, I'll dissect the initramfses and compare [09:41] pitti, i have both here, so while you are looking at vala, i'll see what i can see [09:47] apw: indeed, my initrd.img-3.9.0-2-generic is 31 MB, initrd.img-3.9.0-3-generic is 23 [09:47] initrd.img-3.9.0-2-generic is from May 28, thus before udev 202-0ubuntu10 [09:47] pitti, that was the shrink which gives us back half of it [09:48] apw: 14 MB was from raring? [09:49] pitti, hmm that is hard to tell with qa's stuff [09:49] 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] apw: filed bug 1188108 to track, FYI [09:49] bug 1188108 in systemd (Ubuntu) "saucy initramfs ballooned, causing bootspeed regression" [Undecided,New] https://launchpad.net/bugs/1188108 [09:49] pitti, thanks [09:49] apw: the regression was noted by d-i team, since sudently icu-udebs were required. [09:50] xnox, yeah ... good [09:50] 1/2 the regression is revert of extra icu baggage. [09:50] (recovery)?! [09:51] cause icudata is ~19MB unpacked. [09:51] pitti, oh yeah so locally my 16M ones are raring yes, so that is likely true for QA [09:51] pitti, so ... we have an initial delta 16->30 from raring->saucy, and 30->23 from fixing icu [09:51] ugg [09:53] $ 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] indeed, that's the removal of icu and libstdc++.so.6 [09:53] but it added +usr/lib/x86_64-linux-gnu/libgraphite2.so.3 [09:54] pitti, by the looks of it we have a heap more kernel modules in the new ones, like possibly all of them [09:54] apw: I think libgraphite2-3 is a dep of libharfbuzz0a is a dep of libpangoft2-1.0-0 is a dep of plymouth [09:55] pitti, i think we have a modules issue primarily [09:55] so at least there isn't anything udev-ish between -2 and -3 [09:55] apw: yeah [09:57] 5.2MAc/lib/modules [09:57] 31MBc/lib/modules [09:57] pitti, not good [09:57] pitti, so not all of them, but a heck of a lot more of them [09:58] apw: so is that due to udev somehow? [09:58] pitti, seems unlikely to me [09:59] 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 .. [10:00] pitti, let me poke it for a bit, and update the bug while you vala yourself to death [10:00] heh; effing buildds.. [10:01] what did the eff ever do to you :) [10:03] not reproduce in sbuild or debuild [10:03] so I keep banging new versions onto the buildds until they submit [10:11] 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:14] pitti, ok my 16M ones are actuall made with MODULES=dep in /etc/initramfs-tools/initramfs.conf [10:14] pitti, can you confirm whether you have like /etc/initramfs-tools/initramfs.conf.dpkg-old on the machine you checked [10:14] pitti, as my other raring machine they are all 31M [10:17] pitti, did your machine by any chance have the kmod stuff installed on it, the early kmod testing we did [10:19] 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] (in the QA scenario [10:20] apw: re [10:21] 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] pitti, i get a 23 M one now indeed [10:21] apw: ok, so it's not the new kernel then [10:21] pitti, and that is because i got a new initramfs-tools, which switched my conf from =dep to =most [10:22] 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] /usr/sbin/mkinitramfs:# MODULES=most is default [10:22] /usr/sbin/mkinitramfs:echo "W: mkinitramfs: Falling back to MODULES=most." [10:22] pitti, so the confusing thing is how this test box was _ever_ 16M [10:22] pitti, right ... i know, and that worries me about the machine which did the testing [10:22] 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:23] and there is no regression, but i am going to chat to QA to confirm the older results [10:23] pitti, but you have a 16M one as well and want to confirm you got that with =dep somehow [10:23] on that note, what happened to the really useful automatic creation of initramfs .bak files by update-initramfs ? [10:23] that your machine is a poor example as mine is [10:24] apw: 9554231 Jun 6 12:23 initrd.img-3.9.0-3-generic [10:24] pitti, i don't recall ever seeing those, though it does sound useful [10:24] that's with "dep" in /etc/initramfs-tools/initramfs.conf [10:24] but I just changed that [10:24] yep so nice and small [10:24] apw: I didn't have a 16 MB one on my machine; it's all saucy [10:24] apw: I was just quoting your number [10:24] ok, so 16M in the bug, was my number, ok, so that is a false number, just happening to match nearly exactly QAs [10:25] but i am now suspicious of [10:25] apw: so either /etc/initramfs-tools/initramfs.conf really had "dep" at some point, or someone poked that into the QA machine? [10:25] their number ... right ... so ... off to qa to ask [10:25] apw: you had manually configured that as well? [10:25] pitti, yeah seemingly when i was doing the kmod testing [10:25] i probabally change it to confirm i had done the right thing in the merge i did for initramfs tools for that [10:25] (one we didn't use in the end) and tested both modes, and left it in the wrong one, sigh [10:27] well, "dep" doesn't seem exactly "wrong", but it might indeed not be enough if you use root on a network fs [10:27] (but yuck) [10:27] having all those HID and network drivers in initramfs seems like a waste [10:27] at least if update-initramfs sees that the root fs is on a local disk [10:28] 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] 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:29] so you can recover in a disk moved to different h/w scenario [10:30] apw: I was just speaking about the network drivers, but indeed we could downsize the block drivers, too [10:36] pitti, ahh i see what you mean, make the decision that the disk is only portable as a disk [10:36] which makes a lot more sense [10:36] apw: I was thinking to not include any network stuff if your root dev is on any /dev/ [10:36] as opposed to some nfs device or so [10:37] 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] (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] apw: yes, I fully support having at least the most common disk drivers in the initramfs [10:38] lib/firmware/matrox/g200_warp.fw [10:38] lib/firmware/r128/r128_cce.bin [10:38] lib/firmware/radeon/PITCAIRN_mc.bin [10:38] wow, we have a lot of stuff in our initramfs [10:39] (for KMS, I guess) [10:42] apw: so we ship 9.9 MB of network drivers [10:42] that's a third of the size of drivers/net === mmrazik is now known as mmrazik|lunch === MacSlow is now known as MacSlow|lunch [11:22] does someone here use saucy? pulseaudio (in pauvcontrol) lists no sound cards [11:26] does for me on saucy/amd64 [11:27] xnox: saucy/amd64 here as well but no cards ;( [11:29] xnox: heh.. I am not in audio group [11:35] hrw, the audio group shouldnt be used unless you dont use a DM [11:35] i assume there is a bug in systemd-logind [11:35] (or in pluse talking to it) [11:35] ogra: DM? [11:35] cjwatson: ping is it possible for you to de-binary new python3-mimeparse please? [11:35] displa/login manager [11:35] ah [11:36] ogra: kdm is broken, lightdm+kde-greeter not yet work for me - working on it now === mmrazik|lunch is now known as mmrazik [11:41] zul: done [11:41] cjwatson: thanks === hrww is now known as hrw === seb128_ is now known as seb128 === doko_ is now known as doko === Mez_ is now known as Mez [12:04] so i have this upstart job http://paste.ubuntu.com/5738554/ [12:05] 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] it doesnt start on boot at all, even though syslog shows [12:05] Jun 6 12:00:11 ubuntu-phablet upstart-file-bridge[460]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofon [12:05] does anyone have an idea why ? [12:05] the file is there (and the syslog entry actually reacts to it) [12:06] running "start ofono" manually works fine too [12:08] i have the feeling that "on started dbus" doesnt do what it should [12:21] 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:22] hmm [12:22] add "--debug" to kernel command-line [12:22] that needs cmdline changes [12:22] thats fiddly [12:23] or add a very early job to "exec initctl log-priority debug" [12:24] ah, it seems the file i wait for is created twice in a row [12:24] (which is weird [12:24] ) [12:24] start on (starting file-bridege and starting dbus) or something like that. [12:25] additionally to file FILE= ? [12:25] upstart-file-bridge emits event if the file added event, and then again if it's changed/added/removed. [12:25] ogra: no, that was start on condition for a job that does "initctl log-priority" tweak. [12:25] oh, i could look for the added event [12:26] ogra: yeah, so there is FILE= which is path to file and EVENT= which is create|modify|delete [12:27] right ... === MacSlow|lunch is now known as MacSlow [12:27] i'm not 100% that i dont have a dangling file there before it gets newly created [12:27] so lets see if that helps [12:28] sigh ... [12:28] if rebooting would only work reliably [12:28] ogra: does /dev/socket exist when file-bridge starts? see limitations on recursive inotify watches in upstart-file-bridge manpages.... [12:29] oh, it might not [12:29] not sure when the file bridge starts, let me take a look [12:30] ah. well, "emits file" [12:30] so i should be starting before it [12:30] *shouldnt [12:31] sigh [12:31] so now i see it starting and then stopping [12:31] ogra: did "stopping dbus" kick in?! [12:32] i dont see why it woould on boot [12:32] i removed it [12:32] 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:33] because ofonod needs dbus [12:34] if thats gone we want to go away as well [12:34] ogra: but when dbus comes back, ofono will not come back. [12:34] thats true for the file too ... i added a stop sequence for it [12:34] ogra: since a file event for the socket will not be emitted ever again. [12:35] let me drop the on stop line [12:36] hmm, nope [12:36] doesnt start at all anymore [12:37] even if it cant find dbus it should just respawn ... i dont see it doing that either [12:38] all i get is [12:38] Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/ofono [12:38] Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/ofono [12:38] Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job went away /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono [12:38] Jun 6 12:37:33 ubuntu-phablet upstart-file-bridge[337]: Job got added /com/ubuntu/Upstart/jobs/_2fdata_2fubuntu/ofono [12:38] why does it have that "_2fdata_2fubuntu/ofono"! thing there ? [12:39] 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] well, let me fiddle with the cmdline [12:39] just takes a bit === greyback is now known as greyback|food [12:40] ogra: above are just funny upstart-file-bridge logs which are "things that file-bridge is tracking / watching / emited / finished dealing with" [12:40] well, i dont get why there seems to be a proper "ofono" job but also the two others [12:42] * ogra wonders why pastebinit hangs [12:44] ah, well, 200000 lines was probably a bit much [12:44] http://paste.ubuntu.com/5738646/ [12:46] ogra: i see dbus running, yet no starting nor started dbus events?! [12:46] weird [12:47] init: Error while reading from descriptor: Bad file descriptor [12:47] looks scary. [12:48] * ogra wonders where that might come from [12:48] ogra: can I see output of `dmesg` ? [12:49] hmm, thats filled with trash already ... i can get you /var/log/dmesg [12:49] ogra: | grep init [12:49] http://paste.ubuntu.com/5738654/ [12:50] there is no init: in it anymore ... [12:50] if the ringbuffer is full dmesg deletes [12:54] ogra: create a "custom logger" =))) http://paste.ubuntu.com/5738665/ [12:55] 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] ogra: also add "or started/starting/stopped/stopping ofono" if you want to notice those as well. [12:55] ditto dbus. [12:57] ugh [12:57] /bin/sh: 0: Can't open /proc/self/fd/9 [12:57] all over the place [13:01] http://paste.ubuntu.com/5738679/ [13:01] should packagekit-qt be removed also? (it unfortunately migrated out of -proposed) [13:02] i see 4 create events for the file === _salem is now known as salem_ === ckpringle_ is now known as ckpringle [13:13] ogra: weird, but the ofono job should be running then. Was that booted two times? as dbus/file-bridge are started twice. [13:14] yeah === Zic is now known as Guest97647 [13:17] * ogra tries something els [13:17] e === 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 [13:46] mardy, Hey, is there a way to turn off UOA in Evolution? [13:47] tedg: open the account in the System Settings, there should be switches next to the various services [13:48] mardy, With Google I have photo search, shotwell, empathy and Google Drive plugin. But no Evolution. === henrix_ is now known as henrix [13:54] tedg, mardy: not sure if you got that before [13:54] mardy, that's not listed evolution, Laney mentioned that there was an error about no matching .desktop yesterday iirc [13:55] eds should supply a .desktop file for it [13:55] Yeah, I also just did a dist-upgrade and I'm getting an account-plugin-google. [13:55] Curious if part of my problems were that I didn't have the right provider. [13:56] it's basically broken with accounts that require 2fa [13:57] https://bugs.launchpad.net/ubuntu/+source/evolution-data-server/+bug/1187699 [13:57] Launchpad bug 1187699 in evolution-data-server (Ubuntu) "Timeout retreiving Google calendar" [Undecided,New] === seb128_ is now known as seb128 [13:58] xnox, so dropping the file stuff and instead depending on the job that creates the file makes it work reliable [13:59] the file is a symlink to a socket which originally lives in /proc ... i guess the file bridge doesnt really get along with that === wedgwood_away is now known as wedgwood [14:01] 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:02] xnox, yeah, that wont help, the thing talking to the socket is the thing i'm starting :) [14:02] 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:03] well, ofono needs the link to be there to start properly [14:03] else it cant talk to the daemon inside the container [14:03] i see. [14:07] how long does it take to get somehting out of -proposed? [14:08] it needs to be installable [14:15] 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] 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:16] In particular why does it select just one number when multiple compilers are installed on the system? [14:16] jdoles: my guess it comes from the compiler it self. and whichever one is the "cc" or "gcc" compiler?! [14:16] xnox: the compiler being? [14:16] xnox: (there is no 'the') [14:16] jdoles: type $ cc --version [14:17] xnox: unless you mean that it has been hardcoded to use cc. [14:17] jdoles: that's the default c-compiler on any system (hence "cc") you can update that symlink if you wich. [14:17] wish. [14:17] and I'm sure distcc can be configured to use alternative compilers. [14:18] xnox: after apt-get install gcc-4.7, I don't have a gcc-4.7 on my path. Why not? [14:19] jdoles: i do. what's your path?! =) [14:19] zul: unless you are talking about SRUs verification from $stable-proposed -> $stable-updates ?! [14:19] xnox: nah im good thanks [14:20] xnox: the default PATH + some site specific ones. [14:21] xnox: actually I only have gcc-4.7-base. [14:21] xnox: and that is a very small package which doesn't seem include an actual compiler. [14:22] 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] tedg is running into this right now with recoverable problems [14:22] why this didn't occur to me sooner, I have no idea [14:22] I noticed that bzr does the right thing here for its crashes [14:23] jdoles: dlocate /usr/bin/gcc-4.7 tells me you want: gcc-4.7: /usr/bin/gcc-4.7 [14:23] jdoles: as in $ apt-get install gcc-4.7 [14:23] xnox: I did that. [14:24] xnox: Note, selecting 'gcc-4.7-base' for regex 'gcc-4.7' [14:25] xnox: alternatively, how can I make distcc use an older compiler? [14:28] xnox: thanks for fixing the software-center package branches! [14:28] xnox: is your other nickname nox? [14:28] jdoles: no. [14:29] (not for more than 12 years now anyway) [14:29] 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] aah [14:29] apw: so cryptsetup and the like [14:30] that would drop a lot indeed [14:30] pitti, there is also some cryptsetup in there, so it seems that something in the recent image is pulling that in [14:30] > lib/libcryptsetup.so.4 [14:30] is added in the later image [14:30] (in its initrd) [14:30] 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:31] pitti, how the heck would one figure that out [14:31] pitti: apw: whilst images have cryptsetup, the default unencrypted/lvm-less desktop shouldn't have cryptsetup in the initramfs. [14:31] does distcc not support doing "CC=/usr/bin/foo-cc distcc" or something? [14:32] xnox, as soon as cryptsetup is installed we will add plymouth and junk into the initramfs [14:32] dobey: i mostly saw it use wrappers & diverts everytime I had to use distcc. [14:32]