=== wedgwood is now known as wedgwood_away [04:49] Good morning === dpm-afk is now known as dpm [06:01] infinity: is there some amount of merges you would trade against taking initramfs-tools from me? [06:03] infinity: hm, it seems texinfo, apr, and vim are all comparatively simple === smb` is now known as smb === greyback|away is now known as greyback [07:05] good morning [07:08] @pilot in === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach [07:24] cyphermox, what do you think about https://code.launchpad.net/~jbicha/ubuntu/saucy/network-manager/depend-on-valac/+merge/166626? [07:25] to me it seems to be a bit of a matter of preference - I'll leave it up to you :) === ivoks_ is now known as ivoks [08:13] pitti: Oh, I'll take initramfs-tools back anyway, since I'm upstream. My bad for forgetting about it. [08:14] infinity: thanks; I'm happy to take off texinfo and apr from you anyway if you want [08:15] 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] pitti: Oh, actually, my texinfo cross hacks are vile too. I should probably keep that and sort out something less disgusting. [08:16] 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] sounds like forgetting as a good idea in this case :) [08:36] Mirv, so I merged your touch merge proposal for ubuntu-seeds - are you going to upload another -meta? [08:37] Mirv, there's a bunch of changes since the last time - does http://paste.ubuntu.com/5731925/ look all right to you? [08:37] Mirv, I can put your email address into it if you like ;-) [08:40] you might want to check with ogra [08:40] "Removed powerd" seems suspicious [08:40] but maybe that's pulled in another way [08:40] erm, the touch seeds are special [08:41] 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] dholbach: thanks! looks good for the sdk related changes, although I can't do the uploads. [08:41] I'll leave the rest to you then [08:41] you need to manually hack them until things are in the archives, germinate cant use PPAs [08:41] aha [08:41] nevermind then [08:41] mm, been meaning to figure that out ... [08:41] i'll take care later [08:41] thanks ogra! [08:41] (I haven't done any touch meta related changes) [08:41] cjwatson, nah, we better get that stuff into the archive [08:42] Well, sure, but I consider it a germinate bug anyway [08:42] Probably [08:47] germinate can't use PPAs? [08:47] Can't you just feed it another -m? [08:48] I would think that should Just Work. [08:52] 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] Yeah, I was just following that code now to see how or why that's more special than a by-hand invocation. [08:53] It does even go and fetch the relevant Packages files [09:27] * cjwatson attacks germinate-update-metapackage with pdb [09:38] 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] cjwatson, looks like it removed everything under the debug section ... weird [09:39] and powerd [09:39] though i'm not sure it is seeded [09:39] * ogra looks [09:40] ogra: "debug section"? [09:40] in the touch seed [09:40] ogra: It only removed powerd on i386 [09:40] Where, I'm guessing, it doesn't exist [09:40] ah, that might be [09:40] ogra: All the entries in the debug section are duplicated from ubuntu-minimal [09:40] iputils-ping [09:40] from the debug section [09:41] oh [09:41] sorry, typed to fast [09:41] ogra: Your STRUCTURE file says "touch: minimal", so germinate intentionally prunes those [09:41] well, then it looks perfect [09:41] ogra: And, indeed, your livecd-rootfs config installs ubuntu-minimal as well, so they are indeed redundant [09:41] yeah [09:42] thats how it is supposed to be [09:42] i'll drop it from the seed [09:42] OK, I'll double-check powerd and if that's right then I'll upload [09:43] yeah, i think it is intentionally not built for x86 yet [09:43] iirc it wants to talk to android devices [09:44] Indeed, https://launchpad.net/%7Ephablet-team/+archive/ppa/+sourcepub/3241512/+listing-archive-extra concurs [09:46] That was against 1.009, BTW, so a bit laggy. I'll update against 1.015 [09:58] @pilot out === udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [09:59] (I'll do the rest of my shift tomorrow. Got to take care of some other bits first.) === Sweetsha1k is now known as Sweetshark [10:15] ogra: OK, uploaded ubuntu-touch-meta. Could you use the ./update script for future changes? [10:15] cjwatson, with pleasure ! [10:15] thanks a lot ! [10:15] np. didn't really do much other than observing it worked :-) === mmrazik is now known as mmrazik|lunch === mmrazik|lunch is now known as mmrazik === MacSlow is now known as MacSlow|lunch [12:23] * cjwatson holds his breath and uploads a debhelper merge [12:23] Let me know if you notice any resulting weirdness [12:35] 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] jibel: not known to me at least; can you please file a bug? [12:39] jibel: I tested the upgrade on a normal system, which went fine [12:39] pitti, sure, it's is blocked on "stop udev" [12:39] jibel: I guess I should be reproducible in otto? :-) [12:40] jibel: oh, it's the *old* udev which fails to stop? [12:40] pitti, yes, that's the problem :) I was provisioning a fresh saucy [12:40] postinst does "invoke-rc.d udev restart", that shoudl call "stop udev" === MacSlow|lunch is now known as MacSlow === tkamppeter_ is now known as tkamppeter [13:10] pitti, bug 1187375 [13:10] bug 1187375 in systemd (Ubuntu) "upgrade of udev from 202-0ubuntu12 to 204-0ubuntu1 hangs on configure in LXC container" [Undecided,New] https://launchpad.net/bugs/1187375 [13:15] jibel: thanks; I'll stop my "fix autopkgtest" vendetta now and look at this [13:17] pitti, thanks! [13:25] stgraber: anything I should look out for in this user upstart kde-plasma session? seems to work fine [13:32] 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] gpg: problem with the agent - disabling agent use [13:40] stgraber: might that be caused by it? [13:40] ^^ === ckpringle_ is now known as ckpringle [13:41] 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] 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] Riddell: either way, "initctl status gpg-agent" and "env | grep GPG" may help figuring out what's going on there [13:47] Riddell: oh, and "grep use-agent ~/.gnupg/gpg.conf" too [13:47] >initctl status gpg-agent [13:47] gpg-agent start/running [13:47] GPG_AGENT_INFO=/tmp/gpg-cTlh4g/S.gpg-agent:24776:1 [13:48] use-agent is set in my ~/.gnupg/options [13:48] and I have pinentry-qt4 installed [13:48] 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 === wedgwood_away is now known as wedgwood [13:50] and ^Cing it and re-tryign "start udev" causes upstart to lie "job has already been started", although udevd isn't running === kentb-out is now known as kentb [13:52] 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] Riddell: what do you get if you run "gpg-connect-agent"? [14:11] stgraber: a > prompt character [14:20] Riddell: ok, so it managed to connect to the agent... [14:20] Riddell: that suggests the agent is running as expected, not sure what that error message is about then... [14:21] hmm, no infinity in #ubuntu-touch ... so i'll ask here ... [14:21] infinity, we need to find some way to exclude the /etc/init.d/ondemand script on ubuntu-touch [14:22] ogra: Why? [14:22] cpu frequency stuff is full in the hands of the android side [14:22] and my phone starts to glow after the script forced ondemand here [14:23] i was wondering if we could move it to its own package and just make it a recommends [14:23] interactive, surely. [14:23] If it's an Android kernel. [14:23] And all we're doing it poking some /proc bits, which I assume Android is setting similarly. [14:23] Can you see what all those bits are set to before ondemand runs? [14:25] ogra: Just how much Android userspace are we running, anyway? And why don't we pare it down more? [14:27] 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] 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] doing this part relibable in the same way android does it will be hard [14:28] and the android settings should usually get us the best setup for power saving [14:28] 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] 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. === ckpringle_ is now known as ckpringle [14:29] ogra: Assuming the Android setup is what we want is probably not true. Our userspaces are wildly different. [14:29] jodh, xnox: oh, of course -- just after I asked i got it [14:30] jodh, xnox: there was a "start on starting udev" job which failed; where would/should I have seen that? [14:30] jibel: ^ we need to auto-destruct or fix /etc/init/lxc-udev.conf :) [14:30] infinity, right, and currently our userspace doesnt have anything HW related at all we talk to HW through the platform-api [14:31] 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] 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] jodh: ah, thanks for "log-priority debug" [14:33] 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] ogra: And if there is, I don't see how we're getting in its way. [14:34] no, it isnt ... that was long ago [14:34] with interactive governors the user actions are monitored all the time [14:34] By the kernel. [14:34] Hence my "set and forget" comment. [14:35] This is true of all governors except powersave and performance. [14:35] well, the interactive governor on the nx4 has like 20 settings or so [14:35] and they differ for every exynos [14:36] s/exynos/exynos device/ [14:36] 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] not with ubuntu-touch ... the defaults are set from androids init [14:37] so we need to leave it to the container to set them up [14:37] and not force ondemand [14:38] We don't force ondemand. [14:38] 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] pitti, thanks for finding this [14:38] ogra: What order do these scripts get run in? Ours first, then Android's, or the inverse? [14:39] ogra: And what do the settings look like when Android's done with it? [14:39] jibel: I'm working on a fix [14:40] 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] 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] ogra: Cause if Android's setting up tweaks, and all we're doing is setting it to interactive, everyone wins. [14:40] 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] infinity, we force ondemand if we do find it [14:41] (and the system uses one of its own governors nobody knows about ... like on three of my foud devices here)( [14:41] *four [14:41] ogra: No, we force ondemand if we *don't* have interactive. [14:41] yes [14:42] ogra: So, what are these other governors? [14:42] jodh: yes, it's today's saucy image, and I ran it with sudo [14:42] inevnted by the vendors [14:42] ogra: Their names. :P [14:42] * ogra doesnt have the names here [14:42] not std kernel ones [14:43] ogra: Sure, interactive isn't standard either. [14:43] hmm, i thought it was since a while [14:43] on arm at least [14:43] No, it's Android-specific. [14:43] 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] well, in any case, android will set them on container start [14:44] jodh: sudo stop/start whoopsie also doesn't log anything; logger foo works [14:45] jodh: might be because that's inside a container? [14:45] ogra: Sure. So, we can make our script just exit silently if it finds any of these other fancy governors. [14:45] 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] pitti: maybe rsyslog isn't running? [14:45] pitti: unsure - stgraber? [14:45] ogra: And I'm not sure flipping matters, given that the init script sleeps for 60s, it's probably always run last. [14:45] infinity, i would at least make it fail if it finds the android upstart job [14:46] oh, right [14:46] jodh: it is running, I get log messages from other stuff just fine (e. g. dbus tells me spawned services) [14:46] still redundant though [14:46] ogra: What's this Android upstart job? We can certainly just exit 0 if that exists. [14:47] lxc-android-container.conf [14:47] 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] if it wouldnt be a sysvinit script that would be easier :) [14:48] ls -l /var/lib/lxc/ [14:48] argh [14:49] 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] ogra: Out of curiosity, where did all these interactive tweaks come from? [14:50] infinity, the ones we ship atm ? [14:50] androids nexus7 init scripts [14:50] 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] 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] infinity, loading interactive with its defaults made the device crawl [14:51] yeah, tear themm out [14:51] nexus7 desktop is done [14:51] ogra: That's the opposite of the reports I got from others when I enabled it... === davidcalle_ is now known as davidcalle [14:51] the load was constantly around 2.x [14:51] with interactive properly configured it was normal [14:52] feel free to try it if you still have an nx7 desktop around :) [14:52] I don't. [14:52] it was a quite noticeable difference [14:52] (like switching from beagle to panda) [14:55] 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] 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] jibel: ^ can I pass this option to lxc-start from otto start? [14:56] jodh: right, mounted-run is a signal, not a job === mmrazik is now known as mmrazik|otp [14:56] jodh: it'll only happen on boot AFAIK (it works there, i. e. during bootup udev is getting started just fine) [14:56] jodh: ok, I'll probably just redesign that job to disable itself [14:57] pitti: mounted-run is a job. [14:57] pitti, if it is supported by the python binding yes [14:58] ogra: http://paste.ubuntu.com/5732832/ <-- Verify that path is right? [14:59] infinity, wrong ... /etc/init/lxc-android-config.conf === mmrazik|otp is now known as mmrazik [15:00] 08:47 < ogra> lxc-android-container.conf [15:00] 08:59 < ogra> infinity, wrong ... /etc/init/lxc-android-config.conf [15:00] This is what I get for trusting people. ;) [15:00] haha, sorry [15:01] jodh: ah, close enough; it's a task, i. e. it's usually stopped [15:01] ogra: Uploaded with that correction. [15:01] 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] jibel: so I'd rather not use anythign file system based, except /run [15:02] do we have a /run/init/ for jobs? [15:03] infinity, thx ! [15:03] 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] 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] (as used in user sessions for example) [15:04] xnox: didn't we explicitly decide not to support this in system mode? [15:04] jibel: ok, that works fine [15:04] pitti, otherwise we could delete the override in the pre-mount [15:04] pitti, ok [15:04] stgraber: it would be similar to /run/udev/rules.d/ [15:05] stgraber: correct. but it wouldn't be hard to enable. [15:06] 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] 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] and initctl reload-configuration would be needed. [15:11] 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] sure. [15:12] 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] cjwatson: yes. https://wiki.ubuntu.com/Touch/Install#Manual_Installation [15:15] 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] k, thanks [15:17] 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] jibel: hm, seems we need the "mounted-run" after all, so I don't commit my changes [15:21] jibel: so we need to remove the override in the pre-mount script [15:21] jibel: I'll commit that [15:22] jibel: (done) [15:25] pitti, many thanks, I'll do a run with the fix. === ckpringle_ is now known as ckpringle [15:39] 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] slangasek: thanks [15:42] * pitti goes on to the next one [15:47] slangasek: do we still need the "Breaks: libiodbc2" in odbcinst1debian2 (from bug 901638)? [15:47] bug 901638 in soprano (Debian) "Remove iodbc2 (causes upgrade failure from Oneiric to Precise)" [Unknown,New] https://launchpad.net/bugs/901638 [15:48] 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] xnox: are those saucy images supposed to work currently? [15:48] I just pushed them and I got into a reboot loop [15:50] Laney: I had more success upgrading and/or using the custom saucy image from someone's blog post. [15:50] I think I'll go back to the normal ones for now [15:50] * Laney fablet-phlash [15:50] slangasek: it was an upgrade fix to precise, but I'm not sure whether it still makes sense semantically [15:52] wait, might have pushed the wrong thing the second time [16:03] bdrung: hi. Are you still unable to access errors.ubuntu.com? [16:04] we've had another report of this today via dpm, so this could be a bug [16:04] barry: hey, how are you? [16:05] pitti: hi! good, and you? [16:05] 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] barry: I'm fine, thanks! [16:06] pitti: i could take a crack at it, but it probably won't be today. is there a bug open on it? [16:06] barry: I can open one if it helps for scheduling/reminding [16:06] pitti: it definitely would :) [16:07] 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] barry: cheers, will do [16:07] pitti: sounds good [16:10] pitti: Does eglibc still fail? I haven't looked in a while. === Ursinha is now known as Ursinha-afk [16:10] pitti: Interestingly, after we went and blamed qemu/kvm, eglibc passed its testsuite with flying colors on the new kvm openstack buildds. [16:10] pitti: And it's not the raring/saucy kernels, cause that's what I test on at home. [16:10] infinity: hah, good to hear [16:10] pitti: So, if it's still broken, I'm a bit stumped. [16:11] barry: filed bug 1187460 with all links and an excerpt of the failures [16:11] bug 1187460 in oneconf (Ubuntu) "autopkgtest has several failures" [Undecided,New] https://launchpad.net/bugs/1187460 [16:11] 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] yes, it still fails [16:11] * pitti downloads the 57 MB log [16:11] You could selectively disable them in autopkgtest if you were really stuck [16:12] (env variable, filtering, whatever) [16:12] infinity: the host that we are running this on is probably still precise [16:12] cjwatson: I could slap in a different set of expected results, yeah. But ew. [16:12] pitti: thanks [16:12] pitti: precise host and saucy guests, I assume? [16:13] infinity: saucy guest definitively (we use the daily servercloud image); let me double-check the host [16:13] pitti: Ha, I fixed the haskell-yesod one in darcs just before I saw the IRC notification of your bug [16:13] 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] cjwatson: oh, awesome! [16:13] pitti: Anyhow, I need a bit of a nap, so I'll have to ponder it a bit later. [16:14] Ah, apparently not quite, hadn't realised yesod was genuinely exiting non-zero too [16:14] badpkg: dependency install failed, exit code 2 [16:14] cjwatson: ah, "yesod test" exiting with 127 is actually expected? [16:15] I don't think so [16:15] I'll look [16:15] infinity: so it's something else now; let's look tomorrow, it's getting late for me, too [16:15] pitti: Oh yay for "something else". :) [16:15] * pitti crosses fingers that binutils will succeed now [16:16] infinity: /usr/lib/pbuilder/pbuilder-satisfydepends-classic fails now [16:16] i. e. some bad or uninstallable dependencies [16:16] pitti: Curious. [16:16] Passed regression testing. No new failures, no changed error values. [16:16] infinity: ^ that bit looks good, though :) [16:17] pitti: Shiny. [16:17] pitti: So, apparently, ignoring failures is the best way to fix them. [16:18] oh wait, I think that might not be the whole story [16:18] pitti: Where can I find this log again? Jenkins and I don't love each other. [16:19] infinity: http://paste.ubuntu.com/5733066/ is the "interesting" excerpt [16:20] infinity: does that look like a test pass or fail? (not sure whether these "make check" errors are expected) [16:20] infinity: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-eglibc/17/ARCH=amd64,label=adt/ [16:20] pitti: That's a pass. [16:20] infinity: "log" is the full log [16:20] pitti: It prints out the output of the XFAILs just to remind you. :P [16:20] infinity: ok, then it's just some bogus with test depends or something; I'll have a look tomorrow [16:21] pitti: Well, locales-all doesn't exist. [16:22] pitti: Probably my fault for allowing it to be in the .dsc [16:22] ah, was just trying this with apt-get, indeed [16:23] infinity: we could just add a "Depends: libc-dev" to debian/tests/control [16:23] infinity: the default is "Depends: @" which means "all binaries from that source" === mmrazik is now known as mmrazik|afk [16:23] 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] infinity: so "libc-dev" or "coreutils" or something like that should do fine [16:24] pitti: Ahh, that would do. [16:25] infinity: do we have a Vcs-* on the Ubuntu side to commit that? [16:25] might not be worth an upload just for this [16:25] pitti: I'll commit it to Debian, the test lives there. [16:25] ah, great; just to stow it away and not having to remember all this again next time [16:26] pitti: I'll just do "Depends: build-essential", seems appropriate for a needs-build. [16:26] infinity: yep, that's what we have in binutils [16:27] (although it's also just a dummy, Depends: is installed after building, FYI) [16:28] pitti: *nod* [16:28] pitti: Is there a bug for this? [16:28] infinity: I can create one if you want to [16:28] Nah, I'm good. [16:29] pitti: ah, yesod is just a missing test dep [16:30] cjwatson: oh, is it? I was running this in a VM, and the "yesod" command seemed to exist [16:30] it needs cabal-install too [16:30] after that it's fine [16:30] ah, nice [16:30] (was clear-ish from strace) [16:30] * infinity really naps now. [16:32] 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] this should get quite a bit better with britney integration in the future, though [16:33] jibel: OOI, any news about the RT about sending the notifications to the uploader? [16:38] 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] jibel: nice [16:40] 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] jbicha was talking about that earlier [16:40] seb128: oh sorry, I wasn't aware it's stuck in -proposed [16:41] seb128: yes, can do tomorrow [16:41] 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] pitti, but we should probably start organizing that (or revert the update) [16:41] http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html says "valid candidate", hmm [16:42] skipped: packagekit (35 <- 26) [16:42] got: 172+0: i-172 [16:42] with a load of packages [16:42] pitti: binutils> great minds? ;) [16:42] seb128: yes, there is bug 1175972 at least [16:42] bug 1175972 in aptdaemon (Ubuntu) "aptdaemon packagekit compatibility layer broken" [Undecided,Fix released] https://launchpad.net/bugs/1175972 [16:42] pitti, see https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407 [16:42] Launchpad bug 1022407 in packagekit (Ubuntu) "Update to 0.8.x" [Wishlist,Triaged] [16:42] pitti, do you think that update is worth the work involved? [16:43] pitti, I'm pondering if we should just revert to the old version... [16:43] they're not all direct depends [16:43] 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] seb128: I don't have a strong opinion yet before looking at how much needs porting [16:43] Laney, right, but I though we didn't go for it in raring because porting aptdaemon and stuff is not trivial [16:43] pitti: update_excuses is package-local checks, update_output is global checks [16:43] pitti, right, we should have a look at the work involved [16:43] pitti: (as in Debian) [16:44] slangasek: it's a test dependency, debian/tests/isql has tests for both unixodbc and iodbc [16:44] slangasek: so if we cannot make them co-installable, we can split the test or disable the iodbc one [16:45] Reverting to the old version isn't a "just", since it has the potential to screw up library dependencies, surely [16:45] slangasek: but versioned breaks sounds great [16:45] pitti: disable the iodbc test, iodbc is irrelevant [16:45] (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] 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] slangasek: ack, thanks [16:47] 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] seb128: urgh, that's a sizable stack indeed [16:47] seb128: so, I have no particular urgency with the new PK [16:47] pitti, we stayed away from it for a reason... [16:47] it's not even supported [16:47] ask somebody like glatzor if he can help, maybe? [16:48] pitti, did you want the new one for a reason or did you overlook that the abi changed so much? [16:48] cjwatson, https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1022407/comments/6 [16:48] cjwatson: yes, I was talking to him quickly about porting aptdaemon [16:48] Launchpad bug 1022407 in packagekit (Ubuntu) "Update to 0.8.x" [Wishlist,Triaged] [16:48] cjwatson, he said he would work on it, but it has been over 6 months [16:48] cjwatson, I'm sure that will happen at some point, but he seems quite busy atm [16:48] might as well ask [16:49] the transition is pretty well advanced in saucy-proposed as far as archive reverse dependencies go [16:49] glatzor, ^ [16:49] or Matthias Klumpp might be willing to help out with aptdaemon, perhaps? [16:49] 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] ok [16:49] cjwatson: I doubt that, given that Matthias heavily advocates to drop aptdaemon and move to PK proper [16:49] is Matthias Klumpp on IRC? [16:50] 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] seb128: ximion AFAIR [16:50] pitti, thanks [16:50] cjwatson, noted [16:50] we will wait to hear back from glatzor [16:50] we for sure don't have anyone in Desktop with the free slots to do non trivial aptdaemon porting this cycle [16:51]