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:40 |
---|---|---|
sparr | https://help.ubuntu.com/community/Kernel/Compile and https://wiki.ubuntu.com/KernelTeam/GitKernelBuild don't mention those steps | 00:41 |
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 | 00:42 |
=== cpaelzer__ is now known as cpaelzer | ||
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 |
ubottu | 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 |
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:48 |
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:49 |
oSoMoN | LocutusOfBorg, why not patch python-selenium to change the hardcoded path? | 09:50 |
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:51 |
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:53 |
LocutusOfBorg | maybe ruby-selenium-webdriver? | 09:54 |
LocutusOfBorg | not sure how many else... | 09:54 |
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:55 |
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:56 |
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:57 |
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:58 |
oSoMoN | I haven't checked in a while, they probably strip down the upstream source tarball | 09:59 |
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:05 |
LocutusOfBorg | https://paste.ubuntu.com/p/5TQn4kBMv6/ | 10:18 |
LocutusOfBorg | oSoMoN, ^^ it takes more time for the debdiff than for the patch itself... | 10:18 |
oSoMoN | LocutusOfBorg, note that the description of bug #1667208 is incorrect, it says "/usr/lib/chromium/chromedriver" but it's "/usr/bin/chromedriver" | 11:31 |
ubottu | 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:31 |
LocutusOfBorg | true... | 11:40 |
oSoMoN | LocutusOfBorg, here is an updated diff, would you mind giving it a sanity check? https://paste.ubuntu.com/p/mdzS9BGmVt/ | 11:43 |
LocutusOfBorg | yes, I like it! | 11:44 |
LocutusOfBorg | of course if it builds :) | 11:44 |
oSoMoN | wait, I forgot the provides line | 11:45 |
oSoMoN | adding it | 11:45 |
LocutusOfBorg | oops true | 11:45 |
=== ricab is now known as ricab|lunch | ||
=== caribou_ is now known as caribou | ||
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:55 |
rbasak | How were systemd services installed back then? | 13:56 |
LocutusOfBorg | rbasak, hold on | 13:57 |
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? | 13:59 |
LocutusOfBorg | anyway, you should build-depend on dh-systemd (>= 1.5) on control file, it wasn't part of debhelper at that time | 14:00 |
rbasak | I can do that. Thanks! | 14:03 |
LocutusOfBorg | in virtualbox/xenial I simply do dh --with systemd | 14:03 |
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:04 |
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:05 |
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:07 |
LocutusOfBorg | not sure, vbox uses virtualbox.service IIRC and it works | 14:08 |
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:09 |
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:16 |
LocutusOfBorg | if it is non-standard naming you should anyway tell it how to enable | 14:17 |
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:25 |
rbasak | The certbot.service is ending up in the deb though. | 14:26 |
=== ricab|lunch is now known as ricab | ||
Ark74 | ricotz, hello! | 19:43 |
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:44 |
kenvandine | hggdh: pong | 19:47 |
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:48 |
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:49 |
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:50 |
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:51 |
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:52 |
hggdh | k. Still, then, we now have two different paths -- older systems still carry the package, new ones carry the snap | 19:54 |
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:55 |
kenvandine | that's the intent | 19:56 |
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:54 |
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:55 |
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:56 |
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:57 |
infinity | Same story. | 20:58 |
zimmerian | okay nope - still confused … so more info time - let me write this to be more clear and concise :-) | 21:01 |
zimmerian | alright - I hope this helps | 21:06 |
zimmerian | https://pastebin.com/bw1MpGDU | 21:06 |
sarnold | maybe start with ls -l and dpkg -L output with the old version and new version of your package | 21:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 | |
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 |
ubottu | Debian bug 182747 in dpkg "dpkg should not remove a symlink to a directory unless it's empty" [Wishlist,Open] | 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:21 |
infinity | google packages have similar potential issues. | 21:22 |
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. | 21:23 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!