crouton
crouton copied to clipboard
dnschneid
Kali Linux "xbindkeys" Fix
About This is an target file and contains an fix, for the error during the installation of kali linux, where xbindkeys, can't be installed. Issue: #4792
What does the fix do? The fix will add debian bullseye repository to the apt sources.list, and than install xbindkeys, xbindkeys-config. After installation the script is removing the debian bullseye repository from the sources.list file.
sudo crouton -r kali-rolling -t kalifix,xfce,...
yes contact the owner and have the changes added This branch has no conflicts with the base branch Only those with write access to this repository can merge pull requests.
The fix should be in x11-common, not a separate target. I'm also not really sure what the fix should be. Adding an additional non-kali repository seems against the spirit of the distro (security-focused). It does look like kali's repo has xbindkeys packages though, and it looks like it's in the release list. Is this still even an issue?
It will not work when it is in x11! Because you need xbindkeys in gnome also or when using xiwi.
Than it only installs 2 packages (xbindkeys) from the debian repos, after that the repos got removed, so no packages will be installed from that source.
The next thing is, Kali is based on debian, so theoretically, it doesn't matters if the debian sources are included.
Yes xbindkeys is not available in the Kali repos, but crouton is needing it, so it's your project, than fix it, i give an opinion and target that fixes the bug.
To complain about the solution/Workaround is not the right way to maintain an project.
It will not work when it is in x11! Because you need xbindkeys in gnome also or when using xiwi.
The x11-common target is included by all flavors of X11, and desktop environment targets such as gnome will always include one of the X11 targets.
Put another way, the only target that actually installs xbindkeys is the x11-common target, so why would a fix go anywhere else?
Than it only installs 2 packages (xbindkeys) from the debian repos, after that the repos got removed, so no packages will be installed from that source.
Sure, until the chosen debian repo gets ahead of kali's current glibc version, and then your benign install has to pull in a mess of glibc packages to satisfy updated dependencies.
The next thing is, Kali is based on debian, so theoretically, it doesn't matters if the debian sources are included.
In theory Ubuntu is based on debian as well, but all that means is they share some basic packaging infrastructure. The choice of patches, library versions, standard compiler flags, and honestly really anything else can be tweaked by the downstream distro. Including an entire alternative distro's package list is a recipe for disaster, even if the intent is to only use it briefly for some specific packages.
Yes xbindkeys is not available in the Kali repos, but crouton is needing it,
Except it is available somehow, so maybe your root cause isn't correct.
so it's your project, than fix it, i give an opinion and target that fixes the bug.
To complain about the solution/Workaround is not the right way to maintain an project.
One of the many roles of a maintainer is to maintain project quality. Committing a bad fix does not help the project in the long term.
Because of naming it a bad fix
Quote:
IT'S WORKING !!!!!!!!!!!!!!!!!!!!!! God bless you, I've been struggling for MANY HOURS trying to find a solution to this error. Have a great week!!! <3 and thanks again for doing what you do.
The next thing is, I fixed it and it's working, you can copy the code and include it in x11. But coming after 2 months and whining about the creation of the fix is the wrong way.
Just because a fix works doesn't mean it's the correct fix or of an acceptable quality. You can (and already are), maintaining your own fork, so if you don't want to improve your patch to be upstreamable, there's really no point in keeping this discussion open.
Yes it's not in Kali repos so you need the debian repos, Kali is based on top of debian, so no problems should come up. Also there are only 2 packages that get installed from debian (xbindkeys and xbindkeysconfig).This fix is as extra target because you also need it when don't use xfce (install without x11). The second thing is that xbindkeys is needed before all other targets, this fix adding the repo, install xbindkeys and removes the repos so you will never had any other packages from this repo source installed.Von: David Schneider @.>Gesendet: Freitag, 21. Oktober 2022, 02:40An: dnschneid/crouton @.>Cc: Maik Damm @.>; Author @.>Betreff: Re: [dnschneid/crouton] Kali Linux "xbindkeys" Fix (PR #4800) The fix should be in x11-common, not a separate target. I'm also not really sure what the fix should be. Adding an additional non-kali repository seems against the spirit of the distro (security-focused). It does look like kali's repo has xbindkeys packages though, and it looks like it's in the release list. Is this still even an issue?
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>
x11-common is what brings in xbindkeys, so the fix needs to be in x11-common. xorg, xiwi, xfce, gnome, etc targets all directly or indirectly include the x11-common package as a dependency; that's how the crouton target system works.
"Based on debian" isn't sufficient to ensure compatibility. Ubuntu is based on debian as well, but pulling packages from sid into focal for instance will set you up for a world of hurt. I don't know why kali is building xbindkeys but not including it in the release. Maybe you need to file a bug with Kali as well.
I'm not going to accept a fix that includes adding a different distro's repository, even temporarily. I would, however, accept a fix that adds kali-only logic to x11-common, and does so by pulling the .debs from https://http.kali.org/kali/pool/main/x/xbindkeys/ using wget or curl. If you'd like to help out with this, feel free to re-open this PR once you've updated your patch.