[03:50] <mwhudson> hm
[03:51] <mwhudson> can i use uvt-kvm to create a vm backed onto a lvm lv?
[04:00] <Miplo> Hi, do I need to permit root login on an Ubuntu server using SSH? Wouldn't the actual admin user be enough? (using sudo)
[05:26] <rahuldroy> Hey Guys, I have a quick question. I am planning to make a closed-source website using MySQL as a database. Will I be legally allowed to do that?
[05:32] <sheptard> are you planning on redistributing mysql?
[05:32] <sheptard> or just using mysql to drive the website
[05:32] <rahuldroy> just use mysql to drive the website
[05:33] <sheptard> then why would they care
[05:33] <rahuldroy> I don't want to do anything illegal
[05:33] <sheptard> also, IANAL
[05:33] <rahuldroy> haha neither
[05:33] <rahuldroy> just tyring to make sense of open source licences
[05:34] <rahuldroy> BSD and MIT Seems to have no restriction on commercial use
[05:34] <sheptard> those licenses usually only matter if you plan to use the actual code in another product, or redistribute said product
[05:34] <rahuldroy> GPL seems to though
[05:35] <rahuldroy> lets say I get an GPL Software and customize the code to my needs
[05:35] <rahuldroy> Do I need to make the modifications freely available??
[05:36] <sheptard> only if you want to
[05:36] <sheptard> assuming you aren't selling the software
[05:37] <rahuldroy> thats what I though as well. Does this include saas software??
[05:39] <sheptard> don't think so
[05:39] <sheptard> again, IANAL
[05:41] <rahuldroy> I think it would be be best if I avoid GPL code on my project completely just to be safe but I will keep using MySQL though
[05:59] <EpicCyndaquil> I tried asking in #ubuntu but no one there answered, and you all are probably better with bash anyway: can anyone help me understand why this bash script doesn't work? https://3d3.ca/yLLXL.bash#VT23LM5SHgTzkCLU
[06:01] <vonsyd0w> EpicCyndaquil, what about the #bash channel?
[06:01] <EpicCyndaquil> ah, good idea :)
[06:03] <EpicCyndaquil> shellcheck.net was enough to help me figure it out, so thanks for bringing up #bash, vonsyd0w
[06:04] <vonsyd0w> no prob, my bash skills arent that great... yet
[06:11] <Alina-malina> this cronjob is it recommended to use in high load mode? for example i have multiple users they add posts and the crontab removes those after 5 hours, will that be problem if there are 5000+ users?
[06:19] <lordievader> Good morning.
[06:20] <prgCoder> hey guys - I have a weird problem and my head already hurts...
[06:21] <prgCoder> had a problems where a suse server all of a sudden started to poll the internet and started to use up a lot of bandwidth
[06:21] <prgCoder> local it admin said it was only out going.....
[06:22] <prgCoder> so I grapped another box, formatted the drive and install ubuntu 12 server and transaferred programs and data to it
[06:23] <prgCoder> a day later the same thing started to happen - the suse server is off and the new ubuntu server is up and the local IT admin says this server is plling the internet, over and over again
[06:24] <prgCoder> any ideas on what to look for and where this is coming from - I havetried wireshark and a few others but I have no clue what to look for
[06:24] <lordievader> prgCoder: Investigate what is using it ;) iftop -P might come in handy there.
[06:25] <prgCoder> I will give that a go when the local admin either turns it back on or can some how retard the server from using up most of the bandwidth so i can get in remotely
[06:26] <prgCoder> what should i look for?
[06:29] <lordievader> prgCoder: Something that uses a lot of bandwith. It will show the src ip+port and dst ip+port. From there you can make up which service/application is responsible.
[06:29] <prgCoder> loadievader: thanks
[06:31] <prgCoder> lordievader: thanks
[06:33] <lordievader> :)
[06:34] <lordievader> prgCoder: Good luck
[06:34] <prgCoder> thanks
[09:10] <dv81> whats the easiest tool to backup/restore an entire server's disk?
[09:11] <dv81> to an offsite location
[09:12] <jpds> I doubt you'll find something "easy".
[09:12] <dv81> "easiest"
[09:17] <jpds> dv81: Well, I can only give suggestions like bacula, rsync, obnam, ....
[09:17] <dv81> *googles*
[09:18] <lordievader> I find dirvish quite easy (I've come to understand that dirvish is an rsync wrapper).
[09:20] <alesales> exist also a tool named relax and recover :)
[09:20] <alesales> http://relax-and-recover.org/
[09:20] <alesales> is like aix mksysb or OS/400 SAVSYS :)
[09:21] <dv81> thanks guys
[09:22] <dv81> looking for something that will image a disk, grub and all rather than just certain parts of the fs
[09:22] <dv81> alesales: Rear, looks good thanks
[09:23] <alesales> I never tried...I just heard about that
[09:23] <alesales> I'm not working with Linux on x86 :)
[10:45] <ashd> setting up ldap and samba - ubuntu 14.04 following the ubuntu docs and walkthrough. “id user” shows uid,gid and groups.. but only main group… ldapid shows all the groups… is this the correct behavoir, or have i done something wrong somewhere.
[11:02] <Proshot> afternoon when i login into ubuntu server via ssh i get this welcome http://pastebin.com/46THn4se i was wondering where the config is that displays this message
[11:06] <jamespage> smoser, roaksoax, zul, hallyn: I've added some content to https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes for server this morning
[11:06] <jamespage> I've left some placeholders for MAAS and libvirt right now - if you want to draft something appreciated :-)
[11:06] <jamespage> gaughen, ^^
[11:23] <Proshot> anybody any idea where i get the config files which displays that message
[11:59] <gt8ost4l> anyone know how i can somehow change the mysql default name
[12:00] <bekks> gt8ost4l: default name?
[12:01] <gt8ost4l> yeah the name you give the mysql server the first installation
[12:01] <bekks> gt8ost4l: you dont set any names for mysql servers at all during installation.
[12:02] <gt8ost4l> so its just a password and thats all
[12:03] <bekks> gt8ost4l: you have to enter a password for the mysql root user during installation.
[12:03] <gt8ost4l> so root is just the default
[12:07] <bekks> gt8ost4l: thats the default mysql username of the mysql root user, yes.
[12:08] <gt8ost4l> so theres no way to change that username
[12:08] <bekks> gt8ost4l: Create a new user, done.
[12:09] <gt8ost4l> how do i do that
[12:09] <bekks> gt8ost4l: https://dev.mysql.com/doc/refman/5.1/en/create-user.html
[12:15] <rbasak> gt8ost4l: don't change the name of the root user. The maintainer scripts need root access for upgrades, etc, and so if you change the username you'll break upgrades.
[12:15] <rbasak> gt8ost4l: creating another user for what you want is fine.
[12:47] <zul> jamespage:  https://code.launchpad.net/~zulcss/heat/heat-mir/+merge/215494
[13:04] <Havenstance2> good morning, is there a work around for the gpg not found error in 13.10?
[13:05] <rbasak> What gpg not found error?
[13:06] <Havenstance2> I keep getting a gpg not found error when I try to pull in a key. not sure why it just says gpg package not found
[13:06] <Havenstance2> wget -q http://keys.zentyal.org/zentyal-3.4-archive.asc -O- | sudo apt-key add -
[13:06] <Havenstance2> I enter that then it returns, gpg not found
[13:07] <Havenstance2> the machine sitting right next to it takes the command and returns OK
[13:08] <Havenstance2> only difference is one is server 13.10 amd64 the other is server 13.10 i386
[13:08] <Havenstance2> and its the amd64 throwing the error
[13:09] <rbasak> How did you install the broken machine?
[13:09] <rbasak> The apt package depends on the gnupg package.
[13:09] <rbasak> You might be able to install gnupg to fix the problem, but it sounds like you have a bigger issue there.
[13:10] <rbasak> (or something wrong with your PATH or something)
[13:24] <Haven|Work> rbasak, I just did a fresh install so we will find out when it finishes. I had a network failure on Friday about the time I set this machine up so its possible that it didn't pull a package it needed
[13:24] <jamespage> zul, one typo but other than that +1
[13:26] <zul> jamespage:  saw...thanks
[13:26] <jamespage> hallyn, could you take a look at bug 1305280 - might be related to bug 1304167
[13:42] <zul> jamespage:  im just catching up precise-icehouse this morning
[13:43] <jamespage> zul, libvirt and xen?
[13:43] <zul> jamespage:  yep
[13:44] <jamespage> zul, I'm just sorting out the publishing issue - ceph built twice for armhf on the last version
[13:44] <jamespage> hashsum mismatches all round
[13:44] <zul> jamespage:  uh ok :)
[13:44] <smb> zul, Still the build in P problem? Most admit I have not yet checked how well the current 4.4 does as I tried to make arm64 more real
[13:45] <zul> smb:  still the P problem i have a work around for it though
[13:45] <smb> zul, ok sounds good
[13:50] <jamespage> zul, your patch for heat is still worng
[13:50] <zul> jamespage:  arrgh
[13:50] <zul> jamespage:  gimme a sec
[13:51] <jamespage> zul, you might want to change the name of the patch as well
[13:51] <jamespage> suder ->sudoers
[13:58] <smoser> roaksoax, where are we on maas ?
[13:59] <zul> jamespage:  https://bugs.launchpad.net/bugs/1307518
[13:59] <smoser> :-(
[14:00] <hallyn> hm.  stgraber: ^ wonder if bug 1304167 could be due to the new pivot_mount rule (i haven't dug yet)
[14:03] <jamespage> zul, eh
[14:04] <jamespage> zul, I'll try to reproduce
[14:04] <zul> jamespage:  ditto
[14:07] <stgraber> hallyn: that sounds more like a problem with the new apparmor statements
[14:07] <hallyn> oh god.  is this in cloud archives again?
[14:07] <hallyn> people really need to mentin that
[14:09] <jamespage> zul, I see that we are missing "schema-image.json"
[14:09] <jamespage> hmm
[14:11] <zul> jamespage:  arrgh so we are
[14:11] <jamespage> zul, and that the perms on /var/lib/glance/images and /var/lib/glance/image-cache are wrong
[14:11] <stgraber> hallyn: no, it's just the LXC upload done by the apparmor folks being wrong
[14:11] <jamespage> they are not writable by the glance user
[14:11] <stgraber> hallyn: LXC doesn't version depend on apparmor so it'll happily install with the wrong apparmor version
[14:11] <hallyn> stgraber: feh.  (i'm still waiting for an upgrade so i can get to testing)
[14:11] <stgraber> hallyn: I have a debdiff here, uploading in a minute
[14:11] <jamespage> zul, ah crap - that's a regression from fixing bug 1214947
[14:12] <hallyn> stgraber: thanks
[14:12] <jdstrand> stgraber: what upload? the one I did added the sed rules and was acked by stgraber
[14:12] <jdstrand> err, by you
[14:12] <jamespage> hmm
[14:13]  * jdstrand uploaded 1.0.2-0ubuntu2
[14:13] <stgraber> jdstrand: right, and we missed the fact that you need a versioned dependency on apparmor too.
[14:13] <stgraber> jdstrand: so that precise -> trusty doesn't break
[14:14] <jdstrand> wouldn't that have broken with the dbus rule too?
[14:14] <stgraber> it probably did in some cases but since people don't care much about non-LTS releases we never heard about it
[14:14] <stgraber> jdstrand: http://paste.ubuntu.com/7249946/
[14:15] <jamespage> zul, this highlights a gap in testing I think
[14:15] <zul> jamespage:  we seem to be missing property-protections-policies.conf.sample property-protections-roles.conf.sample as well
[14:15] <zul> jamespage:  agreed
[14:15] <jamespage> zul, hmm - those are just samples
[14:15] <jamespage> less worried about those
[14:16] <roaksoax> smoser: check the bug :)
[14:16] <jdstrand> stgraber: hrmm, apparmor itself has: Breaks: ..., lxc (<< 1.0.2-0ubuntu2~), ...
[14:17] <smoser> roaksoax, i thought we agreed to upload without that feature
[14:17] <smoser> with the 2 bug fixes
[14:17] <stgraber> jdstrand: right, so apparmor won't upgrade with an old LXC, but LXC will happily upgrade with an old apparmor
[14:17] <stgraber> jdstrand: bug 1304167
[14:17] <hallyn> hm, that's not gonna help ppl upstream
[14:17] <stgraber> jdstrand: that's someone getting a cloud instance of beta2, doing apt-get update && apt-get install lxc without doing a dist-upgrade
[14:17] <stgraber> jdstrand: they get the new LXC but not the new apparmor and things break
[14:17] <hallyn> ideally there'd be versioning built into the policy language :)
[14:18] <jdstrand> why doesn't beta2 have the new apparmor?
[14:19] <jdstrand> hallyn: we are getting there
[14:19] <stgraber> no idea, though the problem should also happen when doing 12.04 to 14.04. apt may very happily resolve the upgrade path as lxc in a first batch and apparmor in a second one. Which will cause the exact same failure.
[14:20] <stgraber> On smaller upgrades, you get a single batch so the apparmor breaks is enough to sort out the configure ordering but if they are each in their own batch, then things will break.
[14:21] <stgraber> jdstrand: anyway, I think my fix should be enough for that, I'd just suggest you make sure any other affected package gets something similar or I'd expect quite a few confusing upgrade bugs to show up soon enough...
[14:21] <jdstrand> I don't know how apt will sort these things, but slangasek said the Breaks was enough to dtrt for upgrades. I didn't do 12.04 to 14.04, but I did do upgrade test of lxc under that version and it all worked
[14:22] <jdstrand> if apt isn't breaking isn't honoring that, that seems like a bug in apt
[14:22] <jdstrand> (otherwise why even have the Breaks mechanism at all)
[14:23] <jdstrand> now, I get that a cloud image with the old apparmor will happily install a new lxc
[14:23] <stgraber> no, what apt is doing is perfectly correct. Your debian/control only prevents me from upgrading apparmor before lxc itself has been upgraded.
[14:23] <stgraber> but I can upgrade lxc itself independently of apparmor and nothing will force me to get the right parser
[14:24] <roaksoax> smoser: well... there is some discussion as to how to
[14:24] <roaksoax> smoser: well... there is some discussion as to how to publish that the setting is enabled
[14:25] <hallyn> jodh: ok i'll go ahead and push 'stop on [06]' for cgmanager;  if/when someone has a problem due to it, we can revisit.  ideally there would be a signal emitted right before final umounts (/var and /)
[14:25] <smoser> roaksoax, 2 bugs need fixing
[14:25] <smoser> independent (i thought) of feature being added
[14:25] <zul> jamespage:  https://code.launchpad.net/~zulcss/glance/lp1307518/+merge/215679
[14:25] <smoser> and i had hoped we'd upload with 2 bugs fixed
[14:25] <jodh> hallyn: right, although upstart isn't doing the unmounting.
[14:26] <roaksoax> smoser: i know
[14:26] <roaksoax> smoser: feel free if you want to go ahead and upload those
[14:26] <hallyn> jodh: what is?  doens't seem to be mountall...
[14:26] <roaksoax> smoser: cheery pick and patch the ubuntu package
[14:27] <jdstrand> stgraber: I understand that the cloud image having an old apparmor, apt-get update, apt-get install lxc doesn't work. I'm saying that a do-release-upgrade or apt-get dist-upgrade where apt breaks this into chunks that don't correctly honor the Breaks would be a bug
[14:27] <jodh> hallyn: /etc/init.d/umount*sh
[14:27] <jdstrand> when was the beta2 image generated?
[14:28] <roaksoax> smoser: i rather make I upload than make 2 though
[14:28] <stgraber> jdstrand: having apt do the upgrade in two chunks, first upgrading 200 packages including LXC, then upgrading another 300 packages including apparmor, would honor the Breaks and would make the upgrade fail.
[14:28] <roaksoax> smoser: that's why I'm saying, follow the bug as the latest developments are happen there and for the looks of it, it is just deciding how to notify the user about the setting being enabled by default
[14:29] <jdstrand> stgraber: who is breaking that up into chunks? the user or the upgrader?
[14:29] <stgraber> jdstrand: because it'd technically never have the new apparmor installed before the new lxc, so the Breaks would be satisfied
[14:30] <stgraber> jdstrand: apt does it when there are massive set of packages with complex dependencies (most pre-depends and the like). A lts-to-lts upgrade usually qualifies...
[14:30] <stgraber> jdstrand: you'll often see apt do multiple configure runs during a dist-upgrade, that's the easiest sign to see it do the chunking
[14:30] <hallyn> jodh: ok so we may just have to provide guidance that any upstart jobs using cgm in post-stop should do '|| true'
[14:30] <stgraber> so download of everything => unpack => configure => unpack second chunk => configure second chunk => ...
[14:31] <jdstrand> stgraber: ok, so I'm saying that if in its chunk calculation it allows what you are saying, its calculation is wrong. it should always put them in the same chunk
[14:32] <stgraber> jdstrand: why?
[14:32] <stgraber> it'll always ensure that apparmor isn't installed before the new lxc because that's what you said in your Breaks
[14:32] <jdstrand> because it would break on upgrades when the Breaks is explicitly there to prevent that
[14:32] <stgraber> but that's as much as it'll do for you
[14:32] <stgraber> as that's as much as you asked it to do
[14:33] <stgraber> it won't at all prevent lxc from going in a first chunk on its own and then apparmor in a second chunk
[14:33] <stgraber> because that'd perfectly respect your Breaks
[14:34] <jdstrand> "When one binary package declares that it breaks another, dpkg will refuse to allow the package which declares Breaks to be unpacked unless the broken package is deconfigured first, and it will refuse to allow the broken package to be reconfigured."
[14:35] <stgraber> so? apt will respect that and things will still break
[14:35] <jdstrand> the broken package is lxc
[14:35] <stgraber> there's no break against installing the new lxc with the old apparmor
[14:35] <jdstrand> yet, it is being configured before apparmor
[14:35] <stgraber> sure because the old installed apparmor doesn't break on the new lxc
[14:35] <jdstrand> (in your scenario)
[14:36] <stgraber> it's just the new apparmor which breaks on the old lxc, but they can be installed 6 months appart for all apt cares
[14:36] <jdstrand> I get that-- but the calculation is wrong. the intent of a massive upgrade is for everything to be upgraded
[14:36] <hallyn> jdstrand: does 'we are getting there' for versoined policy language mean that we might get them during 14.10, or that we might get them during 16.04 timeframe?
[14:37] <jdstrand> if apt breaks it up into a bunch of little things that get you a different upgrade, that is wrong
[14:38] <stgraber> jdstrand: well, usually the point of doing things in chunk is to make the whole upgrade possible to resolve... and unless lxc has a version dependency on the new apparmor or a break against the old apparmor, apt won't necessarily put them both in the same batch
[14:38] <jdstrand> hallyn: you'd have to ask jjohansen. it is recognized as a real problem. I would guess 15.04 though. we are trying to get abstract sockets and lxc finished up first
[14:38] <hallyn> jdstrand: thanks
[14:38] <jdstrand> they are both quite close actually, but trying to be realistic
[14:39] <jdstrand> smoser: hey, who generated the beta2 cloud images?
[14:40] <smoser> jdstrand, they're built in automation
[14:40] <smoser> utlemming would have marked it as 'beta-2'
[14:40] <jdstrand> smoser: so, looking at bug #1304167, I'm quite surprised the old apparmor is still there
[14:41] <jdstrand> smoser: is there an easy way to see a package list with versions of that? is there a beta 3 already?
[14:42] <jdstrand> stgraber: I maintain that is a bug in apt if it operates differently with small and massive upgrades
[14:43] <jdstrand> I don't know that it actually does. I've not seen any upgrade bugs yet.
[14:44] <jdstrand> I guess I can try an upgrade, but if what you say is correct, then upgrades are non-deterministic and just cause my upgrade succeeds doesn't mean yours would
[14:45] <stgraber> jdstrand: well, I don't feel like arguing for hours, it's not an apt bug neither is it something new, I had to fix around 50 of those with the last lts to lts upgrade for 12.04.1. apt does respect your dependencies, however assuming that everything is processed in a single run is wrong and will lead to problems on massive upgrades.
[14:46] <stgraber> jdstrand: feel free to file a bug against apt though, I'm sure mvo will be happy to discuss it though I still expect the outcome to be that packages need to clearly define what they need, which in this case wasn't the case.
[14:46]  * jdstrand doesn't want to argue anymore either
[14:47] <jdstrand> I find it curious that 13.04 to 13.10 didn't have the same issue with dbus policy though
[14:52] <stgraber> jdstrand: well, you need to be pretty unlucky and the larger the set of package and the further they are appart the more likely it becomes. I'd expect 13.04 to 13.10 to be just a few hundred packages, that don't have a massive amount of transitions going on with complex pre-depends/breaks and such. So the upgrade may have happened in a single chunk (if it was resolvable that way) or maybe two, in which case we basically had a 50% chance of
[14:52] <hallyn> smb: for bug 1218959, did you look to see what patches fedora is currently using? :)
[14:53] <hallyn> anyway if that route isn't simple i'll do the darned udev rules.  i'm not sure if we should have later releases remove them then, but they should be safe
[14:53] <stgraber> lts to lts tends to be more like 5-6 runs, especially if we get things like massive debhelper, upstart, libc, ... changes with strict dependencies, it's therefore much more likely to show up in lts to lts than in any other upgrade case
[14:54] <stgraber> (lts to lts are also pretty much the only case where we may get to the point where apt just plain fails to resolve an update, no matter who many chunks it makes)
[14:54] <smb> hallyn, No, if its not mentioned in the bug report (and I have not yet read it carefully) its always a bit hard to find. I wanted to check on the two I think may be the ones. But have not yet got there either
[14:55] <hallyn> smb: ok lemme check one more time, ithought someone said the udev workaround did not work for them.  if nooe said that, we'll do the workaround
[14:56] <zul> jamespage:  ok updated
[14:59] <smb> hallyn, Ok, if they do work it maybe is the simpler route for older kernels. What we will do if that does not work we'll figure out when it does not work. That always works...
[15:01] <jamespage> zul, +1
[15:01] <zul> jamespage:  thanks
[15:01] <jamespage> zul: nope -thankyou!
[15:02] <hallyn> smb: ok yeah let's go with the udev rules.  ttyl
[15:04] <jamespage> coreycb, your grizzly->icehouse upgrade; can you check the keystone.conf post upgrade please
[15:16] <lordievader> Good afternoon.
[15:18] <coreycb> jamespage, sure
[15:18] <coreycb> jamespage, I had compared it vs the havana->icehouse and they were the same post upgrade
[15:19] <jamespage> coreycb, ack
[15:19]  * jamespage thinks again
[15:19] <jamespage> coreycb, the only thing I can think is that something did not happen in the db migrations
[15:19] <coreycb> jamespage, http://paste.ubuntu.com/7250219/
[15:20] <jamespage> coreycb, that looks aok
[15:20] <coreycb> jamespage, ok yeah I was thinking the same.  I can test vs rc2 branches if you think anything's changed.
[15:27] <jamespage> coreycb, I don't think so
[15:31] <jamespage> zul, we might want to considering doing that late-restart thing with debhelper dh_installinit in the packaging
[15:31] <jamespage> right now if you get a kernel update, nova-compute and stuff stays down for a long time
[15:54] <TazaChoncha> hello there
[15:56] <Zal> Hello all. I'm having trouble running an 'apt-get upgrade' on an Ubuntu 12.04LTS EC2 instance. The process stuck at grub-pc. After aborting, the process sticks at lvm2. Now "apt-get upgrade" tells me to run "sudo dpkg --configure -a", which itself sticks again at lvm2. Any tips on getting fixing this installation?
[15:57] <Zal> All I see in dpkg log is a message telling me lvm2 is half configured, when the process freezes
[16:05] <hallyn> we're missing a zul
[16:06] <hallyn> smb: i just uploaded a new libvirt-bin.  are you done with xen-releated libvirt uploads?
[16:06] <Zal> I manually killed the dpkg and frontend processes, blacklisted lvm2 and grub-pc, after which dpkg --configure -a ran successfully. I'm still concerned about the state of my instance though, any pointers are appreciated.
[16:06] <hallyn> Zal: might ask in #ubuntu-devel.  lvm upgrade error would scare me too...
[16:06] <smb> hallyn, If you did a ubuntu13 for T that is fine by me. The 12 was the one I had
[16:07] <hallyn> smb: yeah 13 (phew)
[16:07] <hallyn> Zal: take a look at /var/log/apt/term.log for details on teh lvm failure.
[16:07] <smb> hallyn, Ok, so we are good (hopefully) :)
[16:07] <Zal> hallyn, thanks, I'll look there again, didn't see anything previously
[16:08] <Zal> yeah, no errors there
[16:16] <hallyn> Zal: my *guess* is that there is a hung udev rule which is holding a lock
[16:17] <zul> jamespage:  just about to seed heat
[16:20] <axisys> how to encrypt a folder in my dir? I am sharing this precise 64bit server with multiple system admins
[16:21] <axisys> I like it auto decrypt when I login and only try to access the folder
[16:22] <axisys> and when I get out of the folder/dir, it will go back to encrypt.. is it possible?
[16:22] <axisys> I dont mind to do it manually ..
[16:23] <axisys> so decrypt; access the folder; exit the folder; encrypt
[16:23] <axisys> https://help.ubuntu.com/community/FolderEncryption looks interesting
[16:25] <zul> jamespage/coreycb: glance rc2  has been accepted
[16:33] <jamespage> zul, w00t - I think that means only swift and neutron are still in the queue right?
[16:47] <kosmo> Hi I got problem with my apache server. All was right but after week serevr just crashed and I cant start it.
[16:48] <jpds> Please explain what you mean by "crash".
[16:48] <kosmo> I cant accces it from my local network
[16:48] <bekks> Then investigate the logs.
[16:48] <jpds> Any debug?
[16:49] <jpds> "Crash" could mean anything from meteor strikes, cosmic rays, annexation by Russia, etc.
[16:49] <kosmo> and apache status command resutlts apache server is not running lolz
[16:49] <bekks> kosmo: Then check the logs.
[16:49] <sarnold> oh that crazy putin, here he goes again
[16:49] <jpds> sarnold: He's putin'g himself in your servers.
[16:49] <bekks> Now he crashes server. Does he even pay that "peer" who always terminates connections?
[16:50] <sarnold> jpds: lol
[16:50] <bekks> jpds: :D
[16:50] <sarnold> bekks: hahaha
[16:50] <jpds> kosmo: So you can *access* the server from SSH, but not on HTTP?
[16:50] <kosmo> weell the thing is error.log file is empty
[16:51] <kosmo> jpds yes smbd also works gr8
[16:51] <bekks> kosmo: Which ubuntu release is it?
[16:51] <kosmo> 12.04 LTS
[16:52] <patdk-wk> did you check dmesg?
[16:54] <kosmo> you mean the msg after service apache2 start?
[17:00] <RoyK> kosmo: just type 'dmesg'
[17:05] <jamespage> jdstrand, around? I just got asked to look at the seed changes for bug 1266066 but need some guidance from the security team
[17:06] <jamespage> jpds, technically mterry needs to ack unbound still as well
[17:08] <jpds> jamespage: All tests run as of https://launchpad.net/ubuntu/+source/unbound/1.4.22-1ubuntu4
[17:08] <jdstrand> jamespage: what do you need?
[17:09] <jamespage> jdstrand, just a bit confused as to what actions need to be taken - the bug report references removal of ipsec-tools - but I see racoon that still depends on that
[17:09] <jamespage> jdstrand, I was just going to push strongswan into the supported-misc-servers seed
[17:09] <jdstrand> racoon is superceded by strongswan, no?
[17:09] <jdstrand> jpds: ^
[17:11] <jdstrand> jamespage: I wonder if supported would be better (eg network-manager-strongswan)
[17:11] <sarnold> racoon is built from ipsec-tools, right?
[17:12] <kosmo> I got dmesg output but its big and I didnt find anythnig interesting
[17:12] <jdstrand> sarnold: yes
[17:12] <jamespage> sarnold, yes
[17:13] <jdstrand> so yes, please unseed that :)
[17:13] <jamespage> jdstrand, jpds: OK - so I'll replace racoon with strongswan in the supported-misc-servers seed
[17:13] <jdstrand> jamespage: in case I wasn't clear, I was saying 'supported' instead of 'supported-misc-servers'
[17:14] <jdstrand> jamespage: I'm ok with supported-misc-servers, but supported seems ok too
[17:14] <jdstrand> jamespage: you're call
[17:14] <jdstrand> meh
[17:14] <jdstrand> your*
[17:14] <jamespage> jdstrand, just going on where racoon is currently :-)
[17:14] <jdstrand> that's fine
[17:14] <jdstrand> jamespage: you are taking the list from comment 13?
[17:15] <jdstrand> jamespage: strongswan-pt-tls-client and network-manager-strongswan were also mentioned as desired
[17:16] <jamespage> jdstrand, looking now - but if I just seed strongswan it will pull source+binaries into main right?
[17:17] <jdstrand> jamespage: you want to seed the binaries you want. there are a lot, jpds enumerated those we want
[17:17] <jamespage> jdstrand, ack
[17:18] <jdstrand> hrmm
[17:18] <jdstrand> openvswitch-ipsec depends on racoon
[17:22] <jamespage> jdstrand, indeed
[17:23] <jamespage> jdstrand, I'm assuming the outcome of having ipsec-tools and strongswan in main is not desirable?
[17:23] <jdstrand> it is undesirable
[17:23] <jdstrand> it looks like debian/ovs-monitor-ipsec is the only thing that uses racoon
[17:24] <jdstrand> is there an ovs-monitor-strongswan we can drop in its place?
[17:24] <jdstrand> it looks like Nicira wrote debian/ovs-monitor-ipsec
[17:24] <jdstrand> well, it is the only thing other than the testsuite that uses ipsec-tools
[17:25] <jdstrand> (and the testsuite uses it to test ovs-monitor-ipsec)
[17:25] <jamespage> jdstrand, indeed
[17:25]  * jamespage continues to dig
[17:26] <jdstrand> feel free to commit the change to promote strongswan. the demotion of ipsec-tools can happen separately (but before release)
[17:27] <jpds> jdstrand: openvswitch-ipsec is in universe now.
[17:27] <jamespage> jdstrand, not yet - it looks like upstream ovs have been discussing switch to strongswan but there is no support yet
[17:27] <jamespage> jdstrand, is it?
[17:27] <jamespage> jpds, erm - is it
[17:27] <jpds> jamespage: Yep, cjwatson said he'd move it today.
[17:27] <jdstrand> ah
[17:27] <jdstrand> I was just going to suggest doing that
[17:28] <jamespage> I have to admit to being uncomfortable making this change so late in  cycle
[17:28] <jdstrand> which change?
[17:28] <jamespage> this puts any users of the ipsec feature of openvswitch in a different support position after moving to 14.40
[17:28] <jamespage> 14.04 even
[17:28] <jdstrand> oh, just moving it to universe?
[17:29] <jpds> Well, debian/ovs-monitor-ipsec looks like some nasty hack.
[17:29] <jdstrand> I also mentioned in January that we would want to demote ipsec-tools
[17:30] <jdstrand> ipsec-tools is stagnant
[17:31] <jdstrand> jamespage: note, it does not change the support position over 12.04. openvswitch itself was in universe
[17:31] <jamespage> jdstrand, I know
[17:32] <jpds> jamespage: Ah, yes. The list in my email + strongswan-pt-tls-client (we can ignore n-m for now).
[17:33] <jamespage> jdstrand, yes - but ipsec-tools and racoon where in main
[17:33] <jamespage> jdstrand, I guess I'm uncomfortable as I was not aware of this plan until 10 days ago
[17:34] <jdstrand> jamespage: I'm confused about the support position you are referring to. are you referring to openvswitch or ipsec-tools to strongswan migration?
[17:34] <zzxc> Hey guys. I have a question. I had a script I want to run on startup for a machine that does a mount -bind. How would I get it to run on start up?
[17:34] <jpds> jamespage: Anyone using them, is going to probably see their quality of life improve with something a little more... modern. ;-)
[17:35]  * zzxc wonders if his conf has gone screwie or if jdstrand, jpds, and jamespage are talking using /me comments
[17:35] <jdstrand> jamespage: moving to strongswan is no different than moving to another supported technology in any other software in the stack. we release note that ipsec-tools no longer receives support and users should migrate to strongswan, which works better (more featureful, active upstream, etc)
[17:36] <jdstrand> jamespage: people who need ipsec-tools can use it on 12.04 for 3 more years. upgrade timelines are at their discretion
[17:39] <jdstrand> jamespage: honestly, I bet people are simply installing strongswan from universe anyway-- ipsec-tools hasn't gotten a new release in 3 years
[17:39] <jamespage> jdstrand, just uncomforable doing this right now - I've not had three months to thing about it
[17:40] <jdstrand> jpds: perhaps you can step in here-- you are the one driving this
[17:40] <sarnold> zzxc: must be your configuration, they look like normal /msg #ubuntu-server to me
[17:41] <sarnold> zzxc: /etc/rc.local may be the easiest way to get your script to run; you could create an upstart job just for your script if you wanted to be fancy: http://upstart.ubuntu.com/cookbook/
[17:41] <bekks> zzxc: fstab ;)
[17:42] <jpds> jamespage: Well, I've been using the tool since August last year pretty much.
[17:42] <zzxc> bekks: Hahaha thanks for that bekks.
[17:44] <sarnold> bekks: does that work out alright for bind mounts? cool :)
[17:44] <bekks> sarnold: Sure.
[17:44] <zzxc> sarnold: Actually I never understood upstart jobs. Isn't it just basically just like sticking it in the init.d folder and running update-rc.d?
[17:44] <jpds> jamespage: All the IPsec stuff's in the kernel; there are essentially keyring daemons with feature sets.
[17:45] <zzxc> bekks: Yeah still kind of nervious about that. Espically if something happens to the prod server.
[17:45] <bekks> zzxc: Then test the fstab entries before rebooting. Whats the problem with that?
[17:46] <sarnold> zzxc: I found upstart's 'native' interface easier to use than the sysv compatibility things, or the old sysv-init
[17:47] <jdstrand> jpds: perhaps describing more why it is desirable over ipsec-tools (perhaps with why you are pursuing it to beging with)
[17:47] <zzxc> bekks: Honestly. If I leave the company I'm working for I wouldn't trust the other people to remeber to do a check on the prod machine before restarting it when they need to update it.
[17:48] <zzxc> sarnold: Hmmm alright. Isn't upstart going away in the next couple of version though?
[17:48] <jpds> jdstrand: That's all in the bug.
[17:48] <jamespage> jdstrand, jpds: tbh I don't think this is up to me to decide - this counts as a feature for me - I've pushed it to the release team
[17:49] <sarnold> zzxc: yeah, eventually. fwiw I prefer bekks's advice after hearing it :) hehe
[17:49] <jdstrand> jamespage: from my perspective, the fact that strongswan has an active community upstream, within Debian and Ubuntu, has a modern feature set and is well-written are all compelling. Holding on to something that has gotten upstream attention in 3 years for a security sensitive piece of software is not desirable
[17:50] <jdstrand> hasn't*
[17:50] <zzxc> *sigh* alright. I've gone through enough holding my breath during the heartbleed fixes. Guess I'm going to have another everytime we update it.
[17:50] <jpds> jamespage: Yeah, they pushed me towards you.
[17:53] <sarnold> zzxc?
[17:54] <bekks> zzxc: sudo apt-get update; sudo apt-get dist-upgrade; <- that how to install the heartbleed fixes.
[17:55] <zzxc> Whats up sarnold?
[17:55] <zzxc> bekks: Yeah I know. We took a slightly different route and used unattended_upgrade
[17:56] <zzxc> Boss was terrified of compadibiltiy breaking.
[17:57] <sarnold> zzxc: I'm just curious what you mean by "guess i'm going to have to hold my breath every time we update it" ..
[17:57] <bekks> zzxc: He should have read the changelog then.
[17:57] <zzxc> bekks: ? Which change log?
[17:59] <bekks> zzxc: the changelogs for the bugfixes? http://www.ubuntu.com/usn/usn-2165-1/
[18:02] <zzxc> bekks, Yeah of course right. No I read through that. It was more along the lines of only doing a security update rather than updating jaxb, or 3cpo, or hibernate.
[18:02] <bekks> zzxc: Those applications do not need to be updated to fix the heartbleed issue.
[18:04] <zzxc> Right. no I get that we could have just recompiled openssl as well with the noheartbeat flag and it would have worked as well. But I wanted to do all of the security updates. He didn't want to update anything that wasn't a secuirty fix so using unattended_upgrade was the medium for only updating the security patches, and not other updates that would have been covered in a dis-upgrade.
[18:05] <bekks> you can easily cover security-only updated in dist-upgrade, too.
[18:06] <sarnold> zzxc: thanks for not compiling your own, that's a path of pain and suffering. we do updates so our users don't have to do them themselves :) hehe
[18:07] <sarnold> zzxc: see https://wiki.ubuntu.com/SecurityTeam/FAQ#Repositories  for a quick description of what bekks is describing
[18:07] <zzxc> bekks: How so?
[18:07] <zzxc> sarnold: Thanks
[18:08] <bekks> zzxc: Disable all repos but the security ones, run sudo apt-get update; sudo apt-dist-upgrade; and re-enable all formerly disabled repos again.
[18:08] <bekks> 1zThat takes about 5 minutes overall.
[18:09] <zzxc> Mmmmm yeah, I thought of that as well. You can also change the ranking of secuirty updates to 500 and downgrade the none security updates to 50.
[18:10] <bekks> Which doesnt help at that point.
[18:10] <zzxc> Basically all i had to do was do sudo apt-get update && unattended-upgrade -d. which did the same thing.
[18:10] <bekks> because regardingless of the ranking, non-security updated would have been pulled in.
[18:13] <zzxc> bekks: No currently installed applications have a ranking of 100 (I beleive) so unless you need pull in a new version for a dependency its less desirable than an application that has already been installed.
[18:13] <bekks> zzxc: That doesnt affect what I just said. :)
[18:13] <zzxc> So why would the non-security be updated?
[18:14] <bekks> Because of the enabled repos.
[18:14] <bekks> Not because of their ranking whatsoever.
[18:14] <sarnold> if all your updates are through unattended-upgrades it probably does the right thing; but when you go to run apt-get -u dist-upgrade yourself, it'll pull in all -updates and -security packages together..
[18:14] <bekks> dist-upgrade literally means "get them all". No matter which ranking the updates have.
[18:15] <zzxc> http://askubuntu.com/questions/194/how-can-i-install-just-security-updates-from-the-command-line the second entry was was I was talking about.
[18:16] <zzxc> was what*
[18:16] <zzxc> sarnold: Actually that was what I was wondering about. If I do a dis-upgrade -security does it only pull in security updates?
[18:17] <bekks> There is no such parameter.
[18:19] <zzxc> bekks, Ok I didn't think there was. Is there a way to tell dis-upgrade to only install the secuirty updates?
[18:19] <bekks> zzxc: Disable all other repos.
[18:21] <zzxc> bekks, Ok right, so short of disabling the other repos there is no way to do that?
[18:22] <zzxc> sarnold: And right. But the lead developer didn't want to do a full update because he was convinced it would break something and at midnight I didn't really feel like arguing with him about it.
[18:23] <sarnold> zzxc: yeah, that part makes a lot of sense :) hehe
[18:23] <dv81> zzxc: it will break imo
[18:25] <zzxc> Doing an unattended_upgrade to update only the secuirty patches? It wouldn't shock me honestly, but it is a feature that sets it self up like a cron job to do updates on prod machines ever so often. And honestly the system is pretty stable still and I just need it to work for about 2 or 3 more months then I can upgrade the system to the new LTS.
[18:27] <zul> hallyn:  i already uploaded a fix for the libvirt cloud-archive bug
[18:27] <zzxc> Or more actually build a new system and move over to that. I'm also hoping I can move the data volumes over to ext4 or s3.
[18:28] <bekks> zzxc: You are on ext3 currently?
[18:30] <zzxc> For the data volumes yes. A lot of the infrastructure has been here well before I got here.
[18:30] <hallyn> zul: which one is that?
[18:30] <bekks> zzxc: Then mount the as ext4, done.
[18:31] <zzxc> bekks, wait really? I know ext3 and ext4 are pretty simalar but won't I still not have the journaling functionality of a ext4 drive?
[18:32] <bekks> Guest88173<EMAIL_ADDRESS>that should be enough to know you're not anonymous ;)
[18:32] <bekks> zzxc: ext3 is a journalling fs, too.
[18:32] <bekks> zzxc: And you can upgrade to ext4 by just mounting ext3 as ext4.
[18:33] <lordievader> bekks: Really, no need for any conversion tools?
[18:33] <bekks> lordievader: No need for tools whatsoever.
[18:33] <zul> hallyn:  the libvirt apparmor change on precise
[18:33] <lordievader> Nice :)
[18:33] <hallyn> zul: ok, so you took the one i uploaded to trusty?
[18:34] <zul> hallyn:  when did that happen?
[18:34] <hallyn> earlier today
[18:34] <zul> hallyn:  no but i will
[18:34] <hallyn> cool, thx
[18:48] <zzxc> bekks: Cool good to know. Thank you.
[19:08] <jamespage> jpds, still around? whats the closest thing to ipsec-utils in strongwan?
[19:09] <jpds> jamespage: That packages doesn't exist?
[19:10] <jamespage> jpds, I have to replace ipsec-utils on the iso with something equivalent
[19:10] <jpds> $ apt-cache show ipsec-utils
[19:10] <jpds> N: Unable to locate package ipsec-utils
[19:10] <patdk-wk> ipsec-tools you mean?
[19:11] <jamespage> I do
[19:11] <jamespage> jpds, ipsec-tools
[19:11] <jpds> jamespage: All of that should be in strongswan-starter.
[19:13] <jamespage> jpds, ok
[19:13] <jamespage> jpds, just testing the seed changes now
[19:16] <jamespage> jdstrand, I'll make the seed change in the ISO to demote ipsec-tools in favour of strongswan-starter
[19:17] <jdstrand> jamespage: ok. I looked at openvswitch more and it shouldn't need a packaging change
[19:18] <jdstrand> I thought it did, but it doesn't install raccoon or ipsec-tools during the build
[19:18] <jdstrand> I'm kinda curious what the testsuite is actually testing now, but not enough to look at it :P
[19:20] <jamespage> jpds, which was the additional package you wanted in the seed?
[19:21] <jpds> jamespage: https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1266066/comments/13
[19:21] <jpds> jamespage: +strongswan-pt-tls-client.
[19:22] <jdstrand> jamespage: ok, so I should not touch serv-ship. got it
[19:22] <jamespage> jpds, ok
[19:22] <jdstrand> server-ship
[19:22] <jamespage> jpds, how does this look> http://paste.ubuntu.com/7251357/
[19:24] <jpds> jamespage: +1.
[19:25] <jamespage> jpds, is strongswan-nm - that appear to pull network-manager into the misc-server seed?
[19:25] <jpds> jamespage: Oh, drop that one.
[19:25] <jpds> That would be for network-manager-strongswan, which I'm not too fussed about.
[19:25] <jamespage> jpds, ack
[19:31] <jamespage> jdstrand, jpds: seed changes pushed
[19:32] <jdstrand> thanks!
[19:32] <jamespage> jdstrand, np
[19:32] <jpds> jamespage: Thank you!
[19:32] <jdstrand> ipsec-tools demoted (openvswitch-ipsec already was)
[19:32] <jamespage> jpds, thanks for your work on this this cycle
[19:32] <jdstrand> crafting a release note now
[19:38] <jpds> jamespage: Always a pleasure. :)
[19:41] <jamespage> jdstrand, thanks for doing the release note btw
[19:42] <jdstrand> np
[19:44] <jdstrand> jamespage: did you commit all your changes? I only see the strongswan-starter change
[19:44] <jamespage> jdstrand, in server-ship yes
[19:45] <jamespage> jdstrand, the others are in supported-misc-servers in the platform.trusty seeds
[19:45] <jdstrand> ah, platform.trusty
[19:46] <jdstrand> right. thanks!
[19:46] <jdstrand> jamespage: I'm going to get ahead of component-mismatches and promote these now
[19:58] <smoser> zul, is there a way to easily tell which cloud-archive packages have delta ?
[19:58] <bekks> have delta compared to what?
[19:59] <smoser> compared to their source release.
[19:59] <smoser> ie, the majority are straight (changelog change only) backports of trusty packages for icehouse
[19:59] <smoser> but some require changes.
[20:01] <smoser> my best guess is package presense at https://code.launchpad.net/~ubuntu-cloud-archive/
[20:04] <zul> smoser: not really...its just libvirt/xen/mongodb/subunit that have deltas
[20:06] <smoser> i'm fairly sure thats not true.
[20:06] <smoser> i know mongodb oes
[23:56] <Runemoro> Hi, could anyone help me fix some problems I'm having with bind9?
[23:58] <Runemoro> Whenever I do "dig @rebornlegend.no-ip.org rebornlegend.tk", I get the correct response, but if I remove the<EMAIL_ADDRESS>part, it doesn't work anymore. I've checked with whois that my nameserver is set to rebornlegend.no-ip.org
[23:59] <sarnold> hah, why is the "dot tk" registry in the netherlands? o_O


