Hi All,

not sure if this packaging problem is on debian side or not -- this is what I get when installing kicad on my devuan testing box:

ii  kicad                                                    7.0.11+dfsg-1                     amd64        Electronic schematic and PCB design software
ii  kicad-demos                                              7.0.11+dfsg-1                     all          Demo projects for kicad
ii  kicad-footprints                                         8.0.1-1                           all          Footprint symbols for KiCad's Pcbnew
ii  kicad-libraries                                          7.0.11+dfsg-1                     all          Virtual package providing common used libraries by kicad
ii  kicad-symbols                                            8.0.1-1                           all          Schematic symbols for KiCad's Eeschema
ii  kicad-templates                                          8.0.1-1                           all          Project templates for KiCad

Notice the mismatch in versions between different kicad package components.

Please advise.   Thanks.

Greetings,

I am using a recently installed daedalus system with nvidia drivers.   The system cannot be suspended, with the following message in syslog:

loginctl[15454]: Failed to suspend system via elogind: Connection timed out

I spent about an hour looking for solutions.  It looks like a lot of people have the same problem.
Posting here just in case someone knows what's going on.   The driver version is nvidia-tesla-470.
Thanks for any suggestions!

Edit: there was one report that systemd does suspend successfully.  I cannot verify that since all my machines are on devuan now. I am skeptical about that claim because both systemd and elogind are likely to use the same mechanism to signal the suspend.

A question to system maintainers, should we install the "usrmerge" debian package?
Please see the following link:  https://salsa.debian.org/md/usrmerge/ra … DME.Debian

After the latest update (devuan testing) the mount command cannot find the mount.nfs binary.  It expects it in /sbin, but nfs-common package installs is in /usr/sbin.   Here is the corresponding entry from debian changelog of nfs-common package

nfs-utils (1:2.6.3-4~exp1) experimental; urgency=medium

nfs-utils (1:2.6.3-4~exp1) experimental; urgency=medium

  * Remove extraneous words left behind by commit 522837f. (Closes: #1051088)
  * Install systemd units to /usr/lib/systemd/system
    - debian/rules: Drop explicit setting with path for Debian
      --with=systemd=/lib/systemd/system and install the systemd units by
      default in /usr/lib/systemd/system trough --with-systemd
    - debian/nfs-common.install: Install systemd units from
      /usr/lib/system/system
    - debian/nfs-kernel-server.install: Install systemd units from
      /usr/lib/system/system
    - debian/*.links: Create symlinks for systemd units from and to
      /usr/lib/systemd/system instead of /lib/systemd/system
  * debian/rules: Don't force nfsdcltrack and mount helpers into /sbin
  * nfs-common: Install {u,}mount.nfs{,4} into /usr/sbin
  * nfs-common: lintian-overides: Adjust paths after installation to /usr/sbin
  * nfs-kernel-server: Install nfsdcltrack to /usr/sbin
  * debian/rules: Update chmod call to fix permissions of /usr/sbin/mount.nfs
  * Install rpc.statd, sm-notify and showmount into /usr/sbin
    - Install binaries to default locations in /usr/sbin
    - Drop now oboslete patches to reference sm-notify from /sbin
    - Drop now obsolete patches to change ExecStart to start sm-notify and
      rpc.statd from /sbin

-- Salvatore Bonaccorso <carnil@debian.org>  Mon, 20 Nov 2023 22:13:01 +0100

Thanks.

Greetings all,  I track devuan testing.  Today after an update remote NFS would not mount on boot.   Turns out /sbin/mount.nfs went missing.  A symbolic link from /usr/sbin/mount.nfs has fixed this.

Does anyone know what is going on?  I recall there was some old discussion about merged /usr directories in debian.

I have a devuan (chimaera) system with runit used as init.

The system has dnsmasq installed and it is used as a local dns server, /etc/resolv.conf contains 127.0.0.1 as a nameserver:

domain xyz
search xyz
nameserver 127.0.0.1

Looking at the init scripts in /etc/rc2.d, I see S03dnsmasq and S03ntpsec (the first file is before the second file in alphabetical order).

I suspect ntpsec is started before dnsmasq, because as soon as I modified /etc/resolv.conf to use nameserver 127.0.0.1, the machine started to hang for a few minutes on boot  with "starting ntp" message.

How is the startup order determined when running under runit?

The second mystery is the file /lib/runit/run_sysv_scripts which seems to run scripts from /etc/rc2.d in alphabetical order but only if  a corresponding file is present under /etc/sv.   /etc/sv/dnsmasq is present, but I don't see /etc/sv/ntpsec. How is the latter started during boot?

Thanks.