[02:50] <CarlFK> stgraber  cyphermox - tumbleweed says you might be able help with a Network Manager install issue: I don't want it to create "Wired Connection 1"  which seems to be created when the box first boots, not during the di
[06:43] <pitti> Good morning
[07:11] <damascene> Any Idea why Ubuntu still have the deb-src enabled by default in source.list? I've never used them in my 5+ years with Ubuntu
[07:12] <damascene> sources.list
[07:22] <damascene> commenting deb-src remove
[07:23] <damascene> sorry, commenting deb-src saved Ubuntu servers 15 hit at least in my simple test.
[08:12] <pitti> slangasek: FTR, julia/i386 is known broken, don't bother retrying
[08:13] <pitti> slangasek: suitesparse is blocked by uninstallability, not tests
[09:37] <Odd_Bloke> cjwatson: https://code.launchpad.net/~daniel-thewatkins/livecd-rootfs/ppc64el/+merge/284229 is the other part of yesterday's change, if you get a minute. :)
[10:08] <Odd_Bloke> cjwatson: (I've just pushed another unrelated minor fix to that branch as well, to save on the overhead of another MP etc.)
[10:33] <cpaelzer_> I surely can come up with one, but I wanted to ask if there is a common way that should be used in d/rules to make decisions based on the arch?
[10:33] <cpaelzer_> like if arch=ppc64el, ...
[10:51] <cpaelzer_> CPU_TARGET=$(shell dpkg-architecture -qDEB_HOST_ARCH_CPU)
[10:51] <cpaelzer_> ifeq ($(CPU_TARGET),ppc64el)
[10:51] <cpaelzer_> is what I chose for my first try
[11:20] <pitti> stgraber, hallyn: ooh, bash completion on image names with "lxc launch"! ♥
[11:30] <hallyn> you and your unicode :)
[11:30] <stgraber> pitti: haha, yeah, we've had the problem for a while but elmo reminded us that actually installing it would be a good idea :)
[11:31] <pitti> hallyn: 2665 is one of the few numbers I actually remember ☺  most fancy chars (like the smiley) have compose key combinations, but I don't know one for "heart"
[11:51] <cjwatson> Odd_Bloke: thanks, uploaded
[11:52] <cjwatson> cpaelzer_: you usually don't need to use _CPU etc., just compare against DEB_HOST_ARCH
[11:54] <caribou> When one creates an initscript that accepts DAEMON_OPTS modifications, should these be done in /etc/default/{package} or directly in the initscript ?
[11:55] <caribou> in other words : is it better to have the conffile in /etc/default ?
[11:56] <cpaelzer_> cjwatson: ok thanks
[11:56] <doko> Logan, I see you merged sphinxbase, but not pocketsphinx. now stuck in -proposed
[11:56] <pitti> caribou: TBH it'd be best to configure such things in /etc/yourdaemon.conf, not in the init script
[11:57] <pitti> caribou: the general pattern has been to put tweakable stuff into /etc/default/ -- init scripts should not ever be touched
[11:57] <pitti> caribou: (by admins, I mean)
[11:57] <pitti> caribou: but modifying command lines to change a service's configuration is a bit icky
[11:58] <caribou> pitti: so what is the rationale in choosing /etc/yourdaemon.conf or /etc/default ? The debian doc seems to point toward /etc/default
[11:58] <pitti> caribou: what I meant is, that you should start /usr/sbin/foo and *that* should read its configuratoin from /etc/foo.conf
[11:58] <caribou> pitti: ah, ok get it
[11:59] <pitti> caribou: it's conceptually wrong that each distro has to come up with its own schema of "how do I configure foo?"
[11:59] <pitti> as that makes it impossible for upstreams to document this
[11:59] <pitti> and it looks different everywhere
[11:59] <caribou> true
[11:59] <pitti> caribou: i. e. "how to configure a daemon" is not conceptually a distro question, it's an upstream questoin
[11:59] <cjwatson> cpaelzer_: also, those variables are often exported to the environment although not always; so the best way to acquire them is usually "DEB_HOST_ARCH ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)"
[11:59] <cjwatson> i.e. keep the name of your make variable in sync
[12:00] <pitti> caribou: so if possible, please don't introduce new /etc/default files -- we should instead get rid of them in the long run..
[12:00] <xnox> cjwatson, cpaelzer_: and i prefer to do: include /usr/share/dpkg/default.mk
[12:00] <pitti> caribou: also, perhaps don't write new sysvinit scripts -- we stopped using sysvinit like 10 years ago
[12:00] <xnox> and that gives me all DEB_*_* variables
[12:00] <cjwatson> cpaelzer_: and definitely don't use terms like TARGET if you don't have to, because those have different associations in this context and you'll just get confused
[12:00] <xnox> and a bunch of other useful stuff.
[12:00] <cjwatson> xnox: right, or that
[12:01] <caribou> pitti: thanks; it's not a new one, just adapting a failing one
[12:01] <xnox> cpaelzer_, DEB_HOST_ARCH is by far the most common one to key on. and it's the short debian arch tag: i386, s390x, etc...
[12:01] <pitti> caribou: working on merging rsyslog by any chance? :-) (just saw the latest responses on bug 1534106)
[12:02] <caribou> pitti: not at the moment, but looks like I will do another round at it if this solves that bug
[12:03] <xnox> pitti, i also see that on s390x. Also discovered that debugging tools are a bit odd on s390x.
[12:03] <caribou> pitti: my sysinit question was about LP: 1248054
[12:03] <pitti> xnox: the rsyslog crash with juju, you meaN?
[12:03] <cpaelzer_> xnox: cjwatson: thanks for the further guidance
[12:03] <xnox> pitti, yeap.
[12:04] <caribou> the current script fails so wolsen has debianized the upstream script
[12:04] <pitti> caribou: oh -- no new conffiles in SRUs please
[12:04] <xnox> pitti, caribou: see other recently reported bugs on rsyslog.
[12:04] <xnox> bug 1538723
[12:04] <caribou> pitti: I'm fine with it
[12:04] <LocutusOfBorg> jrwren_, can you please merge pngnq from debian?
[12:04] <xnox> caribou, i have extra gdb dump there....
[12:04] <pitti> caribou: ah, this is also for xenial, I see (cofusing bug title), sory
[12:04] <LocutusOfBorg> or can I steal your merge?
[12:05] <caribou> pitti: it will be SRUed so it still applies
[12:05] <cpaelzer_> xnox: I already sourced and didn't realize it would fill these env yet, and by that I also get rid of the misleading cariable name cjwatson mentioned - great
[12:06] <xnox> cpaelzer_, yeah, it does crazy caching and queries them on demand. but yeah, DEB_HOST_ARCH is available as a make variable if sourced. And you can export them, to make them environment variables if you need to.
[12:10] <cjwatson> (which is rare)
[12:49] <elijah> Was chatting with davmor2 in #ubuntu-app-devel and they mentioned that there is work being done between Ubuntu Touch and the Gnome devs to fix the network scan refresh for Network Manager. Does anyone know the issue links for those?
[12:50] <elijah> Been searching for 10 minutes and can't find them
[12:52] <davmor2> elijah: https://bugs.launchpad.net/ubuntu/+source/indicator-network and https://bugs.launchpad.net/ubuntu/+source/network-manager  it'll be among these
[12:54] <davmor2> elijah: your best bet will be awe but he is in the US so won't be on for a bit
[12:55] <elijah> davmor2: Thanks, maybe I will ping him later (ps. I am in the US too, on a train to NYC right now :D)
[12:57] <elijah> davmor2: This is gold - https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1529294/comments/2
[13:01] <elijah> Says NM 1.2 scans when a Wi-Fi network list is displayed - https://blogs.gnome.org/dcbw/2016/01/18/networkmanager-1-2-has-better-wi-fi-scanning/
[13:27] <flexiondotorg> gnome-schedule is no longer in the Xenial archive - http://packages.ubuntu.com/wily/gnome-schedule
[13:28] <flexiondotorg> Is there any way of finding why a package is no longer present?
[13:28] <flexiondotorg> Also, how can I go about getting it re-instated?
[13:35] <pitti> flexiondotorg: yes, on https://launchpad.net/ubuntu/+source/gnome-schedule/+publishinghistory
[13:35] <pitti> Deleted on 2015-12-19 by Colin Watson
[13:35] <pitti> (From Debian) ROM; unmaintained, dead upstream, RC buggy, depends on obsolete libs; Debian bug #808060
[13:36] <flexiondotorg> pitti, Thanks.
[13:39] <cjwatson> and the best way to get something reinstated that's been removed from Debian is to get it back into Debian
[13:39] <flexiondotorg> cjwatson, Yep.
[13:40] <flexiondotorg> The problem with removing it from Debian is that the RC bugs alluded to the the removal bug report are now gone.
[13:41] <LocutusOfBorg> doko, can I merge itk4?
[13:42] <doko> LocutusOfBorg, sure
[13:42] <LocutusOfBorg> thanks
[13:42] <LocutusOfBorg> I tried to steal ghostscript, but I failed
[13:42] <LocutusOfBorg> can you please help?
[13:42] <doko> tkamppeter, ^^^
[13:44] <flexiondotorg> cjwatson, Will new packages introduced to Debian unstable automatically sync to Ubuntu xenial archive?
[13:45] <cyphermox> good morning!
[13:46] <pitti> hey cyphermox, how are you?
[13:46] <cyphermox> pitti: doing alright, you?
[13:46] <pitti> cyphermox: quite fine too, thanks
[13:47] <cjwatson> flexiondotorg: yes
[13:47] <pitti> cyphermox: greetings from Belgium! (FOSDEM this weekend)
[13:47] <cyphermox> oh, nice, lucky you
[13:47] <cjwatson> flexiondotorg: well, up to Debian import freeze; and with some caveats, things that have previously been removed from Ubuntu (or some other conditions) require manual review
[13:47] <cyphermox> pitti: I'm a little cold and in multipath hell ;)
[13:48] <flexiondotorg> cjwatson, Thanks.
[13:48] <pitti> cyphermox: multiple pathogens? :)
[13:48] <flexiondotorg> gnome-schedule does have newer upstream versions.
[13:48] <flexiondotorg> Will take a look.
[13:48] <pitti> cyphermox: urgh, get better soon then!
[13:48] <cyphermox> ah, not at all
[13:48] <cyphermox> it's just generally cold here, weatherwise ;)
[13:49] <pitti> oh, ok :)
[13:49] <pitti> cyphermox: stay healthy then! :)
[13:50] <cyphermox> well, you too. stay safe from the FOSFLU ;)
[13:52] <LocutusOfBorg> cjwatson, doko can I steal log4cxx merge?
[13:53]  * pitti believes LocutusOfBorg is the new Merge-O-Matic!
[13:53] <tkamppeter> LocutusOfBorg, what do you mean with "I tried to steal ghostscript, but I failed"?
[13:53] <LocutusOfBorg> tkamppeter, I would like to merge ghostscript, but the packaging diverged a little bit
[13:53] <LocutusOfBorg> and I'm not sure I can handle it
[13:53] <LocutusOfBorg> pitti, I would like to have packages ready for png1.6
[13:53] <LocutusOfBorg> :)
[13:54] <cjwatson> LocutusOfBorg: sure
[13:55] <tkamppeter> LocutusOfBorg, I know and I already investigated. You can go ahead with merging, but give a kick to the security team to solve bug 711061 (and not that we have already mid or end January).
[13:56] <LocutusOfBorg> tkamppeter, I don't know how to merge it, I'm not sure everything will be correct
[13:57] <tkamppeter> LocutusOfBorg, you can even sync that package, which is my intention to not need separate maintenance of Ghostscript in Ubuntu and Debian. Most of the rest of the printing stack is already synced.
[13:57] <LocutusOfBorg> I can try however
[13:57] <jrwren_> LocutusOfBorg: I think you misdirected that message. I don't know about pngnq
[13:57] <jrwren_> LocutusOfBorg: if i have a merge, please steal i.
[13:57] <LocutusOfBorg> https://launchpad.net/ubuntu/+source/pngnq/1.0-2ubuntu2
[13:57] <tkamppeter> LocutusOfBorg, what I plan to do is to simply sync it, as soon as the MIR for openjpeg gets solved.
[13:57] <LocutusOfBorg> jrwren_, ^^^
[13:58] <LocutusOfBorg> tkamppeter, wonderful then, I'll leave it to you
[13:58] <tkamppeter> LocutusOfBorg, OK.
[13:58] <LocutusOfBorg> jrwren_, I uploaded the delta in debian/deferred queue, will be syncd in 10 days
[13:59] <hallyn> pitti: adt-build-lxc, is there a way to make it use the download or ubuntu-cloud templates?
[13:59] <hallyn> or is there something else i should use which maybe makes it use lxd?
[13:59] <hallyn> (or is this my fault for being on wily)
[14:01] <pitti> hallyn: for LXD, use adt-build-lxd :)
[14:01] <pitti> hallyn: wily> ah, I suppose I shold update the autopkgtest backports, then the wily backport will get teh new LXD backend and tools
[14:02] <pitti> hallyn: adt-build-lxc only works with debootstrap (it's meant as a convenience wrapper around it)
[14:02] <pitti> hallyn: locally I have entirely stopped using adt-virt-lxc, lxd is so much nicer
[14:04] <hallyn> hm, so i can't use adt-build-lxd :(  maybe i should build it locally
[14:04] <pitti> hallyn: just dowlnoad and install http://archive.ubuntu.com/ubuntu/pool/main/a/autopkgtest/autopkgtest_3.19.2_all.deb
[14:04] <pitti> hallyn: I update the backports now
[14:04] <hallyn> cool thanks :)
[14:05] <pitti> hallyn: adt-build-lxd is more or less just "take a standard LXD image and run the setup script", which adds deb-src, eatmydata, and a few tweaks
[14:05] <jrwren_> LocutusOfBorg: I have poor memory. this was over a year ago and I don't remember doing it. Sorry. Thank you for mergine
[14:05] <LocutusOfBorg> thanks for allowing me to merge it :)
[14:05] <pitti> hallyn: so with lxd you don't necessarily need to use adt-build-lxd at all, but if you use it often it's still more convenient/faster
[14:06] <hallyn> oh, hm.  well i don't know if i'll be using it often - i probably should :)
[14:08] <pitti> hallyn: see man adt-virt-lxd for some details
[14:09] <hallyn> and then to run adt-run against it,
[14:14] <hallyn> pitti: http://paste.ubuntu.com/14688283/  i'm messing up
[14:15] <pitti> hallyn: you need to specify an image -- adt-run [...] --- lxd lco:ubuntu/xenial/amd64
[14:16]  * pitti whispers "adt-virt-lxd(1)" again
[14:16] <hallyn> adt-build-lxd built an image, but i dont' knwo what it was called
[14:16] <hallyn> (lxc list doesn't show it)
[14:16] <pitti> hallyn: lxc image list
[14:16] <pitti> hallyn: ah, then presumably adt/ubuntu/xenial/amd64
[14:16] <hallyn> hm, not showing up.  wtf
[14:16] <pitti> or whichever release you built it from
[14:17] <smoser> bdmurray, i modified update-notifier so that it doesn't background a task after you run 'apt-get update'
[14:17] <smoser> as that task was what was keeping /dev busy and making the installer fail to unmount
[14:18] <smoser> kirkland, ^
[14:18] <hallyn> pitti: ok, i'll just lxc:ubuntu/xenial/amd64 i guess...  will adt-virt-lxd then cache what it built for me locally?
[14:19] <hallyn> (would make sense for it not to, just asking)
[14:19] <pitti> hallyn: it does, as it creates the image locally
[14:19] <pitti> hallyn: did adt-build-lxc fail? do you still have the output in scrollback?
[14:19] <hallyn> pitti: cool, thx
[14:19] <pitti> (and what you called it with)
[14:20] <hallyn> i dstopped the adt-biuld-lxc.  the adt-build-lxd did not fail i don't think, but i don't have scrollback.
[14:20] <hallyn> hm, now i get "Test dependencies are unsatisfiable."
[14:20]  * hallyn tries -U
[14:21] <pitti> hallyn: maybe you need to call it with -U (--apt-upgrade) if the image is a bit outdated
[14:21] <pitti> ... that
[14:21] <hallyn> it should'nt be outdated - it just d/led it :)
[14:21] <pitti> that's a matter of when it was built, not when you downloaded it, but indeed they shold get rebuilt every day
[14:21] <hallyn> no, -U doesn't help
[14:21] <pitti> or maybe your local package changes dependencies somehow
[14:22] <pitti> hallyn: which package does it complain about?
[14:22] <hallyn> it doesn't say.  do i say -v or -d ?
[14:22] <pitti> hallyn: the log should say -- can you pastebin it?
[14:23] <hallyn> re-running with -d
[14:23] <pitti> apt's -o Debug::PkgProblemResolver
[14:23] <pitti> hallyn: -d doesn't make apt any more verbose
[14:24] <hallyn> pitti: http://paste.ubuntu.com/14688316/
[14:24] <pitti>   Removing adt-satdep:amd64 because I can't find libpam-cgfs:amd64
[14:24] <pitti> hallyn: ah! it's in -proposed only
[14:24] <pitti> hallyn: so re-run with --apt-pocket=proposed -U
[14:24] <hallyn> where is that dep coming from...
[14:25] <pitti> hallyn: from your debian/tests/control Depends:
[14:25] <pitti> hallyn: I suppose you tell it to run with the binaries from the archive instead of building the package locally and using those debs
[14:25] <hallyn> i didn't add that
[14:26] <hallyn> i want it to build locally
[14:26] <hallyn> but also that isn't in debian/test/control - or does '@' expand to that
[14:26] <pitti> hallyn: run it against the .dsc then, not the source.changes
[14:27] <hallyn> why would the .changes not cause it to be built?  that seems weird
[14:27] <pitti> that's a bit of a grey area right now -- Debian folks run against .changes with .debs, so they *don't* want to rebuild
[14:27] <hallyn> huh
[14:27] <pitti> and it currenlty just doesn't make enough checks on it to realize that there are no debs in it and you probably want a build
[14:27] <hallyn> heh, ok
[14:28] <pitti> hallyn: so, simply, you are the first person I'm aware of who tried to run against a source.changes :)
[14:28] <hallyn> ok this seem sto be getting further
[14:28] <pitti> (that's not currently documented/defined)
[14:28] <pitti> .dsc should do what you mean
[14:28] <hallyn> pitti: i actually pondered which to use, then the manpage showed using .changes so i used that
[14:28]  * pitti makes a note to clarify that
[14:31] <hallyn> meh, ran alo tlonger, but Khttp://paste.ubuntu.com/14688362/
[14:32] <pitti> the log is cut off
[14:32] <pitti> i. e. the apt error message isn't there
[14:32] <pitti> pmerror:cgmanager:81.7308:subprocess installed post-installation script returned error exit status 1
[14:32] <pitti> ah
[14:32] <pitti> hallyn: does cgmanager work in a container?
[14:33] <hallyn> no.  shouldn't really be needed for this...
[14:33] <pitti> hallyn: you can try with
[14:33] <pitti> lxd adt/ubuntu/xenial/amd64 -- --config raw.lxc=lxc.aa_profile=unconfined
[14:33] <pitti> disabling apparmor might help
[14:34] <pitti>  lxc launch adt/ubuntu/xenial/amd64 x1
[14:34] <hallyn> pitti: actually it'll fail in lxd anyway bc i'tll want to run fuse.  i was being silly.
[14:34] <pitti> $ lxc exec x1 -- apt-get install -y cgmanager
[14:34] <pitti> that semes to work
[14:34] <pitti> hallyn: so, qemu then?
[14:35] <hallyn> i dunno, do i want to wait an hour for all that to get setup
[14:35] <pitti> hallyn: it's primarily the time that it takes to download the > 300 MB cloud image indeed
[14:37]  * hallyn starts it and goes to get a coffee
[14:39] <kenvandine> pitti, i see you just landed a change to lxc-android-config to xenial, any reason that shouldn't land in the vivid overlay too?
[14:40] <pitti> kenvandine: it's not necessary at all in vivid
[14:40] <kenvandine> pitti, i was about to create a landing for slangasek's branch and would rather dual land
[14:40] <hallyn> pitti: so after i do sudo adt-buildvm-ubuntu-cloud -a amd64 -r xenial , do i have to pass the full rootfs pathname to adt-run, or is there some short name i can provide?
[14:41] <pitti> kenvandine: ah; well it doesn't *hurt* in vivid
[14:41] <smoser> bdmurray, i put a very long winded explanation of my beliefs in bug 1527710 if you're interested.
[14:41] <pitti> hallyn: no sudo please
[14:41] <kenvandine> pitti, cool
[14:41] <pitti> hallyn: you have to pass the complete path to the image
[14:41] <hallyn> pitti: huh...  i don't think adt-run let me do it without
[14:41] <kenvandine> there aren't separate vivid and xenial branches
[14:41] <hallyn> ok
[14:41] <pitti> kenvandine: ok; I just checked vivid and systemd-detect-virt --container --quiet works there
[14:42] <kenvandine> great
[14:42] <ogra_> pitti, eeek
[14:42] <pitti> hallyn: no, pretty much only virt-chroot (nobody uses that)
[14:42] <pitti> hallyn: nothing else needs root
[14:42] <ogra_> pitti, i think you want to revert the lxc-android-config upload ... at least until we see any traces of systemd on phones
[14:43] <pitti> ogra_: we have logind on the phone, so it's quite obviously installed (and I checked that)
[14:43] <ogra_> does it also work without systemd as init ?
[14:43] <pitti> yes, it doesn't care
[14:43] <pitti> I tested with upstart and sysvinit
[14:43] <pitti> it just does a couple of tests in /proc and /sys
[14:43] <ogra_> ah, k, i thought it calls a specific init function
[14:44] <ogra_> then ignore me ;)
[14:44]  * pitti watches ogra's blood pressure go back to normal :)
[14:44] <kenvandine> :)
[14:44] <ogra_> lol, no high pressure here ... i only sound like it ;)
[14:45] <kenvandine> pitti, once i get it built in the silo, mind testing it as well to be certain it works before i send it to QA?
[14:45] <kenvandine> i'll test slangasek's fix
[14:46] <kenvandine> ugh... not there's a conflict
[14:47] <mdeslaur> xnox: are you working on virt-manager?
[14:47] <kenvandine> slangasek, can you please refresh https://code.launchpad.net/~vorlon/lxc-android-config/apport-job-cleanup/+merge/274497
[14:47] <kenvandine> slangasek, now there's a merge conflict...
[14:50] <pitti> kenvandine: meh, it conflicts merely because the file that got removed anyway is now slightly different?
[14:50] <kenvandine> i guess
[14:50] <pitti> kenvandine: wait
[14:50] <kenvandine> i didn't look closely
[14:51] <pitti> kenvandine: I can just remove my pakcage from -proposed and uncommit, then you can retry to land
[14:51] <pitti> seems easier
[14:51] <kenvandine> ok...
[14:51] <kenvandine> :)
[14:51] <kenvandine> pitti, we can land your's togther
[14:51] <pitti> kenvandine: after slangasek's there's nothing of mine left
[14:52] <kenvandine> ah!
[14:52] <kenvandine> :)
[14:52] <hallyn> pitti: ung.   http://paste.ubuntu.com/14688473/
[14:52] <pitti> kenvandine: done -- try again?
[14:53] <kenvandine> ok
[14:53] <kenvandine> thx
[14:53] <pitti> hallyn: you didn't build that with adt-buildvm-ubuntu-cloud apparently?
[14:53] <pitti> hallyn: adt qemu images need some preparation to get a "foot into the door", the qemu equivalent of lxc-attach
[14:54] <pitti> hallyn: if that's just the stock xenial image, you can avoid re-downloading, though
[14:54] <xnox> mdeslaur, well i must have the new one, to stop endless fiddling inside it when connecting to s390x libvirt.
[14:54] <pitti> hallyn: although the name matches, so I wonder how you built that
[14:54] <xnox> mdeslaur, i'm happy for others to update it =)
[14:54] <xnox> mdeslaur, has it been in progress for you?
[14:54] <kenvandine> pitti, one conflict left... Text conflict in debian/lxc-android-config.maintscript
[14:55] <pitti> kenvandine: ok, I didn't touch that (now in fact there's no trace of my commit left)
[14:55] <kenvandine> right
[14:55] <pitti> kenvandine: oha, that MP is from october already
[14:55] <kenvandine> yeah...
[14:56] <kenvandine> pitti, i'll need to get slangasek to refresh it
[14:56] <mdeslaur> xnox: I haven't looked at it yet. If I get time, I'll let you know, and if you start it before me, let me know.
[14:56] <hallyn> pitti: ?   yes, i built that with adt-buildvm-ubuntu-cloud
[14:56] <kenvandine> i guess nobody's really looking after lxc-android-config anymore
[14:56] <hallyn> pitti: "adt-buildvm-ubuntu-cloud -a amd64 -r xenial"
[14:57] <pitti> hallyn: hmm -- can you please append --show-boot?
[14:57] <pitti> hallyn: that's an entirely new error now, I'm afraid
[14:57] <hallyn> pitti: will do
[14:58] <mdeslaur> xnox: any truth to the rumour that the "x" in s390x stands for xnox?
[14:58] <ogra_> kenvandine, hmm, i thought morphis actually planned to bring it into bzr at least (note it waqs always source package only, there isnt a tree for it)
[14:58] <pitti> hallyn: I suppose something went wrong during the image build (maybe setup-testbed errored out early before it got to installing that magic init.d script); I'll try here
[14:58] <pitti> I ran it this morning successfully, but who knows
[14:58] <morphis> ogra_: what exactly?
[14:58] <kenvandine> ogra_, i had it so it was landable from bzr branches
[14:58] <s390x> mdeslaur, no way
[14:58] <ogra_> morphis, lxc-android-config
[14:59] <mdeslaur> lol
[14:59] <hallyn> pitti: http://paste.ubuntu.com/14688510/
[14:59] <ogra_> kenvandine, it never was in any bzr branches afaik
[14:59] <kenvandine> it wasn't...
[14:59] <kenvandine> we fixed that :)
[14:59] <ogra_> ah, k
[14:59] <ogra_> so it is now ...
[14:59] <kenvandine> yup
[14:59] <ogra_> ignore me even more then :P
[14:59] <kenvandine> haha
[15:02] <Laney> who said that?
[15:06] <dpm> sil2100, seb128, the new "Custom Ringtone" string for ubuntu-system-settings that came with ota9... seems to be only translatable on Xenial?
[15:06] <dpm> Or am I looking at the wrong place in LP? I could only see it here: https://translations.launchpad.net/ubuntu/xenial/+sources/ubuntu-system-settings/+translations
[15:07] <pitti> hallyn: WTH, reproduced with a current run of buildvm-u-c; I'll look
[15:07] <pitti> this morning's was still okay, so whatever broke can't yet be that long ago
[15:07] <pitti> ooh
[15:08] <pitti> hallyn: yes, I know
[15:08] <seb128> dpm, https://translations.launchpad.net/ubuntu-rtm/15.04/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/370/+translate
[15:08] <dpm> aha! thanks
[15:08] <seb128> yw
[15:08] <seb128> is that the one you need?
[15:08] <pitti> hallyn: this was a regression in init-system-helpers 1.26ubuntu1, which got fixed in https://launchpad.net/ubuntu/+source/init-system-helpers/1.26ubuntu2
[15:09] <pitti> hallyn: but the current cloud image has ubuntu1 still, so it had that bug that update-rc.d enable failed
[15:09] <pitti> hallyn: so tomorrow's cloud image should be good again
[15:09] <dpm> seb128, yes, I was expecting it to appear under the list of "translatable distros", but I was looking at ubuntu, forgot about ubuntu-rtm for a sec
[15:09] <seb128> dpm, ok, good that it's there ;-)
[15:09] <pitti> hallyn: this isn't your testing day :/
[15:18] <hallyn> pitti: heh, ok thanks :)
[15:19] <dgadomski> pitti: hey, do you have any idea what may be holding back the release of fix to bug 1337873?
[15:19] <hallyn> pitti: but so can i do a adt-build that says update with what is in proposed?
[15:22] <slangasek> pitti: yeah, I noticed your notes on julia after I had hit retry, sorry.  The issue again of the test results and the override message being so far from each other (I was looking at jquery, not suitesparse)
[15:22] <slangasek> kenvandine: I probably won't get to refreshing that branch today
[15:24] <kenvandine> slangasek, ok
[15:24] <kenvandine> slangasek, please ping me when you do, i have a silo ready for it
[15:27] <slangasek> ok
[15:27] <kenvandine> slangasek, thx
[15:27] <pitti> slangasek: no problem, just wanted to explain that it's going to fail again
[15:39] <LocutusOfBorg> tkamppeter, thanks for opening debian bugs against ghostscripts :)
[15:45] <Odd_Bloke> apw: We're seeing /boot/initrd.img end up as an LZMA-compressed empty regular file when building s390x images using live-build; do you think that might be related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1536810?
[15:49] <ginggs> slangasek, pitti: julia needs a no-change rebuild for suitesparse, but it started FBTFS on armhf on the Ubuntu buildds and I don't know why
[15:49] <bdmurray> didrocks: I recreated bug 1532355 just by upgrading from Wily to Xenial.
[15:51] <didrocks> bdmurray: I did see that, I retried this morning and got a lot of other script failures, but not that one though :/
[15:51] <didrocks> bdmurray: that was an up to date ubuntu wily desktop
[15:52] <didrocks> bdmurray: I guess it depends on the package order, and the other failures shadowed it, I think the other should be fixed first so that we can reproduce that one more rigorously
[15:56] <Odd_Bloke> apw: Huh, we're also seeing that in our arm64 images, so there's definitely a problem somewhere; I'm going to file a separate bug and we can dupe it if necessary.
[16:00] <pitti> hallyn: doesn't --apt-pocket=proposed do that for builds?
[16:04] <hallyn> pitti: but that needs your cloud init updated package in order to be able to do the update to -proposed right? :)
[16:06] <pitti> hallyn: err, yes; that, or you use yesterday's cloud image
[16:08] <apw> Odd_Bloke, nope that doesn't sounds like i'd expect that particular bug to relate
[16:09] <apw> Odd_Bloke, i'd expect that to mean you have no /boot/initrd.img or it be a link to the wrong place, not be emtpy anything
[16:09] <apw> Odd_Bloke, let me know the number pls
[16:09] <Odd_Bloke> apw: OK, thanks; will do.
[16:11] <LocutusOfBorg> cjwatson, now that we have virtual architectures, why can't we have ppas with them too?
[16:12] <LocutusOfBorg> BTW about the arm64 virtual issues, I found some other packages having troubles, llvm-toolchain-3.7, insighttoolkit4 just today, I retried, and not sure if by chance, they went in a real machine and successful
[16:13] <cjwatson> LocutusOfBorg: you can, with ppc64el
[16:13] <cjwatson> LocutusOfBorg: but the others aren't reliable enough yet
[16:13] <LocutusOfBorg> ok, thanks!
[16:13] <LocutusOfBorg> I probably won't ask to enable ppc64el ATM
[16:13] <cjwatson> LocutusOfBorg: as soon as they're reliable enough, we'll add them for self-service enablement in PPAs, like ppc64el already is
[16:13] <cjwatson> LocutusOfBorg: (http://blog.launchpad.net/ppa/ppas-for-ppc64el)
[16:13] <LocutusOfBorg> :D wonderful! I was wondering about arm64 as example
[16:14] <cjwatson> LocutusOfBorg: right, the thing with arm64 is, the builders stay up provided they aren't being used much ;-)
[16:14] <cjwatson> LocutusOfBorg: the failure rate on reset is ridiculous
[16:14] <Odd_Bloke> apw: I've filed https://bugs.launchpad.net/ubuntu/+source/live-build/+bug/1539157; it's against live-build for now, because I didn't really know which package to point the finger at. :p
[16:14] <cjwatson> LocutusOfBorg: or at least was - it seems to have improved recently but it's currently hard to tell whether that's just chance
[16:14] <cjwatson> LocutusOfBorg: and yeah, bumping memory to 8GiB is something we'll need to look at for arm64 virt builders
[16:18] <Odd_Bloke> xnox: (See above filed bug for the issue we're seeing)
[16:25] <rharper> if I need to have a build dep for ppc64el only, does foo [powerpc] cover that? or is powerpc different DEB_HOST_ARCH than ppc64el ?   is there a more general power arch string that ppc64el would match to ?
[16:26] <rbasak> They're separate architectures, and no general term. At packaging level, anyway.
[16:26] <apw> rharper, debian ppc64el and powerpc are separate
[16:26] <rharper> apw: ok, thanks
[16:26] <rharper> rbasak: ok, thanks
[16:29] <nacc> rharper: BE vs. LE
[16:29] <nacc> v.v. rather
[16:30] <rharper> nacc: yep
[16:32] <kirkland> smoser: ah, interesting, good to know
[16:54] <caribou> Does someone have an idea what could cause "insserv: Service mountdevsubfs has to be enabled to start service lvm2"
[16:55] <caribou> in autopkgtests ? I see that in many Regressions flagged (including lvm2 that I uploaded earlier today)
[16:56] <caribou> I only see that for other services (cgmanager)
[17:06] <doko> barry, do you know how to look for libpeas dependencies?
[17:09] <pitti> caribou: could be some more fallout of the upgrade-rc.d failure (fixed in init-system-helpers this morning)
[17:09] <pitti> caribou: although mountdevsubfs.sh is just a no-op shim for init.d dependencies, so not really sure that's related
[17:09] <caribou> pitti: ah, wasn't aware of this one.
[17:10] <caribou> pitti: the only thing that changed in lvm2 is a script in clvm which is not touched by anyone; I doubt it comes from that
[17:10] <pitti> caribou: right, that sounds harmless; I guess the change that cuased that landed earlier, and it just surfaced now that lvm2 got built again
[17:11] <pitti> caribou: I won't get to it today or tomorrow (hackfest), next week there's a sprint, but I hope I can squeeze it in on Monday
[17:11] <pitti> caribou: unless you want to investigate yourself of course
[17:11] <pitti> caribou: if not, can you please file a bug with some pointers and assign to me?
[17:12] <caribou> pitti: I spent a good portion of my day looking for that
[17:12] <pitti> lrwxrwxrwx 1 root root   26 Nov 20  2014 /etc/rcS.d/S04mountdevsubfs.sh -> ../init.d/mountdevsubfs.sh
[17:12] <pitti> ooh
[17:12] <pitti> caribou: right, there *should* be an enablement symlink for that
[17:12] <pitti> caribou: so, the broken update-rc.d explains that after all
[17:12] <pitti> caribou: just retry them
[17:13] <caribou> pitti: just did with the magic button :)
[17:13] <pitti> caribou: if it still fails, then I guess I'll need to rebuild the base xenial images
[17:13] <pitti> caribou: yay!
[17:14] <pitti> caribou: ok, retry won't help I'm afraid
[17:15] <pitti> caribou: ganeti is broken differently, but overridden
[17:15] <pitti> caribou: so it's those arm/s390 failures for libvirt and cinder
[17:15] <caribou> pitti: yes
[17:15] <pitti> I guess I need to rebuild the containers for that
[17:16] <caribou> pitti: I've tried to run cinder & libvirt autopkgtests locally; been running for hours
[17:16] <pitti> oh, wow -- cinder sohld be quick
[17:16] <caribou> not sure that running them in schroots will work though,
[17:17] <caribou> pitti: I was dumb enough to run a build; unit tests take forever
[17:20] <pitti> ah :)
[17:21] <caribou> pitti: libvirt runs faster and seems ok
[17:26] <pitti> caribou: so, started container rebuilds, I'll then retry the bits
[17:27] <caribou> pitti: thanks!
[17:29] <smoser> just looking for some help... anyone else use pentadactyl ? firefox 44 seems to have killed it for me, i assume there is some way to make it go again, but...
[17:33] <smoser> pitti, wrt https://bugs.launchpad.net/ubuntu/+source/init-system-helpers/+bug/1539016
[17:34] <smoser> i recently had to convince grub not to run grub-probe when installing a kernel via chroot.
[17:34] <smoser> i did so by making running-in-container a link to /bin/true
[17:34] <xnox> smoser, systemd-virt-detect should be used instead, no?
[17:35] <xnox> sorry systemd-detect-virt
[17:35] <pitti> smoser: ah, you are saying we should fix grub to skip those bits in chroots too, not only containers?
[17:35] <pitti> xnox: yeah, see bug 1539016
[17:36] <cjwatson> it's much more ambiguous for chroots
[17:36] <smoser> hm..i guess i can do both. running-in-container actually works all the way back to precise.
[17:36] <cjwatson> recovery via chroot is a common use case
[17:36] <xnox> smoser, systemd-detect-virt -r and check exit code.
[17:36]  * pitti will read scrollback tomorrow, I need some food now -- been sitting here for too long, sorry
[17:42] <barry> doko: the trick is libpeas deps that actually have python in them.  bryan quigley did an initial search: https://bugs.launchpad.net/debian/+source/libpeas/+bug/1440504/comments/6
[17:43] <barry> doko: then i tried to look at deps to see if they were py2 or py3: https://bugs.launchpad.net/debian/+source/libpeas/+bug/1440504/comments/9
[17:43] <dobey> barry: oh fun, i guess you need to split the plug-ins into separate packages
[17:43] <barry> doko: it's possible we missed some, but that should be a good start
[17:43] <barry> dobey: yes, exactly
[17:43] <barry> and then update deps
[17:45] <dobey> barry: well, i'd just shove the py2 loader into a separate package, and leave the py3 one in the main package, and then only tweak the deps that require the py2 one still; to make life easier
[17:45] <barry> dobey: that could work too
[17:45] <barry> not a bad idea
[17:45] <dobey> much less work for you that way :)
[17:46] <doko> yes, that looks good.
[17:46] <doko> dobey, barry: do you know offhand if it's ok to move the loader into a multiarch subdir?
[17:48] <dobey> doko: that might be problematic, but i haven't looked deep enough into it to be sure; i know there are plenty of plug-in using things that make multi-arch hard to do for them, though
[17:48] <barry> doko: i don't know
[17:49] <cjwatson> pitti: could we get a retry request button for "always failed" tests as well?
[17:49] <doko> ohh, and a retry all button
[17:50] <doko> I mean, all archs
[17:52] <pitti> cjwatson: technically yes; practically I'm afraid of people hammering those without any chance of success
[17:52] <cjwatson> fair
[17:53] <ancaemanuel> cjwatson: why nobody care about apt ? https://bugs.launchpad.net/ubuntu/+source/lz4/+bug/1531923
[17:53] <pitti> doko: you can run "run-autopkgtest" and thus use retry-autopkgtest-regressions :)
[17:55] <ancaemanuel> pitti, can you merge lz4 ?
[17:56] <ancaemanuel> from debian ?
[18:01] <cjwatson> ancaemanuel: Please stop harassing me.  I assume Seth is busy at the moment; I'm very wary about rushing security review.
[18:03] <doko> caribou, sil2100, Laney: who is driving unity-settings-daemon and libunity-webapps these days?
[18:03] <sil2100> doko: hey! libunity-webapps I suppose it would be something for dbarth or someone from his team
[18:04] <sil2100> doko: not sure about unity-settings-daemon, but answering the earlier question: it's a CI Train managed package
[18:04] <ancaemanuel> cjwatson: oh, I do not want to harassing you.
[18:05] <ancaemanuel> I waited several days
[18:06] <ancaemanuel> more than a week
[18:07] <cjwatson> ancaemanuel: but it's not my problem so I've no idea why you're even asking me.  I just answered you once on IRC
[18:07] <cjwatson> MIR review is not a thing I do; MIR review is not a thing I even have permission to do
[18:07] <cjwatson> so asking me is pointless
[18:08] <ancaemanuel> ok, thank you for looking.
[18:08] <smoser> interestingly, in probably the most likely scenario of a chroot, 'systemd-detect-virt --chroot' exits 1 (not running in a chroot).
[18:08] <smoser> it only works if /proc is mounted. but in many, many chroot cases, that is not going to be so.
[18:11] <ancaemanuel> cjwatson: any ideea to what person to ping ?
[18:26] <sarnold> ancaemanuel: there's multiple packages in line before lz4. sorry.
[18:35] <mdeslaur> xnox: I'm doing virt-manager now
[18:41] <xnox> mdeslaur, \o/
[18:44] <mdeslaur> xnox: I found a 3/4 done 1.3.1 package in my scratch directory...apparently something shinier came up and I had forgotten about it :P
[18:45]  * xnox rapidly turns all the lights off, and hides all the blikies
[18:45]  * xnox rapidly turns all the lights off, and hides all the blinkies
[18:52]  * mdeslaur gets distracted by lights suddenly going out
[18:58] <pitti> caribou: looking much better
[18:59] <NikTh> UPod ? https://twitter.com/ubuntu/status/692739548107927553 :-)
[19:47] <jtaylor> are there plans on updating docker for xenial? I think we might be better of removing it than shipping 1.6 and confusing users
[19:48] <jtaylor> I expect in a year or two even 1.8 will be unusable because all tooling is updated to the new networking stuff in 1.9
[19:48] <sarnold> even if it gets updated to $latest_in_march it'll probably look pretty comical in 2021.
[19:48] <sarnold> I get the impression their idea of "backwards compatability" is measured in weeks, not years :)
[19:49] <jtaylor> actually its decently backward compatible, the issue are all the tools around it
[19:49] <jtaylor> they tend to use the latest stuff and remove old stuff quickly
[19:50] <jtaylor> e.g. compose won't even start unless the version matches the latest one, for no really good reason
[19:50] <jtaylor> (but at least there are hidden env variables to get it to work regardless)
[21:11] <xnox> mpt, i shall go down in history as freedom hater
[21:37] <smoser> how can i tell 'rrecommends'
[21:38] <smoser> the analog of apt-cache rdepends
[21:41] <smoser> cyphermox, wonder if you might know this.
[21:41] <smoser> a wily server install ended up with ubuntu-standard metapackage installed. but same preseed for xenial does not have that meta-package installed.
[21:42] <cjwatson> apt-cache rdepends shows both Depends and Recommends.  grep-aptavail/grep-dctrl is a good Swiss army knife for more detailed exploration.
[21:42] <smoser> yeah, i saw that.
[21:43] <smoser> thank you cjwatson.
[21:43] <cyphermox> smoser: cjwatson is quicker to respond. I blame the alphabet :)
[21:43] <smoser> me too. but he d idn't answer my second queestion
[21:43] <smoser> so you can still try
[21:43] <smoser> although unlikely you'll be able to beat cjwatson
[21:43] <cyphermox> ahah
[21:43] <smoser> :)
[21:44] <cyphermox> did we not discuss that last week?
[21:44] <smoser> i dotn know. maybe we did.
[21:44] <cyphermox> oh wait, no. I remember the change was in quantal
[21:44] <smoser> so... https://platform-qa-jenkins.ubuntu.com/view/smoke-default/ .
[21:44] <cyphermox> I suspect it's a matter of picking minimal or not when installing, if you're installing utah
[21:44] <smoser> smoke-default for xenial is insisting that 'irqbalance' is installed. and failing because it is not in xenial.
[21:45] <cyphermox> right, that's what we'd been discussing last week
[21:45] <cyphermox> or maybe you weren't around then
[21:45] <smoser> using the same preseed in both cases
[21:45] <smoser> so some behavior changed by design in d-i that would select minimal rather than standard ?
[21:45] <cyphermox> also, irqbalance seems to be in xenial?
[21:46] <smoser> (i also notice int he installed package lists, ubuntu-standard is not present in xenial, but is in wily)
[21:46] <smoser> and it is the only thing i see in 'rdepends' of irqbalance... ie, the only reason that package would be in there
[21:47] <cyphermox> yes
[21:47] <cyphermox> http://paste.ubuntu.com/14691070/
[21:47] <smoser> above "failing because it is not in xenial" meant failing because it is not installed by the preseeded install.
[21:47] <cyphermox> ^ looks like ubuntu-standard is installed here, this wasn't a preseeded install though
[21:47] <cyphermox> ok
[21:47] <cyphermox> smoser: could you show me the preseed?
[21:48] <smoser> http://bazaar.launchpad.net/~ubuntu-server-dev/ubuntu-test-cases/server-tests-raring/view/head:/preseeds/default.preseed
[21:49] <smoser> same preseed, same utah. run with wily, ubuntu-standard gets isntalled (and thus irqbalance). but run with xenial, there is no ubuntu-standard installed.
[21:49] <smoser> xenial: http://paste.ubuntu.com/14691083/
[21:50] <smoser> wily: http://paste.ubuntu.com/14691086/
[21:51] <cyphermox> oh, interesting
[21:51] <cyphermox> I might have broken tasksel after all
[21:57] <cyphermox> or not
[22:00] <cyphermox> smoser: I think the behavior changed: https://launchpad.net/ubuntu/+source/tasksel/3.34ubuntu3
[22:00] <cyphermox> smoser: try just 'server' rather than 'Basic Ubuntu Server'
[22:00] <smoser> well, fiddle though./
[22:01] <smoser> i'll have to have wily specific preseeds then ?
[22:01] <smoser> s/wily/xenial/
[22:01] <cyphermox> it's going to be like this from now on
[22:01] <cyphermox> it makes more sense to have the task name rahter than its short description anyway
[22:01] <smoser> it does, yes.
[22:02] <smoser> nuclearbob, ok. so that would seem to likely be it.
[22:02] <nuclearbob> smoser: okay
[22:03] <smoser> but we'll then need to generate those preseeds at utah-runtime from their templates based on input release.
[22:06] <nuclearbob> do we need to do that, or can we have different preseeds/jobs based on release?
[22:06] <nuclearbob> we have some scripts that select which preseed to use
[22:06] <nuclearbob> if we pass those options, we can have the scripts generate or select a preseed based on release
[22:08] <smoser> you're rigth. i guess we do not have to generate entirely.
[22:21] <smoser> cyphermox, i dont think this change worked.
[22:21] <smoser> -tasksel tasksel/first multiselect Basic Ubuntu server
[22:21] <smoser> +tasksel tasksel/first multiselect server
[22:22] <cyphermox> I can try in a bit.. just trying to get my parted SRU finished
[22:26] <smoser> is it perhaps the 'Task-Key' ?
[22:28] <smoser> which woudl be quite unfortunate. as ait is 'screen' for ubuntu.xenial/server task.
[22:28] <smoser> i'm testing that now.
[22:51] <doko> jtaylor, https://launchpad.net/ubuntu/+source/python-scientific/2.9.4-3build2 ?
[22:52] <jtaylor> doko: oldnumeric is gone from numpy since a while
[22:52] <jtaylor> 1.9 I think
[22:52] <jtaylor> if we are lucky that is just a renamespacing
[23:58] <smoser> cyphermox, i dont htink its the tasksel thing.
[23:58] <smoser> that preseed did in fact have 'Basic Ubuntu Server'
[23:58] <smoser>  tasksel tasksel/first multiselect Basic Ubuntu server
[23:59] <smoser> but changing that to 'server' didnt help.  and even with it as it was, grep shows