[05:51] <phunyguy> gosh darnit
[07:07] <ROOM1> hi
[07:37] <ROOM1> hi
[07:37] <ROOM1> hi
[09:47] <dholbach> hiya
[09:47] <dholbach> is anyone aware of the mysql-5.6 installation/removal issues? https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bugs?orderby=-id&start=0)
[09:49] <dholbach> hey rbasak, ^ do you know who could help with this?
[09:52] <rbasak> dholbach: that would be me - thank you for the heads up
[09:52] <dholbach> <3
[09:53] <dholbach> rbasak, if you need a tester with half-installed packages let me know :)
[09:54] <rbasak> dholbach: OK. So you can confirm the bug?
[09:54] <dholbach> yes
[09:54] <rbasak> Thanks
[09:55] <dholbach> I noticed mysql-server-5.6 being installed yesterday and couldn't quite remember installing it in the last time, so I tried to remove it
[09:55] <dholbach> now dpkg says "rH  mysql-server-5.6"
[11:05] <nivv> Is it possible to dry run a dist upgrade? I'm moving from 12.04 to 14.04
[11:05] <istram> hey! is there anybody using cloud-init while also having a configuration management system?
[11:05] <OpenTokix> istram: yes and no, dpeends onr you config managmenet.
[11:11] <istram> OpenTokix: what are your experiences? I have rather minimal configuration in it as the CFGM takes over quite quickly for most of tasks.
[11:12] <istram> even then, cloud-init has probably the worst documentation I've seen aside Bluez.
[11:21] <OpenTokix> istram: my experience is that if you follow the debian file structure. - IE dont edit files in /usr/ apart from /usr/local - and have sensible dpkg-defaults - it will be a painless upgrade.
[11:33] <istram> nivv: guess the last message from OpenTokix was for you :)
[11:33] <nivv> istram thanks :)
[11:33] <nivv> so scary though..
[11:33] <nivv> with no staging server :/
[11:34] <istram> nivv: I also find the dist upgrade to work fine, just make sure you follow the documentation.
[11:34] <nivv> hm yea,
[11:34] <istram> there can possibly be lots of ifs and buts and not every service may go without configuration update.
[11:35] <istram> better count with bigger service window...
[11:35] <OpenTokix> nivv: Have you built it your self, - or is it some legacy system?
[11:35] <nivv> yea
[11:35] <nivv> OpenTokix: It's a hosted vps
[11:35] <OpenTokix> nivv: ok
[11:35] <nivv> but the kernel is 2.6.32-042stab090.4 x86_64
[11:36] <OpenTokix> nivv: so its xen or some other paravirt-stuff.
[11:36] <OpenTokix> nivv: can't you get a second VPS and migrate to that?
[11:37] <nivv> OpenTokix: migrating seems to be even more work tbh, lots of websites running on it
[11:37] <nivv> but if we can keep the same IP maybe it could work
[11:37] <OpenTokix> nivv: Do your vps-company offer snapshots?
[11:38] <nivv> OpenTokix: they offer full backups, and you can restore to whichever of the full backups, so technically yes
[11:38] <OpenTokix> nivv: do a snapshot, - upgrade, make sure it works
[11:39] <nivv> Yup! open
[11:39] <nivv> OpenTokix will the kernel be upgraded as well?
[11:39] <OpenTokix> nivv: if its xen or other paravirt, no
[11:39] <OpenTokix> since your system is running the kernel of the dom0
[11:39] <nivv> OpenTokix should I be worried about that?
[11:39] <OpenTokix> nivv: no
[11:39] <nivv> Goodie!
[11:40] <OpenTokix> nivv: your upgrade is focused around the userland-software. - Ie. webserver etc.
[11:40] <nivv> OpenTokix indeed
[11:40] <OpenTokix> nivv: kernel is the program that just keep the intrastructure for disk-communication etc.
[11:40] <nivv> OpenTokix ah! cool, I'm going to try to upgrade on my server at home now, see what happens, basically the same software on both
[11:41] <OpenTokix> nivv: have fun
[11:41] <nivv> OpenTokix thanks for the (calming) help! :)
[11:41] <OpenTokix> nivv: I once did a scripted dist-upgrade accross 40 hosts  - I have a big trust in dist-upgrade
[11:41] <OpenTokix> nivv: since I always do everything the "debuntu-way" so to speak
[11:42] <Walex> OpenTokix: your trust is well places. Debian and Canonical spend quite a bit of effort in producing smoothly-upgradeable packages...
[11:42] <nivv> Coolio! Only reason I'm upgrading is actually  because PHP 5.6 isn't available on 12.04
[11:42] <OpenTokix> Walex: yes, - I like it
[11:46] <ikonia> wom 1
[11:46] <ikonia> oops
[11:51] <jamespage> zul, I'm going to ask for your oslo-log upload to be rejected
[11:52] <jamespage> zul, Debian will use a different source package name and I want to ensure we don't break ourselves next cycle
[11:52] <jamespage> zul, policy and log will be tweaked uploads from debian vcs (not uploaded in Debian just yet)
[12:03] <zul> jamespage:  thats fine with me
[12:45] <nivv> Anyone here?
[12:46] <Sling> plenty of people :)
[12:46] <nivv> I just did a do-release upgrade and now I got a message that grub couldn't be installed on /dev/sda
[12:46] <nivv> What gives?
[12:49] <OpenTokix> nivv: since you ar running a paravirt vps, grub isnt needed really
[12:49] <nivv> OpenTokix; this is on my server at home though.
[12:50] <Sling> leave your question here and people will attack it
[12:50] <nivv> (sorry for the swedish) https://www.dropbox.com/s/h3x0y6eppypqb5n/Sk%C3%A4rmklipp%202015-03-23%2013.50.05.png?dl=0
[12:50] <OpenTokix> nivv: oh, and it is /dev/sda ?
[12:50] <OpenTokix> nivv: try to run update-grub2 from a shell
[12:50] <OpenTokix> nivv: (Im swedish, so no worries)
[12:51] <nivv> ok, OpenTokix, should I press "yes" or "no"?
[12:51] <nivv> maybe this is because I did a dry run?
[12:51] <OpenTokix> nivv: oh, its a dry-run
[12:51] <nivv> yea..
[12:51] <OpenTokix> nivv: press yes, and then do it manually later
[12:52] <nivv> it's kind of weird. I'm pretty confident I did a dry run but during the install my sites are down on my homeserver
[12:55] <nivv> OpenTokix: got this when doing "update-grub2"
[12:55] <nivv>  /usr/sbin/grub-probe: fel: failed to get canonical path of `none'.
[12:56] <OpenTokix> nivv: hmmm, weird
[12:56] <nivv> maybe because I'm still in the sandbox? Maybe I should try to reboot and see if I'm on 12.04
[12:57] <OpenTokix> if you did dry-run, nothing was changes
[13:09] <nivv> OpenTokix: turns out I wasn't and I can't connect after the reboot >_< Probably have grub error at home now!
[13:09] <OpenTokix> nivv: you did it via ssh?
[13:09] <nivv> yes
[13:10] <nivv> OpenTokix ^
[13:11] <OpenTokix> nivv: I guessyou have to connect a monitor now and troubleshoot your homemachine
[13:21] <sohail-ahmed> I am unable to scan from a network printer. Would any body help. xsane gives device is busy, thanks!!!
[13:35] <pmatulis> is it turned on?
[13:37] <nivv> OpenTokix yup!
[13:40] <nivv> OpenTokix btw, when I try to SSH into the box I immediately get connect to host domain.com port 22: Connection refused
[13:41] <OpenTokix> nivv: probably machine is booted, somewhat has ip and such - but no services is running. - My guess is you have gotten your devices mixed up somehow. - Do you have multiple disks in the machine - or a usb-stick connected or something.
[13:41] <nivv> OpenTokix: I got a mdadm raid
[13:42] <nivv> + and OS disk, nothing else, and a printer via USB
[13:42] <OpenTokix> nivv: oh, ok
[13:43] <nivv> OpenTokix: you think it's trying to boot the raid array instead of the OS disk?
[13:44] <OpenTokix> nivv: yes - sounds like it
[13:45] <nivv> probably the reason I got the grub error
[13:45] <OpenTokix> nivv: sounds like it
[13:45] <nivv> hm,  we'll see!
[13:53] <nivv> OpenTokix: got this error btw when doing the upgrade
[13:53] <nivv> https://www.dropbox.com/s/l72lghpn9c6ms4x/Sk%C3%A4rmklipp%202015-03-23%2014.53.05.png?dl=0
[13:54] <OpenTokix> nivv: not sure what happened
[13:54] <nivv> Seems to have stopped at grub-pc though?
[14:49] <nvez-> How can I report a bug regression?
[14:49] <nvez-> This started appearing again: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1346917 .. running 3.13.0-46-generic
[14:51] <rbasak> nvez-: if the previous bug was fixed but has now regressed, then please file a new bug. You could also mention the new bug in the old bug, and also mention it in #ubuntu-kernel.
[14:52] <nvez-> Thanks rbasak !
[14:53] <rbasak> nvez-: no problem. One of the tags from https://wiki.ubuntu.com/Bugs/Tags#Regression_specific might also be appropriate.
[14:53] <rbasak> (for your new bug)
[14:54] <nvez-> got it! :)
[14:59] <hallyn> rbasak: hey, is the fix for bug 1432683 ready?
[15:09] <rbasak> hallyn: sorry, I didn't realise I was supposed to be driving that. No real progress since we last spoke - haven't had an ack from anyone else, and no idea about reverse deps that might need to be fixed.
[15:10] <rbasak> I can poke people and start grepping the archive I suppose.
[15:23] <jamespage> zul, most things are building now - https://launchpad.net/~james-page/+archive/ubuntu/kilo/+packages
[15:24] <zul> jamespage:  cool just fixing trove
[15:25] <jamespage> zul, the ~= versioning in requirements is being fixed upstream - created an issue in glance
[15:25] <zul> jamespage:  ack
[15:49] <hallyn> rbasak: if you prefer i take it over that's fine - i just thought yo uowned it, and had a good solution :)
[15:49] <rbasak> hallyn: I've just started grepping the archive for apparmor-init-parser
[15:49] <rbasak> Er, apparmor-profile-load
[15:51] <hallyn> so we never figured out what is causing things like lxc and cgmanager to transatively depend on init-scripts-helper or whatever it's called?
[15:51] <hallyn> (init-system-helpers)
[15:51] <rbasak> I'm not sure anything does transitively depend on it
[15:51] <hallyn> lxc's packaging doesn't list it, but apt-cache show shows it depending on it
[15:51] <rbasak> infinity suggested that dh_installinit (IIRC) should grep the init scripts and add a dependency on init-system-helpers dynamically (using ${misc:Depends}
[15:51] <teward> anyone know what can cause a ssh login to take an age before it drops me to a shell?
[15:51] <rbasak> )
[15:52] <rbasak> But we'd need to know which sources to rebuild even after I made that change
[15:52] <rbasak> So I'm grepping everything to find out
[15:52] <rbasak> I suspect the actual list is quite small.
[15:52] <hallyn> k
[15:52] <hallyn> thanks!
[15:52] <rbasak> No problem.
[15:53] <rbasak> hallyn: btw, I'm not sure that this grep will finish in a realistic amount of time. I'll check progress after an hour or so to work out an estimate.
[15:53] <rbasak> (I'm running pull-lp-source in a looP)
[15:54] <hallyn> seems like we'd have a lxr style site for that :)
[15:54] <hallyn> sources.debian.org style
[15:55] <rbasak> 200/23816 sources done now
[15:56] <rbasak> Maybe ~20 hours then.
[16:43] <sarnold> jamespage: sorry for the slow reply, three day weekend was nice though; I reall ylike the idea of disabling build-time requirement and moving repoze.who to a suggests; that seems like a good approach
[16:43] <jamespage> sarnold, good cause I uploaded that an hour ago :-)
[16:44] <jamespage> sarnold, I need to sort-out the unit test suite with xmlsec1 and then I think its all good to go to main
[16:44] <sarnold> jamespage: yay! thanks :)
[16:48] <shodan45> if I want a private network between 2 KVM vms, do I need a bridge on the host?
[17:54] <sconklin> gaughen,  utlemming: 14.04.2 has shipped, but Amazon hasn't updated their AMIs yet, any reason?
[17:54] <utlemming> sconklin: are you talking about the quickstart images ?
[17:57] <sconklin> utlemming: let me get a clarification from the person who asked me?
[17:59] <sconklin> utlemming: specifically, why doesn't this page reflect .02? http://cloud-images.ubuntu.com/trusty/current/
[17:59] <utlemming> sconklin: ah, okay, fixing that now
[17:59] <sconklin> cool, thanks
[18:01] <utlemming> sconklin: fwiw, 14.04.2 is utterly meaningless in the context of a cloud image. 14.04.2 is a snapshot (release + updates) in time, well the cloud images uses a serial and has more freuent releases. The only reason we do put 14.04.x is because people expect it.
[18:02] <utlemming> sconklin: for this reason, future LTS's won't have cloud image point releases. We want to eliminate the confusion.
[18:03] <sconklin> utlemming: so to get to the equivalent of a point release in cloud, one should change to the HWE kernel package and just stay updated?
[18:03] <utlemming> sconklin: correct
[18:04] <sconklin> cool. That also means not having to wait for the 'release'
[18:05] <utlemming> sconklin: right. Often times we have the packages that will make the point release before the it is generally released sans the HWE kernel
[18:05] <utlemming> sconklin: I hope to get this confusion fixed in time for 16.04.
[18:05] <sconklin> that would be nice.
[18:05] <utlemming> sconklin: the contentious bit is whether cloud images should use the HWE kernel by default. That sticking point is rather...polarizing.
[18:06] <sconklin> I can see both sides of that one myself
[18:07] <utlemming> sconklin: I really wish that there was a good answer to it
[18:08] <sconklin> well, there's no one answer. Different people want different things. The naming has gotten convoluted and doesn't make sense in some cases.
[18:08] <sconklin> example: What does "hardware enablement" mean if I only run in VMs?
[18:09] <utlemming> which is generally valid, until you consider VM's. VMware and Hyper-V have all had interesting changes in their kernel support such that "hardware enablement" is actually meaningful
[18:10] <utlemming> and then you have things like Multiqueue for KVM instances
[18:10] <utlemming> so, yeah, even though "hardware" is the verb, the new feature enablement is actually what is needed
[18:11] <sconklin> exactly. And in our case, it's OverlayFS that we care about (this time).
[18:53] <wedgwood> I'm seeing behavior in trusty that looks precisely like this old bug https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/285897
[19:32] <wiredfool> just upgraded to trusty, and I'm getting a uvt sumplestreams error when updating.  This worked on precise last week. http://pastebin.com/6K95PPKR
[19:36] <sarnold> wiredfool: wild-guess time, could you check dmesg or /var/log/audit/audit.log for apparmor DENIED lines?
[19:42] <wiredfool> sarnold: nope, nothing there
[19:43] <sarnold> wiredfool: bummer. well,that's overall good, but it does mean I don't know what to suggest next. sorry.
[19:46] <wiredfool> was afraid of that
[19:59] <wiredfool> sarnold: I think the essential problem is that I have 5 metadata entries and 10 base images
[20:36] <wiredfool> sarnold: wound up converting the images I care about to not use a backing store, then blowing away the simplestreams store using uvt-simplestreams-libvirt purge
[20:48] <devster31> hi, I need to keep both libcurl4-gnutils-dev and it's :i386 version, is it possible?