The officially official Devuan Forum!

You are not logged in.

#2 Re: Other Issues » [SOLVED] How to get these 2 apps to open maximized? » 2018-10-28 05:01:18

If you feel like using the "big stick", then you simply
a) install the devilspie package, then
b) put

(if (is (application_name) "Atril Document Viewer") (maximize))

into the file $HOME/.devilspie/maximize_atril.ds, then
c) run devilspie (e.g. via a session application startup thingy).

Thereafter, supposedly, atril will be maximized when started.

#4 Re: Other Issues » qt speech cannot find in Synaptic » 2018-10-16 07:17:19

Perhaps joive, which apparently is a "text-to-speech system" that the okular package has as suggested.

#5 Re: Installation » [Solved] Wicd 1.7.4 question » 2018-10-16 07:13:44

Good find.

There is also the per-AP settings in /etc/wicd/wireless-settings.conf which have a possible line of automatic = 1 or automatic = 0. That line tells wicd whether to connect to the AP automatically when in range, or not. To be sure, the wicd-curses UI offers a toggle for achieving this (without manual file editing), and I would guess the other UI's do as well.

#6 Re: Installation » Latest devuan jessie update causing authentication problems » 2018-10-08 23:59:41

do any of these issues have to do with using pkgmaster.deuvan.org instead of deb.devuan.org

No. deb.devuan.org is resolved into any one of a number of actual hosts (IP addresses):

% host deb.devuan.org
deb.devuan.org is an alias for deb.roundr.devuan.org.
deb.roundr.devuan.org has address 37.220.36.58
deb.roundr.devuan.org has address 5.196.38.18
deb.roundr.devuan.org has address 95.216.15.86
deb.roundr.devuan.org has address 195.85.215.180
deb.roundr.devuan.org has address 185.203.112.44
deb.roundr.devuan.org has address 31.220.0.151
deb.roundr.devuan.org has address 130.225.254.116
deb.roundr.devuan.org has address 141.24.220.40
deb.roundr.devuan.org has address 200.236.31.1
deb.roundr.devuan.org has address 91.121.196.103
deb.roundr.devuan.org has address 37.187.111.86
deb.roundr.devuan.org has address 46.4.50.2
deb.roundr.devuan.org has address 185.26.197.8
deb.roundr.devuan.org has address 185.183.113.129

and all of those are mirror hosts provided by good and friendly individuals and organisations; they are all rsync mirrors of the ultimate source of pkgmaster.devuan.org. If there are differences in using the one or the other, this system is set up to only have temporary, transitional such issues, that occur when something is updated (in pkgmaster.devuan.org, then shortly thereafter mirrored to the deb.devuan.org hosts).

#7 Re: Hardware & System Configuration » WPA cannot install in ASCII - need the wpa_supplicant.conf file » 2018-10-07 09:01:45

I think the configuration file for wpa_supplicant that you refer to is created either manually (in a manual networking setting) or by the networking utility software (e.g. network-manager or wicd). E.g., for wicd, I have the configuration files in /var/lib/wicd/configurations/ with some "random" filenames.

#8 Re: Other Issues » Emacs 25 or later in ASCII - dependency issues » 2018-10-07 08:30:25

emacs26 is not available in ASCII. Which dependency issues do you have?

#9 Re: Desktop and Multimedia » Tried to Install libav-tools then I got this message » 2018-10-05 08:00:43

No, you don't need to access contrib and/or non-free for this; all those packages (libopencv-core2.4, libavfilter5, libopencv-imgproc2.4, libav-tools, libavdevice55 and libtbb2) are available in jessie/main, and some of them also have upgrades in jessie-security/main.

Your OP warning probably relates to devuan-keyring, and it may help if you (re-)install that first, and then try again to install libav-tools.

Then as an aside: the current advice is that you should use deb.devuan.org instead of pkgmaster.devuan.org in your sources.list, so as to take advantage of the mirroring. But that's a different thing.

#10 Re: Desktop and Multimedia » Moving application towards panel ends in full screen window » 2018-09-26 13:26:25

If you're using xfce, that wonderful magic is hidden on the "accessibility" tab of the "window manager tweaks" setting; the option to "automatically tile windows when moving towards the screen edge".

#11 Re: Installation » [Solved] X server configuration - FontPath » 2018-09-24 13:05:58

