This is my first time using debian away from stable. I’m used to periodic apt update && apt upgrade but I suspect that’s probably not good practice on unstable or that I should at least ask. Web search got me nothing useful.
Should work fine. Normally if there’s a problem the problem packages will show up as ‘held back’. Packages with known bugs will show you the bugs and ask you if you still want to proceed.
I’m the person who maintains the machinery building Debian packages for the Reform repository (reform-debian-packages repo), the scripts that build the system image (reform-system-image repo) and who maintains the reform-tools package.
But, I’m also not using any of that myself.
Instead, I’m going to use this thread for a shameless plug of reform.debian.net which offers system images and a package repository tracking Debian stable (bookworm) instead of Debian unstable like the MNT repo.
If you find any bugs in the stuff shipped by reform.d.n, please do not hesitate to contact me. The website will also soon get a rework with the release of the Pocket Reform and the rk3588 module for the big Reform.
I totally agree it would be better for me to be on bookworm!
The recommended method A not working for me.
METHOD A:
extrepo installed ok but complains:
$ extrepo enable reform.debian.net
Repository reform.debian.net does not exist! at /usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 33.
extrepos is looking for config in /etc/apt/sources.list.d/extrepo_*.sources which does not exist.
Now my /etc/apt/sources.list did not match what was alleged to be there. My sources.list is below. Thinking that maybe installing extrepos would have installed the necessary configuration containing reform.debian.net I tried apt reinstall but extrapos doesn’t exist in the repositories now configured (and didn’t, when I first installed in with the “before I started” repos.
/etc/apt/sources.list:
# Contents before I started:
#deb http://deb.debian.org/debian unstable main non-free-firmware
# Should have been, according to reform.debian.net/repo
# deb http://deb.debian.org/debian unstable main
# deb [arch=arm64 trusted=yes] https://mntre.com/reform-debian-repo reform main
# as per changes https://reform.debian.net/repo/
deb http://deb.debian.org/debian bookworm main
deb http://deb.debian.org/debian bookworm-updates main
deb http://security.debian.org/debian-security bookworm-security main
Given the above, and sources.list as shown, apt update runs to completion with no error except, as expected:
N: Missing Signed-By in the sources.list(5) entry for 'https://mntre.com/reform-debian-repo'
In a local directory I attempted to extract the subkey via the given gpg command, which results in:
gpg: keybox '/usr/share/keyrings/debian-keyring.gpg' created
gpg: WARNING: nothing exported
I suspect this means that I do not have the 2023.07.22 keyring, but at this point I’m a bit over my head. I understand apt pretty well but the intricacies of gpg/pgp, not much.
Hi there, this last error is normal, the repo on our website is not signed, as we don’t have a really secure signing process in place that could be automated. So HTTPS is the only authentication mechanism there at the moment.
I was responding to josch’s suggestions about switching to bookworm, here reform.debian.net, which I took to mean there was a key:
If you go this route instead of using extrepo, see below for a method to verify that the GPG key attached to your downloaded reform_bookworm.sources is indeed the one that is also present in your /usr/share/keyrings/debian-keyring.gpg.
Following josch’s suggestions I don’t think I’m setup correctly. Nowhere in the /etc/apt tree is referrence to the new repository, reform.debian.net.
“switching to bookworm” cannot be done by converting your Debian “unstable” installation to bookworm. Doing so would mean to downgrade packages to their version in bookworm and that is very dangerous and will lead to file-loss. Debian (and to my knowledge all its derivatives) only support upgrades but do not support downgrades of package versions.
The extrepo method does not work for you because extrepo correctly identified that your system is actually Debian unstable but the repository provided at reform.debian.net is for bookworm and not compatible with unstable and hence does not show it to you nor lets you enable it.
If you want to use Debian bookworm instead of unstable on your Reform (unless your Debian unstable installation was not updated for over a year) you can only do that via doing a fresh installation but you cannot downgrade.
Thank you for your feedback. I’m going to add a short version of what I explained here to reform.d.n.
OK understood. I hadn’t considered that in fact stable/bookworm would be a downgrade.
OK this all makes sense. I’ll stay in unstable since wholesale change has no immediate value to me, other than less vigilance for occasional bad packages. I’ll put a note in my sources.list regarding this should I get to a point where reinstall makes sense.
Is the only option to switch to a stable release to do a complete reinstall?
Last night apt update && apt upgrade Sid decided to remove a few packages I use like firefox-esr and telegram-desktop and now every time I tell it to explicitly install something I want, I have to go back and reinstall more things it decided it was removing with a “dependency problems, but removing anyway as you requested” message. Nowhere in my command history or the apt log have I given it a remove command.
Kind of getting sick of this gaslight routine from the package manager.
Is your system in a healthy state right now? I.e. can you run apt-get install -f and it succeeds? If yes, give me the output of this command and I will probably be able to tell you exactly what the problem is:
My plan is to add support for it together with rk3588 so that I can use my limited free time a bit more effectively.
If there are people in the community who would like to help with Debian stable support for the Pocket Reform on reform.debian.net, this can of course happen earlier than that.
Follow-up on this from IRC.
I had no problem running apt-get install -f. It looks like I decided to update in the middle of some big changes with the *t64 packages, because trying again this evening seems to have done installs for everything it removed.
I am probably going to try to migrate this machine to “testing” later after I get back home.
I’m not a debian expert, but my understanding is that this should in general prefer testing over unstable when installing packages. Obviously the system still has a whole bunch of packages from unstable installed, but as they migrate into testing, the system should slowly turn into a testing install as updates are performed over time.
When installing any package, there will likely be conflicts if that package depends on something already installed, because the installed version will be from unstable and be too new. aptitude seems to handle this a bit better than apt-get, because it will interactively give you a few options to resolve the conflict. (e.g. you might be able to downgrade just a few dependencies, or install the package from unstable).
This can happen indeed but I think these situations come up only very, very rarely in the wild. For when they do come up, yes aptitude will do a better job than apt and then your strategy to still have unstable available to the resolver will make it able to probably find a working solution.
Note, that 500 is the default pin priority, so what you also can do is to not pin trixie at all but pin sid alone with a lower priority.
Another thing you can do to avoid pinning is to set the APT::Default-Release configuration option to trixie which in turn will give packages from trixie a pin priority of 990.
Let me please compliment you that your last post shows greater understanding of apt than I’d expect from any regular user.
If you do not want your system to be in a mixed state, you could also build yourself a system image for testing and install from that one by running the following in the reform-system-image git:
./mkimage -d testing reform-system-imx8mp
Lastly: yes, I’d say that running testing rather than unstable is a reasonable compromise for people who would not like to use bookworm/stable (because they enjoy very new packages) but who also would not like to run into the RC bugs from unstable (remember the recent ones like ALERT! /dev/mmcblk2p2 does not exist. Dropping to a shell! - #14 by josch ).
There should only be very few problems you could run into. One of them is, that the kernel on the mntre.com repositories is built in unstable and as such it uses gcc and the C library from unstable. It will sometimes be the case that the kernel is built against package versions that are not yet in testing and in those situations you will either not be able to install the more recent kernel until gcc and glibc also transitioned to testing, or you will have to make use of a more clever resolver and pull gcc and glibc from unstable for the time being.