| nacc | sarnold: does that make sense? | 00:00 |
|---|---|---|
| sarnold | nacc: it sure makes more sense than my pile of forty thousand symlinks :) | 00:02 |
| 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:03 |
| nacc | luckily juliank is cleverer than us! | 00:04 |
| sarnold | yes :D | 00:05 |
| juliank | :D | 00:05 |
| 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:08 |
| 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:09 |
| juliank | this way you get a canonical url | 00:10 |
| nacc | juliank: yep, true | 00:10 |
| 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:11 |
| 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:12 |
| juliank | Every solution has its pros and cons. The symlink one is technically the easiest one, and the most resource efficient one. | 00:13 |
| 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:15 |
| slangasek | nacc: I don't see any reason to care that there is extra stuff published under c.u.c/pool/$component | 00:38 |
| juliank | I almost have working generic rewrite rules. | 00:50 |
| 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:55 |
| juliank | That was a bit funny, as I tried to really simplify things. | 00:56 |
| 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 | 00:57 |
| juliank | nacc: So JFTR: Given that these rewrite rules look fairly easy now, that is my recommendation, as it is completely undangerous :) | 01:01 |
| juliank | The clue in the solution was to figure out that I can use $1 back references to the rewriterule pattern in rewritecond. | 01:02 |
| 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:04 |
| 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:05 |
| juliank | Cleaned up in https://gist.github.com/julian-klode/600237d0b61cf92b01748b25cf5921d7 | 01:28 |
| === dax is now known as hax | ||
| === hax is now known as dax | ||
| === davmor2_ is now known as davmor2 | ||
| 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:09 |
| seb128 | wgrant, hey, is there any news of that zesty translation export? https://translations.launchpad.net/ubuntu/zesty/+language-packs is still empty | 09:11 |
| happyaron | stgraber: I've uploaded a fix for that, will see what to do for zesty+1 | 09:53 |
| 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:04 |
| 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:05 |
| cjwatson | yes | 12:06 |
| cpaelzer | thanks | 12:06 |
| cpaelzer | 'll prepare the related SRUs then | 12:06 |
| === hikiko is now known as hikiko|ln | ||
| 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 | 12:42 |
| === hikiko|ln is now known as hikiko | ||
| === Son_Goku is now known as Conan_Kudo | ||
| === Conan_Kudo is now known as Son_Goku | ||
| barry | seb128: i'll look at that today | 14:07 |
| 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. | 14:35 |
| jackpot51 | Anybody know how to preseed language selection in the installer? | 15:44 |
| mdeslaur | jackpot51: http://bazaar.launchpad.net/~ubuntu-bugcontrol/ubuntu-qa-tools/master/view/head:/vm-tools/uvt#L1980 | 15:48 |
| jackpot51 | sweet | 15:50 |
| ginggs | mitya57: yes, that looks to be same issue. great :) | 15:54 |
| 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:11 |
| jackpot51 | Looks like it does | 16:12 |
| 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:32 |
| Saviq | willcooke, I know not really your area, but FYI ↑↑ | 17:47 |
| 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:48 |
| 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:49 |
| willcooke | Saviq, happyaron is EOD now, but I will pick it up with him first thing | 17:50 |
| Saviq | willcooke, ack, tx | 17:50 |
| 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:04 |
| 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:06 |
| Pharaoh_Atem | jbicha: afaik, gnome-software has been using PK backend since it was introduced in Xenial | 20:10 |
| Pharaoh_Atem | that's all gnome-software upstream supports, as far as I know | 20:11 |
| 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:12 |
| Pharaoh_Atem | eww | 20:13 |
| 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:14 |
| Pharaoh_Atem | why did you guys let it get this bad? :( | 20:16 |
| dobey | why did pk 1.0 have to remove pluggable back-end support? | 20:20 |
| 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:21 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:29 |
| 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:31 |
| barry | jbicha: yeah, it looks like just removing the dep from gnome-software doesn't help; aptdaemon still gets pulled in | 20:46 |
| jbicha | barry: oh, gnome-software > software-properties-gtk > aptdaemon | 20:47 |
| barry | jbicha: yeah ;/ | 20:47 |
| 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:48 |
| 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:51 |
| 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:52 |
| jbicha | one reason we killed software-center was because it depended on aptdaemon so the intent has been to drop aptdaemon eventually | 20:53 |
| barry | +1 | 20:54 |
| tumbleweed | ./win 35 | 21:45 |
| Unit193 | Bingo! | 21:45 |
| 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:46 |
| foli | This it to announce that we will be beginning maintenance on Canonical data centre firewalls in 8 minutes. | 22:52 |
| 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:54 |
| 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:55 |
| 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 | 22:56 |
| === 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: | ||
| tsimonq2 | foli: Ok | 22:57 |
| foli | tsimonq2: main thing effected that might interest you is launchpad | 22:57 |
| 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:58 |
| 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 :) | 22:59 | |
| foli | This it to notify the we are beginning maintenance on Canonical data centre firewalls now, lasting up to 1 hour. | 23:01 |
| 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:10 |
| nacc | jgrimm: should be fairly fast/trivial | 23:11 |
| jgrimm | nacc, yep, i will | 23:11 |
| nacc | jgrimm: your d/changelog entries don't close the bug anymore. Ok if i manually edit? | 23:12 |
| jgrimm | nacc, yes certainly | 23:13 |
| nacc | jgrimm: oh i see why | 23:13 |
| nacc | jgrimm: dep3changelog does it normally | 23:14 |
| nacc | but you used the long-form | 23:14 |
| 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:15 |
| jgrimm | hrmm | 23:16 |
| 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:18 |
| 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:20 |
| nacc | jgrimm: hrm, weird, even changing it locally it still didn't pick it up | 23:24 |
| jgrimm | nacc, meaning it didn't close? | 23:25 |
| 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:26 |
| 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:27 |
| 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:36 |
| 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:37 |
| 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:38 |
| jgrimm | nacc, ok that could certainly explain it then | 23:39 |
| slangasek | nacc: dep3changelog only likes https://bugs.launchpad.net/bugs/NNNNNNN | 23:39 |
| 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:40 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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 | 23:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!