User1: User2 So, when do I get qemu-system-aarch64, now that it's upstream? ;)
User2: User1 ?  why don't you have it yet?
User1: User2 Sorry, I should have specified "with full emulation".
User2: ah
User1: User2 We have kvm-only right now.
User2: yeah
User2: so it depends how badly you want it i guess :)
User1: User2 OMG SO BADLY.
User2: clearly my preference would be to wait until it'sin a release,
User2: but i'll happily do buidl with the patchset if you need it
User1: User2 Nah, I don't *need* it.  Though, if it's undisruptively backportable to 2.0, it would be shiny to have.
User1: User2 (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)
User1: That might actually be a first, given that qemu-system-ppc was pretty broken until just recently too.
User2: speaking of which has openbios-ppc's mir happened yet?
User2: 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)
User1: User2 People emulating sane systems use qemu-slof, not openbios-ppc.
User1: User2 (Though that's also in universe, I think)
User1: Yeah, it is.
User2: actually taht's the one i meant, yeah
User1: We probably should have pulled it into main for trusty and made qemu-system-ppc depend on it, didn't even think about it.
User1: Oops.
User1: Oh well.  That one extra step of "install slof" isn't a world-ending thing to put on a wiki HOWTO or something.
User2: well i'd hoped tha tthe suggests would suffice, but it doesnt' seem to be reducing the # of bugs :(
User2: yeah maybe i should add it to the community docs
User1: User2 Oh, you actually get bugs about it?
User2: yeah, suggesting more ppl are trying out qemu-system-ppc in the last few months than... ever
User1: User2 Yeah, that's actually a positive note, other than the bit where it generates bugs. :P
User1: User2 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.
User1: User2 I'm less fussed about the first group, but we kinda want the second group to work.
User1: User2 And, indeed, if we decide to make trusty a viable host for ppc64el KVM guests, we'll need slof too.
User1: User2 So, we might have to look at a sketchy promotion-to-main-in-updates for that one down the road.
User2: or a fugly in-universe qemu-ppc metapackage that depends on the right things :)
User1: Ick.
User2: :)   half-joking
User1: 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)
User3: User1 when do you think would be a good time to start the libav transition in utopic? https://release.debian.org/transitions/html/libav10.html
User1: User3 yesterday?
User2: is that going back to ffmpeg?
User1: User3 More seriously, check to see if there are any other transitions in progress that you'll heavily overlap with before you start.
User3: User1 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
User2: hm,what're the odds i'll brick my vm byinstalling dh-systemd
User1: User3 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.
User3: I'd certainly help out, but I'm not able to actually drive it
User1: User3 Do you know how much of it will be clean rebuilds, how much needs patches for API changes, etc?
User3: it's going to be pretty bad
User1: User3 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.
User3: there have been a lot of API deprecations and many year-old deprecated functions have been dropped
User4: User2 Pretty much none, it's a dh helper and that's it.
User3: it will also very likely require some removals.
User1: User3 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.
User2: User4 cool, that was my hope
User1: User3 We have people who are pretty good with this sort of thing, but we prefer not to work blind. ;)
User3: User1 you mean such as https://wiki.libav.org/Migration/10 ?
User1: User3 Exactly that, yes.
User3: User1 I've been working on this transition by patching packages since february (no kidding)
User1: User3 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.
User3: User1 that would be awesome.
User3: User1 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
User3: User1 so just let me know when you think it would be a good time to upload it to utopic-proposed
User1: User3 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
User3: absolutely
User3: keep in mind that we do have a couple of extra packages in ubuntu that are not being taken care of in debian
 * infinity nods.
