The officially official Devuan Forum!

You are not logged in.

#176 Hardware & System Configuration » excalibur dist-upgrade? » 2025-08-15 13:37:11

Altoid
Replies: 12

Hello:

As I have mentioned a few times, these days my main box runs on Devuan 5 / Daedalus, which I update and back-up once a week to a recovered WD-MBL running on OpenWRT:

$ uname -a
Linux devuan 6.1.0-38-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.147-1 (2025-08-02) x86_64 GNU/Linux
$ 

No issues save those which may have appeared while doing some housekeeping, more than anything to clean up stray matter / files / unnecessary packages left over from my system's dist-upgrade path beginning with ascii or Jesse. As it has been a while, I cannot exactly recall when, but it must have been ~ 05/2017.

I have recently seen quite a few posts from members (some quite eager) to do an upgrade to Devuan 6 / Excalibur, which I expect must be for a variety of valid reasons.

As for me, I cannot at least for the time being, find one to move from Daedalus, much the same way I was not able to find one to move from Beowulf with which I had no issues and was quite comfortable with (but was being mothballed) to Chimaera, process which was nothing short of a train-wreck for which I hold XFCE mainly responsible.

A last resort effort by way of yet another dist-upgrade to Devuan 5 / Daedalus straightened most everything out and thus avoided a tiresome roll-back or clean installation.

My box is a fully upgraded ca. 2008 BIOS boot only (ie: no secure boot crap) Sun Ultra24 workstation with an early version of the infamous Intel MEI which I keep at bay (?) by blacklisting the respective modules, and an Intel Q9550 CPU with 8.0Gb RAM which has been running perfectly well on Linux since late 2015 and on Devuan Linux since ~ 05/2017.

The MB has PCIe v2 / PCI v2.3 slots, USB2.0 controller and GbE.
Twin Quadro FX 580 cards feeding three 19" monitors run (well enough) with the latest nouveau driver and the LSI SAS1068E and the 2940U/UW SAS/SCSI controllers have worked perfectly well from the very first Linux installation.

So it would seem that (?) there is nothing that would require much of a dist-upgrade as I expect that any and all applicable Linux drivers / modules* are quite mature by now.

That said, I have no plan (or willingness) to spend my pension money on new (unneeded) hardware as everything works as expected.
My only (small) peeve is that the nouveau driver could do much better at running a 3x monitor desktop but that is about it.

In the 10+ years I have been running on Linux I have seen the size of each release grow and grow and cannot but wonder what more is in store.
eg:
Devuan Chimaera netinstall *.iso: 372.00 MB - UEFI installer:  0.754 MB
Devuan Daedalus netinstall *.iso: 477.80 MB - UEFI installer:  23.00 MB
30X more code was added to the UEFI partition on the road between Chimaera and Daedalus.

Frankly, I do not think I can expect anything in the way of improvements for my hardware.

And after reading this I cannot but to agree with this note:

## Old Business

- Debian Trixie has been released
- And what a cluster-f*** it is!

Not that I am wanting to do a dist-upgrade as I will probably be able to get by (like I did with Beowulf) by using a backported kernel if necessary but eventually the time will come to move forward albeit with the bare metal in my box in perfect working condition and unchanged, save maybe larger/faster drives or newer monitors.

I guess that, besides @greenjeans and I, there may be more members in a similar situation from which I would like to hear an opinion.

Best,

A.

* corrections welcome.

#177 Other Issues » Mozilla and LLMs » 2025-08-13 11:02:15

Altoid
Replies: 2

Hello:

From today's edition of The Register:
------------------------------------------------
Some users report their Firefox browser is scoffing CPU power
You guessed it: looks like it's a so-called AI
by Liam Proven
------------------------------------------------
https://www.theregister.com/2025/08/13/ … ing_power/

Liam Proven @The Register wrote:

... in July we reported on the next installment: Firefox 141 now has an odious new feature Mozilla dubs AI-enhanced tab groups, to which the company adds a box called Things to keep in mind –

Firefox uses a local AI model to read your open tabs' titles and descriptions to suggest more tabs and group names. Everything happens on your device.

Best,

A.

