[06:26] good morning [09:06] any idea why when i press "ok" in the "Send this crash bug" i get no browser? [09:06] i think the crashes are not being reported [09:07] or are they just being sent to errors.u.c? === _salem is now known as salem_ [10:34] tsdgeos, they are sent to errors.u.c, and that happens silently [10:35] But you can enable sending them to Launchpad as described in https://wiki.ubuntu.com/Apport#Ubuntu_12.04_and_later [10:35] ok, so we don't even open the browser anymore? [10:35] interesting, i guess it's an old intall vs new install thing? [10:36] 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] I always have that commented out, so I say no :) [10:37] And the browser is not opened, because users do not have access to errors.u.c. [11:44] 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:44] bug 1639754 in snappy-hwe-snaps "Ethernet devices have higher metric than wlan or wwan ones" [Undecided,New] https://launchpad.net/bugs/1639754 [11:46] doko: x-x-i-libinput MIR bug modified === marcusto_ is now known as marcustomlinson === ilmaisin_ is now known as ilmaisin [12:10] xnox: hi! are you going to look at the openssl issue? [12:11] mdeslaur, check #ubuntu-installer [12:12] ah! [12:12] there cannot be a more obscure channel to discuss openssl 1.1 transition lol [12:17] yeah, I saw mention of it yesterday because my channel lighted up, but I couldn't find it again this morning :) === hikiko is now known as hikiko|ln === alan_g is now known as alan_g|lunch === salem_ is now known as _salem === marcust__ is now known as marcustomlinson === hikiko|ln is now known as hikiko [13:56] 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] I guess I'll build against libssl-dev for now instead of libssl1.0-dev Debian uses [14:15] 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? === alan_g|lunch is now known as alan_g === _salem is now known as salem_ [14:40] slangasek: sure, let's do that at the sprint [14:46] doko: how about at UOS? [14:48] meh, maybe [16:17] tjaalton: http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg please could you have a look at the khronos mismatch? [16:22] ahh, that was already done an hour ago [16:53] 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] rbasak: ping [16:58] nacc: o/ [16:59] rbasak: hey! have time for a quick sync up -- can do here or HO, whichever is easier [17:01] Sure [17:01] nacc: how about the regular team hangout? [17:03] rbasak: thanks! [17:03] * rbasak is there === daniel1 is now known as Odd_Bloke === _salem is now known as salem_ [17:28] 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] sigh [17:30] stupid botnet [18:15] smoser: so, the dsc branch: would you prefer importer/{debian,ubuntu}/dsc as branches or importer/dsc:{debian,ubuntu}/ as paths ? [18:16] i think consistent with pristine-tarball branch or tags... again, i guess they dont have to be a branch [18:18] 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] sure. so i think importer/{debian,ubuntu}/dsc for consistency dont you think ? [18:20] yeah, i think that's fine [18:20] fwiw, we're going to namespace the branch of lpusi/lupsd to importer/ [18:20] that way it's clear that the series branches are ubuntu/ and debian/ [18:20] while the importer-specific branches are in importer/ [18:51] tedg, in https://bileto.ubuntu.com/#/ticket/2129 i have retried zesty unity-shell thing it should build now with fixed boost. [18:51] (retried builds in the ppa, not sure what needs to be clicked on the bileto once those finish and fully publish) [18:53] xnox: bileto should pick it up [18:53] xnox: When the builds are complete [18:53] cool, then i will not check on it =) [18:56] 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] git-annex does this, for example. pristine-tar is effectively doing the same - one branch per project. [18:57] But really perhaps each project should parameterise the branch and use a subdirectory. [18:58] Anyway, I have No Strong Opinion. Just a thought. [18:58] rbasak: not sure that'd work with pristine-tar [18:58] rbasak: as in, i think we need a branch for each to gain the benefits, and to separate out the tarballs [18:58] It could work in theory I think, but of course that would require support in pristine-tar. [18:58] pristine-tar and gbp are rather inflexible [18:58] i've found [19:34] rbasak: smoser: so gbp does the `gbp ` 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] nacc: I'm not sure. I'm not really very familiar with this area. [19:35] Being able to run it out of the working tree is useful. [19:36] rbasak: yeah, and it seems like gbp, e.g., can't be run that way (direct from the git tree) [19:36] so maybe i'll just write asimple wrapper for now [19:36] OK [19:36] and we can figure out packaging later :) [19:36] nac, so.. gbp uses setup tools for entry points. [19:36] smoser: right, amongst other things, yeah [19:36] entry points dont indicate how subcommands are done. [19:36] i mean, gbp defines the subcommeands using an entry point [19:36] 'console_scripts' [19:37] i'm just trying to look at how other packages do it, gbp was the first i tried [19:37] git is a C program, so that doesn't help [19:37] i could probably wrap waht gbp does in direct python [19:37] smoser: i think that's your point? [19:40] well, no. [19:41] as far as i can see, git-buildpackage defines a single console_script (gbp.scripts.supercommand:supercommand) [19:41] yes [19:41] that just gest you the python launcher that goes in /usr/bin [19:41] yes [19:41] it doesnt indicate how you do subcommands [19:42] gbp.scripts.supercommand is *how* gbp does subcommands [19:42] specifically, gbp.scripts.supercommand.supercommand() [19:42] basically i'd take something similar and put that in usd [19:43] well, unless you have a reason, i'd suggest just using argparse. [19:44] https://docs.python.org/3/library/argparse.html#sub-commands [19:44] ah nice [19:44] i hadn't found that [19:44] no, i have no reason to do it other way [19:44] smoser: thanks! [19:45] yeah that looks way easier :) [19:47] 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] ie, gbp build -uS -uc [19:47] without "knowing" about uS and uC things can be tricky [19:48] ie, determining when that was bad arguments to you versus stuff to be passed on. [19:49] i think we're going to rely on -- [19:49] https://realpython.com/blog/python/comparing-python-command-line-parsing-libraries-argparse-docopt-click/ [19:49] it only is needed for usd buildpackage (note the rename) [19:50] just something i googled here... the other options he discusses there are not standard library, so i'd probably use argparse === salem_ is now known as _salem [21:47] 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] definitely not 1 [21:56] the entry point doesnt have to match anything really [21:56] oh. you want python -m usd ? to do something? [21:56] smoser: so i'm *not* using entrypoints, as you suggested to use argparse :) [21:57] smoser: so i've got that mostly working [21:57] but the base command, e.g, `usd` [21:57] argparse and entrypoints are not contraditory with each other [21:57] that name is obviously the name of a directroy already [21:57] i think i'm confused though. [21:58] lots of things would use both entry points and argparse [21:58] so we don't have entry points at all right [21:58] you dont have to. [21:59] ok [21:59] i'll read more [22:01] an entry p oint just makes an executable out of a string like 'usd=usd.cmd.main' [22:01] so that you get a /usr/bin/usd that does 'from usd import cmd; cmd.main()' [22:01] or the like. [22:02] 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 === ChanServ changed the topic of #ubuntu-devel to: Yakkety Yak (16.10) Released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise-yakkety | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | Patch Pilots: [22:29] has something changed in zesty? [22:29] mv: cannot stat '/<>/maas-2.1.1+bzr5542/debian/tmp/usr/lib/python*/*-packages/maasserver/static': No such file or directory [22:29] debian/rules:46: recipe for target 'override_dh_auto_install' failed [22:30] before the python*/*-packages would match to python3/dist-packages === _salem is now known as salem_ [22:48] smoser: got it [22:54] 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] 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] ah i think i found it [23:07] but there's not a way around the aliasing issue (usd being both the eventual executable name and the package name) === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem