# How to add kernels in debian trixie?

**URL:** <https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515>\
**Category:** JupyterLab\
**Tags:** how-to, help-wanted\
**Created:** [April 19, 2026, 6:05pm UTC](https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515 "2026-04-19T18:05:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![N7DR](https://avatars.discourse-cdn.com/v4/letter/n/ee7513/32.png) [@N7DR](https://discourse.jupyter.org/u/N7DR)\
**Post date:** [April 19, 2026, 6:05pm UTC](https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515/1 "2026-04-19T18:05:16Z")

</div>

1. Trixie (debian 13) system, fully up to date.
2. I have installed the official debian jupyter packages from the debian repositories; also installed the R kernel at the same time.
3. I have used jupyter notebook successfully on the same computer in the (somewhat distant) past, with several other kernels (bash, gnuplot, markdown, sos). This was probably using debian 12, or possibly debian 11.
4. debian does not appear to have official trixie packages for bash, gnuplot, markdown or the sos kernels.
5. when I start jupyter lab, I am presented with icons for available kernels: python, R, bash, gnuplot, markdown, sos.
6. selecting these kernels one at a time, jupyter lab can find and connect only to the python and R kernels; it fails to connect to the other kernels for which icons are present.
7. looking at the list of kernels returned from kernelspec list (which I assume might be helpful): [ZB:~] jupyter kernelspec list  
Available kernels:  
bash /home/n7dr/.local/share/jupyter/kernels/bash  
ir /home/n7dr/.local/share/jupyter/kernels/ir  
markdown /home/n7dr/.local/share/jupyter/kernels/markdown  
gnuplot /usr/local/share/jupyter/kernels/gnuplot  
sos /usr/local/share/jupyter/kernels/sos  
python3 /usr/share/jupyter/kernels/python3  
[ZB:~]

I am guessing that the python and R kernels (i.e., the ones installed from official debian packages) are the only ones that are properly installed, and the others are left over from the very old jupyter installation, and for some reason no longer work.

Given all these facts (I’m happy to provide any more information that might be necessary), what do I need to do to remove the old kernels that jupyter no longer seems to be finding, and to install the bash, gnuplot, markdown and sos kernels in a way that the current jupyter installation will be able to connect to them properly? A simple idiot-proof step-by-step list of commands to execute would be wonderful! 🙂

---

<div class="post-metadata">

**Author:** ![bollwyvl](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/bollwyvl/32/904_2.png) [@bollwyvl](https://discourse.jupyter.org/u/bollwyvl)\
**Post date:** [April 19, 2026, 7:04pm UTC](https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515/2 "2026-04-19T19:04:37Z")

</div>

If they don’t work, `(sudo) rm -rf` (or just `mv` to some backup location) on the not-working kernels in `{various}/share/jupyter/kernels/{broken-kernel}` will make them stop appearing.

Once cleaned, the “several other kernels” can be re-installed… however they were installed in the first place. Once installed, their kernelspec folders would need to be discoverable either by copying or symlinking from the `{various}/share/jupyter/kernels` you are seeing above. If there was complex environment fixturing, this could be… non-trivial, and might require manipulating the `kernel.json`.

Given the above, and that using the os-level package manager for most jupyter things isn’t particularly recommended (as in, we really can’t help _when_ `sudo pip install` breaks someone’s OS), I don’t think a “list of scripts” is going to be forthcoming from anyone that isn’t sitting at your computer.

The above _will_ start falling apart when browser assets start to mismatch, or kernel startup need a lot of fixturing, which is entirely possible for deep/niche stacks.

The most reproducible approach I know of is to:

- get and install [miniforge](https://conda-forge.org/miniforge/)
- keep the `base` environment it creates entirely clean, mostly just with `conda`, `mamba` and friends
- manage as much as possible in a single `environment.yml`, keeping the “big rocks” like `python`, `notebook`, etc. fairly tightly pinned, at least to your desired major/minor versions
- use that to set up a _separate_ environment which can be rebuilt on a whim with `$CONDA_EXE env update --file environment.yml`

---

<div class="post-metadata">

**Author:** ![N7DR](https://avatars.discourse-cdn.com/v4/letter/n/ee7513/32.png) [@N7DR](https://discourse.jupyter.org/u/N7DR)\
**Post date:** [April 20, 2026, 5:15pm UTC](https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515/3 "2026-04-20T17:15:12Z")

</div>

I’m trying to figure out what to do, following your detailed – but somewhat difficult for me to understand – response. (I’m just a guy wanting to get this working, and floundering at how difficult it all seems to be nowadays.)

Should I, do you think:

1. remove the debian packages and all the kernels from the computer.
2. start from scratch and install jupyterlab using the procedure documented at: [Installation — JupyterLab 4.6.0a4 documentation](https://jupyterlab.readthedocs.io/en/latest/getting_started/installation.html)
3. install the kernels seriatim from the list at [Jupyter kernels · jupyter/jupyter Wiki · GitHub](https://github.com/jupyter/jupyter/wiki/Jupyter-kernels) (although I see that, strangely, that list does not contain the bash kernel).

One the one hand, it seems silly, given that debian has gone to the trouble of providing packages, that I should ignore those packages; but on the other, having installed those packages, it seems that one is basically stuck with no simple, clear., documented way to install other kernels; so starting again from scratch and avoiding the debian packages looks to me like the weird-but-sensible thing to do.

---

<div class="post-metadata">

**Author:** ![bollwyvl](https://yyz1.discourse-cdn.com/flex031/user_avatar/discourse.jupyter.org/bollwyvl/32/904_2.png) [@bollwyvl](https://discourse.jupyter.org/u/bollwyvl)\
**Post date:** [April 20, 2026, 6:29pm UTC](https://discourse.jupyter.org/t/how-to-add-kernels-in-debian-trixie/38515/4 "2026-04-20T18:29:32Z")

</div>

Sure, it’s a known fact that `pip`, `conda`, `cargo`, `npm`, etc. lack the rigour of a true distribution like debian, which does incredible, principled work emulated in many other places.

No doubt, you could build or request all of the extra kernels as packages for debian, and then work entirely from within those packages.

But the language-based ecosystems, and their cross-platform downstreams like `conda-forge`, are what Jupyter volunteer maintainers can feasibly impact directly, given the enormous variance of downstream user operating systems, architectures, and then separate release cadences of different lifecycles within them.

> **... for example, "just" ipython...**
>
> [![Packaging status](https://repology.org/badge/vertical-allrepos/ipython.svg)](https://repology.org/project/ipython/versions)