[00:28] <jose> jacekn: ping
[08:33] <niedbalski> good morning eco's
[14:12] <fali> Hello. I installed juju-gui on machine0. Worked fine, but I get the following error message in the web browser: "Charm API server did not respond". Can't find that anyone else has this problem, so trying here.
[14:12] <fali> I can't find anything in the logs, and the juju.conf file shows the correct proxy settings.
[14:13] <avoine> fali: juju-gui use websockets does your proxy allow that?
[14:16] <fali> avoine: Don't know, but I doubt it... Will check. Is there any workaround if it's not allowed?
[14:17] <avoine> fali: I was using nginx an I had to upgrate to a newer version and follow this: http://nginx.org/en/docs/http/websocket.html
[14:20] <avoine> fali: if you use a browser inspector in the network tab you should see the error for the websocket request (one every seconds I think)
[14:35] <fali> avoine: seems like our corporate proxy won't let us through. I have no possibility to change that :( Is it possible to run juju-gui locally? downloading what we need, then use our own Charm API server?
[14:41] <avoine> fali: yes, you could install it by checking what the charm is doing but I'm not sure if juju-gui is using websocket for his communication
[14:41] <avoine> like getting charms from the charm store for example
[14:45] <avoine> fali: I'm looking at the code and I looks like it's the case so it won't work.
[14:45] <avoine> https://github.com/juju/juju-gui/blob/develop/app/config-prod.js#L36
[14:46] <avoine> maybe you can change the socket_protocol variable tought
[14:54] <fali> avoine: Ok. First I'll try finding a proxy that is a bit more cooperative. Thank you so much for your input.
[14:54] <avoine> fali: np, good luck
[15:04] <breze441> Trying to add netapp nfs share in to cinder . how do i paass the netapp info in to cinder via juju ? it appears manual config on cinder.conf get overwritten by juju
[15:37] <breze441> sorry to repeat but just wondering if anyone knows how to pass netapp config to cinder via juju
[15:48] <jcw4> breze441: what charms are you using?
[15:49] <jcw4> breze441: I assume cinder
[15:49] <jcw4> breze441: is there a charm for netapp?
[15:50] <breze441> no charm for netapp, i was trying to follwo the steps for RDO packstack by editing the cinder.conf but it get overwritten by the juju during cinder restart
[15:51] <breze441> i am assuming the same parameters should be able pass via juju cli to cinder
[15:52] <jcw4> breze441: hmm
[15:53] <jcw4> breze441: so you're doing 'juju deploy --config=cinder.conf cinder', but when cinder restarts it overwrites the cinder.conf file ?
[15:53] <jcw4> breze441: I mean juju overwrites cinder.conf when the cinder service restarts?
[15:56] <breze441> when i deployed i didnt have these netapp configs in the config file . so i go and edit the file with configs netapp recommends to use. to complete the process i have to do a stop jujud-cinder follwed by a start jujud-cinder where i lose the netapp configs. Now if i know how to send them when deploying i dont have to edit the configs
[15:57] <jcw4> breze441: I see that makes sense
[15:57] <jcw4> breze441: so if you edit the config after deploying, juju doesn't know about it and overwrites the config file...
[15:58] <jcw4> breze441: you want to know how to tell juju about the config settings so that juju doesn't overwrite it?
[16:07] <breze441> exactly, maybe there is a way to pass these information when o deploy.
[16:08] <breze441> on side note, is it possible to change conf files deployed with Juju ?
[16:09] <jcw4> breze441: I'm doing a little research to see if I can answer that; I don't really know much about it but I hope to get the people who do involved :)
[16:10] <breze441> much appreciated
[16:20] <lazyPower> breze441: thats dependent on how the charm is implemented. Idempotency dictates if you've made changes to a config file vs what the charm expects, it should update it.
[16:20] <jcw4> lazyPower, breze441 when you say edit the config... did you edit it in the charm directory or on the unit where it's deployed?  lazyPower does that make a difference?
[16:21] <lazyPower> breze441: is a charm you're deploying not exposing a configuration set? If thats the case there are 2 options here. 1) you can file a bug against the charm to see if the maintainer deems this missing behavior - or 2) you can fork the charm and implement the configuration file changes you need and track upstream by backporting patches as they are released.
[16:22] <jcw4> breze441: this is the charm right? https://github.com/charms/cinder
[16:22] <lazyPower> jcw4: When you edit a charm on the server, any edits will be blown away on the next upgrade of the charm - if you edit the config file manually - each run will blow your changes away. its all about idempotency. If it's already taken the action, and there's no delta on the files - it shouldn't execute. If it's got modifications, the charm should assume it requires an update and use the templated config.
[16:22] <jcw4> lazyPower: that makes sense to me, so you should edit the template if you want it to remain?
[16:23] <lazyPower> so you're better off to fetch the charm locally, and make the required modifications - and if deemed necessary, submit a patch back against the charm so everyone benefits.
[16:23] <lazyPower> Yep
[16:23] <breze441> so i edited the cinder.conf on the node *not the charm*
[16:23] <lazyPower> that or make it configurable.
[16:24] <jcw4> lazyPower: I see.  I think the specific config that breze441 is changing is not specific to cinder, it's actually specific to netapp
[16:25] <jcw4> is that right breze441 ?
[16:26] <jcw4> so I'm assuming breze441 would edit the charm template locally, but wouldn't propose it be merged back into the charm
[16:27] <lazyPower> that would be my suggestion - it will be prudent to make sure you subscribe to the upstream charm's launchpad repository so you're aware when updates are published so you can backport them to your local charm deployment
[16:27] <breze441> well there are few lines of config specific to netapp i need to add to the cinder.conf to load netapp drivers
[16:27] <lazyPower> thast the downside to forking a charm - you lose automatic upgradeability, it becomes a required manual step - its really simple, but takes away a dash of taht 'magic' juju brings to the table.
[16:28] <breze441> well the drivers are in upstream its just pointing the ip address of the netapp filer and credentials etc..
[16:28] <lazyPower> so ideally if everyone would benefit from loading netapp drivers - i'd propose a merge and see where it goes.
[16:28] <lazyPower> the worst that will happen is they say no
[16:28] <lazyPower> in which case you're no worse off than when you started, and *then* you walk down the path of maintaining a forked charm.
[16:32] <breze441> any any pointers on how to edit the cinder charm ?
[16:34] <lazyPower> do you have charm-tools installed?
[16:34] <breze441> sync-tools ? if so yes
[16:34] <lazyPower> sudo apt-get install charm-tools
[16:35] <lazyPower> mkdir -p ~/charms/<series> && cd ~/charms/<series> && charm get cs:<series>/cinder
[16:35] <lazyPower> then when you're ready to test your revisions: juju deploy --repository=$HOME/charms local:<series>/cinder mycinder
[16:36] <lazyPower> the cinder charm is in python, has unit tests, and is extremely well covered in terms of code quality - so  you should have a good foundation to work off of. Our OpenStack charms are stellar examples of charms.
[16:37] <breze441> ok Thank you let me give it a shot
[16:38] <lazyPower> np, if you get stuck dont hesitate to ask :)
[17:32] <jose> jacekn: ping
[20:11] <revagomes> Hi mates! Can anyone give me a hint about the connection refused error when trying to run juju status? When I ran juju status --debug -v I've got the following message: "DEBUG juju.state.api apiclient.go:248 error dialing "wss://localhost:17070/", will retry: websocket.Dial wss://localhost:17070/: dial tcp <IP_ADDRESS>:17070: connection refused"
[20:14] <revagomes> I can ssh the service by hand but when I tried running "juju ssh [service]" it doesn't work The juju log shows
[20:15] <revagomes> that it's trying to start the api and dialing "wss://[...]" but thr connection is refused
[20:17] <marcoceppi> revagomes: is this local provider?
[20:18] <revagomes> marcoceppi, yep
[20:18] <marcoceppi> revagomes: run `sudo initctl list | grep juju` what does it say?
[20:18] <revagomes> I was using juju v1.20 but I already upgraded to 1.20.1
[20:19] <revagomes> juju-agent-revagomes-local stop/waiting
[20:19] <revagomes> juju-db-revagomes-local stop/waiting
[20:19] <marcoceppi> revagomes: run
[20:19] <marcoceppi> sudo start juju-db-revagomes-local
[20:19] <marcoceppi> sudo start juju-agent-revagomes-local
[20:20] <marcoceppi> revagomes: then do the list command again and make sure both are started
[20:22] <revagomes> The processes are running now. Perfect! The juju status and other commands are working now. ;)
[20:22] <revagomes> marcoceppi++
[20:22] <revagomes> marcoceppi, I have to start the processes by hand or it's was a bug from the 1.20 version?
[20:23] <marcoceppi> revagomes: this happens if you restarted the computer typically
[20:24] <sebas5384> revagomes: \o/
[20:25] <revagomes> marcoceppi, I got it. So to set juju processes to run on startup seems a good way to prevent this next time ;)
[20:25] <revagomes> marcoceppi, tks!
[20:25] <marcoceppi> revagomes: we did this a while ago
[20:25] <marcoceppi> people complained about it
[20:25] <sebas5384> thanks marcoceppi! revagomes is starting to use juju these days with us :)
[20:26] <marcoceppi> revagomes: we're building a "local" command, so in the future you can just do `juju local start` or `juju local suspend` etc to safely turn off/on local provider and recover from a state
[20:26] <marcoceppi> sebas5384: great to hear!
[20:26] <sebas5384> marcoceppi: that would be great! a start and stop
[20:26] <revagomes> awesome!


