[06:28] <cpaelzer> good morning
[10:44] <Mez_> Hi all, I've found an issue in the Ubuntu Installer (where it shows the map screen) - anyone know which package that is ?
[10:44] <Mez_> (I may be able to "fix" the issue myself)
[10:45] <cjwatson> Mez_: ubiquity
[10:45] <Mez_> cjwatson: where does it pull city names from ?
[10:45] <Mez_> (I vaguely remember that you work on the installer)
[10:47] <cjwatson> Mez_: I can't remember whether it's tzdata or tzsetup (both exist, the latter is a d-i component) - one of those two
[10:47] <cjwatson> Mez_: I used to, moved to working on Launchpad a couple of years ago
[10:52] <Mez_> Ah, fair enough.  I just don't like the installer mocking the local accent :)
[10:53] <cjwatson> huh?
[10:54] <cjwatson> nobody is mocking anything.
[10:54] <Mez_> one sec :)
[10:54] <Mez_> (and that is said jokingly, btw)
[10:57] <Mez_> http://imgur.com/Wxfk2jQ
[10:58] <cjwatson> I think the autocompletion stuff comes from a web service ...
[10:59] <cjwatson> geoname-lookup.ubuntu.com
[11:00] <cjwatson> which is https://launchpad.net/ubuntu-geonames
[11:00] <Mez_> And the question is, where is that maintained?
[11:01] <cjwatson> did you type that before or after I pasted the Launchpad link?
[11:02] <Mez_> before :)
[11:02] <cjwatson> so the string "Birmin'gxam" does appear in current geonames data (I grabbed http://download.geonames.org/export/dump/GB.zip) - I think that this may be a matter of choosing incorrect localisation
[11:03] <cjwatson> because e.g. https://ug.wikipedia.org/wiki/Birmin%27gxam
[11:04] <cjwatson> curl 'http://geoname-lookup.ubuntu.com/?query=Birmin&release=16.04' | jq   reproduces without having to go through the installer
[11:05] <cjwatson> somebody gets to work out how the geonames importer works and whether this is just a matter of refreshing from upstream data or whether it needs a fix to the importer
[11:06] <cjwatson> anyway, this is definitely all in the ubuntu-geonames project
[11:08] <cpaelzer> usually SRU policy implies a change to be upstream in the latest release before SRUing - what if latest release has way more complex changes in other packages to no more trigger it?
[11:09] <cpaelzer> it makes no sense to add a fix to zesty it doesn't need, but it certainly does to fix it in Xenial
[11:09] <cjwatson> that would be an exception to discuss with the SRU team, probably in the context of a patch
[11:09] <cpaelzer> reasonable, I'll add details to the SRU template
[11:09] <cpaelzer> thanks cjwatson
[12:11] <caribou> hmm, not a good day for the dev release on my laptop : systemd-resolvd is going haywire on me, I'm loosing some keybindings
[15:00] <rbasak> !dmb-ping
[15:11] <sil2100> !dmb-ping
[15:11] <sil2100> (re-pinging)
[15:30] <mitya57> Mirv, hi, do you have any pending changes for qtbase 16.04 / 16.10 SRUs? Or a branch in Git or Bzr or somewhere?
[15:31] <mitya57> (I want to SRU LP: #1380702)
[15:33] <nacc> mitya57: there are tasks open, and someone needs to follow: https://wiki.ubuntu.com/StableReleaseUpdates
[16:47] <slangasek> ogra_: the TB meeting is on the UES team calendar... I don't know why this event always gets hit, but it seems to be magical from the phone's POV because people always wind up editing it via phone sync
[17:46] <ogra_> slangasek, is it still happening ? or did my wiping fix it ?
[17:46] <slangasek> ogra_: I haven't seen any overwrite from you lately, but I've seen several more overwrites from other users
[17:47] <ogra_> slangasek, i just remembered that i got an invite notification once ... and was actually wondering about why the TB invites me ...
[17:47] <slangasek> ogra_: it wasn't the TB, it was somebody editing the event and inviting eeeeeverybody :)
[17:47]  * ogra_ goes to check evolution, i might still have it somewhere
[17:48] <ogra_> ah
[17:48] <ogra_> :)
[18:05] <mterry> jdstrand: I'm looking at the guest session apparmor profile -- it's denying connect/w access to /run/snapd.socket -- I tried adding a "/run/snapd.socket rw," rule to the lightdm guest profile, but that didn't help -- I thought rw would be enough?
[18:07] <mterry> I can share the apparmor denial message if that would help
[18:09] <sarnold> mterry: jdstrand is out for the week
[18:10] <mterry> sarnold: ah!  thx
[18:10] <sarnold> mterry: do we -want- the guest session to be talking to snapd? to what end? I certainly wouldn't want the guest account to be starting up dhcp servers or web servers or bgp daemons or whtaever it is that is snapped
[18:25] <mterry> sarnold: my goal was to let it get a list of installed snaps and run them
[18:26] <mterry> sarnold: web servers would be snap daemons, not user-run snaps right?
[18:26] <mterry> sarnold: my head space was letting guest run Calculator and such
[18:28] <sarnold> mterry: hrm. even calculator seems like a bit much, unless snapd grows knowledge how to stack apparmor profiles when launching, based on the confinement of the calling process.
[18:29] <mterry> sarnold: hmm, OK.  I won't bother continuing this then  :P
[18:30] <dobey> that does seem like a problem we need to solve, but doesn't seem like it should be prioritized at the moment
[18:30] <sarnold> mterry: well, if we ever face the day of only having browsers via snaps, we'll probably need answers to this :/
[18:30] <dobey> but i don't think we want the genral ability to read/write to snapd.socket
[18:32] <dobey> should be ok for unity8 and a couple other system things to do that perhaps, but general access seems bad
[18:33] <mterry> sarnold: agreed that was my thinking
[18:33] <mterry> sarnold: but if we have a technical block on stacking profiles, no need for it now
[19:42] <mitya57> Mirv, FWIW I am building the packages in silo 2569, and am going to copy to archive tomorrow if they build fine (unless you have any objections).
[19:59] <nacc> slangasek: i've been bothered by an annoying ubuntu-component consequence for a long time; `apt-get changelog qemu` fails, because src:qemu is in main and the binary qemu is in universe, so it tries to download a changelog from the universe component, but they are stored by src packages. I started looking at the apt source (very rusty at C++, I admit), and I see how it could be fixed (at least in terms
[19:59] <nacc> of what code needs to change), but it also seems like apt doesn't store enough information to easily solve it. Is this just something everyone else doesn't care about?
[20:00] <slangasek> nacc: if I had hit this problem, I had not realized it was a component issue.  I would argue that it shouldn't be necessary to know the component to get the changelog; what do you think about flattening it (with backwards-compatibility)?
[20:03] <nacc> slangasek: yeah, it feels like it shouldn't be necessary to me too -- since a source can only live in one component. So we'd change, e.g., http://changelogs.ubuntu.com/changelogs/pool/universe/q/qemu/qemu_2.8+dfsg-3ubuntu2/changelog to http://changelogs.ubuntu.com/changelogs/pool/q/qemu/qemu_2.8+dfsg-3ubuntu2/changelog with appropriate linking for BC? And then update the tooling to drop using the
[20:03] <nacc> component
[20:04] <slangasek> nacc: that's my thought, yeah
[20:06] <nacc> slangasek: sure that makes sense to me. I assume changelogs.ubuntu.com is deployed somewhere? Do you know if there is 'source' for it? or maybe it's just a matter of the deployed configuration
[20:07] <slangasek> bdmurray: ^^ you might know the answers here re: changelogs.u.c?
[20:11] <nacc> slangasek: ah, we might also just be able to use http://changelogs.ubuntu.com/changelogs/binary/q/qemu/1:2.8+dfsg-3ubuntu2/changelog (sub. appropriate binary pkg name)
[20:11] <juliank> nacc: slangasek: Interesting stuff. Flattening requires defining a new template like @CHANGEPATH@ without the component. Of course, if you flatten, you can just symlink all sections
[20:11] <nacc> slangasek: so it might just be because we are using pool/ as the prefix
[20:11] <nacc> juliank: yep, that's what i was looking at (after staring at the code for a while :)
[20:12] <slangasek> juliank: symlink> which would require no client-side code changes, convenient
[20:12] <juliank> Yep. That would be 100% backward compatible
[20:12] <nacc> i'll file a bug regardless, because it feels like something we can/should fix.
[20:12] <juliank> I think it would make a ton of sense to define more variables
[20:13] <juliank> @CHANGEPATH@ is not really the best abstraction layer
[20:13] <udevbot> Error: "CHANGEPATH@" is not a valid command.
[20:13] <nacc> lol
[20:13] <juliank> lol
[20:14] <nacc> juliank: yeah, it feels like it happens to work for what is defined now, but if something was to change, it's hard to tweak
[20:14] <juliank> I'd say do the flatten and symlink change now-ish, and then we have some time to figure out a better clean solution to the problem for 17.10 :)
[20:15] <nacc> juliank: ack, once i know how it's setup :)
[20:16] <juliank> nacc: That should even work without changing the server side code if it's just files (the software would write through main/, etc., but symlinking those to .. means it just works in practice)
[20:18] <nacc> juliank: right, that makes sense
[20:37] <bdmurray> slangasek/nacc: https://code.launchpad.net/extract-changelogs
[20:37] <nacc> bdmurray: thanks!
[20:42] <nacc> juliank: hrm, is this comment self-contradictory?
[20:43] <nacc> "// the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/1.1 or contrib/liba/libapt/2.0 " ?
[20:43] <nacc> oh is SRCNAME_SRCVER a variable?
[20:43] <nacc> path.append(Src).append("_").append(StripEpoch(SrcVersion))
[20:44] <juliank> You are right, the examples are wrong
[20:44] <juliank> / the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/apt_1.1 or contrib/liba/libapt/libapt_2.0
[20:44] <nacc> juliank: ack, np, i just wanted a sanity check :)
[20:45] <nacc> bdmurray: interestingly --^ the binary/ subdirectory for c.u.c does not do that, it has it as binary/SRC/SRCNAME/SRCVER/changelog
[20:46] <nacc> and it seems that the epoch is being kept in the binary/ SRCVER
[20:46] <juliank> nacc: Comment fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e6dddfe
[20:47] <nacc> juliank: thanks! :)
[20:49] <nacc> juliank: ok, with some fiddling, (without having to change c.u.c yet) i was able to get binary/ to work (rather than pool/) for c.u.c -- but i think we'd need to tweak how binary/ is setup to match what the changelog subcommand does. Given that it seems like binary/ exists for exactly this reason (i'm still readling/learning) and is doing all this symlinking, it seems like it might be sensible to use
[20:49] <nacc> (rather than changing how c.u.c/c/pool works?
[20:51] <juliank> nacc: Switching the URI would require changes to apt and possibly other clients (who knows?). I'd rather have a backwards compatible change.
[20:52] <nacc> juliank: ack, makes sense
[20:52] <nacc> juliank: my first foray into apt's code, so just learning a bit :)
[20:53] <juliank> nacc: Well, you'll probably regret that day then!  :D
[20:53] <nacc> juliank: :)
[20:54] <juliank> nacc: Don't look into it too much though, if you become an expert, you'll get all sort of questions.
[20:54] <juliank> ;)
[20:54] <nacc> heh
[21:15] <nacc> bdmurray: am i reading lp:extract-changelogs::lp-extract-changelogs.py wrong, or does it log the symlinks in binary/ backwards (e.g., '%s' -> '%s' % (dest, lnk)) ?
[21:16] <bdmurray> nacc: I haven't looked at the code in about a year, can you be more specific?
[21:16] <nacc> bdmurray: it eventually calls (sort of), os.symlink(os.path.abspath(dest), lnk)
[21:16] <nacc> which to me means lnk -> dest
[21:16] <nacc> but it logs "dest -> lnk"
[21:19] <bdmurray> nacc: around line 323?
[21:20] <nacc> bdmurray: err, yeah, sorry!
[21:21] <bdmurray> nacc: yes, it does look backwards
[21:21] <nacc> bdmurray: ack, i'll stage a fixlet for that along with my suggestion then -- as i'm copying that code a bit :)
[21:21] <bdmurray> nacc: well don't copy any of that author's mistakes!
[21:21] <nacc> bdmurray: :)
[21:47] <nacc> bdmurray: i think i found another error, I think the binary/ symlinks are only created when the changelog already exists. But if we are extracting it for the first time, we don't create the symlinks until we see it again. r45 changed this (before that chagne, if i'm reading it right), we only created the symlinks when the changelog is extracted the first time. I think the intention of the change was to
[21:47] <nacc> 'fix-up' already extracted versions? not entirely sure yet :)
[21:51] <bdmurray> nacc: yes, re "fix-up"
[21:57] <nacc> bdmurray: ack, thanks