#178 Re: Hardware & System Configuration » [SOLVED] Devuan 6 excalibur, OpenRC, networking, /etc/hosts ingnored » 2025-08-12 20:09:36

Hello:

Andre4freedom wrote:

... NetworkManager is always installed ...

Yes, that it is.

I eventually got tired of seeing my /etc/resolv.conf continually being tampered with.
Because, after all ...   Just whose bloody $%& workstation is it?

Good old WiCD did not do that.
But, alas, it is no longer available.

So I just disabled the crap Network Manager and that was it.

My ethernet link comes up at boot and I just use ifdown / ifup when I want to do otherwise or connect to a friendly neighbour's AP if my fibre-link provider finds the opportunity to screw up something.

Doing that has made life much simpler.
As always, YMMV.

Best,

A.

#179 Re: Installation » any way to obtain Excalibur ISO? » 2025-08-11 22:56:53

Hello:

marma-lade wrote:

... Excalibur is not ready for prime-time ...

If it is in the repository, it is because it has been tested and works.
Otherwise it would not be there.

marma-lade wrote:

... "missing firmware" or something to that effect.

I take it you do not have a wired connection available?
ie: ethernet

From https://www.devuan.org/os/install:

Non-free firmware

Non-free firmware packages are available on all install media. These packages will only be installed if required by your wifi adapter. To avoid the automatic installation and loading of needed non-free firmware, choose the Expert install option during the installation process.

The desktop-live and minimal-live images have non-free firmware packages pre-installed. These packages may be removed after boot using the remove_firmware.sh script available under /root.

Best,

A.

#180 Re: Installation » any way to obtain Excalibur ISO? » 2025-08-10 23:21:42

Hello:

marma-lade wrote:

Thanks ...

You're welcome.

marma-lade wrote:

... "burning" was trying to do a migration from Debian ...

I see.
A bit trickier than Devuan to Devuan
Have heard that it is doable but never had to go there.

marma-lade wrote:

... always make back-ups.

The only way.

marma-lade wrote:

... try building a system with that ISO ...

If you have a bit of experience, can follow instructions and know what sort of system you want, the netinstall option is the best one.
You get to install exactly what you want.

Excluding unneeded recommends and avoiding choices made for you by the one size fits all packaging system makes for a win-win.
eg:
No need for exim4 as the default MTA in a desktop system.
Replacing it with DMA (DragonFly mail agent) is just one of many examples.

Start small / basic on a spare disk and build on that while keeping a log.
It will be very useful in the future.

When you are done, you can clone your Devuan system to your main HDD. 

Do let us know how you fared.

Best,

A.

#181 Re: Installation » any way to obtain Excalibur ISO? » 2025-08-10 22:15:38

Hello:

marma-lade wrote:

... impatient to get an Excalibur ISO.

OK ...  8^°

marma-lade wrote:

... burned by migrating ...

Rare ...
But not unheard of.

marma-lade wrote:

... ISO available?

Have you tried checking for info in the usual places? eg: here.

That said and with your not wanting to risk a dist-upgrade, you may want to consider having a go at the recently uploaded netinstall.iso (20250809) and see how you fare with it.

Best,

A.

#182 Other Issues » Stardict - possibly problematic application? » 2025-08-08 21:24:32

Altoid
Replies: 4

Hello:

From today's edition of The Register:
------------------------------------------------
Star leaky app of the week: StarDict
Fun feature found in Debian 13: send your selected text to China – in plaintext
by Liam Proven - Fri 8 Aug 2025 // 15:29 UTC
------------------------------------------------

Liam Proven @The register wrote:

A discussion on the oss-security mailing list on OpenWall highlights an interesting feature of an apparently innocuous dictionary app that's included in Debian: StarDict, a Gtk app that looks up text and displays the definition in a tooltip. The alarm was raised by Vincent Lefèvre from INRIA in an email titled StarDict sends the user's X11 selection to the network:

With some plugins, StarDict sends the user's X11 selection from other applications to some servers: dict.youdao.com and dict.cn (both Chinese servers).

https://www.theregister.com/2025/08/08/ … p_of_week/

Best,

A.

#183 Re: Hardware & System Configuration » gnome related files shuffle / replacement » 2025-08-06 16:07:57