User3: I guess we should just remove the binaries and hope for the best
User3: 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
User3: User1 in any case, thanks for your understanding and assistance!
User1: User3 I'm pretty not happy about the idea of a statically linked mplayer.  Is mplayer really no longer libav-compatible? :/
User1: User3 Does this go back to the age-old libav-vs-ffmpeg debate, and mplayer is primarily an ffmpeg project?
User3: User1 if you are truely bored, see the fight I had with raimar here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159
User5: Debian bug 732159 in ftp.debian.org "RM: mplayer - RoM - unmaintained, RC-buggy, alternatives exist" [Normal,Open]
User3: User1 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.
User1: User3 *sigh*... Is there any chance _at_all_ of a reconciliation between libav and ffmpeg people and a merge of the codebases?
User3: User1 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
User1: :(
User1: Why can't we all just get along? :P
User6: infinity, could you upload https://bugs.launchpad.net/ubuntu/+source/gnome-photos/+bug/1319236 (it should be in our packageset but it isnt ;( )?
User5: Launchpad bug 1319236 in gnome-photos (Ubuntu) "support tracker 1.0" [Undecided,New]
User1: User6 Or, if I can figure out how, I could add it to your packageset.
User6: infinity, that would work too
User1: User6 I'm running to the store with my roommate.  I'll figure out how to fix it when I get back.
User6: infinity, ok and thanks
User1: User6 Oh, maybe I can't edit it anyway.  Weird.  I thought the TB could.  Maybe it's only the DMB.
User1: That's annoying.
User1: User16 Halp.
User1: User6 I give up on doing the right thing.  Just test-building before I sponsor. :P
User6: infinity, ok, I will get the packageset sorted later
User7: doko_: I can take a look. some Qt packages come directly from Debian via autosync, but some have our own changes (and symbols files)
User7: 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)?
User8: User7 WIll do, that was my fault, forgot to do that after having to work on the package outside of UDD.
User9: Good morning
User7: User8 thanks!
User8: np
User9: doko_: btw, bzr-builddeb's test is fixed in debian, just waiting for LP to import it and sync
User9: (one of the two remaining things that hold back python-default)
User10: User9 Would you like to upload colord to experimental at your leisure?
User9: User10 sure
User10: While I'm waiting on a transition slot.
User9: User10 do you want to dch -r/debcommit -r or want me to?
User10: User9 Done so.
User9: User10 hm, were you missing git push --all? pristine-tar/upstream seems outdated
User10: User9 Quite possibly; now done.
User9: User10 ah, all there now; building
User11: good morning
User9: User10 aaaand uploaded
User12: hey dholbach
User11: hey mv
User11: hey mvo
User9: mvo, User11 guten Morgen!
User12: hey pitti, good monring
User11: hey pitti
User11: na Jungs, wie lÃ¤uft's?
User10: User9 Danke
User13: 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.
User13: so, it is not related to apt or packaging, but PackageKit rather :-/
User14: xnox, are you able to reproduce the unity issue with pch? if yes, a stacktrace of cc1plus would be nice
User6: Laney, a while ago I asked (on devel-permissions list) for gnome-photos to get add to our packageset, did you miss that one?
User15: User6 maybe
User16: stgraber@castiana:~/data/code/ubuntu-archive/ubuntu-archive-tools$ ./edit-acl add -P ubuntugnome -s gnome-photos -S utopic
User16: Added:
User16: gnome-photos
User16: User1 ^
User15: why infinity?
User15: also, I was checking if it was seeded and it's not
User15: â desktop-extra
User6: stgraber, Laney, yes it should have gone into desktop-extra!
User15: unless you do plan on seeding it in which case it might not be worth the effort to change :-)
User6: Laney, probably not this cycle, its not quite feature complete yet
User16: User15 I'll move it. I guessed ubuntugnome based on the earlier discussion with infinity but I apparently guessed wrong ;)
User15: ah I didn't see any earlier one
User15: I think desktop-extra is for the random gnome-y additional bits and ubuntugnome itself for the image
User16: done
User15: ty
User15: btw, we should make some time at $sprint to look at fixing that script if possible
User15: as it's clear that I'm failing to do it on my own
User16: User15 yeah, we can do that
User16: User15 I'll add an item for that to the foundations malta agenda so I remember :)
User15: great
User15: put my name or something so that I can legitimately go away for a bit :P
User16: User15 "fix the packageset/seed generator (stgraber, Lantey) "
User16: *Laney
 * Laney nod
