[04:49] <pitti> Good morning
[06:01] <pitti> infinity: is there some amount of merges you would trade against taking initramfs-tools from me?
[06:03] <pitti> infinity: hm, it seems texinfo, apr, and vim are all comparatively simple
[07:05] <dholbach> good morning
[07:08] <dholbach> @pilot in
[07:24] <dholbach> cyphermox, what do you think about https://code.launchpad.net/~jbicha/ubuntu/saucy/network-manager/depend-on-valac/+merge/166626?
[07:25] <dholbach> to me it seems to be a bit of a matter of preference - I'll leave it up to you :)
[08:13] <infinity> pitti: Oh, I'll take initramfs-tools back anyway, since I'm upstream.  My bad for forgetting about it.
[08:14] <pitti> infinity: thanks; I'm happy to take off texinfo and apr from you anyway if you want
[08:15] <infinity> pitti: I have no great love for texinfo.  I should probably keep apr until I figure out a cleaner way to make crossing happy upstream.
[08:15] <infinity> pitti: Oh, actually, my texinfo cross hacks are vile too.  I should probably keep that and sort out something less disgusting.
[08:16] <infinity> pitti: I forgot that was the package I did *that* to.
[08:16]  * infinity finds his lunch returning upon re-reading that diff.
[08:17] <geser> sounds like forgetting as a good idea in this case :)
[08:36] <dholbach> Mirv, so I merged your touch merge proposal for ubuntu-seeds - are you going to upload another -meta?
[08:37] <dholbach> Mirv, there's a bunch of changes since the last time - does http://paste.ubuntu.com/5731925/ look all right to you?
[08:37] <dholbach> Mirv, I can put your email address into it if you like ;-)
[08:40] <Laney> you might want to check with ogra
[08:40] <Laney> "Removed powerd" seems suspicious
[08:40] <Laney> but maybe that's pulled in another way
[08:40] <ogra> erm, the touch seeds are special
[08:41] <dholbach> ogra, ok, so I just merged https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.add-qt-accounts-friends-plugins/+merge/166223 and did nothing else
[08:41] <Mirv> dholbach: thanks! looks good for the sdk related changes, although I can't do the uploads.
[08:41] <dholbach> I'll leave the rest to you then
[08:41] <ogra> you need to manually hack them until things are in the archives, germinate cant use PPAs
[08:41] <dholbach> aha
[08:41] <dholbach> nevermind then
[08:41] <cjwatson> mm, been meaning to figure that out ...
[08:41] <ogra> i'll take care later
[08:41] <dholbach> thanks ogra!
[08:41] <Mirv> (I haven't done any touch meta related changes)
[08:41] <ogra> cjwatson, nah, we better get that stuff into the archive
[08:42] <cjwatson> Well, sure, but I consider it a germinate bug anyway
[08:42] <cjwatson> Probably
[08:47] <infinity> germinate can't use PPAs?
[08:47] <infinity> Can't you just feed it another -m?
[08:48] <infinity> I would think that should Just Work.
[08:52] <cjwatson> Well, this is germinate-update-metapackage, so it all needs to go in update.cfg.  But apparently shoving in more archives didn't do the trick, and I haven't had a chance to investigate yet.
[08:53] <infinity> Yeah, I was just following that code now to see how or why that's more special than a by-hand invocation.
[08:53] <cjwatson> It does even go and fetch the relevant Packages files
[09:27]  * cjwatson attacks germinate-update-metapackage with pdb
[09:38] <cjwatson> ogra: So, wait.  Now that I've actually updated my seed checkout, I don't see anything wrong with germinate-update-metapackage's output.  What parts of http://paste.ubuntu.com/5732062/ do you think are wrong?
[09:39] <ogra> cjwatson, looks like it removed everything under the debug section ... weird
[09:39] <ogra> and powerd
[09:39] <ogra> though i'm not sure it is seeded
[09:39]  * ogra looks
[09:40] <cjwatson> ogra: "debug section"?
[09:40] <ogra> in the touch seed
[09:40] <cjwatson> ogra: It only removed powerd on i386
[09:40] <cjwatson> Where, I'm guessing, it doesn't exist
[09:40] <ogra> ah, that might be
[09:40] <cjwatson> ogra: All the entries in the debug section are duplicated from ubuntu-minimal
[09:40] <ogra> iputils-ping
[09:40] <ogra> from the debug section
[09:41] <ogra> oh
[09:41] <ogra> sorry, typed to fast
[09:41] <cjwatson> ogra: Your STRUCTURE file says "touch: minimal", so germinate intentionally prunes those
[09:41] <ogra> well, then it looks perfect
[09:41] <cjwatson> ogra: And, indeed, your livecd-rootfs config installs ubuntu-minimal as well, so they are indeed redundant
[09:41] <ogra> yeah
[09:42] <ogra> thats how it is supposed to be
[09:42] <ogra> i'll drop it from the seed
[09:42] <cjwatson> OK, I'll double-check powerd and if that's right then I'll upload
[09:43] <ogra> yeah, i think it is intentionally not built for x86 yet
[09:43] <ogra> iirc it wants to talk to android devices
[09:44] <cjwatson> Indeed, https://launchpad.net/%7Ephablet-team/+archive/ppa/+sourcepub/3241512/+listing-archive-extra concurs
[09:46] <cjwatson> That was against 1.009, BTW, so a bit laggy.  I'll update against 1.015
[09:58] <dholbach> @pilot out
[09:59] <dholbach> (I'll do the rest of my shift tomorrow. Got to take care of some other bits first.)
[10:15] <cjwatson> ogra: OK, uploaded ubuntu-touch-meta.  Could you use the ./update script for future changes?
[10:15] <ogra> cjwatson, with pleasure !
[10:15] <ogra> thanks a lot !
[10:15] <cjwatson> np.  didn't really do much other than observing it worked :-)
[12:23]  * cjwatson holds his breath and uploads a debhelper merge
[12:23] <cjwatson> Let me know if you notice any resulting weirdness
[12:35] <jibel> pitti, is there any limitation to upgrade udev/systemd in an lxc container ? upgrade from 202-0ubuntu12 to 204-0ubuntu1 hangs on configure
[12:38] <pitti> jibel: not known to me at least; can you please file a bug?
[12:39] <pitti> jibel: I tested the upgrade on a normal system, which went fine
[12:39] <jibel> pitti, sure, it's is blocked on "stop udev"
[12:39] <pitti> jibel: I guess I should be reproducible in otto? :-)
[12:40] <pitti> jibel: oh, it's the *old* udev which fails to stop?
[12:40] <jibel> pitti, yes, that's the problem :) I was provisioning a fresh saucy
[12:40] <pitti> postinst does "invoke-rc.d udev restart", that shoudl call "stop udev"
[13:10] <jibel> pitti, bug 1187375
[13:15] <pitti> jibel: thanks; I'll stop my "fix autopkgtest" vendetta now and look at this
[13:17] <jibel> pitti, thanks!
[13:25] <Riddell> stgraber: anything I should look out for in this user upstart kde-plasma session?  seems to work fine
[13:32] <stgraber> Riddell: with unity we had some problems around accessibility, input methods and some environment variables being missing. That last one should be fine for KDE as it's using a single upstart job and so that problem shouldn't be possible. Input methods and accessibility are probably worth checking though.
[13:40] <Riddell> gpg: problem with the agent - disabling agent use
[13:40] <Riddell> stgraber: might that be caused by it?
[13:40] <Riddell> ^^
[13:41] <pitti> jibel: indeed, booting today's iso in otto, "sudo stop udev" works, but "sudo start udev" hangs (that's with 202 only, no upgrade)
[13:44] <stgraber> Riddell: maybe, though we do ship a gpg-agent.conf upstart job that should avoid that. Does KDE ship its own gpg agent (similar to gnome-keyring in gnome)?
[13:46] <stgraber> Riddell: either way, "initctl status gpg-agent" and "env | grep GPG" may help figuring out what's going on there
[13:47] <stgraber> Riddell: oh, and "grep use-agent ~/.gnupg/gpg.conf" too
[13:47] <Riddell> >initctl status gpg-agent
[13:47] <Riddell> gpg-agent start/running
[13:47] <Riddell> GPG_AGENT_INFO=/tmp/gpg-cTlh4g/S.gpg-agent:24776:1
[13:48] <Riddell> use-agent is set in my ~/.gnupg/options
[13:48] <Riddell> and I have pinentry-qt4 installed
[13:48] <pitti> jibel: hm, I can manually stop and start udevd just fine, just the upstart command hangs; I wonder if it's somehow interfering with the host system
[13:50] <pitti> and ^Cing it and re-tryign "start udev" causes upstart to lie "job has already been started", although udevd isn't running
[13:52] <jibel> pitti, but upgrade from ubuntu11 to ubuntu12 went just fine on the same system. Shouldn't it have been affected as well is it was something with the host?
[14:09] <stgraber> Riddell: what do you get if you run "gpg-connect-agent"?
[14:11] <Riddell> stgraber: a > prompt character
[14:20] <stgraber> Riddell: ok, so it managed to connect to the agent...
[14:20] <stgraber> Riddell: that suggests the agent is running as expected, not sure what that error message is about then...
[14:21] <ogra> hmm, no infinity in #ubuntu-touch ... so i'll ask here ...
[14:21] <ogra> infinity, we need to find some way to exclude the /etc/init.d/ondemand script on ubuntu-touch
[14:22] <infinity> ogra: Why?
[14:22] <ogra> cpu frequency stuff is full in the hands of the android side
[14:22] <ogra> and my phone starts to glow after the script forced ondemand here
[14:23] <ogra> i was wondering if we could move it to its own package and just make it a recommends
[14:23] <infinity> interactive, surely.
[14:23] <infinity> If it's an Android kernel.
[14:23] <infinity> And all we're doing it poking some /proc bits, which I assume Android is setting similarly.
[14:23] <infinity> Can you see what all those bits are set to before ondemand runs?
[14:25] <infinity> ogra: Just how much Android userspace are we running, anyway?  And why don't we pare it down more?
[14:27] <pitti> jodh, xnox: if "sudo start udev" just hangs (in lxc), there is no udevd process, no log in /var/log/upstart, but I can manually start udevd just fine, how would I go to debug that?
[14:27] <ogra> well, over the years we might be able to pull over HW configs for each and every ubunt-touch port ... just not yet i guess
[14:28] <ogra> doing this part relibable in the same way android does it will be hard
[14:28] <ogra> and the android settings should usually get us the best setup for power saving
[14:28] <infinity> ogra: Eh?  What does this have to do with hardware configs?  If there's a frequency-twiddly daemon running, stop that.  Setting interactive should work fine.
[14:28] <jodh> pitti: looks like udevd has a --debug option - you could try adding that to /etc/init/udev.conf to see if you get any output.
[14:29] <infinity> ogra: Assuming the Android setup is what we want is probably not true.  Our userspaces are wildly different.
[14:29] <pitti> jodh, xnox: oh, of course -- just after I asked i got it
[14:30] <pitti> jodh, xnox: there was a "start on starting udev" job which failed; where would/should I have seen that?
[14:30] <pitti> jibel: ^ we need to auto-destruct or fix /etc/init/lxc-udev.conf :)
[14:30] <ogra> infinity, right, and currently our userspace doesnt have anything HW related at all we talk to HW through the platform-api
[14:31] <jodh> pitti: boot with --debug or "initctl log-priority debug" and check dmesg/syslog, or look at the /var/log/upstart/ log if the failing job produced any output.
[14:31] <pitti> jodh: there was no /var/log/upstart/udev.log; I guess it didn't even get to that yet, as it tried the depending lxc-udev.conf first
[14:31] <pitti> jodh: ah, thanks for "log-priority debug"
[14:33] <infinity> ogra: Yes, but we don't need to "talk" to anything WRT frequency scaling.  It's set-and-forget in the kernel, unless there's a daemon running that does weird things.
[14:33] <infinity> ogra: And if there is, I don't see how we're getting in its way.
[14:34] <ogra> no, it isnt ... that was long ago
[14:34] <ogra> with interactive governors the user actions are monitored all the time
[14:34] <infinity> By the kernel.
[14:34] <infinity> Hence my "set and forget" comment.
[14:35] <infinity> This is true of all governors except powersave and performance.
[14:35] <ogra> well, the interactive governor on the nx4 has like 20 settings or so
[14:35] <ogra> and they differ for every exynos
[14:36] <ogra> s/exynos/exynos device/
[14:36] <infinity> ogra: Instead of trying to outsmart the kernel and set fiddly bits (like you did in the upload after mine), you could just let the defaults get used.
[14:37] <ogra> not with ubuntu-touch ... the defaults are set from androids init
[14:37] <ogra> so we need to leave it to the container to set them up
[14:37] <ogra> and not force ondemand
[14:38] <infinity> We don't force ondemand.
[14:38] <jibel> pitti, Oh, I see the problem. I'll create an override on first run. Why does it fail now and in previous upgrade?
[14:38] <jibel> pitti, thanks for finding this
[14:38] <infinity> ogra: What order do these scripts get run in?  Ours first, then Android's, or the inverse?
[14:39] <infinity> ogra: And what do the settings look like when Android's done with it?
[14:39] <pitti> jibel: I'm working on a fix
[14:40] <infinity> ogra: I contend that if we remove all those little hacks and tweaks from your 2.88dsf-13.10ubuntu15 upload, it'll all work fine.
[14:40] <pitti> jodh: hm, I did the initctl log-priority, but I still don't see anything at all in dmesg and /var/log/syslog when I do "sudo start udev"
[14:40] <infinity> ogra: Cause if Android's setting up tweaks, and all we're doing is setting it to interactive, everyone wins.
[14:40] <jodh> pitti: did you "sudo initctl log-priority"? If not, you'll just have changed the log priority for your session init if this is saucy ;)
[14:40] <ogra> infinity, we force ondemand if we do find it
[14:41] <ogra> (and the system uses one of its own governors nobody knows about ... like on three of my foud devices here)(
[14:41] <ogra> *four
[14:41] <infinity> ogra: No, we force ondemand if we *don't* have interactive.
[14:41] <ogra> yes
[14:42] <infinity> ogra: So, what are these other governors?
[14:42] <pitti> jodh: yes, it's today's saucy image, and I ran it with sudo
[14:42] <ogra> inevnted by the vendors
[14:42] <infinity> ogra: Their names. :P
[14:42]  * ogra doesnt have the names here 
[14:42] <ogra> not std kernel ones
[14:43] <infinity> ogra: Sure, interactive isn't standard either.
[14:43] <ogra> hmm, i thought it was since a while
[14:43] <ogra> on arm at least
[14:43] <infinity> No, it's Android-specific.
[14:43] <jodh> pitti: confused then. try starting/stopping another job and seeing if you get output. Presumably "logger foo" does the expected on that system?
[14:44] <ogra> well, in any case, android will set them on container start
[14:44] <pitti> jodh: sudo stop/start whoopsie also doesn't log anything; logger foo works
[14:45] <pitti> jodh: might be because that's inside a container?
[14:45] <infinity> ogra: Sure.  So, we can make our script just exit silently if it finds any of these other fancy governors.
[14:45] <ogra> so we are setting them twice ... with the non flipped container pretty harmfulk *after* android comes up ... with the flipped one we just have a redundant call before the android container sets it again
[14:45] <jodh> pitti: maybe rsyslog isn't running?
[14:45] <jodh> pitti: unsure - stgraber?
[14:45] <infinity> ogra: And I'm not sure flipping matters, given that the init script sleeps for 60s, it's probably always run last.
[14:45] <ogra> infinity, i would at least make it fail if it finds the android upstart job
[14:46] <ogra> oh, right
[14:46] <pitti> jodh: it is running, I get log messages from other stuff just fine (e. g. dbus tells me spawned services)
[14:46] <ogra> still redundant though
[14:46] <infinity> ogra: What's this Android upstart job?  We can certainly just exit 0 if that exists.
[14:47] <ogra> lxc-android-container.conf
[14:47] <jodh> pitti: hmm - I'm actually getting the expected output to the console on my raring lxc container. Maybe boot with 'lxc-start -L /tmp/console.log' or similar?
[14:47] <ogra> if it wouldnt be a sysvinit script that would be easier :)
[14:48] <pitti> ls -l /var/lib/lxc/
[14:48] <pitti> argh
[14:49] <pitti> jodh: anyway, I have a job "start on starting udev and started mounted-run" "task" "script" "true" "end script" (i. e. doing nothing); that completely blocks "start udev"
[14:49] <infinity> ogra: Out of curiosity, where did all these interactive tweaks come from?
[14:50] <ogra> infinity, the ones we ship atm ?
[14:50] <ogra> androids nexus7 init scripts
[14:50] <pitti> jodh: I guess it doesn't consider lxc-udev (that job) as started (status lxc-udev says "unknown job"), so I guess that wait condition is busted somehow?
[14:50] <infinity> ogra: Ahh.  Kay.  I'll just tear them out, I think, since I can't imagine they're ideal for any interactive-using device, and kernel defaults seemed good enough.
[14:51] <ogra> infinity, loading interactive with its defaults made the device crawl
[14:51] <ogra> yeah, tear themm out
[14:51] <ogra> nexus7 desktop is done
[14:51] <infinity> ogra: That's the opposite of the reports I got from others when I enabled it...
[14:51] <ogra> the load was constantly around 2.x
[14:51] <ogra> with interactive properly configured it was normal
[14:52] <ogra> feel free to try it if you still have an nx7 desktop around :)
[14:52] <infinity> I don't.
[14:52] <ogra> it was a quite noticeable difference
[14:52] <ogra> (like switching from beagle to panda)
[14:55] <jodh> pitti: suggests the mounted-run job isn't running which will indeed block any follow-on jobs. Try booting with "lxc-start -L /tmp/console.log -- /sbin/init --debug" and looking in /tmp/console.log for the mounted-run job.
[14:55] <jodh> pitti: you could also create a job that specifies "start on mounted\n exec env \n", boot and check the log again to see which mounted events you are actually getting.
[14:55] <pitti> jibel: ^ can I pass this option to lxc-start from otto start?
[14:56] <pitti> jodh: right, mounted-run is a signal, not a job
[14:56] <pitti> jodh: it'll only happen on boot AFAIK (it works there, i. e. during bootup udev is getting started just fine)
[14:56] <pitti> jodh: ok, I'll probably just redesign that job to disable itself
[14:57] <jodh> pitti: mounted-run is a job.
[14:57] <jibel> pitti, if it is supported by the python binding yes
[14:58] <infinity> ogra: http://paste.ubuntu.com/5732832/ <-- Verify that path is right?
[14:59] <ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
[15:00] <infinity> 08:47 < ogra> lxc-android-container.conf
[15:00] <infinity> 08:59 < ogra> infinity, wrong ... /etc/init/lxc-android-config.conf
[15:00] <infinity> This is what I get for trusting people. ;)
[15:00] <ogra> haha, sorry
[15:01] <pitti> jodh: ah, close enough; it's a task, i. e. it's usually stopped
[15:01] <infinity> ogra: Uploaded with that correction.
[15:01] <pitti> jibel: I have the upstart job create an .override file now, but that's broken if we keep deltas -- you can't ever boot this container twice then
[15:02] <pitti> jibel: so I'd rather not use anythign file system based, except /run
[15:02] <pitti> do we have a /run/init/ for jobs?
[15:03] <ogra> infinity, thx !
[15:03] <pitti> jibel: ah, easier I think: udev starts on "virtual-filesystems", which sounds like including /run; so I don't think we need to repeat that condition in lxc-udev; I'll just drop it
[15:03] <xnox> pitti: i don't think we do. but we could add it, e.g. upstart does support multiple locations in priority order correctly.
[15:04] <xnox> (as used in user sessions for example)
[15:04] <stgraber> xnox: didn't we explicitly decide not to support this in system mode?
[15:04] <pitti> jibel: ok, that works fine
[15:04] <jibel> pitti, otherwise we could delete the override in the pre-mount
[15:04] <jibel> pitti, ok
[15:04] <pitti> stgraber: it would be similar to /run/udev/rules.d/
[15:05] <xnox> stgraber: correct. but it wouldn't be hard to enable.
[15:06] <stgraber> xnox: sure, it's just that in a recent MP we agreed this would likely be confusing and cause some weirdness if one of the paths doesn't exist. That's why jodh made a change to allow the option be passed multiple times but discard all but the last instance (and added matching tests to ensure that doesn't change)
[15:10] <xnox> stgraber: thinking about it yeah... it might be weird. does mountall mount /run or is it mounted in initramfs?! it would be confusing not to have conf-source on boot, as we might fail to start tracking it with inotify.
[15:10] <xnox> and initctl reload-configuration would be needed.
[15:11] <stgraber> xnox: /run is usually mounted by the initramfs, so that's fine (so long as you have one), but we'd still hit that kind of problem if you were to pass a /var directory or something under /usr
[15:11] <xnox> sure.
[15:12] <cjwatson> ah, phablet-flash is still looking at ubuntu-touch-preview - if I want to try the ubuntu-touch (saucy) images do I need to do that by hand somehow?
[15:15] <xnox> cjwatson: yes. https://wiki.ubuntu.com/Touch/Install#Manual_Installation
[15:15] <xnox> using the matching/correct saucy files. push first one, reboot into recovery, push second one, reboot into recovery again and you should be good to go.
[15:16] <cjwatson> k, thanks
[15:17] <cjwatson> I got my hopes up when I saw stuff in the changelog about pulling from cdimage, but of course that was ubuntu-touch-preview
[15:21] <pitti> jibel: hm, seems we need the "mounted-run" after all, so I don't commit my changes
[15:21] <pitti> jibel: so we need to remove the override in the pre-mount script
[15:21] <pitti> jibel: I'll commit that
[15:22] <pitti> jibel: (done)
[15:25] <jibel> pitti, many thanks, I'll do a run with the fix.
[15:39] <pitti> slangasek: err -- how come that I was just about to do a test build/upload of binutils to fix exactly the same issue that you did 5 mins ago? :-)
[15:39] <pitti> slangasek: thanks
[15:42]  * pitti goes on to the next one
[15:47] <pitti> slangasek: do we still need the "Breaks: libiodbc2" in odbcinst1debian2 (from bug 901638)?
[15:48] <pitti> slangasek: I'm looking at the psqlodbc autopkgtest which doesn't work in ubuntu as one cannot install its dependencies due to that
[15:48] <Laney> xnox: are those saucy images supposed to work currently?
[15:48] <Laney> I just pushed them and I got into a reboot loop
[15:50] <xnox> Laney: I had more success upgrading and/or using the custom saucy image from someone's blog post.
[15:50] <Laney> I think I'll go back to the normal ones for now
[15:50]  * Laney fablet-phlash
[15:50] <pitti> slangasek: it was an upgrade fix to precise, but I'm not sure whether it still makes sense semantically
[15:52] <Laney> wait, might have pushed the wrong thing the second time
[16:03] <ev> bdrung: hi. Are you still unable to access errors.ubuntu.com?
[16:04] <ev> we've had another report of this today via dpm, so this could be a bug
[16:04] <pitti> barry: hey, how are you?
[16:05] <barry> pitti: hi!  good, and you?
[16:05] <pitti> barry: are you interested in fixing oneconf's autopkgtest? it outputs a lot to stderr (which could be a redirection), but several tests fail, too
[16:05] <pitti> barry: I'm fine, thanks!
[16:06] <barry> pitti: i could take a crack at it, but it probably won't be today.  is there a bug open on it?
[16:06] <pitti> barry: I can open one if it helps for scheduling/reminding
[16:06] <barry> pitti: it definitely would :)
[16:07] <pitti> barry: nah, doesn't need to be today, I'm just trawling through our stack of failures, fixing some (mostly the debian imports), and nagging some people to fix "theirs"
[16:07] <pitti> barry: cheers, will do
[16:07] <barry> pitti: sounds good
[16:10] <infinity> pitti: Does eglibc still fail?  I haven't looked in a while.
[16:10] <infinity> pitti: Interestingly, after we went and blamed qemu/kvm, eglibc passed its testsuite with flying colors on the new kvm openstack buildds.
[16:10] <infinity> pitti: And it's not the raring/saucy kernels, cause that's what I test on at home.
[16:10] <pitti> infinity: hah, good to hear
[16:10] <infinity> pitti: So, if it's still broken, I'm a bit stumped.
[16:11] <pitti> barry: filed bug 1187460 with all links and an excerpt of the failures
[16:11] <infinity> pitti: And I really don't want to go randomly disabling tests because the autopkgtest rig is less reliable than the buildds, that would be moving in the wrong direction.
[16:11] <pitti> yes, it still fails
[16:11]  * pitti downloads the 57 MB log
[16:11] <cjwatson> You could selectively disable them in autopkgtest if you were really stuck
[16:12] <cjwatson> (env variable, filtering, whatever)
[16:12] <pitti> infinity: the host that we are running this on is probably still precise
[16:12] <infinity> cjwatson: I could slap in a different set of expected results, yeah.  But ew.
[16:12] <barry> pitti: thanks
[16:12] <infinity> pitti: precise host and saucy guests, I assume?
[16:13] <pitti> infinity: saucy guest definitively (we use the daily servercloud image); let me double-check the host
[16:13] <cjwatson> pitti: Ha, I fixed the haskell-yesod one in darcs just before I saw the IRC notification of your bug
[16:13] <infinity> pitti: I don't see how that would be any weirder than any of the setups where it's all gone fine, but I dunno.
[16:13] <pitti> cjwatson: oh, awesome!
[16:13] <infinity> pitti: Anyhow, I need a bit of a nap, so I'll have to ponder it a bit later.
[16:14] <cjwatson> Ah, apparently not quite, hadn't realised yesod was genuinely exiting non-zero too
[16:14] <pitti> badpkg: dependency install failed, exit code 2
[16:14] <pitti> cjwatson: ah, "yesod test" exiting with 127 is actually expected?
[16:15] <cjwatson> I don't think so
[16:15] <cjwatson> I'll look
[16:15] <pitti> infinity: so it's something else now; let's look tomorrow, it's getting late for me, too
[16:15] <infinity> pitti: Oh yay for "something else". :)
[16:15]  * pitti crosses fingers that binutils will succeed now
[16:16] <pitti> infinity: /usr/lib/pbuilder/pbuilder-satisfydepends-classic fails now
[16:16] <pitti> i. e. some bad or uninstallable dependencies
[16:16] <infinity> pitti: Curious.
[16:16] <pitti> Passed regression testing. No new failures, no changed error values.
[16:16] <pitti> infinity: ^ that bit looks good, though :)
[16:17] <infinity> pitti: Shiny.
[16:17] <infinity> pitti: So, apparently, ignoring failures is the best way to fix them.
[16:18] <pitti> oh wait, I think that might not be the whole story
[16:18] <infinity> pitti: Where can I find this log again?  Jenkins and I don't love each other.
[16:19] <pitti> infinity: http://paste.ubuntu.com/5733066/ is the "interesting" excerpt
[16:20] <pitti> infinity: does that look like a test pass or fail? (not sure whether these "make check" errors are expected)
[16:20] <pitti> infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-eglibc/17/ARCH=amd64,label=adt/
[16:20] <infinity> pitti: That's a pass.
[16:20] <pitti> infinity: "log" is the full log
[16:20] <infinity> pitti: It prints out the output of the XFAILs just to remind you. :P
[16:20] <pitti> infinity: ok, then it's just some bogus with test depends or something; I'll have a look tomorrow
[16:21] <infinity> pitti: Well, locales-all doesn't exist.
[16:22] <infinity> pitti: Probably my fault for allowing it to be in the .dsc
[16:22] <pitti> ah, was just trying this with apt-get, indeed
[16:23] <pitti> infinity: we could just add a "Depends: libc-dev" to debian/tests/control
[16:23] <pitti> infinity: the default is "Depends: @" which means "all binaries from that source"
[16:23] <pitti> infinity: but as the important part is the "needs-build", and the actual test is just a "true", the Depends: doesn't matter and it can be a dummy
[16:24] <pitti> infinity: so "libc-dev" or "coreutils" or something like that should do fine
[16:24] <infinity> pitti: Ahh, that would do.
[16:25] <pitti> infinity: do we have a Vcs-* on the Ubuntu side to commit that?
[16:25] <pitti> might not be worth an upload just for this
[16:25] <infinity> pitti: I'll commit it to Debian, the test lives there.
[16:25] <pitti> ah, great; just to stow it away and not having to remember all this again next time
[16:26] <infinity> pitti: I'll just do "Depends: build-essential", seems appropriate for a needs-build.
[16:26] <pitti> infinity: yep, that's what we have in binutils
[16:27] <pitti> (although it's also just a dummy, Depends: is installed after building, FYI)
[16:28] <infinity> pitti: *nod*
[16:28] <infinity> pitti: Is there a bug for this?
[16:28] <pitti> infinity: I can create one if you want to
[16:28] <infinity> Nah, I'm good.
[16:29] <cjwatson> pitti: ah, yesod is just a missing test dep
[16:30] <pitti> cjwatson: oh, is it? I was running this in a VM, and the "yesod" command seemed to exist
[16:30] <cjwatson> it needs cabal-install too
[16:30] <cjwatson> after that it's fine
[16:30] <pitti> ah, nice
[16:30] <cjwatson> (was clear-ish from strace)
[16:30]  * infinity really naps now.
[16:32] <pitti> now, after the efforts of the last three days, let's see how long it takes until the failures are a screenful again :)
[16:33] <pitti> this should get quite a bit better with britney integration in the future, though
[16:33] <pitti> jibel: OOI, any news about the RT about sending the notifications to the uploader?
[16:38] <jibel> pitti, yes, I received an update this morning, and IS is setting up a relay for the lab and "it should be ready in the next couple of days"
[16:38] <pitti> jibel: nice
[16:40] <seb128> pitti, hey, do you plan to deal with the packagekit transition? seems it's in proposed since over a month and that you uploaded it?
[16:40] <Laney> jbicha was talking about that earlier
[16:40] <pitti> seb128: oh sorry, I wasn't aware it's stuck in -proposed
[16:41] <pitti> seb128: yes, can do tomorrow
[16:41] <seb128> pitti, it's not going to be a "tomorrow" thing afaik, we didn't do the transition last cycle because abis changed quite a lot and aptdaemon and stuff need to be ported
[16:41] <seb128> pitti, but we should probably start organizing that (or revert the update)
[16:41] <pitti> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", hmm
[16:42] <seb128> skipped: packagekit (35 <- 26)
[16:42] <seb128>     got: 172+0: i-172
[16:42] <seb128> with a load of packages
[16:42] <slangasek> pitti: binutils> great minds? ;)
[16:42] <pitti> seb128: yes, there is bug 1175972 at least
[16:42] <seb128> pitti, see https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407
[16:42] <seb128> pitti, do you think that update is worth the work involved?
[16:43] <seb128> pitti, I'm pondering if we should just revert to the old version...
[16:43] <Laney> they're not all direct depends
[16:43] <slangasek> pitti: the libiodbc2 breaks can be made Breaks: libiodbc2 (<< 3.52.7-3).  Why does psqlodbc reference iodbc, though?  It should only be using unixodbc
[16:43] <pitti> seb128: I don't have a strong opinion yet before looking at how much needs porting
[16:43] <seb128> Laney, right, but I though we didn't go for it in raring because porting aptdaemon and stuff is not trivial
[16:43] <cjwatson> pitti: update_excuses is package-local checks, update_output is global checks
[16:43] <seb128> pitti, right, we should have a look at the work involved
[16:43] <cjwatson> pitti: (as in Debian)
[16:44] <pitti> slangasek: it's a test dependency, debian/tests/isql has tests for both unixodbc and iodbc
[16:44] <pitti> slangasek: so if we cannot make them co-installable, we can split the test or disable the iodbc one
[16:45] <cjwatson> Reverting to the old version isn't a "just", since it has the potential to screw up library dependencies, surely
[16:45] <pitti> slangasek: but versioned breaks sounds great
[16:45] <slangasek> pitti: disable the iodbc test, iodbc is irrelevant
[16:45] <cjwatson> (I think the pressure to decide whether to revert quickly is off, FWIW, given that this is only in -proposed; yes, I realise it impedes development in the medium term but it's not breaking users so we have some time)
[16:45] <slangasek> pitti: we don't need two ODBC DMs, and the only reason I haven't shot iodbc in the head in Debian is because the Debian KDE folks refuse to let it die
[16:46] <pitti> slangasek: ack, thanks
[16:47] <seb128> cjwatson, right, it's not a "just", but I'm not wanting to spend efforts in porting/fixing aptdaemon/software-center etc for no benefit out of being on the current upstream version of packagekit, at least not this cycle where we have been asked to focus efforts on phone and other things
[16:47] <pitti> seb128: urgh, that's a sizable stack indeed
[16:47] <pitti> seb128: so, I have no particular urgency with the new PK
[16:47] <seb128> pitti, we stayed away from it for a reason...
[16:47] <pitti> it's not even supported
[16:47] <cjwatson> ask somebody like glatzor if he can help, maybe?
[16:48] <seb128> pitti, did you want the new one for a reason or did you overlook that the abi changed so much?
[16:48] <seb128> cjwatson, https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407/comments/6
[16:48] <pitti> cjwatson: yes, I was talking to him quickly about porting aptdaemon
[16:48] <seb128> cjwatson, he said he would work on it, but it has been over 6 months
[16:48] <seb128> cjwatson, I'm sure that will happen at some point, but he seems quite busy atm
[16:48] <Laney> might as well ask
[16:49] <Laney> the transition is pretty well advanced in saucy-proposed as far as archive reverse dependencies go
[16:49] <seb128> glatzor, ^
[16:49] <cjwatson> or Matthias Klumpp might be willing to help out with aptdaemon, perhaps?
[16:49] <pitti> seb128: I wasn't aware it changed so much; I thought some rebuilds would do; but I didn't really spend that much time on it TBH
[16:49] <seb128> ok
[16:49] <pitti> cjwatson: I doubt that, given that Matthias heavily advocates to drop aptdaemon and move to PK proper
[16:49] <seb128> is Matthias Klumpp on IRC?
[16:50] <cjwatson> incidentally, if you do get to the point where you decide the best option is to revert, please talk to me first; it may well be better to simply remove the affected packages from -proposed than to upload a mangled-version thing
[16:50] <pitti> seb128: ximion AFAIR
[16:50] <seb128> pitti, thanks
[16:50] <seb128> cjwatson, noted
[16:50] <seb128> we will wait to hear back from glatzor
[16:50] <seb128> we for sure don't have anyone in Desktop with the free slots to do non trivial aptdaemon porting this cycle
[16:51] <cjwatson> or some combination of removals and rebuilds-against-old-library, or similar.  Just thought I'd say because mangled versions are hard to undo later
[16:51] <Laney> I might manually block it then
[16:51] <Laney> since AFAICT it's in danger of transitioning when stuff builds
[16:51] <cjwatson> If stuff builds then we're golden, surely
[16:51] <pitti> doing it now sounds like lots of pain for little gain then, as long as it's still in Debian experimental
[16:51] <seb128> are stuff likely to build if they are not ported?
[16:51] <Laney> I thought the problem was in python-aptdaemon
[16:52] <seb128> they also changed the dbus apis I guess?
[16:52] <Laney> (or whatever the exact package name is)
[16:52] <pitti> but I didn't expect the API to change that much really; my feeling is that it's mostly aptdaemon
[16:52] <cjwatson> I'd have thought aptdaemon's build-time tests would fail
[16:52] <pitti> they do
[16:52] <pitti> https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-aptdaemon/
[16:52] <pitti> they fail in the PK compat bits
[16:52] <Laney> it's not an rdep of the C library though
[16:52] <seb128> pitti, if you see bug #1022407 (which has the NEWS entry), it says "We've broken a lot of API in this release. A LOT"
[16:53] <seb128> Laney, yes, please put a manual blocker on it
[16:53] <cjwatson> ah, aptdaemon isn't in the broken list
[16:53] <cjwatson> so yeah, agree with seb128
[16:53] <Laney> right, so britney isn't helping out
[16:53] <Laney> doing
[16:53] <seb128> Laney, thanks
[16:53] <seb128> do we need an archive grep for the users of the dbus api if that changed?
[16:54] <pitti> we should do that, yes (start with codesearch.d.n?)
[16:55] <Laney> sounds good
[16:55] <pitti> but most stuff really ought to use the library or the gir, not talk to dbus
[16:55] <pitti> (aside from the fact that the d-bus API is really hard to use)
[16:56] <seb128> pitti, right, I guess the main user is aptdaemon which implements the same apis
[16:58] <seb128> Laney, pitti: http://codesearch.debian.net/search?q=org.freedesktop.PackageKit lists stuff like libreoffice and nautilus using directly the dbus api
[16:59] <seb128> g-c-c yelp
[16:59] <Laney> I'm guessing a lot of stuff will be ported based on the comment in the bug
[17:01] <cjwatson> Do autopkgtests have network access?
[17:01] <cjwatson> Guess it's better not to rely on it ...
[17:04] <jbicha> g-c-c should be fine since 3.6; I believe we actually disable yelp's PK integration since aptdaemon didn't support that feature
[17:04] <seb128> g-c-c is not fine no
[17:04] <pitti> cjwatson: through a proxy, but not very reliably indeed
[17:04] <seb128> jbicha, it's broken the other way around, https://git.gnome.org/browse/gnome-control-center/commit/?id=5366d1188e212d472905ac325df9a4c03eb711a9 ... it will turn off the feature at runtime
[17:05] <seb128> jbicha, which probably means the current archive version has that feature broken :/
[17:06] <jbicha> it's not a very useful feature since we have a dedicated app for checking & installing updates
[17:08] <seb128> right
[17:10] <Laney> I found https://blueprints.launchpad.net/ubuntu/+spec/desktop-r-package-kit
[17:10] <Laney> which links a branch to port aptdaemon but it would likely need more work
[17:11] <Laney> I guess we can revisit in a little while as long as things aren't blocked on it
[17:11]  * Laney goes away
[17:12] <seb128> Laney, right, thanks, have fun
[17:13] <seb128> Laney, yeah, that vcs didn't have any commit for 8 months
[17:23] <pitti> seb128: so tomorrow, should we review how many rebuilds in -proposed we'd need when we drop 0.8 from -proposed?
[17:23]  * pitti needs to make dinner now and has a meeting at 8, can't spend much time on that any more today, sorry
[17:23] <seb128> pitti, I would still like to have an estimate of the aptdaemon port work and a reply from glatzor
[17:24] <seb128> pitti, no worry, we will not sort it out today
[17:24] <seb128> pitti, enjoy your evening, let's look to it a bit more tomorrow
[19:12] <dobey> what's the expected TTL to go from proposed to release pocket on saucy at the moment?
[19:17] <stgraber> dobey: should still be a week for saucy-proposed => saucy-updates, assuming that all the bugs have been verified
[19:20] <seb128> stgraber, ?
[19:21] <stgraber> seb128: ?
[19:21] <seb128> stgraber, saucy is the current active serie, why would proposed to archive take a week?
[19:22] <stgraber> seb128: oops, brain not working today ;) I parsed that as raring...
[19:22] <seb128> dobey, should take a publisher run (less than an hour)
[19:22] <stgraber> dobey: so the real answer is 30min if it's not stuck because it's braking the world
[19:22] <stgraber> *breaking even
[19:22] <seb128> stgraber, ;-)
[19:23] <dobey> oh
[19:24] <seb128> dobey, http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt to see if it's blocked by a transition or something
[19:24] <stgraber> dobey: if you give me the name of the source I can tell you why it's stuck?
[19:24] <seb128> dobey, what source are you looking at?
[19:25] <dobey> ubuntu-sso-client. i guess it's blocked due to the breaks/replaces on python-ubuntuone-storageprotocol i added
[19:26] <seb128> dobey,     * i386: deja-dup-backend-ubuntuone, gir1.2-syncdaemon-1.0, libsyncdaemon-1.0-1, libsyncdaemon-1.0-dev, magicicada, python-ubuntuone-control-panel, ubuntuone-client, ubuntuone-client-gnome, ubuntuone-client-proxy, ubuntuone-control-panel, ubuntuone-control-panel-qt
[19:26] <stgraber> dobey: yep, looks like it'll prevent a whole bunch of packages from being installable, so britney refuses to promote it
[19:33] <dobey> right, ok.
[19:36] <arges> hallyn: hi. Is the qemu-kvm_1.0 package based on the qemu-kvm.git repo tagged qemu-kvm-1.0? or is from another source/tag? thanks
[19:42] <doko> infinity, did you sync llvm-toolchain-3.2? looks like not all patches were migrated from llvm-3.2
[19:56] <slangasek> pitti: hmm, I don't understand why jenkins still shows the binutils autopkgtest as failed, because when I drill down I see "no failures" on https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-binutils/12/
[20:11] <hallyn> arges: yes, qemu-kvm.git
[20:15] <arges> hallyn: thanks
[20:30] <slangasek> cjwatson_: if parted fails with a given GPT, but the kernel and gdisk are both happy with it, is this worth a bug report on parted?
[20:30] <slangasek> cjwatson_: http://paste.ubuntu.com/5733851/
[20:37] <dobey> any archive admin around that can take care of bug #1187554 real quick?
[20:42] <ev> kees: can you try logging in to errors.ubuntu.com for me?
[20:42] <ev> I think we've fixed it
[20:46] <kees> ev: sure, one sec
[20:46] <ev> cheers
[20:47] <kees> ev: hm, same thing
[20:47] <ev> damn
[20:48] <slangasek> dobey: yes - though why the urgency?
[20:49] <ev> oh, my mistake
[20:50] <ev> fixing
[20:51] <dobey> slangasek: not really urgent. just want to see it gone :)
[20:51] <slangasek> dobey: ok, well, done then; but removals are normally batch-processed
[20:51] <ev> kees: if you could try once more, I'd appreciate it
[20:53] <dobey> slangasek: thanks
[20:53] <cjwatson_> slangasek: yep
[20:54] <slangasek> cjwatson: ok.  What data should I attach?
[20:54] <cjwatson> dd of the relevant chunks of disk
[20:55] <slangasek> cjwatson: can you hint me which bits are "relevant"? :)
[20:55] <cjwatson> first 4KB should do
[20:55] <cjwatson> at a guess
[20:55] <slangasek> ok
[20:55] <cjwatson> (IIRC it's actually in sector 1)
[20:55] <cjwatson> Make it 16KiB just in case it has a funny block size or something
[20:58] <slangasek> cjwatson: bug #1187560
[21:21] <kees> ev: sure, one sec
[21:22] <kees> ev: yay! works.
[21:23] <ev> woohoo!
[21:23] <kees> ev: so, is it possible to search based on apport fields?
[21:24] <ev> kees: can you give me an example, or otherwise elaborate on the use case?
[21:24] <ev> the short answer is no, but perhaps it's something we should be doing :)
[21:26] <kees> ev: for example: all packages that crashed with 'Signal' == 11
[21:27] <kees> or, better, all package that have 'SegvReason' containing the string 'executing writable'
[21:29] <ev> there's a few things we could do here
[21:30] <ev> the easiest would be to start tracking the type of crash at the problem level (group of instances of errors matched with the same signature) and keep an index of these
[21:30]  * tedg__ thinks it's nice that kees is making "big data" rootkits  ;-)
[21:30] <kees> generally being able to fish out specific apport fields would be great, but for me personally, I'd like to see the SegvReason and likely things like ProcMaps, Disassembly, and Registers
[21:30] <ev> for the latter case of doing text based searches, we have Hadoop coming this cycle
[21:31] <ev> hopefully
[21:31] <kees> tedg__: yeah, I used to mine launchpad for this stuff. it's great
[21:31] <ev> making a note of all this to explore it in more detail tomorrow and see if we can't come up with a plan
[21:31] <kees> ev: cool, thanks. in the meantime, I'll continue to poke around.
[21:31] <ev> kees: let me know if you break anything ;)
[21:32] <kees> ev: sure thing :)
[21:32] <tedg__> kees, That would be a great defcon talk: "Using Big Data for Evil"  ;-)
[21:33] <ev> tedg__: surely this is adorable-sized data compared to the stuff Google is running :)
[21:33] <tedg__> ev, yes, but Google's not allowed to be evil ;-)
[21:34] <kees> tedg__: I proposed that. they didn't take me up on it. :)
[21:34] <kees> ev: are kernel crashes being reported into this too?
[21:34] <ev> it's quite hard to be when you have a quiet room filled with teddy bears
[21:34] <ev> kees: yes, but it's forever on my list to figure out why we're not getting any
[21:35]  * tedg__ imagines that defcon just rejects all talks and expects you to hack the database and change your talk to accepted if you really want it.
[21:35] <thegatta_> hahaha it could work
[21:36] <sarnold> kees: what?!? You said, "hey guys, wouldn't it be more fun if we _could_ be evil?" and they said _no_??
[21:36] <tedg__> ev, Hmm, now you've left me wondering whether teddy bears are cheaper than sound foam for my office.
[21:37] <ev> tedg__: it'd surely make the property tax inspector give you a good rate
[21:38] <ev> right! I'm getting out of here before you lot create any more work for me
[21:38] <tedg__> 'night ev!
[21:38] <ev> if you desperately want any more features while I'm sleeping, lp:errors is place to go ;)
[21:38] <ev> night!
[21:40] <kees> sarnold: hah, no defcon rejected it
[21:40] <kees> ev: cya!
[21:40] <tedg__> kees, I'm kinda curious if we could track segfaults on system services along with geoip based data to discover botnets looking for vulnerable systems.
[21:40] <sarnold> kees: ah. :)
[21:40] <tedg__> kees, Unfortunately we don't have apport on by default in server.
[21:40] <sarnold> tedg__: ooo
[21:41] <kees> ev: btw, getting kernel crashes showing up would be more interesting than the apport fields for me, if you want to priority on those requests. :)
[21:41] <kees> tedg__: heh. too bad!
[21:41] <kees> it's safe to do suidcoredump=2 thing now, too.
[21:42] <kees> er, fs.suid_dumpable=2  rather
[21:43] <kees> that was a fun fix, inspired by some discussion with ev a while back...
[21:45] <bdrung> ev: no. i can access errors.ubuntu.com again.
[23:04] <xnox> slangasek: can we please have your libpam-runtime back?! =) I believe it's so much better. bug 1187579
[23:05] <slangasek> xnox: hmm, you mean libpam-xdg-support?
[23:05] <xnox> yes.
[23:05] <slangasek> preferably not :)
[23:06] <xnox> slangasek: thanks for volunteering to fix the above bug =) did you notice similar? or shall I wait to see what pitti thinks about it =)
[23:06] <slangasek> yes, pam_xdg_support uses a simpler method of managing sessions, but
[23:06] <slangasek> xnox: I haven't upgraded to 204-0ubuntu1 yet
[23:06] <xnox> hm. ok.
[23:06] <slangasek> I think the person who uploaded it should get to fix this ;P
[23:06] <xnox> solomon's decision - invoke the TIL rule
[23:58] <infinity> doko: I didn't, no.