You are not logged in.
Don't use connman
how about using
sudo reboot ; exitGood.
Development like that would happen in git.devuan.org/devuan/documentation with normal fork+change+merge activity.
Thus, 1) register there; 2) fork the project, 3) start a branch.. perhaps named wip/excalibur (but naming could well be discussed); 4) edit; 5) make merge requests to the source project.
There is no magic involved.
Installers that are fully contained within their initrd will be fully loaded by ventoy from their ISO files, and "work" provided that they don't require access to their media.
Installers that require access to their media will not have that access, because the media is not available as partitions with ventoy.
If such an an installer is made to look for a ventoy partition, to mount that filesystem, to search for their ISO among the collection of ISO image files, then it may well also work.
Good. I suppose that error code "-19" means something particular but I don't really know how to find out what. You might want to drop in to the #devuan IRC channel on lilbera.chat where you're likely to find people that knows about graphics.
Does the user that starts Xorg have due access to /dev/dri/card0 ?
You'll need to install hostapd and read through its documentation.
A next option if indeed the "59" package does provide the required ABI could be to use equivs and set up a dummy "58" package so as to make apt happy (believing the "58" package is installed).
Your equivs package, which takes a small amount of effort, would be void of content and only have the meta information declaring it to provide libavformat58 and depend on libavformat59.
In that way you would implement that claim that your "59" package provides whatever is required from the "58" package.
@Altoid, did you try installing when adding/keeping a chimaera sources.list line (in addition to daedalus)? or does that raise conflict with the "59" package?
Thanks for your concern. Let us now and henceforth round up the nonsense and only post things likely to be of more general interest.
I hope all my posts look interesting ![]()
Possibly i you get the initial grub splash screen, you might try using E, C or ESC to enter grub command line and ther type "exit" and ENTER.
Please, if you are posting links, then post links. Otherwise it's just an illegible mess of characters.
Please use "code" block around code and log files.
The way to find out is to use strace, focussing on the open or openat system calls and reducing it to the files concerned. Something like
$ strace -f -s 200 $program | sed '/open/!d;s|[^"]*"||;s|".*||' | sort -uwhere $program is that program that handles the mouse click... your file browser(?).
EDIT: However if the click handling program farms out the decision logic to some dbus activated something, it breaks the call chain and becomes slightly more complext to trace. You might then need to trace dbus to work out where the decision logic is sited, and then set up a way to strace that.
@alexkemp; late evening perhaps ![]()
Please check /etc/default/dbus again (which indeed is different from /etc/init.d/dbus).
I had a quick look and apparently neither of mx1 or mx2 of your domain are in the domain's spf.
Aren't those the mailout hosts? Or should spf include an "a" or its ip to indicate itself, if that's your mailout host (and host ...7 doesn't have rdns)
You might want to use the following setup variant:
First, create or edit /etc/wpa_supplicant/wpa_supplicant.conf to have 2 initial lines like this:
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1Secondly, change /etc/network/interfaces for wlan0 to read like this
auto wlan0
iface wlan0 inet manual
wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcpThirdly, add the user to the group netdev.
Then that user can operate the wlan0 connection with wpagui (which you might need to install), and all details for networks that they connect to gets saved in /etc/wpa_supplicant/wpa_supplicant.conf, to be autimatically re-used upon roaming... (it's also possble for you to enter that beforehand with a text editor, but the file is also updated by wpa_supplicant. See man wpa_action for details).
EDIT: Note that there are two iface blocks for wireless in this setup. Firstly the wlan0 block that registers it to wpa_supplicant via the wpa_roam setting, telling the name of the connection database file to use. Secondly a default block that wpa_action uses for configuring the interface. Note that "default" is the name of that block.
EDIT 2: Technically this solves the issue of running a dhcp attempt too early to the wrong network by the wireless setup being broken up into two phases. The first phase happens on boot, where the interface is brought up to link level. That enables wpa_supplicant to scan for available networks. The interface is thereafter raised to ip level when wpa_supplicant discovers a network it has connection details for, and then dhcp is used (as configured by the default iface block) with the approrpiate link encryption for aquiring the network address(s) etc.
This setup also allows for static (rather than dhcp) network configurations to be made for individual networks. You do that by other specially named iface blocks to identify the concerned connections. See the man page if you need that.
Yes, the files in /var/lib/apt/lists are the package index files, and the Priority in those is a categorical grouping of packages that is something different from Pin-Priority.
(see my previous reply that overlapped yours)
Sorry, I replied before I saw your edit... hmm.
According to man apt_preferences there is an automatic priority of 990 to the versions that belong to the "target release", which would be declared in /etc/apt/apt.conf or some file in /etc/apt/apt.conf.d by a line like APT::Default-Release "stable";
Comment out that line (with initial #)
You have an explicit Pin-Priority of 990 for daedalus in some /etc/apt/preferences.d/* file.
Use apt-mark showhold to check if it's held or not.
/etc/apt/preferences.conf and files in /etc/apt/preferences.d/ define preferences.
And apt-cache policy openssh-server would tell about pinning as well.
Pointing your broswer at https://pkginfo.devuan.org/openssh-server you'll see all currently available versions of the package and the repository points they are found in.
Do you have a hold on the package, or some blocking preferences? It should update.
See also https://www.debian.org/releases/proposed-updates for some new and relevant information.
EDIT: hmm pkginfo favours amd64 ... that might not be ideal for you...
however, armhf has the same versions in the same repositories, at least for openssh-server.
You may want to include daedalus-proposed-updates in your sources.list
as well as daedalus-security