You are not logged in.
I'll try asking on the Ventoy forum
It's both polite and helpful to provide links when cross-posting:
https://forums.ventoy.net/showthread.php?tid=2722
If you also added a link to this thread there, it would allow Ventoy people to see the things posters here have suggested/tried, which can both save them repeating what has already said, and may help diagnosing the issue.
Repository versions are at https://pkginfo.devuan.org/firefox-esr
As one can see, 102.15 is current daedalus version for people who do not have daedalus-security enabled - most people should be on 115.4.0esr-1~deb12u1 - note that's deb12 not deb10!
The "oldoldstable-security" repository is not for Daedalus, it is for Beowulf (and should be referred as "beowulf-security").
Anyone unclear on what their repositories should look like should read https://www.devuan.org/os/packages
Uh... 68M is the directory size? There's two kernels in there.
Stock: 7.7M kernel + 37M initrd = 44.7M
Custom: 5.3M kernel + 14M initrd = 19.3M
Anyone excited by that may also want to check out TinyCoreLinux.
It was called gummiboot before. I don't know why they added it to the systemd. Anyway, is it possible to install that?
...It's not even related to systemd in any way. Why do this? I don't get it...
Systemd might primarily be the work of Lennart Poettering, but he did it in close collaboration with Kay Sievers.
Kay Sievers is the developer who created Gummiboot, and the same person who back in 2015 merged it into systemd, (whilst blanking the gummiboot repository and 404ing its webpage, instead of the standard practice of redirecting or posting suitable migration notices).
(Kay Sievers is also the one who Linus Torvalds banned from the kernel for repeatedly submitting buggy code and refusing to fix it.)
It is entirely unsurprising that Kay would make his project part of systemd.
-
If there is actually a benefit to gummitboot/systemd-boot over the various other options then the correct thing to do would be fork it and create an independent package unrelated to systemd - that is what Gentoo developers did with eudev when udev got merged into systemd.
-
My comment was related exclusively to your asserting that Debian supports all packages in its repositories, installed by default or not.
You are misinterpreting what I wrote. I attempted to clarify, there was no emphasis on "all" (which does not even exist in what I wrote), but should have been emphasis on "by Debian" - with an implied "not Devuan", because Devuan only support the packages that they have created or modified - i.e. packages which do not exist in the Debian repositories, because they are only in the Devuan repositories.
To repeat: I mistakenly didn't put suitable emphasis on "by Debian". What I apparently should have written there is:
Any package you find in the Debian Stable repositories is supported by Debian - where "supported by Debian" means it belongs in Debian's bug tracker not in Devuan's bug tracker - it doesn't matter if it is installed by default what matters is whether it was modified by Devuan or not; that is the factor which decides which bug tracker it goes in.
How individual Debian maintainers may or not handle reports where the presence/absence of systemd affects an issue does not change this and is not relevant to the point I was making, which was about where to report issues.
-
To hopefully un-derail the thread, I'll note that I wrote what I did to reassert the point that ralph made, in response to the subsequent uncertainty of l3u:
I'm not sure if the Debian guys would be very interested in me filing a bug about the (non-Systemd) start-stop-daemon should be the one from another Distribution that provides the init system not being used upstream …
Bugs in a package should be reported to those who maintain that package.
Devuan users are more likely to use OpenRC, discussing OpenRC issues is on-topic here, but Devuan does not maintain the OpenRC package, so for bugs to be fixed they need to be reported to those that do maintain it.
The situation in that example is not the same as the situation here. Boyuan didn't request it be reported upstream because they were not interested in having the bug fixed, but only because they lacked the ability to diagnose the issue themself.
And since "downgrading to normal" is not "closing as wontfix" that example is not counter to the assertion, (even if it lacked suitable emphasis). There may well be other examples that are (such as when a package is orphaned), but the point is: software in the main Debian repository is, by its presence in that repo, supported by Debian.
Software which instead comes from the Devuan repos - because it has been modified by Devuan - is not supported by Debian, and should first be reported to Devuan (via bugs.devuan.org) not to Debian. (If necessary, the Devuan team can refer it to the Debian maintainer of the unmodified package.)
In this example, given the issue appears to be with OpenRC, we know (by virtue of it being an independent init system) that there is no dependency on systemd, and thus it wont need a Devuan-specific package, and so the place to report it is to Debian's OpenRC maintainers, via bugs.debian.org/openrc
Any package you find in the Debian Stable repositories is supported by Debian - it doesn't matter if it is installed by default.
Since OpenRC is available for Debian Stable and is not modified by Devuan, issues with it should be raised with Debian at //bugs.debian.org/openrc
//packages.debian.org/bookworm/openrc
//pkginfo.devuan.org/cgi-bin/package-query.html?c=package&q=openrc=0.45.2-2
Not on any Devuan team, not a dev/maintainer/packager either.
Nevertheless, I sent the people at Distrowatch an email.
Thanks for taking the time with all that - a disappointing attitude from DistroWatch. :(
That said, I have not seen/found which page of the Repology site says anything about Devuan and systemd so I did not address the matter with them.
I think it was noted in a thread about a German news/blog article - actually, it looks like it occurred in that thread golinux linked.
-
I think this thread can be marked as solved.
I don't, because it isn't (yet).
Despite their poor attitude, I doubt the DistroWatch team would deliberately do something different for testing/unstable, yet there is clearly a difference which causes systemd version numbers to appear in those columns and not for the released versions.
So they are getting 254.5 from somewhere, and checking the search results, there is one package in ceres/excalibur that is not in daedalus or earlier:
https://pkginfo.devuan.org/cgi-bin/pack … ev=254.5-1
https://packages.debian.org/sid/systemd-dev
This package contains the systemd and udev pkg-config files. Note that these are different from the libsystemd's and libudev's pkg-config files, which can still be found in the respective dev packages, but instead provide data such as the installation directories for units, and more.
I suspect if systemd-dev gets added to Amprolla's banned package list, the next DistoWatch update would return to showing hyphens for all columns.
Is it possible for Amprolla to automatically blacklist anything matching ^systemd- and/or with Source: systemd, and require a manual override for the rare situations in which such a package is necessary?
(I'm not entirely convinced there is actually any such situation; seems to me libsystemd0 could be replaced with a dummy/stub from a Devuan-controlled package, but that's probably a separate topic.)
There was a similar thread a little while back about Repology claiming Devuan contained systemd. Checking Repology just now, it is still making that claim.
Perhaps someone from the Devuan Team can reach out to Repology and DistroWatch to help them identify why they are saying that and resolve whatever bugs are responsible?
Here's the article link and a bit of information...
//www.theregister.com/2023/10/10/linux_gnome_libcue_exploit
Researchers discovered a high-severity remote code execution (RCE) vulnerability in an inherent component of GNOME-based Linux distros, potentially impacting a huge number of users.
Tracked as CVE-2023-43641, exploiting the vulnerability in the relatively small libcue library takes advantage of the tracker-miners application to facilitate a one-click RCE attack.
The issue is thought to affect all GNOME-based distros, including RHEL, SUSE, and Debian, but has only been proven to work on the latest versions of Ubuntu and Fedora so far.
A user just has to download a file and have it stored in a commonly scanned directory, such as the downloads, music, or videos folders, and the attacker can achieve RCE on their machine.
Debian/Devuan security status: //security-tracker.debian.org/tracker/CVE-2023-43641
I've got to evaluate the strings of weekdays in Gnumeric- Mon, Tue, Wed, Thurs.... - and IF it is Sat OR Sun the result should be "0" or else it should be "1".
So why are you not doing exactly what you said?
i.e. Using OR and testing that the cell is Sat or that the cell is Sun, rather than over-complicating things with inequality!?
Except you probably don't even need to do this manually...
It's a work schedule and it's keeping track of my days worked, hours, salary and stuff for each month. The week days are listed in a column.
There are already functions to work with WORKDAYs, or to tell you the NET WORKDAYS - i.e. the number of workdays in a range, remembering that a range can have a length of one, if that is actually necessary.
As usual. we'll see a patch/fix in no time at all.
The patch was already released through the security repos a day before the article.
Since Devuan is Debian with systemd removed, all packages available for Debian are already available in Devuan, unless they rely on systemd in a way which cannot be resolved (or maybe can be but hasn't yet).
There is no need to manually install a deb file for packages that exist in Debian.
^ Except replace "100C" with "the maximum operating temperature listed in the hardware manual" (or the value of "crit", if the sensor happens to provides that).
Allowing the existing filter lists to update seemed to have solved the problem here - no upgrading nor adding new filters required.
Anyone else found this? Perhaps there is a uBlock Origin update to counter it?
Yes, but not all videos - black screen appears; I mute the audio (shortcut M) until the skip button appears (after 5 seconds).
Searching the uBlock Origin issue tracker reveals it to be a common issue:
//github.com/uBlockOrigin/uBlock-issues/issues?q=youtube
It isn't clear from the "ALL youtube.com issues #7636" whether it needs a fix via uBlock Origin or via the filters or both.
-
I will stop using YT is this goes on.
Statements like that are meaningless. Even if YouTube saw it, they don't care.
Irrespective of what happens in the browser, you can always use yt-dlp to download the videos, bypassing any in-browser advertising, and play the video offline.
I did a KDE Plasma install with --no-install-recommends once.
The result was useless.
It still gave me numerous packages I absolutely did not need, and it took me a while to figure out the reason a bunch of things were not working was because several actually useful packages were mis-labelled as recommends.
-
It would be nice if package maintainers were required to state why something is recommended/suggested, so that people could make informed decisions about when to include/exclude them, (and maybe get the maintainers to think a bit harder about which level a dependency belongs in).
I tried to lookup at the debtree for kde-plasma-desktop but it timed out, and now pkginfo.devuan.org is returning 504 Gateway Time-out even for simple package lookups - I guess the KDE dependencies were too complicated and something crashed or locked up?
-
Anyway, what does apt rdepends systemd-coredump return?
Probably drkonqi ("Crash handler for Qt applications"), which plasma-workspace depends on.
Bullseye/Chimaera version of drkonqi didn't require systemd, but seems Bookworm/Daedalus version might:
https://packages.debian.org/bullseye/drkonqi
https://packages.debian.org/bookworm/drkonqi
According to the banned package list, both systemd and systemd-coredump is banned for "daedalus" and "daedalus-proposed-updates" but not "daedalus-security" and "daedalus-updates" ?
So Alex having the daedalus-proposed-updates repo enabled may explain the difference, though not clear why systemd packages are not banned for ALL repos?
It's a lot.
And to get an idea of how much a lot...
awk '$1=="Size:" {qty+=1;size+=$2}
ENDFILE {print "qty: "qty,"size: "size,"(~"int(1+size/1024^3) "G)","file:" FILENAME}
' /var/lib/apt/lists/*Packages
No point downloading an entire repository when the most common stuff is in the 4GB "desktop" ISO, and that can be supplemented with other necessary packages in various different ways.
I would possibly start with reading //blends.debian.org/blends
You'll be waiting a long time unless you actually provide details on what you are trying to do.
Your Bluetooth would seem to be working.
How to use it is different for attaching a mouse/keyboard, or transferring files, or playing audio via a speaker, or receiving GPS data, or ..., etc.
Again, we cannot read your mind - you need to provide details (both in the title and first post) rather than have people squeeze the information out of you.
A search that combines "bluetooth" with "xfce" and whatever you're actually trying may well provide the answer - if not, detail what you're trying, and where you're stuck. (If you're following any guides, include the links; but beware guides for Ubuntu or Arch which may be common but may do things differently to Devuan.)
DistroWatch also provides the ability to review and rank a distro and reports the averages of the ratings.
In that ranking, when limited to distros with over 100 reviews, six of the top ten are non-systemd distros:
1 Void
2 Devuan
3 Artix
4 Arch
5 TrueNAS
6 Slackware
7 Debian
8 Mint
9 openSUSE
10 Q4OS
Although, since ~75% of them have a "Most Frequent Rating" of either 10 or 1, they're clearly not objective/reliable ratings... *shrug*
DistroWatch is working exactly as it should/describes:
The following distributions match your criteria (sorted by popularity):
They simply show the number of times a distribution page on DistroWatch was accessed each day, nothing more.
So it isn't necessarily a meaningful stat, but at the same time it probably encourages people to go for distros higher in the list.
The correct conclusion is not that the search results are wrong, but that Devuan does not have enough people interested in it.
A bigger problem may be the general lack of popularity of any non-systemd distros - because, given MX Linux supports sysvinit or systemd, there are actually none in the top 10...
Start by running inxi --system --bluetooth --extra 3 (or inxi -SExxx) and showing the results here (within [code]..[/code] tags to preserve formatting).
If inxi isn't installed, install it. You may need to be root to get bluetooth info, and you can also try rfkill list as root to confirm the hardware is active.
about:preferences is a user-friendly front-end, for the real settings, check about:config and/or the prefs.js file in the profile directory (which gets updated when you exit the browser).
Also check whether there's any "safebrowsing" crap that's blocking it?
A quick search reveals the main setting is (should be) a three option radio group, looking something like this:
https://assets-prod.sumo.prod.webservic … a011a8.png
The documentation also shows how to configure the per-site setting, which has an explicit On/Off drop-down:
//support.mozilla.org/en-US/kb/https-only-prefs#firefox:linux:fx102