[06:44] <nix_> https://www.youtube.com/channel/UCyJtqKcPDtdGPzTjhdUIQ-Q/live <-- livestreaming linux setup
[07:06] <nix_> https://www.youtube.com/channel/UCyJtqKcPDtdGPzTjhdUIQ-Q/live <-- livestreaming linux setup
[07:56] <lordievader> Good morning
[08:54] <jamespage> coreycb, ddellav: picking up neutron* rc1's
[09:01] <rbasak> lamont: poke for the bind9 resolvconf fix please. Should I just add a delta to Ubuntu for now?
[09:01] <rbasak> powersj: is the server ISO oversize issue due to ghostscript still an issue? And if so, who is taking point on that?
[10:40] <jamespage> ddellav, coreycb: ceilometer underway
[10:43] <rbasak> Observation of the day: one can type "ip link" with the right hand only. Beats ifconfig :)
[11:07] <jamespage> ddellav, coreycb: ceilometer uploaded
[11:07] <jamespage> rbasak, does the git debian importer tool work ok with experiemtnal
[11:08] <jamespage> rbasak, for the openstack packages we oftern need to work against experimental; to-date we've done that directly in debian git repos, but that's about to change as pkg-openstack in debian is moving dev workflow to openstack project...
[11:42] <rbasak> jamespage: good question
[11:42] <rbasak> nacc: ^
[11:42]  * rbasak isn't sure
[11:42] <rbasak> I'm sure we can adapt it if needed
[11:44] <jamespage> coreycb, ddellav: also merged oslo.db and pymysql from debian
[11:54] <coreycb> jamespage, that sounds scary
[11:54] <coreycb> :)
[11:54] <coreycb> jamespage, I've been hitting issues with DFS and oslo.db pymysql
[11:55] <jamespage> coreycb, there where some breaks but that should now be resolved aiui
[11:57] <coreycb> jamespage, hopefully.  I had to downgrade pymysql to 0.7.6 and it fixed my issues.
[11:59] <jamespage> coreycb, lets hope so
[12:02] <jamespage> coreycb, ok lets block pymysql for now
[12:02] <jamespage> I'll request that in -proposed asap
[12:02] <jamespage> it mis-aligns us with upstream
[12:02] <coreycb> jamespage, might be a good idea
[12:02] <coreycb> +1
[12:05] <jamespage> coreycb, block and rejection requested
[12:09] <jamespage> coreycb, removed from proposed
[13:53] <lamont> rbasak: let me see what I can do right now
[14:06] <jamespage> coreycb, ddellav: either of you two doing rc1 for barbican?
[14:07] <coreycb> jamespage, nope
[14:07] <jamespage> ddellav, ?
[14:07] <smoser> nacc, so... silly me tried:
[14:08] <smoser>  git clone git://git.launchpad.net/~usd-import-team/ubuntu/+source/walinuxagent
[14:08] <smoser> usd-import --no-push -v --directory=walinuxagent walinuxagent
[14:09] <smoser> that fails because walinuxagent (--directory) does not have a git or gitwd dir.
[14:09] <smoser> this would seem to me to be the most useful/expected path for "update"
[14:09] <smoser> is that supportable ?
[14:10] <ddellav> jamespage yes i am
[14:11] <jamespage> ddellav, ok I won't
[14:11] <jamespage> lemme know and either coreycb or I can sponsor
[14:11] <ddellav> jamespage will do
[14:28] <powersj> rbasak, definitely still an issue. ISO is sitting at 812MB
[14:36] <ddellav> jamespage coreycb plz review lp:~ddellav/ubuntu/+source/barbican
[14:37] <jamespage> ddellav, on it
[14:46] <jamespage> ddellav, merged and uploaded - thanks!
[14:46] <jamespage> ddellav, do you have a list of outstanding rc's still?
[14:47] <ddellav> jamespage i've just been keeping track of what you guys are reporting and i grab whatever is on the corey's script output that is not been done yet
[14:47] <jamespage> ddellav, so what's left?
[14:47] <ddellav> jamespage this is what i have so far: http://paste.ubuntu.com/23203081/
[14:48] <ddellav> jamespage the debian sync's mostly but they have not been updated in debian yet. sahara, senlin, zaqar
[15:08] <Donutloop> Has the APT tool a API ?
[15:09] <Donutloop> That i can write a custom command. I want write a apt-security cve tool
[15:28] <cpaelzer> jamespage: hey FYI I uploaded a new DPDK today
[15:28] <jamespage> cpaelzer, aweomse - we should get ovs 2.6.0 this week as well
[15:28] <cpaelzer> jamespage: it should (tm) have no binary implications, well maybe due to fixing the last remaining lintian issue
[15:28] <patdk-wk> someone cloned me?
[15:28] <cpaelzer> which was rpath
[15:29] <cpaelzer> jamespage: so we might need a no change rebuild, but if you up ovs 2.6 anyway that would do it just as well
[15:29] <jamespage> cpaelzer, ack
[15:29] <cpaelzer> jamespage: symbols and all that were untouched, so it should be good - let me know if anything happens when you push latest ovs and I might be able to help
[15:29] <jamespage> okies
[15:44] <rbasak> powersj: https://launchpad.net/ubuntu/+source/samba
[15:45] <rbasak> https://wiki.ubuntu.com/Bugs/Tags
[15:59] <smoser> rbasak, i'm guessing you're about EOD
[15:59] <smoser> but do you have thoughts on my usd-import questions to nacc above ?
[16:02] <rbasak> smoser: seems reasonable that it should autocreate. I thought it did though.
[16:02] <rbasak> Could that be a recent regression?
[16:03] <smoser> rbasak, the difference is i dont have a gitwd and git dir
[16:03] <smoser> i have a .git
[16:03] <smoser> i wanted to point it at a "normal" git clone
[16:03] <rbasak> Ah, I see.
[16:04] <rbasak> That's a bit trickier I think. Your particular case seems reasonable, but we're assuming you have all the remote tracking branches have the right names and tag names etc.
[16:04] <rbasak> I think?
[16:05] <smoser> probably, but you'd think that i do...
[16:05] <smoser> i cloned a branch that was created by  usd-import
[16:05] <smoser> oh.... but i would need the branches locally too i guess.
[16:12] <NOVAtechi> hello all.
[16:13] <NOVAtechi> with mdadm is the metadata the new way of showing which raid level and how many devices?
[16:13] <NOVAtechi> ARRAY /dev/md/0  metadata=1.2 UUID=149b996f:ec0e9fd3:056621ee:ab58ac2b name=zeus.0
[16:23] <allen> I'm trying to sftp from my local macbook to the remote server
[16:24] <allen> i was able to retrive files, no problem, but when uploading, it says "Entering dirname/" and then takes me back to the sftp> prompt
[16:24] <allen> no indication of a succesfful upload, no status bar for each individual files. What am I diong wrong?
[16:24] <nacc> smoser: yeah, it's on my roadmap to not rely on xgit
[16:24] <nacc> smoser: but for now, you need an xgit-style local setup
[16:25] <nacc> smoser: alternatively, use the importer itself to re-import with --no-clean, and it will setup a local directory (specified or in /tmp) with the appropriate configuration
[16:26] <nacc> rbasak: jamespage: it knows about experimental, yes (well, it knows about anything published acc'g to launchpad)
[16:26] <rbasak> nacc: I wonder how well it would work with Ubuntu's packaging not derived from Debian though?
[16:26] <rbasak> I haven't thought it through.
[16:27] <nacc> rbasak: i guess i'd need more context, i was purely asnwering the question of experimental :)
[16:28] <smoser> nacc, right. just want to re-use that tree
[16:28] <smoser> i dont have the original 'directory'
[16:28] <smoser> do i need it? or will usd-import dtrt if ij ust run it again
[16:28] <rbasak> powersj: https://bugs.launchpad.net/ubuntu/+source/mysql-5.7/+bug/1579708
[16:29] <nacc> smoser: it will dtrt -- but let me clarify if i know what you're asking :)
[16:29] <smoser> i jsut dont want it to re-do everything
[16:31] <nacc> smoser: if you run `usd-import -d <dir> pkgname -o usd-import-team`, the importer should set up a remote pointing to usd-import-team's git repository for that pkg. It will check what the status of all the remote branches are (version/publish date) and then it will compare against lp's source pkg publishing history. Anything new it needs, it will `pull-{lp,debian}-source`, and import. Then it will push
[16:31] <nacc> (unless --no-push) is given. Preusming usd-import-team's tree is current, all of that would be skipped, and you'd just hav ea directory with git/ gitwd/ (so suitable for xgit) that has a remote with all the appropriate references you need. You'd just need to `git checkout -b <remote branch>` to do local work
[16:31] <nacc> smoser: that is the intent, at least :)
[16:32] <smoser> ok.
[16:32] <rbasak> Odd_Bloke: do you know about bug 1624596? Found during triaging. Not sure why ~ubuntu-server still has a subscription.
[16:34] <smoser> rbasak, i will / am looking at that.
[16:48] <rbasak> $ rmadison taglibs-standard jakarta-taglibs-standard
[16:48] <rbasak>  taglibs-standard         | 1.2.5-2                | yakkety/universe | source
[16:48] <rbasak> hcdist yakkety-proposed apt-cache showsrc taglibs-standard
[16:48] <nacc> jamespage: if you want to give me an example src package, i can do a side-import of it for you to look at
[16:49] <rbasak> hcdist yakkety-proposed apt-cache showsrc taglibs-standard
[16:49] <rbasak> Package-List:
[16:49] <rbasak>  libtaglibs-standard-impl-java deb java optional arch=all
[16:49] <rbasak>  libtaglibs-standard-jstlel-java deb java optional arch=all
[16:49] <rbasak>  libtaglibs-standard-spec-java deb java optional arch=all
[16:49] <rbasak> rmadison libtaglibs-standard-impl-java libtaglibs-standard-jstlel-java libtaglibs-standard-spec-java
[16:49] <rbasak>  libtaglibs-standard-impl-java | 1.2.5-2 | yakkety/universe | all
[16:49] <rbasak>  libtaglibs-standard-jstlel-java | 1.2.5-2 | yakkety/universe | all
[16:49] <rbasak>  libtaglibs-standard-spec-java   | 1.2.5-2 | yakkety/universe | all
[16:49] <rbasak> cpaelzer: ^
[17:21] <nacc> rbasak: ok, hit an interesting case -- i was testing if my pygit2 conversion was good (leading to the same git trees as the old importer). Tested with at. On yakkety, dpkg-parsechangelog fails on the first debian ssphr, correctly. But in 16.04 it doesn't (so it successfully imported in the past...). I'm on yakkety now. Would you say just run in 16.04 for now? Or should I fix up at like I have for apt?
[17:21] <nacc> I'm guessing that dpkg-parsechangelog has gotten stricter/more correct in 16.10
[17:25] <nacc> oh, it looks like dpkg-dev moved from programs to perl modules
[17:25] <smoser> nacc, whati'd i do wrong
[17:25] <smoser>  http://paste.ubuntu.com/23203695/
[17:26] <nacc> smoser: this would appear to be wrong: "WARNING:root:No objects found in remote git://smoser@git.launchpad.net/~usd-import-team/ubuntu/+source/walinuxagent" (not your fault). let me debug quickly if i can
[17:26] <smoser> ah.
[17:27] <smoser> yeah, smoser@
[17:27] <smoser> no. that should be ok. the smoser@ shoudlnt mbetter
[17:27] <nacc> right
[17:27] <nacc> sorry, what i menat, was thats tatement is wrong
[17:27] <nacc> *that statement
[17:27] <nacc> as it has objects
[17:27] <smoser> right.
[17:28] <nacc> give me a few minutes to dig
[17:30] <nacc> smoser: heh, i blame you
[17:30] <nacc> smoser: ok, your git / git+ssh change
[17:31] <nacc> smoser: so the problem is, git+ssh allows user@
[17:31] <smoser> yep
[17:31] <nacc> smoser: but git doesn't
[17:31] <smoser> yeah, i was just going to suggest you stop taking changes from smoser
[17:31] <nacc> heh
[17:31] <nacc> i think i can fix it quickly
[17:33] <smoser> nacc, http://paste.ubuntu.com/23203720/
[17:33] <nacc> yeah basically
[17:34] <smoser> hm..
[17:34] <smoser> i still get the no objects warning though
[17:34] <smoser> nah. it was dirty dir. never mind.
[17:34] <nacc> well, my version works :) http://paste.ubuntu.com/23203725/
[17:37] <nacc> smoser: should be fixed in git
[17:38] <nacc> smoser: nice, the pickup did seem to work, too, it imported 3 new versions since last import (i assume that's right, i've not actually checked)
[17:39] <smoser> nacc, horay!
[17:39] <smoser> push?
[17:45] <smoser> nacc, the vast majority of the 2 minutes 26 seconds for me was dist_sinfo.launchpad_versions_published_after
[17:45] <nacc> smoser: i ran with --no-push
[17:45] <nacc> smoser: yeah, it's a slow algorithm for correctness
[17:46] <nacc> smoser: we can probably optimize it at some point, but it's a lot of launchpad interactions (as it needs to be) and then looping to get to the point in the history we need to be
[17:46] <smoser> yeah.
[17:47] <nacc> tbh, most of the code is naive in favor of correctness/ease of understanding :)
[17:47] <smoser> sure.
[17:47] <smoser> so i'm running it without --no-push now
[17:48] <smoser> but to make sure i understand this...
[17:48] <smoser> you could in your tree just add the remote and push
[17:48] <smoser> right?
[17:49] <nacc> smoser: yep, although with your change, i'd need to change git/config to use git+ssh and my username
[17:49] <smoser> yeah.
[17:49] <nacc> smoser: i think i adjusted the code already to change that on each run
[17:49] <smoser> (add the remote)
[17:49] <nacc> so you could do --no-push -d ... then immediately do the same without --no-push and it should just work
[17:50] <nacc> this in the pygit2 version, though
[17:50] <nacc> so will be in master hopefully soon :)
[17:50] <smoser> nacc, speed is not a big deal. as the goal is this is running automated and already ran when i looked to pull
[17:51] <nacc> smoser: yep, exactly
[17:51] <nacc> smoser: yeah, speed is only important for the part that is currenty slow (in my experience), which is loading an existing large repo
[17:51] <nacc> smoser: the pygit2 conversion fixes that, afaict
[17:52] <nacc> smoser: then the cronjob should be close to bound by the number of publishes since last run
[18:48] <blizzow> So I went to do a dist-upgrade on a couple of servers, and I find mysql-common is installed on there...I do an apt-get remove mysql-common and only see the following packages getting removed:
[18:48] <blizzow> libdbd-mysql-perl libmysqlclient20 mysql-common
[18:49] <blizzow> Is mysql-common part of the base install somehow now?
[18:49] <cliluw> Is there a way to let a user have superuser privileges without letting them impersonate root?
[18:49] <blizzow> Or is apt not showing me what actually depends on mysql-common?
[18:49] <lunaphyte> cliluw: well, define "have superuser privileges", but generally, that's what sudo is for.
[18:50] <cliluw> lunaphyte: We want to let users do "sudo" but not let them do "sudo su" or "sudo -i".
[18:50] <lunaphyte> sadly, it's been bastardized by ignorant cargo cult admins to mean "run everything with sudo when you are the admin anyway"
[18:51] <blizzow> cliluw: then you need to enumerate a list of commands that sudo can run.
[18:51] <lunaphyte> cliluw: what does "do sudo" mean though?  running sudo by itself is not of value
[18:52] <lunaphyte> your goal should never be to "let users run sudo".  instead, your goal should be to let users run specific commands, or do specific things, which can then be accomodated by way of sudo
[18:53] <blizzow> In your sudo config instead of ALL:ALL, you need to have ALL:/commandsyouwanttolettheuserrun.
[18:53] <sarnold> cliluw: sudo is configurable, almost too configurable; it's easy enough to give someone a specific command, but be aware that if you give them e.g. sudo edit permission then they can just use vim's ! feature to execute a shell.. most programs let people execute shells or arbitrary commands somehow, so be careful if you try to use this to lmiit what people can do
[18:53] <lunaphyte> blizzow: i don't understand what you're asking.  i don't recall mysql-common being present in a base install, but either way, what difference does it make [aside from crappy bloat]?  if you need libdbd-mysql-perl, then the other two come with it.  if not, remove them.
[18:54] <blizzow> lunaphyte: I removed it, I was just curious if mysql-common creeped in as bloat like lxc containers did.
[18:55] <lunaphyte> i hope not, but sadly, it wouldn't be a huge surprise.
[18:55] <lunaphyte> it's become pretty ridiculous the number of packages i now remove from a "minimal" install in order to make it *actually* minimal
[18:55] <lunaphyte> and don't get me started on dependency nonsense :)
[18:56] <blizzow> It's been brutal lately.
[18:56] <blizzow> !
[18:56] <cliluw> blizzow: You have a good point about using whitelisting instead of blacklisting.
[18:57] <blizzow> Guess it's time to set up my own seed server and start doing installs that way again.
[18:58] <blizzow> cliluw: check this out... http://askubuntu.com/questions/500679/block-a-command-from-sudo-user
[18:58] <blizzow> You can blacklist su, but the article says it's pretty ineffective.
[18:59] <rattking> you can run 'aptitude why package' to see what pulled the package in.. assuming you dont consider apitude bloat :)
[19:00] <sarnold> apt-get purge should give a similar reason, no? :)
[19:00] <lunaphyte> indeed.  using sudo in an attempt to blacklist commands is a fool's errand
[19:00] <rattking> by seeing what it wants to take with it? yeah I suppose it would
[19:00] <lunaphyte> rattking: yes, i consider aptitude to be bloat
[19:01] <lunaphyte> i can't remember the last time i wished i hadn't purged aptitude
[19:01] <blizzow> ratking: thanks!  Just what I was looking for. Ansible requires aptitude, so I'm forced to use it.
[19:01] <lunaphyte> ansible requires aptitude?  blech
[19:02] <lunaphyte> actually requires it?  or artificially requires it by way of absurd package dependencies?
[19:02] <blizzow> lunaphyte: yep.
[19:02] <blizzow> actually requires it.  also requires python-simplejson
[19:03] <lunaphyte> that's rather unfortunate
[19:03] <lunaphyte> i can't image it genuinely needs aptitude, and couldn't do everything needed via any number of other mechanisms
[19:06] <blizzow> Unfortunately it does.  Not exactly my favorite management tool, but otterwise, I'm probably forced to use puppet or chef (super gross).
[19:06] <lunaphyte> you consider chef to be less desirable than ansible?
[19:08] <blizzow> yeah, I do.  At least ansible runs over ssh, doesn't have an agent running and checking in all the time, and more importantly is not written in ruby/erlang.
[19:08] <lunaphyte> hmm, interesting.
[19:08] <blizzow> Talk about bloat just to get a current ruby/erlang install.
[19:08] <lunaphyte> although erlang isn't so bad
[19:08] <lunaphyte> [in the grand scheme of things]
[19:08] <lunaphyte> would you take chef over puppet?
[19:09] <blizzow> Last erlang dealings I had was installing couchdb and having to install particular boost libraries to get the right version of erlang.  Don't even get me started on the hipster ruby let's build our own packaging system outside of established methods shitshow.
[19:10] <lunaphyte> well yeah, ruby for sure
[19:10] <sarnold> blizzow: they -all- succumb to that :(
[19:11] <sarnold> blizzow: pip, gems, hell even lua has luarocks
[19:11] <blizzow> I'm really not familiar enough with puppet to give it a nod over chef.
[19:11]  * sarnold glares at cpan
[19:12] <blizzow> sarnold: I know, and it's a total pain in the c*ck to keep my ops people from installing weird shit in new and interesting ways.
[19:12] <lunaphyte> that mentality has become progressively worse with each iteration of the interpreted language of the month club.  first with perl and cpan, which was tolerable but frustrating, then on to php with pear, and after that pythong and its eggs, then ruby and its gems, and most recently lua and its rocks :(
[19:13] <blizzow> oh, I see the go headache already beginning.
[19:13] <sarnold> well underway :(
[19:13]  * nacc wonders if rants could go to #ubuntu-offtopic :)
[19:13] <lunaphyte> then you add cargo cult admins who manage systems by effectively doing things like "curl 'http://www.somedumbblog/tld/' | sudo bash", and it's a surprise as many systems actually function at all
[19:14] <lunaphyte> yeah, fair enough.
[19:14] <lunaphyte> this soapbox was starting to wobble anyway :)
[20:02] <ThiagoCMC> hey guys, how to disable cloud-init network capabilities for deermined vNICs only?
[20:19] <PryMar56> lunaphyte, how Cal Tech & Feynman'esque
[20:19] <PryMar56> reminds me of the Commencement speech in May '74 by Feynman
[20:21] <lunaphyte> which was that?
[20:22] <PryMar56> lunaphyte, the cross compare of script languages and repo from 12:15
[20:22] <PryMar56> 1 hour ago
[20:23] <lunaphyte> ah
[20:40] <ThiagoCMC> Apparently, Cloud Init Network capabilities is "all or nothing", I have instances with 3 interfaces and it is runnign DHCP against all of it! But I only need it to configure the first vNIC, but, how???
[22:23] <k2gremlin> Anyone have a DNS blip recently using 8.8.8.8? Had some really weird dns issues for about 3-4 minutes. Cleared up when I changed to 8.8.4.4
[22:41] <Fiki> k2gremlin, I generally don't like google dns anyway, far too slow compared to my local or even other public dns out there
[22:46] <lunaphyte> who in their right mind would ever run a server and use a third party dns service anyway?
[23:00] <k2gremlin> lunaphyte, Sorry, Just happened to be in this channel when problem came up on my Win10 PC at home.