You are not logged in.
It may be less than known and understood, but in fact almost anyone may register at git.devuan.org and use it as repository for their public projects. If it's aimed at sharing, then documentation is essential.
When you have a binary package to publish you may drop in at #devuan-dev (at libera.chat) to discuss how that may happen; although first and foremost of course you'd publish your package to Debian. Though in some cases it may be warranted to have a trial publishing at Devuan/experimental.
you need to add a parameter to qemu so that it attaches its "monitor" to either a socket that you can connect to, OR as multiplexed with the serial console.
For the first option, you add the qemu command line arguments -monitor unix:QEMU,server,nowait, and thereby get its monitor serving the socket QEMU in the working directory. You then connect to that via socat with a command like the following
socat -,escape=0x1c,rawer unix:QEMUwhich sets up a raw termnal connection to that monitor; you break the connection with key ctrl-\ (control-backslash).
For the second option you instead modify (or add) serial line arguments to be -serial mon:stdio, and thereby get multiplexed monitor and serial console on the run terminal. In that case it starts in serial mode so you need to press ctrl-a c to switch to the qemu monitor.
Then, once you have the monitor, you will issue the commands like sendkey ctrl-alt-f2 etc so as to make the monitor send that key.
hth
opinions are fun, aren't they? One can have any number of them, and there are still more to collect.
And I agree with some that it's time to close this thread.
We'll stop here.
Mmm; it's rc-update that complains.... That's a different place with kindof the same structure.
I'm guessing you have two files in /etc/init.d where one says it provides "udev" and the other that it provides "$udev" (where the latter is a virtual service name). Probably you don't need both, perhaps it's a matter of keeping "eudev" and moving away "udev" from there.
The first step here is to realize that "packages" implement "functions" (or "facilities", or "virtual services").
Often, most usually, and as normal case, the "function" name is impliedby the package that implements it, so that every package automatically and implicitly provides its function. (That's how language works, isn't it)
Like, the package "udev" provides the function "udev".
However some packages are declared to *provide* aditional functions, such that for example package "eudev" provides "udev"; that is simply the promise for the dependecy system that when you install "eudev" you'll get all API and ABI that is originally provided by "udev".
It's not an uncommon or new thing, and I can't answer why dpkg lodges an error message for it. That whinging is new to me. Possibly it just whinges about that your system has both "udev" as a package and some other package, perhaps eudev, that is declared to provide "udev". Though I'd be eager to learn better or more exactly about this.
How does the installer say that? I.e. in what way?
If you are at all interested in getting some help you do need to start reporting actual error messages.
1) "/var/log/syslog" is a file. you could use "less /var/log/syslog" to view it.
2) It appears you try to install on the installer USB. Perhaps you meant to install on /dev/sdb rather?
33.3 MB for "/" does seem a bit tight, but I'd suspect rather that /dev/sda is write protected.
Use C-A-F2 to get a shell prompt and inspect /var/log/syslog, and also, run "fdisk /dev/sda" to check out the ablility to write. Note that the partition table to be written will reside on the first 1 Mb of the device.
Hmm I've never seen the installer give the message "writing to my partition failed". Perhaps you could show a photo?
@devuan_dk_fan: With "/opt" in $PATH one would expect to find some binaries in "/opt" such as for instance "/opt/binary1" and "/opt/binary2" ... but you seem to expect something else?
Did you ever look into what $PATH is, and how it isused? You find $PATH in many operating systems (although some will name it %PATH% instead). All in all it's part of the magic of running programs without naming them by absolute pathname, but merely naming them with relative path.
Like, with your "/opt" setting, you could type "waterfox/waterfox-bin" as a command to run the binary linked as "waterfox-bin" in the directory "waterfox/" relative to some direcotry in $PATH (namely "/opt").
One of the policy choices for Devuan experimental is that its packages must reside at git.devuan.org, so that would be your first step. Next, the building would be off branch suites/experimental
Many of those details remain dutifully hidden from public at
https://git.devuan.org/devuan/documenta … aintainers
Have you tried all different ttyN ? Traditionally graphical session is at tty7, but I have an inclination that sddm deviates from that and uses tty2. I would guess you have keyboard shortcuts for at least tty1-tty10 so you can check those easily. checking further is a little more complex (though afaik debian kernel sets up 64 VTs to play with).
Note that the Devuan build pipeline now has begun to include GNU Hurd OS (hurd-amd64) as target architecture for forked packages.
Thus, if you are using GNU Hurd amd64 from debian-ports you may now add the following sources.list lines so as to include Devuan's forked packages as "overlay"/"overrides" in the package collection:
deb http://deb.devuan.org/devuan ceres main
deb-src http://deb.devuan.org/devuan ceres mainOf course, the hurd-amd6 architecture has been added very recently and although there is not a huge number of packages it will take some time to get them all built and published. In fact some packages might also be held back if they require special care and additional effort for porting to this architecture.
We also would like to add the remark that, given that the Java 15+ jre is not yet available on hurd-amd64, the first hurd-amd64 build host has been added to Devuan's Jenkins build pipeline by means of an amd64 "proxy sibling" that provides the required Java remoting agent support on a shared directory, and it performs the building actions via ssh into the hurd-amd64 build host. Anyone interested in particulars on that should make themselves known at IRC #devuan-dev (at libera.chat).
Further discussions relating to GNU Hurd OS (hurd-amd64) may be had on libera.chat IRC channels #devuan-hurd and #hurd.
I think it does depend on whether or not the Ventoy partition is an exfat with label "Ventoy".
What is DOT ?
That which is wrong is that you are using a git clone URL as if you have set up your ssh authorising access for that project, which apperently you haven't.
The public cloning URL is https://git.devuan.org/devuan-editors/devuan-art.git
Try using that instead.
Do you really want that script to exit before the unmounting has completed?
If not, then don't use "-l" as umount option.
I think we should thank @lafat for offereing tactical level feedback, which is perfectly good to get for a tactical management suborganisation.
Of course such a thing does not exist in the name of Devuan. Instead there are only a number of Devuan fork maintainers who each focus on their packages, a small group of people keeping up the build and repository system and the much larger group of "normal" people that in their minds identify as Devuanites to varying degrees from the perspective of using the Devuan repositories.
All thoughts on coherence and "quality" of desktop environments and "distributions" will fall on those who take an interest in that. It's not something seen as "a Devuan concern".
Rather, Devuan's (qua organisation) strategic objective is merely to counteract the technological lock-in peddled by and with the systemd crowd, by taking positive action that includes both technical work (to bring about and maintain working alternatives) and community oriented activities that largely are aimed at maintaining an active and engaged community.
I'm sure we all also recognise that at a forum like this, anyone at times will capture their thoughts and feelings in words quicly and strongly, and submit without much post-editorial attention to how the words will land in the readership. Evenso, I want to think of every post as intended towards improvement.
In my mind, the term "immutable distro" is a marketing term that really means "I, 'the vendor', knows best; Just pay us and we'll fix it.".... a variant of "secure boot", I'd say.
I guess you won't be interested but as you may know, the action path for Devuan would be for a maintainer to set up a fork project (at git.devuan.org) to sort out its utility in Devuan. I anyhow invite you to take on that role for this package (as well as fftrate packages if you like).
Thanks. Good advice. I'll probably look at doing that eventually.
(I'm not using my bluetooth headset much at the moment)
It could possibly be helpful to the debian maintainer of bluez-alsa-util to lodge a bug regarding outdated codecs. Especially if there is a patch included. I guess the packaging project is on salsa.debian.org.
I think bluealsa gets started via dbus, But I haven't explored it.
Yes try https://pkginfo.devuan.org/bluez-alsa-utils rather
(golinux' URL includes the AI bot distraction so it's not sharable)
Note also that In excalibur bluez-alsa-utils provides bluealsa (without systemd dependency).