[04:48] <janimo> 851256
[05:24] <pitti> Good morning
[05:33] <tnkhanh> do people use switch-case nowadays?
[05:33] <tnkhanh> I always use if-else
[06:57] <smb> hallyn, thanks
[07:27] <Laibsch> micahg: do you have a minute?
[07:28] <micahg> Laibsch: sure
[07:29] <Laibsch> re bug 1438025. I admit to not being 100% certain about the proposed change, either. But the link you posted makes me believe that it is correct even more.
[07:30] <Laibsch> security.ubuntu.com is only a subset of the packages available in the true mirror network, I believe.  The purpose is to allow for quicker distribution of security-related updates.
[07:30] <Laibsch> As such, anything available in security.u.c is a subset of the mirror pool.
[07:30] <micahg> Laibsch: I think the idea is that individuals shouldn't be mirroring security.ubuntu.com and that the updates are actually copied to the -updates pocket within a short amount of time
[07:30] <Laibsch> Correct?
[07:31] <Laibsch> the proposed change wouldn't have that effect
[07:31] <Laibsch> quite the opposite
[07:31] <Laibsch> it would lower the burden on security.u.c
[07:32] <Laibsch> at least that is my understanding and experience of acng
[07:32] <micahg> isn't that list used for pre-caching
[07:32] <Laibsch> nope, not at all
[07:32] <Laibsch> it defines a list of equivalents
[07:34] <Laibsch> so, if a package is already in the cache, then acng will not download it again if requested from a mirror
[07:36] <Laibsch> let's say user A requests package P version 1.1 from de.archive.ubuntu.com. That package is now cached.  It was a security update so it's available on security.ubuntu.com as well.  User B now requests the same package, but uses security.ubuntu.com for the request.  acng will then download the file over the network one more time (and store it separately.
[07:37] <Laibsch> it will NOT treat the files as equivalents, unless security.ubuntu.com is listed as a "Ubuntu mirror" (even if only partial mirror).
[07:40] <micahg> interesting...I'll reopen and subscribe mdeslaur, he can help clarify this I believe as he's more familiar with acng, thanks for the followup
[07:40] <Laibsch> Thanks
[07:40] <Laibsch> Again, I'm certainly not 100% certain about the effects of it, either
[07:40] <Laibsch> We should wait for input from upstream Eduard as well
[07:41] <Laibsch> precisely, about what happens if one of the mirrors is only a partial mirror
[07:41] <Laibsch> thanks, micahg. Have a nice day.
[07:41] <micahg> Laibsch: thanks, you too
[07:54] <tjaalton> is it just me or can't the kvm instance graphics device be changed from the gui? it just complains that the RAM option is only available for QXL (which seems to be the default on vivid)
[08:03] <tjaalton> looks like virt-manager is a bit old too, could be fixed upstream so I'll just leave it at that
[08:04] <zyga> hey
[08:04]  * zyga still sees wlan0 being used instead of eth0 when both are active on vivid
[08:05] <zyga> this is my route output http://paste.ubuntu.com/10705612/
[08:05] <zyga> aww
[08:05] <zyga> sill me
[08:05] <zyga> that was after I turned it off
[08:05] <zyga> http://paste.ubuntu.com/10705615/
[08:06] <zyga> that's with wifi enabled but I think it's only true on fresh boot
[08:06] <darkxst> zyga, odd, I get the opposite, like 2 default routes when both wifi and eth are active
[08:06] <darkxst> that breaks just as bad though
[08:07] <zyga> darkxst: that might be what I see too, this is after clicking on the indicator applet
[08:08] <darkxst> zyga, ubuntu GNOME doesnt have indicator applet
[08:10] <zyga> darkxst: well, it's network manager on the back too
[08:12] <dholbach> good morning
[08:12] <darkxst> zyga, in my case only wifi is managed by network manager
[08:13] <dz0ny> zyga: remove all routes for vmnet
[08:13] <zyga> dz0ny: how?
[08:14] <dz0ny> route del :)
[08:14] <zyga> dz0ny: I see this as a bug in one of the components of the stack, I updated from utopic a few weeks ago and that was not a problem there
[08:14] <darkxst> don;t see why vmnet routes would cause an issue
[08:14] <zyga> dz0ny: I can remove them but this should not need to be done each time
[08:15] <zyga> dz0ny: and I think darkxst is right, traffic goes through wifi, not vmnet*
[08:16] <dz0ny> vmnet1 is treated as link local
[08:16] <dz0ny> i think you have some script that does that
[08:17] <darkxst> dz0ny, they come from vmware
[08:17] <zyga> dz0ny: vmnet are from vmware workstation,
[08:17] <dz0ny> it is used to push all packets to vmware palyer
[08:17] <zyga> dz0ny: though they look okay
[08:17] <darkxst> may or may not be bridged depending on config
[08:17] <zyga> they are on different networks
[08:18] <zyga> vmnet1 is host-only, vmnet8 is nat
[08:18] <dz0ny> mhm
[08:18] <LocutusOfBorg1> good morning
[08:18] <dz0ny> i think its vmware issue
[08:19] <zyga> dz0ny: how can it be a vmware issue where all the traffic goes through wlan0?
[08:59] <darkxst> dz0ny, i don't think its vmware issue, Ive seen the double default route issue on my laptop that doesnt even have vmware installed
[09:29] <Riddell> mvo: so any thoughts on the apt upgrade issue we are having?
[10:25] <flexiondotorg> cjwatson, Thanks for making the new release of grub-gfxpayload-lists
[10:25] <mgedmin> will there be a new gfxboot-theme-ubuntu release with updated launchpad translations, before 15.04?
[10:33] <Odd_Bloke> dhclient is no longer running in the background in the vivid (proposed) images I'm looking at; is this expected because of (network|system)d
[10:33] <Odd_Bloke> *?
[10:33] <Odd_Bloke> (It did run at boot; it has output in the journal)
[10:35] <Odd_Bloke> pitti: ^?
[10:37] <pitti> Odd_Bloke: no, not expected; but systemd just calls /etc/init.d/networking start, so might be a more recent change in ifupdown or dhclient?
[10:38] <Odd_Bloke> Ack; I'll have a poke around.
[10:38] <pitti> Odd_Bloke: I have dhclient -1 on current vivid cloud images
[10:38] <pitti> (for eth0)
[10:39] <pitti> and we don't use networkd, at least it has never been discussed and it'd be rather late trying to integrate it now
[10:40] <flexiondotorg> cjwatson, Is it possible to specific a particular version of a package for a given architecture in a seed?
[10:40] <flexiondotorg> *specify
[10:43] <dz0ny>   695 ?        Ssl    0:01 /usr/sbin/NetworkManager --no-daemon
[10:43] <dz0ny>   788 ?        S      0:00  \_ /sbin/dhclient -d -q -sf /usr/lib/NetworkManager/
[10:43] <dz0ny>   792 ?        S      0:01  \_ /usr/sbin/dnsmasq --no-resolv --keep-in-foregroun
[10:43]  * dz0ny vivid
[10:46] <pitti> flexiondotorg: no, that wouldn't make much sense -- if the version matches the archive it's redundant, and if it doesn't match you couldn't build an image at all
[10:58] <flexiondotorg> pitti, OK.
[10:59] <flexiondotorg> pitti, I only ask because Xorg is completely busted for PowerPC since the recent update. I wanted to try reverting in the image build.
[10:59] <pitti> flexiondotorg: we can't do that, as the previous version isn't even in the archive any more
[11:04] <cjwatson> Experimentation like that is better done locally.
[11:11] <flexiondotorg> cjwatson, Yeah, we are doing. I was just try to find an easier for testers to help.
[11:11] <flexiondotorg> pitti, Have you seen anything like this? - https://bugs.launchpad.net/ubuntu/+source/mate-settings-daemon/+bug/1437722
[11:12] <flexiondotorg> pitti, I can't reproduce on i386, amd64 or armhf.
[11:12] <flexiondotorg> pitti, Is systemd-shim still required in 15.04?
[11:13] <pitti> flexiondotorg: no, I haven't seen that; we use upstart for the session, so that shouldn't change (and sudo systemctl org.mate.settingsd.service wouldn't make sense)
[11:14] <pitti> unless mate actually does use systemd for the session?
[11:14] <pitti> flexiondotorg: no, we don't need shim if you run with systemd
[11:14] <dz0ny> systemctl start org.mate.settingsd.service --user ?
[11:14] <pitti> but we still want to support booting with pstart
[11:14] <dz0ny> isn't that user service?
[11:15] <pitti> yes, it is for sure
[11:16] <flexiondotorg> pitti, OK. indicator-datetime Depends on systemd-shim
[11:16] <flexiondotorg> pitti, Which is why I asked if it was required because I couldn't figure out why it is installed.
[11:17] <flexiondotorg> pitti, Regarding systemd, MATE really only uses logind, if it is available.
[11:17] <pitti> flexiondotorg: uh, indicator-datetime still depends on systemd-services; that's gone since at least trusty
[11:18] <flexiondotorg> pitti, The systemd delay in startup seem to be attributed to audio in the forum dicussion.
[11:26] <Odd_Bloke> pitti: It looks like systemd 219-5ubuntu1 is the cause of dhclient no longer running in the background; it's the only relevant change in the image in which we started seeing the problem: http://cloud-images.ubuntu.com/vivid/20150327.3/unpacked/vivid-server-cloudimg-amd64-20150327.2-to-20150327.3-manifest.diff
[11:27] <pitti> Odd_Bloke: ok; would you mind filing a bug with the details? it's running here with today's cloud image, so it's not entirely obvious to me what you mean
[11:28] <Odd_Bloke> pitti: As in `pgrep dhclient` returns something/
[11:28] <Odd_Bloke> *?
[11:28] <Odd_Bloke> I am really struggling with question marks today.
[11:28]  * pitti tosses a shift key to Odd_Bloke
[11:28] <pitti> yes, I have dhclient -1 running, as expected
[11:29] <pitti> Odd_Bloke: can I sees the image version in the installed systemd anywhere?
[11:29] <pitti> argh, and I can't write "system" any more for the life of me
[11:29] <ogra_> pitti, just use the phone kbd, it reliably turns it into systems
[11:29] <Odd_Bloke> Yes, you just query ubuntucloudimageversiond. ;)
[11:30] <Odd_Bloke> pitti: /etc/cloud/build.info
[11:30] <pitti> build_name: server
[11:30] <pitti> serial: 20150328.1
[11:30] <pitti> root       464  0.0  0.3  23468  7784 ?        Ss   13:28   0:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
[11:30] <pitti> that's for /etc/network/interfaces.d/eth0.cfg
[11:30]  * pitti -> lunch, bbl
[11:33] <Odd_Bloke> pitti: Hmm, I'm not seeing it running in the GCE image built from that cloud image; I'll see if there's anything GCE-specific we're doing that might be messing things up.
[11:38] <Odd_Bloke> But lunch does sound like a good idea.
[12:26] <ari-tczew> can someone help with FTBFS on openblas? It's blocking other packages due to dep-waiting. https://launchpadlibrarian.net/200241214/buildlog_ubuntu-vivid-ppc64el.openblas_0.2.12-1ubuntu1_BUILDING.txt.gz
[12:26] <ari-tczew>  /usr/bin/ld: ../libopenblas_power6p-r0.2.12.a(dcabs1.o): ABI version 1 is not compatible with ABI version 2 output
[12:49] <tjaalton> so using a tmpfs overlay dir for sbuild seems to break with systemd or so, since it mounts a new tmpfs on top of /dev/shm every time sbuild is run :)
[12:56] <Odd_Bloke> pitti: How are you launching your system with running dhclient?  I haven't managed to get a running dhclient in any of the environments I've tried.
[12:59] <pitti> Odd_Bloke: just with qemu, nothing extraordinary
[13:01] <pitti> $ kvm -net nic,model=virtio -net user -snapshot /srv/vm/adt-vivid-amd64-cloud.img
[13:01] <pitti> (I usually have some ssh port redirection, -m, virtio drive etc., but those should hardly matter, and it works like this
[13:02] <pitti> kvm -snapshot /srv/vm/adt-vivid-amd64-cloud.img
[13:02] <pitti> works with this, too
[13:08] <cyphermox> good morning!
[13:11] <mvo> Riddell: hi, sorry for the slow reply, I was trying to reproduce this in a chroot, but failed to trigger the bug with apt-get dist-upgrade --simulate, I try again with a real upgrade now (still chroot). if that does not trigger it I need to create a kubuntu install
[13:11] <Riddell> thanks mvo
[13:11] <Riddell> if I need to just remove the baloo4 package I can probably do that fine
[13:12] <mvo> Riddell: I have no idea right now, sorry. definitely a apt bug though
[13:12] <mvo> Riddell: still, we probably want to workarond it once its better understood
[13:44] <happyaron> mvo: "workarond" get my irssi highlights me, lol
[13:44] <mvo> Riddell: fun, I can not reproduce in a chroot with ubuntu-{minimal,standard}, kubuntu-desktop installed, looks like i need to try harder (i.e. upgrade works just fine)
[13:44] <mvo> happyaron: haha
[13:47] <Riddell> meh
[13:51]  * zyga wonders how to use the company vpn alongside local dns server
[13:51] <ogra_> very carefully ...
[13:58] <arges> hallyn: re: bug 1432644, i may need to try a completely clean vivid install, this is my laptop that's been incrementally upgraded since utopic. but at the moment i'm unable to use uvtool to install VMs and that error message was all I had to go by.
[13:59] <arges> i'll upgrade to the latest libvirt and re-try
[14:00] <tjaalton> hmm, commenting /dev/shm out from /etc/schroot/sbuild/fstab fixes the tmpfs overlays, wonder if that's a proper fix though
[14:07] <jamespage> arges, hallyn: let me know if you want me to disable the lttng integration in ceph - it appears to be making more problems that it solves right now
[14:08] <shadeslayer> ogra_: ping
[14:08] <ogra_> shadeslayer, yo
[14:08] <shadeslayer> ogra_: can we get a armhf tarball going on for Kubuntu vivid?
[14:08] <shadeslayer> or whom should I talk to about that
[14:08] <shadeslayer> I wrote this generic tool that can make RasPi2 images
[14:09] <ogra_> perferably someone from foundations, you will need to send patches fro the build system though
[14:09] <shadeslayer> hm ...
[14:09] <shadeslayer> ogra_: https://github.com/rpi2-stuff/image , maybe you'd be interested in it for Ubuntu
[14:09] <ogra_> unless oyu only want a rootfs tarball
[14:09] <shadeslayer> https://github.com/rpi2-stuff/image/blob/master/config/vivid.yml
[14:09] <shadeslayer> ogra_: I only want a rootfs tarball
[14:09] <arges> jamespage: I'll let hallyn decide, but I don't use the LTTng integration for ceph and it seems like something that should be optional since it would mostly be used for developers
[14:10] <ogra_> shadeslayer, that should be relatively straightforward
[14:10] <shadeslayer> right, so whom do I talk to :)
[14:10] <ogra_> mvo, ^^^ who does image stuff for distro nowadays ?
[14:10] <arges> hallyn: also my problem wasn't starting VMs it was creating a _new_ VM via 'uvt-kvm create' maybe try that too
[14:11] <ogra_> (i know you do snappy ... but i guess there is someone for general distro and flavour stuff)
[14:51] <jdstrand> tyhicks: hey, what is the status of cache loading for vivid?
[14:51] <jdstrand> tyhicks: I ask cause if it isn't going to land, someone needs to fix this:
[14:51] <jdstrand> 1 processes are unconfined but have a profile defined.
[14:51] <jdstrand>    /sbin/dhclient (634)
[14:52] <tyhicks> jdstrand: we're still trying to nail down a detail in the libapparmor API
[14:52] <tyhicks> jdstrand: I'm working on that now
[14:52] <tyhicks> jdstrand: then the systemd changes need to happen
[14:52] <tyhicks> jdstrand: I'm thinking that it is all happening a bit too late to land in Vivid
[14:53] <jdstrand> tyhicks: I think I agree-- but we should land it as soon as 'w' opens
[14:53] <tyhicks> (when I said that "I'm working on that now", I meant that I'm working on the libapparmor API details and not the dhclient bug)
[14:53] <tyhicks> jdstrand: yeah, it'll definitely be ready then
[14:55] <tyhicks> jdstrand: do you have the dhclient bug # handy?
[14:55] <jdstrand> pitti: I'm filing it now
[14:55] <jdstrand> err
[14:55] <jdstrand> tyhicks: ^
[14:55] <tyhicks> oh
[15:03] <jdstrand> tyhicks: fyi, I updated bug #1385414 to reflect what you said above. filed bug #1438249 for dhclient
[15:04] <jdstrand> tyhicks: I'm not sure what the best solution is for bug #1438249-- perhaps discuss with pitti?
[15:04] <jdstrand> pitti: hi! :)
[15:06] <tyhicks> pitti: hello - if you have any initial thoughts on how to address 1438249, please let me know. I'll come up to speed on what network-interface-security.conf does in the meantime.
[15:09] <pitti> hey tyhicks
[15:10] <pitti> tyhicks: I'll have a look and respond to the bug
[15:31] <awe_> seb128, hey question for you... every so often on utopic, my desktop freezes during a hangout.  I have a working cursor, and audio, but everything is frozen such that I need to hard-power off my system
[15:31] <awe_> any suggestions for where I should file and bug and/or debug the problem?
[15:31] <seb128> awe_, hey, can you go to a vt in those cases?
[15:32] <awe_> hhhh, didn't try that...
[15:32] <seb128> I would start there
[15:32] <seb128> if you can, try to kill compiz
[15:32] <seb128> it might the wm being locked
[15:32] <awe_> everything else is frozen hard thought ( indicators, window controls, ... )
[15:32] <awe_> compiz still lives???
[15:32] <seb128> right
[15:33] <awe_> sigh...
[15:33] <seb128> could be xorg
[15:33] <seb128> could be compiz
[15:33] <seb128> could be the input stack/kernel
[15:33]  * awe_ remember his first Canonical all-hands-meeting where we did a mock technical board session about including compiz by default
[15:33] <awe_> seb128, ack
[15:34] <awe_> thanks for the suggestion
[15:35] <seb128> yw!
[15:45] <pitti> tyhicks, jdstrand: responded to the bug, WDYT?
[15:47] <shadeslayer> ogra_: btw out of curiosity, any particular reason why ubuntu-standard isn't installed in the core armhf tar?
[15:47] <ogra_> shadeslayer, to big ... not needed for embedded
[15:47] <shadeslayer> I see
[15:48] <ogra_> we dont use it in the phone images either
[15:48] <shadeslayer> oh I see
[15:48]  * shadeslayer checks if his modifications work
[15:48] <ogra_> (which costs a price though ... extra maintenance and seed management for bit we actually want)
[15:48] <ogra_> *bits
[15:48] <shadeslayer> true enough
[15:49] <shadeslayer> ogra_: my script adds a user to the image it builds, but turns out there is no sudo on the rootfs
[15:49] <shadeslayer> so I can't effectively do much :p
[16:05] <rbasak> pitti: strikov and I are confused about bug 1409639. Why do you say Fix Committed in Vivid?
[16:21] <pitti> rbasak: the fix landed in trunk apparently?
[16:24] <jdstrand> pitti: sorry was in a meeting. responded in the bug
[16:29] <rbasak> pitti: trunk upstream, but it won't be landing in Ubuntu for a while. Needs a major version bump for a version that isn't released yet.
[16:29] <rbasak> pitti: so I think upstream task Fix Committed makes sense, but not Ubuntu task as we'll be doing uploads that don't include the support in the interim.
[16:58] <pitti> rbasak: ok; I don't mind much  (that's how I use "fix committed" -- as soon as the fix lands in trunk)
[17:00] <rbasak> pitti: I wasn't aware of that use. No worries. I don't mind either.
[17:00] <rbasak> (now I understand that use exists :)
[17:01] <pitti> rbasak: please use the states as you usually do within juju, I don't want to step on your toes
[17:01]  * pitti waves good night
[17:08] <mvo> Riddell: still no luck, did a fresh 14.10 kubuntu install in a VM, then upgraded to vivid (amd64), no error
[17:10] <Riddell> mvo: um really?
[17:10] <Riddell> mvo: I'll give it another go tomorrow, maybe it magically fixed itself since beta came out
[17:18] <mvo> Riddell: hm, maybe I'm wrong, it looks like its incomplete, let me try again
[18:42] <mvo> Riddell: same result, 14.10 kubuntu/amd64 -> 15.04 dist-upgrade, no error, sorry
[18:59] <infinity> mvo: Did you mean to add ubuntu to a bunch of groups in that livecd-rootfs upload?
[18:59] <infinity> mvo: The changelog doesn't mention it.
[19:03] <mvo> infinity: yes, sorry, I should have documented that, I can double check tomorrow though
[19:04] <infinity> mvo: Well, I'm less fussy about the changelog mentioning it (though that would be nice) and was mostly concerned that it was an accident, since adding a user to a couple of priviledged groups seems like the sort of thing one wouldn't want to do by accident. :P
[19:07] <mvo> infinity: oh, I see. the ubuntu user is already part of sudo,docker this is just moving it into a different place, there is a existing 02-add_user_to_groups.chroot that does that. my mistake for not documenting that properly :/
[19:08] <infinity> mvo: Oh, so did this make 02-add_user_to_groups.chroot obsolete, or do you now do it twice? :P
[19:09]  * infinity also thinks that syslog user's $HOME is rather suspiciously wrong, but that's not your fault.
[19:09] <mvo> infinity: *cough* twice!
[19:09]  * mvo adds a todo to fix that
[19:10] <infinity> mvo: *smirk*.  Alright, letting it in anyway, assuming that's a no-op and doesn't break.
[19:10] <mvo> infinity: its tested in our PPA, so it should not break(tm) :)
[19:10] <infinity> (base)root@cthulhu:~# adduser adconrad sbuild
[19:10] <infinity> The user `adconrad' is already a member of `sbuild'.
[19:10] <infinity> (base)root@cthulhu:~# echo $?
[19:10] <infinity> 0
[19:10] <infinity> Yeah, looks like it'll work fine.
[19:11] <infinity> Just a pointless extra bit.
[19:23] <infinity> pitti: Can we, I dunno, make the systemd autopkgtests actually pass?  You're setting a bad example for everyone else. :P
[20:10] <shadeslayer> mvo: who's in charge of the foundation bits for flavor images ?