[00:40] https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.0-rc6/ has five patch files that are applied to the source before building the mainline kernel [00:41] https://help.ubuntu.com/community/Kernel/Compile and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild don't mention those steps [00:42] if I am trying to build a kernel that is as close as possible to the ubuntu packaged kernels, should I be applying those or any other patches? [00:42] aww, damnit, sorry, all that belongs in another channel. sorry === cpaelzer__ is now known as cpaelzer [09:48] hello oSoMoN [09:48] hi LocutusOfBorg [09:48] can I upload a chromium fix for https://bugs.launchpad.net/ubuntu/+source/python-selenium/+bug/1667208 ? [09:48] Launchpad bug 1667208 in python-selenium (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed] [09:48] my wild guess is: let chromium-chromedriver provide chromium-driver [09:48] and add a symlink from /usr/lib/chromium-browser/chromedriver to /usr/bin/chromedriver [09:49] this way chromium should expose the same binary packages as debian, and the binary would be in the same location, so applications can use it [09:50] LocutusOfBorg, why not patch python-selenium to change the hardcoded path? [09:51] because we would need to patch all the reverse-dependencies if we do it that way... [09:51] do you have a reason for exposing tools in a different location with debian? [09:53] no specific reason, just trying to figure out the least invasive fix − I'm not sure I understand why reverse deps would need to be patched, if the path is already in python-selenium, do other packages hardcode it too? [09:54] maybe ruby-selenium-webdriver? [09:54] not sure how many else... [09:55] ./lib/selenium/webdriver/chrome/service.rb: @executable = 'chromedriver'.freeze [09:55] ./lib/selenium/webdriver/chrome/service.rb: Unable to find chromedriver. Please download the server from [09:55] if applications are supposed to find it in $PATH, I think we should patch chromium... [09:56] that makes sense [09:56] in the future more applications might start using it, this is why I think the binary package should be provided and the tool exposed in the system in a sane-way, otherwise we might not even have a way to find what in the archive breaks because of this [09:57] LocutusOfBorg, please do not upload the fix right away though, as there's a new release in the stable channel for which I was preparing an upload when you pinged, if you make a patch and hand it to me I'll include it [09:57] oSoMoN, I think I'll reassing the bug to chromium, and I'm already looking at how debian did it, I'll provide a patch shortly [09:58] thanks for confirming my analysis, I'm of course not a chromium user/developer :) [09:58] LocutusOfBorg, thanks, I'll put my upload on hold until I get your patch [09:58] mmm interesting, the debian package is 100MB, the Ubuntu one is 700MB [09:59] I haven't checked in a while, they probably strip down the upstream source tarball [10:05] since nobody is using the old location https://codesearch.debian.net/search?q=browser%2Fchromedriver [10:05] I think I will avoid the symlink [10:18] https://paste.ubuntu.com/p/5TQn4kBMv6/ [10:18] oSoMoN, ^^ it takes more time for the debdiff than for the patch itself... [11:31] LocutusOfBorg, note that the description of bug #1667208 is incorrect, it says "/usr/lib/chromium/chromedriver" but it's "/usr/bin/chromedriver" [11:31] bug 1667208 in chromium-browser (Ubuntu) "Ubuntu's selenium hardcodes a path that is valid for Debian, but not for Ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/1667208 [11:40] true... [11:43] LocutusOfBorg, here is an updated diff, would you mind giving it a sanity check? https://paste.ubuntu.com/p/mdzS9BGmVt/ [11:44] yes, I like it! [11:44] of course if it builds :) [11:45] wait, I forgot the provides line [11:45] adding it [11:45] oops true === ricab is now known as ricab|lunch === caribou_ is now known as caribou [13:55] In backporting certbot from Bionic to Xenial, dh_installsystemd no longer exists which I think is causing the timer and service to no longer be installed. [13:55] Suggestions? [13:56] How were systemd services installed back then? [13:57] rbasak, hold on [13:59] dh-systemd | 1.29ubuntu4 | xenial-updates/universe | all [13:59] dh-systemd | 10.2.2ubuntu1~ubuntu16.04.1 | xenial-backports/universe | all [13:59] using dh-systemd from backports should work... [13:59] rbasak, is it ok? [14:00] anyway, you should build-depend on dh-systemd (>= 1.5) on control file, it wasn't part of debhelper at that time [14:03] I can do that. Thanks! [14:03] in virtualbox/xenial I simply do dh --with systemd [14:04] and it should take care of mostly of it... [14:04] I'll give that a try. [14:04] I had completely forgotten about dh-systemd! [14:05] man dh_systemd_enable should give you the best answer :) [14:05] it took me a while to that back in time :) [14:07] Oh. It's in backports? [14:07] This is for an SRU. [14:07] Will 1.29 be enough? [14:07] It's >= 1.5 of course ;) [14:08] not sure, vbox uses virtualbox.service IIRC and it works [14:09] It looks like certbot.service got installed but not the timer. [14:09] And the override_dh_installsystemd didn't run. [14:09] But I can trawl through the docs now. Thanks again! [14:16] override_dh_systemd_enable: [14:16] dh_systemd_enable -p$(sname) --name vboxweb --no-enable debian/vboxweb.service [14:16] this is what I did in vbox for non-standard services names [14:17] if it is non-standard naming you should anyway tell it how to enable [14:25] dh_systemd_enable: Could not find "certbot.timer" in the /lib/systemd/system directory of certbot. This could be a typo, or using Also= with a service file from another package. Please check carefully that this message is harmless. [14:25] Maybe I can just installed that manually with dh_install [14:25] (well, certbot.install) [14:26] The certbot.service is ending up in the deb though. === ricab|lunch is now known as ricab [19:43] ricotz, hello! [19:44] I've being studiying the libreoffice ppa compilation/build. [19:44] Is this a good place to ask about it? [19:44] kenvandine: ping re. a few gnome packages and snaps [19:47] hggdh: pong [19:48] kenvandine: we compared the installed snaps from a Disco RC with an upgraded-to-Disco install. The RC install brings in gnome-(calculator|characters|logs|system-monitor), while on the already-existing system these are all (Disco) packages [19:48] kenvandine: even more, at least gnome-calculator is at a different version package x snap [19:48] hggdh: upgraded from what? [19:49] disco has the devel series of the debs [19:49] the snaps are built from the upstream stable series [19:49] which is still 3.30.x [19:49] once that hits 3.32 the snaps will as well [19:50] kenvandine: the upgraded system was Bionic->Cossmic->Disco [19:50] bionic shipped with those 4 as snaps not debs [19:50] so it should have the snaps instead [19:51] hggdh: could it have been an upgrade from a bionic system that was originally installed before bionic release? [19:51] the switch to the snaps was pretty late [19:51] my snap list only shows gnome-common-themes [19:52] they were seeded pretty late, so if you installed around beta you wouldn't have gotten the snaps [19:52] kenvandine: it *might*, yes. I got the laptop in... Feb 2018, so before release [19:52] ah, yeah they weren't seeded yet [19:52] yeah [19:52] so they would have been there as debs [19:54] k. Still, then, we now have two different paths -- older systems still carry the package, new ones carry the snap [19:55] but they are at different versions. The gnome-calculator package on Disco is 1:3.31.90-1ubuntu1, the snap (stable) is 3.30 [19:55] (edge does have a 3.31.90) [19:55] yeah [19:56] that's the intent [20:54] so this is probably a larger apt / dpkg thign but on remove my symlink gets removed [20:54] nothing in post pre scripts [20:54] is this a known bug? [20:55] or could it be the upgrading package at fault? [20:55] not very clear what you mean - how is this symlink created? [20:55] ^ [20:56] Need more info here. What symlink, what package is being removed, does the package believe it exclusively owns that path? [20:56] dpkg makes no real distinction between links and files [20:57] (except for some details around symlinks vs. directories on upgrade) [20:57] k - let me look a bit deeper I think I may know what's going on - sorry and thanks [20:57] Certainly if a symlink is shipped in a .deb then it'll be removed when that package is removed. [20:57] Intentionally [20:57] Or if you replace a file shipped by a deb with a symlink. [20:58] Same story. [21:01] okay nope - still confused … so more info time - let me write this to be more clear and concise :-) [21:06] alright - I hope this helps [21:06] https://pastebin.com/bw1MpGDU [21:08] maybe start with ls -l and dpkg -L output with the old version and new version of your package [21:09] It's possible that dpkg feels itself entitled to clean up the top-level directory (actually a symlink) when there was previously exactly one package using it and then that package was removed. [21:09] Not really specific to /opt except that packages generally don't install under /opt but apparently this one does. [21:09] cjwatson: that is true - it is the only package afaik [21:09] and yes - I fig'd that but this is the only package using /opt :-) [21:10] Not sure if there's a good way to avoid that here. [21:10] It's just generic "remove cruft that appears to be no longer used" code [21:10] hmm well I can create a stupid package with /opt/dont_delete_me or something [21:10] maybe that'd work [21:10] but curious if I should file this as a bug w/ debian [21:11] It's not a bug. [21:11] after I do actually test your theory - which seems to apply [21:11] I mean you could, but I'm not sure how it would be fixable even in theory [21:11] dpkg will always remove a directory when the last package owning it is removed. [21:11] (if it's also empty) [21:11] infinity: it's a symlink and there's other stuff that the symlink has - [21:12] it's a bug IMO [21:12] /other/moar_stuff does exist [21:12] It might be a bug if it's non-empty and dpkg has decided to treat it as a file instead of a directory. [21:12] and so this has a larger impact [21:12] The question is how it could possibly be fixed without breaking lots of other stuff [21:13] But it's certainly not Ubuntu-specific, so if you wanted to pursue it then the proper place would be a bug report on Debian dpkg, yes [21:13] cjwatson: true but I'm hoping somehow a test -L can be used - dunno [21:13] thank you all! [21:13] It's not about testing if it's a link and then not removing it. [21:14] It's about resolving it, treating it as a directory, and then applying the directory tests. [21:14] well to see if it is indeed because no other packages are using there [21:14] (if not empty, don't remove) [21:14] So it does indeed feel like a bug in this case, if the target isn't empty. [21:14] yeah - I agree infinity but I think that would actually make it a bigger quest perhaps? [21:15] dpkg just tries rmdir/unlink and ignores stuff like ENOTEMPTY; it doesn't look before it leaps [21:15] not sure of the cost of delving into each / every item to see if there's something else if it's a symlink [21:15] (if it has no remaining references to the thing) [21:16] and it makes some sense from the apt / deb side [21:16] nothing to do with apt [21:16] purely dpkg [21:16] whether it's a bug or not [21:17] I mean, the word "bug" is perhaps not the right one here. Misfeature. :P [21:17] cool - well thanks all - I'll see what I can find [21:17] hehehe true [21:17] I think it's behaving as expected (by the people who wrote it), but those people could be seen to be wrong, based on what a user might expect in this case. [21:18] It is mildly surprising, looking at the code, because it should try rmdir first, get ENOTEMPTY, give up before getting as far as the unlink that must have removed the symlink. But I haven't often needed to look at this code so might be misreading something. [21:18] cjwatson: Or, the misfeature was fixed, and you're reading a newer version than he's using. [21:19] Guillem does have a nasty habit of improving dpkg occasionally. [21:19] oh, I'm misreading [21:19] rmdir would get ENOTDIR in that case, and then it falls through [21:19] Ahh. [21:20] But that also highlights a maybe-not-computationally-insane path to fixing it. [21:20] If ENOTDIR, check linkiness, check contents of target, bail if not-empty. *hand-wavy* [21:20] Maaaaybe. If there aren't legit cases that would break [21:20] * cjwatson is happy for somebody else to think through that maze [21:21] well I'll be - seems like way back this was a thing and well … still is [21:21] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=182747 [21:21] Debian bug 182747 in dpkg "dpkg should not remove a symlink to a directory unless it's empty" [Wishlist,Open] [21:21] Probably means it's hard :) [21:21] …. and in true fashion - also /opt :-D [21:21] Yeah. [21:21] The real answer here might be to admit that /opt is a thing and ship it in base-files. :P [21:22] google packages have similar potential issues. [21:23] My hot take is that as soon as something is in deb/rpm form, it should be installing to system locations, not /usr/local or /srv or /opt, but obviusly there are those who disagree, and plenty of packages in the wild to prove it.