[01:08] <nacc> rbasak: so i think there is a case we're missing ... unless i misunderstood you (for the importer)
[01:08] <nacc> rbasak: if import_previous_version != tip_version, for debian
[01:08] <nacc> rbasak: we currently always orphan
[01:09] <nacc> rbasak: however, what about the case where debian didn't publish certain versions? so the lp publishing history does not include every version from the changelog
[01:11] <nacc> rbasak: e.g., https://launchpad.net/debian/+source/strongswan/4.5.2-1, where import_previous_version is 4.5.1-1 (d/changelog), but debian/sid is 4.5.0-1 (lp spph)
[01:11] <nacc> rbasak: it seems like we want the history to be as continuous as possible there, rather than a bunch of unconnected orphan chains?
[01:40] <nacc> rbasak: i was just thinking that maybe get_versions_from_treeish should ensure the versions it returns are published versions? it doesn't matter for hte above case, though, it seems like 4.5.1-1 should have been published
[03:33] <rstarmer> @stokachu: did you ever get a chance to try conjure-up on a KVM based system?
[03:36] <stokachu> rstarmer: not yet ive been sprinting all week
[03:37] <stokachu> was going to try it next week when I get back
[03:37] <rstarmer> sounds good. enjoy your sprints.  Can you point me to any docs on debugging the deployment process, I may have some time to try to figure out what's going on, and it'd be good to understand anyway.
[03:38] <rstarmer> or should I be looking to a pur juju mechanism for this instead (conjure-up just seems like a nice interface for managing all the pieces needed).
[03:39] <stokachu> rstarmer: mostly use juju status to see which services are in an error state, then juju ssh service/0 and check the logs in /var/log/juju
[03:39] <stokachu> yea we sit nicely on top of juju and lxd
[03:39] <rstarmer> cool, will look off into that direction.
[03:40] <stokachu> thanks, I'll definitely get this figured out I can see this being a nice benefit
[03:40] <rstarmer> thanks!
[04:11] <k2gremlin> Hey all quick and easy question. I want to create 2 new users to manage websites on a server. How can I lock them into their respective directories when they remote in? /var/www/webite1 and /var/www/website2
[07:58] <Javezim> Anyone know how to tell Unattended Upgrades to NOT update Samba in Ubuntu 14.04.4
[07:59] <andol> Javezim: Assuming a default setup you likely have a /etc/apt/apt.conf.d/50unattended-upgrades file? If you take a look in it you'll likely find examples on how to blacklist packages.
[08:01] <Javezim> Would commenting out this line stop all security updates?
[08:01] <Javezim> Unattended-Upgrade::Allowed-Origins {
[08:01] <Javezim>      "${distro_id}:${distro_codename}-security";
[08:08] <andol> Javezim: I imagine so, but if I were you I'd test and verify. Yet, in case you want to stop the automatic updates fully, wouldn't it make more sense to disable "APT::Periodic::Unattended-Upgrad" instead?
[08:08] <Javezim> Is that in the 10periodic file?
[08:10] <andol> Likely, but to be sure, just do a full grep under /etc/apt/apt.config.d/
[08:40] <rbasak> nacc: if that's common, then yes, maybe.
[08:40] <rbasak> nacc: and I like your solution.
[08:40] <rbasak> nacc: unconnected orphan chains was my intent, but I didn't think it'd be very common.
[08:41] <rbasak> nacc: can we keep our options open perhaps, and warn either way?
[12:32] <Nonymous> What is the default username password for login into openstack dashboard after installing using conjure-up
[13:49] <rbasak> stokachu: ^
[13:49] <rbasak> Though he's gone it seems.
[14:44] <Amadiro> Evening. I was trying to run `journalctl -b -1` to get the journal messages of the previous run on 16.04, but got the message "Specifying boot ID has no effect, no persistent journal was found". Any idea how to fix this?
[14:44] <Amadiro> I tried journalctl --merge, but that doesn't give any messages older than the current boot either.
[14:50] <ducasse> Amadiro: create /var/log/journal
[14:50] <Amadiro> ducasse, thanks, I'll give that a shot
[14:50] <Amadiro> ducasse, do you know what permissions/owner/group should be?
[14:51] <ducasse> Amadiro: drwxr-sr-x 3 root systemd-journal 4096 okt.  20  2015 /var/log/journal/
[14:54] <ducasse> Amadiro: AIUI journald will only write a persistent journal if that directory exists.
[14:56] <rbasak> nacc: on second thought, I think you're right. I'm not sure how we'd manually fix up Debian imported orphan chains anyway.
[14:56] <Amadiro> ducasse, thanks
[14:57] <rbasak> nacc: as long as the version number goes up, tying them together is the best we can do I think. Provided Launchpad doesn't import intermediary versions out-of-order later.
[14:57] <ducasse> Amadiro: you're welcome :)
[15:00] <stokachu> NonParity: admin/openstack
[15:00] <stokachu> sorry
[15:08] <nacc> rbasak: ack, i'll adjust our algorithm for that, thanks!
[15:08] <nacc> s/our/your/ :)
[16:14] <k2gremlin> Hello all, currently on 15.10. When I try to upgrade to 16.04 using "sudo do-release-upgrade" tells me No new release found.. help? :P
[16:23] <andol> k2gremlin: Seem to recall something about do-release-upgrade by default not moving to a new LTS until the first point release. You could try adding the -d option, doing "sudo do-release-upgrade -d", which I think will offer you 16.04.
[16:23] <{a}qu|l3s>  Visit Irc . netchat . cl By Ragnar
[16:23] <Isaboe>  Visit Irc . netchat . cl By Ragnar
[16:23] <alcaldesa>  Visit Irc . netchat . cl By Ragnar
[16:23] <maria37>  Visit Irc . netchat . cl By Ragnar
[16:23] <COLOMBO1>  Visit Irc . netchat . cl By Ragnar
[16:23] <Hugo35>  Visit Irc . netchat . cl By Ragnar
[16:23] <jpdp>  Visit Irc . netchat . cl By Ragnar
[16:23] <AnAiS_13_MaDriD>  Visit Irc . netchat . cl By Ragnar
[16:23] <lucia10>  Visit Irc . netchat . cl By Ragnar
[16:23] <a----->  Visit Irc . netchat . cl By Ragnar
[16:23] <DeMonia33Barna>  Visit Irc . netchat . cl By Ragnar
[16:23] <faro>  Visit Irc . netchat . cl By Ragnar
[16:23] <chatina>  Visit Irc . netchat . cl By Ragnar
[16:23] <Canaria35Guapa>  Visit Irc . netchat . cl By Ragnar
[16:23] <sakkara40>  Visit Irc . netchat . cl By Ragnar
[16:25] <andol> k2gremlin: I assume that your existing 15.10 install is fully up-to-date, and that you if nothing else have the most recent version of the ubuntu-release-upgrader-core package installed?
[16:26] <k2gremlin> andol, Correct. When I log into the 15.10 install, it tells me upgrade is available. New release '16.04 LTS' available.
[16:27] <andol> k2gremlin: Ok, did the -d option help then?
[16:29] <k2gremlin> andol, tried that as well. -d is just accept defaults right?
[16:31] <andol> No idea then.
[16:31] <k2gremlin> sudo apt-get update && sudo apt-get dist-upgrade shows 0 upgraded, 0 newly installed etc..
[16:31] <k2gremlin> so fully updated lol
[16:34] <k2gremlin> andol, any significant problem staying on 15.10 until I can find time to just re-install the two VM's I have running Ubuntu?
[16:36] <andol> k2gremlin: Well, you might want to do the upgrade within 2-3 months, because after that 15.10 won't recieve any more secure fixes.
[16:39] <k2gremlin> andol, Thanks
[16:59] <teward> nacc: around?
[17:01] <k2gremlin> andol, got it working. had to change my Prompt=lts to Prompt=normal since 15.10 was not an LTS..
[17:01] <k2gremlin> ill change it back to lts when its done
[17:02] <andol> k2gremlin: Ahh, never knew that that setting also affected the from-version. Good to know, thanks.
[17:12] <nacc> teward: pong
[17:12] <teward> nacc: Zend errors would be in PHP or the zend-framework packages, right?
[17:12] <teward> (I happened to be watching the bug announcements list, it has an apache2 issue that is Zend-related
[17:12] <teward> nacc: since you know the PHP side, i thought i'd poke
[17:12] <teward> :P
[17:12] <teward> see if you can confirm my thought
[17:13] <nacc> teward: it depends on which zend errors, zend engine itself is in PHP proper; zend-framework is MVC tooling
[17:13] <teward> nacc: https://bugs.launchpad.net/bugs/1578732 looks auto-generated
[17:13] <teward> but i doubt it's Apache
[17:14] <teward> stacktraces keep pointing to libphp7.0.so and other php7.0 library items so..
[17:14] <teward> .*shrugs*
[17:14]  * teward happened to watch bug announcements roll in heh
[17:16] <teward> nacc: but Zend is not part of Apache, the engine is in PHP, and zend-framework is separate
[17:16] <nacc> teward: ack
[17:16] <nacc> teward: that stacktrace is a php stakctrace
[17:16] <teward> nacc: so then I should repoint this to PHP then?
[17:17] <nacc> teward: what package is this (2.4.18-2ubuntu3) is that hte apche2 version?
[17:17] <teward> nacc: the errors.u.c tracker has the errors filed as Apache2
[17:17] <teward> because the errors were triggered as part of apache2's php module likely
[17:17] <teward> which is 'seen' as part of apache2
[17:17] <nacc> ah
[17:17] <teward> unlike php7.0-fpm which is separate
[17:18] <teward> nacc: and yes that's the apache2 version
[17:18] <teward> the bug is a PHP7.0 one, though, if that's a PHP stacktrace
[17:18] <nacc> teward: yep, i'd say so
[17:18] <nacc> teward: although fixing these kind of bugs willoften need testing of upstream php7.0 and then psosibly filing an upstream bug
[17:19] <teward> nacc: indeed.
[17:19] <teward> i'm just on triage duty right now ;)
[17:20] <teward> nacc: probably going to get yelled at, but that didn't read as an Apache error to me, when I saw "ZEND" :P
[17:20] <nacc> teward: sure, but i also don't see what the error itself is yet
[17:20] <nacc> php stack traces are awful
[17:20] <nacc> did something segfault?
[17:20] <teward> nacc: indeed, so it's just going to stay "New" until there's something we can test is my guess
[17:20] <nacc> teward: ack
[17:21] <teward> nacc: yeah it's reading an Apache crash
[17:21] <teward> but the stacktrace goes to PHP module
[17:21] <nacc> also i wonder if it's not showing the top, is there alimit to how many frames get copied? seems odd it would be precisely 2000
[17:21] <nacc> so the error message is missing
[17:22] <teward> nacc: scroll to the bottom of the errors.u.c page in the bug, and you should see incident uuid links
[17:22] <teward> nacc: nfc, that's a bdmurray question
[17:22] <teward> or errors.u.c people
[17:23] <nacc> teward: so is e.u.c where auto-filed bugs get their data put?
[17:23]  * nacc wasn't aware of it, just learning
[17:23] <teward> nacc: looks like Apache crash during Apache start, but the trace points at php7.0 based on the address signature
[17:23] <teward> nacc: ever see the "report error" button on the GUIs?
[17:23] <teward> when something happens on the system and it generates an error report (like a crash)?
[17:24] <nacc> teward: ack, i thought that was tied to apport-bug or whatever?
[17:24] <teward> nacc: well, you can file a bug about it, but 'report problem' or 'report error' or similar will send to errors.u.c
[17:24] <nacc> oh i see!
[17:24] <teward> it's how I track the number of nginx upgrade issues without bugs for each one
[17:24] <nacc> interesting
[17:24] <teward> you'd be surprised how many issues I debugged in Trusty -> Utopic with that xD
[17:24] <nacc> teward: and errors.u.c. has some smarts to combine them?
[17:24]  * teward shrugs
[17:24] <teward> nacc: AFAIK yes, but i think it does it based on traces
[17:25] <teward> so the stacktrace and address signatures, and I think there's some analysis to try and ID identical issues
[17:26] <nacc> teward: great, thanks for the info
[17:26] <teward> nacc: but if that's a PHP stack trace then it stands to reason the php plugin is doing something wrong, with zend engine
[17:26] <nacc> teward: i would agree
[17:26] <teward> nacc: https://wiki.ubuntu.com/ErrorTracker
[17:29] <nacc> rbasak: i'll add a sanity check that in this case and we're trying to fixup the history, there aren't any imports for versions in teh changelog between the last imported one and this one
[17:29] <nacc> rbasak: and if so, we'll orphan like we were going to
[21:02] <rbasak> nacc: I didn't think that fixing up the history was a special case though?
[21:21] <hallyn> what the heck?  all my libvirt tests seem to be passing.  i must have set the host up wrong
[21:25] <teward> hallyn: heheh
[22:00] <nacc> rbasak: err, sorry, not general fixup, but the above case of a discontinous publishing history
[22:00] <nacc> rbasak: which seems quite common, in lp
[22:08] <nacc> rbasak: and it happens in ubuntu too: https://launchpad.net/ubuntu/+source/strongswan/+publishinghistory?batch=75&memo=75&start=75, 5.1.1-0ubuntu6 never made it out of proposed
[22:14] <nacc> rbasak: hrm, another issue i just hit ... NMU uploads in debian, they seem to get deleted from the changelog on the next mainatiner upload?
[22:21] <mrjazzcat> Are there instructions to setup conjure-up on 14.04.4?  From jamespage ODS talk, he mentions that is has some hoops to jump through.  I'm ready to jump.
[22:23] <sarnold> looks like conjure-up is only packaged on xenial
[22:24] <mrjazzcat> sarnold: thx.  Pretty big hoop :)
[22:24] <sarnold> if you want to try it on trusty, maybe you could start with the 'backportpackage' tool in the ubuntu-dev-tools package
[22:24] <mrjazzcat> sarnold: ok, thx
[22:24] <sarnold> but it may make assumptions about what versions (or, more accurately, which features) exist in the tools it uses
[22:25] <sarnold> so the next hoops might be installing e.g. dev versions of juju or whatever..
[22:25] <mrjazzcat> sarnold: :)  maybe an alternative route, like the existing autopilot, then
[22:28] <nacc> rbasak: i guess it can happen even for non-NMU, e.g. 5.1.0-1 dropped 4.6.4-7, 4.6.4-7, 4.6.4-8 -- i think our publishing history should reflect what's in the changelog?
[22:28] <nacc> err, sorry -7, -8, -9
[22:45] <hallyn> teward: yeah but i was right :)  was testing the wrong version.  zounds.
[23:34] <jayjo> If I run 'sudo jupyterhub', does the privelege escalation apply to everything the jupyterhub process does in the future, or just the initial execution? Isn't a shell being launched as root and running the command juptyerhub, so further commands executed by jupyterhub are in the root shell, so should execute?
[23:36] <sarnold> it depends upon the program; it could be possible for jupyterhub to change privileges if it wants to
[23:38] <sarnold> it's a minor point, but I doubt sudo is starting a shell for this execution
[23:42] <JanC> only if jupyterhub is a shell script or if you specify the -s parameter
[23:44] <jayjo> jupyterhub is a python script
[23:49] <nacc> rbasak: on a more positive note, i got changelog attribution working, so the git authorship is identical