[04:13] <Pharaoh_Atem> rbasak: ping
[04:43] <Pharaoh_Atem> rbasak: I've sent you an email with patches and a plea for help :/
[06:11] <ScottK> tsimonq2: Congratulations on membership.
[06:59] <pitti> Good morning
[06:59] <Unit193> Howdy.
[07:03] <pitti> cjwatson: this is testing PPA + overlay + xenial-proposed; apt's ProblemResolver list in there is rather long (starting with libjsoncpp0v5); supposedly either something in -proposed breaks it or it doesn't have strong enough dependencies; I'll have a closer look
[07:06] <pitti> smb: err no, that sounds really strange; try with -s, shell in, and see what happens in detail?
[07:06] <pitti> roaksoax: are there maybe more entries in the .postinst which do something to rackd.service again? does it get run on install, maybe there's a short-circuit?
[07:07] <pitti> smb: /usr/share/zoneinfo/UTC was wrong?? erk; on my system it's a symlink to "Zulu"
[07:07] <pitti> smb: and that's what's in the .deb too
[08:02] <smb> pitti, Yeah its misleading as Zulu has various meanings. But one is UTC
[08:03] <smb> pitti, It was wrong when I used the downloaded image directly with kvm, so I guess something in the generating of it went wrong
[08:04] <smb> pitti, So the link was there as well but the Zulu file was different to what the pkg is installing
[08:31] <pitti> smb: i. e. there's something weird in the cloud image build process?
[08:31] <pitti> smb: seems fine in today's amd64 image at least
[08:32] <smb> pitti, Maybe a one off. It was ok at the start of last week, then broken for about the second half. I had not yet looked again
[08:32] <pitti> smb: oh, wait -- maybe this?
[08:32] <pitti> $ cat /etc/timezone
[08:32] <pitti> Europe/Berlin
[08:32] <pitti> $ ls -l /etc/localtime
[08:32] <pitti> lrwxrwxrwx 1 root root 27 Feb  5 15:17 /etc/localtime -> /usr/share/zoneinfo/Etc/UTC
[08:32] <pitti> this is indeed inconsistent
[08:32] <pitti> and sounds like some cloud-init bug
[08:32] <smb> Might be a result of cloud-init though
[08:33] <pitti> $ TZ=UTC date
[08:33] <pitti> Mon Feb  8 09:31:39 CET 2016
[08:33] <pitti> ah, yeah
[08:33] <smb> Not sure what is normal there
[08:33] <pitti> that seems to confuse date somehow
[08:33] <pitti> smb: well, /etc/timezone and /etc/localtime should certainly agree
[08:33] <pitti> /etc/timezone is a Debianism
[08:33] <pitti> it should ideally be dropped at some point, as it's redundant with the /etc/localtime link
[08:33] <smb> pitti, I'd check the /usr/hsare/zoneinfo/zulu file
[08:34] <smb> when I looked it was rather largeish and had CET info in (when you check with strings/less
[08:34] <smb> The correct file is only a few bytes iirc
[08:35] <pitti> -rw-r--r-- 1 root root 127 Jan 30 00:13 /usr/share/zoneinfo/Zulu
[08:35] <pitti> ^ on my host
[08:35] <pitti> -rw-r--r-- 1 root root 2335 Feb  7 09:53 /usr/share/zoneinfo/Zulu
[08:35] <pitti> ^ on cloud image
[08:35] <pitti> whoa
[08:35] <smb> pitti, excactly
[08:35] <smb> pitti, and that goes away if one reinstalls tzdata
[08:36] <pitti> smb: indeed, that looks like a grave bug in cloud-init or the image build process
[08:36] <pitti> smb: can you please file that against cloud-init for now and ask utlemming/smoser about it?
[08:36] <smb> pitti, Probably rarely observed, Just that libvirt has a build test that verifies that the time offset of UTC is 0...
[08:37] <smb> pitti, ok will do
[08:37] <pitti> smb: I'm downloading today's cloud init and will dissect it with directly mounting it, to see if it's already broken in the image or at first boot
[08:38] <smb> pitti, ok. awsome
[08:46] <smb> pitti, fyi, I created bug 1543025
[08:46] <ubottu> bug 1543025 in cloud-init (Ubuntu) "Wrong UTC zoneinfo in cloud-images" [Undecided,New] https://launchpad.net/bugs/1543025
[08:48] <seb128> hum, lightdm is getting some reports of package install issues with that error
[08:48] <seb128> "insserv: Service dbus has to be enabled to start service lightdm
[08:48] <seb128> insserv: exiting now!
[08:48] <seb128> update-rc.d: error: insserv rejected the script header"
[09:02] <pitti> smb: hm, kpartx is acting up, but the .squashfs is correct
[09:02] <pitti> smb: so for now my gut feeling is cloud-init
[09:03] <seb128> doko, good morning! could you have a look to bug #1542747?
[09:03] <ubottu> bug 1542747 in telepathy-mission-control-5 (Ubuntu) "Empathy stop working with accounts setup with GOA after last telepathy update" [High,New] https://launchpad.net/bugs/1542747
[09:03] <seb128> your multiarch upload changed the plugins location it seems
[09:03] <smb> pitti, Ok, so that sounds like its messed up during the config phase... yes
[09:03] <seb128> the rules had
[09:03] <seb128> "# We specifically do not want multiarch: only one version of MC can be
[09:03] <seb128> # installed anyway, the plugin directory is based on the ${libdir}, and
[09:03] <seb128> # empathy/experimental ships a plugin in the non-multiarch location
[09:03] <seb128> CONFIGURE_FLAGS += --libdir=\$${prefix}/lib"
[09:03] <pitti> l
[09:03] <seb128> it seems like the debian maintainer specifically decided to not multiarch ... shouldn't we do the same?
[09:07] <dholbach> good morning
[09:07] <seb128> hey dholbach!
[09:07] <dholbach> salut seb128
[09:11] <pitti> smb, smoser, utlemming: I think I found the culprit in cloud-init, I updated bug 1543025
[09:11] <ubottu> bug 1543025 in cloud-init (Ubuntu Xenial) "Wrong UTC zoneinfo in cloud-images" [High,Triaged] https://launchpad.net/bugs/1543025
[09:12] <smb> pitti, Ah good catch
[09:48] <seb128> hum, is https://errors.ubuntu.com/ loading for others?
[09:49] <seb128> the list stays on loading for a while and returns an error here
[09:49] <pitti> still at "Loading..." here
[09:49] <seb128> oh, loaded this time
[09:49] <pitti> seb128: oh, it loaded now
[09:50] <seb128> pitti, yeah, same here, thanks for testing!
[09:50] <pitti> Mirv: bug 1542239 fixed if you want to check
[09:50] <ubottu> bug 1542239 in Auto Package Testing "Unable to run some retries" [Low,Fix released] https://launchpad.net/bugs/1542239
[09:50] <seb128> pitti, do you know about that "update-rc.d: error: insserv rejected the script header"" that impacts lightdm?
[09:50] <seb128> https://errors.ubuntu.com/problem/14b7d70c74b6a386bf9677234a61bb0265f97886
[09:51] <pitti> no, I don't -- what does insserv complain about?
[09:51] <seb128> dunno, what I copied is what is in the log
[09:51] <seb128> "insserv: Service dbus has to be enabled to start service lightdm
[09:51] <seb128>  insserv: exiting now!
[09:51] <seb128>  update-rc.d: error: insserv rejected the script header"
[09:52] <pitti> sudo /usr/lib/insserv/insserv --verbose --dry-run
[09:52] <pitti> ?
[09:52] <pitti> ah
[09:52] <pitti> so, dbus is disabled
[09:52] <seb128> well, I would have to have the issue locally to be able to run debug commands...
[09:52] <pitti> well that then
[09:52] <seb128> lightdm and insserv didn't change recently
[09:52] <seb128> I wonder why that started being an issue
[09:52] <Mirv> pitti: hmm, still getting the same message, do you think the fix is fully deployed?
[09:53] <pitti> Mirv: it should be
[09:53] <Mirv> pitti: ok, I reopened the bug now at least
[09:54] <pitti> Mirv: ok, then I need you to interactively debug this with me, as that was the only wrong thing that I saw
[09:54]  * pitti enables some debug logging
[09:55] <Mirv> pitti: ok. I don't see a logic yet - qtcreator-plugin-ubuntu and rocs fail (from under qtdeclarative-opensource-src-gles), but unity8 succeeds. all of them are in universe.
[09:55] <pitti> ERROR:root:https://api.launchpad.net/1.0/ubuntu/+archive/primary?person=https%3A%2F%2Fapi.launchpad.net%2F1.0%2F%7Etimo-jyrinki&sourcepackagename=qtdeclarative-opensource-src-gles&ws.op=checkUpload&component=main&pocket=Proposed&distroseries=https%3A%2F%2Fapi.launchpad.net%2F1.0%2Fubuntu%2Fxenial failed with 403: Forbidden
[09:55] <xnox> pitti, is there systemd-tmpfiles sysv service running on kfreebsd/hurd on debian?
[09:55] <pitti> ah, so that's still wrong -- component=main
[09:55] <Mirv> although there is a difference that in addition to MOTU I have PPU rights to unity8
[09:55] <pitti> xnox: nope
[09:55] <xnox> pitti, =((((((
[09:56] <pitti> xnox: someone proposed to reimplement some parts of the specification, but it's not in Debian yet
[09:56] <xnox> pitti, i wonder if just that can like simply compile on kfreebsd.
[09:56] <pitti> xnox: no, it won't
[09:56] <xnox> ditto e.g. like sysusers, etc.
[09:56] <xnox> =(
[09:57] <pitti> well, someone could take the source, rip out all the linux specific bits etc., and make that build
[09:57] <pitti> but that's not trivial
[09:58] <pitti> Mirv: hit that URL again, please?
[10:00] <pitti> Mirv: yep, as it's using &component=main -- as you have PPU, the component doesn't matter for LP
[10:00] <pitti> Mirv: i. e. the determination  of the component is still wrong
[10:00] <pitti> Mirv: oh, crap, I see it, nevermind
[10:09] <pitti> Mirv: ok, please try again
[10:11] <Mirv> pitti: works now!
[10:11] <pitti> great
[10:22] <Saviq> pitti, hey, after an update of init-system-helpers, ofono fails to install with "invoke-rc.d: unknown initscript, /etc/init.d/ofono not found."
[10:22] <Saviq> or at least I think that's the cause
[10:22] <pitti> Saviq: which version did you upgrade from?
[10:23] <Saviq> pitti, not upgrade, builders fails to install ofono https://launchpadlibrarian.net/236956211/buildlog_ubuntu-xenial-amd64.unity8_8.11+16.04.20160208-0ubuntu1_BUILDING.txt.gz
[10:23] <pitti> Saviq: ok; can you please file a bug with the URLs?
[10:23] <pitti> I'll look ASAP
[10:23] <Saviq> pitti, thanks
=== vrruiz_ is now known as rvr
[10:24] <pete-woods> hi folks, I'm looking for some assistance in landing (https://code.launchpad.net/~pete-woods/ubuntu/xenial/libgcrypt20/disable-arm-asm-rijndael) into xenial+vivid overlay. it's not a train-managed package, so I don't know how to land it
[10:24] <pete-woods> was hoping a friendly archive admin or such like could help me out
[10:24] <pete-woods> (it's a simple branch that disables some broken ARM assembler for AES in libgcrypt, falling back to C code)
[10:25] <pete-woods> without it, the keyring crashes on the phone
[10:25] <pete-woods> I've linked it to branches, reported the bug upstream, etc
[10:25] <seb128> pete-woods, hey, #ubuntu-ci-eng might be a better place to ask about overlay landings
[10:26] <pete-woods> seb128: okay, thanks will head over there
[10:31] <Saviq> pitti, bug #1543051, looks like it ignored invalid initscripts before, now it bails out
[10:31] <ubottu> bug 1543051 in init-system-helpers (Ubuntu) "New helpers version fail on "unknown initscript"" [Undecided,New] https://launchpad.net/bugs/1543051
[10:32] <pitti> cjwatson: that was another example of bug 1541334; I deployed the fix now, test is green now
[10:32] <ubottu> bug 1541334 in autopkgtest (Ubuntu) "Do not run silo tests against all of -proposed" [Undecided,Fix released] https://launchpad.net/bugs/1541334
[10:32] <pitti> Saviq: thanks
[10:38] <cjwatson> pitti: ah, great, thanks
[11:22] <pitti> infinity, cjwatson: wow, we still don't have a proper xenial buildd chroot? http://launchpadlibrarian.net/222053869/chroot-ubuntu-xenial-amd64.tar.bz2 is allegedly the current one, but has wily deb sources and pakcage versions
[11:39] <cjwatson> pitti: that's up to infinity :)
[11:50] <pitti> Saviq: fix uploaded; it shouldn't be necessary for the package to land in -release, published in -proposed should be enough; so as soon as https://launchpad.net/ubuntu/+source/init-system-helpers/1.28ubuntu2 is published and on the mirror, you can retry the build
[11:50] <Saviq> pitti, yup, thanks!
[12:35] <Mirv> pitti: could kblog and ktnef be overriden for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qtbase-opensource-src - I've filed a bug #1543093 after reproducing the failures locally on stock xenial
[12:35] <ubottu> bug 1543093 in ktnef (Ubuntu) "fails to build with No rule to make target '/usr/lib/libical.so'" [Undecided,New] https://launchpad.net/bugs/1543093
[12:36] <Mirv> it's not simply a missing build dependency or such, but something else
[12:37] <cjwatson> multiarch fallout?
[12:41] <tsimonq2> thanks ScottK :)
[13:38] <pitti> Mirv: done
[13:39] <Mirv> thank you!
[13:44] <pitti> xnox: are you interested in looking into the upstart test regression? (that happend a fair while ago), or should I just bump the force-badtest?
[13:44] <pitti> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/u/upstart/20160207_110626@/log.gz
[13:44] <pitti> search for "not ok" (one hit, "26 - with single-line script that is killed")
[13:45] <pitti> which consistently fails on all arches and all runs
[13:45] <mterry> jdstrand, hello!  We had settled on python-oauthlib as the recommended oauth bindings library a while back.  I'm getting a MIR (bug 1540431) that wants python-oath2client.  Apparently it is the Google-oriented flavor of oauth libraries, and would be difficult to just swap out for oauthlib (has direct support for appengine, etc).  What is the security stance on having two oauth libraries in main?  How much trouble would that be?
[13:45] <ubottu> bug 1540431 in python-uritemplate (Ubuntu) "[MIR] python-googleapi python-oauth2client" [Undecided,Incomplete] https://launchpad.net/bugs/1540431
[13:45] <xnox> pitti, it's flakey on ppc64el builders (had to retry the builds). I'm suspecting it's specific to how adt package tests are run.
[13:45] <xnox> pitti, either to little or too much load.
[13:46] <xnox> pitti, and the test is racy. We may or may not catch the thing we are trying to catch =/
[13:46] <pitti> xnox: yes, that's what I meant -- should we just disable that test, if it's known to not work properly anyway?
[13:46] <pitti> better than entirely ignoring the whole thing
[13:47] <xnox> pitti, i was pondering to upload: not ok 26 - ..... # TODO -> which will then make it XFAIL, rather than FAIL.
[13:47] <xnox> pitti, to be honest, unless it affects user-session, or touch, i really don't care.
[13:47] <pitti> xnox: XFAIL would then fail if it actually succeeds, no?
[13:48] <ogra_> is that a branded FAIL ? like XNOX-FAIL ?
[13:48] <ogra_> :)
[13:48] <xnox> ogra_, expect...
[13:48] <xnox> pitti, depends how i code it =), i'll make it "ok" or "not ok # TODO"
[13:48] <xnox> :P
[13:48] <pitti> xnox: ah, that sounds perfect
[13:48] <pitti> xnox: thanks
[13:59] <caribou> Laney: Hi, I would need help with a trusty backport : https://bugs.launchpad.net/trusty-backports/+bug/1494141
[13:59] <ubottu> Launchpad bug 1494141 in trusty-backports "HAProxy 1.5 init script does not terminate processes" [Medium,In progress]
[14:07] <caribou> or anybody from the backport team as a matter of fact
[14:12] <caribou> pitti: did you get to verify the juju-local bug caused by rsyslog since I uploaded 8.16 ?
[14:13] <pitti> caribou: yes, it doesn't crash any more; thanks!
[14:13] <caribou> pitti: good, I can close the bug
[14:21] <Laney> caribou: what actually is needed?
[14:22] <caribou> Laney: it's been sitting idle for a long time and would need that the current package be replaced by the version in wily-updates (as stated in my last comment)
[14:22] <caribou> Laney: it was stopped waiting for fixes to make it to the stable release
[14:23] <caribou> Laney: and is causing problems in Openstack
[14:24] <Laney> caribou: it is a confusing bug and your comment says "From what I can gather", and not "Please backport from wily-updates" - the former reads to me like you aren't certain
[14:24] <Laney> So if that's what you want, please make it clear and say that you have tested it
[14:24] <Laney> for example fix the bug title too
[14:24] <caribou> Laney: ok, will do & ping you back
[14:26] <Laney> thanks
[14:28] <dobey> hmm, when's lts-wily xorg expected to land in trusty updates?
[14:38] <jdstrand> mterry (and tyhicks): in general we try to avoid things like that. istr this particular case came up once before...
[14:39] <jdstrand> mterry: ah, yes, bug 1213934. I'll let sarnold comment when he comes online
[14:39] <ubottu> bug 1213934 in python-oauth2 (Ubuntu) "[MIR] python-oauth2" [Critical,Won't fix] https://launchpad.net/bugs/1213934
[14:41] <mterry> jdstrand, yeah I know we don't like it.  I'm just not sure that oauth2client is as simple a comparison because of all its google-specific stuff
[14:41] <mterry> But yeah let's hear sarnold
=== zbenjamin_ is now known as zbenjamin
[14:42] <mterry> jdstrand, also, did you ever get my email about that PAM module I wrote for lockscreen password?
[14:42] <mterry> jdstrand, I figure if we're going to use it on phones, you folks should make sure I didn't do something stupid
[14:43] <jdstrand> we did. tyhicks and I need to give it a priority and assign it to someone. we are pretty behind on reviews atm
=== barry` is now known as barry_
=== barry_ is now known as barry
[14:54] <caribou> Laney: just tested & updated the bug; let me know if that is adequate for you
[15:02] <doko> ginggs, https://bugs.launchpad.net/bugs/1542928
[15:02] <ubottu> Launchpad bug 1542928 in python-scientific (Debian) "python-scientific should be removed" [Unknown,Confirmed]
=== my-name is now known as kulyzu
[15:06] <Laney> caribou: ok, thx
[15:10] <seb128> @pilot in
=== udevbot changed the topic of #ubuntu-devel to: Wily (15.10) Released! | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-wily | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: darkxst, seb128
[15:11] <nandersson_>  Hi, how many years does one have to wait for a contributed patch to enter Ubuntu? This bug is oooooooooooooold, patched and still Canonical hasn't added the patch. What is the reason behind this? https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1390061/+subscriptions
[15:11] <ubottu> Launchpad bug 1390061 in bash-completion (Ubuntu) "bash-completion tilde expansion every time" [Medium,Confirmed]
[15:19] <mdeslaur> nandersson_: I've subscribed ubuntu-sponsors to the bug so the patch gets looked at
[15:19] <Laney> caribou: done
[15:19] <seb128> nandersson_, Ubuntu contributors are not restricted to Canonical and that bug should perhaps be sent to Debian, also what mdeslaur said
[15:19] <caribou> Laney: thank you sooo much !
[15:19] <tseliot> pitti: for some reason I can't find dh-modaliases on armhf in xenial (arch is set to all in the control file though)
[15:22] <roaksoax> pitti: there are none: http://paste.ubuntu.com/14993709/
[15:23] <pitti> tseliot: hm, rmadison also says "all"
[15:23] <roaksoax> pitti: this was working fine the week before last though, and we just started seeing this last week when trying to update packaging
[15:23] <pitti> roaksoax: that's the source's .postinst; I mean the built version, with #DEBHELPER# expanded
[15:23] <nandersson_> mdeslaur, Thanks a lot! :)
[15:24] <nandersson_> seb128, Thanks. Actually I think it is already patched upstream in Debian, but I will check that.
[15:24] <cjwatson> tseliot: it's definitely there.  how are you checking this?
[15:25] <tseliot> cjwatson: my xenial chroot can't find it, also here: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.4.15/+build/8908972
[15:25] <showaz> nandersson_, http://bash-completion.alioth.debian.org/
[15:26] <cjwatson> tseliot: the latter is irrelevant, it's arch: all so only built on amd64
[15:26] <cjwatson> tseliot: when you say "can't find it", could you give me a transcript?
[15:26] <nandersson_> showaz, Yes, I'll check with Luk and David. Thanks
[15:26] <cjwatson> tseliot: (https://launchpad.net/ubuntu/xenial/armhf/dh-modaliases shows it as published, and I can see it in a chdist instance)
[15:27] <tseliot> cjwatson: sbuild says E: Build-Depends dependency for sbuild-build-depends-nvidia-graphics-drivers-361-dummy cannot be satisfied because the package dh-modaliases cannot be found
[15:27] <tseliot> apt-get failed.
[15:27] <cjwatson> tseliot: check sources.list etc., or schroot in and see what apt-cache thinks
[15:28] <tseliot> cjwatson: I did: http://pastebin.ubuntu.com/14993739/
[15:28] <cjwatson> tseliot: when did you last sbuild-update?
[15:28] <pitti> tseliot: there is no /ubuntu-ports, it's just /
[15:29] <roaksoax> pitti: argh! my bad: http://paste.ubuntu.com/14993743/
[15:29] <pitti> tseliot: ah well, it actually does seem to work, supposedly a symlink to .
[15:29] <cjwatson> yes, /ubuntu-ports has long been a thing
[15:29] <cjwatson> having a non-/ root for the archive is helpful for mirrors
[15:29] <tseliot> pitti: yes, I think apt would have complained otherwise
[15:29] <pitti> roaksoax: dpkg-maintscript-helper rm_conffile /lib/systemd/system/maas-clusterd.service 2.0.0~alpha1+bzr4635-0ubuntu1 -- "$@"
[15:30] <pitti> roaksoax: o_O
[15:30] <pitti> roaksoax: that's not a conffile
[15:30] <tseliot> cjwatson: I created the chroot maybe a couple of hours ago
[15:30] <pitti> $ wget -O- http://ports.ubuntu.com/dists/xenial/main/binary-armhf/Packages.bz2 | bzgrep -A10 'Package: dh-modalias'
[15:31] <pitti> tseliot, cjwatson ^ works (just to ensure that there's really nothing wrong on the mirror)
[15:31] <tseliot> hmm...
[15:31] <seb128> nandersson_, the xenial version has been rebased on Debian and has  trivial diff, so the issue should apply to Debian as well
[15:31] <cjwatson> yeah, I was just doing the same thing :)
[15:32] <pitti> smb: lol, the messed up UTC timezone is breaking one of my tests, too :)
[15:32] <nandersson_> seb128, yeah, I am reaching out to Debian maintainers, and have it incorporated there :)
[15:32] <cjwatson> tseliot: try schrooting in and doing 'apt-cache policy base-files ncurses-base dh-modaliases'
[15:33] <seb128> nandersson_, thanks
[15:33] <tseliot> cjwatson: http://paste.ubuntu.com/14993776/
[15:34] <pitti> tseliot: curious, what kind of setup can run both amd64 and armhf debs at the same time?
[15:34] <tseliot> it does seem to be there..
[15:34] <cjwatson> pitti: qemu-user-static presumably
[15:34] <tseliot> pitti, cjwatson: correct
[15:35] <cjwatson> tseliot: can you paste the entire output from sbuild, including the command line used to invoke it?  add the --debug option while you're there
[15:35] <tseliot> that is also how I build Mir on armhf ;)
[15:35] <tseliot> cjwatson: sure
[15:41] <doko> ginggs, any idea about petsc on powerpc?
[15:46] <roaksoax> pitti: yes, I've already cleaned that up, but obviously that doesn't affect things at all
[15:51] <tseliot> cjwatson: err... it's giving me a different error now: http://pastebin.ubuntu.com/14993857/
[15:51] <tseliot> that I can probably fix
[15:54] <cjwatson> mm, that might be something to do with nss databases in the chroot
[15:58] <tseliot> cjwatson: I managed to fix that, and now the old error is back
[16:06] <tseliot> cjwatson: http://pastebin.ubuntu.com/14993921/
[16:42] <cjwatson> tseliot: pass, for the moment - if you tell sbuild not to purge the session then you can use schroot -rc <session id> -u root and see what's up
[16:43] <tseliot> cjwatson: ok, I'll try that, thanks
[16:57] <ginggs> doko, no ideas about petsc on powerpc yet, sorry, and there's also aces also fails on powerpc. i'm not sure if petsc still builds in debian on powerpc; it doesn't look like it has been rebuilt there yet
[17:17] <seb128> smoser, hey, you are core-dev ... any reason you go through the sponsoring queue for https://code.launchpad.net/~smoser/ubuntu-seeds/platform.xenial-ppp-to-server-ship/+merge/284943 rather than doing the changel yourself?
[17:21] <smoser> seb128, i think peer review makes sense for all people.
[17:22] <smoser> even for uber elite people who are core dev like myself :)
[17:22] <smoser> but i mostly planned on doing that one today.
[17:23] <smoser> i just sent to mailing list and waited to get wider view of it.
[17:42] <marlinc> The latest updates removed ubuntu-make
[17:42] <marlinc> The following packages have unmet dependencies.
[17:42] <marlinc>  ubuntu-make : Depends: python3-argcomplete but it is not going to be installed
[17:47] <marlinc> https://bugs.launchpad.net/ubuntu/+source/python3.4/+bug/1543228
[17:47] <ubottu> Launchpad bug 1543228 in ubuntu-make (Ubuntu) "Latest update caused removal of ubuntu-make" [Undecided,New]
=== mnepton is now known as mneptok
[18:01] <kuly-zu> when i run netstat i saw some PID/program-name has a -, even if it's run with sudo, why?
[18:02] <teward> kuly-zu: i think that's a question for #ubuntu not here
[18:27] <hallyn> pitti: was talking with tych0, and wondering - should lxcfs try loading liblxcfs with relative path first and then the libdir path, or other way around?
[18:27] <hallyn> i was doing libdir first, but maybe there's no good reason to do so
[18:30] <sarnold> relative to what? loading libraries from "relative" paths feels scary
[18:39] <hallyn> sarnold: as in dlopen("lib.so") vs dlopen("/usr/lib/lxcfs/lib.so")
[18:39] <hallyn> subject to all the usual rpath/ldlibrarypath stuff of course
[18:40] <hallyn> agree it feels scary, but LD_LIBRARY_PATH Is pretty will thought out these days
[18:40] <sarnold> hallyn: would cwd ever be anything that allows untrusted writing? e.g. /tmp or /var/tmp ?
[18:41] <hallyn> sarnold: i don't think so.  depends on init i suppose.  note lxcfs is not setuid-root
[18:41] <hallyn> surely . isnot in library path by default?
[18:41] <sarnold> it is not :)
[18:41] <sarnold> but dlopen("lib.so")..
[18:42] <cjwatson> dlopen("lib.so") isn't interpreted as a relative path
[18:43] <cjwatson> see dlopen(3) - "If filename contains a slash ("/"), then it is interpreted as a (relative or absolute) pathname.  Otherwise ..." and it's the "otherwise" bit that pertains here
[18:43] <sarnold> cjwatson: ah, thus the source of my confusion :) thanks
[18:44] <cjwatson> AFAIK this is basically the same as an ELF object having DT_NEEDED with no slash in it, which is entirely usual
[18:45] <hallyn> interesting, i hadn't realized what a pickle dlopen("a/b") would be -not that i can see any reason to do that
[18:45] <hallyn> anyway, so the poin tis that lxcfs will ship /usr/lib/lxcfs/liblxcfs.so, and i'm trying to decide whether it is better to have lxcfs try dlopen("lxcfs.so") first and fallback to libdir, or not
[18:46] <hallyn> the usual case if "make; ./lxcfs" suggests yes
[19:00] <hallyn> (i see, so my wrong terminology was adding to confusion :)
[20:06] <barry> cjwatson: you don't mind if i upload a new python-six dropping python-six-whl?
[20:28] <tedg> So I need to have different versions of the compiler choose whether the symbols file is used.
[20:29] <tedg> Specifically, because gcc5 has different signatures than gcc4.9.
[20:29] <tedg> So if built on gcc 4.x I don't want to check symbols.
[20:29] <tedg> Can't seem to figure out how to detect that and turn off symbols in a reasonable way. Ideas?
[20:54] <ginggs> doko: fwiw, i just tried building petsc on debian powerpc porterbox and it fails there too - as soon the mpi test program is launched
[20:55] <doko> ginggs, ahh, so openmpi is broken. filing a bug report
[20:57] <ginggs> doko: i concur. aces3 fails in exactly the same way (and does not use petsc)
[21:14] <cjwatson> barry: not if you do it to Debian :)
[21:14] <barry> cjwatson: of course! :)
[21:14] <barry> thx
[21:14] <tedg> xnox: Trying to figure out dh_acc, do you know of a project I could look at and steal from?
[21:22] <dobey> tjaalton: if you're around, i'm just curious why xorg-server-lts-wily hasn't made it into trusty-updates yet :)
[21:29] <tjaalton> dobey: probably because of some miscommunication.. the dailies need to be tested, then the stack can be moved to updates, i'm told
=== damascene is now known as burcuiela
=== burcuiela is now known as damascene
[21:30] <tjaalton> noone did the testing part yet
[21:30] <dobey> oh
[21:30] <dobey> hmm
[22:00] <doko> rbasak, please could -server write a MIR for lua-lpeg, new b-d for nmap
[22:13] <nacc> slangasek: for new src packages (e.g., php-pear moving from src:php5 to src:php-pear), is there a template for filing a bug? Its more intuitive for updating to a new version, but for packaging an altogether new package, I wasn't sure
[22:18] <nacc> slangasek: nm! found it on the wiki, sorry for the noise
[23:41] <xnox> tedg, checkout reverse-depends -b src:acc-package-name ?!
[23:41] <xnox> tedg, it's convoluted, and there are bug reports about it. in practice, build once with it enabled everywhere, retrieve abi tarballs, ship them.