[00:00] <smoser> http://paste.ubuntu.com/14691689/
[00:01] <smoser> but wily shows:
[00:01] <smoser> http://paste.ubuntu.com/14691702/
[00:02] <smoser> the key difference there is that its the 'standard^' seed that is getting irqbalance, not the tasksel 'Basic Ubuntu Server' or 'server'
[00:02] <smoser> nuclearbob, ^
[00:02] <smoser> i've not been successful getting it to dtrt
[00:02] <smoser> and i have to go
[00:08] <doko> pitti, the visp autopkg test are run against the release version of libzbar-dev and therefore fail. that doesn't sound correct
[00:11] <nuclearbob> smoser: dang
[00:44] <roaksoax-brb> pitti: howdy! I have a quick question. I have a debian/rules file with dh-systemd, where I'm passing: dh_systemd_enable, dh_installinit --no-start, dh_systemd_start --no-start , however, I see this in debian/rules: http://pastebin.ubuntu.com/14691933/, which is starting the service... is there a bug that you know of or am I doing something wrong?
[00:44] <roaksoax-brb> I see the pb in the .postinst*
[01:11] <smoser> cyphermox, i've filed bug 1539329
[01:12] <smoser> I'd appreciate your time to at least triage it to the right package
[01:15] <teward> who's the apport hooks expert?
[01:15] <teward> i keep forgetting who it is, but I could use some help debugging things
[01:17] <smoser> i'm sure that pitti knows some things about it, teward but i'm not sure if he's who you've worked with before.
[01:18] <sarnold> he's probably also a few more hours before he returns..
[01:19] <teward> i'll be asleep by then, it'll be a case where I'll have to intercept pitti then, because apport errored out on one Xenial bug
[01:19] <teward> and I mean errored out at the generic apport hooks
[01:19] <teward> didn't even get to nginx's hooks heh
[01:19] <teward> i think it was pitti who helped previously, too
[01:20] <teward> i'll just show up tomorrow morning and see if pitti's around, and see if they can help debug the issue i'm seeing in Xenial where it's not triggering the apport hooks in the package.
[01:20] <teward> thanks
[07:24] <pitti> doko: visp> for which package? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#zbar is meant to run against the released visp, for isolating -proposed packages against each other
[07:24] <pitti> doko: and http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#visp ran against the proposed version
[07:24] <pitti> doko: I can run zbar against the -proposed visp if that helps
[07:26] <pitti> roaksoax-brb: can you show me debian/rules for that? --no-start should indeed not do that
[07:26] <pitti> roaksoax-brb: I have a hunch what's wrong (we had a similar error in libvirt)
[07:27] <pitti> teward: it's more useful if you just directly ask what's wrong, avoids another day of roundtrip :)
[07:27] <pitti> teward: what's the particular error that you see?
[07:33] <doko> pitti, no, still run against 0.10+doc-10build2
[07:35] <pitti> Get:335 http://ftpmaster.internal/ubuntu xenial-proposed/universe amd64 libvisp-ar3.0 amd64 3.0.0-2build1 [29.7 kB]
[07:35] <doko> this visp pkgconfig file is crazy, recording the absolute library name
[07:35] <pitti> doko: in e. g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/v/visp/20160128_220555@/log.gz I see the -proposed version both for the source and the binaries ??
[07:36] <pitti> oh, you do mean against zbar
[07:36] <pitti> yes, it's mean to run against the released visp
[07:36] <pitti> or -proposed visp against released zbar
[07:36] <pitti> (as there are no dependencies which would force it otherwise
[07:36] <doko> but for the test to succeed it must run against the one in -proposed: https://launchpad.net/ubuntu/+source/zbar/0.10+doc-10ubuntu1
[07:37] <pitti> if they need to go in together, I can run them with both packages from -proposed
[07:37] <pitti> doko: ok, I started that
[07:37] <pitti> this is a case of "dependencies are not strict enough" (but meh)
[07:37] <doko> ta
[07:38] <doko> well, would a break in zbar help?
[07:39] <pitti> yes, that will do too
[07:39] <pitti> doko: not that we care much about partial upgrades, it just causes hitches like that with testing -proposde bits in isolation
[07:39] <pitti> doko: so I guess let's not worry too much for now -- this test run should succeed, and then all is good
[07:39] <doko> ok
[07:40]  * pitti toddles off to Brussels to the systemd hackfest, bbl
[07:40] <doko> me too
[07:40] <doko> just to Brussels
[08:20] <dholbach> good morning
[08:24] <seb128> doko, hey, do you plan to mp your multiarch changes to the proper vcs?
[08:25] <doko> seb128, have a wonderful morning. did you really check before starting with general complaints?
[08:26] <seb128> doko, shrug, it seems you pushed your update to the vcs but without using the vcs, e.g there was unreleased changes and you didn't include them in the release...
[08:26] <seb128> speaking about nautilus
[08:27] <doko> and for others I had to check in your very own non-checked in changes
[08:28] <doko> and please address your dep-waits for main
[08:28] <seb128> is there a page listing those?
[08:28] <seb128> dep-wait doesn't trigger any email afaik
[08:28] <doko> http://qa.ubuntuwire.com/ftbfs/ isn't that new
[08:29] <seb128> that's not only depwait
[08:29] <seb128> and there is no filter for "your own packages"
[09:05] <mpt> xnox, since you fixed the bug, I assume “I disagree” meant “I agree”. If so, yay. \o/
[10:02] <caribou> pitti: thanks! any reason why the ganeti tests are all failing ?
[10:02] <pitti> caribou: they are overridden; I don't remember what's broken with them, but not related to lvm
[10:02] <caribou> pitti: thought so, just wanted to confirm
[10:02] <pitti> caribou: oh, it migrated, good
[10:03] <caribou> pitti: next time I won't wait so long before asking
[10:27] <infinity> Laney: Is it possible that https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1521302 is gnome-terminal's fault, not unity?
[10:33] <LocutusOfBorg> hi folks, can anybody pretty please
[10:34] <LocutusOfBorg> "syncpackage libnatpmp --force"
[10:34] <LocutusOfBorg> it is in main
[10:34] <LocutusOfBorg> mapreri, ^^^
[10:35] <jemadux> in ubuntu devel , nautilus has both buttons on global bar and his own window ?
[10:35] <infinity> LocutusOfBorg: Will do.
[10:35] <LocutusOfBorg> <3 infinity
[10:35] <LocutusOfBorg> please give also mapreri the -s switch
[10:35] <LocutusOfBorg> he asked me to do it
[10:36] <infinity> LocutusOfBorg: Oh.  Too late.
[10:36] <LocutusOfBorg> no problem :)
[10:36] <LocutusOfBorg> Laney, I'm gonna sync herwig++ soon I think
[10:39] <LocutusOfBorg> same for gjay
[10:44] <LocutusOfBorg> mapreri, for marble I already did the change in ubuntu a few days ago
[10:45] <LocutusOfBorg> everything is syncd, thanks for merging the ubuntu work in debian
[10:46] <Saviq> popey, hey, so I've been trying to restart http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#mir but it says I can't upload, so I can't "use this service", what badges would I need to earn to be able to use this?
[10:46] <Saviq> OTOH this looks like a real fail :/
[10:47] <popey> I have no idea.
[10:47] <popey> dholbach, ^ any idea?
[10:47] <popey> looks like a motu thing
[10:48] <LocutusOfBorg> You submitted an invalid request: You are not allowed to upload qtmir or mir to Ubuntu, thus you are not allowed to use this service.
[10:48] <LocutusOfBorg> nope, I'm MOTU and I couldn't do it
[10:48] <LocutusOfBorg> core-dev can I think
[10:48] <Saviq> sounds like it
[10:49] <LocutusOfBorg> mir is in main, I guess only core-devs can retry builds
[10:49] <Saviq> popey, on another note, those regressions are there for a version of qtmir previous to what just got uploaded to proposed from the same silo along with the mir that triggered them...
[10:49]  * Saviq not sure where the chicken'n'egg thing broke
[10:49] <LocutusOfBorg> so you need somebody that retries the testsuite against the proposed version?
[10:51] <Saviq> yeah, well, I'd have expected that to happen automagically
[10:52] <LocutusOfBorg> nope, but did I already bothered infinity today? ^^^ :)
[10:54] <infinity> LocutusOfBorg: Literally anyone with upload rights for the package.
[10:54] <infinity> Saviq: ^
[10:55] <LocutusOfBorg> :D
[10:55] <Saviq> right, but what does that actually mean :)
[10:55] <infinity> It means exactly what I typed?
[10:55] <infinity> People who can upload the package to Ubuntu.
[10:55] <infinity> Note that "using a silo as a backdoor" doesn't count.
[10:56] <Saviq> ok, so not me, will have to work on that
[10:56] <Saviq> infinity, can I ask for the qtmir{,-gles} regressions triggered by mir be restarted for the qtmir{,-gles} versions that are there in proposed, please?
[10:56] <infinity> Anyhow, retried them all for you.
[10:56] <Saviq> oh thanks
[10:57] <infinity> Oh.  You want them as a set?  That's more complicated.
[10:57] <infinity> britney intentionally doesn't do that by default.
[10:58] <infinity> Saviq: Do you have appropriate Breaks in place to note that the new mir doesn't work with old qtmir?
[10:59] <Saviq> infinity, no, only Build-Depends
[10:59] <Saviq> infinity, and well, for binaries, whatever dpkg finds
[10:59] <infinity> Saviq: So, binary upgrades *could* be partial, and britney's test is entirely valid by saying "you let me install these two together, and they don't work".
[11:01] <infinity> Although, that failure doesn't look binary related at all, it's source..
[11:01] <Saviq> infinity, I think this behaviour change and our dummy "does qtmir build still" autopkgtest makes no sense now
[11:01] <Saviq> it's very likely we're doing something wrong there
[11:02] <infinity> Saviq: A "does it build" autopkgtest never makes sense, really, unless you're testing a toolchain, or that's literally the only way you can run a testsuite.
[11:02] <infinity> Saviq: Given that you just built it, you're testing that it still builds a few hours later.
[11:03] <Saviq> infinity, well, the point was that if a dependency of qtmir is going into proposed, we'd know if it broke its build
[11:03] <infinity> Saviq: However, this also highlights that your build-deps are probably wrong.
[11:03] <infinity> Saviq: If they need to be versioned and aren't, we can't read your mind.
[11:03] <Saviq> infinity, well, yeah, they are versioned, but with >=, not ==
[11:03] <infinity> Saviq: Oh, indeed.  It's the old source failing.  Derp.
[11:04] <infinity> Saviq: Sorry, brain not entirely on.
[11:04] <Saviq> yeah I was thinking you shouldn't be here yet
[11:04] <infinity> Saviq: Anyhow, autopkgtest is meant to be a test of binaries, not source.  We do rebuild tests and the like for source regressions.
[11:04]  * popey tucks infinity back into bed
[11:05] <infinity> Saviq: Obviously, we do source tests for compilers and such, cause how else do you test a compiler, but if every package in the archive tested rebuilding itself anytime a dep was uploaded, we'd be setting a lot more computers on fire.
[11:06] <Saviq> infinity, agreed, we'll be dropping that test from there soon, then
[11:08] <Saviq> infinity, so here's a related question - for unity8's autopkgtest we need some mocks that have no use anywhere else, we've been building those (and the test binaries themselves) during autopkgtest, should we package all those up instead after all?
[11:09] <Saviq> that felt like a waste of archive to some extent
[11:10] <infinity> Saviq: Nothing wrong with packaging them up in mir-tests or something and making your tests pull them in.
[11:12] <Saviq> infinity, ack, thanks
[11:13] <infinity> Or unity8-tests or whatever.  I can't read. ;)
[11:39] <cjwatson> pitti: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/h/haskell-hoogle/20160129_083554@/log.gz - not the friendliest response to this from haddock, but is HOME meant to be entirely unset here?
[11:42] <cjwatson> pitti: (I think this has started failing in Debian too, not obviously related to any change in the packages under test that I can see)
[11:48] <jamespage> pitti, hey - just hit a problem with lvm2 upgrades: https://launchpad.net/bugs/1539546
[11:49] <jamespage> pitti, the systemd package is masking that job - when the lvm2 maintainer script tries to update-rc.d, it throws that problem
[11:49] <jamespage> any ideas? correct that its masked? do we need to tweak lvm2 to not require that to be enabled....
[11:59] <infinity> cjwatson: I think a postinst wanting HOME is a bit sketchy.  But I guess if it's readonly to pick up a user prefs file or something, the fault lies in not catching it.
[12:00] <infinity> cjwatson: Unless POSIX says HOME must always be set, but I'm betting it doesn't.
[13:15] <pitti> jamespage: hey
[13:15] <pitti> jamespage: this looks like fallout from the update-rc.d breakage
[13:15] <pitti> jamespage: it should have been fixed by yesterday morning's init-system-helpers
[13:16] <pitti> cjwatson: tests set $HOME, but this is the apt-get install
[13:16] <pitti> cjwatson: what would $HOME be there, /root?
[13:16] <infinity> pitti: Usually, yeah.
[13:17] <pitti> cjwatson: first time someone reported that; if that's legitimate (I think it's not), I can set it to /tmp or /root or so
[13:17] <ricotz> rharper, hi, fyi, libnl3 3.2.21-1ubuntu1 breaks network-manager causing it to crash
[13:17] <infinity> But I don't think apt or dpkg should rely on being run in a login session, which implies postinsts shouldn't, which implies that anything run in a postinst shouldn't.
[13:17] <pitti> jamespage: the masking is correct, it was just insserv not seeing the /etc/rcS.d/S04mountdevsubfs.sh symlink
[13:21] <teward> pitti: are there any Xenial bugs against the general Ubuntu apport hooks at all?  Seeing a HookError failure on one of the bugs that landed on my radar, not sure whether it completely errored and that's why it didn't execute the package specific hooks, or whether something else is going on...
[13:21] <cjwatson> infinity,pitti: Yeah, possibly I should look at working around this in ghc-doc or something
[13:26] <infinity> cjwatson: Or haddock itself.  If it's trying to read a user prefs file (I'm assuming?), it must already have a test for if it exists, it probably just needs to wrap that in a test for HOME being set.
[13:33] <cjwatson> infinity: Yeah but I was hoping not to have to change the actual Haskell code :P
[13:35] <infinity>   -- getAppUserDataDirectory can fail (e.g. if $HOME isn't set)
[13:35] <infinity>   e_appdir <- tryIO $ getAppUserDataDirectory "ghc"
[13:36] <infinity> Looks like this is worked around in some places, but not all?
[13:37] <infinity> Or just worked around poorly.
[13:45] <Celphish> Elo! Just popped in to say that I'm really happy with how Ubuntu works on my work-laptop atm and I'm really impressed that it can handle everything I can throw at it without too much Hassle :)
[13:47] <Saviq> didrocks, hey, can you please add lukas-kde to ~ci-train-users? also, is it on purpose you still own that team?
[14:12] <roaksoax-brb> pitti: http://pastebin.com/iwr9xsNi
[14:14] <pitti> roaksoax-brb: yes, what I thought; in an override of dh_foo you must not call any dh_* commands other than dh_foo
[14:14] <pitti> roaksoax-brb: so your override_dh_install currently calls dh_systemd_start, and then the default debhelper dh_systemd_start runs without arguments
[14:14] <pitti> roaksoax-brb: so, move the dh_systemd* out of override_dh_install into override_dh_{enable,start}
[14:16] <roaksoax-brb> pitti: what about the requirement where dh_systemd_enable needs to go before dh_instaliinit, and override_dh_start after it ?
[14:17] <roaksoax-brb> pitti: or is that no longer the case, as in, i no longer need dh_installinit
[14:17] <cjwatson> Surely that's already handled by the default sequencing
[14:17] <cjwatson> insert_before("dh_installinit", "dh_systemd_enable");
[14:17] <cjwatson> insert_after("dh_installinit", "dh_systemd_start");
[14:17] <cjwatson> in /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm
[14:18] <roaksoax-brb> cjwatson: ah nice! ok cool! thanks!
[14:18] <roaksoax-brb> pitti: thank you!
[14:20] <pitti> roaksoax-brb: yw! it's a bit of a subtle trap indeed, two weeks ago I debugged that with hallyn on libvirt (and then it took considerably longer :) )
[14:21] <roaksoax-brb> hehe :)
[14:23] <caribou> is there someone from the backport team who could  help me with LP: #1494141
[14:23] <caribou> this has been fixed everywhere but for Trusty-backports
[14:33] <rharper> ricotz: hi; thanks;  saw a bug report as well; reproduced and looking at a fix right now;  I've updated the bug: https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1511735
[14:34] <ricotz> rharper, thanks, make sure it doesn't leave -proposed ;)
[14:34] <ricotz> aka "verification-done" is not a good idea yet
[14:34] <rharper> yep, updated the tag
[14:35] <rharper> the 6wind folks added that but don't have NM on their tests;
[15:07] <Saviq> infinity, hrm a simple re-run won't work then, will it? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mir
[15:07] <kgunn> hey there, i was happily working with lxd/lxc sometime ago....and just yesterday had need to work with it again
[15:07] <kgunn> ran into this
[15:07] <kgunn> https://pastebin.canonical.com/148727/
[15:07] <rharper> ricotz: I've tested a fix, filed bug 1539634 for the NM side;
[15:08] <kgunn> it could very well be me, but just in case...any ideas?
[15:09] <Saviq> infinity, so unless you have a way to make it re-run with qtmir from proposed, we might need to force it through (you can see just below that the new version is fine - pulled new mir in by way of autodeps and bumped build-depends)
[15:12] <ancaemanuel> the new glibc https://tracker.debian.org/pkg/glibc https://www.sourceware.org/ml/libc-alpha/2015-08/msg00609.html was going for wily release but for some regression is not.
[15:15] <ancaemanuel> somebody promised that we will have the latest version "next week"
[15:17] <ancaemanuel> "next week" is now and we do not have any new version.
[15:24] <ancaemanuel> remember that we have an feature freeze on 18 february, less than 20 days from now
[15:31] <infinity> ancaemanuel: I'm well aware.
[15:31] <kgunn> hmmm,blowing everything away, starting over seemed to solve my problem
[15:38] <bdmurray> pitti: Can you bump the version of ubuntu-release-upgrader in your britney hint?
[15:40] <tedg> Yesterday I upgraded to Xenial, now witih a 4.3 kernel my computer doesn't think it has a touchpad. Trying to figure out what's up, welcome ideas :-)
[15:43] <infinity> tedg: A) What kind of computer, B) Try the 4.4 kernel from -proposed before filing a bug, C) file a bug. :)
[15:44] <infinity> tedg: D) Check settings->Mouse&Touchpad to make sure it's not disabled in userspace.
[15:46] <ogra_> tedg, so the thinkpad nipple addicts finally won !
[15:50] <tedg> infinity: XPS 13, a couple generations old. I think it's a PS/2 touchpad though.
[15:58] <ricotz> rharper, thanks
[16:01] <cjwatson> infinity,pitti: All right, https://anonscm.debian.org/cgit/pkg-haskell/DHG_packages.git/commit/?id=e03850adc13e0887e3e45f666b05b4be1e4f5b8d should fix Haskell's autopkgtest woes.
[16:01] <cjwatson> Fingers crossed.
[16:13] <tedg> Nope, same with 4.4
[16:47] <sil2100> Saviq: hey! I can add someone to the ci-train-users team if needed
[16:48] <LocutusOfBorg> sil2100, me me me :)
[16:48] <LocutusOfBorg> I'm not a core-dev, but I usually look at the transition page, and I really would like to be able to retry testsuite failures
[16:53] <sil2100> LocutusOfBorg: ah, members of this team don't have such power IIRC ;)
[16:53] <sil2100> LocutusOfBorg: the ci-train-users are those that can fill silos and do landings through the train
[16:55] <LocutusOfBorg> oh, I don't even understand what does it mean :)
[16:55] <LocutusOfBorg> so don't care ;)
[16:56] <superm1> tedg: can you get the model number (eg 9343, 9333, 9350)?  I might be able to give you some pointer on what touchpad was in there that might aide in you tracking down what happened in 4.3 that broke it
[16:57] <superm1> but really filing a kernel bug might be best to get dmesg, lsinput and all that various stuff included for the kernel guys to track down further too
[17:02] <sil2100> Saviq: lukas-kde was that, right?
[17:02] <sil2100> Saviq: adding
[17:38] <pitti> cjwatson: yay thanks
[18:15] <slangasek> hallyn: any objections to me merging slof?
[18:17] <hallyn> slangasek: no i had my heart set on it!
[18:17] <hallyn> j/k - no objections ,thanks :)
[18:17] <slangasek> :)
[18:42] <slangasek> hallyn: good news, I've adjusted the cross-compiling support for slof to something that should be upstreamable to Debian
[18:45] <hallyn> slangasek: cool
[18:46] <slangasek> hallyn: bad news, the Debian git repo is out of date ;P
[19:03] <hallyn> wrt the Debian pkg?
[19:03] <hallyn> odd
[19:47] <rsalveti> pitti: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=813141 (had that when updating just the systemd package)
[23:09] <teward> I'm doing some server ISO tests, and I noticed that the 'manual package selection' item in Tasksel during the installer doesn't operate - in older ISOs, it launches aptitude to allow for package selection, but it does nothing on the dailies, is this a known issue?
[23:09] <teward> oops bleh wrong channel
[23:09]  * teward kicks his laptop
[23:09] <teward> (evil touchpad is evil)
[23:12] <sarnold> not dselect? man kids these days getting  soft. in my day we had dselect and we were happy to have it! both ways uphill in the snow!
[23:13] <teward> sarnold: i actually couldn't tell what it launched
[23:13] <teward> looked a little like aptitude to me in 14.04 but I may be wrong
[23:13] <teward> in either case, it does nothing on the dailies