User6: stgraber, thanks!
User15: User6 btw codesearch should be back
User15: well, as back as it ever was
User6: Laney, great!
User17: hm can someone put mesa in utopic? seems to fail on an unrelated autopkgtest, probably because of gnat
User9: right, the ada stack is broken in utopic-proposed (and debian unstable), so libgtkada can't work
User9: User17 the release team can override the failure
User17: ok
User17: is this enough of a ping or should I ask in #ubuntu-release?
User18: tjaalton sort of asked earlier
User9: User15 ^ ?
User18: well, he asked what was the issue, not to override
User18: but overriding it seems fine to me
User17: ah goodie :)
User9: yes, to me too
User15: will look in a min
User9: User11 we changed the time of the tech board meeting; how can I get http://fridge.ubuntu.com/calendars/ updated?
User11: pitti, https://wiki.ubuntu.com/Fridge/Calendar
User9: User11 right, I found that, but it doesn't link to a particular google cal, or say how I can update an existing event?
User11: pitti, for the event you're looking at, can you see who created it?
User9: ooh, I can click on it on fridge.u.c.
User9: https://www.google.com/calendar/render?eid=MXFwcnZuZW5lbWlraDU0ajY0MmhmbGU4NjhfMjAxNDA0MjhUMjAwMDAwWiBqNXE4NW1taTZ1anZqdGlpNXMxbjNsaTVpb0Bn&ctz=Etc/GMT&sf=true&output=xml
User9: User11 mdz apparently
User9: User11 so, I'll ask him to update that
User11: pitti, I pinged pleia2 and jose - maybe they have fridge calendar super powers
User11: I have no idea, sorry
User9: User11 ack, thanks
User19: is there anything we can do about the incomplete tcl/tk transition in trusty?
User19: like finishing it up post release or adding new source packages?
User19: e.g. blt is linked against 8.6 and itcl3 still against 8.5, use them together and boom
User19: (both libraries so they affect a fair share of applications)
User19: User1 you ported blt to 8.6, we still need a 8.5 blt for e.g. skycat
User19: as the shared library is luckily versioned I would suggest adding a new source package blt8.5 to trusty which builds against 8.5
User14: jtaylor, can't we just link itcl3 with 8.6?
User19: User14 yes but then we have to change a whole stack of applications too
User20: User19 thanks for digging into this. Can I suggest a dep8 test too? This would catch the same issue next time I think, right?
User14: jtaylor, how many?
User19: User14 direct dependencies about 9
User19: but some of them look like bases of other stuff
User19: like plplot
User19: some apache stuff even
User14: ugh, ugly package anyway
User19: User20 well looking at build logs would have been enough in this case already :)
User14: so can we build these in utopic first using 8.6 and then decide what to do?
User19: one could try
User19: I tried buildint itcl3 against 8.6 but still didn't get it to work
User19: don't know why yet
User19: building blt against 8.5 worked
User19: I may have forgotten some other library thats still linked against 8.5
User19: assuming we get utopic to work with 8.6 only, can the fixes be all SRU'd to trusty?
User14: honestly, that would the right thing to do. but others may disagree ...
User19: adding new 8.5 would be less invasive
User19: *packages
User19: because building is one thing, but actually working is another
User19: and its too much stuff to test
User21: pitti, how do I retry a failed autopkgtest run from proposed-migration?
User9: User21 answering in the distro channel
User22: User9 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.
User22: it looks like all of the structs are auto generated from xml files and their contents is intended to be exported over dbus
User22: so how can you store some private data like this, that isn't supposed to go over dbus?
User9: User22
User9: err, I was about to say "hi!"
User9: User22 so you can't put it into one of the private structs like struct _UDisksLinuxDrive?
User22: hi ;)
User22: hrm... I didn't see that one, let me go look
User22: ahh, it's not in a header.. it's defined in udiskslinuxdrive.c
User9: right, it's a private struct
User22: hrm... I was looking at adding the code to udiskslinuxdriveata.c, which wouldn't have access to that
User9: User22 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
User22: hrm... maybe I can find a way to add it to udiskslinuxdrive.c instead... I'll look it over some
User22: thanks for the pointer
User9: User22 ah, struct _UDisksLinuxDriveAta then? :-)
User9: pretty much every class has its private data struct
 * psusi facepalms
User22: it never occured to me that they would be defined in the source instead of the header ;)
User9: hehe
User9: User22 that's the standard GObject approach to ensure it stays private and doesn't leak into any headers or PAI
User9: API
User9: User21 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
User9: User12 ^
User21: pitti, :(  I get them occasionally on my own devices, but they go away
User9: 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?
User9: I almost never see them on my workstation
User23: Yes, I believe it's roughly that
User9: User21 yes, I just restart these, and it usually works then
User12: User9 yeah, its this race condition usually
User9: cjwatson, User12 ok, thanks for confirming
User12: User9 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
User9: User12 well, clicking the retry button 10 times a day isn't a big problem for me personaly
User12: User9 well it is
User12: User9 i mean, thats a lot
User9: but it creates these "nice sets of "jenkins failed"/"jenkins fixed" things which hold up promotion a bit and annoy people
User12: indeed
User9: I'm quite sure we can work around this in adt-run somehow, too
User9: or in the machinery above, to auto-retry stuff
User9: just didn't get to that yet
User9: User12 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)
User12: User9 I think we should give it a shoot on the apt side, its annoying too many people for too long already :/
 * mvo puts it on his list