It looks like the default font path is compiled into "the actual server" binary, /usr/lib/xorg/Xorg, and even though that font path is simply a null terminated string, it's not for the faint-hearted to edit a binary. It'd be easier to avoid the warning by creating an empty directory, or maybe just have a quick sideways glance at the cat when the harmless warning scrolls past.

#12 Re: Other Issues » <Solved> [Ascii] Problem with AptCacherNg » 2018-09-22 09:15:19

Presumably, as implied by your initial note "... It worked fine in Debian.", you are also running a DHCP/DNS service combination, such that the DHCP server upon serving an IP for vmdevuanr1 registers that host name appropriately with the DNS service, so that other hosts should be able to resolve it? Which DHCP/DNS service combination are you using?

#14 Re: Hardware & System Configuration » Ascii: Lenovo Trackpoint Scrolling » 2018-09-06 05:53:42

I don't have this problem myself, but a quick round-trip through the cloud suggests that man libinput is a good source of learning the property names. In particular they seem to have libinput rather than "Evdev" as their first word.

#15 Re: Hardware & System Configuration » /etc/udev/rules.d/70-persistent-net.rules rule not working (ASCII) » 2018-09-04 23:54:17

I suppose, if you choose to stay with the names eth0 and eth2 (i.e. not eth1) it might also work as udev rules.

#16 Re: Desktop and Multimedia » [Solved] Cinnamon or Gnome 3 with Devuan ASCII with apt-pinning » 2018-09-04 10:23:50

I can't really answer many of your questions, except perhaps that there is indeed a "blacklist of  packages which cannot be installed due to systemd dependency", HERE.

But I wanted to suggest that you try a different approach, for greater success on the forum, and just raise one issue or ask one question in a thread. Start a new thread for each. Otherwise the thread just ends up as a mishmash of half-answers and counter questions, without really being useful for anyone, including yourself, probably.

#17 Re: Installation » Services start issue » 2018-09-03 23:45:30

Sort of like what was once known as (this dates me) CR or 'carriage return'.
Typing machines and telex terminals from long ago.

Almost exactly right, I'd say. Time has blessed us with three different ways of ending a line, all relating back to the use of these characters for printer control, and basically a matter of how it is represented on file. So, nowadays we have:

  • the Microsoft line ending idea of using both CR (carriage return) and LF (line feed),

  • the Apple idea of ending lines with only CR, and

  • the Unix (and Linux) idea of ending lines with LF.

That line ending are characters within the files, to make up the traditional "text file" representation. Obviously the Unix idea is the right way, and the others are merely weak attempts of obfuscation.

For some reason, the fourth option of LF+CR never took hold, even though that's really the mechanical sequence that got implemented in type writers, and probably the "safest" motion for a ribbon printer, which otherwise might smudge the printing.

#18 Re: Installation » Services start issue » 2018-09-03 21:28:08

ralph.ronnquist wrote:

    ... suspect the issue is rather the absence or presence of a newline at the end of the line.

I'm sorry, I don't understand what you mean.

Hmm. A "newline" is a character at the end of a line, and it belongs to the text of the line in the same way as space characters belong to the line, but it also is a separator between lines in the way space characters are separators between words. For visudo (and sudo, I guess) the (last) line must have a terminating newline.

Many editors though don't show much different for that last newline being there or not, and some editors (like vi) even force a final newline. Presumably the editor, jed(?), that you used, lets you end the last line without a newline character.

You can check that by making a one-line file, say xxxx.txt without entering a final newline, and then view it by cat xxxx.txt, which will show the text content of the file, and then, if the final newline is missing, the next command prompt becomes joined up on the same line.

So, you configuration file problem was that the first one-liner didn't have the terminating newline, and therefore visudo complained. As you added the % character to the beginning, you also happened to get a terminating newline, presumably because you then edited the file with a different editor (eg through visudo). The fix was due to that newline, and adding the % character "merely" changed the semantics of the line.

#19 Re: Installation » Services start issue » 2018-09-03 13:01:55

Regarding that "X days has passed ...", it sounds like the fsck output, telling you that the file system hasn't been checked in X days, and that a check is forced. Nowadays there is a tendency of not showing the startup messages, but rather just showing an image or a black screen until the desktop environment kicks in. This is something you can configure by changing the boot command line.

Regarding your sudo configuration, I suspect the issue is rather the absence or presence of a newline at the end of the line.

#20 Re: Hardware & System Configuration » How i must write "openrc-run" script for launch boot service? » 2018-08-31 10:49:41

