[00:00] <nacc> sarnold: does that make sense?
[00:02] <sarnold> nacc: it sure makes more sense than my pile of forty thousand symlinks :)
[00:03] <nacc> presuming the above seems reasonable to anyone else, then we can do a one-time merge pool/component/* to pool/* and symlink before the changelog parser runs next and it should be very little change from then on -- it's actually *really* easy, except for the case you just mentioned, where we might have some src package in multiple components
[00:03] <nacc> sarnold: yeah that was my initial changes too, don't worry
[00:04] <nacc> luckily juliank is cleverer than us!
[00:05] <sarnold> yes :D
[00:05] <juliank> :D
[00:08] <juliank> nacc: IMO it would be awkward if anything relied on main/ not containing stuff from universe/ and similar. That basically means somebody crawling things.
[00:09] <juliank> Hmm, not thought about internal scripts
[00:09] <juliank> On the http level, you could hide the symlinks, by doing a 301 redirect for the symlink
[00:10] <juliank> this way you get a canonical url
[00:10] <nacc> juliank: yep, true
[00:11] <juliank> nacc: As a counter point, it doubles the number of requests on the changelogs server :D
[00:11] <nacc> slangasek: do you have an opinion on the above? specifically, woudl it break B-C in your opinion if c.u.c/pool/universe/ contained publications from main (or v.v.)?
[00:12] <juliank> Arguably, if you find out the correct rewrite rules, rewriting things in apache would be the cleanest solution, and one that allows you to rollback easily at any point.
[00:13] <juliank> Every solution has its pros and cons. The symlink one is technically the easiest one, and the most resource efficient one.
[00:15] <juliank> Just rewriting in apache would make things fairly invisible (you can't find the "wrong" links by querying), but you need like 4 redirect rules (one for each component). It also doubles the number of requests (because it needs to follow the redirect) [although, you can probably just do an internal redirect and directly serve a 200]
[00:38] <slangasek> nacc: I don't see any reason to care that there is extra stuff published under c.u.c/pool/$component
[00:50] <juliank> I almost have working generic rewrite rules.
[00:55] <nacc> slangasek: ack, thanks for the response
[00:55] <juliank> nacc: I just added these rules to my /changelogs dir in .htaccess, that deals with everything https://jak-linux.org/changelogs/htaccess.txt
[00:55] <nacc> juliank: thanks
[00:56] <juliank> That was a bit funny, as I tried to really simplify things.
[00:57] <juliank> Hence stuff like RewriteCond $1 !^main$
[00:57] <juliank> otherwise, I'd have to repeat the relevant sections for every component that would be boring
[01:01] <juliank> nacc: So JFTR: Given that these rewrite rules look fairly easy now, that is my recommendation, as it is completely undangerous :)
[01:02] <juliank> The clue in the solution was to figure out that I can use $1 back references to the rewriterule pattern in rewritecond.
[01:04] <juliank> nacc: I now added a slightly different take in the htaccess file: Start the section with RewriteCond "%{REQUEST_FILENAME}" !-f instead of the RewriteCond $1 !^main$ thing
[01:05] <juliank> So basically: If the requested file does not exist, and the file exists within <other component>, redirect to <other component>
[01:05] <juliank> that's also more robust against double slashes and stuff
[01:28] <juliank> Cleaned up in https://gist.github.com/julian-klode/600237d0b61cf92b01748b25cf5921d7
=== dax is now known as hax
=== hax is now known as dax
=== davmor2_ is now known as davmor2
[09:09] <seb128> barry, hey, did you see that your aptdaemon upload from january is still blocked in zesty-proposed? do you plan to sort that out?
[09:11] <seb128> wgrant, hey, is there any news of that zesty translation export? https://translations.launchpad.net/ubuntu/zesty/+language-packs is still empty
[09:53] <happyaron> stgraber: I've uploaded a fix for that, will see what to do for zesty+1
[12:04] <cpaelzer> cjwatson: on bug 1668093 will there be another release in Debian and sync into Zesty or should I create a fix for Zesty as well just as for the SURs?
[12:04] <ubottu> bug 1668093 in openssh (Ubuntu Yakkety) "ssh-keygen -H corrupts already hashed entries" [High,Triaged] https://launchpad.net/bugs/1668093
[12:05] <cjwatson> cpaelzer: I'm going to upload to unstable today
[12:05] <cpaelzer> cjwatson: thanks, to confirm will that still be synced despite being late in zesty cycle?
[12:06] <cjwatson> yes
[12:06] <cpaelzer> thanks
[12:06] <cpaelzer> 'll prepare the related SRUs then
=== hikiko is now known as hikiko|ln
[12:42] <ginggs> mitya57: sphinx 1.5.3 fixes the two failing tests with the latest texlive-base packages, and i see you've just uploaded that to experimental
=== hikiko|ln is now known as hikiko
=== Son_Goku is now known as Conan_Kudo
=== Conan_Kudo is now known as Son_Goku
[14:07] <barry> seb128: i'll look at that today
[14:35] <mitya57> ginggs, thanks for the info, it is https://github.com/sphinx-doc/sphinx/issues/3428 then.
[14:35] <mitya57> I will sync 1.5.3-1 when LP picks it up.
[15:44] <jackpot51> Anybody know how to preseed language selection in the installer?
[15:48] <mdeslaur> jackpot51: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1980
[15:50] <jackpot51> sweet
[15:54] <ginggs> mitya57: yes, that looks to be same issue. great :)
[16:11] <jackpot51> mdeslaur: Does the same apply to OEM config?
[16:11] <mdeslaur> jackpot51: sorry, I don't know
[16:11] <jackpot51> I will test
[16:12] <jackpot51> Looks like it does
[17:32] <Saviq> happyaron, hey, I'm afraid the new zfs causes bug #1673197
[17:32] <ubottu> bug 1673197 in zfs-linux (Ubuntu) "Upgrading zfs-initramfs breaks booting from a zfs root" [Critical,New] https://launchpad.net/bugs/1673197
[17:47] <Saviq> willcooke, I know not really your area, but FYI ↑↑
[17:48] <willcooke> Saviq, related to this perhaps?  https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1672749
[17:48] <ubottu> Launchpad bug 1672749 in lxd (Ubuntu) "Please don't assume zfs module is always loaded" [Undecided,Triaged]
[17:48] <Saviq> possibly
[17:49] <willcooke> Saviq, have you got version 0.6.5.9-4ubuntu1 installed?
[17:49] <Saviq> willcooke, of everything else zfs, yes, downgraded just zfs-initramfs to make it work again
[17:49] <willcooke> Saviq, ack
[17:50] <willcooke> Saviq, happyaron is EOD now, but I will pick it up with him first thing
[17:50] <Saviq> willcooke, ack, tx
[20:04] <jbicha> barry: did you run gnome-software without aptdaemon installed? I thought it was needed for the apt backend we're using (but I could be wrong)
[20:06] <lamont> should I be concerned that the "Display" icon is missing from System Settings?
[20:06] <lamont> tbf, new video card, but wut?
[20:06] <jbicha> I was going to propose when 17.10 opened to try to switch Software to the packagekit backend used by Debian (LP: #1643134)
[20:06] <ubottu> Launchpad bug 1643134 in gnome-software (Ubuntu) "Switch gnome-software to use PackageKit backend" [Wishlist,Triaged] https://launchpad.net/bugs/1643134
[20:10] <Pharaoh_Atem> jbicha: afaik, gnome-software has been using PK backend since it was introduced in Xenial
[20:11] <Pharaoh_Atem> that's all gnome-software upstream supports, as far as I know
[20:12] <jbicha> Pharaoh_Atem: we have been patching Software to use apt instead: https://git.gnome.org/browse/gnome-software/log/?h=wip%2Fubuntu-3-22
[20:13] <Pharaoh_Atem> eww
[20:14] <jbicha> xenial didn't have packagekit 1.0 for one thing
[20:14] <Pharaoh_Atem> well, I'm going to feel real stupid if my email to ubuntu-devel gets approved
[20:14] <Pharaoh_Atem> oh gross
[20:14] <Pharaoh_Atem> pk 0.8.x!?
[20:16] <Pharaoh_Atem> why did you guys let it get this bad? :(
[20:20] <dobey> why did pk 1.0 have to remove pluggable back-end support?
[20:21] <barry> jbicha: oh, i probably didn't uninstall aptdaemon.  i'll do that test in a bit.  i just installed gnome-software from my ppa
[20:21] <barry> jbicha: i grepped teh g-s src pkg and couldn't find a reference to aptdaemon
[20:24] <Pharaoh_Atem> dobey: you'd have to ask hughsie
[20:24] <Pharaoh_Atem> though if I had to guess, people writing bad, terrible, evil backends
[20:24] <Pharaoh_Atem> but all backends in PackageKit are libraries
[20:24] <Pharaoh_Atem> I've hacked on the dnf backend in PackageKit
[20:25] <Unit193> So some people did bad things, remove all the support?  Makes sense..
[20:25] <Pharaoh_Atem> so from that perspective, they are pluggable
[20:25] <Pharaoh_Atem> you can swap backends at runtime, as well
[20:25] <Pharaoh_Atem> (I did during the hif->dnf backend transition)
[20:25] <dobey> you mean in gnome-software or in packagekit?
[20:26] <Pharaoh_Atem> dobey: you said PackageKit
[20:26] <Pharaoh_Atem> PackageKit has multiple backends
[20:26] <dobey> yes, but part of the reason why we delayed the move from 0.8 was because we could no longer build a click back-end for it
[20:26] <Pharaoh_Atem> that seems more your fault than anything
[20:26] <dobey> because support for having back-ends built outside the source tree was killed
[20:27] <Pharaoh_Atem> ah, out of source backends
[20:27] <Pharaoh_Atem> that's different
[20:27] <Pharaoh_Atem> I'm not sure why, though I'm not sure why you didn't just contribute the backend
[20:27] <dobey> well building back-ends as dso in-tree, and not allowing anyone out of tree to build back-ends as dso, is kind of an oxymoron
[20:29] <Pharaoh_Atem> you'd have to ask hughsie, but I suspect he would rather be able to freely refactor the API between PK and backends
[20:31] <dobey> re: not contributing the back-end into upstream source tree: i'd say it doesn't make sense. packagekit isn't a packaging system. having every packaging system maintain back-ends in packagekit source tree is bad practice. better to maintain the back-end in the tree for the packaging system it's for, so it stays properly in sync
[20:31] <Pharaoh_Atem> dobey: that seems quite backwards
[20:31] <dobey> but anyway. it's done now
[20:31] <Pharaoh_Atem> meh
[20:46] <barry> jbicha: yeah, it looks like just removing the dep from gnome-software doesn't help; aptdaemon still gets pulled in
[20:47] <jbicha> barry: oh, gnome-software > software-properties-gtk > aptdaemon
[20:47] <barry> jbicha: yeah ;/
[20:48] <barry> jbicha: i think i will still ask to have the aptdaemon in proposed just removed.  we should continue to purge aptdaemon in zesty+1
[20:51] <jbicha> barry: software-properties was already ported from aptdaemon to pk in Debian, we didn't push it into zesty since I don't think anyone checked if the driver code worked
[20:51] <jbicha> https://anonscm.debian.org/git/collab-maint/software-properties.git/tree/debian/patches/0004-Implement-PackageKit-support.patch
[20:52] <barry> jbicha: that's interesting.  thanks.  i'll file some bugs.  i think next cycle i'll have other fun things to work on so i'm not sure i want to take it as *my* mission to get rid of aptdaemon ;)
[20:53] <jbicha> one reason we killed software-center was because it depended on aptdaemon so the intent has been to drop aptdaemon eventually
[20:54] <barry> +1
[21:45] <tumbleweed> ./win 35
[21:45] <Unit193> Bingo!
[22:46] <omajid> hi! is anyone working on packaging (or related) work for .NET Core here?
[22:46] <omajid> please feel free to chime in here: https://github.com/dotnet/core-setup/issues/1599
[22:52] <foli> This it to announce that we will be beginning maintenance on Canonical data centre firewalls in 8 minutes.
[22:54] <RAOF1> omajid: You'd likely be looking for #debian-cli on OFTC.
[22:54] <omajid> thanks.. weird channel name, but looks like the right place!
[22:55] <tsimonq2> foli: Ok, so what does this mean?
[22:55] <tsimonq2> foli: i.e., what will be down?
[22:55] <RAOF1> omajid: We've got all the packaging infrastructure in place to be able to have .NET Core and Mono installed in parallel and such. I think someone has started trying to package?
[22:55] <popey> sounds like a directhex_ type question
[22:55] <popey> he did a ton of work packaging mono bits
[22:56] <omajid> oh, cool!
[22:56] <directhex_> moo?
[22:56] <foli> tsimonq2: maintenance on multiple firewalls, each should only be a brief outage
[22:56] <popey> moo indeed.
[22:56] <popey> directhex_: long thread (linked above) about packaging *waves hands* dotnet things
=== ChanServ changed the topic of #ubuntu-devel to: Canonical datacentre firewall maintenance 23:00 - 00:00 UTC | Yakkety Yak (16.10) Released | Archive: feature freeze, DIF | 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:57] <tsimonq2> foli: Ok
[22:57] <foli> tsimonq2: main thing effected that might interest you is launchpad
[22:58] <tsimonq2> foli: Then you might want to find someone to tweet on behalf of @launchpadstatus or whatever the handle is.
[22:58] <tsimonq2> (just a suggestion)
[22:59] <wgrant> It's next on my list :)
[22:59] <tsimonq2> wgrant: \o/ :)
[22:59]  * tsimonq2 goes back to doing other things, thanks for letting us know foli :)
[23:01] <foli> This it to notify the we are beginning maintenance on Canonical data centre firewalls now, lasting up to 1 hour.
[23:10] <nacc> jgrimm: can you do the sru paperwork for LP: #1668813 ?
[23:10] <ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress] https://launchpad.net/bugs/1668813
[23:11] <nacc> jgrimm: should be fairly fast/trivial
[23:11] <jgrimm> nacc, yep, i will
[23:12] <nacc> jgrimm: your d/changelog entries don't close the bug anymore. Ok if i manually edit?
[23:13] <jgrimm> nacc, yes certainly
[23:13] <nacc> jgrimm: oh i see why
[23:14] <nacc> jgrimm: dep3changelog does it normally
[23:14] <nacc> but you used the long-form
[23:15] <nacc> jgrimm: https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1668813 rather than https://bugs.launchpad.net/bugs/1668813
[23:15] <ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress]
[23:15] <nacc> jgrimm: may be worth its own bug against dep3changelog :)
[23:16] <jgrimm> hrmm
[23:18] <nacc> jgrimm: note that the latter is the default template when you run `dpkg-source --commit` as well (b.l.n/bugs/<bugnumber>)
[23:18] <jgrimm> ack, yeah i hadn't realized that at all, subtle
[23:20] <nacc> jgrimm: http://paste.ubuntu.com/24185552/ is the regex ... it seems like it should have caught your case (i'm assuming it's greedy)
[23:24] <nacc> jgrimm: hrm, weird, even changing it locally it still didn't pick it up
[23:25] <jgrimm> nacc, meaning it didn't close?
[23:26] <nacc> jgrimm: it didn't insert into the changelog, i must be missing something obvious
[23:26] <jgrimm> or meaning you were testing that regex
[23:26] <jgrimm> ah
[23:27] <jgrimm> i shouldn't have blindly trusted dep3changelog
[23:27] <nacc> jgrimm: i just tested in a different src package and it worked fine
[23:36] <nacc> jgrimm: ok, figured it out
[23:36] <nacc> i *think* the patch is not being viewed as dep3
[23:36] <nacc> dep3-compliant
[23:37] <nacc> it seeing the second blank line and quitting
[23:37] <nacc> http://dep.debian.net/deps/dep3/
[23:37] <nacc> slangasek: is that right?
[23:38] <nacc> slangasek: dep3changelog is not putting the LP bug # in the changelog for https://bugs.launchpad.net/ubuntu/+source/iproute2/+bug/1668813/+attachment/4835669/+files/iproute2_4.3.0-1ubuntu3.16.04.1.debdiff
[23:38] <ubottu> Launchpad bug 1668813 in iproute2 (Ubuntu Yakkety) "The tc man page references tc-index man page but tc-index man page does not exist" [Low,In progress]
[23:38] <nacc> jgrimm: my understanding is there are two blocks of headers at most and a block ends at the first empty line (after stripping whitespace))
[23:38] <nacc> so the second block here is 'Just a typo there...'
[23:39] <jgrimm> nacc,  ok that could certainly explain it then
[23:39] <slangasek> nacc: dep3changelog only likes https://bugs.launchpad.net/bugs/NNNNNNN
[23:40] <nacc> slangasek: afaict, it handles both (i'm messing with my local version) -- it's the whitespace it's not liking in this case
[23:40] <nacc> the blank lines, specifically
[23:40] <slangasek> oh
[23:40] <nacc> but the example from http://dep.debian.net/deps/dep3/ has blank lines (afaict on a website)
[23:40] <slangasek> dep3changelog bug, then
[23:42] <nacc> i *think* it might be a bug in the dep3 spec too
[23:42] <nacc> it's hard to say
[23:42] <nacc> oh i see what it is
[23:42] <nacc> slangasek: yeah, dep3changelog bug
[23:42] <nacc> subject and description are meant to be handled differently, i think
[23:42] <slangasek> well, I don't love the dep3 spec's laxity when it comes to blank lines, but I can't assert that it's a bug :)
[23:42] <nacc> i'm not sure how you'd solve this properly ...
[23:43] <nacc> "When Subject is used, it is expected that the long description is outside of the structured fields."
[23:43] <nacc> but it can be immediately after the Subject line and separated by whitespace
[23:43] <nacc> but you don't know when the 'long description' ends
[23:44] <jgrimm> nacc, FYI description updated with an SRU template filled in
[23:44] <nacc> jgrimm: thanks
[23:44] <jgrimm> np, thank you
[23:44] <nacc> jgrimm: eitehr way i'll fix up the changelog on sponsoring this
[23:45] <nacc> jgrimm: i'm assumign this was a straight wget of the upstream patch?
[23:45]  * jgrimm will be wary of trusting dep3changelog going forward (or less trusting that i know how to interact with it)
[23:45] <jgrimm> nacc, git forma-patch of upstream cherry pick
[23:45] <jgrimm> format-patch
[23:45] <nacc> jgrimm: ack