You are not logged in.
From mount(8)
nosuid Do not honor set-user-ID and set-group-ID bits or file capabilities when executing programs from this
filesystem.
...TRUNCATED...
noexec Do not permit direct execution of any binaries on the mounted filesystem.
I cannot find exactly the "noa," so it is probably either noauto or noatime.
noatime
Do not update inode access times on this filesystem (e.g. for faster access on the news spool to
speed up news servers). This works for all inode types (directories too), so it implies nodiratime....TRUNCATED...
noauto Can only be mounted explicitly (i.e., the -a option will not cause the filesystem to be mounted).
So you certainly need any partition that houses /usr/bin, /bin/, /sbin/, /usr/sbin/ and probably /usr/local/bin to NOT have "noexec." Those partitions should also NOT have "nosuid."
I feel uncertain about the "noa" because I cannot determine which one it is. "noatime" is generally used on ssds to reduce how many writes happen to the disk, to minimize wear and tear. And in the installer for a distro of Linux, you should never choose "noauto." That's generally for secondary disks that don't need to be there for boot up.
I'm no expert, but here's some general advice that you did not indicate if you already know.
Input device drivers for X11 are usually stored in packages named xserver-xorg-input-*, so xserver-xorg-input-wacom sounds like what you would want for just the raw input.
$ apt-cache search wacom
kde-config-tablet - implements a KDE configuration GUI for the Wacom drivers
libwacom-bin - Wacom model feature query library -- binaries
libwacom-common - Wacom model feature query library (common files)
libwacom-dev - Wacom model feature query library (development files)
libwacom2 - Wacom model feature query library
libwacom2-dbg - Wacom model feature query library (debug files)
xserver-xorg-input-wacom - X.Org X server -- Wacom input driver
What you could do on your Mint install is to look for what binary runs the graphical window of your tablet configurator, and see if we can find that in the Devuan repos. If nothing else, you could try the kde-config-tablet to see if that gets you what you want in a Devuan environment.
Er, yes, you can use dpkg-deb for that. This is not recommended, as noted above. But to extract the contents of a dpkg file (.deb), you can just
dpkg-deb -x file.deb /output/dir/here
You would probably have to add the extracted library path to ldconfig. So you would probably need a file, /etc/ld.so.conf.d/my-customized-firefox with contents:
/output/dir/here/usr/lib/
And then run ldconfig.
DISCLAIMER: I have not done this, and officially you shouldn't be doing this at all, for several reasons: 1) Super-old firefox. 2) Customizing your ld path is something you should do when you really, really know what you're doing and if you did, you probably didn't need our help for this task.
Wow, that one is ideal! I wish I had thought of it. I migrated through the Xfce DE and didn't even think of that one. Xfce's applications are really neat. I successfully installed xfce4-settings and it didn't bring in the entire desktop environment. It only brought in a few things for this one application.
What I had found on the Internet at large is https://github.com/i026e/mime_types_editor which is written in GTK3+ and Python3.
Hello d1ers, I want to solicit recommendations and advice about a graphical mimetype association editor. It doesn't have to be xdg-specific, but using the xdg stuff would be great.
I have found a few projects online and can discuss my findings here, but before I try to build dpkgs for these third-party applications, I want to know if there's already something here I couldn't find on my own with `apt-cache search mimetype` which didn't return much.
Of course I can go edit associations on the command line, but sometimes I am lazy and I do want to just point-and-click.
Well, are you looking to just disable the screensaver completely? Just remove xscreensaver from whatever startup scripts or xdg autostart type stuff you have.
If you want it disabled only when running kodi, you could investigate running the command
xscreensaver-command -deactivate
periodically somehow.
I found that at https://wiki.archlinux.org/index.php/XS … a_playback, which had other ideas. It looks like Arch Linux also bundles up https://github.com/graysky2/kodi-prevent-xscreensaver which is really just a shell script which runs the above command every so many seconds.
Wow, what was wrong with globbing? My friend moving to FreeBSD doesn't have to deal with bad decisions like this. (FreeBSD has their own bad decisions...)
Do a reality check. Does the audio work in other programs? Does the audio work on other sites. Do the speakers or headphones work when plugged in to another system that plays sound? Also, sometimes I get confused about how many different levels to set in the various mixer programs. Maybe there's a different slider you need to adjust as well as master.
I have no input for you regarding slim; I'm sorry.
What I do know about is using lightdm with elogind. Another forum user already found the solution: HOWTO: lightdm (with libpam-elogind) + xfce4 (ASCII/Stable) / Documentation / Dev1 Galaxy Forum
My current solution, derived from the above link:
#!/bin/sh
# Reference: https://bgstack15.wordpress.com/2019/09/01/devuan-with-lightdm-and-xfce-will-not-let-user-reboot-or-shutdown-from-user-session/
# Startdate: 2019-08-11
# only for devuan ceres
sudo apt-get install --no-install-recommends libpolkit-backend-elogind-1-0 policykit-1 lightdm lightdm-gtk-greeter
sudo sed -i -r -e '/session\s+optional\s+pam_systemd\.so/s/systemd/elogind/;' /etc/pam.d/lightdm-greeter
The branding of the ISO file was updated sometime after the devuan_ascii_2.0.0-beta_amd64_DVD.iso, so that it shows "Devuan GNU/Linux" as shown below.
$ isoinfo -J -i devuan_ascii_2.0.0-beta_amd64_DVD.iso -x /.disk/info
Debian GNU/Linux 2.0.0-beta "Ascii" - Official amd64 DVD Binary-1 20180213-18:54
$ isoinfo -J -i devuan_ascii_2.1_amd64_dvd-1.iso -x /.disk/info
Devuan GNU/Linux 2.1 (ascii) amd64 DVD1 - 2019-12-21 07:24:54 UTC
When this branding changed, virt-install could no longer identify this iso file as a Debian (or derivative) distro, so it could not pull from a built-in list of initrd and kernel files to load.
On my virtualization server (CentOS 7, virt-install-1.5.0-7.el7.noarch), I patched /usr/share/virt-manager/virtinst/urlfetcher.py to handle a Devuan disc.
--- /usr/share/virt-manager/virtinst/urlfetcher.py.2020-02-20.01 2020-02-20 21:06:53.515076802 -0500
+++ /usr/share/virt-manager/virtinst/urlfetcher.py 2020-02-20 21:41:17.649056883 -0500
@@ -1279,6 +1279,33 @@
logging.debug("Didn't find any known codename in the URL string")
return self.os_variant
+class DevuanDistro(DebianDistro):
+ name = "Devuan"
+ urldistro = "devuan"
+ def _is_install_cd(self):
+ # For install CDs
+ if not self._check_info(".disk/info"):
+ return False
+
+ if self.arch == "x86_64":
+ kernel_initrd_pair = ("linux",
+ "initrd.gz")
+ elif self.arch == "i686":
+ kernel_initrd_pair = ("install.386/vmlinuz",
+ "install.386/initrd.gz")
+ elif self.arch == "aarch64":
+ kernel_initrd_pair = ("install.a64/vmlinuz",
+ "install.a64/initrd.gz")
+ elif self.arch == "ppc64le":
+ kernel_initrd_pair = ("install/vmlinux",
+ "install/initrd.gz")
+ elif self.arch == "s390x":
+ kernel_initrd_pair = ("boot/linux_vm", "boot/root.bin")
+ else:
+ kernel_initrd_pair = ("install/vmlinuz", "install/initrd.gz")
+ self._hvm_kernel_paths += [kernel_initrd_pair]
+ self._xen_kernel_paths += [kernel_initrd_pair]
+ return True
class UbuntuDistro(DebianDistro):
# http://archive.ubuntu.com/ubuntu/dists/natty/main/installer-amd64/
It looks like upstream virt-manager has moved in from virt-manager 1.5 and has refactored the code, but file https://github.com/virt-manager/virt-ma … ldetect.py is the one that could be patched to include Devuan disc info.
Do you expect that the initrd and kernel file names on the install media will be stable? I would not mind submitting a patch to upstream. I have no relationship with them, but I want Devuan to be easier to install on virtualization platforms!
Don't bother with wicd, it's crap.
I have good success with wicd. I have used NetworkManager before and it was OK. I think I even successfully used NM to connect with those complicated auth schemes like EAP v2 (that AD RADIUS auth stuff) but that was back in my Fedora days.
While /etc/network/interfaces is fine with me, and I prefered the old Red Hat /etc/sysconfig/network-scripts because it was shell scripts, I have found wicd-cli and wicd-gtk quite sufficient!
What do you dislike about wicd?
Woops, I got this too, in an Ascii 2.0 installer. Guess I need to get the latest install media. I did remember that something was up with the "us.deb.devuan.org" stuff so I picked pkgmaster...
Wow, those are pretty! Now I think I'm going to make my login manager wallpaper that...
I am not an expert, nor do I have any say in what Devuan does as a community. As I understand it, Devuan exists as a systemd-free fork of Debian. Debian uses the Linux kernel (primarily), so that's what Devuan will use.
The idea of using Rust in the kernel sounds really scary to me, if only because of the fast-moving nature of that project/language. I compile Waterfox (based on Mozilla Firefox) on a regular basis, and half the time, the project fails to compile because it has not been updated yet for the latest version of rust, or it has been updated and my distros (not just Devuan) are not yet up-to-date on Rust packages.
I think the switch of Hyperbola to a BSD base is amusing, because Project Trident is switching to the Linux kernel (Void Linux distro) from FreeBSD (TrueOS). But I'm glad all these projects feel that the switch is feasible.
I thought the comments from Rick Moen, Simon, and Steve Litt the most useful parts of the whole page.
I could see this alternative alternatives thing being adapted by other distros, say, ones that claim to "support exploring alternatives" (no pun intended, haha).
And I think it's cool that he's working on POSIX shell for everything. Portability is great. However, in my own recent experience, shell speed is an order of magnitude slower for certain things like text parsing, than python. There's a reason some things are written in real programming languages...
Does anyone have any experience to share, about if the kiss package manager is faster than yum?
With the Red Hat purchase a year or two ago of CoreOS, the team behind Container Linux (formerly known as CoreOS), the release of Fedora CoreOS is now public!
Fedora CoreOS out of preview - Fedora Magazine
I dabbled with Container Linux at work for a month. It was kinda meh. It seemed pretty clear at the time that they had some original ways of doing things that they wrote, but those ways were being displaced by the "current trend." Like their own configuration for most things was slowly being supplanted by cloud-init. Each has their benefits and weaknesses. And, not everything in cloud-init was supported by Container Linux.
So, the linked article above refers to how the new Fedora CoreOS (the name throws back to the original name of the Fedora Core distribution) is configured for networking: Network Manager key files! So the age-old tried-and-true Red Hat method of /etc/sysconfig/network-scripts/ifcfg-eth0 is out. Even the systemd network configuration is out (never even knew that was a thing, but totally not surprised)! Perhaps mashing everything together in our nifty /etc/network/interfaces could have used a nice dot-dee makeover (and probably has; shows you how little I configure networking these days), but hot diggity, how many netconfig tools are there!?
I know the Red Hat distros made Network Manager required for anything fancier than a single IP address on a single network card. Thankfully, 99% of my work environment was single IP address on single nic.
I had the displeasure to learn about the Ubuntu netplan (yaml-based) network configuration tool, which aside from the silly whitespace problem, maybe wasn't quite so terrible. It's just a NIH solution looking for a problem.
Man, I really like the wicd network configuration tool! Coupled with a choice of dhcp client (dhclient, of course), wicd is lightweight, cross-distro, and does exactly what you want it to do. Devuan is great, because it's Debian with an init system that does only init system tasks. The user can choose each and every tool.
I'm hardly technical in this regard, but to expand on what golinux just said, elogind helps manage user sessions, primarily for X desktop applications' ability to log out/shut down/etc.
My mom actually still uses Thunderbird. I expect it's seriously out of date. Anyway, I think TDF would be a great organization to maintain an email client!
Would there be interest in the Devuan community for a maintainer of an xdgmenumaker dpkg? I like it enough that I am willing to read through the process for how to be a maintainer, and volunteer to participate if I can agree with all the T&Cs, if there is enough community desire for the package.
In the mean time, I've built it on my OBS: https://build.opensuse.org/package/show … gmenumaker if people want an easy download. My package adds a trigger on /usr/share/applications, and a corresponding postinst script:
#!/bin/sh
# xdgmenumaker postinst
case "$1" in
triggered)
Xvfb :18 &
result=$!
export DISPLAY=:18
for word in fluxbox ;
do
/usr/bin/xdgmenumaker -f "${word}" -i > "/etc/xdgmenumaker/${word}" 2>/dev/null
done
kill $result
;;
*)
:
;;
esac
Which could easily be adapted to just run for any set of WMs.
A weakness this has, is that it is run as root, and therefore will not make a single suitable fluxbox menu file that also reads the users' $XDG_DATA_DIR or similar values. So in my ~/.fluxbox/startup file I have:
/usr/bin/xdgmenumaker -f fluxbox -i > ~/.fluxbox/xdg-menu &
And of course in ~/.fluxbox/menu
[begin] (fluxbox)
[include] (.fluxbox/xdg-menu)
#[include] (/etc/xdgmenumaker/fluxbox)
[include] (/etc/X11/fluxbox/fluxbox-menu)
[end]
So related to undoing more poor choices made by the GTK3 toolkit, I prefer my scrollbars to be as solid as I am. Thank you for the nooverlayscrollbars thing. I didn't see such a file in the clearlooks-phenix-cinnabar-theme or gtk3-nocsd packages.
I don't mind dropping something in a ~/.profile for myself; that's easy enough. I just didn't want to have to build a package like the gtk3-mushrooms thing earlier. So I don't necessarily need a fancy Xsessions.d/ file, I can just implement the shell variables for myself.
We have a gtk3-nocsd package?! A few months ago I spent a little bit of time drooling over gtk3-mushrooms but gave up because I have a large fleet of systems and I don't want to do one-offs.
This gtk3-nocsd thing is inspiring! Thanks.
https://simon.shimmerproject.org/2020/0 … 5-updates/
The Xfce devs have started work on the unstable version 4.15 in preparation for their 4.16 milestone. They are beginning to use client-side decorations for some of the main Xfce applications.
I personally feel that CSD turns Xfce into a Gnome knock-off. While I appreciate GTK because it makes more sense to me than QT (the underlying libs for KDE), if following GTK means dropping window manager control of window control functions and moving to client-side decorations, I guess I'll move on.
Eh, I was moving on to a more minimal Fluxbox (and less dbus) anyway.
Also, help2man sounds legit! I have conducted a brief Internet search and don't see any debhelper guidelines for help2man. I found https://salsa.debian.org/reproducible-b … it/075d944 as an example, so it looks like one just uses help2man manually in a Makefile (or perhaps rules)?
Actually, this tool will transform how I write my --help screens... who doesn't want an auto-generated man page?! Regardless of whatever happens with this systemdtl abomination, help2man is a definite positive thing I've learned.
Ah, I realize the script is complex, and has a dependency, so you probably wouldn't have installed and tried it. The script does output some stuff when you run "sudo systemctl --help." It's hardly a standard GNU coreutil --usage page, but it shows something. And it's my standard boilerplate with only one line added so it's not even demonstrating the correct verbiage.
Would you please file some bugs against the project on gitlab? Otherwise, I'll do it.
And, since you brought up lintian, is there some package I should be using for builds on a Devuan box, so that I don't get this error?
Now running lintian systemdtl_0.0.1-1+devuan_amd64.changes ...
Could not find a profile matching "{VENDOR}/main" for vendor devuan
Lintian::Profile::_find_vendor_profile(Lintian::Profile=HASH(0x55d82ca5b490)) called at /usr/share/perl5/Lintian/Profile.pm line 140
Lintian::Profile::new("Lintian::Profile", undef, ARRAY(0x55d82a4852d0), HASH(0x55d82a7ba3a0)) called at /usr/bin/lintian line 216
dplint::load_profile(undef) called at /usr/share/lintian/commands/lintian.pm line 751
eval {...} called at /usr/share/lintian/commands/lintian.pm line 751
main::main() called at /usr/bin/lintian line 46
eval {...} called at /usr/bin/lintian line 46
main::__ANON__("/usr/share/lintian/commands/lintian.pm") called at /usr/bin/lintian line 115
dplint::run_tool("/usr/bin/lintian", "lintian") called at /usr/bin/lintian line 291
dplint::main() called at /usr/bin/lintian line 375
I already tried
$ apt-file search /usr/share/lintian/profiles/devuan
$
EDIT:
Huh, I found devuan-lintian-profile which adds such a directory. Let me guess, apt-file has a cache that needs to be updated just like apt-file?