[04:37] <doko> apw, https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-352/+bug/1575451
[04:37] <ubottu> Launchpad bug 1575451 in nvidia-graphics-drivers-361 (Ubuntu) "PIE mode breaks building kernel modules" [Undecided,New]
=== unixpro1970 is now known as _unixpro1970
[05:19] <doko> Logan, not sure how UDD is involved, but people don't seem to care that a package actually lands in the release pocket (or they lack the time to get it there)
[05:19] <Logan> maybe Launchpad should have a way to show all of your package uploads that are stuck in proposed
[06:34] <pitti> Good morning
[06:50] <sladen> morning pitti
[07:05] <dholbach> good morning
[07:06] <sladen> http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_0b63afb3ebd5c7ca  kudos to slangasek infinity kees stgraber mdeslaur seb128
[08:00] <bipul> ttp://paste.ubuntu.net/16075814/ I was trying to compile dash source package, but i am getting error messages. And i don't see any .deb file in parent directory,only i can see dash_0.5.7-4ubuntu1_i386.build
[08:07] <dholbach> can somebody moderate my mail on the u-d-a list through?
[08:07] <pitti> dholbach: sure, doing
[08:07]  * dholbach hugs pitti 
[08:07]  * pitti hugs dholbach back, wie gehts?
[08:08] <dholbach> sehr gut, und dir? :)
[08:08] <pitti> prima, danke! endlich kein Schnee mehr :)
[08:08] <dholbach> :-)
[08:08] <sladen> the weather was just *weird* the last 36 hours
[08:09] <dholbach> pitti, typisches April-Wetter - Lisa war vor ein paar Tagen in Bayern und an einem Tag waren es 20°, sie hatte Sonnenbrand und zwei Tage später standen sie mit dem Auto im Schneegestöber
[08:10] <pitti> sladen: yeah, I like snow in January, but not after two weeks of finest spring weather with everything blossoming in the garden
[08:13] <sladen> dholbach: /me went ->Wiesloch (BW, summer's day) ->Rhineland-Pf (sleet, snow, sun, snow, sun, sleet, sun, snow) ->HD (rain, sun) ->Wuerzburg (found myself cycling in driving snow) and back at the office in HD there was 10cm of snow on somebody's car on an otherwise mild day
[08:13] <darkxst> dholbach, I just replied to your UOS email, but may as well just ask here
[08:13] <sladen> pitti: yeah, I like *proper* snow, when the air is dry
[08:14] <darkxst> can we run a an ubuntu GNOME session but outside the proposed hours?
[08:15] <dholbach> darkxst, I'll send an email to you and mhall119 about it
[08:15] <dholbach> I don't know
[08:16] <dholbach> sladen, nuts :)
[08:17] <darkxst> dholbach, ok thanks, I obviously can't stay up all night on weeknights ;)
[08:18] <dholbach> of course... and I know it's unfair to you :-(
[08:21] <darkxst> dholbach, speaking of which I submitted a GUADEC talk today ;)
[08:21] <darkxst> atleast in that case I will travel to their timezone ;)
[08:21] <dholbach> nice :-)
[08:23] <bipul> Hi anyone around?
[08:24] <davmor2> bipul: lots
[08:27] <bipul> Can anyone tell me ? why i am not able to create .deb file, from source package of dash.
[08:27] <bipul> http://paste.ubuntu.net/16075814/
[08:30] <sladen> bipul: how did you obtain the source?
[08:30] <bipul> sladen, apt-get source dash
[08:31] <bipul> I am able to create only dash_0.5.7-4ubuntu1_i386.build
[08:31] <bipul> not .deb :(
[08:31] <darkxst> pull-lp-source dash is safer!
[08:31] <bipul> let me try.
[08:32] <darkxst> you need ubuntu-dev-tools installed though
[08:32] <darkxst> I'm out for dinner
[08:32] <bipul> ok darkxst Thank you
[08:33] <bipul> pull-lp-source: Warning: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details.
[08:33] <bipul> Or specify a distribution.
[08:33] <bipul> :(
[08:38] <sladen> bipul: have you done a   sudo apt-get build-dep dash  first too?
[08:43] <bipul> sladen, is there anyway to get the source from bzr?
[08:44] <bipul> sladen, yes i executed that command. sudo apt-get build-dep dash before performing pull-lp-source dash
[08:44] <mwhudson> bipul: did you run sudo apt-get source?
[08:45] <mwhudson> because you don't need sudo for that
[08:46] <bipul> mwhudson, Yes that also i had run, and i got 3 files and 1 directory with starting name "dash"
[08:46] <doko> apw, tyhicks: could one of you merge schroot?
[08:48] <bipul> oh yes, mwhudson thank you
[08:53] <doko> seb128, is the "don't merge" comment for vino still appropriate?
[08:54] <seb128> doko, yes
[08:59] <cpaelzer> pitti: first of all thanks for making me aware that DPDK needs an Y upload as well to let the SRU X upload progress to updates
[09:00] <cpaelzer> pitti: since ubuntu7 was copied from xenial this doesn't need more than a "dch --release --distribution yakkety" before creating an upload right (no new tarball or other special things)
[09:00] <cpaelzer> pitti: I made sure it sbuilds fine in Y, but wanted to check if there woudl be more needed
[09:00] <pitti> cpaelzer: no, not really; the main point is that it builds with the Y toolchain and works with that
[09:01] <pitti> cpaelzer: we also have some library transitions already, so binary  copies might end up linking to the wrong (old) ones
[09:01] <cpaelzer> pitti: ok, that the two Y sbuilds should have ensured I think
[09:01] <cpaelzer> pitti: thanks
[09:03] <cpaelzer> is there a way to also adt for Y locally before https://cloud-images.ubuntu.com/yakkety... exists?
[09:03] <pitti> cpaelzer: lxd has yakkety images already
[09:04] <pitti> cpaelzer: if you need QEMU: what I did was to copy the xenial VM to -yakkety, boot it, change apt sources and dist-upgrade
[09:04] <cpaelzer> thats a nice experiment to do
[09:05] <pitti> not that much experimental, it's a well-proven approach :)
[09:15] <tsdgeos> seb128: do you know why there's no uptodate libflac8-dbgsym at http://ddebs.ubuntu.com/pool/main/f/flac/ ? it has 1.3.0 instead of 1.3.1 or do you know anyone that may know why?
[09:15] <seb128> tsdgeos, ddebs are in launchpad now
[09:16] <seb128> tsdgeos, like on https://launchpad.net/ubuntu/+source/flac/1.3.1-4/+build/7763370
[09:16] <seb128> you have debs and ddebs
[09:16] <tsdgeos> seb128: you mean there's no repo i can use anymore?
[09:16] <seb128> tsdgeos, the old server is only useful for things that didn't get rebuilt since those got moved to launchpad
[09:17] <tsdgeos> seb128: still https://launchpad.net/ubuntu/+source/flac/1.3.1-4/+build/7763370 doesn't have the dbgsym either
[09:17] <seb128> it has?
[09:17] <seb128> 3rd item
[09:17] <seb128> in "built files"
[09:17] <tsdgeos> seb128: that's not for libflac8
[09:17] <tsdgeos> it's for libflac6++
[09:18] <seb128> hum, indeed
[09:19] <mwhudson> "libflac8 has no unstripped objects, ignoring" says the build log
[09:20] <tsdgeos> weird, since nm /usr/lib/x86_64-linux-gnu/libFLAC.so.8.3.0 gives me no symbols
[09:20] <tsdgeos> so i guess they were stripped?
[09:21] <seb128> tsdgeos, right, that's what the error says
[09:21] <seb128> the binary was already stripped
[09:21] <tsdgeos> ah you mean before trying to strip/create the dbgsym
[09:21] <mwhudson> or compiled without -g maybe?
[09:21] <seb128> yes
[09:21] <Odd_Bloke> pitti: lxd already has yakkety images?  I thought they were meant to pull from cloud-images.u.c to produce theirs...
[09:22] <seb128> tsdgeos, what mwhudson says, maybe no -g so the binary never had the symbols?
[09:22] <pitti> Odd_Bloke: on images: (i. e. https://images.linuxcontainers.org/), not on ubuntu:
[09:22] <mwhudson> Odd_Bloke: no ubuntu-daily:yakkety, but there is images:ubuntu/amd64/yakkety
[09:22] <pitti> Odd_Bloke: we use images: in production, as these are much smaller and nicer than the cloud ones
[09:22] <Odd_Bloke> Ah, OK, images:.
[09:23] <Odd_Bloke> pitti: You know they aren't actually official Ubuntu images though, right? :p
[09:23] <pitti> Odd_Bloke: I do, yes; but neither are the adt ones I construct for our nova runners :)
[09:23] <Odd_Bloke> :)
[09:23] <pitti> with the huge purge list
[09:24] <tsdgeos> seb128: ok, i see
[09:24] <pitti> Odd_Bloke: so we don't need to download LXD images three times the size and do http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed#n183
[09:33] <xnox> Odd_Bloke, whilst i understand lxd on cloud-images, it makes no sense in the lxd image...
[09:33] <xnox> stgraber, ^
[09:33] <xnox> i know it can do nested lxd, but i don't see why that should be a default.
[09:34] <Odd_Bloke> xnox: The lxd images is a cloud images; there may be some things in there that don't make sense (e.g. open-vm-tools), but that's a compromise that's being made to avoid a (further) proliferation of images.
=== muktupavels is now known as muktupavels_
[09:35] <xnox> Odd_Bloke, it's not a cloud image, because it's a separate tarball =)
[09:35] <xnox> shipping useless blobs in a tarball, that may or may not be present in .img is well useless.
[09:35] <Odd_Bloke> xnox: No, it isn't; lxd consumes the root .tar.xz and an additional metadata tarball.
[09:36] <Odd_Bloke> The root .tar.xz _is_ the cloud image, minus kernel.
[09:36] <xnox> Odd_Bloke, is it known for .tar.xz to be used in booted instances (e.g. virtual machines)?
[09:36] <xnox> or bare metal?
[09:36] <Odd_Bloke> xnox: I believe MAAS use it and install a kernel in it (because they want the generic kernel, not the virtual kernel).
[09:39] <xnox> Odd_Bloke, smoser: that's a weird statement. Given that -virtual depends on -generic... it's the same kernel. The difference is the installation of -extra and firmware.
[09:39] <Odd_Bloke> xnox: I may be mistaken.
[09:39] <xnox> obviously kernel is not needed on the lxd images.
[09:40] <xnox> Odd_Bloke, if we remove lxd from the tarball images.... they could probably superseed all of the ubuntu-core tarballs we generate and ship.
[09:40] <xnox> infinity, what do you think ^ ?
[09:40] <xnox> slangasek, ^
[09:40] <Odd_Bloke> xnox: Image consolidation is a conversation we'll be having in Austin next week. :)
[09:41] <xnox> Odd_Bloke, let me check if cloud images discriminate powerpc ;-)
[09:41] <Odd_Bloke> xnox: Discriminate?
[09:42] <xnox> Odd_Bloke, i see there are powerpc lxd/lxc tarballs in place, so all is good.
[09:42] <xnox> i remember at some point lxd images were not generated for arches that don't have cloud-images or some such.
[09:42] <Odd_Bloke> xnox: That's because the lxd images _are_ cloud images. :p
[09:43]  * xnox rolls eyes
[09:43] <xnox> Odd_Bloke, where is this austin discussion? can you invite me there too?
[09:45] <Saviq> pitti, hey, does the adt-run output at the end of https://unity8-jenkins.ubuntu.com/job/test-ppa-autopkgtest/142/label=amd64,package=unity8,release=vivid+overlay,testname=qmluitests.sh/console make sense to you?
[09:46] <Saviq> has there been a change recently in adt-run that could cause that?
[09:54] <pitti> Saviq: not that I remember, but I'll look into that, thanks
[10:02] <mwhudson> i have a small pile of packages i want to do something to, and i want to do it to depended-on packages before the depending packages
[10:02] <mwhudson> is there tooling for this already? transitions must be a bit like this
[10:11] <doko> chrisccoulson, there is a new firefox-esr package in yakkety. should that be blacklisted or built?
[10:11] <chrisccoulson> doko, that should definitely be blacklisted
[10:12] <doko> chrisccoulson, and thunderbird is in http://people.canonical.com/~ubuntu-archive/nbs.html
[10:12] <mapreri> i'm looking at the inkscape delta between ubuntu and debian.  i wonder, is there any way to avoid the delta on the translation things?  can't ubuntu's debhelper add it to it's sequencer or something instead?
[10:19] <bdrung_work> pitti, hi. can you explain how you/we fixed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=751636 in Ubuntu?
[10:19] <ubottu> Debian bug 751636 in openssh-server "ssh sessions are not cleanly terminated on shutdown/restart with systemd" [Important,Open]
=== muktupavels__ is now known as muktupavels
[10:19] <Wulf> Hello
[10:19] <Wulf> Is there any chance https://bugs.launchpad.net/ubuntu/+source/msktutil/+bug/1568714 will get fixed in 16.04?
[10:20] <ubottu> Launchpad bug 1568714 in msktutil (Ubuntu) "stack smashing detected ***: msktutil terminated for version 0.5.1+git8158aa2b-1" [Undecided,Confirmed]
[10:24] <doko> chrisccoulson, done
[10:26] <Wulf> Or could you link me a policy that described what will (not) be updated before the next release?
[10:40] <cjwatson> Wulf: I haven't looked at the specific bug in question, but the policy doc is https://wiki.ubuntu.com/StableReleaseUpdates
[10:41] <pitti> Saviq: hm, this code hasn't changed in ages (since July 2014)
[10:42] <pitti> Saviq: /dev/tty not being present in the job sounds a bit fishy; but what's more fishy is why a Jenkins job runs with --shell or --shell-on-failure (-s) in the first place -- that's never going to work
[10:46] <pitti> Saviq: I committed http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=c13bab9fb to provide a nicer error; but you really should drop this --shell-fail
[10:46] <pitti> Saviq: if it would actually work, it would block the job forever
[10:47] <pitti> Saviq: another thing: you pass DEB_BUILD_OPTIONS=parallel=4 to adt-run, but that's not generally going to work for testbeds; pass adt-run --build-parallel=4 instead
[10:47] <pitti> Saviq: it defaults to nproc, so maybe you don't even need to set this in the first place
[10:49] <Wulf> cjwatson: thanks, will read through it
[10:56] <Wulf> ``3.1 Check that the bug is fixed in the current development release, and that its bug task is "Fix Released".''  Is there such a "development release", is it "Yak"?
[10:58] <Saviq> pitti, oh yeah, the --shell* was a debug thing, /me drops
[10:58] <Wulf> It it correct that first someone needs to make a new package with the patch applied and upload it into yak?
[10:58] <Saviq> pitti, sorry about the noise, /my fault completely
[10:58] <pitti> Saviq: no worries, this was a nice cosmetic fix
[11:05] <Odd_Bloke> Wulf: Yep, yakkety is the current development release.
[11:08] <doko> apw, sbeattie: please address https://bugs.launchpad.net/bugs/1574982
[11:08] <ubottu> Launchpad bug 1574982 in ubuntu (Ubuntu) "Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler" [Undecided,Confirmed]
[11:09] <Odd_Bloke> mvo: o/ I'm trying to puzzle out the default unattended upgrades behaviour for kernels in xenial, but can't quite work it out; will older kernel packages be cleared out of the system by default?
[11:09] <apw> doko, yeah ... is that fallout from -fpie or has that just gone away ?
[11:09] <doko> apw, looks like pie
[11:10] <doko> so maybe needs fixing in dkms as well?
[11:10] <Odd_Bloke> I second infinity's hunger-related complaint about that TLA. :p
[11:10] <apw> doko, so turning pie off which we should be doing at least for now in the kernel
[11:10] <apw> doko, i am expecting that dkms is using the kernel headers, speficially the Makefile from there to get that
[11:10] <mvo> Odd_Bloke: hey, the details can be found here: http://paste.ubuntu.com/16077278/
[11:11] <apw> doko, so if we fix the kernel we might fix that...
[11:11] <apw> doko, oh damn, of course that kernel is in xenial and copied forward, so _fun_
[11:12] <doko> apw, already told the security team not to binary-copy stuff from xenial ...
[11:13] <apw> doko, right ... though for the kernel as we are about to turn of pie there ... prolly we can do so still
[11:13] <apw> though i guess, if we have to, we cna upload it as +yakkety
[11:13] <Odd_Bloke> mvo: Ah, handy; and is autoremove enabled by default in xenial, or would these rules only apply when running it manually?
[11:14] <Odd_Bloke> mvo: (autoremove as part of unattended-upgrades, that is)
[11:15] <mvo> Odd_Bloke: autoremove is enabled as part of unattended-upgrades, but it will only remove unneeded dependencies that became unneeded during that run. so it might be worthwhile to test if there are any unexpected side effects but it should work
[11:15]  * mvo lunches
[11:16] <Odd_Bloke> mvo: Cool, thanks!
=== xavigarcia is now known as xavigarcia_lunch
[11:53] <cpaelzer> cjwatson: I just sent also the current memory allocations - in general if the s390 resource allocations become an issue once you work with IS about it let me know to help sorting things out
=== _salem is now known as salem_
=== xavigarcia_lunch is now known as xavigarcia
[12:44] <barry> Unit193: thanks.  sorry i couldn't ever get to it, but i'll look at it for yakkety
=== Laney is now known as seb128smum
=== seb128smum is now known as Laney
[13:28] <smoser> xnox, ubuntu server is ubuntu server is ubuntu server.  Wherever we produce it it acts the same.  That does have some cost of inert things installed.  all images have ubuntu-server metapackage installed.  At this point the maas image is only one file different from the lxd image (and that one file can actually go away now).
[13:30] <pitti> I know that this is a design decision, but it's really not the only one that makes sense IMHO
[13:30] <pitti> a "pet server" is conceptually quite different from a "cattle instance" in terms of how much stuff/hw support/interactivity you need
[13:31] <xnox> nested lxd support is a niche thing
[13:32] <xnox> landscape monitoring per container doesn't make sense either
[13:32] <pitti> and mdadm/lvm/iscsi/ppp/cryptsetup etc. don't work in lxc at all
[13:33] <xnox> imho LXD image must slim
[13:33] <pitti> but yeah, we've gone through this several times; we have https://images.linuxcontainers.org/ and they are nice
[13:34] <pitti> I wish juju could use those too
[13:37] <xnox> pitti, hm, juju does want to have lxc/lxd available to deploy thing to an instance, in a container.
[13:37] <pitti> xnox: sure, but on the host, not in the juju instance
[13:38] <pitti> also, apt-get install lxd :)
[13:38] <xnox> pitti, nah, not on the host... in the target juju instance.
[13:38] <pitti> xnox: it doesn't do nesting, no
[13:39] <xnox> juju deploy mysql --to 24/lxc/3
[13:39] <xnox> deploy into 3rd container on 24th machine
[13:39] <xnox> pitti, https://jujucharms.com/docs/1.25/charms-deploying
[13:39] <xnox> totally does
[13:39] <xnox> and for that magic to work, you do need lxc on the juju instance
[13:39] <pitti> xnox: well, that's really not the default mode
[13:40] <pitti> and, as said, if juju wants/needs that, it should explicitly install lxd either way
[13:40] <xnox> sure, maybe juju should learn to deploy subordinate "lxc" to the machine before sub-deploying containers?
[13:45] <cjwatson> cpaelzer: Thanks, good to know.  We can probably also just rebalance things a little during the transition; having 28 really fast builders is obviously great fun and helped the bootstrap a lot, but it's a bit less vital now.
[13:53] <cpaelzer> cjwatson: ok, just wanted to provide the vital data and a helping hand
[13:53] <cpaelzer> cjwatson: IS really tries but s390 can be crazy stuff
[13:53] <cpaelzer> cjwatson: balancing surely is a good approach in the transition
[13:54] <cpaelzer> cjwatson: due to the SSI cluter we can balance nicely without "loosing" an active guest
[13:54] <cpaelzer> cjwatson: but I understand your balancing suggestion as slowly going down from 28 to less builders
[13:55] <cpaelzer> right?
[13:55] <tyhicks> doko, apw: I can merge schroot because there's another patch that I need to add to it
[13:55] <apw> tyhicks, works for me :)
[13:56] <cjwatson> cpaelzer: right
[13:56] <nebuchadnezzar> I finally found why my custom xenial ISO were not working as expected: https://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/tools/boot/xenial/boot-amd64#L644
[13:56] <nebuchadnezzar> just put my stuff before that line and it's embedded in the bootlogo, and everything works
[13:57] <cjwatson> cpaelzer: Do you know where our 328G total current in use comes from?  We have 28 builders with 8G each, which is 224G; 104G seems like an awful lot of overhead
[13:58] <cjwatson> cpaelzer: I can't make the arithmetic come out to the value you quote
[13:58] <cpaelzer> cjwatson: while I have no insight into the system I know that all foundation z/VM guests are on the same Hosts
[13:59] <cjwatson> cpaelzer: I thought they were very specifically and deliberately on separate LPARs
[13:59] <cjwatson> cpaelzer: indeed you list separate ones for Foundations, don't you?
[14:00] <cpaelzer> cjwatson: the other LPARs are "forbidden", but nothing can escape the z/VM configuration
[14:00] <cpaelzer> cjwatson: The Foundation guests get into the right (= not yours) VLAN by the VSWITCH config in the z/VM Host
[14:00] <cjwatson> cpaelzer: well; so this seems to me like 104G which needs to be accounted for somehow and could perhaps be reclaimed for use in a transition to scalingstack
[14:00] <cpaelzer> cjwatson: they can't do anything to leave theirs or reach your vlan
[14:01] <cjwatson> cpaelzer: it certainly doesn't fit the memory allocations that you outlined
[14:01] <cpaelzer> cjwatson: oh yes, it could very well be just oversized and could be shrinked in the progress of that transition
[14:01] <cjwatson> cpaelzer: maybe S0LP1 and S0LP2 just have more memory allocated to them than they in fact need?
[14:01] <cjwatson> right
[14:12] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1575572
[14:13] <ubottu> Launchpad bug 1575572 in cloud-init (Ubuntu) "apache2 fails to start if installed via cloud config (on Xenial)" [Undecided,Confirmed]
[14:13] <smoser> so that bug says that telling cloud-init to install apache2 results in apache2 not running.
[14:13] <smoser> you can do that either with cloud-config or with just:
[14:13] <smoser>  apt-get install -q -y apache2
[14:13] <smoser> in a '#!'
[14:14] <smoser> i think that is essentially because one systemd service is running (cloud-init) and so somehow the newly installed package doesn't get processed.
[14:15] <xnox> the postinst should be doing daemon-reload and start apahce2
[14:16] <xnox> can you extract and who the logs?
[14:16] <xnox> of dpkg/apt?
[14:16] <smoser> 'who' ?
[14:17] <xnox> cjwatson, there are other non-lp builders z/vms running on lp lpars.
[14:17] <xnox> cjwatson, but that's okish, as z/vms have network & disk segregation, as in no disks nor network is visible apart from the parts that are specific to a paricular z/vm
[14:18] <xnox> smoser, no idea how that got typed, or what i was trying to say there =)
[14:19] <smoser> xnox, well, i'll get you some data here. easily re-creatable in lxc
[14:20] <xnox> smoser, well we need apt/dpkg output to see what it was doing
[14:27] <smoser> xnox, http://paste.ubuntu.com/16081486/
[14:27] <xnox> smoser, that does not look like apt/dpkg output =)
[14:28] <xnox> ah this one http://paste.ubuntu.com/16081365/
[14:28] <smoser> yeah, apt is happy.
[14:28] <smoser> thinks the world is fine
[14:29]  * davmor2 sees the number of wars breaking out across the globe and thinks smoser is lying ;)
[14:30] <smoser> apt is happy though.
[14:30] <smoser> ignorance is bliss
[14:30] <cjwatson> xnox: tell the thread or this knowledge will get lost. :)
[14:31] <xnox> cjwatson, i am confused
[14:31] <xnox> smoser, yeah, so it should have run
[14:31] <xnox> update-rc.d apache2 defaults >/dev/null
[14:31] <cjwatson> xnox: it's still not accurate to account this memory use to LP, though, even if it's piggybacking on our LPARs
[14:31] <xnox> invoke-rc.d apache2 start || true
[14:31] <xnox> cjwatson, =)))))
[14:32] <smoser> xnox, where are you looking ?
[14:32] <xnox> smoser, i wonder if you can inject in cloud-init to run things without redirection to dev/null
[14:32] <xnox> e.g.
[14:33] <xnox> update-rc.d apache2 defaults
[14:33] <xnox> invoke-rc.d apache2 start
[14:33] <xnox> and check the logs as to what happens.
[14:33] <xnox> or maybe even run those two commands just now
[14:33] <xnox> smoser, i'm looking in /var/lib/dpkg/info/apache2.postinst
[14:34] <xnox> also i find it weird that we ship _both_ init script for apache2, /lib/systemd/system/apache2.service.d/apache2-systemd.conf systemd sub-snippet
[14:34] <xnox> but no systemd unit
[14:36] <xnox> smoser, what does $ grep apache /etc/init.d/.depend.start have?
[14:37] <smoser> http://paste.ubuntu.com/16081721/
=== salem_ is now known as _salem
[15:47] <pitti> mvo, juliank: I just discovered that in some cases apt-cache policy pkg gives me information about several packages, none of which is pkg: http://paste.ubuntu.com/16083336/
[15:47] <pitti> am I doing anything wrong there? can I influence this somehow?
[15:48] <pitti> apt-cache policy is documented to take package names, not regexps
[15:49] <pitti> ah, if there's an exact match it uses that, but if the package does not exist it silently switches to regexp mode
[15:58] <slangasek> sladen: thanks for standing!
[16:00] <sladen> slangasek: still don't know who nominated me...
[16:01] <bdmurray> tyhicks: Is there somebody who could look at the last comment in bug 1471645?
[16:01] <ubottu> bug 1471645 in apparmor (Ubuntu) "[trusty] [regression] chromium-browser crashed with SIGABRT in base::debug::BreakDebugger()" [Medium,Confirmed] https://launchpad.net/bugs/1471645
[16:06] <infinity> pitti: Huh.  My apt-cache doesn't switch to regex mode...
[16:09] <tyhicks> bdmurray: we'll likely be working on underlying AppArmor changes to fix the user namespace issues causing the need for 'capability sys_admin,'
[16:09] <tyhicks> bdmurray: that's obviously something that you don't want your browser to have
[16:13] <nemo> I'm in a bit of a fun situation w/ a 64 bit ubuntu... Up until the last vmware server update I was successfully using the 64 bit 4.5 view client with a manually maintained opensc (to fix the exports from upstream that haven't made it into ubuntu yet)
[16:13] <nemo> Last update of server broke communication w/ client so have to switch to 5.0 - and here's the odd thing.
[16:14] <nemo> Ubuntu only offers vmware-view-client 5.0 in 32 bit.  That implies some upstream non open source blob
=== Elimin8r is now known as Elimin8er
[16:14] <nemo> Fine.  No problem, let me see if I can fix it.. But, Ubuntu also does not offer :i386 versions of opensc/pcscd which would be needed to actually use the client against a server using smartcards
[16:15] <nemo> I was hoping #ubuntu-devel might be able to tell me if manually figuring out how to package :i386 versions of those libs is an insane thing for me to embark on or not
[16:18] <nemo> (this is from someone who has an itsy bitsy passing familiarity w/ deb packaging w/ some help from Locutus)
[16:22] <infinity> juliank: https://patches.ubuntu.com/p/python-apt/python-apt_1.1.0~beta2ubuntu1.patch <-- Plz to apply to Debian git.
[16:23] <nacc> nemo: when you say "Ubuntu only offers ..." where is "vmware-view-client"? I don't see it in the archives?
[16:23] <nemo> OMG. Network admin coworker just showed me a screenshot from some vmware thingy of his that says "64 bit vmware view client for linux"
[16:23] <nemo> sure hope it is 5.0 the date seems promising
[16:23] <nemo> nacc: weird. wonder where I'm getting it from. I just installed it in 14.04 lts
[16:23] <nemo> lemme dig it up on ubuntu's website
[16:24] <nemo> http://www.ubuntuupdates.org/package/canonical_partner/trusty/partner/base/vmware-view-client  shows up here FWIW, but looking for official link
[16:24] <infinity> It's in the partner archive.
[16:24] <nacc> ah, partner
[16:24] <nemo> https://launchpad.net/ubuntu/trusty/+package/vmware-view-client
[16:24] <nemo> ok
[16:24] <nemo> Anyway. Looks like there might be a 64 bit one that ubuntu isn't packaging. here's hoping.
[16:24] <nemo> gonna revert all the damage I've done to my libs so far flailing about w/ i386
[16:25] <infinity> And yes, the newer versions ship 64-bit binaries.
[16:25] <infinity> I'll be pushing those soon.
[16:26] <nacc> infinity: how does the partner repo work? does canonical support those packages? or does the partner? (or both, i guess) is it just for ease of use?
[16:26] <nemo> infinity: omg you are??
[16:26] <juliank> infinity: Applied - https://anonscm.debian.org/cgit/apt/python-apt.git/commit/?id=2e1e4a5
[16:26] <nemo> infinity: can you link me to the .deb?  it might be a better call than whatever the heck my coworker is going to give me
[16:26] <nemo> infinity: I wonder if I'll have to still maintain my own opensc
[16:26] <infinity> nacc: It's based on contracts with said partner, as well as unsuitability for the real archive.
[16:27] <infinity> nacc: ie: if a contract allows only Canonical to redistribute the non-free blob of doom, we can't slap it in multiverse, which gets mirrored all over the world.
[16:27] <nemo> yeah, my understanding is the open client got pulled 'cause vmware cancelled their contract *and* hadn't pushed any new code since initial release in 2012
[16:27] <nemo> (boo)
[16:28] <infinity> juliank: Ta.
[16:28] <nemo> stupid vmware view website still links to canonical's "open" client from 2012 if you look for linux
[16:28] <nemo> s/view//
[16:28] <nacc> infinity: ah got it, thanks!
[16:29] <infinity> nacc: As for who "supports" partner, that's a bit muddier.  It's Canonical, and the partner, as you surmise, but given that most of it is non-free binary blobs, there's very little Canonical can do except forward your anger to our partner and hope. :P
[16:29] <infinity> nacc: So, y'know, I wouldn't recommend you use any of the stuff we ship in there unless you have no choice.
[16:29] <nacc> infinity: right that's what i was curious about :)
[16:30] <nemo> infinity: yeah, I was much happier w/ the open client and stuck w/ it right up until server started crashing it
[16:33] <nemo> I guess since the 4.5 client is open I could in theory try to make a debug build and work aroudn the crash but that's a bit more time than I want to invest in this ☺
[16:33]  * nemo shudders and runs the VMWare installer on his poor pristine ubuntu system
[16:34] <nemo> agh. has system services too
[16:34] <nemo> maybe I should have waited for infinity's .deb - god knows how I'm going to ever clean this up
=== mcasadevall is now known as NCommander
[16:40] <nemo> infinity: just FYI, the new VMWare View 64 bit client appears to be working perfectly, but only once I apply the exact same fixes as with the old 4.5 one
[16:41]  * nemo adds an addendum to the launchpad bug
[16:43] <nemo> https://bugs.launchpad.net/ubuntu/+source/vmware-view-client/+bug/1268770/comments/8
[16:43] <ubottu> Launchpad bug 1268770 in vmware-view-client (Ubuntu) "Error loading shared library for smart card authentication to server" [Undecided,Confirmed]
[17:04] <bdmurray> pitti: ddebs seems to me missing yakkety-updates, should it be?
=== rcj` is now known as rcj
=== rcj is now known as Guest12905
=== Guest12905 is now known as rcj
=== _salem is now known as salem_
[19:57]  * Unit193 waves to a wild sarnold.
[19:58] <sarnold> hey Unit193 :)
[20:46] <pitti> bdmurray: I fixed this earlier today, it's there now
[20:46] <pitti> xnox: ^ FYI
[20:47] <pitti> http://ddebs.ubuntu.com/dists/yakkety-updates/
[20:49] <bdmurray> pitti: great, thanks
[20:52] <sidi> I'm having a dramatic situation with my PPA. I have forks of the glib, gtk, etc, and almost every Xfce package on it (with custom patches). Recently my glib package seems to have become uninstallable. It seems to conflict with my Xfce packages (which I've ported to make multiarch). I've only noticed the issue today so I dont know what triggered the problem, only that my users are running some old version of the glib. How can I get apt-get to tell me w
[20:52] <sidi> hy my current libglib2.0-0 conflicts with other packages?
[20:52] <sidi> when I upgrade it says the glib packages (and the linux headers too for some reason) are being kept back
[21:06] <sarnold> sidi: do you have any errors you can copy-and-paste? that usually helps
[21:09] <bipul> http://paste.ubuntu.net/16088679/ can anyone tell me what went wrong?
[21:20] <dobey> bipul:  pbuilder-satisfydepends-dummy : Depends: texinfo which is a virtual package and is not provided by any available package.
[21:22] <dobey> sidi: packages held back during upgrade may just have new binary dependencies or such. you need to dist-upgrade to see what will happen when you try to install them
[21:22] <dobey> sidi: or you can just try to install libglib2.0-0 itself to see what happens for only it
[21:24] <bipul> dobey, can you explain more about pbuilder? and how to use pbuilder for source package?
=== salem_ is now known as _salem
[21:26] <dobey> bipul: you really should use sbuild instead, but seems like perhaps you don't have universe repository enabled in your pbuilder chroot
[21:27] <bipul> dobey, Yes, it is not been enable, since i am on VPS
[21:27] <dobey> vps has nothing to do with the pbuilder chroot
[21:28] <sidi> dobey, ive done that and it's removed a lot of packages. i've got skype:i386 that is no longer installable, knowing that i added deps to my libglib2.0-0 (and other glib packages). Im considering the possibility that if i add a dep to a multiarch source package, which itself is not multiarch, then the resulting libraries built from that source package would no longer be multiarch? that makes very little sense but i cant formulate another hypothesis
[21:32] <dobey> sidi: if you link to a new binary that is not multiarch, then yes, that may cause problems
[21:32] <slangasek> the glib2.0 is still multiarch, but that doesn't mean it will be coinstallable if its dependencies aren't
[21:33] <sidi> dobey, i'm pretty sure this is what happened. i linked to a package because i now use some of its headers, but that package is, originally, not complying to FOSS standards much. It's a mix of headers, libraries and binaries. I'll cut it into multiple bits and see if it works better
[21:33] <dobey> sidi: ie if skype:i386 depends on libglib2.0-0:i386, and you changed glib2.0 to depend on libfoo which is not multiarch, then libglib2.0-0:i386 will not be installable without libfoo:i386, but libfoo:i386 and libfoo:amd64 can't both be installed
[21:33] <sidi> dobey, slangasek how would i verify that this is the issue though? can I get apt-get to give me more infos what deps arent satisfied?
[21:33] <slangasek> you also need to have built glib for all relevant archs, you can't mix and match across versions
[21:34] <dobey> sidi: apt-get would have told you what apt was going to do, and you can infer from that what happened
[21:35] <dobey> anyway, i have to go. later
[21:36] <sidi> slangasek, i think it's "well" built for both amd64 and i386. The problem is it cant be installed on amd64 systems that have existing, well built i386 binaries depending on the i386 glib. Or the other way around, such i386 binaries cant be installed any more after the amd64 glib is installed
[21:36] <sidi> dobey, thanks either way, i believe you're right
[21:36] <sidi> going to try and fix that now.
[22:51] <mwhudson> is mk-sbuild setting preserve-environment on the schroots it creates really sane?
[23:14] <infinity> mwhudson: I don't see that in the code...
[23:15] <mwhudson> hm
[23:15] <mwhudson> wonder where it comes form then
[23:15] <mwhudson> oh, i clearly cargo-culted ~/.mk-sbuildrc from somewhere silly
[23:16] <mwhudson> i.e. https://wiki.ubuntu.com/SimpleSbuild
[23:30] <dmick> hi all.  I am puzzling over a question of install behavior that makes me want to browse the code comprising the ubuntu non-LiveCD installer
[23:31] <dmick> which I gather is based heavily on debian-installer, but probably there are ubuntu-specific mods.
[23:31] <dmick> where should I look to start understanding the structure of the installation boot  (what programs run when, where are there sources,etc.)?
[23:32] <dmick> (this is in service of the question "who creates /etc/init/ttySn.conf to start the getty for my SoL device, pre-systemd")
[23:33] <sarnold> dmick: iirc server images use https://launchpad.net/ubuntu/+source/debian-installer and desktop images use https://launchpad.net/ubuntu/+source/ubiquity
[23:34] <dmick> sounds right; wonder if there's a "flow of operations" doc somewhere
[23:41] <tarpman> https://launchpad.net/d-i has a nice list of the components involved, not sure about such a doc though
[23:46] <cjwatson> dmick: https://d-i.alioth.debian.org/doc/internals/
[23:46] <cjwatson> dmick: I can answer your actual question directly if you like, but only if you actually want that rather than having the learning experience
[23:47] <sarnold> :)
[23:47] <dmick> well it's complicated :)
[23:47] <dmick> but yes I'd welcome a cheatsheet in this instance
[23:48] <cjwatson> dmick: it's in the finish-install package (you won't be able to apt-get install that, but apt-get source should work), finish-install.d/90console
[23:48] <dmick> ooh, that would have been annoying to try to find on my own, I bet
[23:48] <dmick> thank you
[23:49] <cjwatson> np
[23:50] <dmick> and that alioth doc is awesome too; I assume the ubuntu process is largely similar with small patches then?
[23:58] <cjwatson> dmick: The general structure is pretty close, yes.
[23:59] <cjwatson> And yes, the internals doc is good.  RIP Frans. :-(