You are not logged in.
Everything went well with the upgrade. Thank you for your hard work, Devuan Team!
I noticed that the same thing happened with lazpaint-gtk2, trimage and speedcrunch packages, they are not in Trixie/Excalibur even though they were available previously. It also used to be the case with acetoneiso in Bookworm/Daedalus, it was missing from there but now it's back in the repos.
It's pretty annoying when it occurs, but I agree that there must be a reason for the disappearance of particular versions - lack of maintainers, bugs etc. It might be a good idea to visit the software's website to see what's going on, sometimes they offer deb packages or source tarballs for (hopefully successful) installation. There also may be suitable software alternatives in the repositories.
A Linux equivalent for SD Card Formatter is the blkdiscard command, but it's quite risky to use - can only be used in 'forced' mode due to a bug and probably won't work at all if using a usb card reader instead of an integrated one.
Use blkdiscard
In short:
blkdiscard /dev/mmcblk0
Discussion
To quickly erase an entire SD card, you can use the blkdiscard(8) command. This calls the Linux BLKDISCARD ioctl, which in turn passes CMD38, the same as SD Memory Card Formatter.
Interesting options
-s, --secure securely discard blocks. As has been pointed out elsewhere, a normal CMD38 will make some blocks appear empty, but leave others plainly visible due to garbage collection. Use -s if you wish to be a little more secure and force garbage collected blocks to also be erased.
-z, --zero zero-fill blocks rather than discard.
Does not work over USB
Note that while this works on my laptop and Raspberry Pi, it would not work on a USB SD card reader. The difference is that kernel needs to have access to the low-level MMC subsystem, which USB abstracts away as a generic "mass storage" device. [I believe Microsoft Windows has the same limitation, but please correct me in the comments if I'm wrong.]
If you do not have a device that can speak directly to the low-level SD card, it is possible to build one out of an Arduino and run SDFormatter.ino.
Extraordinarily dangerous!
Since blkdiscard must be run as root, it can easily destroy all of your data. You better be sure that you are pointing it at the right device and then double-check again. Use lsblk and df.
The manpage claims that, to be safe, it will only work if the drive isn't already mounted. That would be a nice safety feature, but it is not true as of this writing. The current implementation requires the -f, --force option if the drive is already formatted, which is (almost) always going to be the case since SD cards come pre-formatted. Unfortunately, using --force means that all checks, including if the drive is in use, are disabled.
Hopefully someday Linux will allow blkdiscard to be run on removable devices without requiring root privileges which would make it much less dangerous.
Other uses
Besides quickly wiping out data for privacy, supposedly blkdiscard, similar to fstrim for an SSD, will improve wear-leveling and make some SD cards generally run a little bit faster.
I have a 64G TeamGroup drive that I use regularly, when I looked at it in Gparted I also saw a chunk of unallocated space at the beginning. It was quite small, but still noticeable, maybe about 20MB. I reformatted it to use all the space available, did not suffer any data loss so far but of course with such oddities going on it's best to keep backups everywhere you can... It's also supposed to be USB 3.0 but is very slow on writes. Flash memory is getting very sketchy, a lot of people complain, especially when it comes to bigger capacity drives/cards.
Got another 64G drive by Kingston (bought together with the first one), that one came preformatted as FAT32 instead of ExFAT for some reason... Strange.
Here is another good page on the subject of fake flash drives: https://rmprepusb.com/tutorials/007-all … sh-drives/ .
I was using KeePassX and KeePass2 before, did not care for XC at all but now I found a very nice alternative called QtPass.
It uses GPG for encryption and doesn't have bells & whistles like autotype, attachments etc. - just a password generator, hierarchical storage and customizable extra fields. May be worth checking out if you're looking for this kind of simplicity.
La Llorona de Los Angeles...
I've just tried the solution proposed in post #6, installed the missing 32-bit packages and configured the printer via CAPT Printer option. Same story with the empty print jobs being sent, only this time it returns Idle - ccp send_data error, exit. According to various related threads, mostly on Linux Mint forums, for whatever reason the ccpd daemon has trouble starting up and working correctly without additional configuration via special scripts. Making it start together with the system seemed to help some people, as did querying the status via lpstat command (this didn't work for me).
I will be on the lookout for those HP and Brother printers from now on, looks like for compatibility with Linux these brands are the best choice after all.
Yes, this is the manual approach that I also came across on a few Ubuntu-related sites, but I have not seen this link, very interesting. Thanks for sharing, I will keep it mind as a possible solution. I have actually installed printer-driver-cjet from the repos (turns out that cndrvcups-capt was just the driver from the debs that showed up in Synaptic, so that was a misnomer on my part). But as I mentioned, the repo driver did not have any effect. Since the native solution didn't work, I'll leave it at that for now. I don't feel like overwhelming a new system with the non-repo stuff like ccpd at the moment. But thanks for the help, everyone. Perhaps I will give it a try some other time, as it doesn't sound too hopeless.
Thank you for the swift replies and recommendations.
So far I have tried removing the factory drivers, reinstalling cups and installing the libcupsimage2 package that was suggested in one of the links. Unfortunately in my case this resulted in no change whatsoever, the print jobs still go into nothingness (I tried both with and without the official driver). Interestingly, the print queue window and the CUPS error log both say that 0 bytes were sent to the printer (for any job). Could this be the clue as to what's going on?
I've also installed openprinting-ppds, that gave me more options for the drivers, there are several LBP models listed but not the 6020 - the Printer Settings tool suggested LBP6670... still the same result. Installing foomatic-db expanded the list even further, but my printer's model isn't there either. Configuring it as a generic text-only printer also doesn't work.
Greetings to everyone in the Devuan community. Recently I have installed the system on my new laptop, and I must say it's been quite a pleasure to set up, configure and use - a BIG thank you to everyone involved in the project! I have been looking for a solid, reliable and sensible OS and indeed: I found it in Devuan.
I have this old printer lying around from the past decade, Canon i-SENSYS LBP6020. Knowing that there isn't much luck when it comes to the printer support in Linux, I nevertheless decided to give it a try, just in case. It seems that the system detects the printer just fine (at /dev/usb/lp0), I was able to add and configure it via system-config-printer, but I cannot get it to actually print anything. The CUPS test page as well as any jobs from other applications get sent to the printer, the Printer Properties dialog reports that data is being sent, but then the state returns to Idle shortly after, without printing anything. The printer is connected directly to a USB 3.0 port, no hubs involved.
I have downloaded and installed the 64-bit debs from the manufacturer's site as provided here:
https://www.canon-europe.com/support/co … p6020.html
The GUI Print Settings tool accepts this driver, but I always end up with the result described above. Same thing happens if I try to set up the printer using the cndrvcups-capt driver from the repos. Something appears to be missing here, and I'm not sure what exactly should be the next step.
The official driver package comes with a thorough instruction for manual installation, but it's from 2013 so I cannot really tell which of the steps described there are now supposed to be handled by the system-config-printer tool, if any at all. Do I need the ccpd daemon and autoshutdowntool?
I also found some information regarding the missing 32-bit components that may be necessary for this particular driver to function properly in 64-bit environment, and about an old version of the libpango library which I found in the repositories and installed, but apparently it isn't enough. I haven't tried installing the 32-bit stuff.
There is an old autoinstall script
https://github.com/hieplpvip/ubuntu_can … p_setup.sh
https://github.com/hieplpvip/ubuntu_can … restart.sh
specifically created to resolve the issues, but as you see it was made for Ubuntu and I don't know if it can be adjusted to work with Devuan, or perhaps there is another way to make this printer work using the currently available tools and some additional steps. Any advice would be very much appreciated, although if there are any big stumbling blocks here, it's not the end of the world - I can still use my old machine for printing.