=== _salem is now known as salem_
=== salem_ is now known as _salem
[04:17] <pitti> Good morning
[04:26] <Unit193> Bye.
[06:02] <highvoltage> hmm, odd how thunderbird in 14.04 says 'Welcome to daily!', would probably be nicer with the usual welcome to thunderbird message in an lts release.
[06:03] <infinity> chrisccoulson: ^
[06:09] <micahg> highvoltage: it's actually an upstream issue
[06:11] <highvoltage> micahg: I believe it should be patched in Ubuntu since it will confuse users and may cause some alarm
[06:12] <micahg> highvoltage: that would take much longer, I'll see if I can poke upstream
[06:14] <micahg> it's not a code issue
[06:14] <highvoltage> micahg: cool :)
[06:18] <micahg> I poked, but not sure anyone is awake that this hour that can fix it
[06:23] <micahg> mozilla 1166040
[06:23] <ubottu> Mozilla bug 1166040 in General "31.7.0 start page not going to production start page. It goes to Daily page" [Normal,New] http://bugzilla.mozilla.org/show_bug.cgi?id=1166040
[06:38] <dholbach> good morning
[06:40] <micahg> highvoltage: someone will be looking at it shortly, I'm sure Chris can follow up when he comes online
[06:50] <seb128> hey dholbach
[06:56] <highvoltage> micahg: great
[07:12] <zyga> pitti: good morning
[07:13] <zyga> pitti: I was using adt-run to test qtbase-opensource-src-5.4.1+dfsg yesterday
[07:13] <zyga> pitti: and the only test that failed was
[07:13] <zyga> FAIL!  : tst_qstandardpaths::testRuntimeDirectory() '!runtimeDir.isEmpty()' returned FALSE. () Loc: [tst_qstandardpaths.cpp(411)]
[07:13] <zyga> pitti: does adt-run provide XDG_RUNTIME_DIR?
[07:14] <pitti> zyga: no, as there is no login involved, thus no pam and logind
[07:14] <pitti> so your test should probably set up a temp dir and set XDG_RUNTIME_DIR to it
[07:15] <pitti> s/probably//
[07:15] <zyga> pitti: well, it's just stock debian qt, I'm interested in patching it so I wanted to run tests on vainlla first
[07:15] <zyga> I wonder if it passes in debian
[07:16] <pitti> http://ci.debian.net/?q=qtbase-opensource-src
[07:16] <pitti> no result -- does it even have tests in Debian?
[07:16] <zyga> pitti: thanks!
[07:16] <zyga> pitti: ha, good question, let's see
[07:17] <zyga> pitti: ah, wait, those are not adt tests!
[07:17] <zyga> pitti: (the build ran overnight so I didn't check the full log)
[07:17] <zyga> pitti: just regular make check style tests
[07:17] <pitti> ah, it as needs-build and these are build time tests?
[07:17] <pitti> ack
[07:17] <pitti> same thing in buildds, no login/pam
[07:18] <zyga> hmmm
[07:18]  * zyga wonders how it gets built then :)
[07:18] <zyga> I built it in a vanilla sbuild for wily
[07:21] <zyga> Mirv: hey, I started looking at the story we talked about during ODS
[07:21] <zyga> Mirv: on building qt with prefix for /opt/something
[07:22] <zyga> Mirv: would you be so kind to rebuild qtbase-opensource-src without any patches and tell me if it fails on build-time tests (see above for FAIL that I see)
[07:30] <Mirv> zyga: you mean unit tests? yes it does fail, there was a huge work done originally to find out which tests pass on our builders. Debian doesn't have tests enabled in qtbase.
[07:30] <Mirv> zyga: see the enable_tests.patch in packaging.
[07:33] <zyga> Mirv: ah, that makes sense
[07:33] <zyga> Mirv: so what happens, how do we build it?
[07:33] <zyga> Mirv: if it fails here for me
[07:44] <Mirv> zyga: so it's built by selectively disabling the failing tests
[07:45] <zyga> Mirv: I still don't get it -- I buit the package straight from our archive
[07:45] <zyga> Mirv: so why do I hit the failing test
[07:45] <zyga> Mirv: is there something I'm missing?
[07:49] <Mirv> zyga: oh, you built yourself, locally? well, on a desktop Ubuntu a different set of tests fail than on builders.. because of environment differences and assumptions Qt makes
[07:50] <Mirv> zyga: the runtimedirectory sounds exactly like that
[07:50] <Mirv> zyga: the easy way out is an empty override_dh_auto_test:[C
[07:50] <Mirv> -[C
[07:50] <zyga> Mirv: I buit it in sbuild
[07:51] <zyga> Mirv: hmm
[07:51] <zyga> Mirv: yeah, I can disable tests, no problem
[07:51] <zyga> Mirv: I just wonder what else I might be missing from my environment
[08:01] <zyga> dholbach: thanks for sending that email
[08:01] <dholbach> anytime
[08:26] <seb128> mardy, hey
[08:26] <seb128> mardy, on my wily desktop I see saw warning, is that a known issue?
[08:26] <seb128> "signond[12379]: ../../../../src/signond/signondaemon.cpp 390 init Failed to SUID root. Secure storage will not be available."
[08:48] <mardy> seb128: oh, we should definitely remove that line... it's a leftover from MeeGo times (we don't run as root in Ubuntu)
[08:49] <seb128> mardy, k, I was trying to look at https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/1453549 ... I guess something changed on the facebook side
[08:49] <ubottu> Ubuntu bug 1453549 in shotwell (Ubuntu) "Cannot publish to Facebook" [High,Incomplete]
[08:55] <mardy> seb128: I'll have a look at it
[09:07] <seb128> mardy, thanks
=== dholbach_ is now known as dholbach
[10:30] <LocutusOfBorg1> ginggs, hi, you there?
[10:30] <LocutusOfBorg1> I opened a bug with debdiffs for vbox
=== _salem is now known as salem_
=== oSoMoN_ is now known as oSoMoN
[12:39] <rbasak> cyphermox: FYI, I'm lining up another grub2 SRU for Trusty: bug 1443735. I'll wait for your upload of 2.02~beta2-9ubuntu1.2 to clear first.
[12:39] <ubottu> bug 1443735 in grub2 (Ubuntu) "recordfail false positive causes headless servers to hang on boot by default" [High,Triaged] https://launchpad.net/bugs/1443735
[12:39] <cyphermox> rbasak: ack
[13:04] <cjwatson> apw: I filed bug 1456625 for the ability to set HEAD, which you requested a while ago; feel free to subscribe of course
[13:04] <ubottu> bug 1456625 in turnip "Can't set default branch ("HEAD") on a Git repository" [High,In progress] https://launchpad.net/bugs/1456625
[13:05] <apw> cjwatson, nice thanks, subbing
=== oSoMoN__ is now known as oSoMoN
[14:23] <barry> pitti: ping, re adt-build-lxc
[14:23] <pitti> hey barry
[14:24] <barry> pitti: hi.  i'm working on si adt failures.  two of my tests are isolation-container and i'm trying to build an lxc container for those tests on vivid.  should i be able to build a wily amd64 container on vivid?  it keeps failing for me
[14:25] <pitti> barry: I haven't tested it in this direction (I'm running wily and have trusty/vivid/wily containers), but there's no significant difference between v and w really
[14:25] <pitti> barry: what precisely fails for you?
[14:25] <barry> pitti: http://paste.debian.net/180374/
[14:26] <barry> pitti: yeah, i'm running wily on all but this one particular machine.  haven't upgraded it yet
[14:26] <pitti> /var/cache/lxc/wily/partial-amd64/debootstrap/debootstrap.log ?
[14:26] <pitti> barry: hm, I just landed a new util-linux, perhaps that broke stuff
[14:26] <pitti> the main change was that some binaries moved from sysvinit-utils to util-linux
[14:26] <pitti> barry: trying here..
[14:27] <barry> pitti: cool
[14:27] <barry> thx
[14:27] <pitti> barry: I mean, what does /var/cache/lxc/wily/partial-amd64/debootstrap/debootstrap.log say?
[14:27] <barry> pitti: yeah, that's the weird thing!  there's nothing in /var/cache/lxc/wily
[14:27] <pitti> ah, so perhaps lxc-create cleaned that up
[14:29] <barry> pitti: it'll be interesting to see if you can reproduce it.  i'm going afk to try this on my wily box
[14:29] <pitti> barry: it's running (but it takes a while)
[14:29] <pitti> barry: it'd really surprise me if that would depend on the host's release
[14:30] <pitti> http://people.canonical.com/~ubuntu-archive/priority-mismatches.txt doesn't look related (although I'll clean this up now)
[14:32] <pitti> $ sudo http_proxy=http://localhost:3142 debootstrap wily /tmp/wily
[14:32] <pitti> barry: ^ that reproduces it for me
[14:33] <pitti> and is muuuuch faster than lxc-create (due to tmpfs)
[14:33] <rbasak> pitti: is systemd-timesyncd supposed to be active by default now?
[14:33] <pitti> (the http_proxy is just to use apt-cacher-ng)
[14:33] <pitti> rbasak: yes, since vivid; unless you have ntpd, chrony, or another "big" ntp server installed
[14:33] <rbasak> pitti: what's the logic it uses to decide whether to be active or not (eg. if ntp server is installed)?
[14:34] <rbasak> pitti: I have an item to make NTP syncing default on server. I was planning to seed ntpd. Not sure whether that is necessary now.
[14:35] <pitti> rbasak: see /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
[14:35] <pitti> ConditionFileIsExecutable=!/usr/sbin/ntpd
[14:35] <pitti> ConditionFileIsExecutable=!/usr/sbin/openntpd
[14:35] <pitti> ConditionFileIsExecutable=!/usr/sbin/chronyd
[14:35] <rbasak> pitti: and should we change the default to s/debian.pool.ntp.org/ubuntu.pool.ntp.org/?
[14:35] <rbasak> pitti: I see - thanks.
[14:35] <pitti> rbasak: ^ basically that; that's rather simplistic of course, it'd be better to use Conflicts=; but that's only possible once these three get systemd units
[14:35] <rbasak> pitti: any opinion on ntpd by default? I guess systemd-timesyncd will suffice for the default server case then?
[14:36] <pitti> rbasak: timesyncd is simple and efficient for desktops; my gut feeling is that it should be just right for most cases where you don't care about manually configuring stuff
[14:36] <barry> pitti: by "reproduce" it means you're seeing the problem too?
[14:37] <pitti> rbasak: and once you do, I feel that an admin would explicitly pick something to install anyway
[14:37] <pitti> rbasak: but I don't have a strong opinion whether ntpd is a good default for a server, I'm not that familiar with it
[14:38] <pitti> rbasak: as for changing the default NTP server -- I'm not sure, maybe
[14:38] <pitti> barry: yes
[14:38] <rbasak> pitti: that sounds about right to me. Thanks.
[14:38] <barry> pitti: and the last dist-upgrade seems to have broken my wily machine's desktop.  i see the greeter and can log in but then never get to the desktop
[14:38] <barry> which of course may just be unrelated
[14:38] <rbasak> pitti: does timesyncd run all the time or is it one shot (i.e. is it ntp or ntpdate?)
[14:38] <barry> pitti: i'm going to go try to fix that, but ping me if i can gather any more information from you, or if you want me to file a bug
[14:40] <pitti> rbasak: hm, no idea about the broken dist-upgrade for you; I'll file a bug and investigate the broken debootstrap for now
[14:40] <rbasak> s/rbasak/barry/ ^^
[14:41] <pitti> rbasak: whoops, sorry :)
[14:41] <barry> pitti: cool, thanks
[14:42] <pitti> barry: filed bug 1456670
[14:42] <ubottu> bug 1456670 in util-linux (Ubuntu) "debootstrap failure: insserv: Service mountdevsubfs has to be enabled to start service hwclock" [High,In progress] https://launchpad.net/bugs/1456670
[14:44] <barry> pitti: thanks
=== larsu_ is now known as larsu
[15:11] <pitti> barry: I uploaded a new sysvinit which will hopefully fix this; I'm a bit stunnned about this, but there was only one change that really sticks out
[15:12] <barry> pitti: interesting!  i'll try to keep watch and update/try again in a bit
[15:16]  * barry now tries to verify that unity updates broke his wily desktop
[15:21] <pitti> barry: now I'm scared to reboot :)
[15:21]  * pitti does it anyway, the "unstable" experience!
[15:22] <pitti> barry: hm, all hunky-dory here, same boring "never breaks" as always..
[15:36] <barry> pitti: yeah, i'm having trouble narrowing it down.  *something* in the last dist-upgrade prevents my desktop coming up.  i thought i narrowed it down to unity but bisecting package installs (and installing just the unity related upgrades) doesn't seem to reproduce it.  fortunately this is a snapshotted disk so it's easy-ish (if tedious) to try each package by hand
[15:36] <cjwatson> pitti: latest util-linux has broken debootstrap, http://paste.ubuntu.com/11227070/
[15:37] <pitti> cjwatson: tracked in bug 1456670
[15:37] <ubottu> bug 1456670 in sysvinit (Ubuntu) "debootstrap failure: insserv: Service mountdevsubfs has to be enabled to start service hwclock" [High,In progress] https://launchpad.net/bugs/1456670
[15:37] <pitti> cjwatson: I uploaded https://launchpad.net/ubuntu/+source/sysvinit/2.88dsf-59.1ubuntu2 for now, which is the only change that looked substantial to debootstrap
[15:37] <pitti> I'm not 100% sure that this will be the fix, but this is so utterly hard to test with local packages..
[15:38] <cjwatson> pitti: oh, failure to read up on my part, sorry
[15:38] <cjwatson> rcj: ^-
[15:38] <rcj> cjwatson, thanks
=== tkamppeter_ is now known as tkamppeter
[15:49] <shadeslayer> rbasak: any news on the docker backport
=== matsubara_ is now known as matsubara
[15:50] <rbasak> shadeslayer: currently blocked on merging the apparmor delta.
[15:51] <shadeslayer> oh ok
[15:51] <shadeslayer> thanks
[15:51] <rbasak> shadeslayer: I've stuck all the dependencies in a PPA now, so you might be able to build the Debian source package for 1.6.1 unmodified against it now.
[15:51] <shadeslayer> rbasak: well, I wanted to use it locally on my machine :)
[15:51] <shadeslayer> on vivid
[15:52] <rbasak> shadeslayer: try sbuild with --extra-repository of my (racb) docker PPA on amd64 against Debian's 1.6.1. I think that may work.
[15:53] <rbasak> You'll be using upstream's apparmor profile then, instead of the standard Ubuntu one. That's something I don't want to regress, hence I'm blocked - but I think it'll work. You'll just end up with upstream's preference instead of Ubuntu/AppArmor upstream's preference.
[15:57] <shadeslayer> rbasak: roger :)
[16:05] <hallyn_> jodh: infinity: xnox: so does anyone remember of a good reason why libnih is built without --enable-threading?
[16:06] <hallyn_> it actually *only* makes __thread be #dfined to nothing when not set, so i can't see any possible safety advantage
[16:11] <xnox> hallyn_: because i believe upstart detects that and uses threads.
[16:11] <xnox> hallyn_: in practice i don't want any threads in upstart code when it is pid1
[16:11] <xnox> hallyn_: now that it's no longer pid1 in ubuntu, i'm happy to change libnih to be better suited for normal userspace programs and not as critical as pid1.
[16:14] <hallyn_> xnox: i dont' think libnih creates any threads with --enable-thrading.  it only marks some variables as __thread
[16:15] <hallyn_> but in any case - cool, it woudl def be nice to have in wily
[16:15] <hallyn_> also stgraber suggested adding a 'is-threading-enabled' check in libnih, so i may post a ptach for that
[16:15] <hallyn_> (though it's easy to check by hand anyway, but a helper would be appropriate)
[16:16] <hallyn_> (better yet would be enabling it on all releases :)
[16:29] <hallyn_> xnox: where should upstream libnih patches go these days?
[16:31] <xnox> hallyn_: so github.com/libnih/libnih is ubuntu-compatible thing with (hopefully) all ubuntu patches in place.
[16:31] <xnox> hallyn_: i can add you to that, or i'm happy to transfer it to linuxcontainer umbrella.
[16:31] <xnox> hallyn_: there is also keybuk/libnih which i tried to push things to from libnih/libnih but it has different license - gplv2 only.
[16:32] <hallyn_> xnox: cool i just want to post a patch to add a 'bool nih_threaded()' helper.  i'll post it for github.com/libnih/libnih and then we can cherrypick itno wily if not rejected outright
[16:32] <hallyn_> thanks
[16:32] <xnox> ok.
[16:33] <hallyn_> xnox: wait.  https://github.com/libnih/libnih no worky
[16:34] <xnox> hallyn_: horum, looks like i only have docs there.
[16:34] <xnox> there is https://github.com/keybuk/libnih
[16:34] <xnox> oh
[16:34] <xnox> https://github.com/xnox/libnih
[16:34] <xnox> and well lp:ubuntu/libnih
[16:35] <xnox> hallyn_: keybuk doesn't take fixes, and e.g. cgmanager will not work with keybuk's libnih
[16:35] <hallyn_> heh.  can i bless https://github.com/xnox/libnih as 'upstream' ?
[16:35] <xnox> hallyn_: submit there yes.
[16:35] <hallyn_> alright will do.  thx, ttyl
[16:35] <xnox> hallyn_: and as "upstream" i'll talk to "linuxcontainers" project to possibly include libnih/libnih org into their structure.
[16:36]  * xnox runs away for a bit
[16:36] <hallyn_> xnox: hah, sounds good.
[16:36] <xnox> hallyn_: btw, maybe it makes sense in ubuntu to compile two variants, -mt and normal.
[16:37] <hallyn_> xnox: i'm still not actually seeing where there can be any advantage to !--enable-threading.  The only thing it will do is break things at nih_err checking if the caller happens to use threads.
[16:38] <hallyn_> but i'll start with the detection fn and go from there
[17:00] <xnox> hallyn_: ok, cool.
=== pgraner is now known as pgraner-food
[18:19] <hzut> Hi - Please, let me know a good successor for emule?
=== Elimin8r is now known as Elimin8er
=== pgraner-food is now known as pgraner
[18:49] <pitti> barry, cjwatson: hm, that didn't help, debootstrap is still failing; need to investigate more closely tomorrow
[19:03] <barry> pitti: gotcha, thanks.  i finally narrowed down my wily problem to unity
[19:30] <hzut> Hi - Please, let me know a good successor for emule?
[19:30] <Unit193> I think you've mistaken this for a support channel, hzut?  I don't know what protocol they used, but there's gtk-gnutella.
=== tmpRAOF is now known as RAOF
[20:48] <ahasenack> hi guys, I have an apt-get crash/coredump file, easily reproduced
[20:49] <ahasenack> what package do I need to install so the core file has symbols?
[20:49] <ahasenack> it was recorded in /var/crash
[20:50]  * ahasenack installs apport-retrace
[21:08] <ahasenack> pitti: around?
=== tkamppeter_ is now known as tkamppeter
[23:31] <soren> Is there some way in which I can disable authentication for just a single repository?
[23:33] <soren> I have a tarball of packages + a Packages file. I trust it implicitly. I'd like to extract it locally, add that dir to my source.list and just trust it, but APT will complain it's not signed.
[23:33] <tarpman> soren: deb [trusted=yes] file:/... ought to do it
[23:33] <soren> Sweet!
[23:33] <soren> Let me try it!
[23:34] <tarpman> soren: personally I have http://paste.debian.net/180638/ saved as ~/bin/mkrepo ... pretty quick
[23:36] <soren> I *could* do that, but I'd be distributing the key over the same channel, so it's not really any safer than just saying that I implicitly trust the repo.
[23:36] <tarpman> :)
[23:36] <soren> Besides, it's only for testing. Once things are validated, they'll be built and signed properly.
[23:37] <soren> Doh, I can't test the trusted=yes thing, but looking at the docs, it certainly should work.
[23:37] <soren> tarpman: Thanks!
[23:37] <tarpman> np