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