[06:26] <cpaelzer> good morning
[09:06] <tsdgeos> any idea why when i press "ok" in the "Send this crash bug" i get no browser?
[09:06] <tsdgeos> i think the crashes are not being reported
[09:07] <tsdgeos> or are they just being sent to errors.u.c?
[10:34] <mitya57> tsdgeos, they are sent to errors.u.c, and that happens silently
[10:35] <mitya57> But you can enable sending them to Launchpad as described in https://wiki.ubuntu.com/Apport#Ubuntu_12.04_and_later
[10:35] <tsdgeos> ok, so we don't even open the browser anymore?
[10:35] <tsdgeos> interesting, i guess it's an old intall vs new install thing?
[10:36] <mitya57> For me when apport upgrades, I am prompted whether I want to keep my crashdb.conf or update it to the package version
[10:37] <mitya57> I always have that commented out, so I say no :)
[10:37] <mitya57> And the browser is not opened, because users do not have access to errors.u.c.
[11:44] <abeato> pitti, hi, I have opened bug #1639754, and would like to get your opinion. Ideally NM should manage all network connections if present, but not sure if that can be done easily when installed as a snap in Core. What would you think it is the best solution?
[11:46] <tjaalton> doko: x-x-i-libinput MIR bug modified
[12:10] <mdeslaur> xnox: hi! are you going to look at the openssl issue?
[12:11] <xnox> mdeslaur, check #ubuntu-installer
[12:12] <mdeslaur> ah!
[12:12] <xnox> there cannot be a more obscure channel to discuss openssl 1.1 transition lol
[12:17] <mdeslaur> yeah, I saw mention of it yesterday because my channel lighted up, but I couldn't find it again this morning :)
[13:56] <doko> infinity, pitti: please could you hold back the dpkg merge a bit? I'd like to do one more test rebuild for the Linaro toolchain first in Nov, and would like to avoid mixing this with any PIE changes
[13:57]  * Mirv thinks of asking about openssl but notices I'm not alone
[13:58] <Mirv> I guess I'll build against libssl-dev for now instead of libssl1.0-dev Debian uses
[14:15] <slangasek> doko, infinity, pitti: well, shouldn't we have a discussion about whether we want to enable PIE on the remaining archs, independent of Debian's decision and independent of the dpkg merge?
[14:40] <doko> slangasek: sure, let's do that at the sprint
[14:46] <slangasek> doko: how about at UOS?
[14:48] <doko> meh, maybe
[16:17] <doko> tjaalton: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please could you have a look at the khronos mismatch?
[16:22] <doko> ahh, that was already done an hour ago
[16:53] <nacc> cpaelzer: do you happen to know what the tags pointed to before such that I can reproduce? and if so, can you file a bug?
[16:55] <nacc> rbasak: ping
[16:58] <rbasak> nacc: o/
[16:59] <nacc> rbasak: hey! have time for a quick sync up -- can do here or HO, whichever is easier
[17:01] <rbasak> Sure
[17:01] <rbasak> nacc: how about the regular team hangout?
[17:03] <nacc> rbasak: thanks!
[17:03]  * rbasak is there
[17:28] <IemSPkZpALESHgmU> https://www.youtube.com/watch?v=3EsJLNGVJ7E & https://wikileaks.org/podesta-emails/emailid/15893, https://wikileaks.org/podesta-emails/emailid/23561, http://www.reuters.com/article/us-usa-election-foundation-idUSKBN12Z2SL & https://wikileaks.org/podesta-emails/emailid/3774 (ctrl+f qatar) - please don't let these be buried
[17:29] <dobey> sigh
[17:30] <dobey> stupid botnet
[18:15] <nacc> smoser: so, the dsc branch: would you prefer importer/{debian,ubuntu}/dsc as branches or importer/dsc:{debian,ubuntu}/ as paths ?
[18:16] <smoser> i think consistent with pristine-tarball branch or tags... again, i guess they dont have to be a branch
[18:18] <nacc> so right now we have improter/{debian,ubuntu}/pristine-tar, because they need to be branches and, in theory, there could be collisions
[18:19] <smoser> sure. so i think importer/{debian,ubuntu}/dsc for consistency dont you think ?
[18:20] <nacc> yeah, i think that's fine
[18:20] <nacc> fwiw, we're going to namespace the branch of lpusi/lupsd to importer/
[18:20] <nacc> that way it's clear that the series branches are ubuntu/ and debian/
[18:20] <nacc> while the importer-specific branches are in importer/
[18:51] <xnox> tedg, in https://bileto.ubuntu.com/#/ticket/2129 i have retried zesty unity-shell thing it should build now with fixed boost.
[18:51] <xnox> (retried builds in the ppa, not sure what needs to be clicked on the bileto once those finish and fully publish)
[18:53] <tedg> xnox: bileto should pick it up
[18:53] <tedg> xnox: When the builds are complete
[18:53] <xnox> cool, then i will not check on it =)
[18:56] <rbasak> smoser, nacc: is there any chance we'll want to store anything else? Because then instead of a branch per-thing-to-store, we may want to use a single branch and a flatfile arrangement for things-we-want-to-store instead.
[18:56] <rbasak> git-annex does this, for example. pristine-tar is effectively doing the same - one branch per project.
[18:57] <rbasak> But really perhaps each project should parameterise the branch and use a subdirectory.
[18:58] <rbasak> Anyway, I have No Strong Opinion. Just a thought.
[18:58] <nacc> rbasak: not sure that'd work with pristine-tar
[18:58] <nacc> rbasak: as in, i think we need a branch for each to gain the benefits, and to separate out the tarballs
[18:58] <rbasak> It could work in theory I think, but of course that would require support in pristine-tar.
[18:58] <nacc> pristine-tar and gbp are rather inflexible
[18:58] <nacc> i've found
[19:34] <nacc> rbasak: smoser: so gbp does the `gbp <subcommand>` stuff via setuptools, it seems. Do we want to go down that route (more reorganization). Or is it appropriate to do it manually ourselves (as we don't have a setup.py currently anyways) -- preferences?
[19:35] <rbasak> nacc: I'm not sure. I'm not really very familiar with this area.
[19:35] <rbasak> Being able to run it out of the working tree is useful.
[19:36] <nacc> rbasak: yeah, and it seems like gbp, e.g., can't be run that way (direct from the git tree)
[19:36] <nacc> so maybe i'll just write  asimple wrapper for now
[19:36] <rbasak> OK
[19:36] <nacc> and we can figure out packaging later :)
[19:36] <smoser> nac, so.. gbp uses setup tools for entry points.
[19:36] <nacc> smoser: right, amongst other things, yeah
[19:36] <smoser> entry points dont indicate how subcommands are done.
[19:36] <nacc> i mean, gbp defines the subcommeands using an entry point
[19:36] <nacc> 'console_scripts'
[19:37] <nacc> i'm just trying to look at how other packages do it, gbp was the first i tried
[19:37] <nacc> git is a C program, so that doesn't help
[19:37] <nacc> i could probably wrap waht gbp does in direct python
[19:37] <nacc> smoser: i think that's your point?
[19:40] <smoser> well, no.
[19:41] <smoser> as far as i can see, git-buildpackage defines a single console_script (gbp.scripts.supercommand:supercommand)
[19:41] <nacc> yes
[19:41] <smoser> that just gest you the python launcher that goes in /usr/bin
[19:41] <nacc> yes
[19:41] <smoser> it doesnt indicate how you do subcommands
[19:42] <nacc> gbp.scripts.supercommand is *how* gbp does subcommands
[19:42] <nacc> specifically, gbp.scripts.supercommand.supercommand()
[19:42] <nacc> basically i'd take something similar and put that in usd
[19:43] <smoser> well, unless you have a reason, i'd suggest just using argparse.
[19:44] <smoser> https://docs.python.org/3/library/argparse.html#sub-commands
[19:44] <nacc> ah nice
[19:44] <nacc> i hadn't found that
[19:44] <nacc> no, i have no reason to do it other way
[19:44] <nacc> smoser: thanks!
[19:45] <nacc> yeah that looks way easier :)
[19:47] <smoser> it has some hangups, largely my issues are when you're trying to pas through args that you dont really want to "know".  and dont' want to go the '--' route.
[19:47] <smoser> ie, gbp build -uS -uc
[19:47] <smoser> without "knowing" about uS and uC things can be tricky
[19:48] <smoser> ie, determining when that was bad arguments to you versus stuff to be passed on.
[19:49] <nacc> i think we're going to rely on --
[19:49] <smoser> https://realpython.com/blog/python/comparing-python-command-line-parsing-libraries-argparse-docopt-click/
[19:49] <nacc> it only is needed for usd buildpackage (note the rename)
[19:50] <smoser> just something i googled here... the other options he discusses there are not standard library, so i'd probably use argparse
[21:47] <nacc> smoser: pythonic question for you; given that we have a module namespace of usd, and i would like to use usd as the command base-name, would you recommend I 1) move usd/ to _usd/, 2) use a differnt command name (ubp?), 3) someting else?
[21:56] <smoser> definitely not 1
[21:56] <smoser> the entry point doesnt have to match anything really
[21:56] <smoser> oh. you want python -m usd ? to do something?
[21:56] <nacc> smoser: so i'm *not* using entrypoints, as you suggested to use argparse :)
[21:57] <nacc> smoser: so i've got that mostly working
[21:57] <nacc> but the base command, e.g, `usd`
[21:57] <smoser> argparse and entrypoints are not contraditory with each other
[21:57] <nacc> that name is obviously the name of a directroy already
[21:57] <smoser> i think i'm confused though.
[21:58] <smoser> lots of things would use both entry points and argparse
[21:58] <nacc> so we don't have entry points at all right
[21:58] <smoser> you dont have to.
[21:59] <nacc> ok
[21:59] <nacc> i'll read more
[22:01] <smoser> an entry p oint just makes an executable out of a string like 'usd=usd.cmd.main'
[22:01] <smoser> so that you get a /usr/bin/usd that does 'from usd import cmd; cmd.main()'
[22:01] <smoser> or the like.
[22:02] <smoser> then, what you do in that main is anything you want.  you can have one 'cmd' that does all the subcommands or separate them out
[22:29] <roaksoax> has something changed in zesty?
[22:29] <roaksoax> mv: cannot stat '/<<BUILDDIR>>/maas-2.1.1+bzr5542/debian/tmp/usr/lib/python*/*-packages/maasserver/static': No such file or directory
[22:29] <roaksoax> debian/rules:46: recipe for target 'override_dh_auto_install' failed
[22:30] <roaksoax> before the python*/*-packages would match to python3/dist-packages
[22:48] <nacc> smoser: got it
[22:54] <nacc> smoser: but entry points only help for installation, afaict? that is, i can switch to entry points, but you won't be able to use usd (there won't be one) in the repository itself
[23:06] <nacc> smoser: aiui, entry points provide a means to do `usd` if we 'install' the package. But given just a clone (as we have it now), there's no trivial way to do what you're suggesting?
[23:07] <nacc> ah i think i found it
[23:07] <nacc> but there's not a way around the aliasing issue (usd being both the eventual executable name and the package name)