[00:00] <jtaylor> its weird
[00:00] <jtaylor> the system works alright until I fully load it, as if it does the opposite of what it should
[00:09] <sarnold> infinity: oh yeah, definitely, the first one I had was 700 mhz, but several cracked motherboards later, I got the 800 mhz version :) woohoo, speed demon
[00:10] <infinity> sarnold: I have a 1GHz G3-class (IBM PPC750) that's still a speed demon, really.
[00:10] <infinity> sarnold: And that CPU is now 15y old or something...
[00:11] <sarnold> infinity: hehe, older server gear is still impressive :)
[00:12] <infinity> sarnold: It's not server gear, it's a Beige Apple G3 tower with a (seriously) upgraded CPU. :P
[00:12] <sarnold> infinity: really??
[00:12] <infinity> sarnold: And the CPU itself is actually the low power embedded version of the PPC750, so despite being 15y old, it's pretty efficient.
[00:12] <infinity> sarnold: Can't say the same for the ancient hard drive in it, though, should probably replace that.
[00:13] <sarnold> infinity: heh, 80-conductor pata? or 40 conductor? :)
[00:13] <sarnold> oh wait, were they still in their scsi stage then?
[00:13] <infinity> sarnold: The drive is 80-conductor era, just barely.  1st gen 66 or 133, don't recall now.
[00:13] <infinity> sarnold: The part where the label says "Quantum" probably says something.
[00:13] <infinity> I miss Quantum. :(
[00:14] <infinity> I'm not sure I'll ever forgive Maxtor for that buyout.
[00:17] <infinity> sarnold: I'm not sure if it was Maxtor buying out Quantum, or Compaq buying DEC, but somewhere in that area, I gave up on the idea that "server kit" would ever be anything more than whitebox PC junk with a pretty case and a longer warranty.
[00:18] <infinity> ... and here we are today.
[00:31] <sarnold> infinity: *sniff* quantum
[00:31] <sarnold> infinity: but there's still something to be said for ecc ram, hehe
[00:36] <infinity> sarnold: Back in my day, we didn't need ECC RAM, we just made computer cases out of lead.
[00:37] <sarnold> infinity: muahahaha
[00:39] <jtaylor> seems to be thermald messing around, my temperaturs are fine ._.
[00:46] <infinity> jtaylor: thermald shouldn't do anything at all on non-Intel kit.
[00:47] <jtaylor> too bad its logfile is not really readable
[00:48] <jtaylor> I'll have a deeper look tomorrow, bye
[00:57] <doko> Riddell, ScottK, pitti: was there any idea about the recent KDE autopkg test failures?
[01:55] <ScottK> doko: Taking a quick look at ark, the current version passed previously and now it complains about not being able to find executables.  That smells of a linker change somewhere.
[01:57] <doko> ScottK, but according to the autopkg test log, the package builds sucessfully ...
[01:57] <doko> I'm fine to search things, but I can't see where I should look
[02:06] <doko> barry, I'm not ok with tox and pip in main.
[02:09] <barry> doko: suggestions welcome, but i'm not removing the build-dep on tox
[02:09] <doko> barry, keep it in universe
[02:10] <barry> doko: isn't that a problem for seeding system-image?
[02:10] <doko> barry, then we don't see it
[02:10] <doko> seed it
[02:11] <barry> doko: right now it's only needed for touch.  maybe someday it will be needed for server or desktop
[02:11] <doko> barry, you have to explain why tox is needed to test
[02:12] <doko> the test environment is clearly defined by build dependencies or autopkg test dependencies. so there is no need to use a virtual env
[02:14] <barry> doko: why no tox or pip in main?
[02:16] <doko> barry, I don't care about tox, if you remove pip as a dependency. and I answered that in a bug report already. upstream systems like this are a pain to maintain. we see this with rails, and we keep maven in universe for a reason
[02:21] <barry> doko: well, i'll sleep on it
[02:23] <desrt> slangasek: it's done as far as i'm concerned
[02:24] <desrt> slangasek: although it looks like hallyn has pushed some extra patches to improve efficiency by making use of new cgmanager features
[02:36] <tedg> pitti, The adt test for dbus-test-runner failed. I'm not quite sure why.
[02:36] <tedg> pitti, There seems to be some PID giving a signal 15.
[02:37] <tedg> pitti, How do I recreate that?
[02:39] <tedg> I don't think I have any autopkg tests.
[05:27] <pitti> Good morning
[05:28] <pitti> infinity: I am now
[05:28] <pitti> bigon_: some user session upstart job calls /usr/share/apport/apport-gtk (without args) when there's new files in /var/crash
[05:28] <pitti> doko: I haven't heard back about the KDE failure galore
[05:29] <pitti> tedg: "some pid" getting sig 15 is certainly QEMU when adt-run shuts it down, that's perfectly normal
[05:30] <pitti> tedg: "ERROR: testbed failed: timed out"
[05:30] <pitti> tedg: so apparently something hung forever in the test; I'll try and rerun it, if that doesn't help it needs to be debugged more thoroughly
[05:31] <pitti> tedg: you can run locally with http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
[05:45] <Unit193> pitti: I don't suppose I could interest you in a very simple upload to Debian (small bugfix) and sync to Ubuntu could I? :)
[05:45] <pitti> Unit193: if it's a package I can upload (i. e. sponsor or I'm a maintainer), sure
[05:46] <Unit193> pitti: Yeah, it's a QA upload, I put unversioned breaks in a transitional package by mistake: http://mentors.debian.net/package/samdump2
[05:53] <ScottK> pitti: For the KDE stuff, what I checked had previously passed without being changed.  Most of the Kubuntu people are at Akademy (annual KDE conference) this week, so less likely than usual to be responsive.
[05:54] <ScottK> Somehow, I think it's not our fault though.  No idea where to start though.
[06:08] <pitti> mvo_, cjwatson: FYI, recent click regressed its autopkgtest and is stuck (anonymous upload notification forward :) )
[06:09] <pitti> tedg: re-run still hangs
[06:10] <bigon_> pitti: ok thank, update notifier has some code for it too
[06:13] <pitti> Unit193: "Bug #760723 does not belong to this package" -> needs some reassignment?
[06:14] <Unit193> pitti: There used to be a source package of the same name, but that's against the binary package of samdump2.
[06:15] <pitti> Unit193: ah, ok; uploading
[06:15] <Unit193> pitti: Thank you very much!
[06:15] <pitti> no worries, thanks for the fix
[06:17] <mvo_> pitti: thanks, I have a look
[06:18] <darkxst> pitti, is the current adt cloud image broken? I can't run any autopkgtests locally atm. http://pastebin.com/3Eq8WNYU
[06:21] <pitti> darkxst: I had that a few days ago (some uninstallability problems), but works again with recent images
[06:22] <didrocks> @pilot in
[06:22] <darkxst> pitti, I am getting it with todays image
[06:23] <dholbach> good morning
[06:24] <didrocks> morning dholbach
[06:24] <dholbach> salut didrocks
[06:24] <dholbach> comment ça va?
[06:24] <didrocks> ça va plutôt bien, il fait chaud ! et toi ? :)
[06:25] <dholbach> très bien aussi :)
[07:07] <mvo_> pitti: when I try to reproduce the failure in the autopkgtest for click I run into http://paste.ubuntu.com/8297301/
[07:08] <mvo_> pitti: is that a known issue?
[07:10] <pitti> lxc-clone: unrecognized option '--name'
[07:10] <pitti> Error: container adt-utopic is not defined
[07:10] <pitti> mvo_: silly question, but do you actually have an adt-utopic container?
[07:10] <pitti> mvo_: also, did you run with "lxc -es"?
[07:10] <pitti> the pastebin doesn't show your command
[07:10] <mvo_> pitti: lxc-ls tells me I have adt-utopic
[07:11] <pitti> mvo_: so the next common error is to forget the -s, so that it runs lxc as user (and thus expects user containers, not system containers)
[07:12] <mvo_> pitti: thanks! the warning about --name is still there, but now it seems to work, thanks a bunch. would you mind me doing a patch that warns if uid != 0 and no -s ?
[07:12] <mvo_> pitti: so that the clueless^Wfogetfull^Wpeople get a hint :) ?
[07:12] <pitti> mvo_: that and "there is no user-level container of that name"
[07:13] <pitti> mvo_: not sure about the --name warning; that looks like an lxc buglet
[07:13] <pitti> mvo_: you can have per-user containers in utopic, so it should not warn about those
[07:14] <mvo_> pitti: *nod*
[07:21] <jtaylor_> hm how do I disable a daemon from starting in upstart? I'd googe it but a modern browser is no fun  to use with the cpu set to 800mhz :(
[07:21] <jodh> jtaylor: echo manual >> /etc/init/$job.override
[07:23] <jtaylor> thanks
[07:27] <jtaylor> ah sweet performance bliss :D
[07:27] <mvo_> pitti: so my adt-lxc gives me a very different error, is the lab using adt with the kvm backend? whats the best way to recreate this backend?
[07:27] <mvo_> pitti: and sorry for my silly question, I feel like I asked them before :/
[07:28] <pitti> mvo_: yes, we use qemu in the lab -- but that shoudn't matter for something like click?
[07:28] <pitti> mvo_: http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test is what we use in teh lab
[07:28] <pitti> mvo_: can you put the log into a pastebin?
[07:30] <mvo_> pitti: it shouldn't no, but - the lab test fails with "ImportError: Start directory is not importable: 'click.tests.integration'" before it even runs the tests - but let me see, I have some ideas
[07:30] <pitti> mvo_: what exactly did you run?
[07:30] <mvo_> pitti: thanks for the link I will bookmark it
[07:30] <pitti> mvo_: i. e. did you actually test the proposed package?
[07:31] <mvo_> pitti: yeah, I think that is the problem, I was running against the bzr tree
[07:31] <pitti> adt-run click -U --apt-pocket=proposed --- lxc -es adt-utopic
[07:31] <pitti> mvo_: that ought to reproduce it
[07:31] <pitti> mvo_: you can also add a -s (--shell-on-failure) to examine
[07:31] <mvo_> pitti: thanks a lot!
[07:31] <mvo_> pitti: that is super helpful
[07:32] <pitti> mvo_: https://people.debian.org/~mpitt/autopkgtest/README.running-tests.html FYI :)
[07:32] <pitti> mvo_: these are also in /usr/share/doc/autopkgtest/
[07:33] <mvo_> pitti: nice, thanks, I will remember that
[07:47] <Saviq> dbarth, hey, can you come to #ubuntu-release please
[08:20] <infinity> pitti: Hey, was wondering if you had any insight into the two autopkgtests that are preventing unity8's migration.  Both of them install a bunch of deps, and then say "dep installation failed", with no real meaningful debug output.
[08:20] <infinity> pitti: And, of course, I can't reproduce anything that looks like a "failure" locally.
[08:20] <pitti> infinity: (in meeting, coming back to you in a bit)
[08:21] <infinity> pitti: S'ok, I'm going to bed, I just wanted to hand it off to someone who knows adt and the infra and might be able to sort out WTF. :P
[08:21] <darkxst> infinity, I am getting similar failures locally (on different packages), that don't seem to be reproducing on jenkins ;(
[08:28] <pitti> infinity: tehre were some uninstallable packages for some tests (see the apt problem resolver output)
[08:34] <didrocks> dholbach: hey, do you know why https://code.launchpad.net/~canonical-platform-qa/dialer-app/qmltests1/+merge/233130 is on the sponsoring list? Seems a pure upstream dialer-app thing
[08:36] <seb128> didrocks, because ubuntu-core-dev is in the reviewers list
[08:37] <seb128> didrocks, it's there because they are packaging changes and that's what the CI documentation recommends doing, "get review from somebody with upload rights"
[08:37] <didrocks> seb128: yeah, we traditionally don't add core-dev for that, we have the LT with people having upload rights for it, but let's do the review
[08:38] <seb128> didrocks, right, I'm just explaining why it's there (I asked them before iirc)
[08:38] <didrocks> seb128: weird that it starts to count as sponsoring, as when I was reviewing almost all packaging change for touch, those wouldn't count at all as a patch pilot shift :)
[08:38] <seb128> didrocks, I don't think it "starts to count"
[08:38] <seb128> didrocks, it's just that $somebody didn't know how to get a review and subscribe core dev
[08:39] <seb128> subscribed
[08:39] <didrocks> yeah, probably
[08:39] <seb128> didrocks, I'm not sure it's an official/recommended workflow
[10:18] <GunnarHj> didrocks: Hi Didier!
[10:28] <GunnarHj> cyphermox_: ping?
[10:48] <ScottK> barry: Please see some of the later comments on Bug 1290847.  You are going to do this for Trusty, right?
[11:44] <didrocks> GunnarHj: hey, what's up? :)
[11:59] <GunnarHj> didrocks: See that you are piloting. Any chance that you can give these, involving trusty SRUs, some attention:
[11:59] <GunnarHj> https://code.launchpad.net/~gunnarhj/ubuntu/utopic/fonts-android/droid-sans-fallback-fix/+merge/229432
[11:59] <GunnarHj> https://launchpad.net/bugs/1308771
[12:01] <didrocks> GunnarHj: I'll have a look
[12:01] <didrocks> GunnarHj: but you nominated laney for the review, he's back next week and probably know better the matter, wdyt?
[12:02] <didrocks> I know he had it on his radar
[12:02] <didrocks> I can remind him once he's back :)
[12:02] <GunnarHj> didrocks: Ok, let's wait with that one. How about the other?
[12:03] <didrocks> GunnarHj: I'll poke bjoern at today's meeting, ensuring he's looking at it quickly
[12:03] <GunnarHj> didrocks: TIA
[12:03] <didrocks> GunnarHj: yw ;)
[12:14] <didrocks> @pilot out
[13:04] <tedg> pitti, Okay, I'll give that a try. Odd that the tests run on package build without issue, but not with autopkg.
[13:05] <cyphermox_> GunnarHj: hi
[13:05] <cyphermox_> oh, oops.
[13:05] <cyphermox_> @pilot out
[14:03] <desrt> hallyn: awake yet?
[14:03] <desrt> hallyn: should be be bumbing the version depend in cgmanager.c?
[14:03] <desrt> *bumping
[14:04] <hallyn> desrt: sigh, i don't know.  we'd need to get cgmanager into the archive first to do that.  i.e. ask slangasek to take a quick look at the package i have in mentors
[14:04] <desrt> i'm more or less done with my rewrite of your rewrite of my rewrite of your code ;)
[14:04] <hallyn> jodh: did you have a chance to look at latest cgmanager github changes?
[14:04] <hallyn> desrt: cool :)
[14:05] <hallyn> desrt: i wasn't sure what 'proper' file i/o looks like in glib, but also i simply cannot figure out how to do that gnome indenting style
[14:05] <hallyn> it's not always 2 spaces,
[14:05] <hallyn> 4 spaces for a while() block?
[14:05] <desrt> while (xxx)
[14:05] <desrt>   {
[14:05] <desrt>     do_stuff ();
[14:05] <desrt>   }
[14:05] <desrt> it's standard GNU style
[14:05] <hallyn> oh so always 2
[14:05] <hallyn> gotcha
[14:05] <hallyn> heh so maybe i should just fire up emacs next time
[14:06] <desrt> :)
[14:06] <desrt> there are a couple of things we do differently: always use soft spaces, never hard tabs
[14:06] <hallyn> i was a die-hard emacs user for a year or two around 1993
[14:06] <desrt> and we line up the parameters at the top of the function in that funky way...
[14:06] <desrt> but otherwise it's more or less stock GNU
[14:07] <desrt> fwiw, we have g_file_set_contents()
[14:07] <desrt> this is almost always better than using fopen, etc.
[14:08] <desrt> also, functions like g_remove, g_open(), etc. are only meant to be used on programs wanting ot be portable to windows
[14:08] <desrt> since otherwise they're just macros for the normal thing
[14:08] <hallyn> ok.  yeah i'd used g_file_get_contents(), i'm not sure why i didn't think to look for set_contents.  (it occurred to me last night in bed :)
[14:08] <desrt> (on windows, they do character-set conversion of the filename)
[14:08] <desrt> fwiw, i replaced that stuff anyway
[14:08] <desrt> with a single keyfile
[14:08] <hallyn> ok
[14:09] <desrt> it's easier to list out the groups in that case
[14:09] <hallyn> which is like a dictionary?
[14:09] <desrt> for the introspection
[14:09] <desrt> ya...
[14:09] <hallyn> cool
[14:09] <desrt> will look like
[14:09] <desrt> [session-1.scope]
[14:09] <desrt> path=/user-slice/blah
[14:09] <desrt> [session-2.scope]
[14:09] <desrt> path=etc.
[14:09] <desrt> i figure we can easily expand this if we want to get stateful about other unit types in the future
[14:12] <slangasek> hallyn: "cgmanager into the archive first" - i.e. there's a dependency chain here for getting the fix into the archive?  If so, please point me at it ASAP :)
[14:12] <slangasek> desrt: so "done" means "in upstream git"?
[14:13] <desrt> slangasek: no.  testing it first.
[14:14] <slangasek> ok
[14:15] <desrt> btw: what is the actual command that cgmanager uses to remove cgroups?  is it writing something to some file in sysfs or is there a proper syscall?
[14:15]  * desrt wants to clean up a bit...
[14:16] <slangasek> hallyn: ^^
[14:17] <desrt> also: how can i install the new cgmanager for testing?
[14:19] <desrt> fwiw: https://github.com/desrt/systemd-shim/commits/wip/abandon4
[14:19] <desrt> if someone else wants to test...
[14:20] <desrt> assuming nothing is wrong (and it looks fine to me from what i can test without the new cgmanager) then the only change that is needed is to bump the cgmanager dependency version to [whatever is correct] and push to master
[14:28] <jodh> hallyn: still on the list for today! :)
[14:29] <hallyn> slangasek: http://mentors.debian.net/debian/pool/main/c/cgmanager/cgmanager_0.32-1.dsc
[14:30] <hallyn> desrt: cgmanager does rmdir
[14:30] <desrt> oh.  interesting.
[14:30] <desrt> it can do that even when there are files in there?
[14:30] <hallyn> desrt: i won't be able to test for the next 30 mins, morning commotion
[14:30] <hallyn> yes, but not with subdirs
[14:31] <hallyn> the files are ignored
[14:31] <desrt> tasks are not
[14:31] <desrt> this is actually quite utterly sane...
[14:31] <desrt> omg how lovely
[14:31] <desrt> look ma!  i'm creating cgroups!
[14:31] <desrt> i suppose i move pids by echoing them into the tasks file?
[14:32] <hallyn> yup
[14:32] <desrt> this is awesome :)
[14:32] <hallyn> you can also use 'cgm', which is what i usually do for these tests
[14:32] <hallyn> cgm create all xxx/y
[14:32] <hallyn> sleep 20 0&
[14:32] <hallyn> cgm movepid all xx/y $!
[14:32] <desrt> what's with the 0?
[14:33] <hallyn> it's a misplaced space :)
[14:33] <hallyn> sleep 200 &
[14:33] <desrt> :)
[14:33]  * hallyn biab
[14:33] <desrt> TIL: you can give multiple arguments to sleep(1) and it will handle each one in turn
[14:33] <desrt> sleep 10 5 == sleep 15
[14:51] <rbasak> How does one do a dep5 file that involves a BSD-3-clause, but where the ORGANIZATION placeholder has been replaced by different organisations in different files?
[14:52] <rbasak> I can't collapse the License text to a single stanza easily, since then I'll have failed to preserve the text as required.
[14:52] <rbasak> Unless I name them differently, in which case I've failed to use the recommended common name.
[14:52] <cjwatson> You don't have to have a separate stanza for the License text; you can put it in a Files stanza
[14:53] <rbasak> I want to though, since I'm using many Files stanza which _do_ have a common license text.
[14:53] <bigon> doko: hey do you have any plans regarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720545 ?
[14:53] <cjwatson> I think that's probably the best you can do.
[14:53] <rbasak> Would it be acceptable to use my own names? Eg. BSD-3-clause+Google, with the full text at the bottom? This detracts from the common names.
[14:54] <cjwatson> You should be able to coalesce the identical ones, since the Files field takes a whitespace-separated list.
[14:54] <rbasak> But this is an incredibly complicated dep5 file, since juju embeds upstream sources.
[14:54] <cjwatson> Unless they have different Copyright, I suppose.
[14:54] <cjwatson> But the definition of Copyright does say "Not all copyright notices may apply to every individual file".
[14:54] <rbasak> I'm trying to avoid collapsing Files fields that come from separate upstream projects, to try and help make it easier to update the file in the future.
[14:54] <rbasak> Then I only have to review the section of the file that has changed.
[14:55] <rbasak> But I have bundled all the license texts at the bottom, since they're very common (eg. standard Google golang 3-clause with Google, Inc. organisation)
[14:55] <cjwatson> I think at this point I'd recommend asking debian-policy or similar for advice ...
[14:56] <rbasak> I wondered where I should ask the question. Though Juju isn't currently packaged for Debian.
[14:57] <cjwatson> Or, slangasek is listed as the driver :)
[14:57] <cjwatson> But it's been incorporated into debian-policy, so I think that's the right contact address
[14:58] <rbasak> I think I'll just fail to use the common name in this case, and explain why in a comment at the top. AFAICT, that doesn't violate the spec.
[14:59] <rbasak> I'm using names like "BSD-3-clause+Google" instead, which I hope is clear.
[14:59] <cjwatson> I don't think it violates the spec, no.  It's a trade-off of less-desirable options is all.
[14:59] <rbasak> Yeah.
[15:00] <cjwatson> It would be nice if people who had to do this were using a consistent syntax to denote the variant names though.
[15:00] <rbasak> It's 256 lines long without any license texts :-/
[15:00] <rbasak> That's ~30 embedded upstream projects.
[15:02] <rbasak> I guess the core issue is that there are two things trying to fit into the licence name field. 1) a ref for Files stanzas to refer to; and 2) a reference to an outside standard.
[15:03] <rbasak> Except that the licence text is permitted to vary, still meets the outside standard, but I need separate refs.
[15:03] <rbasak> Anyway
[15:03]  * rbasak JFDI
[15:04] <rbasak> Thank you for the discussion. At least I know I'm not missing something and there isn't a better answer.
[15:04] <davmor2> rbasak: just 1 small line off a JEDI then so close
[15:05] <rbasak> :)
[15:26] <desrt> hallyn: sup?
[15:28] <hallyn> desrt: you're asking if i've tested your wip/abandon4, or if i've heard from slangasek  about the cgmanager package?
[15:28] <hallyn> zul: pushing one last candidate of libvirt to ppa, will run tests, then push to utopic
[15:28] <desrt> if you've done the first one then i don't care about the second :)
[15:28] <zul> hallyn: cool
[15:28] <hallyn> desrt: not yet, lemme spin up the vm
[15:30] <hallyn> zul: libvirt_1.2.8-0ubuntu1~ppa2_source.changes pushed to ppa:serge-hallyn/virt.  now wait, do we need ffe for this, or did you already get that?
[15:31] <zul> hallyn: not yet
[15:33] <hallyn> do you mind filing it?
[15:39] <hallyn> desrt: so the one change that helped for me was to add a cgmanager_prune (path); to the top of ccgroup_unit_stop()
[15:39] <hallyn> desrt: not sure if there is a race otherwise or what, but the cgroup doesn't always get removed
[15:39] <desrt> weird....
[15:40] <desrt> maybe the kill is slow
[15:40] <desrt> like the kernel doesn't have time to properly kill off the processes
[15:40] <desrt> or maybe they don't get reaped or something
[15:40] <desrt> so the remove fails...
[15:40] <desrt> makes sense, though.  i'm happy to change that.
[15:40] <hallyn> yo'ud think the n retries would work around that :(
[15:40] <desrt> not if it happens so quickly
[15:40] <hallyn> but then there have been a few problems with cgroups in the last few kernels where rmdir goes slowly etc
[15:41] <desrt> if we don't get scheduled out....
[15:41] <desrt> we're running a pretty tight loop there, without even a sched_yield() or so
[15:41] <hallyn> dbus calls though?
[15:41] <desrt> true...
[15:41] <desrt> *shrug*
[15:41] <hallyn> yeah
[15:41] <desrt> we could add sched_yield and i bet this would help
[15:41] <desrt> but.............
[15:41] <hallyn> otherwise looking good - thanks
[15:41] <desrt> any bug that sched_yield fixes is not truly fixed
[15:41] <desrt> so i think your solution is better :)
[15:42] <desrt> hallyn: i need to know the new version number for cgmanager...
[15:42] <desrt> then i'll push
[15:44] <hallyn> desrt: 0.32-1
[15:44] <desrt> what protocol version, i mean
[15:44] <desrt> for the check at connection time
[15:44] <desrt> we have 6 now...
[15:44] <desrt> 7? 8?
[15:50] <hallyn> oh, 8
[15:50] <hallyn> desrt: ^
[15:50] <desrt> thanks.
[15:51] <desrt> will push after our desktop meeting
[15:51] <hallyn> thx, ttyl
[15:51] <desrt> i guess a release is due now, too.
[15:51] <desrt> any other patches you guys are carrying around?
[15:51] <desrt> slangasek: ^ ?
[15:51] <hallyn> you mean for systemd-shim itself?
[15:51] <desrt> yes
[15:51] <desrt> ie: any vendor patches that i can take upstream
[15:52] <hallyn> not from me
[16:11] <slangasek> desrt: the only systemd-shim patches are cherry-picks
[16:11] <desrt> cool.  thanks for the info.
[16:31] <hallyn> slangasek: d'oh, there's an open debian bug which i should fix in that cgmanager pkg (badness in sysvinti job)
[16:35] <slangasek> hallyn: ok; shall I wait for a reupload to mentors?
[16:35] <hallyn> slangasek: yes please, should be up in 5 mins
[16:35] <hallyn> just trying ot make sure i'm not missing some sysvinit-ism tha tmakes the bug report wrong
[16:37] <slangasek> hallyn: well, I would recommend using do_start / do_stop as the function names, rather than using function names that are the same as upstart commands
[16:37] <slangasek> hallyn: but I can confirm that this is a real bug
[16:38] <hallyn> slangasek: i'd feel more comfortable doing that change (back to ->do-start) in a later relase with more testing
[16:38] <slangasek> oh?
[16:38] <hallyn> no?  well i can do it now i guess :)
[16:38] <slangasek> why?  this is purely a shell name mismatch problem
[16:39] <slangasek> so looking at the change to debian/cgmanager.cgmanager.upstart
[16:39] <slangasek> what are you expecting this to do?
[16:39] <slangasek> +start on mounted MOUNTPOINT=/sys/fs/cgroup or virtual-filesystems or starting dbus
[16:39] <slangasek> that will not block the start-up of dbus
[16:39] <slangasek> in fact, it will 100% never trigger on 'starting dbus', because virtual-filesystems is always emitted before local-filesystems and dbus starts on local-filesystems
[16:41] <hallyn> slangasek: that is what fixed the previous phone problem (i didn't come up with that fix)
[16:41] <hallyn> apparently ther ewere jobs which were start on started dbus which started before cgmanager was ready
[16:41] <hallyn> ok, pushing new cgmanager to mentors now
[16:43] <slangasek> hallyn: which phone problem was fixed by this?  because that change is nonsensical with the standard dbus job, and if the phone is overriding the start condition for dbus, then cgmanager's startup condition needs to also be overridden there, not as part of the job in the cgmanager package
[16:43] <hallyn> pitti: ^
[16:44] <hallyn> I guess tedg had originally proposed it
[16:47] <hallyn> slangasek: i suppose we could keep it out of the debian pkg and keep it as ubuntu delta until we're sure whether and why we need it (and maybe have better fix)
[17:05] <desrt> slangasek: okay.  systemd-shim-8 is released
[17:06] <desrt> slangasek: i moved the tarball dir from ~desrt/ to ~desrt/systemd-shim
[17:06] <desrt> 451357c32ada3d68fec56f508990739edee19e9088509adfabf0648068015bcf  systemd-shim-8.tar.xz
[17:29] <slangasek> hallyn: so I'll sponsor this cgmanager package as-is; the upstart job change looks wrong because it's ineffective, not because it's harmful
[17:31] <hallyn> slangasek: ok, thx
[18:01] <arges> hallyn: would you like me to get the qemu SRU debdiff ready for bug 1366868? i could also do the combination with bug 1324174 if you want
[18:01] <hallyn> arges: sure - i was planning on doing this afternoon, but i'll move on to qemu merge for utopic in that case
[18:01] <hallyn> arges: thanks!
[18:01] <arges> hallyn: np
[18:11] <hallyn> slangasek: so, 'or starting dbus' wont' make cgmanager start earlier, but can't it delay dbus starting?  that's how i thought it fixed the problem we wer ehaving on krilin
[18:22] <slangasek> hallyn: no, it doesn't delay dbus starting
[18:22] <arges> hallyn: so the patch that fixes the issue for me actually updated the pc-bios/*bin files, which I believe we don't put into our source package; so maybe I need to patch seabios...
[18:23] <slangasek> hallyn: because cgmanager is already starting when 'virtual-filesystems' triggers, and upstart won't block starting dbus for this
[18:23] <hallyn> slangasek: my undestanding was always that y having  'start on starting x' meant that when x starts, y will first start, then x will start
[18:23] <hallyn> arges: oh.  yeah.
[18:23] <slangasek> that's what 'start on starting x' means
[18:23] <slangasek> that's not what 'start on foo or starting x' means
[18:24] <hallyn> ah
[18:24] <arges> hallyn: so i'll have to track that one down... if you wan to go ahead with the other SRU go for it
[18:24] <hallyn> arges: what's the git commit id again?
[18:25] <arges> hallyn: well db76ec6291df8a03c2cc82ea1249049383cca392 in qemu. but they just bumped their seabios version. so I need to track down the actual seabios commit
[18:25] <hallyn> arges: espeak love sspitting out commit ids :)
[18:25] <arges> heh, i'm glad i don't have that turned on
[18:26] <hallyn> arges: ok, thanks, i'll do the other one then :)
[18:26] <arges> great
[18:42] <mterry> barry, I never heard of nose2 before.  Was there some fork?  Why not make nose better?
[18:43] <barry> mterry: nose is eol'd. nose2 is much better and the official next version.  all new development is happening on nose2
[18:43] <barry> so i guess the answer is kind of and time machine :)
[18:44] <mterry> barry, huh...  should we as a project try to get nose into universe?  Probably not a whole lot of maintenance work, but I'm curious how much of a push there is to get projects to switch
[18:45] <barry> mterry: there's hasn't been a concerted effort.  the api's are different, but nose2 is much better.  i tell people to switch, but yes, i'd like to see migrations from nose to nose2
[19:00] <tedg> slangasek, The though there was that systemd-shim was getting dbus activated even before the android container started.
[19:00] <tedg> thought
[19:02] <slangasek> tedg: none of these start conditions are related to the android container
[19:02] <tedg> slangasek, No, but I thought that's why you were saying it is ineffective.
[19:03] <tedg> slangasek, Why do you think it's ineffective.
[19:03] <slangasek> tedg: what problem was this change supposed to solve?
[19:03] <ogra_> doesnt systemd-shim (and the session bus) get started by lighdm ?
[19:03] <ogra_> thats definitely guaranteed to start after the container
[19:03] <slangasek> the start condition does not cause cgmanager start-up to block dbus start-up
[19:03] <ogra_> (due to lightdm.override with differnt start conditions)
[19:03] <tedg> slangasek, jodh had found some cases where cgroups manager was starting after systemd-shim, and systemd-shim wasn't detecting it starting, so thought it didn't have cgmanager support.
[19:04] <tedg> slangasek, We can't (grumble, dbus activation) ensure that we start before it, so the goal was to make it better.
[19:05] <slangasek> tedg: my reading of the change to the job config is that it's a complete no-op
[19:05] <slangasek> tedg: the conditions are still the same: cgmanager will be started "before" dbus but not in a blocking manner
[19:06] <tedg> slangasek, Yes, not blocking, it can't block dbus starting (I forget why now). So not a guarantee, correct.
[19:06] <slangasek> tedg: so the 'or starting dbus' is *never hit*
[19:06] <slangasek> unless someone has totally bodged all the start ordering on the phone, which is possible
[19:06]  * tedg doesn't comment
[19:07] <ogra_> not that badly :P
[19:07] <tedg> slangasek, The thought was that initrd might be mounting some of the filesystem triggers already, so they weren't happening.
[19:07] <ogra_> http://people.canonical.com/~ogra/touch-bootcharts/ubuntu-phablet-utopic-111.png ... quite old, but i dont think the order changed much since
[19:07] <slangasek> tedg: the filesystem events should still happen, and in order; virtual-filesystems should be emitted before local-filesystems, or else I'm wrong about how mountall works
[19:09] <tedg> slangasek, Ah, okay. To be clear, I'm just the messenger here :-)
[19:09] <tedg> Someone was busy planning debconf ;-)
[19:13] <hallyn> should be easy enough to test with a test pkg removing that bit
[20:57] <Triniboi00> does the os ubuntu support long term scehduling?
[20:57] <sarnold> Triniboi00: what's that?
[20:58] <Triniboi00> Long term scheduling: which determines which programs are admitted to the system for execution and when, and which ones should be exited.
[20:59] <Triniboi00> does ubuntu support this?(school project looking for guidance)
[21:00] <sarnold> Triniboi00: the linux kernel has one, non-pluggable, scheduler. whichever tasks are selected for running are selected based on the details of the one scheduler without much in the way of deadlines or goals
[21:00] <sarnold> Triniboi00: the cgroup system can modify the parameters somewhat, as can the nice levels
[21:01] <sarnold> .. as well as the SCHED_RR, SCHED_FIFO, SCHED_BATCH, etc. scheduling priorities..
[21:01] <sarnold> Triniboi00: it sounds a lot like what you're looking for is a cluster-level job scheduler to schedule jobs on specific machines?
[21:01] <Triniboi00> no
[21:02] <Triniboi00> http://www.cim.mcgill.ca/~franco/OpSys-304-427/lecture-notes/node38.html
[21:03] <Triniboi00> these are the type of scheduling i just want to know which does unbutu support?
[21:03] <sarnold> Triniboi00: ah! some kind of crazy professor definition :)
[21:05] <sarnold> Triniboi00: see the 'nproc' rlimit in setrlimit(3) and /proc/sys/kernel/pid_max and /proc/sys/kernel/threads-max in proc(5)
[21:06] <Triniboi00> ETMLI5
[21:07] <Triniboi00> 8.	Does the OS support long term scheduling?  9.	Does the OS support medium term scheduling (swapping)?   10.	Describe the short term (CPU) scheduling algorithms implemented in the OS :
[21:07] <sarnold> yeah, no OS has done _swapping_ in decades
[21:07] <Triniboi00> these are the questions i have to answer for unbuntu
[21:07] <sarnold> paging is the new hotness
[21:07] <sarnold> for the last 25 years or so
[21:09] <Triniboi00> so the answers are no to all?
[21:10] <sarnold> Triniboi00: no, the answers require some nuance :)
[21:13] <Triniboi00> there yes or no questions whats up?
[21:18] <dobey> do your own homework
[21:18] <dobey> also, they're
[21:20] <Triniboi00> lol i do my own hw
[21:20] <Triniboi00> these are 3 questions out of 22 that i cant find ...linux has a completley fair scheduler
[21:21] <Triniboi00> but i cant find if its supports long term or not i am not well versed in the subject
[21:27] <cjwatson> Long-term scheduling sounds like a concept from batch-processing systems that doesn't really apply.  There are resource limit controls that can cause fork to fail, and things like the OOM killer that will sometimes forcibly kill processes in exceptional situations, but those aren't really part of what I'd characterise as core scheduler behaviour.
[21:28] <sarnold> Triniboi00: a few minutes with the setrlimit and proc manpages ought to help a little.
[21:30] <cjwatson> I suppose you might also look into process priorities and control groups and such things.  The approach in all Unix systems I'm aware of though tends to be to accept the process (except for some exceptional situations like running over resource limits, but as I say those don't really come up much in normal operation) and then whether the scheduler actually ever gives it any timeslices later is up to it ...
[21:31] <Triniboi00> ah ok so i see ubuntu does not use the LTS because its first come first serve
[21:32] <Triniboi00> long term scheduling is a no
[21:32] <cjwatson> That would be an overly simplistic characterisation.  Linux's scheduling certainly isn't first-come-first-served.
[21:32] <cjwatson> I suppose that's sort of true of process admission but I think putting it that way is confusing.
[21:33] <sarnold> cjwatson: you've got to see the crazy page from the professor to understand the meaning of "first come first served" in the context "long term scheduler".. they're like lecture notes that havent been updated in 30 years...
[21:33] <sarnold> despite clearly being written in html :)
[21:34] <cjwatson> Yeah, I skimmed it
[21:35] <cjwatson> In general I think you'll do better in your research if you note that for this purpose the distinctions between Ubuntu and other distributions are not desperately relevant; you'll get more interesting research hits by just looking for commentary on the behaviour of Linux.
[21:36] <Triniboi00> yea  i have seen that
[21:36] <cjwatson> Practically all of this is up to the Linux kernel; while that is modified and built by Ubuntu, you aren't going to find core differences at the sort of level that's relevant to this kind of work.
[21:36] <Triniboi00> thanks for the help i think i understand what to do
[21:37] <sarnold> have fun :)
[21:37] <Triniboi00> will do :D
[21:38] <Triniboi00> what is this btw are you developers?
[21:38] <Triniboi00> or this is just a social thing
[21:39] <sarnold> I do mostly security work; not so much development on my own as picking nits with other people's development work
[21:40] <cjwatson> Lots of developers are here, but not necessarily kernel developers.
[21:40] <Triniboi00> ah i do security work as well
[21:40] <Triniboi00> for ibm
[21:42] <sarnold> nice :)
[22:39] <hallyn> process question - if there is a new debian qemu release that fixes a (9p readdir d_type) flag.  should i simply push it right now as it's a bugfix even without an open ubuntu bug, or should i open a bug just to close it?
[22:53] <RoyK> anyone had a look at this https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1364091
[23:05] <hallyn> (anyway, i'll test+push i guess)