[04:21] <pitti> Good morning
[04:24] <pitti> slangasek: mind pushing your systemd-shim update to bzr?
[04:59] <slangasek> pitti: done
[04:59] <pitti> slangasek: thanks
[06:00] <doko> pitti, had you a look at the failing pythonx.y test with the proxy set?
[06:00] <pitti> doko: yes, I mailed you about the result?
[06:00] <doko> pitti, no, you mailed a workaround, not a fix
[06:00] <pitti> doko: I mean I also mailed you the results with the option dropped that you suggested
[06:01] <pitti> "-network"
[06:01] <pitti> that still doesn't work, so I kept the "unset proxy" for now
[06:04] <doko> pitti, does the proxy handle ftp?
[06:05] <pitti> doko: there's no $ftp_proxy set right now; trying
[06:07] <pitti> doko: no, I'm afraid not
[06:07] <pitti> i. e. our squid.internal doesn't handle ftp
[06:11] <doko> pitti, and smtp?
[06:13] <pitti> doko: smtp is certainly not something that's being handled through a proxy; but if you mean "can I send mail from that machine", there's no local MTA
[06:13] <pitti> (but a test hopefully doesn't try that :) )
[06:14] <doko> pitti, no, looking at the test_smtplib test
[07:04] <dholbach> good morning
[07:37] <kdeuser56> caribou: how would I setup kdump with an encrypted root? I'd like to dump to the boot partition, but I could not get it to work
[08:07] <dholbach> @pilot in
[08:14] <seb128> dholbach, hey, enjoy the piloting ;-)
[08:14] <dholbach> thanks seb128
[08:17] <caribou> kdeuser56: ouch, never thought of that
[08:17] <caribou> kdeuser56: which version ?
[08:18] <kdeuser56> caribou: I am on latest utopic
[08:18] <kdeuser56> caribou: there are a few bug reports against fedora/red hat and according to them it has been fixed there ...
[08:19] <kdeuser56> caribou: https://bugzilla.redhat.com/show_bug.cgi?id=1053045
[08:19] <caribou> kdeuser56: they use a totally different codebase
[08:19] <kdeuser56> and https://bugzilla.redhat.com/show_bug.cgi?id=1028397
[08:19] <caribou> kdeuser56: & changing KDUMP_COREDIR in /etc/default/kdump-tools didn't work ?
[08:19] <kdeuser56> oh ...
[08:19] <kdeuser56> caribou: I simply changed to /boot ... did not work
[08:20] <kdeuser56> caribou: can I somehow specify a partition?
[08:20] <caribou> kdeuser56: that's what it should do but it must already be able to mount / first. I don't know how it behaves when it is encrypted
[08:21] <caribou> I mean the kexec part of things
[08:21] <kdeuser56> caribou: hm ... can we somehow make it not mount root?
[08:21] <kdeuser56> caribou: mounting root will be problematic, since the screen will be frozen during panic and I can't see the password prompt
[08:21] <caribou> kdeuser56: no as the whole sequence implies a normal reboot up to the point where kdump kicks in
[08:22] <kdeuser56> caribou: hm... the fedora guys somehow managed to not mount root, if I got that right
[08:23] <caribou> kdeuser56: because of the fact that the initial boot sequence on Fedora is different
[08:23] <kdeuser56> caribou: so impossible on ubuntu? :-(
[08:23] <caribou> kdeuser56: I would not say *impossible* upfront, but it requires some investigation
[08:24] <kdeuser56> caribou: I'd be happy to provide as much information as needed
[08:24] <caribou> kdeuser56: I would suggest to open a bug o kdump-tools(ubuntu) on the matter
[08:24] <caribou> kdeuser56: the problem might be similar on Debian as well, but I maintain both so if needed I'll create a bug ther
[08:24] <kdeuser56> caribou: what information would you need there apart form how my partitions look like?
[08:25] <caribou> kdeuser56: maybe the kind of error message you get when changing KDUMP_COREDIR to /boot
[08:25] <kdeuser56> caribou: where can I find those error messages?
[08:25] <kdeuser56> caribou: I can't see any on the screen, because it simply hangs forever and wont reboot
[08:25] <caribou> kdeuser56: anything you see on the screen if any otherwise don't bother
[08:26] <caribou> then just mention that fact
[08:27] <kdeuser56> caribou: Okay I have to be somewhere soon, I'll open the bug report later, may I ping you again for further communication?
[08:27] <caribou> kdeuser56: sure no problem
[08:27] <caribou> kdeuser56: I'm here all the time
[08:27] <kdeuser56> caribou: thank you very much
[09:15] <doko> Logan_, online?
[09:28] <Mirv> mitya57: hi! the qtxmlpatterns upload is hitting us because of the versio checks done by Qt.. https://launchpadlibrarian.net/184302130/buildlog_ubuntu-utopic-amd64.libusermetrics_1.1.1%2B14.10.20140908-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:28] <Mirv> mitya57: it'd either need manual forcing of the version number to 5.3.0 in qmake.conf or alternatively a revert
[09:33] <pete-woods> ogra_: hi, not sure if you're the right person to bug about this, but basically when developing (click packaged) scopes we need a bunch of stuff to be present both on the phone image, and devel packages in the SDK
[09:33] <pete-woods> so I have this MR: https://code.launchpad.net/~unity-api-team/ubuntu-seeds/scope-facing-apis/+merge/233535
[09:34] <pete-woods> as at the minute, it's just luck that makes those libraries available at runtime on the phone image
[09:34] <pete-woods> and some of them simply aren't present in on the "devel" side
[09:35] <ogra_> pete-woods, we are pretty must at the very edge if it comes to available space on the image, do these three libs add anything ? also if you seed in sdk-libs they need to be part of the ofiicial framework and we commit to maintain them for the lifecycle of the device
[09:35] <ogra_> s/must/much/
[09:35] <pete-woods> ogra_: they are already present on the device afaik
[09:35] <ogra_> good
[09:36] <ogra_> what about the framework ?
[09:36] <pete-woods> ogra_: well we better had commit to maintaining them, as our example scopes in the SDK all use them :)
[09:36] <ogra_> (we can just seed them in touch or touch-core otherwise)
[09:36] <ogra_> ok
[09:36] <ogra_> i'll try to get to merge it later today then :)
[09:36] <pete-woods> ogra_: they are mostly tvoss libraries (except the json one)
[09:37]  * ogra_ puts a "tvoss will maintain it" sticker on them 
[09:37] <ogra_> :)
[09:37] <tvoss> ogra_, that sticker is already there :)
[09:37] <ogra_> haha
[09:37] <tvoss> ogra_, but thanks, I like badges ;)
[09:39] <lfaraone> so, I can technically just commit these (barring FeatureFreeze), but do bug 1366718 and bug 1366723 look like reasonable feature requests? I sort of want to sanity-check a bit :)
[09:39] <lfaraone> sorry, first bugnumb should be bug 1366721
[09:40]  * lfaraone waves at dholbach
[09:40] <dholbach> hi lfaraone
[09:40] <lfaraone> how's lyfe?
[09:40] <dholbach> good good - how about you?
[09:41] <lfaraone> not bad. Just making sbuild do evil things, because of layer 9 reasons.
[09:45] <dholbach> lfaraone, if you're adding new options, it might make sense (my opinion) to have a chat with folks who put some work into mk-sbuild, for example kees or tumbleweed
[09:45] <dholbach> (I just ran 'bzr blame' on the script to get an idea)
[09:45] <lfaraone> thanks!
[10:56] <dholbach> smb, happy birthday!
[10:59] <ogra_> smb, yeah ... happy b-day !
[11:04] <cjwatson> ~>
[11:05] <cjwatson> sorry
[11:09] <ogra_> snakes !
[11:10] <kdeuser56> caribou: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1366754
[11:12] <caribou> kdeuser56: got it
[11:13] <kdeuser56> caribou: thanks, for any additional info, experimts etc. just ask
[11:14] <davmor2> ogra_: oh ascii snakes that is definitely what the phone needs you should file a bug instantly ;)
[11:14] <ogra_> davmor2, well, colin developed it already it seems, we just need to merge it ;)
[11:14] <davmor2> ogra_: hahaha
[11:15] <caribou> kdeuser56: sure
[11:23] <pete-woods> Mirv: sorry to nag. but do you have any update on the broken qtxmlpatterns-opensource-src package? are we reverting? / (what page should I repeatedly hit F5 on?)
[11:28] <Mirv> pete-woods: I was hoping to get a reply from mitya57, but I guess I need to upload on my own soon(ish). it's when there's something new in release pocket at https://launchpad.net/ubuntu/+source/qtxmlpatterns-opensource-src/
[11:29] <Mirv> to not revert the changes in that upload, I'll try that forcing of module version (that I've successfully used in the past) as a workaround, and I'll use your silo as testing grounds :)
[11:29] <pete-woods> Mirv: that sounds like a pragmatic solution
[11:30] <pete-woods> (furiously hitting F5) :)
[11:56] <rbasak> infinity: possible MySQL ABI breakage: http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2014-September/007015.html
[11:56] <rbasak> infinity: thank you for getting me to check!
[12:24] <Mirv> mitya57: hey, it seems you just did an ubuntu2 upload! I just finished testing that this is what would work, if you don't mind doing ubuntu3 as well as yours failed to build: http://pastebin.ubuntu.com/8290061/
[12:25] <Mirv> it's a trick I learned when testing single module updates earlier
[12:30] <dholbach> @pilot off
[12:30] <udevbot> (pilot (in|out)) -- Set yourself an in or out of patch pilot.
[12:30] <dholbach> @pilot out
[12:37] <cjwatson> Mirv: (should be "mkdir -p .git" there for idempotency)
[12:39] <Mirv> ack
[12:52] <Mirv> mitya57: thanks! and right, that works too.
[12:52] <Mirv> pete-woods: your F5 must have worn out by now, but during the last 800 refreshes you've seen that "ubuntu3" in proposed, so once that hits release pocket your build will start working shortly
[12:59] <janimo`> jamespage, hi, do you know what the status of golang 1.3 in utopic is?
[13:00] <jamespage> janimo`, I think its not in yet
[13:00] <janimo`> jamespage, by status I meant plans and ETA :)
[13:00] <janimo`> sorry if I was not clear
[13:01] <janimo`> jamespage, any blocker for just syncing it?
[13:01] <jamespage> janimo`, yes - you'll need to merge it to preserve the alternatives stuff
[13:01] <janimo`> jamespage, but no crashers or regressions on packages using it?
[13:02] <jamespage> janimo`, I have no idea
[13:02] <jamespage> janimo`, sorry - I've not tested anything related to the 1.3 upgrade
[13:02] <janimo`> jamespage, is anyone 'owning' golang packages in Ubuntu?
[13:02] <jamespage> janimo`, I heard rumor that the next docker.io update was blocked due to the 1.3.x release
[13:04] <jamespage> janimo`, was there a specific reason you wanted to upgrade to 1.3.1?
[13:05] <janimo`> jamespage, trying to build some nonpackaged apps from github which already rely on 1.3
[13:05] <janimo`> I can build Go from sources but since we'd want 1.3 anyway soon I thought I'd ask
[13:09] <jamespage> janimo`, I'd not stand in the way of a golang 1.3 bump but I lack to time capacity to reverse build and test everything in the archive; as golang statically links rebuilds are required.
[13:10] <doko> directhex, didrocks, Laney, seb128: not sure who of you disabled pch for armhf and arm64 ... this seems to work with 4.9. so please re-enable this when you see it in merges /update etc ...
[13:10] <janimo`> jamespage, so landing is not happening until those tests happen? I do not know the current landing process well
[13:10] <seb128> doko, what is "pch"?
[13:10] <directhex> snuh?
[13:10] <janimo`> jamespage, we don;t just upload and then fix anything that is reported broken :) ?
[13:10] <doko> precompiled header files
[13:11] <seb128> doko, I lack context to understand what you are asking, is that about a specific package,
[13:11] <seb128> ?
[13:11] <jamespage> janimo`, I'm not sure the release team (or I) would signoff on that approach
[13:11] <jamespage> we're past feature freeze so this would need a release team signoff, and they should ask for testing evidence
[13:11]  * janimo` is longing for the good old times when development releases of ubuntu were development releases :)
[13:12] <doko> seb128, no, but afaicr the desktop team disabled that for a few packages
[13:12] <ogra_> janimo`, we had a release schedule back then as well :P
[13:12] <ogra_> freeze is freeze
[13:14] <janimo`> ogra_, right, I just thought someone was responsible for Go if we're using it seriously or I'd have brought this up when 1.3 released, months ago :)
[13:15] <ogra_> we only use it semi seriously except in juju i think
[13:16] <ogra_> (which doesnt live in the archive afaik)
[13:16] <pete-woods> Mirv: thanks! I had noticed you put the new package in the silo :)
[13:17] <seb128> doko, do you have an example?
[13:18] <doko> seb128, opencv
[13:20] <hallyn> desrt: then again, after writing the code, i'm a bit worried about giving all unpriv users the ability to take O(nlogn) of cgmanager's time with a single call where n is npids (i.e. trivial to bump)
[13:21] <hallyn> now that's only bc i was supporting gettasksrecursive(all, cgroup) so you wouldn't have to call it separately for all controllers,
[13:22] <desrt> hallyn: ya... i was realising as i was writing this code that this could get annoying with large numbers of cgroups
[13:22] <hallyn> but that sort of seemed necessary
[13:22] <desrt> but only privileged users can make these requests...
[13:22] <hallyn> no,
[13:22] <desrt> at least via systemd-shim...
[13:22] <hallyn> any unpriv user can create a container where they can start their own systemd-shim
[13:23] <desrt> true
[13:23] <desrt> but then they can do anything at all....
[13:23] <desrt> i should not be concerned that the user has the ability to cause their own copy of systemd-shim to burn cpu cycles...
[13:23] <hallyn> i suppose this just means i (o rsomeone :) will have to add accounting of time used per uid and report outrageous usage
[13:23] <desrt> because they could just as easily replace systemd-shim with a forkbomb -- it's their container, after all :p
[13:24] <hallyn> desrt: it's not their copy of system-dshim,
[13:24] <hallyn> it's the global cgmangaer
[13:24] <hallyn> whic his not threaded
[13:24] <hallyn> that's what i'm worried about
[13:25] <hallyn> i'm suggesting making systemd-shim do more work so cgmanger doesn't have to :)
[13:26] <desrt> meh.
[13:26] <desrt> i've already coded the necessary loops in systemd-shim
[13:26] <hallyn> yeah, i'm undecided
[13:26] <desrt> i took a bit of a different approach
[13:26] <hallyn> oh?
[13:26] <desrt> it's non-recursive now
[13:27] <desrt> i'm still working on the patch... it ended up being my sister's birthday yesterday so i couldn't ditch her just to hack on systemd-shim :p
[13:27] <desrt> i'm figuring out the subtree stuff just now
[13:27] <hallyn> so you don't need the recursive (non-kill) remove?
[13:27] <desrt> well
[13:27] <desrt> it would be nice :D
[13:27] <desrt> but no -- the code would be fine as it is
[13:27] <hallyn> hm.
[13:27] <desrt> i also added a retry mechanism
[13:28] <desrt> we try to kill off all processes 5 times
[13:28] <desrt> of course, we could have a D-state process that won't receive even SIGKILL
[13:28] <desrt> so we can't retry forever...
[13:29] <hallyn> right. seems to make sense to just go until there were no new tasks
[13:29] <hallyn> whatever happened to the 'kill' cgroup
[13:29] <hallyn> now on a well-setup systemd you should be able to freezer the freezer cgroup to prevent forks
[13:30] <desrt> there is no cgroup-kill
[13:30] <desrt> and apparently it was never planned
[13:31] <desrt> which is kinda bogus.... seems like this would be the most useful feature of all
[13:31] <desrt> "remove this cgroup... and its contents"
[13:31] <desrt> anyway... gonna go back to hacking the shim now... should be done EOD
[13:32] <desrt> having a hard time testing it, tho :/
[13:33] <hallyn> desrt: no, cgroup-kill was discussed several times, think there was even code.  oh well.
[13:33] <hallyn> desrt: timing sucks here.  but i can push a pkg with Prune and GetTasks Recursive today if it helps, but that seems to complicate things.
[13:34] <hallyn> (but then again if i don't i did this for nothing :)  - nothing new there)
[13:34] <desrt> so let me tell you what i'm doing
[13:34] <desrt> or let me paste it :)
[13:35] <desrt> http://paste.fedoraproject.org/131785/41018327
[13:35] <desrt> http://paste.fedoraproject.org/131786/83298141/
[13:36] <desrt> so basically, when i want to do an operation (Abandon, for example) on an existing scope ('session-1.scope' for example)
[13:36] <desrt> i get cgmanager to enumerate the existing cgroups to me, under a particular path
[13:36] <desrt> i now have a list of strings of cgroup paths
[13:36] <desrt> i do this 'match' operation to find out which i should care about
[13:36] <desrt> so for example /user.slice/user-1000.slice/session-1.scope and /user.slice/user-1000.slice/session-1.scope/other match "session-1.scope"
[13:37] <desrt> so those go on my kill-list
[13:37] <desrt> and i just iterate over this list, killing and removing
[13:37] <desrt> until all such kills/removes are successful
[13:37] <desrt> (or 5...)
[13:38] <desrt> the 'enumerate' algorithm is sufficiently simple... make an array, add the root node, initialise an index to 0
[13:38] <desrt> then as long as the index is less than the number of items in the array, enumerate the children of the item at the index and append them
[13:38] <desrt> look ma... no recursion
[13:38] <desrt> this is the one thing that it would truly help to have in cgmanager
[13:39] <desrt> "list me off, recursively, all cgroup paths below X"  (where X is probably, for example, "user.slice")
[13:39] <desrt> but again, i'm getting by OK without it
[13:42] <hallyn> desrt: so in shim you only care about name=systemd.  that little nugget had escaped me.
[13:42] <desrt> hallyn: ya... we've been using "all" in some places
[13:42] <desrt> i honestly don't know enough about this stuff to know what is the right thing to say, so i mostly copied you :)
[13:42] <hallyn> well you do want to delete the other cgroups 9and creat them),
[13:50] <hallyn> stgraber: good morning - are you around?
[13:57] <stgraber> hallyn: I am
[13:57] <hallyn> stgraber: the methods i was adding to cgmanager over the weekend are now probably not going to be used by the shim.  So my q is whether you might need any of them, or if i shoul ddrop them.
[13:58] <hallyn> 1. Prune - does a removeonempty followed by remove recursively,
[13:58] <hallyn> 2. GetTasksRecursive - return a lis tof pids (for one, a set, or all controllers) for a cgroup and all its children
[13:58] <hallyn> so 2. is my attempt tomake up for the fact that i can't safely do kill
[13:59] <hallyn> though as i was saying earlyer this morning i'm a bit worried about giving all unpriv users one cgmanager call that will take o(nlogn) of cgmanager's time on number of pids they create
[13:59] <hallyn> but it's probably ok
[14:01] <cyphermox> @pilot in
[14:05] <hallyn> well i guess if sytemd-shim doesn't need it then i can take more time testing it and tweaking it
[14:07] <desrt> hallyn: fwiw, the prune (with kill?) thing would be really great
[14:07] <desrt> although it would only be truly useful if we had a way to tell it to do the matching of cgroup names for us
[14:08] <desrt> like if we could tell it to kill all in .../session-1.scope/.../*
[14:08] <desrt> because otherwise we need to enumerate the list of cgroups to _find_ the proper path for session-1.scope anyway
[14:08] <desrt> so it doesn't save us much to not have to do that enumeration at the time of the kill
[14:08] <desrt> since we already just did it...
[14:09] <desrt> as it is, though, we get into some stupid territory with containers
[14:09] <hallyn> desrt: i cannot do 'with kill' because it would provide a way for users to get aorund LSM kill restrictions (like yama)
[14:09] <desrt> since we'll have to bounce all the way between the shim plus nested cgroup managers..
[14:10] <desrt> preventing containers from killing their own children?
[14:10] <hallyn> maybe i'm missing what you mean - but shim shouldn't care that it's in a container
[14:10] <desrt> even as root?
[14:10] <desrt> but when shim calls cgmanager inside the container, cgmanager will communicate with the cgmanager outside, no?
[14:10] <hallyn> right,
[14:10] <desrt> so we're jumping through a bunch of different levels...
[14:11] <hallyn> (well, cgproxy)
[14:11] <hallyn> right, but shim doesn't deal with those levels
[14:11] <desrt> i know
[14:11] <hallyn> ok
[14:11] <desrt> but that doesn't change the fact that performance could be bad...
[14:12] <desrt> anyway... not critical
[14:12] <hallyn> desrt: well the performance of the chained dbus calls is already a hit, sadly
[14:12] <hallyn> yeah i think for 15.04, unless we can do away with cgmanager,
[14:12] <desrt> i sent an email to msm asking if i could be readded to the plumbers list...
[14:12] <hallyn> i'll want to go back to tuning performance, and add some auditing for abuse (like one container taking too much cgmanager time)
[14:13] <hallyn> cool
[14:13]  * desrt should have just sucked it up in the first place
[14:15] <stgraber> hallyn: nope, I don't think I need those for cgmanagerfs
[14:16] <desrt> stgraber: i hope you're not spending too much time working on this :(
[14:16] <stgraber> desrt: nope, so far I spent about 30min on the python prototype :)
[14:16] <desrt> good
[14:16] <desrt> hopefully we can kill it during plumbers :)
[14:17] <stgraber> desrt: so there are a bunch of things which should make it possible to kill it, but they are rather complex kernel features (cgroup namespace + unprivileged mount of cgroupfs) and we'll need backward compatibility for a few years so regardless of what will happen in the next 3-4 kernel releases, we'll need cgmanagerfs for a few years
[14:18] <hallyn> sigh.  and the gettasksrecursive worked out so nicely last night :)
[14:18] <desrt> hallyn: add it anyway?
[14:18] <stgraber> and the part of cgmanagerfs which provides meminfo, cpuinfo and stat will likely stay relevant for a while as the kernel folks made it pretty clear they don't want to make those files cgroup-aware...
[14:22] <desrt> is there a way to get change notification from cgmanager?
[14:22] <desrt> on creation/remove of cgroups?
[14:30] <hallyn> desrt: it's either in the latest kernels, or on its way
[14:30] <hallyn> not creation, i think just removal
[14:31] <desrt> pah
[14:31] <hallyn> (and when it's in the kernels, cgmanager will export an epoll interface for it)
[14:31] <hallyn> yeah
[14:33] <desrt> cgmanager is being unkind to me.
[14:33]  * desrt tries upgrading
[14:43] <desrt> so i keep getting "invalid request" in response to ListChildren
[14:43] <desrt> any idea?
[14:45] <desrt> disregard.  reboot fixed it.
[14:45]  * desrt had old names in his cgroup tree
[15:43] <mitya57> Mirv: sorry, I was not on IRC and read all your messages only now :P
[16:20] <pitti> Riddell, doko: hmm, so what caused all these KDE autopkgtests to suddenly fail?
[16:21] <doko> pitti, ?
[16:22] <pitti> doko: that was more of a CC:, as they block the gcc upload
[16:22] <pitti> I got 7 new "jenkins failed" regressions for ark, kfilemetadata, klettres, kcalc, etc., whose tests now all fail completely
[16:23] <pitti> Could not find executable /tmp/adt-run.GXmatc/build.C6j/kcalc-4.14.0/obj-i686-linux-gnu/knumber/tests/knumbertest.shell
[16:23] <pitti> did something recently changed in some common KDE build system tools?
[16:23] <Mirv> mitya57: heh, I thought there was async communications going on ;) no problem, all resolved now.
[16:24] <pitti> Could not find executable /tmp/adt-run.nVaQc4/build.b07/okteta-4.14.0/obj-i686-linux-gnu/kasten/controllers/customtostringtest.shell
[16:24] <pitti> Riddell: all the failures look fairly similar, like that ^ like the test isn't being built any more
[16:26] <doko> yep, always some "shell" which is missing
[16:27] <doko> pitti, afaics the autopkg tests don't build, only run the test (at least ark)
[16:28] <pitti> doko: hm, I wonder how they previously passed then?
[16:28] <pitti> ark has a fairly spotless record until now (https://jenkins.qa.ubuntu.com/job/utopic-adt-ark/)
[16:28] <pitti> and the log also shows that it builds the entire package
[16:28] <pitti> I think pretty much all KDE packages do that (first build, then run the built tests)
[16:42] <slangasek> pitti: so why did daily boot testing with upstart fall off the core-1403-systemd-transition workitems?  Wasn't the intention here to make sure both were tested so that a) we could ensure we weren't regressing upstart boot during the transition to systemd, and b) we could tell if a boot regression is init-specific or not?
[16:46] <pitti> slangasek: ah, I removed it as the desktop/server ones on http://ci.ubuntu.com/smokeng/utopic/ already do that
[16:46] <pitti> slangasek: or http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/Smoke%20Testing/ (ci.u.c. is a little slow today, at least for me)
[16:46] <slangasek> ah, ok
[16:46] <pitti> slangasek: so we've always had daily testing with upstart already
[16:46] <slangasek> so this is "done" rather than "dropped" :)
[16:47] <pitti> slangasek: well, "retroactively done" if you will
[16:47] <pitti> slangasek: I first tried to add systemd tests to our daily image smoketesting, but that opened a can of worms
[16:47] <pitti> slangasek: and as UTAH is going away, I don't think we should spend much time trying to fix that; ev rather suggested to run those in autopkgtest
[16:48] <pitti> doko: hm, I wonder how they previously passed then?https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd/126/ARCH=amd64,label=adt/
[16:48] <ev> +1
[16:48] <pitti> err, X clipboard, don't mess with me
[16:48] <pitti> slangasek: so here they are: https://jenkins.qa.ubuntu.com/job/utopic-adt-systemd/126/ARCH=amd64,label=adt/
[16:48]  * ev is in favour of anything that brings consistency to the way we drive tests
[16:48] <pitti> doko: sorry, paste error
[16:49] <ev> the fewer ways we have to run tests, the more tests we can run
[16:49] <pitti> the new "boot_and_services" reboots with systemd, and ensures that lightdm, NM, etc. all start
[16:49] <pitti> there's a lot more which I want to add there, but those are the most basic things
[16:53] <tedg> hallyn, desrt, curious what the status of the cgroups systemd-shim patch is
[16:54] <desrt> tedg: testing out a few issues still
[16:54] <desrt> but it's mostly there
[16:54] <tedg> Cool, great.
[16:54] <tedg> A today thing?
[16:54] <desrt> a by-tomorrow-morning thing, certainly
[16:54] <desrt> abandon (which is the default) is working at least
[16:54] <desrt> but i'm having some issues with the kill-all-the-things stuff
[16:55] <tedg> Okay, I'll plan on testing/trying to land the UAL tomorrow afternoon then. Give that a change to move through the phases of packaging/etc.
[16:56] <slangasek> pitti: ah, so these are autopkgtests now, does that mean we have nested KVM working reliably for adt?
[16:57] <pitti> slangasek: no, I haven't touched that since I played around with that, nested KVM was a disaster back then
[16:57] <pitti> that was mid-trusty, perhaps it got a lot better since then
[16:57] <pitti> but as clouds usually don't have the very latest kernel/qemu, I think it'll still be a while since we can do that
[16:58] <pitti> slangasek: we run autopkgtests in temporary VMs on bare metal right now
[16:58] <pitti> slangasek: and in the new airline we'll create temp cloud instances and run the tests in them directly, then tear them down again
[16:58] <slangasek> hmm
[16:58] <slangasek> so do you get console off of the VM via cloud APIs?
[16:59] <pitti> slangasek: ah, no; the current test is modifying the grub config to append init= and then reboots
[16:59] <slangasek> ah, ick
[16:59] <pitti> slangasek: as soon as we land the last bits from bug 1351306 I'll switch that to systemd-sysv
[16:59] <slangasek> so you aren't booting under a test harness
[17:00] <pitti> slangasek: well, the entire VM is the test harness
[17:00] <pitti> slangasek: in teh CI airline we should eventually run those under a full desktop install, not a minimal VM
[17:00] <slangasek> yes, and you just said you're rebooting that VM
[17:00] <pitti> right
[17:00] <slangasek> so, ick :)
[17:00] <pitti> slangasek: and relying on autopkgtest's timeouts
[17:00] <pitti> slangasek: and yes, ick :)
[17:00] <slangasek> better than nothing, but a long way from where I think we should be
[17:01] <pitti> we don't have a better deployment of testbeds yet unfortunately
[17:01] <pitti> slangasek: long way> oh yes
[17:01] <pitti> slangasek: well, at least we stopped running the test controller inside the VM long ago
[17:02] <pitti> which helps quite a bit to reduce assumptions and increase test stability
[17:02] <pitti> so the main issue is that the VM doesn't reboot enough, and thus adt-run will time out
[17:02] <pitti> s/that/if/
[17:03] <pitti> slangasek: but even if the UTAH based tests would get along with reboots, it would essentially be the same? they also just fire off a VM and wait for it to come back
[17:04] <slangasek> pitti: nothing I've said should be interpreted as an endorsement of UTAH
[17:04] <slangasek> pitti: I've been asking ev for proper boot-under-test for over a year ;)
[17:05] <pitti> slangasek: how would that look like in a cloudy env?
[17:05] <pitti> slangasek: getting serial consoles, something of that sort?
[17:06] <pitti> ssh is arguably quite a strong assumption; we don't need it in the current adt runners (only a ttyS1 shell), but we will need it with the CI airline (at least right now)
[17:06] <pitti> as that uses cloud VMs whose primary (and only?) interface is ssh
[17:06] <slangasek> pitti: it would require full console output from the VM, /not/ ssh
[17:06] <pitti> slangasek: yeah, cloudy ttyS0 would rock
[17:09] <desrt> hallyn: hey.. having some trouble with RemoveOnEmpty
[17:09] <hallyn> desrt: how so?
[17:09] <desrt>     member -> 'RemoveOnEmpty'
[17:09] <desrt>     signature -> signature 'ss'
[17:09] <desrt>   Body: ('all', 'user.slice/user-1000.slice/session-29.scope')
[17:09] <desrt>   UNIX File Descriptors:
[17:09] <desrt> returns OK
[17:09] <desrt> but now i see
[17:09] <desrt> root@velocity:~# cat /sys/fs/cgroup/systemd/user.slice/user-1000.slice/session-29.scope/tasks  | wc -l
[17:09] <desrt> 0
[17:10] <desrt> ie: RemoveOnEmpty was called, and there are no tasks, but the group is still here
[17:10] <desrt> other than that, everything actually seems to be working fairly nicely
[17:10] <ev> pitti: cloudy tty0, `nova console-log`?
[17:11] <hallyn> desrt: that's what i was saying last week to explain my shim code.  removeonempty sets it so it'll be reomved the next time it *becomes* empty
[17:12] <desrt> curious.
[17:12] <desrt> Abandon should still be called while there's something in there, though, no?
[17:12] <desrt> i guess not...
[17:12] <desrt> so after i set RemoveOnEmpty, try a remove, i guess?
[17:12] <hallyn> desrt: sure
[17:13] <hallyn> yup
[17:13] <desrt> this is a bit crap :(
[17:13] <hallyn> what Prune does is removeonempty, then work on all the child subdirs, then remove
[17:13] <hallyn> it may be too closely tied to the way the kernel does it,
[17:13] <desrt> might be nice if cgmanager took care of this little detail
[17:13] <hallyn> but since the kernel will be changing soon, i prefer that to adding too much magic
[17:13] <hallyn> it will, with prune
[17:14] <desrt> well, let's get this working first...
[17:14] <desrt> it's pretty much there now
[17:14] <hallyn> desrt: no, consider the way shim's been using removeonempty until now
[17:14] <pitti> ev: oh, that's just that? très awesome :)
[17:14] <hallyn> it creates, calls removeonempty, then moves takss into there
[17:14] <hallyn> if it immediately removed that wouldn't work :)
[17:14] <desrt> hallyn: true :)
[17:14] <pitti> ev: I figure that's read-only, but it's mostly for getting early debug logs on failure anyway, which is sufficient
[17:14] <ev> yeah, it is read-only
[17:14] <ev> cool
[17:29] <smoser> hey. wonder if someone could give some thought to
[17:29] <smoser>  f. write updated ata to /var/lib/cloud/data/status.json
[17:29] <smoser>  e.
[17:29] <smoser> bah.
[17:29] <smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1366893
[17:29] <smoser> my current thinking is just this:
[17:29] <smoser>  http://paste.ubuntu.com/8292135/
[17:30] <smoser> but i dont know if that could cause some issues.  in a initramfs boot, /run is aleady mounted (but that seems ok in testing). in lxc container, it seems that should ensure it.
[17:30] <smoser> jodh, i wonder if you're around and have thoughts.
[17:41] <desrt> hallyn: i've pushed a new branch called wip/abandon
[17:42] <desrt> contains 10 patches
[17:42] <desrt> https://github.com/desrt/systemd-shim/commits/wip/abandon
[17:42] <desrt> it seems to work, more or less
[17:43] <desrt> i've even tested manually calling StopUnit on some session scopes to verify that the session gets killed off
[17:44] <hallyn> desrt: cool, fetched the tree, will take a look after lunch during slow bisect runs
[17:45] <desrt> the first 5 or so are really trivial
[17:45] <desrt> the next few are more complicated changes to support the coming work
[17:45] <desrt> and the last one is the big one, but because of the ones before, is almost purely additive
[17:45] <Mirv> is it just me or sudo apt update claiming all public keys are missing? (on utopic)
[17:48] <bdmurray> slangasek: do you know if the test case for bug 1274466 is different for Trusty?
[17:51] <slangasek> bdmurray: hmm, should be the same test case but with s/precise/trusty/
[17:51] <bdmurray> slangasek: so with one generated from lucid?
[18:05] <kdub> is there a list of currently uninstallable packages somewhere?
[18:07] <smoser> slangasek, ^ do you think it seems reasonable to do http://paste.ubuntu.com/8292135/ (bug 1366893 above)
[18:09] <slangasek> bdmurray: yes, still needs to use lucid as the baseline
[18:10] <slangasek> smoser: looking
[18:11] <slangasek> smoser: have you tested this?  If memory serves, the 'mounted' events are serialized within mountall, and you won't see a second mounted event until the first one clears... which would mean this deadlocks
[18:13] <smoser> slangasek, hm.. well it works in kvm , where an initramfs loaded /, so /run is mounted already.
[18:13] <smoser> and it worked at least in my tests on lxc
[18:13] <smoser> but that could just be lucky
[18:13] <smoser> and i dont want to rely on /run being mounted out of initramfs
[18:14] <slangasek> ok
[18:14] <smoser> you have other suggestions ?
[18:14] <slangasek> it's strange that we would ever see the mounted event for / before the one for /run fwiw
[18:14] <smoser> it almost always happens.
[18:14] <slangasek> I thought the ordering of the events was guaranteed
[18:14] <smoser> 9/10 times in lxc.
[18:14] <smoser> ish
[18:15] <slangasek> hmm
[18:15] <slangasek> so what does it need / mounted for?
[18:15] <slangasek> should it be *just* 'on mounted MOUNTPOINT=/run'?
[18:15] <slangasek> or is this the component that does things like installing extra packages?
[18:16] <slangasek> oh... no, now I remember, 'mounted' events can happen in parallel, but the class-based events (e.g. 'local-filesystems') won't be emitted until the 'mounted' events finish
[18:16] <slangasek> smoser: so I think this is ok
[18:17] <smoser> oh yeah, we fixed it
[18:17] <smoser> you did
[18:17] <smoser> so that events could happen in parallel
[18:23] <smoser> slangasek, https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/643289 i think that was it.
[18:35] <bdmurray> slangasek: hmm, the command in the test case isn't doing anything for me...
[18:51] <slangasek> bdmurray: ok; I don't think I've validated the correctness of the test case
[18:52] <bdmurray> slangasek: okay, I'll email mvo
[19:13] <alex-foo> LLVM 3.5 now requires you use C++11 when linking against it. due to STL incompat between C++11 and C++98 (e.g. std::pair layout changed), it's not safe to mix code that uses C++11 and C++98. does anyone know how distro maintainers plan to work with this? will everything C++ have to be compiled with -std=c++11 now?
[19:28] <slangasek> alex-foo: I'm not sure what the issue is you're concerned about; we don't build the distro with LLVM
[19:32] <xnox> alex-foo: we are not switching to c++11 standard by default, but some packages use c++11 ABI already, but they are careful enough to use that for other dependencies as well.
[19:33] <alex-foo> slangasek: any package in the archives that links against LLVM 3.5 or newer (even if it builds with GCC) will need to be built with -std=(gnu|c)++11
[19:33] <alex-foo> xnox: i don't see how that will work -- will we parallel install C++11 and C++98 builds of every dependency? like 32 vs. 64 bit parallel installation?
[19:34] <slangasek> $ reverse-depends -b llvm-3.5
[19:34] <slangasek> No reverse dependencies found
[19:34] <slangasek> $ reverse-depends -b llvm-3.6
[19:34] <slangasek> No reverse dependencies found
[19:35] <alex-foo> 3.5 was released last week
[19:35] <slangasek> so "any package in the archive" == "no packages in the archive", currently
[19:35] <alex-foo> try 3.4 or 3.2
[19:35] <xnox> alex-foo: 3.4 is our current default. No we do not ship both 98 & 11 variants.
[19:36] <xnox> alex-foo: we have some libraries that have been using unstable 11 abi, but they are build with gcc and have bumped their soname when moving between abi incompatibilities in e.g. gcc 4.8 and 4.9.
[19:36] <alex-foo> GCC 4.8 and 4.9 had ABI incompat?
[19:37] <slangasek> yes; the C++11 ABI is still marked experimental in gcc
[19:38] <alex-foo> ah of course, sorry i thought you were talking about the ABI in general, not the C++11 one.
[19:38] <alex-foo> so what reverse-depends llvm-3.4?
[19:39] <slangasek> AFAICS, only ghc
[19:39] <slangasek> oh, and yrmcds
[19:39] <xnox> alex-foo: there is no abi incompat with llvm-3.4.... for things that compile with 98 standard, when things move to 11 standard, or llvm-3.5 they'd need to bump their soname.
[19:39] <alex-foo> but in general, this will be a problem for any library that requires C++11 going forward
[19:40] <kdub> I can't seem to install crossbuild-essential-armhf on utopic, is this something that should have a bug?
[19:40] <xnox> slangasek: $ reverse-depends -b src:llvm-defaults; $ reverse-depends -b src:llvm-toolchain-3.4
[19:40] <slangasek> xnox: so the clang revdeps are also relevant?
[19:40] <xnox> slangasek: yes, (abuse) of transitive dep
[19:40] <slangasek> ok
[19:41] <slangasek> in that case, there are a few for 3.5 also (creduce, feel++)
[19:41] <xnox> kdub: (a) do you have armhf arch enabled in dpkg? (b) do you have armhf ports archive enabled in apt sources ? (c) do you have proposed disabled?
[19:41] <alex-foo> e.g. Qt now builds with C++11 by default since 5.x IIRC, at some point in the future it will lose C++98 support
[19:42] <kdub> xnox, i haven't /enabled/ proposed if thats something you have to do
[19:43] <xnox> kdub: i'd like you to check and verify all three things. if all three are good, then I'd start looking if there is something worse going on.
[19:44] <kdub> xnox, ack, thanks
[19:45] <xnox> alex-foo: honestly, not a problem... note we are not moving to c++11 by default in utopic, nor are we moving to 3.5, and we are aware of the issue and have mitigated it successfully and our stable releases are abi consistent for given sets of packages.
[19:45] <xnox> alex-foo: if you have a developer / user queries you might find #ubuntu-appdev and or #ubuntu support channels for those. There is also askubuntu and ubuntu-devel-discuss mailing list.
[19:48] <alex-foo> xnox: you have mitigated all of this? and are confident about the situation? https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
[19:53] <xnox> alex-foo: if there is any particular packages that are broken as build in ubuntu, please open a bug demonstrating e.g. a crash against those individual packages. I assert that packages in ubuntu both development and stable releases are fine. If there are any that regressed in this sense, it's a bug.
[19:53] <xnox> alex-foo: have you found a buggy package / miss-built?
[20:00] <alex-foo> xnox: no but it's straightforward to construct
[20:01] <alex-foo> xnox: i don't actually use ubuntu, i'm just interested in how packaging systems are addressing (or not addressing) this issue
[20:01] <xnox> alex-foo: yes, one can construct broken binaries that's easy - i'm asking if you found broken binaries as shipped by ubuntu.
[20:02] <xnox> alex-foo: on packaging we are addressing it with automated as installed testing, abi versioning our library packages, and staying on 98 abi by default for now and only careful test and investigate 11 abi usage where required.
[20:03] <xnox> alex-foo: btw, that was not the question you originally asked. In essence, standard ubuntu & debian development practices are used to track this ABI break just like any other one we had.
[20:04] <alex-foo> what other ABI break is this comparable to?
[20:08] <hallyn> desrt: so your g_ptr_array_foo wizardry is beyond me :)  but it seems to me you don't want to do enumerate_paths() on user.slice.  if two users are logged in with lots of nested containers you'll collect the others' paths just to discard them.  is there any reason not to just enumerate_paths() on user.slice/user-$uid.slice?  oh right, you didnt' have a good way to find the second part of that did you...
[20:09] <hallyn> certainly better than nothing though, a fine way to get it out the door.
[20:13] <hallyn> i'm tempted to say i'll release 0.32 with prune and gettasksrecursive so you can use those, but debian uploads tend to take a week
[20:13] <hallyn> (mainly bc i suck)
[20:20] <desrt> hallyn: i also had another consideration...
[20:20] <desrt> there is nothing to stop the other user from creating scopes with names like session-nn.scope, right?
[20:20] <desrt> we might find those...
[20:20] <desrt> and we have no real good way of knowing which scope is the one we created
[20:20] <desrt> i start to think that this idea about having a file in /run is the best one after all
[20:21] <hallyn> true
[20:21] <desrt> what we have now will certainly work though
[20:21] <hallyn> well, not relaly,
[20:21] <desrt> unless users start doing 'interesting' things
[20:21] <hallyn> the user cannot create cgroups under user.slice/user-1000.slice himself?
[20:21] <hallyn> yeah he can, nm
[20:22] <desrt> did the current set of patches work for you, in any case?
[20:23] <hallyn> i only looked at them, didn't test them.
[20:23] <hallyn> i'm pushing cgmanager 0.32 to debian in af ew mins, just building a new symbols list
[20:23] <desrt> sure thing, knuth :)
[20:26] <hallyn> sorry i didn't think you were at a ready-to-test point, i can build in a few mins though
[20:26] <desrt> i think i'm going to try my hand at the run thing next...
[20:26] <desrt> i guess i didn't appreciate the extent to which you wanted unpriv'd containers to be able to whip up arbitrary cgroups
[20:29] <hallyn> yeah we're mad-men
[20:29] <hallyn> hm, just madmen
[20:31] <hallyn> ok, pushing 0.32-1 to mentors.debian.net and 0.32-1~testing1 to ppa:serge-hallyn/virt
[20:33] <hallyn> make that 0.32-1~ubuntu1
[20:36] <desrt> about to step out for dinner
[20:36] <desrt> i'll see if i feel like looking at the /run file thing when i come home
[20:36] <desrt> otherwise, i'll poke it tomorrow morning
[20:40] <hallyn> desrt: ok.  maybe i'll see if i can convert your code to using the new cgmangaer methods just for my own education (and *maybe* to be useful later)
[20:40] <desrt> :)
[20:40] <desrt> i agree that it would be nice to get rid of that "give me ALL the things!" approach i have now
[20:40] <hallyn> xnox: would you have time for a debian cgmanager package upload review/sponsor?
[20:41] <hallyn> (i understand if not :) - thx for the previous help)
[20:41] <hallyn> desrt: should also help me ifnd any bugs which my testcaseds missed :)
[20:42]  * alex-weej waves at desrt
[20:43] <desrt> alex-weej: hey... long time no see :)
[20:43] <desrt> what're you up to these days?
[20:43] <alex-weej> C++ and Qt. I know, right.
[20:43] <desrt> i've heard this story before ;)
[20:43] <xnox> hallyn: yeah.
[20:43] <hallyn> desrt: good news, scopes are going away :)
[20:44] <desrt> in systemd?
[20:44] <desrt> oh
[20:44] <hallyn> oh wait, i should reboot
[20:44] <desrt> you mean on your system :)
[20:44] <hallyn> yeah i forgot my session is already removeonempty
[20:44] <desrt> i thought you meant that scopes were going to stop being a thing :p
[20:44] <desrt> anyway... i gotta run
[20:44] <hallyn> oh - lol :)
[20:44] <desrt> let me know what you find
[20:44] <hallyn> will do - ttyl
[20:45] <hallyn> still working
[21:16] <hallyn> xnox: hm, there's a bug in cgmanager.Prune, so not sure if 'yeah' meant yeah you have time to review or yeah you're to busy, but i guess it's not ready yet :(
[21:17] <hallyn> unless i'm using the wrong code, hm
[21:38] <jtaylor> someone fancy helping me with some grub debugging?
[21:38] <cjwatson> jtaylor: depends how complex it is (working around children's bedtime)
[21:40] <jtaylor> grub is complaining the gpt partition contains no bios boot partition, it works fine from 14.04 but not 14.10
[21:41] <hallyn> xnox: oh, disgregard, it was my systemd-shim patch that was wrong
[21:41] <jtaylor> if you don't know the answer right now don't bother, I can work around it and try again later
[21:41] <cjwatson> jtaylor: copy and paste the error message please?
[21:43] <jtaylor> this gpt partition label contains no bios boot partition; embedding won't be possible
[21:43] <jtaylor> but this is required for raid and lvm install
[21:43] <TJ-> jtaylor: Does the GPT have an EF02 type partition?
[21:43] <cjwatson> jtaylor: what does parted say?
[21:43] <cjwatson> EF02 isn't a GPT type
[21:44] <cjwatson> GPT partition types are GUIDs
[21:44] <cjwatson> EF02 is a gdiskism
[21:45] <hallyn> desrt: so github.com/hallyn/systemd-shim #serge/abandon3 adds a bone-stupid per-scope /run-file and uses cgmanager:Prune for Scope.Abandon
[21:47] <jtaylor> parted say about what?
[21:48] <TJ-> jtaylor: "sudo parted /dev/sda print" - does it list a "BIOS boot partition", or does "sudo gdisk -l /dev/sda" show a "Code" EF02 partition?
[21:49] <jtaylor> no bios no EF02
[21:50] <jtaylor> cde 8300
[21:50] <jtaylor> urg I thought it would work from 14.04 but that now fails too
[21:50] <jtaylor> weird
[21:51] <TJ-> jtaylor: That's the problem then; system is booted in EFI mode but the GPT has no BIOS boot partition. Previously the system must have been booting in CSM/Legacy mode
[21:53] <jtaylor> so its due to the way the installer booted?
[22:05] <jtaylor> hm installed grub on a partition with msdos partition table that worked
[22:05] <jtaylor> doesn't find 14.10 though, I'll figure it out mysef, thanks
[22:21] <infinity> pitti: Around?
[22:29] <hallyn> desrt: and another patch pushed to github.com/hallyn/systemd-shim #serge/abandon3 to do stopunit using cgmanager:GetTasksRecursive - with the warning that there's a segv in that cgmangaer that i need to fix
[22:31] <shadeslayer> doko: poke
[22:31] <shadeslayer> doko: what can we do about https://bugs.launchpad.net/sqlite/+bug/1317449
[23:02] <infinity> shadeslayer: If 3.8.2 is broken and 3.8.4 fixed the issue, can we hunt down the commit(s) that fixed it via bisection or similar and do a targetted cherry-pick SRU?
[23:02] <infinity> shadeslayer: I'm not keen on the idea of just updating sqlite wholesale to a new upstream version because people say that's the fix.
[23:03] <shadeslayer> infinity: me neither, but I'm not exactly a expert at sqllite, someone who's a bit more knowledgable in this area needs to look at this
[23:03] <infinity> shadeslayer: Well, the beauty of bisection is that one doesn't generally need to be an expert.
[23:04] <infinity> shadeslayer: It's just build, test, build, test, until you find the commit that fixed it.  Cherry-pick that (and dependencies, if needed), test again, and done.
[23:04] <infinity> This is all assuming sqlite is in a VCS that isn't from 1991.
[23:04] <infinity> Or a VCS at all.
[23:06] <infinity> Maintained in Fossil... That's a new one to me.
[23:06] <hallyn> desrt: i didn't even bother getting indentation right so assume yo'ull be re-writing it, but both Stop and Abandon seem to be working with my branches.  back to libvirt
[23:07] <cjwatson> It's a VCS not from 1991, just from a parallel universe instead
[23:07] <cjwatson> Stores content in SQLite, so guess why SQLite uses it ;-)
[23:07]  * sarnold *boggle&
[23:09] <infinity> shadeslayer: I suppose a good place to start would be to see if the handful of post-release commits on the 3.8.2 branch (well, the non-win32 ones) relate:
[23:09] <infinity> http://www.sqlite.org/cgi/src/timeline?r=branch-3.8.2
[23:14] <infinity> shadeslayer: A good reproducer for someone who's never used digikam wouldn't go amiss either, in case someone wanted to jump in and be helpful with the bisection/fixing, but has no idea how to make it crash in the first place. :P
[23:17] <infinity> cjwatson: I guess one could choose a worse disk format, though I can't fathom why anyone would want to interact with their VCS via SQL as an interface.
[23:19] <bigon> hey guys, I've a question about apport, under ubuntu how is apport-gtk called when a program segfault?
[23:20] <bigon> I understand that apport itself is called and generate a report in /var/crash
[23:20] <infinity> cjwatson: I suppose I could see it leading to clever third-party shortcuts where one can easily write web UIs and such without the VCS tool, just directly abusing the data.
[23:20] <infinity> Either way, weird.
[23:20] <bigon> but how is the gui called for the user?
[23:21] <infinity> bigon: Via update-notifier, I believe.
[23:21] <infinity> bigon: And a quick perusal of the code confirms my suspicion.
[23:23] <cjwatson> infinity: Does it actually expose the SQLiness, or is it just a backend format?
[23:24] <bigon> thx
[23:24] <infinity> cjwatson: Well, libsqlite would expose SQLness, if you chose to use it to look at the Fossil data store, which is where it would become interesting, I guess, cause you could skip Fossil entirely to interact with it.
[23:24] <cjwatson> infinity: Well, yeah, I just mean that if it's not in the UI then it's just a choice to avoid having to write all your own data store.
[23:24] <infinity> cjwatson: Unlike, say, git, where people have had to write third-party libgit implementations to avoid the git CLI.
[23:25] <cjwatson> Yeah, true.
[23:31] <jtaylor> hmm cpu scaling is kernel buisness or?
[23:31] <jtaylor> 14.10 is running my cpu at 800 mhz under full load ._.
[23:33] <sarnold> jtaylor: "it's complicated" -- there's multiple kernel cpu scheduling governors and then there's multiple thermal management things interacting. it's far more complicated and involved than it used to be
[23:37] <infinity> jtaylor: /proc/cpuinfo also doesn't give the whole story terribly well, since the scaling is up and down far more often than you poll.
[23:38] <jtaylor> cpufreq stats: 3.20 GHz:7.18%, 2.50 GHz:4.95%, 2.10 GHz:5.61%, 800 MHz:82.26%
[23:39] <jtaylor> and its noticable, as soon as I start 4 yes the UI gets terribly slow
[23:39] <infinity> jtaylor: Using ondemand or intel_pstate?
[23:40] <infinity> jtaylor: If ondemand, you might want to try installing thermald and booting with 'intel_pstate=enable' on your cmdline and see if that happies it up any.
[23:40] <jtaylor> its an amd
[23:40] <infinity> Oh.
[23:40] <infinity> Then nevermind. :P
[23:40] <jtaylor> it seems to be ondemand, didn't change anything, fresh install
[23:40] <jtaylor> I guess some kernel bisecting can't harm, tomorrow
[23:41] <infinity> Right, ondemand should be the right thing on an AMD CPU.  It's possible some thresholds could be tweaked a bit to back off less aggressively and favour speed over power.
[23:46] <jtaylor> mh /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq being 800mhz can't be right?
[23:46] <sarnold> heh
[23:47] <sarnold> reminds me of m old g3 laptop... 800 was 'fast', 300 was power saving :)
[23:57] <slangasek> desrt: any news on systemd1.Scope/Abandon?
[23:57] <infinity> sarnold: 800 *was* fast!
[23:58] <infinity> jtaylor: Seems a bit wrong to me.
[23:58] <infinity> jtaylor: But also doesn't add up with "cpufreq stats: 3.20 GHz:7.18%"