[19:19] <lotka> hey guys
[19:20] <lotka> I'm new to Lubuntu, are there any must have programs i should install?
[19:22] <kc2bez> lotka: I guess that depends on what you would like to do. There are many great applications already installed.
[19:23] <lotka> im looking to browse the net with privacy, ive tried tor browser but its a bit slow, are there any other browsers that focus on privacy?
[19:24] <wxl> tor is the only one the actually does it well
[19:25] <wxl> more to the point i should say tor is the only way to truly use the internet privately
[19:25] <wxl> however, it is NOT meant to be fast
[19:26] <wxl> unless you're using onion sites (i.e. those within the tor network itself and not the clearnet, what we normally think of as the internet)
[19:26] <lotka> would firefox and a vpn be adequate? i dont plan on overthrowing any governments...yet... so dont need anything too extreme
[19:27] <wxl> good point. it's your threat level that will suggest the right course of action
[19:27] <wxl> i would say that would be fairly reasonable, but be careful about your choice of vpns
[19:28] <akemhp> VPN is fine, but it's not free usually, NordVPN is pretty cheap and i can recommend it, i'm using it since about 2 years.
[19:28] <wxl> i would recommend riseup-vpn which is not the fastest solution but absolutely the best at respsecting your privacy
[19:28] <lotka> great ill give them both a look, i have a Windscribe account that has 60gb a month but not sure how secure they are
[19:29] <wxl> https://snapcraft.io/riseup-vpn
[19:29] <akemhp> Choose one that does not log and that has lots of servers available around the world.
[19:29] <wxl> riseup is donationware, fwiw
[19:43] <lotka> i thought id try riseup on windows and Defender detected "Program:Win32/Uwasson.A!ml" as a threat, any idea what this is?
[19:48] <akemhp> https://www.reddit.com/r/nethack/comments/dsavio/unnethack_and_uwassonaml_virus_detection_false/
[19:49] <lotka> awesome thank you
[20:14] <lotka> is there a way to enable a dark theme for the FIle Manager?
[20:27] <tbs> wxl: i also couldnt find vpn, riseup seem so good realy, thanks
[20:29] <akemhp> Didn't find out to apply dark theme to file manager, however Thunar file manager can use dark gtk theme without pblm.
[20:29] <akemhp> It's similar.
[20:30] <akemhp> Because i use dark themed Thunar on my other regular Ubuntus.
[20:30] <wxl> akemhp: is that lubuntu 18.04?
[20:30] <lotka> ok thanks ill check it out
[20:30] <tbs> lotka: i checked some but i dont remember any of them makes file manager dark
[20:31] <akemhp> wxl, 19.04 i think, but i'm on normal Ubuntu right now, not the same computer. Not sure.
[20:32] <wxl> sorry i meant that for lotka.. what version of lubuntu you on?
[20:40] <wxl> https://phab.lubuntu.me/w/packaging/packaging_for_new_upstream_releases/
[20:46] <kc2bez> wxl: Ooops ^
[20:47] <kc2bez> But yeah +1 on that.
[20:47] <wxl> and i was doing so good, too


