[00:50] <infinity> hallyn: So, when do I get qemu-system-aarch64, now that it's upstream? ;)
[01:21] <hallyn> infinity: ?  why don't you have it yet?
[01:22] <infinity> hallyn: Sorry, I should have specified "with full emulation".
[01:22] <hallyn> ah
[01:22] <infinity> hallyn: We have kvm-only right now.
[01:22] <hallyn> yeah
[01:22] <hallyn> so it depends how badly you want it i guess :)
[01:22] <infinity> hallyn: OMG SO BADLY.
[01:22] <hallyn> clearly my preference would be to wait until it'sin a release,
[01:23] <hallyn> but i'll happily do buidl with the patchset if you need it
[01:23] <infinity> hallyn: Nah, I don't *need* it.  Though, if it's undisruptively backportable to 2.0, it would be shiny to have.
[01:23] <infinity> hallyn: (And if it were isolated enough to be ignorable in a review as obviously not breaking other targets, I'd even consider it for an SRU so the LTS can emulate all the arches we shipped)
[01:25] <infinity> That might actually be a first, given that qemu-system-ppc was pretty broken until just recently too.
[01:25] <hallyn> speaking of which has openbios-ppc's mir happened yet?
[01:26] <hallyn> but anyway i'll see if i can get a reasonable patchset (at ods this week so not sure when i'll get a chance to do it justice)
[01:26] <infinity> hallyn: People emulating sane systems use qemu-slof, not openbios-ppc.
[01:26] <infinity> hallyn: (Though that's also in universe, I think)
[01:26] <infinity> Yeah, it is.
[01:27] <hallyn> actually taht's the one i meant, yeah
[01:27] <infinity> We probably should have pulled it into main for trusty and made qemu-system-ppc depend on it, didn't even think about it.
[01:27] <infinity> Oops.
[01:28] <infinity> Oh well.  That one extra step of "install slof" isn't a world-ending thing to put on a wiki HOWTO or something.
[01:28] <hallyn> well i'd hoped tha tthe suggests would suffice, but it doesnt' seem to be reducing the # of bugs :(
[01:28] <hallyn> yeah maybe i should add it to the community docs
[01:28] <infinity> hallyn: Oh, you actually get bugs about it?
[01:29] <hallyn> yeah, suggesting more ppl are trying out qemu-system-ppc in the last few months than... ever
[01:29] <infinity> hallyn: Yeah, that's actually a positive note, other than the bit where it generates bugs. :P
[01:30] <infinity> hallyn: So, AFAICT, people who want to emulate ancient Macs need openbios-ppc, people who want to emulate pSeries (ie: newer IBM machines) want qemu-slof.
[01:30] <infinity> hallyn: I'm less fussed about the first group, but we kinda want the second group to work.
[01:31] <infinity> hallyn: And, indeed, if we decide to make trusty a viable host for ppc64el KVM guests, we'll need slof too.
[01:31] <infinity> hallyn: So, we might have to look at a sketchy promotion-to-main-in-updates for that one down the road.
[01:31] <hallyn> or a fugly in-universe qemu-ppc metapackage that depends on the right things :)
[01:32] <infinity> Ick.
[01:32] <hallyn> :)   half-joking
[01:33] <infinity> I don't think you'll find much (any) resistance from people on the points of SLOF being well-maintained upstream and a worthy candidate for main in general.  It's just the post-release promotion thing that's an unpleasant hack (as we can't/won't change it in release, so it'll be mismatched in release/updates)
[01:33] <siretart> infinity: when do you think would be a good time to start the libav transition in utopic? https://release.debian.org/transitions/html/libav10.html
[01:33] <infinity> siretart: yesterday?
[01:33] <hallyn> is that going back to ffmpeg?
[01:34] <infinity> siretart: More seriously, check to see if there are any other transitions in progress that you'll heavily overlap with before you start.
[01:35] <siretart> infinity: ok, so I can certainly upload libav10 to utopic, but I currently don't have the resources and time to push this transition through in both debian and ubuntu. I would definitly need someone to keep an eye and drive that in ubuntu
[01:35] <hallyn> hm,what're the odds i'll brick my vm byinstalling dh-systemd
[01:35] <infinity> siretart: And by the looks of britney, I'd say the answer is "no", I don't see any multimedia madness currently.  So this wouldn't be an awful time to try to bang out a libav transition *is* it's going to go smoothly.
[01:35] <siretart> I'd certainly help out, but I'm not able to actually drive it
[01:35] <infinity> siretart: Do you know how much of it will be clean rebuilds, how much needs patches for API changes, etc?
[01:35] <siretart> it's going to be pretty bad
[01:36] <infinity> siretart: Okay, so, some numbers on what the "pretty bad" is, and if there are already patches in flight for the badness, etc, would be nice before you upload.
[01:36] <siretart> there have been a lot of API deprecations and many year-old deprecated functions have been dropped
[01:36] <Unit193> hallyn: Pretty much none, it's a dh helper and that's it.
[01:36] <siretart> it will also very likely require some removals.
[01:36] <infinity> siretart: Also, if you write up (or have a reference to) a porting guide that outlines API changes, what's been dropped, what we might want to use instead, etc, others can certainly help.
[01:37] <hallyn> Unit193: cool, that was my hope
[01:37] <infinity> siretart: We have people who are pretty good with this sort of thing, but we prefer not to work blind. ;)
[01:37] <siretart> infinity: you mean such as https://wiki.libav.org/Migration/10 ?
[01:37] <infinity> siretart: Exactly that, yes.
[01:37] <siretart> infinity: I've been working on this transition by patching packages since february (no kidding)
[01:38] <infinity> siretart: So, if you give me a bit of time to rustle up some formal resources for a +1 rotation of people who I know are solid with this sort of thing, between you working on it in Debian, and us working in Ubuntu and pushing patches back, we could probably knock it out quickly.
[01:38] <siretart> infinity: that would be awesome.
[01:39] <siretart> infinity: as said, I'm definitly going to assist as good as I can, but realistically, we'd better have someone else driving and coordinating this transition on the ubuntu side
[01:41] <siretart> infinity: so just let me know when you think it would be a good time to upload it to utopic-proposed
[01:41] <infinity> siretart: Understood.  Normally, I might be inclined to say "eh, stuff it, we'll just wait until it's done in Debian and sync it all", but if you're trying to get this done before jessie's freeze, a bit of help from us might not hurt. :P
[01:41] <siretart> absolutely
[01:42] <siretart> keep in mind that we do have a couple of extra packages in ubuntu that are not being taken care of in debian
[01:42]  * infinity nods.
[01:42] <siretart> I guess we should just remove the binaries and hope for the best
[01:43] <siretart> for some packages, such as mplayer, we might get away with using its internal copy of libavcodec, but that's certainly not going to fly in general
[01:44] <siretart> infinity: in any case, thanks for your understanding and assistance!
[01:45] <infinity> siretart: I'm pretty not happy about the idea of a statically linked mplayer.  Is mplayer really no longer libav-compatible? :/
[01:46] <infinity> siretart: Does this go back to the age-old libav-vs-ffmpeg debate, and mplayer is primarily an ffmpeg project?
[02:08] <siretart> infinity: if you are truely bored, see the fight I had with raimar here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159
[02:08] <ubottu> Debian bug 732159 in ftp.debian.org "RM: mplayer - RoM - unmaintained, RC-buggy, alternatives exist" [Normal,Open]
[02:09] <siretart> infinity: short story: we both agreed that it would be feasible to get it working with libav if you are willing to compromise on infrequently used features, but nobody could be found to actually make that happen. I am certainly pissed off enough to no longer bother.
[02:14] <infinity> siretart: *sigh*... Is there any chance _at_all_ of a reconciliation between libav and ffmpeg people and a merge of the codebases?
[02:15] <siretart> infinity: well, you shall never say never, and there are indeed efforts on both sides, but given the current state of affair, I certainly wouldn't hold my breath
[02:16] <infinity> :(
[02:16] <infinity> Why can't we all just get along? :P
[03:02] <darkxst> infinity, could you upload https://bugs.launchpad.net/ubuntu/+source/gnome-photos/+bug/1319236 (it should be in our packageset but it isnt ;( )?
[03:02] <ubottu> Launchpad bug 1319236 in gnome-photos (Ubuntu) "support tracker 1.0" [Undecided,New]
[03:09] <infinity> darkxst: Or, if I can figure out how, I could add it to your packageset.
[03:09] <darkxst> infinity, that would work too
[03:11] <infinity> darkxst: I'm running to the store with my roommate.  I'll figure out how to fix it when I get back.
[03:11] <darkxst> infinity, ok and thanks
[03:36] <infinity> darkxst: Oh, maybe I can't edit it anyway.  Weird.  I thought the TB could.  Maybe it's only the DMB.
[03:37] <infinity> That's annoying.
[03:38] <infinity> stgraber: Halp.
[03:42] <infinity> darkxst: I give up on doing the right thing.  Just test-building before I sponsor. :P
[03:55] <darkxst> infinity, ok, I will get the packageset sorted later
[04:05] <Mirv> doko_: I can take a look. some Qt packages come directly from Debian via autosync, but some have our own changes (and symbols files)
[05:16] <Mirv> could someone with powers mark https://code.launchpad.net/~israeldahl/ubuntu/utopic/lmms/lmms_1.0.1/+merge/217857 as having been merged (at the latest revision)?
[05:21] <TheMuso> Mirv: WIll do, that was my fault, forgot to do that after having to work on the package outside of UDD.
[05:22] <pitti> Good morning
[05:28] <Mirv> TheMuso: thanks!
[05:30] <TheMuso> np
[06:16] <pitti> doko_: btw, bzr-builddeb's test is fixed in debian, just waiting for LP to import it and sync
[06:17] <pitti> (one of the two remaining things that hold back python-default)
[06:18] <RAOF> pitti: Would you like to upload colord to experimental at your leisure?
[06:18] <pitti> RAOF: sure
[06:18] <RAOF> While I'm waiting on a transition slot.
[06:19] <pitti> RAOF: do you want to dch -r/debcommit -r or want me to?
[06:23] <RAOF> pitti: Done so.
[06:24] <pitti> RAOF: hm, were you missing git push --all? pristine-tar/upstream seems outdated
[06:25] <RAOF> pitti: Quite possibly; now done.
[06:25] <pitti> RAOF: ah, all there now; building
[06:31] <dholbach> good morning
[06:36] <pitti> RAOF: aaaand uploaded
[06:37] <mvo> hey dholbach
[06:37] <dholbach> hey mv
[06:37] <dholbach> hey mvo
[06:37] <pitti> mvo, dholbach: guten Morgen!
[06:38] <mvo> hey pitti, good monring
[06:39] <dholbach> hey pitti
[06:39] <dholbach> na Jungs, wie läuft's?
[06:39] <RAOF> pitti: Danke
[07:11] <nandersson> Hi cjwatson, reported a package problem yesterday with respect to samba-common-bin - looks like it is a bug in the version of PackageKit that trusty comes with.
[07:11] <nandersson> so, it is not related to apt or packaging, but PackageKit rather :-/
=== doko_ is now known as doko
[07:53] <doko> xnox, are you able to reproduce the unity issue with pch? if yes, a stacktrace of cc1plus would be nice
[08:04] <darkxst> Laney, a while ago I asked (on devel-permissions list) for gnome-photos to get add to our packageset, did you miss that one?
[08:16] <Laney> darkxst: maybe
[08:28] <stgraber> stgraber@castiana:~/data/code/ubuntu-archive/ubuntu-archive-tools$ ./edit-acl add -P ubuntugnome -s gnome-photos -S utopic
[08:28] <stgraber> Added:
[08:28] <stgraber> gnome-photos
[08:28] <stgraber> infinity: ^
[08:29] <Laney> why infinity?
[08:29] <Laney> also, I was checking if it was seeded and it's not
[08:29] <Laney> → desktop-extra
[08:31] <darkxst> stgraber, Laney, yes it should have gone into desktop-extra!
[08:32] <Laney> unless you do plan on seeding it in which case it might not be worth the effort to change :-)
[08:35] <darkxst> Laney, probably not this cycle, its not quite feature complete yet
[08:36] <stgraber> Laney: I'll move it. I guessed ubuntugnome based on the earlier discussion with infinity but I apparently guessed wrong ;)
[08:36] <Laney> ah I didn't see any earlier one
[08:36] <Laney> I think desktop-extra is for the random gnome-y additional bits and ubuntugnome itself for the image
[08:36] <stgraber> done
[08:36] <Laney> ty
[08:37] <Laney> btw, we should make some time at $sprint to look at fixing that script if possible
[08:37] <Laney> as it's clear that I'm failing to do it on my own
[08:40] <stgraber> Laney: yeah, we can do that
[08:41] <stgraber> Laney: I'll add an item for that to the foundations malta agenda so I remember :)
[08:41] <Laney> great
[08:42] <Laney> put my name or something so that I can legitimately go away for a bit :P
[08:42] <stgraber> Laney: "fix the packageset/seed generator (stgraber, Lantey) "
[08:42] <stgraber> *Laney
[08:42]  * Laney nod
[08:45] <darkxst> stgraber, thanks!
[08:47] <Laney> darkxst: btw codesearch should be back
[08:47] <Laney> well, as back as it ever was
[08:49] <darkxst> Laney, great!
=== MacSlow is now known as MacSlow|lunch
=== _salem is now known as salem_
=== pete-woods is now known as pete-woods-lunch
=== MacSlow|lunch is now known as MacSlow
[12:28] <mlankhorst> hm can someone put mesa in utopic? seems to fail on an unrelated autopkgtest, probably because of gnat
[12:39] <pitti> right, the ada stack is broken in utopic-proposed (and debian unstable), so libgtkada can't work
[12:40] <pitti> mlankhorst: the release team can override the failure
[12:40] <mlankhorst> ok
[12:40] <mlankhorst> is this enough of a ping or should I ask in #ubuntu-release?
[12:41] <seb128> tjaalton sort of asked earlier
[12:41] <pitti> Laney: ^ ?
[12:41] <seb128> well, he asked what was the issue, not to override
[12:41] <seb128> but overriding it seems fine to me
[12:41] <mlankhorst> ah goodie :)
[12:41] <pitti> yes, to me too
[12:42] <Laney> will look in a min
[12:48] <pitti> dholbach: we changed the time of the tech board meeting; how can I get http://fridge.ubuntu.com/calendars/ updated?
[12:48] <dholbach> pitti, https://wiki.ubuntu.com/Fridge/Calendar
[12:49] <pitti> dholbach: right, I found that, but it doesn't link to a particular google cal, or say how I can update an existing event?
[12:50] <dholbach> pitti, for the event you're looking at, can you see who created it?
[12:51] <pitti> ooh, I can click on it on fridge.u.c.
[12:51] <pitti> https://www.google.com/calendar/render?eid=MXFwcnZuZW5lbWlraDU0ajY0MmhmbGU4NjhfMjAxNDA0MjhUMjAwMDAwWiBqNXE4NW1taTZ1anZqdGlpNXMxbjNsaTVpb0Bn&ctz=Etc/GMT&sf=true&output=xml
[12:51] <pitti> dholbach: mdz apparently
[12:52] <pitti> dholbach: so, I'll ask him to update that
[12:52] <dholbach> pitti, I pinged pleia2 and jose - maybe they have fridge calendar super powers
[12:52] <dholbach> I have no idea, sorry
[12:52] <pitti> dholbach: ack, thanks
=== pete-woods-lunch is now known as pete-woods
[13:08] <jtaylor> is there anything we can do about the incomplete tcl/tk transition in trusty?
[13:09] <jtaylor> like finishing it up post release or adding new source packages?
[13:09] <jtaylor> e.g. blt is linked against 8.6 and itcl3 still against 8.5, use them together and boom
[13:10] <jtaylor> (both libraries so they affect a fair share of applications)
[13:14] <jtaylor> infinity: you ported blt to 8.6, we still need a 8.5 blt for e.g. skycat
[13:14] <jtaylor> as the shared library is luckily versioned I would suggest adding a new source package blt8.5 to trusty which builds against 8.5
[13:15] <doko> jtaylor, can't we just link itcl3 with 8.6?
[13:15] <jtaylor> doko: yes but then we have to change a whole stack of applications too
[13:15] <rbasak> jtaylor: thanks for digging into this. Can I suggest a dep8 test too? This would catch the same issue next time I think, right?
[13:16] <doko> jtaylor, how many?
[13:16] <jtaylor> doko: direct dependencies about 9
[13:16] <jtaylor> but some of them look like bases of other stuff
[13:16] <jtaylor> like plplot
[13:17] <jtaylor> some apache stuff even
[13:17] <doko> ugh, ugly package anyway
[13:17] <jtaylor> rbasak: well looking at build logs would have been enough in this case already :)
[13:17] <doko> so can we build these in utopic first using 8.6 and then decide what to do?
[13:17] <jtaylor> one could try
[13:18] <jtaylor> I tried buildint itcl3 against 8.6 but still didn't get it to work
[13:18] <jtaylor> don't know why yet
[13:18] <jtaylor> building blt against 8.5 worked
[13:20] <jtaylor> I may have forgotten some other library thats still linked against 8.5
[13:25] <jtaylor> assuming we get utopic to work with 8.6 only, can the fixes be all SRU'd to trusty?
[13:26] <doko> honestly, that would the right thing to do. but others may disagree ...
[13:28] <jtaylor> adding new 8.5 would be less invasive
[13:28] <jtaylor> *packages
[13:28] <jtaylor> because building is one thing, but actually working is another
[13:28] <jtaylor> and its too much stuff to test
[13:29] <mterry> pitti, how do I retry a failed autopkgtest run from proposed-migration?
[13:31] <pitti> mterry: answering in the distro channel
[13:38] <psusi> pitti: I was wondering if I could pick your brain for a second on udisks.. I'm trying to have it grab the IO counters for the drive and stash them so it can compare it on the next 10 minute poll and skip the smart update if there has been no IO... but I can't find a "regular" struct somewhere to stuff it in.
[13:38] <psusi> it looks like all of the structs are auto generated from xml files and their contents is intended to be exported over dbus
[13:39] <psusi> so how can you store some private data like this, that isn't supposed to go over dbus?
[13:39] <pitti> psusi:
[13:39] <pitti> err, I was about to say "hi!"
[13:39] <pitti> psusi: so you can't put it into one of the private structs like struct _UDisksLinuxDrive?
[13:39] <psusi> hi ;)
[13:40] <psusi> hrm... I didn't see that one, let me go look
[13:41] <psusi> ahh, it's not in a header.. it's defined in udiskslinuxdrive.c
[13:41] <pitti> right, it's a private struct
[13:41] <psusi> hrm... I was looking at adding the code to udiskslinuxdriveata.c, which wouldn't have access to that
[13:41] <pitti> psusi: if you need to access it from someplace else, you need to add some internal API to it, like udisks_linux_drive_{get,set}_whatever
[13:42] <psusi> hrm... maybe I can find a way to add it to udiskslinuxdrive.c instead... I'll look it over some
[13:42] <psusi> thanks for the pointer
[13:42] <pitti> psusi: ah, struct _UDisksLinuxDriveAta then? :-)
[13:42] <pitti> pretty much every class has its private data struct
[13:42]  * psusi facepalms
[13:42] <psusi> it never occured to me that they would be defined in the source instead of the header ;)
[13:43] <pitti> hehe
[13:43] <pitti> psusi: that's the standard GObject approach to ensure it stays private and doesn't leak into any headers or PAI
[13:43] <pitti> API
[13:51] <pitti> mterry: but yes, those "hash sum mismatches" during apt-get are mighty annoying; we get them very often, I don't really know what that means
[13:52] <pitti> mvo: ^
[13:52] <mterry> pitti, :(  I get them occasionally on my own devices, but they go away
[13:52] <pitti> could it be that apt-get starts with downloading Release, then the publisher runs and pushes out new indexes, and apt catches those new ones in the middle of the update run?
[13:52] <pitti> I almost never see them on my workstation
[13:52] <cjwatson> Yes, I believe it's roughly that
[13:53] <pitti> mterry: yes, I just restart these, and it usually works then
[13:53] <mvo> pitti: yeah, its this race condition usually
[13:53] <pitti> cjwatson, mvo: ok, thanks for confirming
[13:54] <mvo> pitti: there was talk about a "by-hash" fetching to avoid this race condition some time ago we are working on some code in the abi-break branch that might help too, if its a problem for you we can make it (more of) a priority
[13:56] <pitti> mvo: well, clicking the retry button 10 times a day isn't a big problem for me personaly
[13:56] <mvo> pitti: well it is
[13:57] <mvo> pitti: i mean, thats a lot
[13:57] <pitti> but it creates these "nice sets of "jenkins failed"/"jenkins fixed" things which hold up promotion a bit and annoy people
[13:57] <mvo> indeed
[13:57] <pitti> I'm quite sure we can work around this in adt-run somehow, too
[13:57] <pitti> or in the machinery above, to auto-retry stuff
[13:57] <pitti> just didn't get to that yet
[13:57] <pitti> mvo: so in essence, it's really far from easy to fix on the apt-get side, so we should fix it in the layer(s) above? (i. e. wait and auto-retry)
[13:58] <mvo> pitti: I think we should give it a shoot on the apt side, its annoying too many people for too long already :/
[13:58]  * mvo puts it on his list
[13:58] <jibel> pitti, we used to auto-retry these jobs, but the regex to detect the retry condition must have changed with the new autopkgtest. Do you have an example, I'll adjust it.
[13:59] <pitti> mvo: I mostly wanted to understand why it happesn -- by the logic above, retrying immediatel actualy shoudl work, right?
[14:00] <mvo> pitti: yes, a retry should fix it. its fetch old-release file, packages and release file gets replaced on the server so new release file, new packages files but apt downloaded the previous one
[14:00] <pitti> jibel: e. g. http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-upower/13/ARCH=i386,label=adt/console
[14:00] <pitti> mvo: ok; I wouldn't want to "sleep 1800" in adt-run, but retrying immediately once in adt-run seems fine to me
[14:00] <pitti> jibel: ^
[14:01] <pitti> jibel: ah, it was in bin/testbed/run-adt
[14:01] <cjwatson> pitti: FWIW I applied a similar workaround in launchpad-buildd a little while back
[14:01] <pitti> cjwatson: ah, with immediate retry?
[14:02] <cjwatson> pitti: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/revision/106?compare_revid=104
[14:02] <pitti> ah, 15 s counts as "immediate", that's fine
[14:02] <cjwatson> pitti: While I agree with mvo that it's a pain to have to work around this everywhere, in practice I don't think I've seen a single problem in LP builds since I applied that
[14:03] <pitti> great
[14:03] <cjwatson> And IIRC your autopkgtest builders are talking to ftpmaster.internal directly?
[14:03] <cjwatson> So should have basically the same constraints
[14:03] <pitti> jibel: so, I think it might be best to just apply a similar workaround to adt-run like http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/revision/106?compare_revid=104
[14:03] <pitti> cjwatson: yes, they are, to ensure we see (by and large) the same archive as britney
[14:03] <cjwatson> Right
[14:04] <cjwatson> Before that I'd had a pretty much daily routine of looking for chrootwait builds
[14:04] <cjwatson> It got more frequent when we made publisher runs much more frequent last summer
[14:05] <pitti> jibel, mterry, mvo: ok, filed as bug 1319416
[14:05] <ubottu> bug 1319416 in autopkgtest (Ubuntu) "Auto-retry on apt-get update failures" [High,Triaged] https://launchpad.net/bugs/1319416
[14:06] <mterry> pitti, ah nice
[14:06] <pitti> jibel: that'll be much cheaper than re-running the whole test (as that means to re-build a VM etc.)
[14:22] <mterry> hallyn, hello!  I'm seeing occasional crashes in cgmanager in Touch when testing my split greeter branches.  But the .crash files don't have usable stacktraces.  Is there a good way to get logs or some such from cgmanager?
[14:24] <labsin> hi, I have a merge proposal for click. But I'd like to first build a package. How can I build the source from the ppa?
[14:27] <mterry> I guess it logs to /var/log/upstart already...  seems to be a double free
[14:27] <mvo> labsin: build the click package? you can just run bzr-buildpackage in the source tree of click
[14:28] <labsin> mvo, I'll try
[14:28] <jtaylor> how would one add a new source package to trusty?
[14:28] <mvo> good luck!
=== rickspencer3_ is now known as rickspencer3
=== JanC is now known as Guest12750
=== JanC_ is now known as JanC
[15:14] <nandersson> Hi, what package does aptd belong to?
[15:14] <ogra_> dpkg -S $(which aptd)
[15:15] <nandersson> ogra_, Thanks!
[15:32] <nandersson> Bug is filed :) https://bugs.launchpad.net/aptdaemon/+bug/1319454
[15:32] <ubottu> Launchpad bug 1319454 in Aptdaemon "Dependencies break when dealing with multiple sources" [Undecided,New]
=== ted is now known as tedg
[16:47] <rbasak> Laney: [flavor name] how about ubuntu-desktop-dev, or ubuntu-desktop-preview?
[16:47] <rbasak> (no response required)
[16:49] <Laney> rbasak: thanks, all suggestions are going into the pot ;)
[17:06] <dobey> can someone *please* accept ubuntuone-client into saucy-proposed?
[17:20] <cjwatson> doko: The problems you ran into with cancelling builds early should be fixed by the launchpad-buildd that's rolling out now
[17:21] <doko> \o/
[17:21] <doko> which reminds me to re-run ruby-moneta locally
[17:26] <hallyn> mterry: that double free is something we've seen very occasionally before, especially from some of stgraber's build machines.  if you can catch it in a debugger that woudl rock.
[17:27] <mterry> hallyn, no luck so far  :(
[17:27] <hallyn> mterry: you'll get more output by adding 'cgmnager_opts=--debug' to /etc/default/cgmanager, but probably not enough to debug it
[17:27] <mterry> hallyn, I set MALLOC_CHECK_=3 which I *think* is supposed to help prevent the stack from dying?
[17:27] <hallyn> mterry: so in your case you didn't have any proxies at all right?
[17:27] <mterry> hallyn, I don't know
[17:27] <hallyn> mterry: cool, hopefully you can track it down, this oens' been bugging me, and i have nto been able to reproduce
[17:27] <mterry> hallyn, can you explain the difference between cgroup, cgmanager, and proxies?
[17:28] <hallyn> mterry: cgmanager allows configuration of cgrousp through a dbus api over a unix socket
[17:28] <hallyn> mterry: cgproxy is a cgmanager proxy which can run in containers, and only forwards requests along to the host's cgmanager
[17:28] <hallyn> (the cgamanger mounts the cgroup filesystems privately;  the proxies don't have to)
[17:29] <mterry> hallyn, I'm debugging some weird race during startup between sessions logging in, registering with logind, and cgmanager.  So I'm a little confused about what is *supposed* to happen vs what is happening sometimes
[17:30] <hallyn> logind should be sending dbus requests to create your cgroup, then chown it, then move you into it, one cgroup at a time
[17:56] <xnox> pitti: i haven't done anything else yet. I've chatted with steve, and the next steps are to introduce back dropped init.d scripts from e.g. initscripts package but in a way that don't change anything under e.g. upstart (if init_is_upstart; exit 0/1 as needed as per current debian policy)
[17:57] <xnox> pitti: after that is done, we should be able to enable insserv & thus drop the guard from dh_installinit and thus start calling update-rc.d for all packages that have init.d scripts.
[17:59] <xnox> wschmidt: infinity: thanks for the emacs24 bug, will look into it.
[18:01] <xnox> pitti: or more complete follow-ups from vorlon on the bug you investigated =)
[18:03] <infinity> xnox: Don't thank me, I just SEPed the bug to you. :P
[18:03] <infinity> xnox: AFAIK, the correct fix is "apt-get --purge install vim emacs24-"
[18:03] <xnox> infinity: SEP stands for... ?
[18:03] <infinity> s/AFAIK/AFAIC/
[18:03] <infinity> xnox: SEP = Somebody Else's Problem.
[18:03] <xnox> infinity: ah, that ok =)
[18:10] <slangasek> xnox: "more complete follow-ups"?  I think I've laid out the necessary steps on this most recent debhelper bug, no?
[19:34] <xnox> slangasek: yeah, that's the one i meant.
[19:34] <slangasek> ack
[20:20] <genii> Is there more current documentation than https://wiki.ubuntu.com/systemd  ?  "Status as at December 2010" doesn't lend much confidence
[20:27] <sladen> genii: done upstream in systemd
=== andreas__ is now known as ahasenack
[20:33] <genii> Hm.
[20:34] <sladen> genii: done upstream in Debian
[20:36] <genii> sladen: I think I found it now, thanks.
[20:37] <xnox> genii: look at history, that page has been edited recently, there is ongoing work in utopic to get systemd support on-par with debian.
[20:38] <xnox> genii: and match the current user-experience & integration that upstart has reached in ubuntu.
[20:38] <genii> There seems to be an older doc with a bit of history: https://wiki.debian.org/Debate/initsystem/systemd   and a current one: https://wiki.debian.org/systemd
[20:38] <xnox> genii: what are you after?
[20:38]  * genii gets ready to read for a while
[20:39] <genii> xnox: Basically how to use it, write startup files for it, etc, and how it compares to sysvinit and upstart
[21:50] <arges> hallyn: if I want to clone and LXC container for another host machine. I assume I copy the rootfs and then do I need to add something else to ensure the container is setup properly?
=== salem_ is now known as _salem