[06:05] <PryMar56> seems that libsystemd-daemon.so.0 is missing in vivid
[06:05] <PryMar56> the header file sd-daemon.h is found, but not the SO
[06:06] <PryMar56> I can't build xen-4.5.0 without it
[09:55] <crane_> hifolks
[09:55] <crane_> I have used sudo usermod -a -G sudo username to make user a sudoer
[09:55] <crane_> now when I use su username and issue sudo it wont accept its pass
[09:56] <crane_> also I cant ssh anymore
[09:56] <crane_> as this user
[09:56] <crane_> wtf? :D
[09:59] <Craig4who> hi everyone
[09:59] <Craig4who> anyone got an experience with heartbeat
[09:59] <Craig4who> pacemaker
[11:43] <jamespage> zul, ok all baked - https://launchpad.net/~james-page/+archive/ubuntu/kilo/+packages
[11:43] <jamespage> just need those oslo-packages to go through aa review
[11:44] <zul> jamespage:  cool anyone said they would review them yet
[11:45] <zul> jamespage:  btw i should have nclxd working with 0.5 today
[11:45] <jamespage> zul, not yet
[11:45] <jamespage> arges appears to be not around
[11:45] <jamespage> asked in -release again
[11:46] <jamespage> zul, I've done designate and manila as well
[11:54] <zul> jamespage:  ack
[13:02] <bornpilot> I am working with 14.04 LAMP on the Apache side of things I need to have web dev usres aceess to the web app folders should I keep the user folders root from the default setting in the install and change the group to have rwx acces to those directorys or what is the best practives for multiuser access to web servers application files?
[13:04] <OpenTokix> bornpilot: I would have the webdav folder writable for the webdav-suers. - And theb mount -bind ro for the actual webaccess fo the files.
[13:05] <bornpilot> web developer users not webdav service sorry about that.
[13:06] <OpenTokix> You can still separate them, to have a writable folder - and then mount that as a bind, but ro for the webserver
[13:06] <bornpilot> Thanks
[13:21] <rbasak> # WARNING! I don't seem to be running in the Docker container.
[13:21] <rbasak> # The result of this command might be an incorrect build, and will not be
[13:21] <rbasak> #   officially supported.
[13:21] <rbasak> jamespage: ^^ is that expected?
[13:21] <jamespage> rbasak, yes
[13:22] <jamespage> the upstream build process uses docker to build docker
[13:22] <jamespage> think schroot's
[13:22] <rbasak> OK, thanks. kickinz1: ^^ - looks like that's fine and we can use sbuild
[14:05] <lnxmen> j #gentoo-pl
[14:06] <lnxmen> Sorry.
[14:44] <rbasak> jamespage: so enable-gccgo-build.patch no longer applies. I think the dep3 headers are wrong, as the pull request it refers to seems to be completely different.
[14:44] <rbasak> Do you know where I can find a current version of the patch please, or where it came from originally?
[14:44] <jamespage> which package?
[14:44] <rbasak> jamespage: docker.io
[14:44] <jamespage> rbasak, that came direct from IBM
[14:45] <rbasak> jamespage: not published anywhere?
[14:45] <jamespage> rbasak, it was based on patches for master upstream
[14:46] <jamespage> rbasak, so for 1.5.0 I'd look for equivalents in master branch
[14:46] <rbasak> jamespage: aha. https://github.com/bpradipt/docker/commit/b34e0cd5e8511f388e5d2150559ec80a99a32d79 maybe?
[14:47] <jamespage> rbasak, yes
[14:47] <rbasak> OK. I'll try those. Thanks!
[14:47] <jamespage> he's the author of the patch you already have
[14:48]  * rbasak wonders if this will break the golang build
[15:42] <gchristensen> Hi, what events cause new AWS AMIs to be built? ie: I was expecting a new one around the openssl patches, but it hasn't come, but it isn't with major releases as far as I can tell, 14.04 has been updated a few times in thepast 6 monhts
[15:49] <Odd_Bloke> gchristensen: The OpenSSL patches should be pulled in via apt-get (the way you would pull in security fixes normally).
[15:50] <Odd_Bloke> gchristensen: The images are respun if there are _critical_ security issues, or if the way that the image interacts with EC2 changes.
[16:01] <gchristensen> Odd_Bloke: makes sense, up until now I just make new servers using a more up to date image. I'll add an apt-get upgrade step in there. though it is curious, is there a way to determine what caused a new AMI to be released? ie: ami-3b14370b, which was released on 2015-03-05
[16:07] <Odd_Bloke> gchristensen: Release notes are generated at http://cloud-images.ubuntu.com/releases/trusty/release-20150305/unpacked/release_notes.txt
[16:08] <Odd_Bloke> gchristensen: Yeah, you should definitely have an upgrade step in there; we don't release new images for every security issue.
[16:15] <jamespage> jdstrand, would you have capacity for three NEW package reviews for vivid? all oslo refactorings of shared code from openstack projects
[16:16] <jdstrand> jamespage: not within the timeframe you'd be interested in (note, I no longer perfrom regular ubuntu-archive duties)
[16:16] <jdstrand> jamespage: (sorry)
[16:17] <jdstrand> if in a few days you are in a jam, ask again and I'll see what I can do
[16:17] <jamespage> jdstrand, ack - ta
[16:22] <hxm> i am migrating a site from hosting, but my bandwich is limited, can i use ftp from old server to other ftp server?
[16:22] <hxm> something like cp but between ftp
[16:27] <Odd_Bloke> hxm: Do you have SSH access to the hosts, or just FTP access?
[16:30] <hxm> just ftp
[16:30] <hxm> not even sftp
[16:35] <Odd_Bloke> hxm: I suspect you're out of luck; I think you'd have to pull down the contents to push them back up.
[16:36] <Odd_Bloke> hxm: But you could use a cloud instance to do it; they generally have excellent bandwidth.  Obviously there would be a cost associated with that.
[16:41] <PryMar56> how to request a new package for vivid? libsystemd-daemon.so.0
[16:42] <PryMar56> in systemd 219
[16:46] <Odd_Bloke> PryMar56: systemd 219 is already in vivid: http://packages.ubuntu.com/vivid/systemd
[16:49] <Odd_Bloke> PryMar56: If there's something missing that you would like included, find or file a bug; it's unlikely to make it in to vivid as we are past feature freeze.
[16:51] <PryMar56> libsystemd-daemon.so.0  is missing & its required to build Xen 4.5.0 upstream
[16:52] <PryMar56> Odd_Bloke, I hope I'm wrong about this. I can't be the first one to try to build this
[16:53] <PryMar56> going to check what is done in fc23
[16:55] <Odd_Bloke> PryMar56: There was a libsystemd-daemon0 package in utopic: http://packages.ubuntu.com/utopic/libsystemd-daemon0
[16:55] <Odd_Bloke> But I don't really know much about systemd or its packaging, so I can't really tell you why it isn't in vivid.
[16:59] <PryMar56> Odd_Bloke, even debian8 (systemd 215) has it
[16:59] <PryMar56> from 215->219 things may have changed
[17:07] <smb> PryMar56, FWIW I just recompiled the xen-4.5 in vivid and had no issues with the current state of the archive
[17:07] <PryMar56> smb, did you configure with --enable-ocamltools ?
[17:08] <PryMar56> smb or did you build oxenstored ?
[17:08] <smb> No since ocaml is for the old toolstack which is gone
[17:08] <PryMar56> smb, so your effort is moot
[17:09] <PryMar56> smb, I'm making progress fishing through the fc23 systemd 219 build
[17:14] <PryMar56> my snooping thru fc22: http://paste.ubuntu.com/10679310/
[17:28] <PryMar56> OK, I filed a bug with [needs-packaging] tag
[17:58] <JanC> Patrickdk: looks like g8 is/was still BIOS-based indeed (but being from 2012, that's an "old" hardware design by now...)
[20:07] <hxm> Odd_Bloke: i did it using lftp
[20:07] <hxm> very usefull
[20:08] <hxm> lftp -e "mirror -R local_dir remote_dir" -u ftp_user,ftp_pass remote_host
[22:23] <kybe> Hi folks. I have an issue with glusterfs-server starting before zfs on ubuntu 12.04 during boot. This results in glusterfs insterting some files into the mount point and ZFS refusing to mount. Any tip on how to adjust that? glusterfs-server is started by upstart on runlevel2 and zfs-mount seems to be S20 in /etc/rc2.d/.
[22:27] <sarnold> kybe: what Snn is used for the glusterfs-server?
[22:29] <kybe> none, i can only find it in /etc/init/glusterfs-server.conf. there it just says runlevel 2345
[22:34] <sarnold> kybe: ugh. I don't recall how the sysvinit compatability levels interact with the upstart prereqs..
[22:34] <sarnold> kybe: it might make most sense to convert the zfs initscript into an upstart configuration file so you can control the ordering exactly
[22:37] <kybe> Ok