[00:26] <smoser> i'd really appreciate it if someone could take a look at the cloud-init upload in xenial-proposed.
[00:26] <smoser> I dont intend to be quick about moving it out of proposed at all, but would like it to get *in* to proposed to further testing.
[00:27] <smoser> bug 1577872
[00:28] <smoser> bah. bug fail
[00:28] <smoser> bug 1595302
[00:28] <smoser> better
[04:35] <ubuntu__> here something i don't get in /proc/iomem the sound is apparently using this mmap  address  f7d30000-f7d33fff : ICH HD audio doing out the math you only have 16 KB of memory for the buffer of audio . If your sampling  at 32-bit, 192 kHz how is this buffer going to be large enough. Maybe i am misunderstanding something
[04:50] <mgedmin> that's probably just the control registers
[04:50] <mgedmin> I would expect audio buffers to be DMAed from the main memory
[05:32] <cpaelzer> good morning
[05:36] <Skuggen> nacc: Just in case it wasn't clear, it does mean it's actually trying to connect to a database named "${db_name}"
[05:36] <Skuggen> nacc: http://paste.ubuntu.com/17732610/
[05:36] <Skuggen> nacc: And that the user is valid, or you wouldn't see the «to database» bit
[06:14] <pitti> Good morning
[06:15] <pitti> rbasak: mysql-server-5.7 is now the only remaining rdepends of initscripts in the whole yakkety archive; sooo tempted to cherry-pick that upload to finally finish it off..
[06:15] <pitti> rbasak: would that actually get in your way somehow?
[06:16] <ubuntu__> So i am wondering about how this acpi works for advanced configuration power interface really confused
[06:16] <ubuntu__> curious anybody familar with how these ports work
[06:16] <ubuntu__>   0400-0403 : ACPI PM1a_EVT_BLK
[06:16] <ubuntu__>    0404-0405 : ACPI PM1a_CNT_BLK
[06:16] <ubuntu__>    0408-040b : ACPI PM_TMR
[06:16] <ubuntu__>    0410-0415 : ACPI CPU throttle
[06:16] <ubuntu__>    0420-042f : ACPI GPE0_BLK
[06:16] <ubuntu__>    0450-0450 : ACPI PM2_CNT_BLK
[06:16] <ubuntu__> I have these ports for it
[06:17] <ubuntu__> And  d9ff9000-da2f9fff : ACPI Non-volatile Storage
[06:17] <ubuntu__> da35b000-da5dafff : ACPI Non-volatile Storage
[06:17] <ubuntu__> da5db000-da5dffff : ACPI Tables
[06:17] <ubuntu__> da5e0000-da622fff : ACPI Non-volatile Storage
[06:17] <ubuntu__> for the mmap
[06:19] <ubuntu__> I understand it is made some how platform independent uses some type of bytecode though  don't really get it at all there are like  tons of tables with in the ACPI TABLE 20kb address space  like DSDT SSDT XSDT ...
[06:19] <ubuntu__> Anybody good with this stuff
[06:27] <rbasak> pitti: an upload to Yakkety? That's fine if you want to upload it.
[06:31] <pitti> rbasak: yes, that; ok, thanks
[06:55] <LocutusOfBorg> pitti, please try ubuntuone-dev-tools against python-coverage in proposed? :) thanks
[06:55] <LocutusOfBorg> or the opposite is even better
[06:56] <pitti> LocutusOfBorg: err, python-coverage pulls in ubuntuone-dev-tools? that sounds strange
[06:59] <pitti> LocutusOfBorg: running: http://autopkgtest.ubuntu.com/running.shtml#pkg-ubuntuone-dev-tools
[06:59] <LocutusOfBorg> ubuntuone-dev-tools has a test with coverage
[06:59] <LocutusOfBorg> and the coverage in proposed is fixed, together with ubuntuone-dev-tools in proposed
[06:59] <pitti> but it seemed to me that the new python-coverage regresses
[06:59] <pitti> oh, ok, great
[07:00] <LocutusOfBorg> :)
[07:00] <pitti> mvo: btw, I uploaded https://launchpad.net/ubuntu/+source/ubuntu-core-launcher/1.0.30ubuntu1 last night, it broke too many things
[07:00] <LocutusOfBorg> so, I guess you can retry the one against python-coverage, make python-coverage migrate, and then I can retry the one on ubuntuone-dev-tools and see it migrate too :)
[07:00] <LocutusOfBorg> or you can retry them both, as you like
[07:01] <pitti> mvo: still makes stuff uninstallable (http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt), but I'll leave that other transition to you :)
[07:01] <LocutusOfBorg> I'm leaving, thanks pitti
[07:02] <mvo> pitti: thanks and sorry, we meant to release a new version but there were some hickups there too
[08:12] <LocutusOfBorg> thanks pitti it worked flawlessly
[08:12] <pitti> nice
[08:27] <flexiondotorg> Anyone able to review a trivial merge proposal for indicator-session that would really help out Ubuntu MATE? https://code.launchpad.net/~ubuntu-mate-dev/indicator-session/mate-compatibility/+merge/297183
[08:39] <kmadac> Hello, I would like to ask where to find ics-dhcp-client package repository for ubuntu xenial. I tried to make "bzr branch ubuntu:isc-dhcp-client isc-dhcp-client.dev", but I get Invalid url error. Thanks
[08:40] <Odd_Bloke> kmadac: UDD (which provides bzr branches for packaging) is not used for xenial, so AFAIK your best is to use pull-lp-source in the ubuntu-dev-tools package.
[08:41] <kmadac> Odd_Bloke: Thank you :)
[08:46] <Odd_Bloke> pitti: Good morning!  https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1584393 looks like an ifupdown/SSH systemd deadlock/race condition on xenial; do you have the time to dig in to it?
[08:57] <pitti> hey Odd_Bloke
[08:59] <pitti> Odd_Bloke: I can't reproduce this in a VM, but yes indeed, looks like a deadlock
[08:59] <pitti> Odd_Bloke: it could be fixed in openssh's if-up.d hook to reload asynchronously
[08:59] <pitti> or in invoke-rc.d to make all reloads async, but this is prone to break other things which expect it to block until it's actually done
[09:00] <Odd_Bloke> pitti: (If you do want a system to look at, I've `ssh-import-id pitti`'d on<EMAIL_ADDRESS>[09:00] <pitti> also, utterly low-prio -- restarting networking has never worked at all under upstart, and now it at least seems to work most of the time
[09:00] <Odd_Bloke> pitti: Yeah, I'm only asking because we're beginning to hear from partners about it.
[09:01] <pitti> Odd_Bloke: works on your system too
[09:02] <Odd_Bloke> ... It didn't before.
[09:02] <Odd_Bloke> Weird.
[09:10] <Odd_Bloke> pitti: Thanks for the bug comment. :)
[09:45] <Unit193> jbicha: Howdy.  Do you plan to package numix-gtk-theme as well?
[09:47] <Unit193> Ah, #827792 I see.
[09:48] <mwhudson> i'm sure i'm missing something obvious (and i'm tired and my brain isn't working)
[09:48] <mwhudson> but can someone explain to me why golang-defaults is not migrating?
[09:48] <mwhudson> it says "golang-any-shared-dev/amd64 unsatisfiable Depends: golang-any"
[09:49] <mwhudson> but golang-any is made by the same package...
[09:51] <mwhudson> and the package installs fine
[09:57] <Unit193> jbicha: Also FWIW Shimmer/Xubuntu may look into the GTK-3.20 patch here soon, but since Ubuntu is standing still on that it's not a high priority in Greybird, at least last I knew.
[10:00] <Unit193> ...It'd be weird for the GTK theme to dep on the icon theme, I'd believe.  Recommends or suggests would be better.
[10:43] <shemgp> is this where i ask for help in fixing an ubuntu bug in a package?
[10:43] <shemgp> bzr branch ubuntu:tomboy tomboy.dev from http://packaging.ubuntu.com/html/udd-getting-the-source.html#branching doesn't seem to work in my machine
[10:43] <shemgp> says: bzr: ERROR: Not a branch: "bzr+ssh://bazaar.launchpad.net/+branch/ubuntu/tomboy/".
[13:10] <brendand> has anyone here ever tried configuring virsh/kvm to run an ipv6 (only) network? i'm a bit lost as to why it won't work
[13:36] <pitti> rbasak: yay, mysql-5.7 went in, with it the new sysvinit, so initscripts is history now \o/
[13:43] <infinity> pitti: Do you have some armhf autopkgtest machines running trusty kernels and some running xenial kernels?
[13:44] <infinity> pitti: I'm seeing a regression on glibc/wily that looks suspiciously related to running kernel.
[13:44] <pitti> infinity: ah, in fact I do; have one with t/w/x each, to bisect bug
[13:45] <pitti> the "old" LXC nodes on cyclops all run xenial
[13:45] <pitti> but I also have some new scalingstack ones
[13:45] <infinity> pitti: I guess there's no way to direct a job at a specific machine? :P
[13:45] <pitti> infinity: but this is actually obsolete, it's not due to the VM guest kernel; so I can bring them all up to xenial again
[13:45] <pitti> infinity: there is with some hand-holding
[13:46] <infinity> pitti: Of course, if the goal is to bring them all to xenial, that doesn't help me here. ;)
[13:46] <pitti> infinity: we record the kernel version, so it's easy enough to check
[13:46] <pitti> infinity: oh, you are saying xenial's is *worse*?
[13:46] <infinity> pitti: Since it's the xenial builds that fail, all the green ones are trusty.
[13:46] <pitti> 'cause that's all we've ever had
[13:46] <pitti> *all*?
[13:47] <infinity> Well, the random sampling of green that I've looked at.
[13:47] <infinity> They all look to be 3.13
[13:47] <infinity> Only those select few reds were 4.4.0
[13:48] <infinity> But I've not been patient enough to download *all* the logs.  If you can prove me wrong, I'm all for it. :)
[13:48] <pitti><EMAIL_ADDRESS>[13:48] <pitti> that indeed was a trusty kernel, yes (green)
[13:48] <pitti> ooh!
[13:49] <pitti> infinity: right, the cyclops boxes run trusty kernels on xenial userspace as newer kernels don't work on those any more
[13:49] <pitti> I forgot, sorry
[13:49] <infinity> "cyclops" being... highbanks?
[13:49] <pitti> yes
[13:49] <infinity> If highbank regressed in xenial, we should fix that.
[13:49] <pitti> (Calxeda nodes)
[13:49] <infinity> It's meant to work, so the bug is likely downstream.
[13:50] <infinity> Anyhow.
[13:50] <pitti> yeah, may just be a config issue
[13:50] <pitti> AFAIR, it doesn't boot because it doesn't find the root fs, maybe missing driver
[13:51] <infinity> None of this is your problem.  I don't care what kernels the autopkgtest machines run (well, I care for kvm ones, but for lxc runners, whatever), just making sure my hypothesis that tst-signal6 regresses on newer kernels indeed matches your data.
[13:51] <pitti> yes, I agree
[13:54] <infinity> apw: ^-- On armhf, tst-signla6 is going to flap based on which node you land on, if you grep the log for "running kernel", 3.13 should be fine, 4.4 is bust.  That's not a new regression.
[14:49] <apw> infinity, ack thanks
[14:50] <roadmr> Hello folks! Firefox 47.0 breaks Selenium, is there a way to get the immediately previous version (46.0)? on Trusty, the only other one I see is 28.0 which is too old :(
[14:51] <nacc> Skuggen: yep, it's something screwed up during the build, I'm just trying to backtrack with dbconfig where it's getting that database name from. Thanks for the tip!
[14:53] <nacc> roadmr: is there a bug filed?
[14:53] <nacc> ubuntu__: i think i mentioned this to you earlier this week; that's not really a question for this channel. Ask in #linux or find an ACPI related channel using alis
[14:54] <roadmr> nacc: not on Ubuntu, I think. There's this: https://github.com/SeleniumHQ/selenium/issues/2110
[15:19] <nacc> roadmr: ok, it may help to file a bug in LP and explain. You can see from the changelog (http://changelogs.ubuntu.com/changelogs/pool/main/f/firefox/firefox_47.0+build3-0ubuntu<IP_ADDRESS>/changelog) that many versions have been published in trusty.
[15:20] <nacc> rbasak: ugh, this bacula bug is teaching me quite a bit about dbconfig :) ... but not making much progress
[15:22] <nacc> elbrus: oddly, in /var/log/dbconfig-common/dbc.log: "populating database via sql...  done.", but http://paste.ubuntu.com/17749799/
[15:22] <nacc> elbrus: that's the the dbconfig output with set -x enabled in the common file
[15:24] <cjwatson> roadmr: you can get older versions by manually downloading the .debs, starting from https://launchpad.net/ubuntu/+source/firefox/+publishinghistory
[15:26] <roadmr> cjwatson: awesome!!! thanks! I'm sure I can hack something to use that for my broken tests. Cheers!
[15:27] <nacc> roadmr: i would try the immediately preceding one first and then it's obviously a regression, etc.
[15:28] <roadmr> nacc: it is; Firefox 46.0 works just fine
[15:35] <nacc> roadmr: ah ok
[15:35] <nacc> rbasak: elbrus: found it: http://paste.ubuntu.com/17750447/
[15:55] <nacc> rbasak: fyi, i might need some assistance from you eventually if bacula needs actual mysql changes (they do some db upgrade stuff in the debian pacakging, and i don't think it's been updated for 5.7) (the last upgrade file mentioned in the contents is 5.2.0)
[15:56] <rbasak> Sure
[15:57] <nacc> rbasak: still trying to figure out how dbconfig generates files like '/usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql'
[15:57] <nacc> ah
[15:57] <nacc>         $(foreach db,$(VARIANTS),$(shell debian/scripts/install-dbconfig $(db)))
[16:04] <nacc> i totally see why dbconfig is better for maintainers, but quite difficult to debug :)
[16:05] <doko> apw, is linux-hammerhead still a supported kernel?
[16:05] <apw> i don't think it ever was supported, that was an rsalveti job i think no ?
[16:06] <apw> rtg ^ ?
[16:28] <ogra_> cjwatson, is https://twitter.com/launchpadstatus dead (LP just told me to check it in the "Uh Oh" message)
[16:29] <cjwatson> ogra_: it's alive, but having it be updated for a random unscheduled firewall failure would rather depend on there being any Launchpad staff around for whom it's a reasonable timezone and who aren't on leave.
[16:35] <jbicha> Unit193: https://github.com/numixproject/numix-gtk-theme/issues/488
[16:36] <ogra_> cjwatson, ah, i thought it is a bot
[16:46] <semiosis> hmmm launchpad is not working.  probably due to the flood of replies to the comment I left on bug 1565985 earlier today!
[16:46] <semiosis> heh, it just started working again
[16:47] <semiosis> aww, there weren't any replies to my comment
[16:51] <infinity> semiosis: We had a datacenter spontaneously reboot.  You didn't break it. :P
[16:52] <semiosis> ouch.  good luck with that
[16:53] <elbrus> nacc: your last message is it...
[16:53]  * elbrus means http://paste.ubuntu.com/17750447/
[16:53] <nacc> elbrus: yeah, i'm trying to work through dbconfig's generator to see why that's happening
[16:53] <elbrus> nacc: dbconfig-common taks that from bacula
[16:54] <nacc> i think it's a bad variable subsittution in the bacula build
[16:54] <elbrus> nacc: I thought you figured that out yesterday while I was still on-line
[16:55] <elbrus> isn't /usr/share/dbconfig-common/data/bacula-director-mysql/install/mysql in the bacula package, no mistery there I think
[16:55] <nacc> elbrus: i'm fully new to dbconfig, so i didn't realize that; or which particular file it was
[16:55] <nacc> elbrus: now i know, and am trying to work out what's generating that file
[16:55] <elbrus> did you read the documentation?
[16:55] <elbrus> especially the design document
[16:56] <elbrus> only about 3 pages IIRC
[16:56] <nacc> elbrus: yep, after realizing this, reading that now
[16:56] <nacc> *read
[16:57] <nacc> elbrus: so bacula has this debian/scripts/install-dbconfig file; which contains the lines: extract_here("src/cats/make_".$longdb."_tables", "debian/bacula-director-$db/$DBC/bacula-director-$db/install/$db");
[16:58] <nacc> but that source file is a shell script, and it seems like it's getting parsed somehow
[16:59] <nacc> because what ends up in install/mysql is just SQL syntax
[16:59] <elbrus> what do you mean with "parsed"?
[16:59] <elbrus> during build?
[16:59] <nacc> elbrus: let me show you the contents
[17:01] <elbrus> it's not shell, it's perl
[17:02] <elbrus> see the first line
[17:02]  * elbrus doesn't read perl...
[17:02] <nacc> elbrus: http://paste.ubuntu.com/17755004/
[17:03] <nacc> elbrus: yes, install-dbconfig is perl, but not he file it's installing
[17:04] <nacc> (src/cats/make_mysql_tables)
[17:05] <elbrus> nacc: where does your /bin/sh point to?
[17:05] <nacc> elbrus: dash, the default in ubuntu, i think
[17:06] <nacc> yeah
[17:06]  * elbrus has to attent to a little girl, back in an hour or so
[17:06] <nacc> elbrus: np, thanks
[17:10] <nacc> elbrus: ah i figured it out
[17:10] <nacc> elbrus: the perl script snips out everything between the two herefile markers
[17:10] <nacc> this can't ever have worked...
[17:17] <nacc> elbrus: ah, and at some point, debian did manually sed this file
[17:29] <nacc> argggh
[17:29] <nacc> elbrus: rbasak: upstream bug, fixed in the latest upstream git
[17:29] <nacc> elbrus: also that datetime issue fixed upstream too :)
[17:36] <nemo> What's wrong with bugs.launchpad.net ?
[17:37] <sarnold> nemo: I understand a datacenter lost power
[17:38] <nemo> sarnold: huh. hosted in california or something?
[17:38] <nemo> but aight. can wait
[17:38] <sarnold> nemo: I think this one is in london
[17:43] <nemo> sarnold: huh. the power shutdowns and decent into mad max chaos weren't supposed to happen until 21:00 UTC
[17:44] <sarnold> nemo: funny thing about descents into mad chaos..
[17:59] <elbrus> nacc: great
[18:03] <Unit193> jbicha: Gotta say, not seen that one.  It only happen in MATE?
[18:05] <jbicha> Unit193: AFAIK, MATE's theme chooser is the only thing that cares about a gtk theme setting an icon theme
[18:05] <jbicha> if no icon theme is set, it won't even show up in the chooser
[18:06] <jbicha> and if an icon theme is set but that theme isn't available, it'll show up but with a warning
[18:06] <Unit193> Well, recommends are installed both in Debian and Ubuntu, so might make sense to be able to install one without the other, no?
[18:07] <nacc> Unit193: only if you use `apt`; `apt-get` doens't install recommends by default (iirc)
[18:07] <Unit193> nacc: False, both get recommends.
[18:07] <nacc> Unit193: ah you're right sorry, i chagned my local config :)
[18:08] <jbicha> I don't think it helps any thing to demote it from depends to recommends
[18:08] <Unit193> Hah, that's fine.  Only flavor that doesn't get recommends is Lubuntu.
[18:12] <Unit193> jbicha: It'd give the user the option to uninstall it if the user doesn't plan on using it, while still being able to use the GTK theme.  Was just asking as it doesn't actually require it to run, I've been using it for a while and never noticed a thing (or message.) :)
[18:12] <jbicha> so for MATE's benefit, we need to depend on some icon theme: probably numix or adwaita
[18:12] <jbicha> who uninstalls icon themes?
[18:43] <nacc> elbrus: re: zero date. Upstream bacula (as well as the version in debian/ubuntu, did this: http://www.bacula.org/git/cgit.cgi/bacula/commit/?h=Branch-7.4&id=36d647345df3c98a2cc1ad24af31e73aaff4a2e9)
[18:43] <nacc> why doesn't that work?
[18:43] <nacc> is it an implicit 0 now?
[18:59] <bdmurray> coreycb: There is a version of horizion already in xenial-proposed.  Should that be verified and release first?
[18:59] <coreycb> bdmurray, the version in the queue fixes a bug found in testing of the proposed package
[19:02] <coreycb> bdmurray, that doesn't answer your question but maybe it does indirectly
[19:02] <bdmurray> coreycb: it did, thanks
[19:02] <coreycb> bdmurray, ok, thanks
[19:04] <bdmurray> coreycb: oh hrmph, the bug (1594249)  didn't have any horizon tasks so didn't get commented on
[19:07] <coreycb> bdmurray, I see a comment from you.  it may be confusion between the source package being horizon and binary package being openstack-dashboard.
[19:08] <coreycb> bdmurray, thanks for the review
[19:09] <bdmurray> coreycb: launchpad tracks bugs about source packages not binary packages
[19:09] <bdmurray> coreycb: there's nothing here https://launchpad.net/ubuntu/+source/openstack-dashboard
[19:11] <coreycb> bdmurray, that is weird, I wonder why it's valid as a target for the bug
[19:11] <coreycb> bdmurray, awesome we have a bunch of bugs here too: https://bugs.launchpad.net/ubuntu/+source/openstack-dashboard
[19:12] <coreycb> bdmurray, alright let me retarget that
[19:12] <bdmurray> coreycb: I think it used to be a source package
[19:13] <coreycb> bdmurray, ok.  I'll chat with jamespage about it and see if we can clean things up.
[19:13] <bdmurray> https://launchpad.net/ubuntu/+source/openstack-dashboard/+publishinghistory
[19:13] <bdmurray> Oneiric!
[19:15] <coreycb> bdmurray, that's like half an alphabet ago :)
[19:22] <Unit193> ...Any chance 1562358 / 1582713 will get in through a SRU, or should I just try and backport it?
[19:22] <krytarik> jbicha: Honestly, I'd just follow what the Debian policy lays out there: https://www.debian.org/doc/debian-policy/ch-relationships.html#s-binarydeps
[19:32] <jbicha> krytarik: since recommends are not always installed and since it's broken on MATE if the icon theme isn't installed, I believe a depends is the right choice
[19:32] <seb128> jbicha, what package/what sort of breakage?
[19:33] <jbicha> seb128: https://github.com/numixproject/numix-gtk-theme/issues/488
[19:33] <jbicha> I'm just having numix-gtk-theme depend on numix-icon-theme
[19:34] <seb128> that feels wrong
[19:34] <jbicha> I could set IconTheme=Adwaita and depend on adwaita-icon-theme instead
[19:34] <seb128> well, a gtk theme doesn't depends on icons
[19:35] <seb128> recommends seems about righ
[19:35] <seb128> right
[19:35] <Unit193> Thanks, seb.
[19:35] <jbicha> they used to, MATE has a lot of old tech
[19:35] <roadmr> hey folks, where can I learn more about the process a package needs to go through to make it out of https://launchpad.net/ubuntu/xenial/+queue and into the archive?
[19:37] <jbicha> apt depends light-themes
[19:37] <jbicha> apt depends mate-themes
[19:37] <nacc> roadmr: https://wiki.ubuntu.com/ProposedMigration ?
[19:38] <seb128> jbicha, if you had numix-theme I would say add the depends
[19:38] <roadmr> nacc: awesome! reading, thanks!
[19:38] <seb128> but you have -gtk-theme
[19:38] <jbicha> but it's broken in MATE, did you see the screenshot?
[19:38] <nacc> roadmr: np, it links to several other pages, etc
[19:39] <seb128> jbicha, broken like missing from the theme selector?
[19:39] <seb128> or like not working if selected in a manual config?
[19:40] <Unit193> Sounds like a but in MATE to me.
[19:40] <jbicha> it looks bad in the theme selector
[19:40] <seb128> well, the theme selector is only one UI
[19:40] <seb128> if the gtk theme runtime is fine when manually selected then it's not a depends
[19:40] <seb128> recommends as "should be there"
[19:40] <seb128> are*
[19:42] <jbicha> ok, how about I just change IconTheme to Adwaita and not depend or recommend on any icon theme
[19:43] <jbicha> GTK3 depends on adwaita-icon-theme so it won't be broken
[19:43] <seb128> wfm
[19:45] <krytarik> jbicha: Well, you can still leave it set like that - Greybird does that too, for example.
[19:48] <jbicha> krytarik: that's a bug for MATE users then, I recommend it be patched in Ubuntu
[19:54] <elbrus> nacc: I don't know those internals of MySQL, but I guess you'll have to set a different default then?
[19:55] <nacc> elbrus: yeah, i'm not sure; your cacti change did work, so maybe i'll just do that, but it seems like it shouldn't have complained at all (aiui). I'll ask rbasak  :)
[19:57] <nacc> elbrus: reading the mysql pages about this, i think we just do what you did with cactui
[19:57] <nacc> *cacti
[20:36] <krytarik> jbicha: I see no reason to make a difference between Debian and Ubuntu there.
[20:37] <ubuntu__> Does anybody know where this driver is located 0 inteldrmfb its for /dev/fb0  cann't find it under lsmod so not a module and cann't find it in kallsyms so doesn't look like its a built in kernel function so where the heck is this driving program for the framebuffer?
[20:37] <nacc> ubuntu__: you've been doing this for days now. Please stop asking non-Ubuntu development questiosn here.
[20:38] <nacc> ubuntu__: ask in #ubuntu or #linux
[20:38] <Unit193> (##linux)
[20:38] <nacc> Unit193: thanks! :)
[20:38] <Unit193> Sure thing!
[20:48] <jbicha> krytarik: sure, Greybird should be packaged for Debian too (in Ubuntu, it's in shimmer-themes currently) :)
[20:49] <Unit193> In Ubuntu it's in the src:shimmer-themes and pkg:greybird-gtk-theme, in Debian it's in src/pkg:murrine-themes...
[20:51] <jbicha> Unit193: cool, thanks for the pointer
[20:52] <Unit193> jbicha: Sure, it's certainly not ideal, and I wouldn't recommend it in Debian as the last update was in June, and since then 3.20 has come out.  You have seen the Fedora patch that fixes Greybird for .20 I believe, though.  Done much testing on it?
[20:56] <jbicha> no I haven't tried the greybird patch yet
[20:58] <Unit193> Ah, OK.  Testing feedback could likely be useful if you were inclined, but that's more GNOME's stuff.
[21:05] <krytarik> jbicha: To be clear, I'm referring to your 'Numix → Adwaita' icon theme change in Debian and back in Ubuntu - imo should be Numix in both.
[21:08] <ubuntu__> well think i figured out what /proc/fb  comes from this line in kernel code  strcpy(info->fix.id, "inteldrmfb");
[21:09] <ubuntu__> all leave it at that kind of a dump thing to but into inteldrmfb how does that string help anything in finding the driver and code its not any name corrosponding to anything
[21:09] <jbicha> krytarik: I changed numix-gtk-theme in Debian new to just use Adwaita by default (for MATE) and not depend on any icon theme
[21:09] <jbicha> and it'll be synced to Ubuntu
[21:10] <ikonia> ubuntu__: you've been told - this channel is not for this discussion
[21:10] <ikonia> ubuntu__: please do not start up in here after you've been told not to use this channel
[21:10] <ubuntu__> but i will leave it at that i have found the built in driver code so its not an LKM  so lsmod won't list it  kallsyms has it but as   intelfb_create the real name for it . And this is where i stop thanks  goodbye
[21:22] <nacc> rbasak: elbrus: alright, bacula-director-mysql does install now (my last test build), but does require mysql-server to be fully installed & configured first (ordering isn't working if installed as part of the bacula install)
[21:22] <nacc> rbasak: should we pre-depend on mysql-server?
[21:22] <nacc> rbasak: in the bacula pacakge, that is
[21:27] <elbrus> nacc: the issue with MySQL (and other databases) is that it may not be running on the same host
[21:28] <elbrus> so if you add a (pre) depends, you are annoying admins that don't want the MySQL server on the same host
[21:28] <nacc> elbrus: oh right, you mentieond this, sorry!
[21:28] <nacc> elbrus: yep, and i think that's why the ubuntu wiki specifically mentions having the sql server alrady configured
[21:28] <elbrus> that is why in general packages that need MySQL have dependecies on the client, but not on the server
[21:28] <nacc> right, makes sense
[21:29] <nacc> elbrus: well, i think bacula with these 3 changes is in a much better state; continuing to debug the remaining bugs
[21:31] <elbrus> unfortunately, the Debian dependency system does not facilitate this
[21:31] <nacc> elbrus: yep, understood (or learning to understand.. :)
[21:31] <elbrus> one of the reasons why dbconfig-common exists...
[21:31] <elbrus> to make sure that packages don't need to invent this all
[21:31] <elbrus> again and again
[21:31] <elbrus> it isn't easy
[21:32] <nacc> yep, i am learning that! :)
[21:32] <elbrus> also dbconfig-common doesn't get it all correct
[21:32]  * elbrus tries to still fix some difficult bugs before the next Debian release
[21:34] <nacc> elbrus: thanks for all your help, again!
[21:35]  * elbrus is off to bed...
[23:12] <nacc> Pharaoh_Atem: can you take a look at LP: #1571436 ?
[23:12] <nacc> teward: --^ maybe you too
[23:14] <teward> nacc: that's a Universe package right?
[23:14] <teward> !info wordpress xenial
[23:14] <nacc> teward: yeah :)
[23:14] <nacc> teward: feel free to say no :)
[23:14] <teward> take a torch to it
[23:15] <teward> and burn the package with flame
[23:15] <teward> 4.4.2 is ancient
[23:15] <teward> at least according to WP
[23:15] <teward> riddled with many security holes
[23:15] <teward> 4.5.3 is latest
[23:15] <teward> and between 4.4.2 and 4.5.0 i think there were six security patch updates?
[23:15] <teward> foo i broke my fileshares
[23:16] <teward> nacc: probably an easy fix... if someone goes and looks at the example php-fpm configs in the nginx package currently
[23:16] <teward> or my blog for that matter
[23:16] <nacc> teward: yes, well, i'll probably sync it for yakkety
[23:16] <teward> nacc: http://dark-net.net/?p=125
[23:16] <nacc> teward: but our goal should be working packages, even if they are out of date (or so it seems)
[23:16] <nacc> teward: thanks, i'll refer to it
[23:17] <teward> nacc: true, but i'm not going to go poking every php package that happens to break OOTB when nginx isn't even listed in rdepends
[23:17] <teward> (for either suggest or recommends)
[23:17] <teward> nacc: fastcgi_pass unix:/run/php/php7.0-fpm.sock;  <-- socket for the conf file
[23:17] <nacc> teward: ack, hence you can say no :)
[23:20] <teward> nacc: i'm not touching it
[23:20] <teward> :P
[23:23] <teward> Pharaoh_Atem: ^ if you want to, you can refer to the nginx default conf currently, or the blog post I linked (http://dark-net.net/?p=125), it's the migration that broke it :)
[23:23] <teward> (from 5.x -> 7.0)