[00:12] * infinity grumps at rebooting to a dnsmasq eating 100% CPU and no name resolution. [00:12] stgraber: ^-- Do you know what's up with that? [00:13] this has been happening to me quite a lot too [00:13] well not sure about the eating cpu part [00:13] but resuming laptop and having no dns has been frequent [00:13] (until killall dnsmasq, which seems to make resolvconf just put the remove nameservers in /etc/resolv.conf) [00:14] I killed dnsmasq, unplugged network, replugged network, and got a fresh dnsmasq that wasn't broken. [00:15] infinity: yes, new dnsmasq is broken [00:15] bug 1313393 [00:15] bug 1313393 in dnsmasq (Ubuntu) "dnsmasq lockup at 100% cpu" [Undecided,Confirmed] https://launchpad.net/bugs/1313393 [00:16] Simon Kelley appears to be on it [00:16] barry: ImportError: No module named _sysconfigdata_nd <-- virtualenv package in 14.04 is broken [00:16] any plans on this being fixed? it's not great having to use pip to install a working virtualenv [00:19] hm. this may be related to something being locked in config management [00:22] indeed. user error. ignore me === rww is now known as rww` === _salem is now known as salem_ === salem_ is now known as _salem [02:26] rsalveti: http://people.canonical.com/~xnox/gcc-i686-linux-android_4_amd64.deb [02:26] rsalveti: but i can't build it in the archive, getting ice from compiler whilst bootstrapping... [02:27] * sarnold rubs his eyes .. i686 .. amd64 .. linux .. android .. [02:27] surely it must just be a bad dream [02:50] don't worry it fails bootstrap with ubuntu toolchain, builds fine with aosp provided official c compiler..... wait trusting trust === rww` is now known as rww [05:05] Good morning [05:08] slangasek: poll> I didn't see an option to convert to local timezones (but I didn't create an account) [05:08] slangasek: yes, these are meant to be London times as I wrote; I left out the ones which definitively don't overlap between EU and US (unless you want to meet in the middle of the night) [05:10] hallyn: the scipts and sourcing of /etc/default/cgmanager are a bit awkward, but that can all be translated pretty much 1:1 [05:10] hallyn: as a guide, I recommend reading man systemd.unit and systemd.service (they explain the available options in an unit file), and perhaps even more look at existing ones [05:11] hallyn: e. g. for cgmanager you don't need to specify any dependencies, the default basic.target (usual stuff mounted etc.) is fine [05:12] hallyn: as for the cgm_extra_mounts= bits, I recommend putting those into config files; systemd units are not conffiles, and upstart jobs really really should have never been [05:26] pitti: morning - yeah, I figured out that was the case, so filled it out accordingly :) [05:27] It hurt my brain a bit to convert to London times, and I have a clock that does it and everything. [05:29] slangasek: I saw, thanks [06:07] xnox: you already uploaded gvfs for plist in 1.20.1-1ubuntu2 :) [06:07] xnox: anyway, gvfs' tests are broken with the new libgphoto2, I need to update them (same as with umockdev) [06:43] pitti: BTW, don't know if you've been following backscroll in #debian-devel, but seems when you boot with systemd, /run/shm is no longer a thing. Might be nice to JFDI a fix on that, so I can stop arguing with Tollef about it. [06:44] Yes, /run/shm doesn't exist for me. [06:53] infinity: eek; yes, we'll need that [06:53] at least a symlink to /dev/shm/ [06:54] infinity: what was Tollef's argument against that? [06:54] infinity, Unit193: mind filing a bug (LP is ok)? I have my head full of debugging state for autopkgtest mess, and that's my #1 prio ATM [06:58] pitti: Debian's wrong, everyone else uses /dev/shm, systemd is always right, we should just drop /run/shm and fix anything that references it instead of having a compat migration plan. [06:58] pitti: Basically. [06:58] pitti: I might have disagreed a fair bit on the conclusion. === work_alkisg is now known as alkisg [07:00] doko__: Hi, is merging python-babel somewhere on your TODO list? Could you also take a look at bug #1299442 as I assume that it's fixed in Debian (run into this bug during a dist-upgrade to trusty). Or is it OK if I prepare the merge and possible SRU? [07:00] bug 1299442 in python-babel (Ubuntu) "UnknownLocaleError: unknown locale 'en'" [Undecided,Confirmed] https://launchpad.net/bugs/1299442 [07:01] infinity: argh, what was that site to grep all Debian source packages again? [07:01] *tock* *tock* memory, start working! [07:03] http://sources.debian.net/ ? [07:03] pitti: http://codesearch.debian.net/ [07:04] aah, that was it, tahnks [07:05] infinity, Unit193: nevermind, already reported: debian bug 674755 [07:05] Debian bug 674755 in systemd "systemd: tmpfs inconsistencies (/run/lock, /run/shm, /tmp)" [Normal,Open] http://bugs.debian.org/674755 [07:07] so indeed most of codesearch's results seem to be quirks for Debian using /run/shm, but still, having a compat symlink doesn't hurt [07:10] pitti: I think at least a compat symlink for wheezy->jessie migrations and 14.04->16.04 migrations probably makes sense. Discussing dropping it after, if literally everyone else uses /dev/shm and no one can come up with an argument for why we decided it might be nice to have it on another FS (or referenced from run) is a fine conversation to have later. [07:11] pitti: Then again, if there *is* a valid reason for it to be on its own FS, inverting the mountpoint and link would be nice. [07:11] infinity: it has always been its own tmpfs, it's just whether it was mounted on /dev/shm/ or /run/shm/ [07:11] (For the record, comments in code aside, glibc DTRT in either case, as long as both paths exists, and one is a link to the other) [07:12] right, eglibc has /run/shm/ as an alternate fallback for the Debian case [07:12] pitti: Err, right, sorry, it's its own FS, but maybe there we sane arguments for it not loving under udev's tmpfs. [07:12] pitti: And maybe those arguments are long buried in the past. [07:12] infinity: I think it was mostly from the time when some Debian people said "but we don't want udev" [07:12] pitti: That glibc code you're reading is actually the kfreebsd patch. [07:13] pitti: The linux path Just Works if the symlink is in place. [07:14] (The linux code is horribly awful after that point, and I might sent a patch upstream tomorrow to tear out about 50 lines of nonsense, but at leas that bit works...) [07:14] s/sent/send/ [07:14] infinity: wasn't /run/shm a change that rleigh inflicted on us, deviating from upstream? [07:14] slangasek: Yeah, but does anyone know why? :P [07:14] infinity: because he thought it was prettier [07:15] If there are no valid arguments, I'm all for reverting the mountpoint back to /dev/ (as systemd does), but I still think a release cycle of grace period for a compat symlink is sane. [07:15] "shared memory is not a device" [07:15] let's rename /etc/ to /config because it's prettier :) [07:15] infinity: yes, agreed [07:16] infinity: but you might want to scan all your chroots before trying to switch this back, because I'm not sure the migration *to* /run/shm was ever finished correctly [07:16] In fact, my buildds all have the inverted setup (mount in /dev, symlink in /run) because launchpad-buildd has a bug where the inverse explodes, and I'm too lazy to fix it. :P [07:16] I didn't mean just buildd chroots fwiw [07:17] slangasek: Yeah, how this will work for chroot upgrades is a touchy thing. And, in fact, that's touched on in the initscripts postinst comments of doom. [07:18] slangasek: For real systems, it's likely cake. Reboot into systemd, it mount /dev/shm, does a check on the state of /run/shm, and if it's a directory, wipes it and replaces with symlink. [07:18] Which, handily, would DTRT if you rebooted back into sysvinit or upstart, I think, as they'd just mount the inverted way on the next boot. I think. [07:18] But anything with a more manual chroot mount setup is touchier. [07:19] Err, /run/shm wouldn't be a directory, obviously, it's in run. [07:19] But you know what I mean. [07:19] systemd would just create symlink and done. [07:19] (on a real system) [07:21] I'm obviously too tired to discuss this sanely. :P [07:35] infinity: for "real" systems there's no migration issue really, as both /dev/ and /run/ are (dev)tmpfses [07:35] pitti, hey, question about autopkgtest - what's the recommended approach when you have mocks (built during dpkg-buildpackage, but not packaged) that you need for autopkgtest, is it better to package them in a foo-tests package or so, or build them during the test run itself? [07:35] and for chroots that should just do [ -e /run/shm ] || ln -s /dev/shm /run/shm [07:35] pitti: Yeah, that was my "I'm obviously too tired" comment. [07:36] Saviq: if it's cheap to build (which I assume), use "needs-build" and use the built mocks [07:36] Saviq: err, "build-needed" [07:36] pitti, huh, that's contrary to DEP-8 :) [07:36] Saviq: if that builds too much, your debian/tests/foo can also do something like make -C tests/mocks/ to only build what you actually need for the test [07:37] pitti, yeah, the latter was what I was thinking of [07:37] Saviq: DEP-8 makes no prescription for that [07:37] And if it's really expensive, ship foo-test. [07:37] Which is what I plan to do with glibc, once it can actually run the testsuite out of tree (getting there!) [07:37] Saviq: we use packaged installed tests for packages like glib where building everything again would be too expensive [07:38] pitti, I'm about unity8 here, a full build took ~12 mins on LP [07:39] pitti, that considered cheap? [07:39] Saviq: but hopefully you don't need to build the full unity for just the mocks? [07:39] pitti, sure, it would take even less for the mocks [07:39] Saviq: I take it it will take much longer on armhf [07:39] Saviq: if you can do a partial build, that's definitively preferred [07:39] pitti, ~21 mins [07:39] for a full build [07:39] -tests packages are by and large clutter [07:40] yeah, that's what I thought [07:40] I think building only the mocks will only be like ⅓ of the time [07:40] ok, going that route then [07:41] pitti, thanks! could I ask you for a review once I have the autopkgtest MP'd? [07:41] Saviq: sure! [07:41] great, thanks [07:58] pitti: excellent write-up and progress on the systemd sprint, it was very fun to read (brings back memories from fun and productive sprints) [08:05] zyga: thanks :) [08:17] pitti, heh, was that sprint photo taken by a painter ? [08:18] ogra_: heh, that was a fun one; we couldn't find a place where to put the mobile phone so that it would see us all [08:18] ogra_: so we used a laptop and cheese; apparently that laptop's webcam was crappy, or he still had some "oil painting" effect enabled.. [08:18] lol === superm1_ is now known as superm1 === infinity3 is now known as infinity === Mirv_ is now known as Mirv === mnepton is now known as mneptok === Ursinha_ is now known as Ursinha === halfie_ is now known as halfie === dbarth_ is now known as dbarth === warp10_ is now known as warp10 === davmor2_ is now known as davmor2 === Adri2000_ is now known as Adri2000 === vrruiz_ is now known as rvr [09:17] xnox: you have updated one B-D in package libzrtpcpp (2.0.0-3build2) (http://launchpadlibrarian.net/155442202/libzrtpcpp_2.0.0-3build1_2.0.0-3build2.diff.gz), is it still necessary, or can be dropped? [09:18] Logan_: I've added you now, thanks [09:30] What's the command-du-jour to get from cozy 14.04 to utopic... the usual suspects don't work (yet)? [09:36] MacSlow: sensible-editor /etc/apt/sources.list [09:36] geser, I feared that answer :) [09:36] MacSlow: sudo sed -i 's/trusty/utopic' /etc/apt/sources.list :) [09:36] MacSlow: sorry, sudo sed -i 's/trusty/utopic/' /etc/apt/sources.list [09:37] MacSlow: or wait a tiny bit and I upload a new release upgrader [09:37] pitti, that's even more terrifying ;) [09:37] MacSlow: but noninteractive [09:37] mvo, ah... yeah, that sounds safer :) [09:38] MacSlow: tiny bit in relative terms, but I hope to get it ready by end-of-today [09:38] MacSlow: :) [09:38] until then: schroot FTW :) [09:39] pitti, geser: I'm so used to dog-fooding our (ui-)tools, I don't do things manually anymore [09:40] mvo, the time-resolution-granularity of days is enough of a hint for me [09:40] MacSlow: great, I had hoped for that [09:43] ev_: oh, nice! https://www.oasis-open.org/news/pr/iso-and-iec-approve-oasis-amqp-advanced-message-queuing-protocol [09:44] wow, that's one of those things where my first reaction was, "wait, it wasn't already a standard?" [09:45] pitti: how's the dep8 rearchitecture coming along? [09:45] are you enjoying working with swift and rabbit? === ev_ is now known as ev [09:45] ev: was a bit stalled while Antonio was reviewing my patches so far, and I was working on the current utopic autopkgtest bugs [09:46] ev: but he pulled all my patches now, so I can contine (however, utopic autopkgtest regressions will still keep me a bit busy) [09:46] * ev nods [09:46] ev: yes, I do; it's quite lovely, AMQP is so much easier than having to endure the jenkins pain [09:46] yeah, tell me about it [09:47] thanks to doanac we've killed Jenkins in the airline [09:47] entirely a queue-based, microservice architecture now [09:53] is it normal for gnome-control-center to show 13.10 in the 'details' tab (system info?) [09:53] on 14.10 [09:54] oh, nice! [09:55] Don't know about normal, but it is known that that's wrong [09:56] It needs manually fixing and nobody's done it yet [09:56] shows 14.10 here [09:56] pitti: unity or gnome? [09:56] zyga: oh, unity [09:56] pitti: yeah, I though the fork might be responsible [09:56] pitti: probably shows 13.10 in 14.04 as wel [09:56] well [09:57] odd, why would that not just use /etc/os-release.. [09:57] pitti, because it's a logo/image not text [09:57] ohhh [09:57] wtf? :) [09:57] zyga, use unity ;-) [09:57] WTF indeed -- a logo for a version number? [09:58] pitti, the ubuntu circle on top of it is in the same image [09:58] seb128: I ususally do [09:58] seb128: I wanted to see what gnome looks like lately [09:59] pitti, but patches are welcome if you want to change that to be dynamic and align a logo for the circle and some text with the right styling bellow [09:59] it's just that nobody got to do that [09:59] (since trusty we generate the logo at buildtime at least) [10:00] oh [10:01] seb128: right, the ubuntu version seems to do just that? === vrruiz_ is now known as rvr [10:04] pitti, yes, darkxst_ said he was going to backport those changes to g-c-c === alkisg is now known as work_alkisg === work_alkisg is now known as alkisg [10:09] seb128, pitti yes I will try look at fixing that this weekend === gusnan_ is now known as gusnan [10:17] pitti: something is even more weird with adt though, e.g. dbus-test-runner migrated despite failing its test, and it's build-deps & build-essential are not installed whilst executing the test => but needed as it does compile tests. [10:18] xnox: who's the best person to talk to about CI loop failures? [10:18] xnox: I had strange failures that block packages that work out okay in debian [10:23] ohhh [10:26] ari-tczew: given the version number, it was simply done to force that rebuild into dep-wait & rebuild only after that one is rebuild. it's save to drop that change. Note however, i had to make a change to libzrtpcpp in unicorn and it is a valid one http://launchpadlibrarian.net/174142130/libzrtpcpp_2.0.0-3build2_2.0.0-3ubuntu1.diff.gz that is needed in debian as well. [10:28] xnox: are you going to merge that one? if not, I can do that. there are CVE fixes. [10:30] zyga: ci loop failures => ask on #ubuntu-release to start the conversation. [10:30] ari-tczew: i really should, and forward patch to debian to get it back into sync [10:31] xnox: ok so I'm leaving that one [10:33] xnox: thanks === MacSlow is now known as MacSlow|lunch [10:41] xnox: jibel has a fix for the premature promotion, but not rolled out yet === alkisg is now known as work_alkisg === darkxst_ is now known as darkxst [10:57] pitti, any idea why modemmanager is calling upstart's initclt script when try to upgrade? [10:57] (under systemd) [10:58] dpkg bug perhaps? [11:02] darkxst: yes, it's debian bug 683084 -- we need to merge sysvinit [11:02] Debian bug 683084 in sysv-rc "Make invoke-rc.d/update-rc.d systemd-aware" [Wishlist,Fixed] http://bugs.debian.org/683084 [11:02] darkxst: that's next on my list after I fix the "tar: unexpected EOF" breakage in autopkgtest's qemu runner [11:02] (as that's hampering production) [11:17] pitti, ok [11:31] ari-tczew: merge uploaded & change forwarded https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746655 [11:31] Debian bug 746655 in libzrtpcpp-dev "libzrtpcpp-dev: Missing dependency on libssl-dev" [Normal,Open] [11:34] ok [11:37] @pilot in === udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur === _salem is now known as salem_ === MacSlow|lunch is now known as MacSlow === bfiller_afk is now known as bfiller === pete-woods is now known as pete-woods-lunch [13:07] pitti: why am I getting emails from jenkins about failiures in https://jenkins.qa.ubuntu.com/job/utopic-adt-python-qt4/4/? :P === tedg` is now known as tedg [13:09] shadeslayer: because you did the last upload [13:09] I ... I did? [13:10] shadeslayer: I restarted the test btw; it's the same bug I'm trying to work around for two days now (argh old qemu) [13:10] aha, the silly encoding issue in python qt4 [13:10] shadeslayer: accordingto https://launchpad.net/ubuntu/+source/python-qt4/4.10.4+dfsg-1ubuntu1 ? [13:10] pitti: right :) [13:10] shadeslayer: nevertheless, not your fault (jibel and I also get all failure mails, I'm checking them all) [13:11] cheers! :) [13:21] bdmurray: got your email about kubuntu-driver-manager crashing, there have been 2 crashes, and both lack a stacktrace [13:21] pitti: the upstart jobs are not conffiles. the cgm_extra_mounts in the upstart job is the default, to be overridden by /etc/default/cgmanager, which is the conffile [13:22] pitti: yes cgmanager doesn't have manyd ependences, but other things depend on it (like lxc), and in particular the curious interaction is that between cgmanager and cgproxy... but ok i'll force myself to address it at some point [13:23] pitti: thanks for the pointers to systemd.unit and systemd.service [13:23] hallyn: yes, so I guess one should depend on the other then? [13:24] hallyn: I hope we can get rid of this stopping of cgproxy in cgmanager.conf and replace that with proper dependencies? [13:25] hallyn: they are conffiles, as they are in /etc/init/; but what I really meant is that we don't want to encourage users to edit them [13:26] pitti: not sure. the issue is that in a container we want only cgroxy to run; on a post-3.13 kernel host we want cgmanager only; on older kernels we want both cgmanager and cgproxy. [13:26] so in upstart we want to just have cgmanager be the thing you have to know about and it starts the right thing [13:26] yes we don't want people to edit them [13:26] hallyn: oh, so one doesn't depend on the other, they just have different startup conditions? [13:26] we want people to override them with /etc/default/ [13:27] no cgproxy does have to start after cgmanager, if they're both going to run [13:27] ah, "start on started cgmanager" [13:27] pitti: but in any case, *that* is a work item for a bit later, the more urgent thing for right now is to straighten out the session cgroups in containers in utopic [13:28] pitti: i just got up, gonna have some coffee, then set up a clean environment ot test in again. will you be around for another hour or two? [13:28] hallyn: I will, but today I'm still in firefighting mode, and thus I'm not in the mood of much else :/ [13:29] pitti: ok, np, i'll not bug you then :) shouldn't be too hard to find the root cause. have fun! er i mean, good luck! er i mean, ... \o [13:56] It's surprising how long a system can survive while not being able to exec any processes [13:57] I set an i386 LXC container to unconfined on my amd64 system, and tried to start it; it promptly installed the qemu-x86_64 binfmt handler and none of my ordinary binaries were executable [13:57] you know, i seem to recall seeing that a few years ago, but i forget why. [13:57] I had chroots around, but couldn't use sudo from them because LD_LIBRARY_PATH isn't allowed on setuid executables [13:57] if only we had a binfmt namespace :) [13:57] quite [13:57] I was able to escape without rebooting though [13:58] that might be worth a blog post with details [13:58] execute ssh from an i386 chroot (with LD_LIBRARY_PATH set appropriately) to connect to the container I'd just started, which of course was working fine [13:58] then sudo inside that and update-binfmts --disable qemu-x86_64 [13:59] it might be, although I just wasted half an hour on this instead of what I was supposed to be doing :) [13:59] yeah i have an insane fear of running containers unconfined [14:00] what I was actually trying to do was to be able to mount -o proc none $chroot/proc (etc.) inside the container [14:00] An unconfined container is not a container. [14:00] I don't care, in this case [14:00] well not much [14:01] I mean, in this instance I care that it broke my binfmt namespace :-), but I don't care about the security of the container right now [14:02] I guess I actually want lxc-container-default-with-nesting [14:03] ... except that doesn't work either [14:04] cjwatson: right it's only for nesting lxc. you want to generalize that one to allow mounting proc anywhere [14:04] i've considered having a menu-driven set of apparmor bits for the many things ppl might want to do... [14:05] do you happen to have an example lying around? [14:05] though -with-nesting and -with-mounting seem to usually do what ppl want [14:05] what I'm specifically doing is running launchpad-buildd in a container [14:06] cjwatson: http://paste.ubuntu.com/7379730/ should work... [14:06] which wants to run http://paste.ubuntu.com/7379736/ [14:07] cjwatson: eh, [14:07] I guess I need a few more bits; is it possible to just say "honestly I don't care for this container, let it mount anything anywhere"? [14:07] cjwatson: just add "mount,' to the profile [14:07] ok, great, thanks [14:07] cjwatson: http://paste.ubuntu.com/7379738/ [14:10] mount: proc is not a block device [14:10] or for "sudo mount -o proc none /path/to/proc": "mount: special device none does not exist" [14:13] hallyn: ^- that's with http://paste.ubuntu.com/7379780/ in /etc/apparmor.d/lxc/lxc-default-mount-anything, I ran "service apparmor reload", and http://paste.ubuntu.com/7379784/ in /var/lib/lxc/precise-lpdev/config - did I miss something? [14:16] shadeslayer: I'm looking into it, thanks === pete-woods-lunch is now known as pete-woods [14:17] bdmurray: cheers :) [14:18] MacSlow: I uploaded the utopic release upgrader now so once that hits the archive you will be able to upgrade - at last if the package startpar is installable then [14:18] cjwatson: hm, that looks ike it should work === paulliu1 is now known as paulliu [14:19] mvo, ok... thanks for the heads up [14:20] mvo: hi, have you seen bug 1310891? [14:20] bug 1310891 in ubuntu-release-upgrader (Ubuntu Trusty) "cached meta-release file should not be saved if it is html" [High,Triaged] https://launchpad.net/bugs/1310891 [14:20] stgraber: ^ any idea? [14:23] cjwatson: huh, worked for me [14:23] i did "stop lxc; start lxc" rather than apparmor reload, [14:24] I'll try that [14:26] hallyn: no, still the same thing - where could I look to debug this? [14:27] cjwatson: what does /proc/self/attr/current show in the container? [14:28] d'oh [14:28] cjwatson: mount -t proc, not mount -o proc :) [14:28] oh whoops [14:29] yeah, that's fine, sorry for the idiocy :) [14:29] phew :) sanity restored [14:29] (and "lxc-container-default-mount-anything (enforce)", FWIW) [14:33] bdmurray: good morning! let me check [14:34] bdmurray: yeah, totally agreeed, let me work on a fix [14:43] cjwatson: can you please do a full requeue on hdf5? [14:43] Logan_: you mean on package-import? [14:43] yeah [14:43] Logan_: don't have access, try xnox [14:43] ogra_: http://people.canonical.com/~cjwatson/tmp/lp-livefs-building.png - glorious success may be distantly visible from here [14:44] cjwatson: ah, apologies [14:44] wheee !!! [14:44] * ogra_ hugs cjwatson ... thats awesome !!!! [14:44] xnox: wanna do a full requeue on hdf5 for me? :) [14:44] still a fair bit of UI coding to go but it's definitely getting there now [14:44] yeah, looks great [14:45] Logan_: no, package-importer is stopped at the moment. [14:45] oh, really? [14:45] Logan_: due to utopic importing. [14:45] gotcha [14:45] Logan_: why else we would have 800 outstanding jobs? =) http://package-import.ubuntu.com/status/ [14:46] because UDD is broken? :P [14:46] Logan_: hm, actually it is running. [14:47] Logan_: right, it was started on the 28th. I'd rather wait for it to process backlog. [14:47] ok === roadmr is now known as roadmr_afk [15:15] stgraber: should liblxc1 be depending on (cgmanager | cgroup-lite) [15:15] bc i can't right now easily test with cgroup-lite... [15:15] also i suppose i should look into getting rid of cgroup-lite now that cgroupfs-mount (based on cgroup-lite) is in debian [15:19] hallyn: so I thought about doing that, but this would have had the side effect that anyone using libvirt or who already had LXC installed wouldn't get cgmanager [15:22] recommends? [15:22] Depends: (cgroup-lite | cgmanager) \n Recommends: cgmanager ? [15:28] mterry: I have to reopen bug 1315185; thanks for the initial fix! [15:28] bug 1315185 in deja-dup (Ubuntu) "pass in trusty, but fails ADT tests in utopic" [High,Confirmed] https://launchpad.net/bugs/1315185 [15:28] mterry: sorry, it seems adt-britney is horribly buggy ATM :( (we need jibel's fix rolled out) === salem_ is now known as _salem [15:30] pitti, guh [15:31] hallyn: that would probably do the trick, yes [15:32] hallyn: I'll do the update to the git packaging and do a daily build [15:33] cool, thanks [15:33] @pilot out === udevbot changed the topic of #ubuntu-devel to: Trusty Final 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 -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: [15:33] pitti, do we have a nice wiki page explaining the best way to run adt tests locally? [15:34] The proximate fix here is easy (add dbus-x11 as a test dep) but want to make sure that's all [15:36] https://wiki.ubuntu.com/QATeam/AutomatedTesting/AutoPackageTesting [15:37] I've been using http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test prepare-testbed / run-adt-test [15:37] but I found out earlier that this isn't always the same as what jenkins does [15:38] Laney: right, that changed since utopic, I need to get that updated [15:38] you mean the document or the behaviour of run-adt-test? [15:38] mterry: ^ [15:38] Laney: the document; run-adt-test is obsolete [15:38] ah [15:39] mterry, Laney: /usr/share/doc/autopkgtest/README.running-tests.gz is now the "official" documentation how to run stuff [15:39] shame, it was quite easy to use [15:39] Laney: yes, but run-adt-test had quite some limitations [15:39] I haven't grasped running adt-run directly properly yet [15:39] Laney: but the new one isn't really that difficult either [15:39] the biggest difficulty is that we don't yet have utopic cloud images [15:39] /current exists now [15:39] (but that would affect both the old and the new system) [15:40] ooh, does it? [15:40] nice! [15:40] yep! [15:40] so what's the way to set up a fresh VM with the new way? [15:40] so, something like [15:40] adt-buildvm-ubuntu-cloud -v -o /my/dir/for/VMs === roadmr_afk is now known as roadmr [15:41] you might need -r utopic if you are still on trusty [15:41] and optiionally -a i386 for selecting an arch [15:41] so [15:41] adt-buildvm-ubuntu-cloud -v -r utopic -a amd64 -o /my/dir/for/VMs [15:42] if you run apt-cacher-ng, this is also useful: -p http://10.0.2.2:3142 [15:42] and then [15:42] adt-run deja-dup --- qemu /my/dir/for/VMs/adt-utopic-amd64-cloud.img [15:42] Laney, mterry: ^ that's how jenkins does it now [15:43] Laney, mterry: but if your test doesn't need particular privileges, you can also test in a schroot (everyone has that, right?) [15:43] adt-run deja-dup --- schroot utopic [15:43] pitti, I got it -- I'm using chroot pointing at my pbuilder chroot [15:44] you can also test a local package, and have that built first, see README.running-tests.gz [15:44] stgraber: so should libpam-systemd:amd64 be all i need to have logins be placed into cgroups? [15:44] mterry: heh, that works, too [15:44] I tried with schroot and I think it had the same build-needed problem [15:44] (can that be?) [15:44] pitti, hey... so deja-dup has autopilot tests but I could never figure out how to get them working in adt... I assume that's gotten better? [15:45] mterry: nothing changed in that regard recently; but I wasn't aware that it isn't working [15:45] pitti: why did the dependencies changed? as in why are "build-essential & build-deps" are not kept for jobs that declare "needs-building" ? [15:45] well and libsystemd-login0:amd64 [15:45] mterry: have a look at shotwell: autopilot-sandbox-run autopilot_tests [15:45] pitti, uh.. I can't remember exact issue, but I think I just had some difficulty getting X and such to work in adt. But if shotwell does it, I can steal their harness [15:46] mterry: autopilot-sandbox-run does the gory details of what needs to happen with xvfb and dbus, so you mostly just need xvfb and dbus-x11 and autopilot-desktop [15:46] mterry: autopilot-sandbox-run is the harness, and it has existed for a long time now; but I guess it isn't well-known [15:46] mterry: and yes, it took us a whole afternoon to figure out, it's quite tricky with xvfb [15:47] pitti, No, I remember that. I had problems running it for some reason. Will re-examine since I'm futzing with it here [15:47] xnox: because we don't use the null runner any more, and each test/build gets a fresh VM [15:47] xnox: if you need the build depends in your test, you need to test-depend on @builddeps@ [15:48] pitti ah @builddeps@ is what i am after then! and that includes build-essential? [15:48] xnox: in fact, one of deja-dup or dbus-test-runner seemed to build the pacakge twice -- once with needs-build, and another time with "make' in the test [15:48] xnox: yes [15:48] pitti: right, indeed then needs-build can be dropped, and @builddeps@ be used. [15:48] Laney: ^ now we know. [15:48] I did know [15:48] Laney: i didn't =( =) [15:48] the thing I didn't know whas about the removal of build-deps from build-needed [15:48] but that is actually quite clear in the spec [15:49] xnox: ah, so it was dbus-test-runner apparently; right, should work without needs-build [15:49] it only does make check, not make [15:49] yeah, just with -null we couldn't enforce that [15:50] (and -null had quite a few more problems and also required this whole set of additionla scripts around it, which is why we wanted to abandon it) [15:50] I have a weird feeling it's testing the built tree though [15:50] pitti: are adt VMs running in US timezone or UTC? or no useful clock at all? [15:50] btw, I think I fixed the weird "tar: unexpected EOF" thing now, so tests should not fail any more due to that [15:51] xnox: let me check [15:51] xnox: it copies the host's timezone [15:51] alderamin: America/New_York [15:51] aldebaran: Etc/UTC [15:52] pitti: yeah, my job was on alderamin. [15:52] albali: Etc/UTC [15:52] wazn: Etc/UTC [15:52] but that "copy from host" behaviour hasn't changed [15:52] maybe the host timezones changed recently [15:53] xnox: if you need a particular one, it's probably best to export TZ= in your test? [15:54] hm, what's wrong with ubiquity!? [15:54] oh, uninstallable on amd64 [15:55] mterry, Laney: oh, for completeness: jenkins runs against -proposed, so if you want to do that, run "adt-run -U --apt-pocket=proposed --- ..." [15:55] hm, dholbach already offline [15:55] I'll see to catch him next week to get http://packaging.ubuntu.com/html/auto-pkg-test.html updated [15:56] I think that's auto deployed from the guide [15:56] in bzr [15:56] (is it?) [15:57] so uninstallable libtimezonemap1 seems to break quite a lot ATM [15:57] * pitti binNEWs it to put it out of its misery [15:58] pitti: no, i want job-logs and console-logs have sanity =) when i view the adt job artifacts. [15:58] pitti: which are comparable across different runners. [15:59] pitti: there is no reason to use New-York timezone =) on build slaves. [16:00] e.g. console ouput says - adt-run [2014-05-02 11:52:40]: version @devel@, yet jenkins job started at (02-May-2014 15:52:39) which is mildly hallarious =) [16:02] xnox: heh, yes; I'll create an RT to have it changed [16:05] Laney: i wonder if the test is now busted, and should actually just be "#!/bin/sh true" and just rely on needs-building, cause i bet the directory is not RW either. [16:05]