[00:00] <nacc> rbasak: sure
[00:00]  * rbasak has a broken '' key. ime for a new lapop?
[00:00] <sarnold> your 't' key doesn't look so good either
[00:01] <rbasak> Like I said :-P
[00:03] <nacc> rbasak: LP: #1686859 filed
[00:09] <rbasak> Thanks!
[05:07] <ScottK> rbasak: Thanks.  Not sure if I should LOL or cry.
[07:58] <infinity> mvo: *poke*
[07:58] <infinity> mvo: I see a bug in those snapd uploads already.
[07:58] <mvo> infinity: meh
[07:58] <mvo> infinity: tell me more
[07:58] <infinity> mvo: Unless dpkg-gencontrol is smarter than I am...
[07:58] <infinity> mvo: Built-Using: ${Built-Using} ${misc:Built-Using}
[07:58] <infinity> mvo: That looks like it'll be missing a comma.
[07:59] <infinity> Oh.  Unless the way you create the first adds a trailing comma.
[08:00] <infinity> mvo: Nevermind.  It does.
[08:00] <infinity> mvo: I didn't read your make closely enough. :P
[08:00] <mvo> infinity: thanks for the careful check!
[08:00] <mvo> infinity: I tested this but was worried for a moment that I forgot something here
[08:02] <infinity> mvo: Though, that Built-Using might be a slight lie on Debian, where seccomp is disabled. But that's a less interesting issue.
[08:03] <infinity> mvo: You might want to set VENDOR_ARGS and BUILT_USING_PACKAGES in the same if/else/endif blocks to keep them matching, but indeed not relevant for the Ubuntu SRUs.
[08:10] <mvo> infinity: indeed, let me look at this. thank you!
[08:11] <infinity> mvo: Also wondering why you're making your own life difficult by having Ubuntu and everyone else differ on the snap-confine apparmor profile name?
[08:12] <infinity> mvo: I mean, sure, it was an Ubuntu oops that made us rename it, but... Divergence is gross.
[08:16] <mvo> infinity: good point, this debian packaging is mostly for our tests currently but there is really no need to diverge. something for morphis_ to check I think :)
[08:19] <mvo> infinity: I pushed a branch for the built-using, lets see if the debian tests are still happy
[08:43] <morphis_> mvo: tell me more about the different names of the apparmor profiles, you mean the one with .real and the one without?
[08:44] <mvo> morphis_: yeah, infinity pointed out that we do not need to diverge between ubuntu and debian
[08:46] <morphis_> wasn't really aware that we do that
[08:46] <morphis_> but have an item on my list to check how different we're in terms of packaging for debian and ubuntu
[09:07] <juliank> xnox: I know you wanted to play with systemctl is-active, but I did a further try with flock inside of the script, and that seems to work nicely (well, apart from it now requiring bash...): https://paste.ubuntu.com/24471873/
[09:07] <juliank> The script acquires the lock at the start, or waits an hour and if it can't acquire fails
[09:08] <juliank> For the long running processes, I close the fd so they don't leak into it (who knows what these start)
[09:17] <juliank> (It's somewhat unclear to me if there's a race condition somewhere if we just check if the other unit is active in ExecStartPre)
[10:54] <rbasak> xnox: are we planning on doing the openssl transition this cycle?
[10:57] <xnox> rbasak, sigh, that thing again.
[10:57] <xnox> rbasak, last time the argument was we don't want two ssl's in main; and at the time neither openssh or apache were ported. let's see what the current state of things is.
[10:57] <xnox> i think we have to do it before 18.04
[10:58] <xnox> i see that both of those are still 1.0
[10:59] <xnox> then again those things might never migrate =/
[11:02] <xnox> i hope there is like a new LTS release, cause 1.1 is not; and 1.0 is until end of 2019 only.
[11:06] <rbasak> xnox: thanks. To be clear, I'm not pushing. I was just asked whether to expect it so we can be ready to fix things.
[11:11] <xnox> rbasak, i'm inclined to say not this cycle.
[11:11] <xnox> mdeslaur, do you want openssl 1.1 yet? loads of key things are still not fixed....
[11:11] <mdeslaur> what I don't want is two openssls
[11:12] <mdeslaur> so if there's still stuff that doesn't work with 1.1, I suggest we wait
[11:12] <xnox> ... in main
[11:12] <xnox> or everywhere? because it's well openssl.
[11:12] <mdeslaur> I would suggest everywhere...last time we had 0.9.x in universe, and people kept using it and bugging us to fix it
[11:13] <xnox> OMG, there was openssl before 1.0? =/
[11:13]  * xnox wonders if i was alive or not.
[11:13] <mdeslaur> xnox: you were 4 at the time
[11:14] <mdeslaur> xnox: I also worry about the fact that 1.1 isn't an LTS release
[11:14] <mdeslaur> and 1.0 will be supported longer than 1.1 :P
[11:15] <rbasak> Yeah keeping one of a thing in main and another of the same thing in universe has never worked out well.
[11:15] <rbasak> Actually, that's perhaps not true with things like Python.
[11:16] <xnox> rbasak, will nova be ported to python3 and will we be able to have python2 in universe in 18.04?
[11:16] <mdeslaur> I definitely need 1.1 or higher for the LTS though
[11:16] <rbasak> No idea, sorry. I don't work on the openstack team.
[11:16] <mdeslaur> s/I/we/
[11:17] <xnox> true.
[11:17] <xnox> bzr, python2, gtk2, qt4, upstart, openssl1.0 -> oh i wish we can kill all of those
[11:57] <infinity> mdeslaur: It might be worth someone trying to get OpenSSL upstream to commit to their next LTS Very Soon.  They claim they're to do so every 4 years, and the last was 2014, so the time is nigh.
[11:58] <mdeslaur> infinity: yeah
[11:58] <infinity> mdeslaur: If I was a betting man, I'd guess 1.1.1 will be the next LTS, but no one really knows for sure.
[11:59] <mdeslaur> at least we'd know what to expect
[11:59] <infinity> mdeslaur: If it's 1.1.x or 1.2, I imagine we can roll with it, but if we decide to push 1.1 and then they say "surprise, 1.0.x is LTSing again!", we'll be in a world of hurt.
[12:00] <mdeslaur> definitely
[12:05] <infinity> xnox: As for gtk2 and qt4, I predict they'll die around the time gtk6 and qt8 are released. :P
[12:05] <infinity> xnox: So, right around the end of the UNIX epoch.
[12:05] <mdeslaur> it's quite nice that we dropped the gtk3 irc client in favour of the gtk2 irc client
[12:06] <infinity> People use graphical IRC clients?
[12:06] <infinity> Savages.
[12:06] <mdeslaur> infinity: and mice!
[12:06] <infinity> mdeslaur: Aren't mice exclusively used to control first person shooters?
[12:06] <mdeslaur> you can plug a mouse into a PS4?
[12:07] <infinity> You can play FPSes properly on a console?
[12:07] <ogra_> asciidoom!
[12:07] <infinity> (Though, yes, you can attach a mouse to a PS4 or Xbone, if you're so inclined)
[12:27] <Skuggen> I think some publishers asked the console makers for ways to prevent it, though, since it gives a competetive advantage :)
[15:11] <rfleming> Greetings smart Ubuntu people.
[15:13] <rfleming> I am in need of your help.  I am trying to find where gvfsd-fuse is called so I can change the option to allow_root
[15:29] <lamont> rbasak: sad things are sad
[15:29] <lamont> rbasak: also, wtf hahaha
[15:30] <rbasak> :)
[15:37] <dpb1> bdmurray: hey https://bugs.launchpad.net/cloud-init/+bug/1676908 for that bug, what gives the ACL for accept/decline on those nominate series tasks?
[15:39] <bdmurray> dpb1: Being able to upload the package or being a member of the poorly named ubuntu-release-nominators team.
[15:40] <dpb1> bdmurray: that's per-package-upload rights for cloud-init specifically, or 'ubuntu-release-nominators'
[15:40] <dpb1> bdmurray: ?
[15:41] <bdmurray> dpb1: being able to upload the package at all (as a core-dev I could accept the nominator) or being a member of that ubuntu-release-nominators team.
[15:41] <dpb1> k
[15:41] <dpb1> thx bdmurray
[15:42] <bdmurray> dpb1: The SRU tools automatically add / accept release tasks.
[15:42] <dpb1> bdmurray: sru developer permission probably required there, right?
[15:43] <bdmurray> dpb1: I don't know why you want to have the release tasks approved but if it is for the SRU process my point is that'll get handled automatically by the SRU team when they approve the SRU.
[15:44] <dpb1> bdmurray: ok, so it's fine to leave them unaccepted
[15:44] <dpb1> bdmurray: for prepping an sru
[15:44] <bdmurray> dpb1: Yes.
[15:45] <dpb1> great, thanks.
[17:45] <nacc> Odd_Bloke: also note that since gce-compute-image-packages isn't in our automtic import list, you're not racing the importer for it :)
[17:45] <nacc> Odd_Bloke: i think you got some feedback, did you update your MR?
[17:47] <Odd_Bloke> nacc: Yep, I did.
[17:47] <nacc> Odd_Bloke: ok, i can pull it in
[17:50] <Odd_Bloke> nacc: Thanks!
[17:50] <Odd_Bloke> Just in time for another import run, too, I think. :)
[17:51] <nacc> Odd_Bloke: oh i see, maybe rbasak already did it? https://git.launchpad.net/~usd-import-team/ubuntu/+source/gce-compute-image-packages/tag/?id=upload/20160930-0ubuntu6_14.04.0
[17:51] <Odd_Bloke> Oh, maybe.
[17:51] <nacc> ok, i'll run the import then and it should pick it up
[17:52] <Odd_Bloke> Oh, yes, he did.
[17:54] <nacc> Odd_Bloke: https://git.launchpad.net/~usd-import-team/ubuntu/+source/gce-compute-image-packages/log/?h=applied/ubuntu/trusty-devel
[17:54] <nacc> Odd_Bloke: and your tagged upload is now part of the history :)
[17:59] <Odd_Bloke> \o/
[17:59] <Odd_Bloke> Thanks!
[18:00] <nacc> Odd_Bloke: np
[18:01] <nacc> LocutusOfBorg: are you ok if i merge libguestfs?
[18:14] <jbicha> fossfreedom: why doesn't Budgie want tracker any more?
[18:15] <fossfreedom> it is a memory whore and people have been complaining of high CPU usage.
[18:17] <jbicha> because of how Ubuntu metapackages work, it will still be installed for users who upgrade
[18:19] <fossfreedom> hmm - will have to cover via the release notes then.
[18:20] <jbicha> see my commit msg for a few benefits to having tracker installed:
[18:20] <jbicha> https://bazaar.launchpad.net/~ubuntu-desktop/nautilus/ubuntu/revision/536
[18:21] <jbicha> the Ubuntu Desktop is undecided about whether to include tracker by default
[18:22] <jbicha> it would be helpful if we could measure how badly it abuses CPU and RAM
[18:23] <jbicha> tracker doesn't seem to be misbehaving on my computer
[18:24] <fossfreedom> various people have mentioned that the idle RAM dropped from 850MB to approx 600-650.  CPU not sure of - other than a couple of users who mentioned removal of tracker stopped the computer running at close 100% for several minutes.  I didnt though ask what they actually had on their computers and their setup
[18:26] <jbicha> I think it's using ~150MB RAM here according to gnome-system-monitor
[18:27] <fossfreedom> k - that makes sense then with the observation.
[18:33] <jbicha> I'm just used to some websites using more RAM than that :|
[18:36] <fossfreedom> it doesnt bother me given my setup.  I'm aware of our community though who are using lower end laptops and older computers though.  So perhaps more sensitive to stuff running
[18:38] <jbicha> I can understand gnome-documents not being in the default install because it's an unusual app but I think gnome-photos is decent and should get better in the future
[18:39] <fossfreedom> difficult to justify tracker for one app though.
[18:39] <fossfreedom> "if (g_strcmp0(g_getenv("XDG_CURRENT_DESKTOP"), "GNOME")" --> so those bits in the commit are specific to GNOME-Shell
[18:42] <jbicha> that commit dropped a patch that made nautilus work differently when run outside of "GNOME" (in Unity)
[18:42] <fossfreedom> ah
[18:51] <nacc> rbasak: fyi, i think src:supermin 4.1.3-1 also triggers the empty dir warning
[20:46] <LocutusOfBorg> nacc, I am, but infinity probably not
[20:46] <LocutusOfBorg> he don't want an ocaml transition
[20:47] <LocutusOfBorg> (he didn't want it last time I asked IIRC, fox yakkety or zesty)
[20:52] <LocutusOfBorg> I would start with an ocaml merge and then do libguestfs and ben
[20:52] <LocutusOfBorg> I can do it tomorrow if nobody objects
[20:53] <LocutusOfBorg> Laney, can I steal src:ben merge?
[20:56] <LocutusOfBorg> (uploaded on ppa:costamagnagianfranco/locutusofborg-ppa)
[22:36] <nacc> LocutusOfBorg: ack, i'll just fix it up with a rebuild then
[22:42] <nacc> rbasak: apparmor too
[22:43] <sarnold> ?
[22:43] <nacc> sarnold: empty directories in the srcpkg?
[22:43] <sarnold> nacc: do we do that?
[22:43] <nacc> sarnold: it confuses git -- 2.11.0-2ubuntu4 apparently has one
[22:43] <nacc> sarnold: rather than importing it, we're flagging it as an error until we have a workaround
[22:44] <nacc> sarnold: let me check locally
[22:45] <nacc> sarnold: http://paste.ubuntu.com/24475776/
[22:45] <nacc> sarnold: the output of `find . -type d -empty`
[22:46] <nacc> sarnold: since those are in the orig tarball, dpkg-buildpacakge will complain if we delete them via our importer's build
[22:46] <nacc> sarnold: but i think we still aren't storing them in our git representation of the (git-)tree
[22:46] <nacc> sarnold: nothing for you to worry about :)
[22:47] <sarnold> curious desktop/ is empty in my local checkout too
[22:47] <sarnold> as is namespace/
[22:47] <nacc> sarnold: yeah, so `pull-lp-source` etc. can do fine with it
[22:48] <nacc> sarnold: is your local checkout from a git repository?
[22:48] <sarnold> nacc: worse, bzr. :/
[22:48] <nacc> sarnold: ah ok -- bzr may be able to represent those changes, i'm not sure
[22:48] <nacc> sarnold: and we can do it with git, we just don't currently in the importer, so we've got a bug filed (for dgit as well)
[22:56] <slangasek> yes, bzr does represent empty dirs
[22:56] <nacc> slangasek: thanks for confirming