Hello:

... policykit-1-gnome is gone ...
... directly replaceable with the mate-polkit.

Being a virtual package and provided by some other package (NN-polikit), to me* it's a tomayto = tomahto situation.
ie: still a virtual package provided by a real one instead of a real, stand alone package to do just that and only that.
* ymmv, obviously.

So I'll just leave that one as-is and avoid the possibilty of something going south.

With respect to replacing pinentry-gnome3 with pinentry-curses, any ideas as how to do it without screwing up?

Thanks for your input.

Best,

A.

#184 Hardware & System Configuration » gnome related files shuffle / replacement » 2025-08-06 15:17:19

Altoid
Replies: 2

Hello:

Having had reasonable success in ridding my box of unnecessary gnome files, I still have two to solve: policykit-1-gnome and pinentry-gnome3.
I have taken care to check on all dependencies but you never know, I will post any complaints I get.

The remaining gnome related files are either by choice (gnome-disk-utility) or dependencies of (timeshift.

This is what aptitude prints out when asked about:

1. policykit-1-gnome

$ aptitude why policykit-1-gnome
i   thunar Recommends policykit-1-gnome | polkit-1-auth-agent
$ 

and
2. pinentry-gnome3

$ aptitude why pinentry-gnome3
i   gnupg           Depends  gpg-agent (< 2.2.40-1.1.1~)
i A gpg-agent       Depends  pinentry-curses | pinentry 
i A pinentry-gnome3 Provides pinentry                   
$ 

If I understand correctly, the alternative to policykit-1-gnome would be polkit-1-auth-agent and the alternative to pinentry-gnome3 would be pinentry-curses.

Unfortunately, the first alternative is a virtual package provided, among others, by policykit-1-gnome.

See here: https://packages.debian.org/bookworm/po … auth-agent

So unless some other option is available, that will be it.

But pinentry-curses is available ...

$ apt list | grep pinentry-curses
--- snip ---
pinentry-curses/stable 1.2.1-1 amd64
--- snip ---
$ 

... and can be installed to replace pinentry-gnome3.

$ aptitude why pinentry-curses
i   gnupg     Depends gpg-agent (< 2.2.40-1.1.1~)
i A gpg-agent Depends pinentry-curses | pinentry 
$ 

Q: which would be the safe / proper manner to replace pinentry-gnome3 with pinentry-curses and not wreak havok in my system?

Thanks in advance.

Best,

A.

#185 Re: Devuan Derivatives » Keyring? » 2025-08-04 20:14:25

Hello:

greenjeans wrote:

Nice work ...

Thanks.
But the merit actually goes to a chap going by the handle Bentolor.

He posted about this same issue* back in 2019 and came up with the keyringrc.cfg file for setting the backend.
See https://github.com/jaraco/keyring/issues/391

* BiT fails because it cannot make sense of the ChainerBackend

A chap going by the handle Jaraco (autor of keyring?) explains the process further down.
You may want to give it a read, it may at some point be useful to you.

Best,

A.

#186 Re: Devuan Derivatives » Keyring? » 2025-08-04 15:30:44

Hello:

I wrote:

So much for my getting rid of all the gnome crap ...

No so fast ...

A deeper look helped me understand something that should have been pointed out to users in a clear(er) manner.
ie: for the half baked hoi-poloi like me.

The problem was that BiT did not automagically choose the available backend to use, seems that getting that done is a rather complex matter.
The solution is an option to add to the BiT GUI, apparently a work in progress to be included upstream, maybe in the next release (?).

But there was a quick, clean and easy alternative: to set it up manually, ending the bloody problem in 5'.
Could not have been easier but ...

Anyhow, if someone else comes across this same problem, the solution is within the BiT FAQs.

TL:DR

backintime FAQs wrote:

To diagnose and solve this follow these steps in a terminal:

# Show default backend
python3 -c "import keyring.util.platform_; print(keyring.get_keyring().__module__)"

# List available backends:
keyring --list-backends

# Find out the config file folder:
python3 -c "import keyring.util.platform_; print(keyring.util.platform_.config_root())"

# Create a config file named "keyringrc.cfg" in this folder with one of the available backends (listed above)
[backend]
default-keyring=keyring.backends.kwallet.DBusKeyring

Once done, you should get something like this ...

$ python3 -c "import keyring.util.platform_; print(keyring.get_keyring().__module__)"
keyring.backends.chainer
$ 

@greenjeans:
That nails it, no more gnome-keyring in my system ...

$ apt list | grep installed | grep gnome-keyring 
--- snip ---
$ 

... and just the necessary keyrings:

$ apt list | grep installed | grep keyring 
--- snip ---
debian-archive-keyring/stable,stable,now 2023.3+deb12u2 all [installed]
devuan-keyring/stable,stable,now 2023.05.28 all [installed]
python3-keyring/stable,stable,now 23.9.3-2 all [installed,automatic]
$ 

Edit:
Just an update to confirm that BiT ran this morning's (05/08/25) daily cronjob without any issues.

Best,

A.

#187 Re: Devuan Derivatives » Keyring? » 2025-08-04 12:59:01

Hello:

Altoid wrote:

... only reason (I can come up with) is that BiT looks for a PW and does not find one.

And so it seems:
---------------------------------------------
Debian Bug report logs - #998105
backintime-qt: Fails to access the keyring with python3-keyring 23.2.0-1
https://bugs.debian.org/cgi-bin/bugrepo … bug=998105
---------------------------------------------

BiT should be able to work properly without gnome-keyring or keepassxc installed.

The problem seems to be (?) with how BiT looks for and finds (or not) a keyring to use.
For whatever reason, it does not find and select the installed python3-keyring, going for whatever else is available to use.

Which is why, instead of using the installed python3-keyring 23.9.3-2, it uses the installed (and otherwise unnecessary) gnome-keyring 42.1-1+b2.
Failing to run if I purge it.

Apparently there is/was (?) a patch but the bottom line is that (two years on)  the bug is still present in backintime-qt 1.3.3-4.

So much for my getting rid of all the gnome crap ...

Best,

A.

#188 Re: Devuan Derivatives » Keyring? » 2025-08-01 16:35:15

Hello:

greenjeans wrote:

... saying you haven't tried uninstalling it ...

No. 8^°
What I am saying is this:

I wrote:

... but if I purge it, BiT will not run properly.

ie: a statement of fact.

But further on (for clarity) I should have written this:

I guess (would have to purge gnome-keychain again to verify ...)

Sorry for being ambiguous, my command of the English language is rather lacking.

That said, the only reason (I can come up with) is that BiT looks for a PW and does not find one.

Thanks for your input.

Best,

A.

#189 Hardware & System Configuration » A glimpse of things to come? » 2025-08-01 09:31:54

Altoid
Replies: 2

Hello:

Rather worrying, I think.

------
Canonical dusts off TPM encryption for Ubuntu 25.10
Passwordless disk locking is coming, a couple of years later than hoped
By Liam Proven @The Register
------
https://www.theregister.com/2025/07/31/ubuntu_tpm_fde/

Liam Proven @The Register  wrote:

We also feel it's worth pointing out that GNU guru Richard Stallman is dead set against this stuff, and we tend to agree with him. As Edward Snowden put it: Stallman was right. "Trusted Platform" doesn't mean you can trust your computer, it means software vendors can trust the PC to prevent you from fiddling with it.

Cannot but wonder how long before we get this crap in Debian/Devuan.

Best,

A.

#190 Re: Devuan Derivatives » Keyring? » 2025-08-01 00:33:19

Hello:

greenjeans wrote:

Can you expand on that? What seems to be broken?

I guess (would have to purge gnome-keychain to verify) that it does not find the password to be able to do its job.

From what I gather, BiT is a user mode backup so it only does backup/restore operations on directories where the user has write access.
As it runs automatically (cron job) it needs the password which is (?) in the gnome-keyring.

Thanks for your input.

Best,

A.

#191 Re: Devuan Derivatives » Keyring? » 2025-07-31 21:59:51

Hello:

greenjeans wrote:

... gnome-keyring sucks. I uninstalled it. Then everything works.

Interesting.

I have it installed in my system because BackInTime recommends it.
It is a remnant of the time when I did not block recommended packages.

$ aptitude why gnome-keyring
i   backintime-common     Depends    python3-keyring                                       
i A python3-keyring       Depends    python3-secretstorage (>= 3.2)                        
i A python3-secretstorage Recommends gnome-keyring | libkf5wallet-bin (>= 5.97) | keepassxc
$ 

But I don't use it to store passwords, not at all comfortable with that.

But it happens that gnome-keyring is not a dependency for BackInTime but if I purge it, BiT will not run properly.
keepassxc is not a dependency either and it requires network access, so that would be a hard no for me.

See https://packages.debian.org/en/sid/backintime-common

It would seem (?) that BiT should be using python3-keyring instead of gnome-keyring for me to be able to purge it.

Any ideas on how to get that done?

Thanks in advance.

Best,

A.

#192 Re: Installation » Systemctl Daemon Reload » 2025-07-30 01:06:39

Hello:

Welcome to Devuan.

HardSun wrote:

... should these files even exist on a supposedly systemd free fork of debian?

I run Devuan Daedalus on my box:

$ uname -a
Linux devuan 6.1.0-37-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.140-1 (2025-05-22) x86_64 GNU/Linux
$ 

My system does not have systemctl installed.
No dependency requires it, but it is present in the repository and as such, it can be installed:

$ apt list | grep systemctl
--- snip ---
systemctl-service-shim/stable,stable 0.0.5-1 all
systemctl/stable,stable 1.4.4181-1.1 all
$
# apt install systemctl
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Suggested packages:
  tini | dumb-init
The following NEW packages will be installed:
  systemctl
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 79.8 kB of archives.
After this operation, 279 kB of additional disk space will be used.
Get:1 http://deb.devuan.org/merged daedalus/main amd64 systemctl all 1.4.4181-1.1 [79.8 kB]
Fetched 79.8 kB in 4s (18.3 kB/s)                 
Selecting previously unselected package systemctl.
(Reading database ... 165616 files and directories currently installed.)
Preparing to unpack .../systemctl_1.4.4181-1.1_all.deb ...
Unpacking systemctl (1.4.4181-1.1) ...
Setting up systemctl (1.4.4181-1.1) ...
Processing triggers for man-db (2.11.2-2) ...
# 

That said, I don't have much of an idea what it is used for in a systemd-less installation, but I suspect (wild guess) that it is/may be related to all the dummy/shim files Devuan uses to be able to run Debian packages which want to see indications of the presence of systemd to work properly. 
ie: a non-dependent dependency, if you will.

If you install it and run it as root from a terminal, you will get a printout with the list of dummy / shim files installed in your system with their status, some with a description of what they are used for.

eg:

# systemctl
.depend.boot.service	loaded inactive dead	
.depend.start.service	loaded inactive dead	
.depend.stop.service	loaded inactive dead	
README.service	loaded inactive dead	
acpid.path	loaded inactive dead	ACPI Events Check
acpid.service	loaded inactive dead	ACPI event daemon
acpid.socket	loaded inactive dead	ACPID Listen Socket
--- snip ---
connman-wait-online.service	loaded inactive dead	Wait for network to be configured by ConnMan
connman.service	loaded inactive dead	Connection service
--- snip ---
zramswap.service	loaded inactive dead	Linux zramswap setup

150 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
# 

Cannot say much more than that.

Best,

A.

#193 Re: Other Issues » [SOLVED] Strange directories in root » 2025-07-28 11:50:43

Hello:

FM81 wrote:

... two hidden dirs, named /.config and /.cache

See this thread: https://dev1galaxy.org/viewtopic.php?id=5596
There is a lot of information about /.config and /.cache there.

In my case, I solved it with this ...

# apt purge pulseaudio && apt autoclean && apt autoremove

... and then this: https://dev1galaxy.org/viewtopic.php?id=3904

The end result being this:

$ cat /etc/apt/preferences.d/avoid_pulseaudio
Package: pulseaudio:*
Pin: version *
Pin-Priority: -1
$ 

In your case, a bit more digging may be necessary.
Or not.

Please let us know how you fared.

Best,

A.

#194 Off-topic » Microsoft and data sovereignty » 2025-07-25 20:10:51

Altoid
Replies: 3

Hello:

From today's edition of The Register:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Microsoft admits it 'cannot guarantee' data sovereignty
Under oath in French Senate, exec says it would be compelled – however unlikely – to pass local customer info to US admin.
by Paul Kunert  @The Register
----------------------------------------------------------------------------------------------------------------------------------------------------------------------

https://www.theregister.com/2025/07/25/ … guarantee/

Paul Kunert wrote:

As proceedings continued, Carniaux was asked if in the event of an injunction that was legally justified, could he, as Microsoft director of public and legal affairs, "guarantee our committee, under oath" that data on French citizens could not be transmitted to the American government without the explicit agreement of the French government.

"No," said Carniaux, "I cannot guarantee that, but, again, it has never happened before."

The Register asked Microsoft to comment on this but it declined to do so.

So ...
What else is new?

Best,

A.

#195 Re: Installation » apport package » 2025-07-21 13:44:57

Hello:

I found some more info on this apport application:

https://nvd.nist.gov/vuln/detail/CVE-2016-9950
https://app.opencve.io/cve/?vendor=apport_project
https://security-tracker.debian.org/tra … -2019-7306

You will notice that Debian refers to all this as a non-issue because apport is not present.
Coming from the creators of systemd, I'll take it with a few grains of salt, low sodium variety.

Paraphrasing the Bard (of Avon, seems there are others):

                           An apport by any other name would still cause damage

So ...

Just to be on the safe side of whatever may be in there, Devuan users may want to consider purging everything in /usr/share/apport/*
But that's just me and my $0.02.

Best,

A.

#196 Re: Installation » apport package » 2025-07-20 23:16:28

Hello:

g4sra wrote:

... but selectively omitted from installation by a simple option in the package preinst script.

Yes, of course*.

*Good luck with that ...  8^°

Thanks for your input.

Best,

A.

#197 Re: Installation » apport package » 2025-07-20 23:09:41

Hello:

dpkg -S apport/package-hooks
$ dpkg -S apport/package-hooks
lxappearance: /usr/share/apport/package-hooks/source_lxappearance.py
pcmanfm: /usr/share/apport/package-hooks/source_pcmanfm.py
yelp: /usr/share/apport/package-hooks/source_yelp.py
libfm-data: /usr/share/apport/package-hooks/source_libfm.py
openssh-client: /usr/share/apport/package-hooks/openssh-client.py
connman: /usr/share/apport/package-hooks/source_connman.py
lxterminal: /usr/share/apport/package-hooks/source_lxterminal.py
pcmanfm, lxappearance, libfm-data, sudo, synaptic, simple-scan, openssh-client, libmtdev1:amd64, connman, lxterminal, cups-daemon, yelp, grub-common, libmtp-common, conky-all: /usr/share/apport/package-hooks
conky-all: /usr/share/apport/package-hooks/conky.py
grub-common: /usr/share/apport/package-hooks/source_grub2.py
simple-scan: /usr/share/apport/package-hooks/source_simple-scan.py
libmtdev1:amd64: /usr/share/apport/package-hooks/source_mtdev.py
sudo: /usr/share/apport/package-hooks/source_sudo.py
libmtp-common: /usr/share/apport/package-hooks/source_libmtp.py
cups-daemon: /usr/share/apport/package-hooks/source_cups.py
synaptic: /usr/share/apport/package-hooks/source_synaptic.py
$ 

All python scripts.
Fortunately I managed to weed them all out.
Will do the same on all my Devuan installations.

ralph.ronnquist wrote:

... classified as a technological remnant from a modular idea ...
... cushioning the end-user with "services" so they could go happy without knowing what they were doing.

And here we are, still with all this absolutely unneeded shit in a Linux system.
No wonder every new release brings about more and more (and more) code. 
All dirt swept under the rug, festering.

How much more of that is there to be found?

ralph.ronnquist wrote:

We all know better than that nowadays, don't we?

Yes, we is right.
Seems the pronoun does not include most (if not all) Debian devs.
Makes me wonder if they are not some sort of sleeper scripts.

As always, thanks for your input.

Best,

A.

#198 Installation » apport package » 2025-07-20 20:58:10

Altoid
Replies: 6

Hello:

While looking at the active threads, I came across this post by fsmithred:

fsmithred wrote:

To get a list of config files that have been changed from the default:

debsums -ca

I did not know about that package (thanks fsr!) nor did I have it installed.
Once installed, I ran it and got a good deal of data which I have always wondered about as I also keep an installation log of sorts but, never thorough enough.

The data included quite a bit of references* to a package named apport which I recalled having deleted from every instance found.
* most if not all in localhost/usr/share/apport/package-hooks

I purged it after I looked it up and decided it was not something I wanted running in my system.

https://github.com/canonical/apport wrote:

Apport intercepts Program crashes, collects debugging information about the crash and the operating system environment, and sends it to bug trackers in a standardized form. It also offers the user to report a bug about a package, with again collecting as much information about it as possible.

This was back in 05/2025, so it is still in my timeshift snapshots.

I had intended to ask here but forgot all about it till now.
I had a look today and could not find it in the Devuan repositories.

I did find that it was at one time in the Debian repositories:
https://tracker.debian.org/pkg/apport

Could it be that it is a zombie remnant from the original Devuan (jessie or ascii) installation which I dist-upgraded since then?

$ aptitude why apport
i   screen Suggests byobu | screenie | iselect (>= 1.4.0-1)
p   byobu  Suggests apport                                 
$ 
$ aptitude why byobu
i   screen Suggests byobu | screenie | iselect (>= 1.4.0-1)
$ 
$ aptitude why screen
i   screen   Suggests byobu | screenie | iselect (>= 1.4.0-1)
p   screenie Depends  screen                                 
$

I cannot recall having ever installed screen.  8^°
Moot point, purged it.

Q: Why did I have apport in my system if it was no longer* in the Devuan repositories?
* it was accepted in experimental in 09/2014 but finally removed in 03/2019. ie: over 10 years in experimental, never made it to stable after 05/2014.

Me thinks there should be some sort of mechanism (?) to post a notice about things like this when doing a dist-upgrade.

Thanks in advance.
Best,

A.

Edit:
My Devuan Chimaera VM has this without apport being installed:

$ locate apport
/usr/share/apport
/usr/share/apport/package-hooks
/usr/share/apport/package-hooks/openssh-client.py
/usr/share/apport/package-hooks/openssh-server.py
/usr/share/apport/package-hooks/source_grub2.py
/usr/share/apport/package-hooks/source_sudo.py
$ 

Same for my (default desktop install) Devuan Daedalus VM:

root@daedalus:~# locate apport
/usr/share/apport
/usr/share/apport/package-hooks
/usr/share/apport/package-hooks/openssh-client.py
/usr/share/apport/package-hooks/openssh-server.py
/usr/share/apport/package-hooks/source_apparmor.py
/usr/share/apport/package-hooks/source_cups.py
/usr/share/apport/package-hooks/source_grub2.py
/usr/share/apport/package-hooks/source_mtdev.py
/usr/share/apport/package-hooks/source_pulseaudio.py
/usr/share/apport/package-hooks/source_sudo.py
/usr/share/apport/package-hooks/source_synaptic.py
root@daedalus:~# 

Can anyone explain to me why this is so?
apport is not in the Debian / Devuan repositories.

.

#199 Re: Other Issues » I seem to crash when I go to a certain website... » 2025-07-20 17:05:23

Hello:

zapper wrote:

git.devuan.org is that website.

Was passing by and tried* it out:

Unable to connect

An error occurred during a connection to git.devuan.org.

    The site could be temporarily unavailable or too busy. Try again in a few moments.
    If you are unable to load any pages, check your computer’s network connection.
    If your computer or network is protected by a firewall or proxy, make sure that Firefox is permitted to access the web.

* 128.3.1esr (64-bit) without Pihole or uBlock enabled.

Best,

A.

#200 Re: Packaging for Devuan » Repackaging Debian packages » 2025-07-16 20:15:18

Hello:

SteveM wrote:

None of my packages are particularly important ...

I beg to differ.
Every bit of work contributed to Devuan Linux is important.

I have been using your TimeShift for the longest while, if I recall correctly, since ascii.

Best,

A.

Board footer

Forum Software