/srv/irclogs.ubuntu.com/2017/03/13/#ubuntu-devel.txt

cpaelzergood morning06:28
=== FJKong is now known as BH1SCW
=== BH1SCW is now known as FJKong
=== bigon_ is now known as bigon
=== JanC is now known as Guest42627
=== JanC_ is now known as JanC
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:44
cjwatsonMez_: ubiquity10:45
Mez_cjwatson: where does it pull city names from ?10:45
Mez_(I vaguely remember that you work on the installer)10:45
cjwatsonMez_: I can't remember whether it's tzdata or tzsetup (both exist, the latter is a d-i component) - one of those two10:47
cjwatsonMez_: I used to, moved to working on Launchpad a couple of years ago10:47
Mez_Ah, fair enough.  I just don't like the installer mocking the local accent :)10:52
cjwatsonhuh?10:53
cjwatsonnobody is mocking anything.10:54
Mez_one sec :)10:54
Mez_(and that is said jokingly, btw)10:54
Mez_http://imgur.com/Wxfk2jQ10:57
cjwatsonI think the autocompletion stuff comes from a web service ...10:58
cjwatsongeoname-lookup.ubuntu.com10:59
cjwatsonwhich is https://launchpad.net/ubuntu-geonames11:00
Mez_And the question is, where is that maintained?11:00
cjwatsondid you type that before or after I pasted the Launchpad link?11:01
Mez_before :)11:02
cjwatsonso 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 localisation11:02
cjwatsonbecause e.g. https://ug.wikipedia.org/wiki/Birmin%27gxam11:03
cjwatsoncurl 'http://geoname-lookup.ubuntu.com/?query=Birmin&release=16.04' | jq   reproduces without having to go through the installer11:04
cjwatsonsomebody 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 importer11:05
cjwatsonanyway, this is definitely all in the ubuntu-geonames project11:06
cpaelzerusually 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:08
cpaelzerit makes no sense to add a fix to zesty it doesn't need, but it certainly does to fix it in Xenial11:09
cjwatsonthat would be an exception to discuss with the SRU team, probably in the context of a patch11:09
cpaelzerreasonable, I'll add details to the SRU template11:09
cpaelzerthanks cjwatson11:09
caribouhmm, not a good day for the dev release on my laptop : systemd-resolvd is going haywire on me, I'm loosing some keybindings12:11
=== hikiko is now known as hikiko|bbiab
=== hikiko|bbiab is now known as hikiko
rbasak!dmb-ping15:00
ubottubdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.15:00
sil2100!dmb-ping15:11
ubottubdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.15:11
sil2100(re-pinging)15:11
=== Mez_ is now known as Mez
mitya57Mirv, hi, do you have any pending changes for qtbase 16.04 / 16.10 SRUs? Or a branch in Git or Bzr or somewhere?15:30
mitya57(I want to SRU LP: #1380702)15:31
ubottuLaunchpad bug 1380702 in Canonical System Image "No keyboards shortcuts in QT apps" [High,In progress] https://launchpad.net/bugs/138070215:31
naccmitya57: there are tasks open, and someone needs to follow: https://wiki.ubuntu.com/StableReleaseUpdates15:33
slangasekogra_: 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 sync16:47
ogra_slangasek, is it still happening ? or did my wiping fix it ?17:46
slangasekogra_: I haven't seen any overwrite from you lately, but I've seen several more overwrites from other users17:46
ogra_slangasek, i just remembered that i got an invite notification once ... and was actually wondering about why the TB invites me ...17:47
slangasekogra_: 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 somewhere17:47
ogra_ah17:48
ogra_:)17:48
mterryjdstrand: 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:05
mterryI can share the apparmor denial message if that would help18:07
sarnoldmterry: jdstrand is out for the week18:09
mterrysarnold: ah!  thx18:10
sarnoldmterry: 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 snapped18:10
mterrysarnold: my goal was to let it get a list of installed snaps and run them18:25
mterrysarnold: web servers would be snap daemons, not user-run snaps right?18:26
mterrysarnold: my head space was letting guest run Calculator and such18:26
sarnoldmterry: 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:28
mterrysarnold: hmm, OK.  I won't bother continuing this then  :P18:29
dobeythat does seem like a problem we need to solve, but doesn't seem like it should be prioritized at the moment18:30
sarnoldmterry: well, if we ever face the day of only having browsers via snaps, we'll probably need answers to this :/18:30
dobeybut i don't think we want the genral ability to read/write to snapd.socket18:30
dobeyshould be ok for unity8 and a couple other system things to do that perhaps, but general access seems bad18:32
mterrysarnold: agreed that was my thinking18:33
mterrysarnold: but if we have a technical block on stacking profiles, no need for it now18:33
mitya57Mirv, 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:42
naccslangasek: 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 terms19:59
naccof 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?19:59
slangaseknacc: 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:00
naccslangasek: 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 the20:03
nacccomponent20:03
slangaseknacc: that's my thought, yeah20:04
naccslangasek: 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 configuration20:06
slangasekbdmurray: ^^ you might know the answers here re: changelogs.u.c?20:07
naccslangasek: 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
julianknacc: slangasek: Interesting stuff. Flattening requires defining a new template like @CHANGEPATH@ without the component. Of course, if you flatten, you can just symlink all sections20:11
naccslangasek: so it might just be because we are using pool/ as the prefix20:11
naccjuliank: yep, that's what i was looking at (after staring at the code for a while :)20:11
slangasekjuliank: symlink> which would require no client-side code changes, convenient20:12
juliankYep. That would be 100% backward compatible20:12
nacci'll file a bug regardless, because it feels like something we can/should fix.20:12
juliankI think it would make a ton of sense to define more variables20:12
juliank@CHANGEPATH@ is not really the best abstraction layer20:13
udevbotError: "CHANGEPATH@" is not a valid command.20:13
nacclol20:13
julianklol20:13
naccjuliank: yeah, it feels like it happens to work for what is defined now, but if something was to change, it's hard to tweak20:14
juliankI'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:14
naccjuliank: ack, once i know how it's setup :)20:15
julianknacc: 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:16
naccjuliank: right, that makes sense20:18
bdmurrayslangasek/nacc: https://code.launchpad.net/extract-changelogs20:37
naccbdmurray: thanks!20:37
naccjuliank: hrm, is this comment self-contradictory?20:42
nacc"// the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/1.1 or contrib/liba/libapt/2.0 " ?20:43
naccoh is SRCNAME_SRCVER a variable?20:43
naccpath.append(Src).append("_").append(StripEpoch(SrcVersion))20:43
juliankYou are right, the examples are wrong20:44
juliank/ the path is: COMPONENT/SRC/SRCNAME/SRCNAME_SRCVER, e.g. main/a/apt/apt_1.1 or contrib/liba/libapt/libapt_2.020:44
naccjuliank: ack, np, i just wanted a sanity check :)20:44
naccbdmurray: interestingly --^ the binary/ subdirectory for c.u.c does not do that, it has it as binary/SRC/SRCNAME/SRCVER/changelog20:45
naccand it seems that the epoch is being kept in the binary/ SRCVER20:46
julianknacc: Comment fixed in https://anonscm.debian.org/cgit/apt/apt.git/commit/?id=e6dddfe20:46
naccjuliank: thanks! :)20:47
naccjuliank: 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 use20:49
nacc(rather than changing how c.u.c/c/pool works?20:49
julianknacc: Switching the URI would require changes to apt and possibly other clients (who knows?). I'd rather have a backwards compatible change.20:51
naccjuliank: ack, makes sense20:52
naccjuliank: my first foray into apt's code, so just learning a bit :)20:52
julianknacc: Well, you'll probably regret that day then!  :D20:53
naccjuliank: :)20:53
julianknacc: 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
naccheh20:54
naccbdmurray: 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:15
bdmurraynacc: I haven't looked at the code in about a year, can you be more specific?21:16
naccbdmurray: it eventually calls (sort of), os.symlink(os.path.abspath(dest), lnk)21:16
naccwhich to me means lnk -> dest21:16
naccbut it logs "dest -> lnk"21:16
bdmurraynacc: around line 323?21:19
naccbdmurray: err, yeah, sorry!21:20
bdmurraynacc: yes, it does look backwards21:21
naccbdmurray: ack, i'll stage a fixlet for that along with my suggestion then -- as i'm copying that code a bit :)21:21
bdmurraynacc: well don't copy any of that author's mistakes!21:21
naccbdmurray: :)21:21
=== josepht` is now known as josepht
=== mako_ is now known as mako
naccbdmurray: 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 to21:47
nacc'fix-up' already extracted versions? not entirely sure yet :)21:47
bdmurraynacc: yes, re "fix-up"21:51
naccbdmurray: ack, thanks21:57

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!