=== buxy_bak is now known as buxy === catbus1 is now known as catbus1-afk [01:07] Is there a dpkg-source --clean type command? [01:53] does anyone have any tips for how to manage distro patches for gcc without going crazy? [01:58] i've tried gbp pq a bit but it fails for reasons i don't understand [02:22] oh, i think i see why it failed for me [03:16] tokolike debuild clean? [03:16] err [03:17] YokoZar: like debuild clean? [03:20] cjwatson: I was more interested in a sort of revert type feature. Basically a package's clean instructions weren't completely cleaning it so a second binary build was balking about having uncommitted changes to the source. [03:21] YokoZar: oh, well, use a version control system. [03:21] or re-unpack. [03:21] Yeah that's what I thought :p [03:22] Or maybe reverse apply the patch shown in the temp file [03:22] it's a bug if clean doesn't clean, of course. [03:22] Yeah, already filed that one :P === _salem` is now known as _salem [04:40] Good morning [04:45] stgraber: ack; I filed bug 1361964 [04:45] bug 1361964 in calibre (Ubuntu) "FFE: Port to Qt5" [Undecided,New] https://launchpad.net/bugs/1361964 === _morphis is now known as morphis === asac` is now known as asac [06:45] good morning [06:54] cjwatson, can you please unblock insighttoolkit4? it should just be three "no change rebuild" away :) [06:54] hi dholbach :) [06:55] hi LocutusOfBorg1 [06:59] sil2100, did you ask to remove lucene++ from new queue? [06:59] I got a strange mail, I would like to ask you prior to ask more informations ;) [07:09] ivoks, happy birthday! :) === dbarth__ is now known as dbarth [07:21] dholbach: :) thanks [07:27] LocutusOfBorg1: not after midnight, find another victim :) [07:30] LocutusOfBorg1: err, in any case, insighttoolkit4 isn't blocked [07:49] cjwatson, no problem ;) [07:50] have a nice day :D === inaddy is now known as tinoco === henrix_ is now known as henrix === ValicekB_ is now known as ValicekB [08:19] how can I ask something to ubuntu-security people? [08:19] I'm wondering about CVE-2014-5119 [08:19] ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem. When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-5119) [08:53] LocutusOfBorg1: I'll be uploading to utopic for that tomorrow, and we'll get it sorted in stables soon. === ikonia_ is now known as ikonia === Riddelll is now known as Riddell === soren_ is now known as soren [09:35] thanks infinity :) === timrc is now known as timrc-afk [10:21] pitti, is it possible to cache packages when using adt-run? === marcustomlinson is now known as marcustomlinson| === marcustomlinson| is now known as marcustomlinson [10:21] darkxst: I just use apt-cacher-ng on my workstation; mk-sbuild, adt-build-lxc, and adt-buildvm-ubuntu-cloud all detect and use that automatically [10:22] yes, otherwise you'll go crazy [10:23] pitti, ok, will try that out [10:23] darkxst: curious, you are the second person today who asks me about that; perhaps it's time for a blog post :) [10:26] pitti, could be ;) I never used to care when I had a 100Mbps internet connection, but now suffering slow adsl [10:27] darkxst: yeah, I'm just going to blog about it this afternoon, lest I'll explain it n times again :) [10:27] and I guess I mostly use pbuilder and sbuild which do cache, but possibly I configured that [10:29] darkxst: schroot doesn't cache by default [10:30] (i. e. sbuild) [10:31] pitti, it does here, though like I said, probably had to tweak config for that [10:31] *nod* [10:32] and with cached packages and eatmydata, sbuild is incredibly fast [10:34] darkxst: I put all overlays (schroot, lxc, qemu) on /tmp which is on a tmpfs for me; even faster [10:34] * pitti will include that in the blog post [10:35] it's a bit ironic that first one buys an expensive 500 MB/s SSD and then puts quite some effort in not touching it by keeping everything in RAM, but it's still worth it :) [10:36] sure is :) [10:36] my first ssd broke after a year, the warranty replacement has been going for nearly 2y now.. [10:37] guess doing builds on tmpfs helps a bit [10:37] but seeing a schroot with 300 build deps download and unpack in 5 seconds is pretty neat [10:37] pitti: if you are writting a sbuild/pbuilder performance tip post, putting this in fstab /dev/mapper/lvm-chroot /srv/chroots ext4 data=writeback,commit=3600,nobarrier 0 1 [10:37] yeah, /tmp is my cwd most of the time :) [10:37] is useful if you don't have enough ram to build large packages [10:38] (probably less important with ssd) [10:38] jtaylor: ah, that probably needs some more setup (LVM), though? I guess you should perhaps blog about this too [10:38] I have 16 GB, thus 8 GB tmpfs, I never ran into trouble so far [10:38] pitti: you can mount any partition you use as BUILDPLACE like that, though don't put important data on it :) [10:38] I'm not Sweetsha1k or the kernel team, of course :) [10:39] jtaylor: ah nice, like a bind mount with degraded data integrity guarantees? [10:40] not a bind mount, a proper mount [10:40] but one needs to set up the devmapper fist [10:40] first [10:40] yes its just a workspace partition which will likely get corrupted on stuff like powercuts [10:40] jtaylor: tell you what, I'll create a wiki page instead of a blog post; probably more useful [10:41] lvm makes it easy to have special purpose partitions, but you could use real partitions too === timrc-afk is now known as timrc [11:06] jtaylor, darkxst: I edited https://wiki.ubuntu.com/SimpleSbuild which already has most of the stuff [11:06] it uses /dev/shm/ which is always a tmpfs, and avoids mangling the symlinks in /var/lib/schroot/ [11:10] pitti, ok, will take a look tomorrow ;) === MacSlow is now known as MacSlow|lunch === Sweetsha1k is now known as Sweetshark === superm1_ is now known as superm1 === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === NComman`` is now known as NCommander === NCommander is now known as Guest81462 === Pici` is now known as Pici === smoser` is now known as smoser [12:44] sil2100, can you please remove lucene++ from mentors? [12:45] I would like to upload again the -1 version [12:45] and BTW how do you feel about maintaining under git in collab-maint? === Guest81462 is now known as NCommander === salem_ is now known as _salem [13:11] stgraber, hallyn, so I ran the uitoolkit tests last night and we're still getting a 8% failure with cgroups enabled. [13:11] So I don't think the underlying bug is fixed. [13:11] What should I capture for a debug log? [13:13] yeah, why would it be fixed ... [13:13] capture the /var/log/upstart/cg{manager,proxy}.log and /proc/pid/cgroup of the login job; but it also may be worth instrumenting systemd-shim [13:13] ogra_: bc cgmanager should now always be running when the login job starts [13:13] your change definitely didnt change the phone boot process [13:14] ogra_, We uploaded a new cgmanager package with a proposed fix. [13:14] (as i said yesterday) [13:14] can you post some bootcharts? [13:14] So I don't think this is a boot issue. [13:14] not atm, i have non submitted code on all devices i could test on [13:14] Because in the same user session I'm getting ones that work and ones that don't. [13:15] you can use phablet-bootchart from phablet-tools to generate a chart though [13:15] Specifically, over 288 application instances created about 8% aren't getting cgroups. [13:15] tedg: huh. that's not in keeping with info i'd gotten from jodh [13:17] hallyn, I think he might have ended up chasing something different. [13:18] hallyn, The only thing in cgmanger log is: cgmanager:per_ctrl_move_pid_main: Could not determine the requested cgroup [13:18] pitti: <3 :) [13:18] mapreri: yw :) [13:19] hallyn, And I actually have that as many times as I have failure. [13:19] tedg, hallyn, are we sure the old kernels we use on the phone have actually all features and functions in cgroups that we use ? [13:19] dont forget we are using BSP kernls [13:19] pitti: 7 minutes between the request and the sponsorship. You can mark it as a personal record :) [13:20] they don't have all the features which is why both cgmanager and cgproxy have to run [13:20] mapreri: I think I've been faster with IRC requests, but thanks :) [13:20] ^^ [13:21] hallyn, hmm [13:21] i wonder if one steps on the toes of the other then [13:23] hallyn, So do you know what could cause that error? [13:23] hallyn, Is there a way to turn on more verbose debugging from cgmanager? [13:24] tedg: /etc/default/cgmanager -> "cgmanager_opts="--debug"". jodh was doing that plus extra debugging with a custom patch [13:25] but at this point, i think what we need to know, [13:25] is at your 8% failures, (1) what was the cgroup of the upstart job itself, [13:25] (2) the upstart job contents, and (3) what was the cgroup of the launched app [13:26] in the cases jodh was pursuing, the upstart job wasn't in a cgroup it controlled. But that was because the whole login session in his cases were not in the right cgroup [13:26] if it's 8% not getting the right cgroups, then you're hitting something different [13:27] so last night my thinkpad sudenly went dark, wouldn't turn back on, and smelled of burning wire. this morning it turns on. but do i want it to.... [13:27] hallyn, So we're creating an cgroup for the upstart job, so I'm not sure what you mean by "what was the cgroup of the upstart job itself" or "it's contents" [13:27] The app is then put into that created cgroup [13:28] So there's no other group for the app === _salem is now known as salem_ [13:30] wgrant: to confirm, RTM langpacks shoudl appear at https://translations.launchpad.net/ubuntu-rtm/14.09/+language-packs , right? (once this is set up) [13:30] tedg: something forks the task which will become the user upstart job [13:30] pitti, btw https://lists.ubuntu.com/archives/rtm-14.09-changes/2014-August/thread.html ... in case you want to subscribe [13:31] ogra_: ah, thanks; but after many years I actually managed to ween myself off reading -changes [13:31] haha [13:31] (in some desperate attempt to reduce my ginormous email/IRC budget a bit) [13:31] "wean" [13:31] hallyn, Yes, upstart does that internally. [13:32] tedg: and i want the cgroup at that point [13:32] i still use these lists ... but 90% of the mail is just marked read [13:32] hallyn, Hmm, okay, perhaps stgraber knows how to get that. [13:34] tedg: if there is simply a user-owned /sbin/init (and it is the one that will fork) then its cgroup will be fine [13:34] hallyn, Ah, okay, I can get that. [13:35] hallyn, http://pastebin.ubuntu.com/8159489/ [13:37] pitti: Yep, that's the place. Just worked out the last ubuntu<->ubuntu-rtm sharing issue today. [13:38] tedg: yeah, but the question is is that somehow different when the 8% failing jobs start. [13:38] wgrant: awesome! [13:38] is it always a different subset of jbos that fail? [13:39] hallyn, Yes, guessing it's a race of some kind. Specifically the UI Toolkit seems to show it the best which has a bunch of "applications" which are each tested for a couple seconds. [13:41] tedg: is that 'Yes, it's always a different set of tasks' ? [13:42] hallyn, It's always the same job, but a different set of tests. All the applications are under the "application-legacy" job, but have an individual instance. Different sets of those instances fail each time. [13:43] hallyn, So the "application-legacy" job fails to start (like no logs, no nothing) 8% of the time. [13:43] wait, fails to start at all, or fails to start int he right cgroup? [13:43] Fails to start at all [13:44] sorry if we're talking in circles here - but do we know they are failing to start bc of cgroups not being set up? [13:45] No problem, we know that if we remove the cgroup directive of the Upstart job things work. [13:45] And we know that we get the error from cgmanager [13:45] (or I know, others may know more) [13:47] ok i think i will add some nih_traces to cgmanager to help us debug there [13:56] tedg: pushing a new cgmanager (0.30-1ubuntu2) would like to see the /var/log/upstart/cgmanager.log with that pkg [13:57] hallyn, Cool, I have a run going with the --debug flag I'll grab that package when it's up. [14:06] hallyn, Hmm, I must have screwed that up, I got no cgmanager log this time. http://pastebin.ubuntu.com/8159755/ [14:13] tedg: /var/log/upstart/cgmanager.log doesn't exist? you've done 'stop cgmanager; start cgmanager' ? [14:14] hallyn, Well, I rebooted. [14:15] hallyn, But, yes, no log [14:15] hallyn, Looking in cgproxy log I see a couple odd messages "cgmanager_create: returning 0; existed is -1" [14:15] hallyn, Sometimes that's a "1" sometimes "-1" [14:16] those are fine. returning 0 means it worked [14:17] K === Mikee_C is now known as Mikee_C_afk === Mikee_C_afk is now known as Mikee_C [14:47] cjwatson, When I run ./update for my meta package I see the following in the logs '! Setting features {no-follow-recommends} for seed required' [14:47] What does that mean exactly and what action is required? [14:48] I've noticed that the installed system is not installing recommended package by default and suspect this message may trying to tel me something 😉 [14:48] flexiondotorg: it means that recommends of recommends are not added [14:48] flexiondotorg: see man germinate [14:49] shadeslayer, Thanks. [14:49] * flexiondotorg goes reading [14:49] ah hm [14:49] no, just 1st level is off [14:49] so recommends of a package in the seed are not added [14:49] flexiondotorg: yw [14:51] shadeslayer, Why is no-follow-recommends being enabled. I have not set it in my seeds. [14:51] possibly turned on by default? [14:51] I never bothered investigating tbh === mbarnett` is now known as mbarnett [15:05] Hi devs :) [15:25] could someone merge usb-modeswitch from Debian unstable - currently usb-modeswitch from Ubuntu 14.10 and 14.04 doesn't work with latest usb-modeswitch-data releases and doesn't support lots of Huawei (and other) modems :( [15:25] oSoMoN, I frown at your HTML emails :P [15:26] See bug #1308895 , bug #1192297 and other bugs at https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch and https://bugs.launchpad.net/ubuntu/+source/usb-modeswitch-data [15:26] bug 1308895 in usb-modeswitch (Ubuntu) "Please merge usb-modeswitch from Debian unstable - Huawei E3531 does not automatically switches to modem mode (no udev rules for this modem in Ubuntu's /lib/udev/rules.d)" [Medium,Confirmed] https://launchpad.net/bugs/1308895 [15:26] bug 1192297 in usb-modeswitch-data (Baltix) "Huawei E3131 mobile modem not recognized" [Medium,Confirmed] https://launchpad.net/bugs/1192297 [15:29] Saviq, my what? since when am I sending HTML emails? [15:30] that would be a terrible heresy [15:31] oSoMoN, I got https://lists.launchpad.net/ubuntu-phone/msg09661.html in HTML [15:32] Saviq, blame gmail then, I just replied inline using the web interface, as I always do [15:32] and couldn't find your reply, because I frown at not cutting the irrelevant parts out ;) [15:32] oSoMoN, I blame gmail for a lot of things, yeah :) [15:32] Saviq, right, my bad for not removing irrelevant context, I’m in a rush… [15:33] oSoMoN, like we all are, no worries :) [15:36] also for example bug #1328412 [15:36] bug 1328412 in usb-modeswitch-data (Ubuntu) "Huawei E398 GSM modem configuration data not included" [Undecided,Confirmed] https://launchpad.net/bugs/1328412 === rww_ is now known as rww === Zic_ is now known as Zic [17:38] anyone have a idea how autologin configs get written from ubiquity? [17:57] shadeslayer: casper? [17:57] I'd suppose that casper writes a lightdm autologin conf [17:57] nope the option from the installer [17:57] I've already put in sddm support in casper [17:57] yeah, that simply closes ubiquity-dm I suppose [17:58] ubiquity-dm unit stops -> proper DM starts -> find autologin logs in [17:58] but in ubiquity you can do "Log in automatically" [17:58] ah that one [17:58] yes [17:58] that one :p [17:58] surely somewhere in ubiquity :P [17:58] I found self.preseed_bool('passwd/auto-login', auto_login) [17:58] that's debconf though, isn't it [17:58] right [17:58] so what actually writes the config then [17:59] ( FYI that snippet is from ubiquity ) [18:01] user-setup? if that still is a thing [18:01] shadeslayer: [18:01] ./user-setup-apply:autologin-session=lightdm-autologin" [18:01] ./user-setup-apply: sed -i "s/^$\(str *$\?autologin-user\)=.*$/\1=$USER/g;" $ROOT/etc/lightdm/lightdm.conf [18:02] ah [18:02] cheerio [18:03] apachelogger: huh, grepping from bzr doesn't give me anything [18:04] grepped from pkg [18:04] lp:~ubuntu-core-dev/user-setup/ubuntu says the control [18:04] https://code.launchpad.net/~ubuntu-installer/user-setup/master says git [18:05] the cake is a lie! [18:05] ^^ :p [18:05] shadeslayer: well, that's the import, since we use lightdm the coredev branch surely is our derivate of it ;) [18:06] yeah I guess [18:09] anyway, will fix it tomorrow [18:21] hallyn, Here's the cgmanager log, don't see anything obvious, looking for which apps failed now: http://paste.ubuntu.com/8161530/ [18:23] hallyn, It looks like the group is getting removed and then someone is looking for it? [18:25] hallyn, Seems like normally it's "created/moved/removed" but there are cases of "created/removed/invalid path" [18:27] tedg: the cgroup will be removed if it becomes completely empty. could that be happening? [18:27] (that is, no tasks in the cgroup and no sub-directories) === kirkland` is now known as kirkland === kirkland is now known as Guest82850 [18:28] hallyn, Guessing it must because there's no move. [18:28] hallyn, So it's created, nothing is moved in, so it's empty. [18:29] no, it has to become empty [18:30] there has to be a task, which is moved out or exits, [18:30] then the cgroup is autoremoved === Guest82850 is now known as kirkland` [18:30] tedg: but that paste doesn't have any failures [18:30] oh there' sone [18:30] hallyn, It has the "Invalid path" [18:31] * tedg searched for "fail" first too :-) [18:32] Hmm, looks like it's being removed before anything is moved into it. [18:32] tedg: Removed /run/cgmanager/fs/freezer//user.slice/user-32011.slice/session-c1.scope/upstart/application-legacy-tmpa3LBk3-1409158710956199 for 9587 (0:0) [18:32] yeah [18:33] who's removing it [18:33] mind you cgmanager won't actually remove it if tasks are in it, [18:33] 9587 :-) [18:33] heh [18:34] It strikes me that it is PID+1 [18:34] suppose cgmanager could spit out /proc/pid/cmdline, but not sure that'd be meaningful [18:34] so where/when does upstart remove it [18:35] sigh, i'll probably be dropping in about 20 mins - bc my new hotspot's batt life is apparently < 2 hrs. poc [18:35] tedg: you're running stock utopic upstart? [18:35] Correct [18:35] 1.13.1-0ubuntu3 [18:39] upstart never calls cgmanager_remove_sync. [18:40] is there a way you can have application-legacy be straced? [18:43] Uhm, I can strace the binary, but last time it looked like our binary wasn't even getting called. [18:44] Like it stopped before execing to us. [18:45] Wait, I'm looking at the one "tmpN5uJfu" and it seems like it's getting created twice. [18:46] Wondering if we're getting duplication in the tmp file generator. [18:46] No, because the timestamps are the same. [18:47] Looks like it gets created 3 times, removed once. [18:47] and why is it getting creatd 3 time? [18:48] shouldn't each one have a separate tmpnam? [18:48] In theory, but more so the timestamp should be incrementing. [18:48] but my q is - is the pid which is asking for the removal showing up in the strace? (i.e. is it part of the app somehow, or is it upstart) [18:49] Huh, so it looks like they're all created 3 times. [18:49] Guessing job, post-start, post-stop. [18:49] heh makes sense [18:49] can you pb the upstart job? [18:49] pb? [18:49] pastebin [18:50] Ah, sure [18:50] 12% battery remaining, will be lunchtime soon [18:50] maybe time fo ran email to warthogs asking for best hotspot batt life [18:50] http://paste.ubuntu.com/8161783/ === roadmr is now known as roadmr_afk [18:52] So It looks like the last create is the one that doesn't get moved in. [18:52] tedg: oh. [18:52] the remove is being done on behalf of cgm-release-agent [18:53] (I'm assuming) [18:53] I'd forgotten it actually goes through dbus to cgmanager as well [18:54] so workarounds would include (a) an upstart job which sets notify-on-release to 0 for all mounted cgroups, [18:54] (b) an option to cgmanager ot say don't remove on empty, [18:54] (c) upstart simply not setting remove-on-empty [18:54] having typed that, c seems most reasonable for now [18:55] Would it be bad if we had a lot of left over cgroups? [18:55] so i think upstart should wait until post-stop is run (if any) before setting remove-on-empty, then attempt to remove by hand [18:55] over time, yes [18:55] I mean we expect people to never reboot their phone. [18:55] but i'm not saying never remove them [18:55] i'm saying wait until we know the job is done before setting automreove [18:55] Ah, okay. That makes sense to me. [18:56] as a short-term workaround, just remove the calls to cgmanager_remove_on_empty_sync() [18:56] (in init/cgroup.c) [18:56] then we should probably wait for jodh to get back for the proper fix [18:56] So, *I* can't do that. [18:56] :-) [18:56] stgraber, can you? ^ [18:56] well, we only want it on that phone for now right? [18:56] or do we want it in all of utopic? [18:57] The goal is to not have a special build for phone. [18:57] ok, my hotspot is about gone - i'll be back after lunch, sorry. [18:57] If we have to, I guess that's possible, but would prefer not to. [18:57] SO disappointed [18:57] NP [18:57] tedg: let's decide in like an hour [18:57] +1 [18:58] (and maybe when i look at the upstart source it'll be obvious how to do the proper fix myself) === plars_ is now known as plars === Mikee_C is now known as Mikee_C_afk [20:22] seems like just doing it at job_process_terminated() should suffice [20:24] hm, upstart is source v 1.0. that's nerve-wracking === roadmr_afk is now known as roadmr [20:56] hallyn, Does that run when all the job processes are done, or just the main one? [20:56] hallyn, It seems like in some cases it is the post-stop that's having issues. [20:58] tedg: the reason it is having issues is that it runs after the job has exited, meaning the cgroup gets removed :) [20:58] and the reason it's a race is that the post-stop *does* create the cgroup, [20:59] but sometimes the autoremove happens after the last create, but before the exec [21:00] Yes, I see that, but I was worried that if you're setting the autoremove after the main job, then it'd be the same. [21:00] right [21:28] tedg: anothe rpossibility would be to ues a different cgroup name at post-stop [21:28] but, lp:ubuntu/utopic/upstart/cgroup-race1 is the first guess [21:29] hm, i'll create a tree with my second guess too. then the ppl who actually know what they're doing can critize both [21:35] i haz doubts on upstart init/cgroup.c:439 [21:35] it checks for cgname->expanded being NULL, but that's after having done a strcmp including it [21:36] oh, nm [21:45] hallyn, So are you by chance at debconf? [21:45] so lp:~serge-hallyn/ubuntu/utopic/upstart/cgroup-race2 would be the other way. What are the odds that would actually work... [21:45] tedg: nope [21:45] Would like to figure out the "final" solution between folks [21:45] Hmm, okay. [21:46] I'll put together an e-mail to see if we can grab those folks that are. [21:46] tedg: I suspect the right answer will simply be removing for real (including killing any remaining jobs) at FINAL job state [21:47] meanwhile though i'm going to build a package with cgroup-race2 [21:47] hallyn, Honestly, that'd be cool as I'm doing that in the job currently "cgroup-reaper" but would love to have Upstart do it for me :-) [21:47] tedg: yeah and it really should do that [21:48] or, cgmanager should perhaps offer a 'RemoveAndKill' method [21:48] and upstart should then use that === salem_ is now known as _salem === asac` is now known as asac [22:50] tedg: incroyable! my patch seems to work [22:51] pre-start is in /xxx_2, script in /xxx_0, post-stop, well, hasn't started yet [22:51] (xxx_4) [22:52] and after stop, cgroups are gone [22:52] it does multiply the cgroup setup being done, but i think that' sok [23:03] tedg: tossed the patch to jodh (in the form of a merge proposal against the wrong tree)