User24: 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.
User9: User12 I mostly wanted to understand why it happesn -- by the logic above, retrying immediatel actualy shoudl work, right?
User12: User9 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
User9: User24 e. g. http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-upower/13/ARCH=i386,label=adt/console
User9: User12 ok; I wouldn't want to "sleep 1800" in adt-run, but retrying immediately once in adt-run seems fine to me
User9: User24 ^
User9: User24 ah, it was in bin/testbed/run-adt
User23: User9 FWIW I applied a similar workaround in launchpad-buildd a little while back
User9: User23 ah, with immediate retry?
User23: User9 http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/revision/106?compare_revid=104
User9: ah, 15 s counts as "immediate", that's fine
User23: User9 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
User9: great
User23: And IIRC your autopkgtest builders are talking to ftpmaster.internal directly?
User23: So should have basically the same constraints
User9: User24 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
User9: User23 yes, they are, to ensure we see (by and large) the same archive as britney
User23: Right
User23: Before that I'd had a pretty much daily routine of looking for chrootwait builds
User23: It got more frequent when we made publisher runs much more frequent last summer
User9: jibel, mterry, User12 ok, filed as bug 1319416
User5: bug 1319416 in autopkgtest (Ubuntu) "Auto-retry on apt-get update failures" [High,Triaged] https://launchpad.net/bugs/1319416
User21: pitti, ah nice
User9: User24 that'll be much cheaper than re-running the whole test (as that means to re-build a VM etc.)
User21: 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?
User25: 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?
User21: I guess it logs to /var/log/upstart already...  seems to be a double free
User12: User25 build the click package? you can just run bzr-buildpackage in the source tree of click
User25: mvo, I'll try
User19: how would one add a new source package to trusty?
User12: good luck!
User13: Hi, what package does aptd belong to?
User26: dpkg -S $(which aptd)
User13: ogra_, Thanks!
User13: Bug is filed :) https://bugs.launchpad.net/aptdaemon/+bug/1319454
User5: Launchpad bug 1319454 in Aptdaemon "Dependencies break when dealing with multiple sources" [Undecided,New]
User20: User15 [flavor name] how about ubuntu-desktop-dev, or ubuntu-desktop-preview?
User20: (no response required)
User15: User20 thanks, all suggestions are going into the pot ;)
User27: can someone *please* accept ubuntuone-client into saucy-proposed?
User23: User14 The problems you ran into with cancelling builds early should be fixed by the launchpad-buildd that's rolling out now
User14: \o/
User14: which reminds me to re-run ruby-moneta locally
User2: User21 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.
User21: hallyn, no luck so far  :(
User2: User21 you'll get more output by adding 'cgmnager_opts=--debug' to /etc/default/cgmanager, but probably not enough to debug it
User21: hallyn, I set MALLOC_CHECK_=3 which I *think* is supposed to help prevent the stack from dying?
User2: User21 so in your case you didn't have any proxies at all right?
User21: hallyn, I don't know
User2: User21 cool, hopefully you can track it down, this oens' been bugging me, and i have nto been able to reproduce
User21: hallyn, can you explain the difference between cgroup, cgmanager, and proxies?
User2: User21 cgmanager allows configuration of cgrousp through a dbus api over a unix socket
User2: User21 cgproxy is a cgmanager proxy which can run in containers, and only forwards requests along to the host's cgmanager
User2: (the cgamanger mounts the cgroup filesystems privately;  the proxies don't have to)
User21: 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
User2: logind should be sending dbus requests to create your cgroup, then chown it, then move you into it, one cgroup at a time
User28: User9 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)
User28: User9 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.
User28: wschmidt: User1 thanks for the emacs24 bug, will look into it.
User28: User9 or more complete follow-ups from vorlon on the bug you investigated =)
User1: User28 Don't thank me, I just SEPed the bug to you. :P
User1: User28 AFAIK, the correct fix is "apt-get --purge install vim emacs24-"
User28: User1 SEP stands for... ?
User1: s/AFAIK/AFAIC/
User1: User28 SEP = Somebody Else's Problem.
User28: User1 ah, that ok =)
User29: User28 "more complete follow-ups"?  I think I've laid out the necessary steps on this most recent debhelper bug, no?
User28: User29 yeah, that's the one i meant.
User29: ack
User30: Is there more current documentation than https://wiki.ubuntu.com/systemd  ?  "Status as at December 2010" doesn't lend much confidence
User31: User30 done upstream in systemd
User30: Hm.
User31: User30 done upstream in Debian
User30: User31 I think I found it now, thanks.
User28: User30 look at history, that page has been edited recently, there is ongoing work in utopic to get systemd support on-par with debian.
User28: User30 and match the current user-experience & integration that upstart has reached in ubuntu.
User30: 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
User28: User30 what are you after?
 * genii gets ready to read for a while
User30: User28 Basically how to use it, write startup files for it, etc, and how it compares to sysvinit and upstart
User32: User2 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?
ubuntu-devel
Ubuntu IRC