ah. of course.

If you've done the set up as @dxrobertson mentioned, maybe the problem is that the noip2 daemon needs some configuration that is missing? E.g., should it have "-i IPaddress" on the command line? Though, I must admit I know less about noip2 than is written at https://github.com/jamesstout/no-ip/blo … ADME.FIRST.

#21 Re: Hardware & System Configuration » How i must write "openrc-run" script for launch boot service? » 2018-08-31 06:53:55

echo '#!/sbin/openrc-run

is an unusual first line for a script. Or was it a mistake when copying to here? Otherwise you should remove the first 6 characters, so that the very first character is the "#" character. Or equally, make it so to say:

#!/sbin/openrc-run

#22 Re: Devuan Derivatives » Can't boot to live Refracta 9 disc » 2018-08-29 22:54:26

On that picture, it looks like init reached the "final" bash prompt, then some background process kept/keeps "spitting" at you.

Push enter, maybe.

Though there seems to be some problem with the network module.

#23 Re: Hardware & System Configuration » what starts the eudev service? [SOLVED] » 2018-08-29 21:36:07

Looking at my own system (ascii), the story is something like the following.

The process is named udevd.

It's first started by its pre-pivot init-top/udev script, in initramfs. That process is then killed at the end of the pre-pivot init sequence, by its  init-bottom/udev script, still in initramfs.

Next it has its init link /etc/rcS.d/S0?eudev (or possibly /etc/rcS.d/S0?udev) for starting udevd in the post-pivot init sequence.

The pre-pivot start up includes a forced traversal of the /sys tree through a udevadm trigger --action=add command, and then that init-top/udev script also waits for udevadm settle to return, before it "pokes" extra on scsi devices, if any, followed by an optional additional timeout in some circumstances. Further, the init-bottom/udev script at the end of pre-pivot init merely kills the pre-pivot udevd process, and then moves the pre-pivot /dev to be available as post-pivot /dev.

Note that pre-pivot init is a script, usually a copy of /usr/share/initramfs-tools/init, and it ends with an exec run-init ..., which becomes the post-pivot init process (or a panic, if exec fails).

#24 Re: Hardware & System Configuration » /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED] » 2018-08-29 13:05:57

Yes, there is 73-usb-net-by-mac.rules which deals with USB net devices, unless there's a net.ifnames=0 assignment on the boot line. Then there is also 80-net-name-slot.rules being active unless net.ifnames=0, applying some last resort naming that is made available by the (unconditional) net_id invocation of 75-net-description.rules.

Those "specialized conditions" I mentioned are various reasons to avoid renaming, and they don't make renaming happen.

Note that net.ifnames=0, net.ifnames=1 and net.ifnames unassigned provide three different ways of hotplug handling of network device adapter naming, with a nice handful of rules files involved. Then there are also at least 2 other rules files involved in the enabling (or configuration) of network interfaces, and those of course depend on the name assignments, especially if there's a renaming involved.

Don't ask me why smile

#25 Re: Hardware & System Configuration » /etc/udev/rules.d/70-persistent-net.rules not regenerating [SOLVED] » 2018-08-28 22:52:11

The generation need not be a mystery. It's indeed that "rules" file 75-persistent-net-generator.rules that comes into play whenever some hotplug event occurs, plus the once off initial scanning of /sys. I suppose you need to learn a bit udev-ish to work it out in detail, but essentially:

IF the hotplug event is due to the (possibly faked) addition of a net device adapter, and the NAME attribute has not been set for it, and the environment does not contain an net.ifnames variable with value 1, and the initial kernel name pattern is one of some few (including eth* and wlan*), and some few more specialized conditions,
THEN make up a name for the device adapter, and run /lib/udev/write_net_rules to generate /etc/udev/rules.d/70-persistent-net.rules.

Afaict the idea is, that any subsequent addition event for the same net device adapter will process 70-persistent-net.rules first, and that will set NAME for the adapter, and thereby disarm 75-persistent-net-generator.rules. It's all at a deplorable level and style of programming, but I'm sure someone is proud of it.

One thing is that the  logic ignores other possibilities of setting NAME before 75-persistent-net-generator.rules. I have a vague memory of various random "solutions" to adapter naming that end up setting NAME early, and thus also disarm the generation of 70-persistent-net.rules, but without them being grounded in their logic. The result is more untouchable udev rules mess, which is good for nothing but clocking consulting time. smile

Board footer

Forum Software