Bug#1071395: runit: breaks the functions of some packages with runit as init
Control: retitle -1 runit: as init breaks several cronjobs
Hi,
thanks for your detailed report:
the problem that you describe is real, but there is no easy/ catch-all
solution. Keep in mind that a certain number of maintainers are removing
cronjobs in favor of systemd timers
On Sun, 19 May 2024 00:31:14 +0800 Mo Jun wrote:
> Package: runit
> Version: 2.1.2-59
> Severity: normal
>
> Dear Maintainer,
>
> Some package call invoke-rc.d for theirs functions. For example,
> anacron have
>
> [anacron and stunnel examples]
>
> On systems using runit as init, due to
> /lib/lsb/init-functions.d/40-runit, `/etc/init.d/script action' is a
> no-op by default if there is a corresponding
> native runit service. This will breaks the functions of those
> packages. For example:
it breaks some cronjobs, hopefully not all. For some just using the
initscript nonstandard action, like 'reopen-logs' or 'rotate', may work.
I don't have any estimate, maybe 90% work, maybe 90% are broken..
> Maybe `invoke-rc.d script action' and `/etc/init.d/script action'
> should be forwarded to the corresponding native runit service to fix
> this bug.
how many cases there are, apart from anacron? If it's only anacron, I
think is better to fix the cronjob rather than signalling each service
twice (see below)
>
> By the way, it is mentioned in the header of
> /lib/lsb/init-functions.d/40-runit
> that if /etc/runit/lsb.runit.forward is set, `/etc/init.d/script
> action' will be
> forwarded to sv "if /etc/sv/ exists and is enabled". However
> I do not see this is implemented in the current version of
> 40-runit.invoke-rc.d
it's here - but you are right, 40-runit is ugly and very complex to
read
-
case "$action" in
start|stop|restart|reload|status|try-restart|force-stop|force-reload|force-restart)
if [ -z "${forcesysv:-}" ]; then
echo "here"
[ -e "/usr/share/runit/meta/$service/installed" ] && exit 0
#dh-runit+runit-helper
[ -e "/etc/sv/$service/.meta/bin" ] && exit 0 # runit trigger-sv
[ -e "/usr/share/runit/sv.current/$service/.meta/bin" ] && exit
0 # runit trigger-sv
echo "and here"
sv "$action" "$service" || true
exit 0
---
it rules out services that are integrated with runit-helper or with a
trigger in runit, otherwise they will be signaled twice each upgrade
>
> And another note. The orphan-sysvinit-scripts package have installed
> /lib/rsyslog/rsyslog-rotate which calls `invoke-rc.d rsyslog rotate'
> on non-systemd
> systems. As there is no such rotate action in sv, the rotate action
> will be forwarded to /etc/init.d/rsyslog, but that will not work if
> the native runit service of rsyslog is running. After looked into
> /etc/init.d/rsyslog, I
> `/etc/init.d/rsyslog rotate' is the same as `sv hup rsyslog' and `sv
> reload
> rsyslog'.
> Maybe assists from the Maintainer of the orphan-sysvinit-scripts
> package is needed
> to make the lograte for rsyslog functional in runit-init systems.
This is possible, but what if orphan-sysvinit-scripts is not installed?
After all in a runit-init system it's likely that one wants to use
runit services, not sysvinit scripts..
Option to deal with this cronjob issue are (add if you have others):
* add runit code in cronjobs (for example for this would work well for
anacron)
* runit-services could start to ship cronjobs for it's services, when
the cronjob is missing or it doesn't work with the runit service
(for example, rsyslogd)
* we could stop using cronjobs and use have runit-timers, converted from
systemd timers (I don't like this option - I don't see the
advantage of having N active timers instaed of one service that does N
jobs - but it's feasible with 'snooze' and a converter)
* a mix of the above
Before deciding I would like to gather some data to make an informed
choice, for example
How many cronjobs are gone in favor of timers(compared with olstable)?
How many cronjobs calls standard sysv actions (like anacron)?
How many calls non-standard actions, and how many of these fails under
runit?
I didn't have the time to gather data so far, so I'm holding this
decision; if you have any data please share
Regards,
Lorenzo
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
Control: tags -1 -moreinfo Hi, On Sat, 11 May 2024 10:24:31 +0200 Tobias Frost wrote: > On Tue, Apr 16, 2024 at 09:39:58AM +0200, Lorenzo wrote: > > Control: block -1 by 1067525 > > > > this fix need to go to unstable because elogind 255.4.1 is already > > there, but runit-services depends on runit > 2.1.2-56 (unstable is > > at 2.1.2-54) so 1067525 needs to be uploaded first or together with > > this one, otherwise runit-services is not installable > > Ok, just saw that one. > Please note that this fact must be stated in d/changelog, something > like "Upload to unstable." > I've update the changelog mentioning the upload to unstable. updated links: https://mentors.debian.net/package/runit-services/ dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads Thanks, Lorenzo
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hi, On Sat, 11 May 2024 10:52:33 +0200 Martin Steigerwald wrote: [...] > > In case it is helpful for you I could post a step to step guide for a > minimal Incus setup and/or at least some pointers. yes this would be useful > > > > > > I just wonder why stage 2 contains /usr/local bin > > > > > directories. I think that should not be the case. Shall I > > > > > report this as a different issue? > > > > [...] > I do think this discussion belongs into a different bug report > though. I am willing to open a low priority report about this and > include the previous relevant discussion to it, so it does not get > lost and you can take your time to ponder about it. There is no need > to rush it. fine for me, feel free to proceed > > Have a great weekend! Thanks :) Lorenzo
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hi, On Tue, 07 May 2024 15:08:37 +0200 Martin Steigerwald wrote: >[...] > > Are init scripts supposed to be started with PATH variable set up and > exported or not? How is it done with SysVInit? I bet it would be best > to match as close as possible what SysVInit is doing to be as > compatible as possible. I checked this and in sysvinit you don't have this bug because during boot sysvscripts are run via /etc/ini.d/rc script, and there is an 'export PATH' there. It could probably be triggered by calling the script directly during runtime. In runit we are calling scripts directly in stage1 so we have this bug > > Otherwise it might be challenging to chase and find all the corner > cases with existing setups. And as there is no issue initializing the > network in the container with SysVInit instead of Runit used as PID > 1, I'd consider a change in Runit. At least it could be challenging > to find whether networking inside a container is the only thing that > breaks. I want to dig this further, I don't recall broken network under docker and I don't think is broken under qemu, but I can be wrong or remember something from before /etc/init.d/rc usage was dropped from stage1 > > > > > > I just wonder why stage 2 contains /usr/local bin directories. I > > > think that should not be the case. Shall I report this as a > > > different issue? > > > > PATH is passed to env call for runsvdir, so I guess one can exec a > > bin from local as runscript (not sure) without setting the PATH. I > > can't think of other use cases.. > > I'm fine with removing, just a bit wary, I'm afraid to break some > > custom setup > > Hmm, I get that. I am just a bit concerned as it may be a security > issue. not urgent, but could you elaborate this (security implications)? is something like an attacker placing a modified foo in /usr/local/ that overrides the legit foo in /usr/bin or is something else? one still needs root privileges to write to /usr/local.. Lorenzo > > > > I added empty "debug" and "verbose" files in /etc/runit but did > > > not find any debug output. Maybe those files needed to have some > > > content. Maybe it requires bootlogd. > > > > those files only work for runit stuff (runscripts and the sv > > trigger), boot scripts are for sysvinit and do not obey to runit > > settings :( perhaps it's time to roll some native runit > > bootscripts.. > > I see. Well that would be great. But also would require a lot of work > and testing I bet. > > Best,
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Hi, On Fri, 03 May 2024 13:05:15 +0200 Axel Beckert wrote: > Package: cgroupfs-mount > Severity: serious > Version: 1.4+nmu1 > > Hi, > > cgroupfs-mount fails to upgrade from 1.4 to 1.4+nmu1 for me (elogind + > sysvinit) as follows: > > Setting up cgroupfs-mount (1.4+nmu1) ... > Unmounting cgroupfs hierarchyumount: /sys/fs/cgroup/elogind: target > is busy. invoke-rc.d: initscript cgroupfs-mount, action "restart" > failed. dpkg: error processing package cgroupfs-mount (--configure): > installed cgroupfs-mount package post-installation script subprocess > returned error exit status 1 > > Is this is a duplicate of #950986? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950986 I bet the patch there would fix this bug too Lorenzo
Bug#576591: mplayer - gmplayer fails by default
Control: severity -1 normal Control: forwarded -1 https://trac.mplayerhq.hu/ticket/1044 Control: tags -1 upstream On Mon, 5 Apr 2010 23:17:21 +0200 Bastian Blank wrote: > Package: mplayer > Version: 1.0~rc3+svn20090405-1+b1 > Severity: grave > > gmplayer fails by default with the following error: > | Error: opening/initializing the selected video_out (-vo) device. > > It only tries the mga output instead of the generic Xv. This seems to be still relevant: I have no vo= defined in /etc/mplayer/mplayer.conf and the gui creates ~/.mplayer/gui.conf with vo_driver=vdpau and in my case fails to play with [vdpau] Error when calling vdp_device_create_x11: 1 Error opening/initializing the selected video_out (-vo) device. Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory if I change to vo_driver=vdpau,xv it plays the video with no errors. Ingo, is it possible to patch the gui so that the default value is changed to xv or to a list that includes xv? Thanks, Lorenzo > > Bastian > > -- > I've already got a female to worry about. Her name is the Enterprise. > -- Kirk, "The Corbomite Maneuver", stardate 1514.0 > > >
Bug#1069188: runit-services: smartmontools runscript
Control: tags -1 moreinfo
Hi!
On Wed, 17 Apr 2024 17:17:39 +0300
"Dimitris T." wrote:
> Package: runit-services
> Version: 0.7.1
> Severity: wishlist
>
> Lorenzo hey,
>
> just tried smartmontools runscript found here :
> https://git.devuan.org/xinomilo/runscript-collection/src/branch/master/smartmontools
thanks for sharing it
>
> [...]
>
Did you take it from void linux? (I think I saw a similar finish
file there) In any case I'm not convinced by the finish file:
#!/bin/sh
# no devices found, disable smartd
[ $1 = 17 ] && sv d $(dirname $0)
Ok, we don't want to keep restarting if there is a permanent
failure condition, but there are others condition like this
that are not catched by [ $1 = 17 ]
I had a look at smartd(8) and found the '-q onecheck' option
and I'm using it as a test, so the runscript becomes
---
#!/usr/bin/env /lib/runit/invoke-run
sv start default-syslog || true
if ! /usr/sbin/smartd -q onecheck ; then
#no devices or other fatal problem
sv d "${PWD##*/}"
fi
exec 2>&1
if [ "$VERBOSE" = 1 ]; then
echo "Invoke-run: Starting $NAME"
fi
exec /usr/sbin/smartd -n $smartd_opts
---
and there is no need for the finish file.
Could you test if it works for you? If you have a system with
no devices suitable for smartd it should put the service down
the same way as the finish file does.
Best,
Lorenzo
>
> thanks in advance,
> d
>
> -- System Information:
> Distributor ID: Devuan
> Description: Devuan GNU/Linux 6 (excalibur/ceres)
> Release: 6
> Codename: excalibur ceres
> Architecture: x86_64
>
> Kernel: Linux 6.8.6-3-liquorix-amd64 (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
> LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages runit-services depends on:
> ii runit 2.1.2-59
> ii runit-helper 2.16.2
>
> Versions of packages runit-services recommends:
> ii runit-init 2.1.2-59
>
> Versions of packages runit-services suggests:
> pn socklog
>
> -- no debconf information
Bug#1070167: openrc: postinst fails with not executable script in /etc/init.d/
Package: openrc Version: 0.45.2-2 Severity: normal X-Debbugs-Cc: plore...@disroot.org Hi, it appears that, at least under certain conditions, openrc postinstall script fails if a sysvinit script in /etc/init.d/ is not executable. Note that recently debhelper started to chmod -x initscripts when a package is removed but not purged, so openrc should deal whit non executebles files under /etc/init.d/ Not sure if the bug is in openrc tools or in update-rc.d/invoke-rc.d's openrc bits See https://dev1galaxy.org/viewtopic.php?id=6549 for some output of the problem Best, Lorenzo -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages openrc depends on: ii insserv 1.24.0-2 ii libaudit11:3.1.2-2.1 ii libc62.37-18 ii libcap2 1:2.66-5 pn libeinfo1 ii libpam0g 1.5.3-7 pn librc1t64 ii libselinux1 3.5-2+b2 openrc recommends no packages. Versions of packages openrc suggests: pn policycoreutils pn sysvinit-core
Bug#1070032: elogind: add NEWS for 255.4.1, suspend now default to s2idle instead of s2ram
Package: elogind Version: 255.4.1-1debian2 Severity: normal X-Debbugs-Cc: plore...@disroot.org Hi, Elogind 255 changed the implicit default for suspend; it was 'deep' until 252, now it's 's2idle'. This is documented nowhere, except if one reads Yamakuzure reply in https://github.com/elogind/elogind/issues/280 and it took me a while [1] to understand that the state where the screen goes black but power led is still on and fans keep spinning is not a bug in elogind. I think this change is worth a NEWS entry, with an example that explains how to revert to the previous default. I suggest something like This version of elogind changes the default Mode for suspend, before elogind 255 it was suspend2ram, now it's suspend2idle. To revert to the previous default you can add a line with SuspendMode=deep in elogind's sleep.conf; for example cat /etc/elogind/sleep.conf.d/20-suspend.conf [Sleep] SuspendMode=deep Best, Lorenzo [1] https://docs.kernel.org/admin-guide/pm/sleep-states.html -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages elogind depends on: ii dbus 1.14.10-4+b1 ii debconf 1.5.86 ii init-system-helpers 1.66 ii libacl1 2.3.2-1 ii libc62.37-18 ii libcap2 1:2.66-5 ii libmount12.40-6 ii libpam0g 1.5.3-7 ii libselinux1 3.5-2+b2 ii libsystemd0 255.5-1 ii libudev1 255.5-1 Versions of packages elogind recommends: ii libpam-elogind 255.4.1-1debian2 ii polkitd 124-2 elogind suggests no packages. -- no debconf information
Bug#1059605: dh-runit: Consider migrating from a haskell-based testrunner
Control: tags -1 help Hi, [sorry for the very late reply] On Thu, 28 Dec 2023 22:03:21 -0600 "David (Plasma) Paul" wrote: > Please consider modifying the testsuite infrastructure for dh-runit to > not require haskell. > > Given that both dh-runit and its tests are written in perl, it's a bit > inconvenient to need a haskell compiler just to build the testrunner > program. I mostly agree, however the haskell testsuit runs very fast and I believe it's also run in some kind of isolated environment (I inherited the testsuite from previous maintainer, so I'm not 100% sure about the isolation). I'm fine with converting the testsuite in perl and/or shell but this is time consuming for very little gain, so it's low priority for me compared to other issues, not sure if/when it will happen. If for someone this is urgent, I'm certainly going to review patches for a testsuite in perl/shell; just make sure the test results are not dependant on the system where the testsuite is run - it has to work in your development system but also in a container like salsa autopkgtest with consistent results. Tagging help in case someone wants to provide patches. Best, Lorenzo > > Thanks, > > -- > Plasma > >
Bug#1069595: mplayer: FTBFS with ffmpeg 7
Source: mplayer Version: 2:1.5+svn38446-2 Severity: important Tags: upstream ftbfs X-Debbugs-Cc: plore...@disroot.org Mplayer fails to build from source with ffmpeg7 (currently in experimental); there are patches upstream but it looks that there are still open issues, at least with jack. https://trac.mplayerhq.hu/ticket/2419 https://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2024-April/074132.html filing with severity important for now, until ffmpeg 7 is uploaded to unstable. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit)
Bug#1069592: runit: trigger_sv logic broken: enable and disable a service in the same loop
Package: runit Version: 2.1.2-59 Severity: normal X-Debbugs-Cc: plore...@disroot.org in order to temporary counter #1069075 I've created a local copy of elogind in /etc/sv/ ; then the elogind path is updated both in the run script and in the .meta/bin metafile so that ~# cat /etc/sv/elogind/.meta/bin /usr/libexec/elogind ~# cat /etc/sv/elogind/run | grep elogind exec /usr/libexec/elogind also (to see more messages from the trigger) touch /etc/runit/verbose then I call the trigger as it would be activated in almost any apt invocation and a not so "funny" thing happens ~# /lib/runit/trigger_sv setup Runit triggered upgrade: setup elogind enabled elogind disabled elogind service is enabled and disabled in the same loop. basically the shadowing logic works for "enable" action but not for "disable", resulting in bin metafiles being processed for both the copy in /etc/sv/ and /usr/share/runit with the latter that prevails due to be processed later. this need to be addressed -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.37-17 ii runit-helper2.16.2 ii sysuser-helper 1.3.9+really1.4.3 Versions of packages runit recommends: ii runit-init 2.1.2-59 Versions of packages runit suggests: ii runit-services 0.7.1 ii socklog 2.1.0+repack-5 ii ucspi-unix 1.0-3 pn zsh -- Configuration Files: /etc/default/runit changed: VERBOSE=1 DEBUG=1 /etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: '/etc/runit/runsvdir/single/sulogin/run' -- no debconf information
Bug#1069267: 2.1.2-59 preinst script fails
control: found -1 runit/2.1.2-55 Hi, On Fri, 19 Apr 2024 00:32:51 + Jamie Heilman wrote: > Package: runit > Version: 2.1.2-59 > > I have a long standing installation of runit which does not use the > runsvchdir(8) symlink flipping mechanics. /etc/service is a normal > directory. This isn't some customization I did, this is simply the > natural state of my sid host after years of following sid. It seems you are right, I did some digging and found the following * until 2.1.2-3 /etc/service was shipped as a directory * 2.1.2-4 no longer ships /etc/service at all [I guess that /etc/service does not disappear if is not empty] * 2.1.2-7 ships /etc/service as a symlink (no migration code to deal with /etc/service as directory) [I thought that dpkg would error if there is already a directory where it has to create a symlink, but evidently it does not ?] * meanwhile the new runit-init 2.1.2-6 package has code in preinst with readlink that breaks when /etc/service is a directory * 2.1.2-55 changes the logic around a test in preinstall and fails if /etc/service exists and is not a symlink So if a system has runit installed since before 2016, and runit-init package was not installed at the time, it will simply fail to upgrade to 2.1.2-59.. I didn't see it coming. > /etc/runit/runsvdir/current does exist, and is a symlink to the > svmanaged directory which is empty. The preinst script that attempts > to migrate away from this layout fails because it sets errexit (-e) > and readlink returns non-zero. > > Checking if "$servlink" != '/etc/runit/runsvdir/current' is never > reached. > > Newer installations won't have this problem, they get set up with the > symlink nest that the runit-init stuff uses, but as it stands, older > installs can't upgrade. skipping releases is not supported, but a clean install for each release is not required, and failing to install/upgrade is not ok, even if affects only a small subset of users; not sure about the severity, maybe it is RC. At least the package has to be installable when /etc/service is a directory; probably having a NEWS where is recommended to change to a symlink would be nice > Obviously migrating /etc/service to a symlink > is delicate, I was able to get away with: I have to think about this, but I see trouble, for example > > T=`mktemp -d /etc/runit.` > ln -s /etc/runit/runsvdir/current "$T/service" > rmdir /etc/runit/runsvdir/svmanaged [rmdir fails if svmanaged it's not empty] > mv /etc/service /etc/runit/runsvdir/svmanaged [ in this moment /etc/service does not exists, not sure what happens if runsvdir perform a scan in this moment, but it can be dangerous expecially if runit is init] > mv -T "$T/service" /etc/service > rmdir "$T" also, if I remember correctly there is a setup where /etc/service is a mountmpoint for tmpfs, not sure what happens if I move it. Overall it seems that if do that automatically too many things can go wrong. However the code can be used as an example in the NEWS, so thanks for sharing and test it! Best, Lorenzo > > but I can't say that will work flawlessly for everybody. I use > sysvinit and my inittab entry is: > > SV:123456:respawn:/etc/runit/2 > > I tried the same fix on a old guest I had running systemd and it > worked there too, FWIW. >
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
Control: block -1 by 1067525 this fix need to go to unstable because elogind 255.4.1 is already there, but runit-services depends on runit > 2.1.2-56 (unstable is at 2.1.2-54) so 1067525 needs to be uploaded first or together with this one, otherwise runit-services is not installable On Tue, 16 Apr 2024 09:30:08 +0200 Lorenzo wrote: > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "runit-services": > > * Package name : runit-services >Version : 0.7.2 >Upstream contact : [fill in name and email of upstream] > * URL : [fill in URL of upstream's web site] > * License : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0 > * Vcs : >https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section > : admin > > The source builds the following binary packages: > > runit-services - UNIX init scheme with service supervision > (services) > > To access further information about this package, please visit the > following URL: > > https://mentors.debian.net/package/runit-services/ > > Alternatively, you can download the package with 'dget' using this > command: > > dget -x > > https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc > > Git repo: > > https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads > > Changes since the last upload: > > runit-services (0.7.2) unstable; urgency=medium > . >* Fix elogind service (Closes: #1069075) > > Regards, > Lorenzo > >
Bug#1069083: RFS: runit-services/0.7.2 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.7.2 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : BSD-3-Clause, GPL-2.0+, GPL-3+, CC0-1.0 * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.2.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads Changes since the last upload: runit-services (0.7.2) unstable; urgency=medium . * Fix elogind service (Closes: #1069075) Regards, Lorenzo
Bug#1069075: elogind: service broken by elogind path change in 255.4.1
Package: runit-services Version: 0.7.1 Severity: important X-Debbugs-Cc: plore...@disroot.org Version 255.4.1 of elogind changes elogind's path from /lib/elogind/elogind to /usr/libexec/elogind; this breaks quite a lot in a desktop setup. the runscript and the bin metafiles need to be updated -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) LSM: AppArmor: enabled Versions of packages runit-services depends on: ii runit 2.1.2-58 ii runit-helper 2.16.2 Versions of packages runit-services recommends: ii runit-init 2.1.2-58 Versions of packages runit-services suggests: ii socklog 2.1.0+repack-5 -- no debconf information
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
On Sat, 13 Apr 2024 17:29:48 +0200 Martin Steigerwald wrote: > Martin Steigerwald - 13.04.24, 15:05:41 CEST: > > No PATH defined. > > > > The script defines it. See line 8 in my changed script. However it > > does not export it. Thus adding line 9 fixes the bug I reported: > > > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > > 9 export PATH > > > > The network is configured just fine after adding that line. > > Since configuring networking works on physical machines – I know for > sure with Devuan 5 aka Daedalus and Devuan Ceres which was at a > similar state Devuan Excalibur is currently – regarding the right fix > the question remains: > > What is different with the PATH in both cases and why? > > Why is it empty inside the (unprivileged) Incus managed LXC > container? Is it empty on the physical machine? I doubt it. But where > does the difference come from? And anyway the PATH is being set in > both stage 1 and stage 2 scripts, just not exported. So on a physical > machine it appears that PATH is being exported before already. It > might be exported before already on a container as well, albeit > undefined / empty. If I remember correctly, it's the kernel that sets environment for init; and it's different even when it boots "statically" vs via initramfs as the latter defines a lot of extra and unecessary stuff > > In both cases /bin/sh points to /bin/dash. Both the VM with Excalibur > and the physical host with Daedalus are usrmerge'd. >
Bug#1068922: runit-init: configuring network interfaces at boot inside LXC with runit as init system fails
Hello Martin, thanks for the detailed info and the time spent on it On Sat, 13 Apr 2024 15:05:41 +0200 Martin Steigerwald wrote: > Martin Steigerwald - 13.04.24, 14:32:16 CEST: > > Any idea how to find the cause of what is happening here? > > I found the cause: > > The container starts out with an almost empty environment. In > [...] > > root@zdevuan:~# cat rcS.log > >> environment > container=lxc > PWD=/ > >> end of environment > > No PATH defined. > > The script defines it. See line 8 in my changed script. However it > does not export it. Thus adding line 9 fixes the bug I reported: > > 8 PATH=/sbin:/usr/sbin:/bin:/usr/bin > 9 export PATH > > The network is configured just fine after adding that line. > > > > Same goes for stage 2. In /etc/runit/2 I added: >[...] > > Exporting the PATH there as well like > > 1 #!/bin/sh > 2 > 3 PATH=/usr/local/sbin:/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin > 4 export PATH > 5 SVDIR=/etc/service > > fixes > > root@zdevuan:~# cat /etc/boot.d/network > #!/usr/bin/env sh > > /etc/init.d/networking restart > > The network is configured even without the "export PATH" fix in > /etc/runit/1. OK, so if I undertand correctly we either export PATH in the /etc/init.d/networking script or we export PATH both in stage 1 and 2 (so the script does not fail during boot and can be called during runtime): is that correct? If yes I think it's better to fix the networking script (ifupdown pkg) so that the fix works for sysvinit users too. Different story if multiple scripts fails during boot because of empty PATH; many scripts in /etc/rc.S/ set their PATH but others don't.. Could you confirm that no other scripts fails in your container setup when PATH is not exported in stage 1 ? > > I just wonder why stage 2 contains /usr/local bin directories. I think > that should not be the case. Shall I report this as a different issue? PATH is passed to env call for runsvdir, so I guess one can exec a bin from local as runscript (not sure) without setting the PATH. I can't think of other use cases.. I'm fine with removing, just a bit wary, I'm afraid to break some custom setup > > > > I am now undoing my debug output. > > I think I could provide a merge request for the fixes at a later time. > For now I like to finish the Devuan template and actually use it. > > That bootlogd does not seem to work inside a container is a different > issue I may report at another time. > > I added empty "debug" and "verbose" files in /etc/runit but did not > find any debug output. Maybe those files needed to have some content. > Maybe it requires bootlogd. those files only work for runit stuff (runscripts and the sv trigger), boot scripts are for sysvinit and do not obey to runit settings :( perhaps it's time to roll some native runit bootscripts.. > > But that is for another time :) > > Best, Best regards, Lorenzo
Bug#1063531: RFS: mplayer/2:1.5+svn38446-2 -- movie player for Unix-like systems
Hi, On Sat, 13 Apr 2024 12:54:19 +0200 Tobias Frost wrote: > Uploaded, thanks for your contribution. Thanks :) > > Some remark: > - On the BTS are quite a number of open bugs. Should they be triaged > to see if they still have merit, reported upstream or otherwise > handled? Yes, I'm *very slowly* processing old bugs (for example #418855, #753991 or other recently fixed) while dealing with the stream of new ones ; for many of those (old bugs) there is not much I can do apart from tagging though.. Besides from fixing frequent FTBFS, top priority on my TODO list are #1038513, maybe #967643 and the quilt patch for CVE-2016-4352 (it's reported as fixed upstream in 2016 but it still apply??) Cheers, Lorenzo > > Cheers, > tobi > > On Fri, Feb 09, 2024 at 02:28:51PM +0100, Lorenzo wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear mentors, > > > > I am looking for a sponsor for my package "mplayer": > > > > * Package name : mplayer > >Version : 2:1.5+svn38446-2 > >Upstream contact : [fill in name and email of upstream] > > * URL : https://mplayerhq.hu > > * License : LGPL-2.1+, Expat, ISC, public-domain-tom, > > GPL-2+, BSD-2-Clause, other-2, other-1 > > * Vcs : > > https://salsa.debian.org/multimedia-team/mplayer Section : > > video > > > > The source builds the following binary packages: > > > > mplayer-gui - movie player for Unix-like systems (GUI variant) > > mencoder - MPlayer's Movie Encoder > > mplayer - movie player for Unix-like systems > > mplayer-doc - documentation for MPlayer > > > > To access further information about this package, please visit the > > following URL: > > > > https://mentors.debian.net/package/mplayer/ > > > > Alternatively, you can download the package with 'dget' using this > > command: > > > > dget -x > > > > https://mentors.debian.net/debian/pool/main/m/mplayer/mplayer_1.5+svn38446-2.dsc > > > > Git repo: > > > > > > https://salsa.debian.org/multimedia-team/mplayer/-/tree/next?ref_type=heads > > > > Changes since the last upload: > > > > mplayer (2:1.5+svn38446-2) unstable; urgency=medium > > . > >* build a noaltivec variant of mplayer for powerpc > >* install alternatives for mplayer-altivec and > > mplayer-noaltivec on powerpc; the altivec > > variant has the highest priority (Closes: #410962) > >* d/control: B-D: > >- add dh-exec > >- replace obsolete pkg-config with pkgconf > >
Bug#1065133: orphan-sysvinit-scripts: Please support pdns-recursor
Control: tags -1 moreinfo
Hi Matija,
could you please test the attached refreshed script and report if it
works as expected for your use case?
Lorenzo
pdns-recursor
Description: Binary data
--- pdns-recursor-sysv 2024-03-25 10:29:15.941311479 +0100
+++ pdns-recursor 2024-03-26 11:05:37.467659608 +0100
@@ -12,7 +12,7 @@
#
# Authors: Matthijs Möhlmann
# Christoph Haas
-#
+#
# Thanks to:
# Thomas Hood
#
@@ -27,15 +27,21 @@
DESC="PowerDNS Recursor"
NAME=pdns_recursor
DAEMON=/usr/sbin/$NAME
+PDNS_USER=pdns
# Derive the socket-dir setting from /etc/powerdns/recursor.conf
-# or fall back to the default /var/run if not specified there.
+# or fall back to the default /var/run/pdns-recursor if not specified there.
PIDDIR=$(awk -F= '/^socket-dir=/ {print $2}' /etc/powerdns/recursor.conf)
-if [ -z "$PIDDIR" ]; then PIDDIR=/var/run; fi
+if [ -z "$PIDDIR" ]; then PIDDIR=/var/run/pdns-recursor; fi
PIDFILE=$PIDDIR/$NAME.pid
+#create sockedir
+install --owner=$PDNS_USER --group=$PDNS_USER -d $PIDDIR
+
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
+ulimit -n 16384
+
# Read config file if it is present.
if [ -r /etc/default/pdns-recursor ]; then
. /etc/default/pdns-recursor
@@ -46,7 +52,8 @@
# 0 if daemon has been started / was already running
# >0 if daemon could not be started
start-stop-daemon --start --oknodo --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null || return 0
- start-stop-daemon --start --oknodo --quiet --pidfile $PIDFILE --exec $DAEMON -- --daemon=yes || return 2
+ start-stop-daemon --start --oknodo --quiet --pidfile $PIDFILE --exec $DAEMON -- \
+--daemon --setuid=$PDNS_USER --setgid=$PDNS_USER 2>/dev/null || return 2
}
start_resolvconf() {
@@ -62,7 +69,7 @@
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occured
- start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME
+ start-stop-daemon --stop --quiet --pidfile $PIDFILE --name $NAME --user $PDNS_USER
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
rm -f $PIDFILE
@@ -84,10 +91,6 @@
case "$1" in
start)
-if [ "$START" != "yes" ]; then
- echo "Not starting $DESC -- disabled."
- exit 0
-fi
echo -n "Starting $DESC: $NAME ..."
start
case "$?" in
@@ -126,10 +129,6 @@
esac
;;
restart|force-reload)
-if [ "$START" != "yes" ]; then
- $0 stop
- exit 0
-fi
echo -n "Restarting $DESC ..."
stop
case "$?" in
@@ -172,5 +171,3 @@
esac
exit 0
-
-
Bug#1067716: RFS: fgetty/0.7-9 [QA] [RC] -- very small, efficient, console-only getty and login
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "fgetty": * Package name : fgetty Version : 0.7-9 Upstream contact : Felix von Leitner * URL : https://www.fefe.de/fgetty * License : GPL-2+ * Vcs : https://salsa.debian.org/debian/fgetty Section : admin The source builds the following binary packages: fgetty - very small, efficient, console-only getty and login To access further information about this package, please visit the following URL: https://mentors.debian.net/package/fgetty/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/fgetty/fgetty_0.7-9.dsc Git repo: (I don't have permission to upload to salsa debian/fgetty so I temporary forked in my namespace) https://salsa.debian.org/Lorenzo.ru.g-guest/fgetty/-/tree/next?ref_type=heads Changes since the last upload: fgetty (0.7-9) unstable; urgency=medium . * QA upload. . [ Francisco M Neto ] * quilt patches: - fix makefile to use dietlibc - add missing #include to fgetty.c (Closes: #1066518) - fix implict type declarations warnings . [ Lorenzo Puliti ] * Standards-Version: 4.6.2, no change required Regards, Lorenzo
Bug#1067525: RFS: runit/2.1.2-59 -- system-wide service supervision
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit": * Package name : runit Version : 2.1.2-59 Upstream contact : Gerrit Pape * URL : http://smarden.org/runit/ * License : CC0-1.0, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/debian/runit Section : admin The source builds the following binary packages: runit - system-wide service supervision runit-run - service supervision (systemd and sysv integration) getty-run - runscripts to supervise getty processes runit-init - system-wide service supervision (as init system) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-59.dsc Git repo: https://salsa.debian.org/debian/runit/-/tree/next?ref_type=heads Changes since the last upload: runit (2.1.2-59) unstable; urgency=medium . * upload to unstable * d/copyright: update years * d/watch: use https instead of http * lintian: update overrides for runit * Revert "d/rules: undo changelog trimming for runit" * update-service: add bash-completion * cpsv: update manpage About the getty-run.NEWS in a previous RFS(#1057098): On Tue, 13 Feb 2024 15:06:46 +0100 Tobias Frost wrote: > You've misunderstood me with NEWS file (but this is not a stopper for > the upload.) > > What I meant is that the NEWS file is that old that it should be > removed. (Debhelper just pointed me to the file, even if it did > not correctly disagnose the issue) > This is even more correct if debhelper decided to strip out that > version from d/changelog anyways, users will not get this NEWS > files displayed, and the information in it shouldn't be relveant > anymore. > So my suggestion would be to just rm it. I prefer not to remove this for now, the info inside the file are relevant for me (as maintainer) since I would like to remove the links in getty-run.links in the future (they are kind of a policy violation) but I face the same issue as Dmitry.. Regards, Lorenzo
Bug#1065146: sysvinit-core: /usr/sbin/halt and others ineffectively diverted (DEP17)
On Fri, 1 Mar 2024 08:05:27 +0100 Helmut Grohne wrote: > Package: sysvinit-core > Version: 3.08-7 > Severity: serious > Tags: patch > User: helm...@debian.org > Usertags: dep17p3 > Control: affects -1 + bfh-container progress-linux-container > > Hi, Hi Helmut, > > thanks for applying my earlier /usr-move patch #1060139. Since > authoring it, the mitigations for ineffective diversions have been > added to diverters, but one missing piece remains. We must not upgrade > sysvinit-core before the diverters have duplicated their diversions or > we may cause file loss. I'm missing something for sure here, but sysvinit-core has a conflict with systemd-sysv and both bfh-container and progress-linux-container depends on systemd-sysv so they already should not be installed at the same time in a system regardless of the versioned conflicts you are adding.. ? Regards, Lorenzo > To achieve this, sysvinit-core needs to gain > two more versioned Conflicts beyond molly-guard to be found in the > attached patch. > > Helmut
Bug#1065072: packagekit: continous bursts of cpu usage
Package: packagekit Version: 1.2.8-2 Severity: important X-Debbugs-Cc: lorenzobertin...@gmail.com Dear Maintainer, packagegitd sits at the top of my task manager since boot, using a single core for bursts of 100% usage. This is critical on a laptop, so from now on I'm masking the service. This is what pkmon reports every couple seconds, without variation: (pkmon:4910): GLib-GIO-CRITICAL **: 12:25:11.737: GTask 0x55bb986bf4e0 (source object: 0x55bb9869c1d0, source tag: 0x7fef9e3c81c0) finalized without ever returning (using g_task_return_*()). This potentially indicates a bug in the program. Transactions: 1 /7299_eecaaebd Transactions: 1 /7299_eecaaebd 2 /7300_dedcabea /7300_dedcabea allow_cancel 1 /7300_dedcabea percentage -1 /7300_dedcabea role get-updates /7300_dedcabea sender /usr/bin/gnome-software /7300_dedcabea status wait Is this a gnome-software problem? Don't hesitate to ask for more info. Best wishes. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages packagekit depends on: ii init-system-helpers 1.66 ii libappstream5 1.0.2-1 ii libapt-pkg6.0t64 [libapt-pkg6.0] 2.7.12+nmu1 ii libc6 2.37-15 ii libgcc-s1 14-20240221-2.1 ii libglib2.0-0t64 [libglib2.0-0]2.78.4-2 ii libglib2.0-bin2.78.4-2 ii libgstreamer1.0-0 1.22.10-1 ii libpackagekit-glib2-181.2.8-2 ii libpolkit-gobject-1-0 124-1 ii libsqlite3-0 3.45.1-1 ii libstdc++614-20240221-2.1 ii libsystemd0 255.4-1 ii polkitd 124-1 Versions of packages packagekit recommends: ii appstream 1.0.2-1 ii packagekit-tools 1.2.8-2 ii systemd 255.4-1 packagekit suggests no packages. -- no debconf information
Bug#1064123: libgl1-mesa-dri: latest version crashes X, can't use mouse/keyboard
Package: libgl1-mesa-dri Version: 24.0.1-1 Severity: important Dear Maintainer, after the latest upgrade it's impossible for me to run a display manager or startx any window manager; after at most a few seconds / keypresses / mouse movements the screen freezes, completely unresponsive to anything other than the power button; the log below suggests a null pointer. Running "sleep 30; killall -u lorenzo" as root before startx returns me to a tty. Reverting to the previous version everything works. I'm running this on a debian derivative, devuan; afaik it shouldn't make a difference, as the package is unmodified from debian - I don't know how to verify that other than by installing debian in some partition, can one start some window manager from a debian chroot/whatever? If it's ok in debian or you need any more info please do let me know. -- Package-specific info: glxinfo: DISPLAY is not set. /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Oland [Radeon HD 8570 / R5 430 OEM / R7 240/340 / Radeon 520 OEM] [1002:6611] /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 0 /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 6.6.15-amd64 (debian-ker...@lists.debian.org) (gcc-13 (Debian 13.2.0-13) 13.2.0, GNU ld (GNU Binutils for Debian) 2.42) #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) Xorg X server log files on system: -- -rw-r--r-- 1 lorenzo lorenzo 48300 Sep 19 15:56 /home/lorenzo/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 rootroot39672 Feb 16 20:09 /var/log/Xorg.0.log -rw-r--r-- 1 lorenzo lorenzo 45226 Feb 17 12:58 /home/lorenzo/.local/share/xorg/Xorg.0.log Contents of most recent Xorg X server log file (/home/lorenzo/.local/share/xorg/Xorg.0.log): [ 2392.994] X.Org X Server 1.21.1.10 X Protocol Version 11, Revision 0 [ 2392.996] Current Operating System: Linux dudu 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 [ 2392.996] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.6.15-amd64 root=/dev/mapper/dev1-root ro quiet [ 2392.997] xorg-server 2:21.1.10-1devuan1 (https://www.devuan.org/os/community) [ 2392.998] Current version of pixman: 0.42.2 [ 2392.999] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 2392.999] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 2393.002] (==) Log file: "/home/lorenzo/.local/share/xorg/Xorg.0.log", Time: Sat Feb 17 12:58:09 2024 [ 2393.003] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 2393.003] (==) No Layout section. Using the first Screen section. [ 2393.003] (==) No screen section available. Using defaults. [ 2393.003] (**) |-->Screen "Default Screen Section" (0) [ 2393.003] (**) | |-->Monitor "" [ 2393.003] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 2393.003] (==) Automatically adding devices [ 2393.003] (==) Automatically enabling devices [ 2393.003] (==) Automatically adding GPU devices [ 2393.003] (==) Automatically binding GPU devices [ 2393.003] (==) Max clients allowed: 256, resource mask: 0x1f [ 2393.003] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 2393.003] Entry deleted from font path. [ 2393.003] (WW) The directory "/usr/share/fonts/X11/100dpi/" does not exist. [ 2393.003] Entry deleted from font path. [ 2393.003] (WW) The directory "/usr/share/fonts/X11/75dpi/" does not exist. [ 2393.003] Entry deleted from font path. [ 2393.003] (WW) The directory "/usr/share/fonts/X11/100dpi" does not exist. [ 2393.003] Entry deleted from font path. [ 2393.003] (WW) The directory "/usr/share/fonts/X11/75dpi" does not exist. [ 2393.003] Entry deleted from font path. [ 2393.003] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, built-ins [ 2393.003] (==) ModulePath set to "/usr/lib/xorg/modules" [ 2393.003] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 2393.003] (II) Loader magic: 0x55d77bd08ea0 [ 2393.003] (II) Module ABI versions: [ 2393.003] X.Org ANSI C Emulation: 0.4 [ 2393.003] X.Org Video Driver: 25.2 [ 2393.003] X.Org XInput driver : 24.4 [ 2393.003] X.Org Server Extension : 10.0
Bug#1063897: firefox: poor performance compared to vendor package
Package: firefox Version: 122.0.1-1 Severity: normal X-Debbugs-Cc: lorenzobertin...@gmail.com Dear Maintainer, Firefox on debian (both ESR and sid versions) is performing poorly. Here are the results on one of my machines, but it's consistent with all the others: Test: Browserbench Speedometer 2.1 (https://browserbench.org/Speedometer2.1) Gentoo: 290 (+65%) Debian sid with vendor package: 260 (+50%) Debian sid firefox: 175 (-) Debian sid firefox-esr: 160 (-10%) Upon inspection, I think the cause is the optimization flags, including LTO, PGO, O3. Please take this report in consideration, as the performance increase is massive. Kind regards -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages firefox depends on: ii debianutils 5.16 ii fontconfig 2.14.2-6+b1 ii libasound2 1.2.10-3 ii libatk1.0-0 2.50.0-1+b1 ii libc62.37-15 ii libcairo-gobject21.18.0-1+b1 ii libcairo21.18.0-1+b1 ii libdbus-1-3 1.14.10-4 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-2 ii libfontconfig1 2.14.2-6+b1 ii libfreetype6 2.13.2+dfsg-1+b1 ii libgcc-s114-20240201-3 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libglib2.0-0 2.78.3-2 ii libgtk-3-0 3.24.41-1 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.96.1-1 ii libpango-1.0-0 1.51.0+ds-4 ii libstdc++6 14-20240201-3 ii libvpx8 1.13.1-2 ii libx11-6 2:1.8.7-1 ii libx11-xcb1 2:1.8.7-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxrandr2 2:1.5.2-2+b1 ii procps 2:4.0.4-4 ii zlib1g 1:1.3.dfsg-3+b1 Versions of packages firefox recommends: ii libavcodec60 7:6.1.1-1 Versions of packages firefox suggests: pn fonts-lmodern pn fonts-stix | otf-stix ii libcanberra0 0.30-11 ii libgssapi-krb5-2 1.20.1-5+b1 pn pulseaudio -- no debconf information
Bug#1063819: dh-sysuser: uses deprecated given/when
Package: dh-sysuser
Version: 1.3.10+really1.4.4
Severity: normal
Tags: patch
X-Debbugs-Cc: Niko Tyni , plore...@disroot.org
Building runit package I have
create-stamp debian/debhelper-build-stamp
dh_testroot -O--sourcedirectory=runit-2.1.2/src
dh_prep -O--sourcedirectory=runit-2.1.2/src
dh_installdirs -O--sourcedirectory=runit-2.1.2/src
dh_auto_install -O--sourcedirectory=runit-2.1.2/src
dh_sysuser -O--sourcedirectory=runit-2.1.2/src
given is deprecated at /usr/bin/dh_sysuser line 37.
when is deprecated at /usr/bin/dh_sysuser line 38.
when is deprecated at /usr/bin/dh_sysuser line 39.
when is deprecated at /usr/bin/dh_sysuser line 46.
dh_install -O--sourcedirectory=runit-2.1.2/src
dh_installdocs -O--sourcedirectory=runit-2.1.2/src
dh_buildinfo -O--sourcedirectory=runit-2.1.2/src
so I guess it needs an update like in dh-runit's #1060709
What I'm not sure is if this need to be fixed in unstable as
possible or it can wait longer. The autopkgtest covers only
sysuser-helper, so the package does not fail to build.
Patch at the bottom.
Dear Niko, please bump the severity if this is urgent.
Regards,
Lorenzo
diff --git a/dh_sysuser b/dh_sysuser
index 74195f9..fbe9c30 100755
--- a/dh_sysuser
+++ b/dh_sysuser
@@ -34,17 +34,17 @@ init();
sub parse_options($conf, $options, $user) {
foreach my $opt (split(/,/, $options)) {
-given ($opt) {
-when (/^home=(.*)$/) { $conf->{home} = $1; }
-when (/^home$/) {
+for ($opt) {
+if (/^home=(.*)$/) { $conf->{home} = $1; }
+elsif (/^home$/) {
my $normal = $user;
$normal =~ s/^_+//; # strip leading
$normal =~ s/_+$//; # and trailing underscore
$normal =~ s/^[Dd]ebian-//; # and discouraged debian- prefix
$conf->{home} = "/var/lib/$normal";
}
-when (/^defaults$/) { "do nothing"; }
-default { error("unknown option `$opt'"); }
+elsif (/^defaults$/) { "do nothing"; }
+else { error("unknown option `$opt'"); }
}
}
}
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages dh-sysuser depends on:
ii perl 5.38.2-3
dh-sysuser recommends no packages.
dh-sysuser suggests no packages.
-- no debconf information
Bug#1057098: RFS: runit/2.1.2-57 -- system-wide service supervision
Control: tags -1 -moreinfo Hi Tobi, thanks for having a look at this package :) Uploaded again to mentors with the following changes: - removed message in preinst (no longer useful, see below) - cleaned up obsolete lintian tag to avoid a new lintian error new links: https://mentors.debian.net/package/runit/ dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-57.dsc Git repo (updated): https://salsa.debian.org/debian/runit/-/tree/next?ref_type=heads > There is a lintian warning: > W debian-news-entry-has-unknown-version > 2.1.2-14 [usr/share/doc/getty-run/NEWS.Debian.gz:1] this was fixed in Debhelper [1], now the NEWS file is automatically trimmed > the warning of unmerged systems will stop booting soon MUST > be in Debian.NEWS, preinst is the wrong place and it will be > very likely missed. NEWS is a well-known mechanism to convey > important information. > > On the other hand, is this warning acutally required? Once this will > get a real issue, Depend: on usr-is-merged and you should > be set. If you cannot tell when that is, enforce it now, as non-merged > systems are no longer supported anyway. > The message was targeted downstream (especially Devuan) where the merged layout is not enforced but no plan was made to actively support unmerged layout. A relevant share of users in testing/unstable where running with the system not merged with no clue that the system was about to break. The problem with the NEWS file is that people don't have apt-listchanges installed and also the NEWS can't be displayed conditionally (only to unmerged systems). The message is already in runit_2.1.2-54+usrmerge (unstable/testing) and subsequently a long discussion started both on Devuan-users mailing list and the Devuan forum, so users are no longer unaware of the issue and I'm satisfied with that. (unmerged systems are already broken now so the message is no longer useful) > > TL:DR: init-system-helpers is Essential: Yes, so you can already now > Depend: on usr-is-merged if you want to make sure. > (That will also cover where people held init-systems-helpers to an > older > I prefer if this is dealt at distro level (downstream), so they either provide support for unmerged layout or they enforce the merge. Best Regards, Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%231021607
Bug#1063531: RFS: mplayer/2:1.5+svn38446-2 -- movie player for Unix-like systems
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "mplayer": * Package name : mplayer Version : 2:1.5+svn38446-2 Upstream contact : [fill in name and email of upstream] * URL : https://mplayerhq.hu * License : LGPL-2.1+, Expat, ISC, public-domain-tom, GPL-2+, BSD-2-Clause, other-2, other-1 * Vcs : https://salsa.debian.org/multimedia-team/mplayer Section : video The source builds the following binary packages: mplayer-gui - movie player for Unix-like systems (GUI variant) mencoder - MPlayer's Movie Encoder mplayer - movie player for Unix-like systems mplayer-doc - documentation for MPlayer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mplayer/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mplayer/mplayer_1.5+svn38446-2.dsc Git repo: https://salsa.debian.org/multimedia-team/mplayer/-/tree/next?ref_type=heads Changes since the last upload: mplayer (2:1.5+svn38446-2) unstable; urgency=medium . * build a noaltivec variant of mplayer for powerpc * install alternatives for mplayer-altivec and mplayer-noaltivec on powerpc; the altivec variant has the highest priority (Closes: #410962) * d/control: B-D: - add dh-exec - replace obsolete pkg-config with pkgconf Regards, Lorenzo
Bug#1062683: RFS: runit-services/0.7.1 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.7.1 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : GPL-2.0+, BSD-3-Clause, CC0-1.0, GPL-3+ * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.1.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads Changes since the last upload: runit-services (0.7.1) experimental; urgency=medium . * Fix piuparts failure in package removal (Closes: #1062682) * update years in copyright.in and regenerate d/copyright Regards, Lorenzo
Bug#1062682: runit-services: fails to remove (prerm) (piuparts)
Package: runit-services Version: 0.7.0 Severity: important Tags: patch X-Debbugs-Cc: plore...@disroot.org when one wants to remove this package dpkg fails with [1] (Reading database ... 5625 files and directories currently installed.) Removing runit-services (0.7.0) ... cat: /usr/share/runit/sv/acpi-fakekey/.meta/onupgrade: No such file or directory dpkg: error processing package runit-services (--remove): installed runit-services package pre-removal script subprocess returned error exit status 1 dpkg: too many errors, stopping Errors were encountered while processing: runit-services Processing was halted because there were too many errors. E: Sub-process /usr/bin/dpkg returned an error code (1) this affects version of the package that are build with dh_runit>=2.16 (currently in unstable); 0.5.5 is not affected right now but it could be if a no-change rebuild is triggered in unstable for some reason. patch: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/commit/407919bcf17fd2560f86194badaeced2f528b1af [1] https://piuparts.debian.org/experimental/fail/runit-services_0.7.0.log -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit-services depends on: ii runit 2.1.2-57 ii runit-helper 2.16.2 Versions of packages runit-services recommends: ii runit-init 2.1.2-57 Versions of packages runit-services suggests: ii socklog 2.1.0+repack-5 -- no debconf information
Bug#1040168: The default orientation of a video in mplayer is wrong
Control: severity -1 wishlist On Sun, 2 Jul 2023 19:49:28 +0200 AlMa wrote: > Package: mplayer > Version: 2:1.5+svn38408-1 > > The video in the attachment is supposed to be oriented in a way such > that the ground and water is below, and the sky is above. VLC does > this without any options (and `mplayer -vf rotate=0` and `mplayer -vf > rotate`). However, the default orientation in mplayer is wrong; what > I see is the video on the side. > > Please improve mplayer in this respect. Hi, This issue needs work upstream and giving the low activity there I don't think there will be a patch soon. Also, according to upstream, rotation was never applied by default due to performance impact, so this is a new feature request rather than a regression. And the one time fix (that is, add vf-pre=rotate to mplayer.conf[1]) on user side is cheap enough to consider this a wishlist bug. possible future development can be followed upstream at https://trac.mplayerhq.hu/ticket/2415 Lorenzo [1] I tested this with the video provided and it works, it may not work with some other -vo, not sure. > > Gratefully, > AlMa
Bug#1059930: runit-init: needs conflict with molly-guard before moving shutdown links
On Wed, 03 Jan 2024 20:23:38 +0100 Lorenzo Puliti wrote: > Package: runit-init > Version: 2.1.2-56 > Severity: important > Tags: patch > X-Debbugs-Cc: Helmut Grohne , plore...@disroot.org > > Hello, > > If I undestrand correctly (there was a PM from Helmut explaining this > to me, but it was before [1]) in the PM you talked about a Breaks on molly-guard side, but looking at the package in sid I don't see any Breaks: so I assume that part is outdated (?)
Bug#1059930: runit-init: needs conflict with molly-guard before moving shutdown links
Package: runit-init
Version: 2.1.2-56
Severity: important
Tags: patch
X-Debbugs-Cc: Helmut Grohne , plore...@disroot.org
Hello,
If I undestrand correctly (there was a PM from Helmut explaining this
to me, but it was before [1]) runit init needs a conflicts with
molly-guard when it moves halt, poweroff, etc.. links from /sbin
to /usr/sbin. Now, following patches already applied to systemd
and reading [2], I'm attempting a patchset for runit-init.
[I know it's holiday time and I'm not in a rush for this]
Helmut, could you have a look (patches attached)?
* Is molly-guard enough or do I need to consider other packages?
I'm excluding progress-linux-container and bfh-container since
they depends on systemd-sysv
* the conflicts is in patch 003, restore the links is in 004
* note that for consistency I'm also moving runit's shutdown
from /lib/runit/ to /usr/lib/runit. For that I have to bump
the Depends to the latest runit (patch 001), I hope that it
doesn't create issues to the apt resolver
Many thanks,
Lorenzo
[1] https://lists.debian.org/debian-devel/2023/12/msg00020.html
[2] https://lists.debian.org/debian-devel/2024/01/msg00025.html
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages runit-init depends on:
ii getty-run2.1.2-56
ii initscripts 3.08-1
ii insserv 1.24.0-1
ii mount2.39.2-1
ii runit2.1.2-56
Versions of packages runit-init recommends:
ii runit-services 0.7.0
runit-init suggests no packages.
-- no debconf information
>From 798a86a24e582a20295741ef808121fe06abcba3 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Wed, 3 Jan 2024 15:01:17 +0100
Subject: [PATCH 1/4] runit: move shutdown to /usr/lib/runit
runit: move shutdown under /usr
runit-init: adjust symlink (halt,poweroff,shutdown,reboot) targets
to point to /usr/lib/runit/shutdown; Depends on runit >= 2.1.2-57
---
debian/control | 2 +-
debian/runit-init.links | 8
debian/runit.install| 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/debian/control b/debian/control
index 3e254a2..1fea2ed 100644
--- a/debian/control
+++ b/debian/control
@@ -71,7 +71,7 @@ Description: runscripts to supervise getty processes
Package: runit-init
Architecture: any
-Depends: runit (>= 2.1.2-43~), ${misc:Depends},
+Depends: runit (>= 2.1.2-57~), ${misc:Depends},
${shlibs:Depends}, getty-run, insserv, initscripts, mount [linux-any]
Breaks: ${runit:Breaks}
Replaces: systemd-sysv, sysvinit-core
diff --git a/debian/runit-init.links b/debian/runit-init.links
index 84d5822..ef10f73 100644
--- a/debian/runit-init.links
+++ b/debian/runit-init.links
@@ -4,9 +4,9 @@
/usr/share/man/man8/runit-shutdown.8.gz /usr/share/man/man8/shutdown.8.gz
/usr/share/man/man8/runit-init.8.gz /usr/share/man/man8/init.8.gz
/usr/share/man/man8/runit-runlevel.8.gz /usr/share/man/man8/runlevel.8.gz
-/lib/runit/shutdown /sbin/halt
-/lib/runit/shutdown /sbin/reboot
-/lib/runit/shutdown /sbin/poweroff
-/lib/runit/shutdown /sbin/shutdown
+/usr/lib/runit/shutdown /sbin/halt
+/usr/lib/runit/shutdown /sbin/reboot
+/usr/lib/runit/shutdown /sbin/poweroff
+/usr/lib/runit/shutdown /sbin/shutdown
/lib/runit/runlevel /sbin/runlevel
/lib/runit/runit-init /sbin/init
diff --git a/debian/runit.install b/debian/runit.install
index 04c1954..4fc9bf9 100644
--- a/debian/runit.install
+++ b/debian/runit.install
@@ -27,7 +27,7 @@ debian/contrib/lib/trigger_sv /lib/runit
runit-2.1.2/src/runit-init /lib/runit
runit-2.1.2/src/runit /sbin
-debian/contrib/shutdown /lib/runit
+debian/contrib/shutdown /usr/lib/runit
debian/contrib/runlevel /lib/runit
debian/sv/sulogin/run /etc/runit/runsvdir/single/sulogin
debian/sv/svlogd/ /etc/sv/
--
2.40.1
>From 656e677e9a08eabcb27b2c13404b7acfd3cea83e Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Wed, 3 Jan 2024 15:37:16 +0100
Subject: [PATCH 2/4] runit-init: move shutdown links to /usr/sbin/
* Move halt, poweroff, reboot, shutdown symlinks to /usr/sbin/
* update runit-shutdown(8) manpage in runit package
---
debian/contrib/shutdown.8 | 8
debian/runit-init.links | 8
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/debian/contrib/shutdown.8 b/debian/contrib/shutdown.8
index 15590e5..cf6956d 100644
--- a/debian/contrib/shutdown.8
+++ b/debian/contrib/shutdown.8
@@ -2,13 +2,13 @@
.SH NAME
shutdown, reboot, poweroff \- poweroff or reboot the system
.SH SYNOPSIS
-.B
Bug#1059559: runit: isolation-machine autopkgtest fails: this is a protected package; it should not be removed
Control: tags -1 patch On Thu, 28 Dec 2023 11:38:43 +0100 Paul Gevers wrote: > Source: runit > Version: 2.1.2-54+usrmerge > Severity: important > User: debian...@lists.debian.org > Usertags: isolation-machine > > Dear maintainer(s), > > Your package has an autopkgtest, great. I recently added support for > isolation-machine tests on ci.debian.net for amd64 and added your > package to the list to use that. Thanks > However, it fails. Can you please > investigate the situation and fix it? I copied some of the output at > the bottom of this report. patch that fixes the test is attached. Lorenzo >From fbc87e15eccab68febb506bf39ffb9f68a3a5e2f Mon Sep 17 00:00:00 2001 From: Lorenzo Puliti Date: Mon, 1 Jan 2024 14:57:45 +0100 Subject: [PATCH] Fix init-switch test * pass the right --force-* option to dpkg in order to remove the init package. This bug was silent until init-system-helpers 1.66 added "Protected: yes" to the init package. * pass service name without full path to update-service so that it doesn't fail when it can't find the service in /etc/sv/ . This is necessary because runit 2.1.2-55 and 2.1.2-56 changed the service layout. * allow stderr, because dpkg prints warnings there when used with --force-remove-protected ; the test is changed so that it fails by default and only succeed when the second reboot is done Closes: #1059559 --- debian/tests/control | 2 +- debian/tests/init-switch | 10 ++ 2 files changed, 7 insertions(+), 5 deletions(-) diff --git a/debian/tests/control b/debian/tests/control index ffa61ed..c48dcc1 100644 --- a/debian/tests/control +++ b/debian/tests/control @@ -6,7 +6,7 @@ Depends: runit, dbus, udev, runit-services, -Restrictions: needs-root, isolation-machine, breaks-testbed +Restrictions: needs-root, allow-stderr, isolation-machine, breaks-testbed Tests: install-953875 Depends: systemd, diff --git a/debian/tests/init-switch b/debian/tests/init-switch index b6e608a..2c35332 100755 --- a/debian/tests/init-switch +++ b/debian/tests/init-switch @@ -48,10 +48,10 @@ if [ -z "$AUTOPKGTEST_REBOOT_MARK" ]; then echo "installing runit-init" #2 steps because of changes in apt(2.3.12) #1005881 #apt-get remove -y -allow-remove-essential init # no longer worksuse dpkg - dpkg -r --force-remove-essential init + dpkg -r --force-remove-protected init apt-get install -y runit-init ls -l /etc/service/ - update-service --remove /etc/sv/dbus.dep-fixer + update-service --remove dbus.dep-fixer if [ -e /tmp/autopkgtest-reboot ]; then if [ ! -h /etc/service/getty-ttyS0 ]; then echo "WARNING: serial getty is disabled" @@ -76,6 +76,8 @@ elif [ "$AUTOPKGTEST_REBOOT_MARK" = runit1 ]; then else check_init_is_runit check_services_are_running - echo "switching to runit init complete" + echo "init-switch test completed" + echo "OK: test done" && exit 0 fi -echo "test done" + +echo "FAIL: init-switch test failed" && exit 1 -- 2.40.1
Bug#1057961: RFS: mplayer/2:1.5+svn38446-1 [RC] -- movie player for Unix-like systems
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "mplayer": * Package name : mplayer Version : 2:1.5+svn38446-1 Upstream contact : [fill in name and email of upstream] * URL : https://mplayerhq.hu * License : LGPL-2.1+, Expat, ISC, public-domain-tom, GPL-2+, BSD-2-Clause, other-2, other-1 * Vcs : https://salsa.debian.org/multimedia-team/mplayer Section : video The source builds the following binary packages: mplayer-gui - movie player for Unix-like systems (GUI variant) mencoder - MPlayer's Movie Encoder mplayer - movie player for Unix-like systems mplayer-doc - documentation for MPlayer To access further information about this package, please visit the following URL: https://mentors.debian.net/package/mplayer/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/mplayer/mplayer_1.5+svn38446-1.dsc git repo: https://salsa.debian.org/multimedia-team/mplayer/-/tree/next?ref_type=heads Changes since the last upload: mplayer (2:1.5+svn38446-1) unstable; urgency=medium . [ Lorenzo Puliti ] * New upstream version 1.5+svn38446 - fix FTBFS (Closes: #1057579) - d/control: B-D: switch to nasm - avoid crahes when -wid specifies an invalid Window ID, see #1034867 - fix ID_VID_0_ROTATE, relevant for #1040168 . [ Vagrant Cascadian ] * debian/rules: Use printf instead of echo. (Closes: #1039457) [ Paul Wise ] * improve printf line in d/rules. Regards, Lorenzo
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
Hi,
On Fri, 1 Dec 2023 13:27:58 +0100
tito wrote:
> Hi,
> but the file is still referenced in /etc/init.d/mdadm
>
> # grep /etc/default/mdadm /etc/init.d/mdadm*
> /etc/init.d/mdadm:DEBIANCONFIG=/etc/default/mdadm
>
> from the 5 variables set in /etc/default/mdadm:
>
> AUTOCHECK, AUTOSCAN, VERBOSE at a first glance are ignored
>
> START_DAEMON has already been moved to the initscript
> so that from the /etc/default/mdadm you can only turn
> the initscript off.
>
> I would propose to move DAEMON_OPTIONS="--syslog"
> to the initscript so that we can forget about
> /etc/default/mdadm.
I'm attaching the amended patch so that the script works without
/etc/default/mdadm, but it still includes the file if it's there
>
> The cronjob that will be removed soon is still a problem as it checks
> the arrays periodically
I'm not saying that it's not a problem, but I think it's a separate bug.
Also, before doing any attempts on this, Matthew has to say if he's ok
with maintaining cronjobs in this package and if yes, how this should
be done.
Best,
Lorenzo
From f748a8eb84b3331a7c0b71aa255064ab6810be02 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Fri, 1 Dec 2023 02:19:27 +0100
Subject: [PATCH] Add mdadm and mdadm-waitidle scripts
Add scripts dropped from mdadm 4.2+20230227-1 on 28 Feb 2023
The script is changed so that it no longer needs /etc/default/mdadm
Closes: #1055645
---
debian/copyright | 8 +++
lib/mapping| 2 +
scripts/mdadm | 101 +
scripts/mdadm-waitidle | 60
scripts/mdadm-waitidle.md5sums | 1 +
scripts/mdadm.md5sums | 1 +
6 files changed, 173 insertions(+)
create mode 100755 scripts/mdadm
create mode 100755 scripts/mdadm-waitidle
create mode 100644 scripts/mdadm-waitidle.md5sums
create mode 100644 scripts/mdadm.md5sums
diff --git a/debian/copyright b/debian/copyright
index 905292d..6746261 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -37,6 +37,14 @@ Copyright: 1997-2002, Remco Treffkorn
License: BSD-3-clause
Comment: Salsa debian-gps-team/pkg-gpsd 026301b71
+Files: scripts/mdadm*
+Copyright: 2001-2005 Mario Jou/3en
+2005-2008 Martin F. Krafft
+2018 Dimitri John Ledkov
+2019 Felix Lechner
+License: GPL-2+
+Comment: Salsa debian/mdadm 140efd48
+
Files: scripts/network-manager
Copyright: 2004 - 2016 Red Hat, Inc.
2005 - 2009 Novell, Inc.
diff --git a/lib/mapping b/lib/mapping
index c1b867d..c0cf8cb 100644
--- a/lib/mapping
+++ b/lib/mapping
@@ -9,6 +9,8 @@ dirsrv.service dirsrv
dnscrypt-proxy.service dnscrypt-proxy
firewalld.service firewalld
gpsd.service gpsd
+mdadm-waitidle.service mdadm-waitidle
+mdadm.service mdadm
nftables.service nftables
pdns.service pdns
rsyslog.service rsyslog
diff --git a/scripts/mdadm b/scripts/mdadm
new file mode 100755
index 000..e98f74f
--- /dev/null
+++ b/scripts/mdadm
@@ -0,0 +1,101 @@
+#!/bin/sh
+#
+# Start the MD monitor daemon for all active MD arrays if desired.
+# This script is not used under systemd.
+#
+# Copyright © 2001-2005 Mario Jou/3en
+# Copyright © 2005-2009 Martin F. Krafft
+# Distributable under the terms of the GNU GPL version 2.
+#
+### BEGIN INIT INFO
+# Provides: mdadm
+# Required-Start:$local_fs $syslog
+# Required-Stop: $local_fs $syslog sendsigs
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: MD monitoring daemon
+# Description: mdadm provides a monitor mode, in which it will scan for
+#problems with the MD devices. If a problem is found, the
+#administrator is alerted via email, or a custom script is
+#run.
+### END INIT INFO
+#
+set -eu
+
+MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
+RUNDIR=/run/mdadm
+PIDFILE=$RUNDIR/monitor.pid
+DEBIANCONFIG=/etc/default/mdadm
+DAEMON_OPTIONS="--syslog"
+
+test -x "$MDADM" || exit 0
+
+test -f /proc/mdstat || exit 0
+
+START_DAEMON=true
+test -f $DEBIANCONFIG && . $DEBIANCONFIG
+
+. /lib/lsb/init-functions
+
+is_true()
+{
+ case "${1:-}" in
+[Yy]es|[Yy]|1|[Tt]|[Tt]rue) return 0;;
+*) return 1;
+ esac
+}
+
+case "${1:-}" in
+ start)
+if [ -x /usr/bin/systemd-detect-virt ] && /usr/bin/systemd-detect-virt --quiet --container; then
+ log_daemon_msg "Not starting MD monitoring service in container"
+ log_end_msg 0
+ exit 0
+fi
+
+if is_true $START_DAEMON; then
+ log_daemon_msg "Starting MD monitoring service" "mdadm --monitor"
+ mkdir -p $RUNDIR
+ set +e
+ start-stop-daemon -S -p $PIDFILE -x $MDADM -- \
+--monitor --pid-file $PIDFILE --daemonise --scan ${DAEMON_OPTIONS:-}
+ log_end_msg $?
+ set
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
On Fri, 1 Dec 2023 07:53:57 +0100 tito wrote: > > > > > > Even the cronjob is gone. > > > > sorry, the patch does not include cronjob since o-s-s does not have > > a way to handle it. > > Couldn't it be appended to crontab? there is no mechanism to selectively add (and remove/purge) additional file or snippets such as cronjobs or /etc/default/* > Hi, > shouldn't /etc/default/mdadm be moved also to o-s-s? > I bet it is the next file to be dropped after timers can't find the file, even in buster https://packages.debian.org/buster/amd64/mdadm/filelist Well, I have it on my system but same problem as for the cronjob $ cat /etc/default/mdadm # mdadm Debian configuration # # You can run 'dpkg-reconfigure mdadm' to modify the values in this file, if # you want. You can also change the values here and changes will be preserved. # Do note that only the values are preserved; the rest of the file is # rewritten. # # AUTOCHECK: # should mdadm run periodic redundancy checks over your arrays? See # /etc/cron.d/mdadm. AUTOCHECK=true # AUTOSCAN: # should mdadm check once a day for degraded arrays? See # /lib/systemd/system/mdmonitor-oneshot.service AUTOSCAN=true # START_DAEMON: # should mdadm start the MD monitoring daemon during boot? START_DAEMON=true # DAEMON_OPTIONS: # additional options to pass to the daemon. DAEMON_OPTIONS="--syslog" # VERBOSE: # if this variable is set to true, mdadm will be a little more verbose e.g. # when creating the initramfs. VERBOSE=false Lorenzo > > Ciao, > Tito
Bug#1055645: orphan-sysvinit-scripts: Please take over mdadm init script
Control: tags -1 patch
Hello Matthew,
attached is a git patch that adds mdadm and mdadm-waitidle
scripts.
On Thu, 9 Nov 2023 16:09:22 +0100
Stephan Seitz wrote:
> [...]
> * Removing cron jobs in favour of systemd timers:
> - daily checks also work if system is not always on (Closes:
> #889978).
I thought that anacron could handle this..
>
> Even the cronjob is gone.
sorry, the patch does not include cronjob since o-s-s does not have
a way to handle it.
By the way I don't remember a project consensus for dropping
cronjobs in favour of timers..
Best Regards,
Lorenzo
From e5179d055f6958638b0319bba25562b3e6b77f5e Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Fri, 1 Dec 2023 02:19:27 +0100
Subject: [PATCH] Add mdadm and mdadm-waitidle scripts
Add scripts dropped from mdadm 4.2+20230227-1 on 28 Feb 2023
---
debian/copyright | 8 +++
lib/mapping| 2 +
scripts/mdadm | 100 +
scripts/mdadm-waitidle | 60
scripts/mdadm-waitidle.md5sums | 1 +
scripts/mdadm.md5sums | 1 +
6 files changed, 172 insertions(+)
create mode 100755 scripts/mdadm
create mode 100755 scripts/mdadm-waitidle
create mode 100644 scripts/mdadm-waitidle.md5sums
create mode 100644 scripts/mdadm.md5sums
diff --git a/debian/copyright b/debian/copyright
index 905292d..6746261 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -37,6 +37,14 @@ Copyright: 1997-2002, Remco Treffkorn
License: BSD-3-clause
Comment: Salsa debian-gps-team/pkg-gpsd 026301b71
+Files: scripts/mdadm*
+Copyright: 2001-2005 Mario Jou/3en
+2005-2008 Martin F. Krafft
+2018 Dimitri John Ledkov
+2019 Felix Lechner
+License: GPL-2+
+Comment: Salsa debian/mdadm 140efd48
+
Files: scripts/network-manager
Copyright: 2004 - 2016 Red Hat, Inc.
2005 - 2009 Novell, Inc.
diff --git a/lib/mapping b/lib/mapping
index c1b867d..c0cf8cb 100644
--- a/lib/mapping
+++ b/lib/mapping
@@ -9,6 +9,8 @@ dirsrv.service dirsrv
dnscrypt-proxy.service dnscrypt-proxy
firewalld.service firewalld
gpsd.service gpsd
+mdadm-waitidle.service mdadm-waitidle
+mdadm.service mdadm
nftables.service nftables
pdns.service pdns
rsyslog.service rsyslog
diff --git a/scripts/mdadm b/scripts/mdadm
new file mode 100755
index 000..0a9004f
--- /dev/null
+++ b/scripts/mdadm
@@ -0,0 +1,100 @@
+#!/bin/sh
+#
+# Start the MD monitor daemon for all active MD arrays if desired.
+# This script is not used under systemd.
+#
+# Copyright © 2001-2005 Mario Jou/3en
+# Copyright © 2005-2009 Martin F. Krafft
+# Distributable under the terms of the GNU GPL version 2.
+#
+### BEGIN INIT INFO
+# Provides: mdadm
+# Required-Start:$local_fs $syslog
+# Required-Stop: $local_fs $syslog sendsigs
+# Default-Start: 2 3 4 5
+# Default-Stop: 0 1 6
+# Short-Description: MD monitoring daemon
+# Description: mdadm provides a monitor mode, in which it will scan for
+#problems with the MD devices. If a problem is found, the
+#administrator is alerted via email, or a custom script is
+#run.
+### END INIT INFO
+#
+set -eu
+
+MDADM=/sbin/mdadm
+MDMON=/sbin/mdmon
+RUNDIR=/run/mdadm
+PIDFILE=$RUNDIR/monitor.pid
+DEBIANCONFIG=/etc/default/mdadm
+
+test -x "$MDADM" || exit 0
+
+test -f /proc/mdstat || exit 0
+
+START_DAEMON=true
+test -f $DEBIANCONFIG && . $DEBIANCONFIG
+
+. /lib/lsb/init-functions
+
+is_true()
+{
+ case "${1:-}" in
+[Yy]es|[Yy]|1|[Tt]|[Tt]rue) return 0;;
+*) return 1;
+ esac
+}
+
+case "${1:-}" in
+ start)
+if [ -x /usr/bin/systemd-detect-virt ] && /usr/bin/systemd-detect-virt --quiet --container; then
+ log_daemon_msg "Not starting MD monitoring service in container"
+ log_end_msg 0
+ exit 0
+fi
+
+if is_true $START_DAEMON; then
+ log_daemon_msg "Starting MD monitoring service" "mdadm --monitor"
+ mkdir -p $RUNDIR
+ set +e
+ start-stop-daemon -S -p $PIDFILE -x $MDADM -- \
+--monitor --pid-file $PIDFILE --daemonise --scan ${DAEMON_OPTIONS:-}
+ log_end_msg $?
+ set -e
+fi
+if [ "$(echo $RUNDIR/md[0-9]*.pid)" != "$RUNDIR/md[0-9]*.pid" ]; then
+ log_daemon_msg "Restarting MD external metadata monitor" "mdmon --takeover --all"
+ set +e
+ $MDMON --takeover --all
+ log_end_msg $?
+ set -e
+fi
+;;
+ stop)
+if [ -f $PIDFILE ] ; then
+ log_daemon_msg "Stopping MD monitoring service" "mdadm --monitor"
+ set +e
+ start-stop-daemon -K -p $PIDFILE -x $MDADM
+ rm -f $PIDFILE
+ log_end_msg $?
+ set -e
+fi
+for file in $RUNDIR/md[0-9]*.pid ; do
+ [ ! -f "$file" ] && continue
+ ln -sf $file /run/sendsigs.
Bug#1057098: RFS: runit/2.1.2-57 -- system-wide service supervision
Package: sponsorship-requests
Severity: normal
Dear mentors,
I am looking for a sponsor for my package "runit":
* Package name : runit
Version : 2.1.2-57
Upstream contact : Gerrit Pape
* URL : http://smarden.org/runit/
* License : BSD-3-clause, GPL-3+, CC0-1.0
* Vcs : https://salsa.debian.org/debian/runit
Section : admin
The source builds the following binary packages:
runit - system-wide service supervision
runit-run - service supervision (systemd and sysv integration)
getty-run - runscripts to supervise getty processes
runit-init - system-wide service supervision (as init system)
To access further information about this package, please visit the
following URL:
https://mentors.debian.net/package/runit/
Alternatively, you can download the package with 'dget' using this
command:
dget -x
https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-57.dsc
git:
https://salsa.debian.org/debian/runit/-/tree/next?ref_type=heads
Changes since the last upload:
runit (2.1.2-57) experimental; urgency=medium
.
* Stage {1,2,3,} and ctraltdel: change PATH order
* runit.preinst: print a message on unmerged systems
warning that such configuration is expected
to fail to boot very soon.
* trigger_sv: incorporate sv_wtime code (Closes: #1057095)
* invoke-run: improve test for bin metafile
* 40-runit: forward non standard actions to
sysv scripts (Closes: #1057094)
* Drop runit-systemd empty package,
it's an empty transitional package since
Bullseye (Closes: #1038301)
Regards,
Lorenzo
Bug#1057095: runit trigger_sv missing services restart
Package: runit Version: 2.1.2-56 Severity: normal X-Debbugs-Cc: plore...@disroot.org Control: affects -1 runit-services the /lib/runit/trigger_sv code sometime fails to restart a service on the services package upgrade - this is a regression compared to 2.1.2-55, and it depends on where is the service in the filesystem. Sometimes I think it also misses enable/disable of services. This is because of recent changes in trigger_sv code. Note that this is a separate and unrelated issue to #1043419; the trigger here is activated but it does not work as expected. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.37-10 ii runit-helper2.16.1 ii sysuser-helper 1.3.9+really1.4.3 Versions of packages runit recommends: ii runit-init 2.1.2-56 Versions of packages runit suggests: ii runit-services 0.7.0 ii socklog 2.1.0+repack-5 ii ucspi-unix 1.0-2 pn zsh -- Configuration Files: /etc/default/runit changed [not included] /etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: '/etc/runit/runsvdir/single/sulogin/run' -- no debconf information -- debsums errors found: debsums: changed file /lib/lsb/init-functions.d/40-runit (from runit package) debsums: changed file /lib/runit/trigger_sv (from runit package)
Bug#1057094: runit: lsb 40-runit does not forward sysv nonstandard actions
Package: runit Version: 2.1.2-56 Severity: normal X-Debbugs-Cc: plore...@disroot.org Control: affects -1 runit-services This was reported downstream but it affects Debian as well; runit uses /lib/lsb/init-functions.d/40-runit code to intercept calls to sysvinit scripts, when on the system an equivalent native runit services exists. This is to avoid conflicts and duplicate instances. However sysv scripts can define non standard actions (such as log rotation) that are not defined in runit's sv(8) control program. So it could be useful to forward such actions to the sysv script even when there is a runit services active. An example where this is useful is rsyslogd and many httpd servers. It should be considered that this strategy is not guaranteed to work, but it This strategy works for services that I've considered so far but it may not work for others: the sysv script uses the PID file (likely in /run/) while runit (actually runsv) maintain the PID process in it's own file inside the service directory, so a mismatch will break this. the alternative would be to define runit timers or oneshots companion services for each non standard actions but it's too expensive for now -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit depends on: ii libc6 2.37-10 ii runit-helper2.16.1 ii sysuser-helper 1.3.9+really1.4.3 Versions of packages runit recommends: ii runit-init 2.1.2-56 Versions of packages runit suggests: ii runit-services 0.7.0 ii socklog 2.1.0+repack-5 ii ucspi-unix 1.0-2 pn zsh -- Configuration Files: /etc/default/runit changed [not included] /etc/runit/runsvdir/single/sulogin/run [Errno 2] No such file or directory: '/etc/runit/runsvdir/single/sulogin/run' -- no debconf information -- debsums errors found: debsums: changed file /lib/lsb/init-functions.d/40-runit (from runit package) debsums: changed file /lib/runit/trigger_sv (from runit package)
Bug#1043419: raising missing trigger interest to serious
Hi Helmut, On Sat, 18 Nov 2023 17:40:23 +0100 Helmut Grohne wrote: First the actionable part: > Is there actually any issue with promoting the change from > experimental to unstable? Yes: the version in experimental is definitely RC buggy, for reasons unrelated to usrmerge > If you lack a sponsor, I am willing to help > out once to get this fixed. Thanks, really appreciated: I prepared a runit_2.1.2-54+usrmerge runit upload targeted at unstable with two commits backported, you can find it on mentors https://mentors.debian.net/package/runit/ dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-54+usrmerge.dsc and on salsa (usrmerge branch) https://salsa.debian.org/debian/runit/-/tree/usrmerge?ref_type=heads let me know if something else is needed for this upload. Now the annoying part: > it still affects > trixie and sid, so by raising it to serious, we get rid of the bug in > trixie before too long (either via upload or autoremove). > [...] However, runit's triggers do > not work anymore. That's a serious bug and we're tracking it like > that. I disagree about the severity (it should be assessed by looking at the broken feature that is provided by the trigger) and especially I disagree that the malfunction of this specific feature should cause the removal of runit from testing (and the same goes for any other alternative init system). I'm stopping here as I think you don't want to spend further time on this bug since it can be fixed with an upload, but I can elaborate if you want me to. Best Regards, Lorenzo > > Helmut > > >
Bug#1043419: raising missing trigger interest to serious
Hi Helmut, On Sat, 18 Nov 2023 09:19:46 +0100 Helmut Grohne wrote: > Control: severity -1 serious > Could you please clarify how this is blocking the usrmerge transition, besides runit itself missing a trigger? Lorenzo > I am raising the bug about missing trigger interest to severity > serious. The systemd package has now moved its units to > /usr/lib/systemd and debhelper will also now install its units there. > Hence, the trigger is now practically broken. I know that the bug is > already fixed in experimental and that's great, but it still affects > trixie and sid, so by raising it to serious, we get rid of the bug in > trixie before too long (either via upload or autoremove). > > Helmut
Bug#1055310: Should recommend xdg-utils
Package: syncthing Version: 1.19.2~ds1-1+b4 Syncthing makes use of xdg-open to launch the web interface, therefore xdg-utils (package which contains xdg-open) should be added at least as a recommended dependency. Output when launching syncthing-ui.desktop or: $ /usr/bin/syncthing -browser-only WARNING: Failed to open web UI: exec: "xdg-open": executable file not found in $PATH
Bug#1054009: RFS: runit-services/0.7.0 -- UNIX init scheme with service supervision (services)
Hi Nicholas, On Mon, 16 Oct 2023 15:26:50 -0400 Nicholas D Steeves wrote: > I'm unfamiliar with runit, but does anything need to be done in the > mini-httpd package to support your work in this upload? there's no need for anything on mini-httpd side, however I plan to do a QA upload (a NEWS file) and later a RoQA for for mini-httpd-run. I will really appreciate if you are available to help with this. I didn't think deeply but my plan is roughly the following: * have the mini-httpd runscript added to runit-services * QA upload to mini-httpd-run, with a NEWS file (package scheduled for removal + instruction to migrate to runit-services). > I'd recommend filing a bug against > mini-httpd-run shortly after the upload of runit-services_0.7.0, > because otherwise someone might potentially see a neglected package > and then adopt it. This bug would make the plan from your commit > message more visible and official. Right, I need to file a bug at this point or shortly before the QA upload * (after trixie): RoQA for removal of the mini-httpd-run package (reason: orphaned, low popcon count, maintained alternative exists, small package design rejected by FTP masters in the past) > > Also, thank you for thinking about smoothing the transition for users > by using Provides; although, I wonder how this will actually function, > because mini-httpd-run's version 1.0+nmu1 >> runit-services' 0.7.0. I'm not entirely sure how Provides works: my hope is that with the current unversioned provides, when mini-httpd-run is removed and one does "apt-get install mini-httpd-run" apt will at least throw a warning saying that the package has no candidate to install but another package (runit-services) provides it. > You're right, Conflicts isn't required and it doesn't seem like Breaks > would be appropriate either. Have you considered using versioned > Provides? This would make it more clear, in dependency resolution, > that mini-httpd-run is now an obsolete cruft package. I think mini-httpd-run is a leaf package but even if something depends on it might not be sensible to automatically bring in a package with 50 runscripts in place of a one with only one specific runscript. At least I want to give mini-httpd-run users the chance to read the NEWS file and react first. Regards, Lorenzo > > > https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides > > Alternatively if the transition requires user/sysadmin intervention, > then why wouldn't a debian/NEWS file be a good thing? > > Kind regards, > Nicholas
Bug#1054009: RFS: runit-services/0.7.0 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.7.0 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : GPL-2.0+, BSD-3-Clause, CC0-1.0, GPL-3+ * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.7.0.dsc Git: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next?ref_type=heads Changes since the last upload: runit-services (0.7.0) experimental; urgency=medium . [ Martin Steigerwald ] * new runscript for zcfan. . [ Lorenzo Puliti ] * dhclient: - raise memory limit (Closes: #1035837) - remove the check file (Closes: #1038425) - dhclient: ship as disabled by default * new runscripts: - mpd, gpm + Thanks to Friedhelm Mehnert - nginx, lighttpd * Import the runscript from mini-httpd-run package: - change the runscript to use the default config file - d/control: runit-services Provides mini-httpd-run * d/copyright.in: add GPL-3+ and GPL-2.0+ text * update d/copyright * update the testsuite: - test only a list of selected services - update the testsuite for new services layout - d/control: runit-services depends on runit(>=2.1.2-56) Regards, Lorenzo
Bug#1053092: initscripts: cannot upgrade to 3.08-1: APT dependency loop
Control: severity -1 whishlist Hi, On Wed, 27 Sep 2023 08:14:19 +0300 Martin-Éric Racine wrote: > Kernel: Linux 6.5.0-1-686-pae (SMP w/1 CPU thread; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), > LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) I guess this is the effect of https://salsa.debian.org/systemd-team/systemd/-/commit/eecd735541c9d5deb9cebd5f2512e7da8b4368a9 that adds a conflicts with initscripts. You can remove initscripts or reassign to systemd as whishlist, explaining why you need both initscripts and systemd-sysv installed. Regards, Lorenzo > Package: initscripts > Version: 3.07-1 > Severity: important > > $ LC_ALL=C sudo apt-get --option Debug::pkgDepCache::AutoInstall=true > install initscripts Reading package lists... Done > Building dependency tree... Done > Reading state information... Done >Removing: udev:i386 as upgrade is not an option for > initscripts:i386 (3.08-1) Installing linux-image-6.5.0-1-686:i386 as > Depends of linux-image-686:i386 Installing initramfs-tools:i386 as > Depends of linux-image-6.5.0-1-686:i386 Installing > linux-image-6.5.0-1-686:i386 as Depends of linux-image-686:i386 > Installing initramfs-tools:i386 as Depends of > linux-image-6.5.0-1-686:i386 Installing linux-image-6.5.0-1-686:i386 > as Depends of linux-image-686:i386 Installing initramfs-tools:i386 as > Depends of linux-image-6.5.0-1-686:i386 Installing > linux-image-6.5.0-1-686:i386 as Depends of linux-image-686:i386 > Installing initramfs-tools:i386 as Depends of > linux-image-6.5.0-1-686:i386 Installing linux-image-6.5.0-1-686:i386 > as Depends of linux-image-686:i386 Installing initramfs-tools:i386 as > Depends of linux-image-6.5.0-1-686:i386 Some packages could not be > installed. This may mean that you have requested an impossible > situation or if you are using the unstable distribution that some > required packages have not yet been created or been moved out of > Incoming. The following information may help to resolve the situation: > > The following packages have unmet dependencies: > initramfs-tools : Depends: initramfs-tools-core (= 0.142) but it is > not going to be installed E: Error, pkgProblemResolver::Resolve > generated breaks, this may be caused by held packages. > > -- System Information: > Debian Release: trixie/sid > APT prefers testing-debug > APT policy: (500, 'testing-debug'), (500, 'testing') > Architecture: i386 (i686) > > Kernel: Linux 6.5.0-1-686-pae (SMP w/1 CPU thread; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), > LANGUAGE=fi:en Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages initscripts depends on: > ii sysv-rc 3.08-1 > ii sysvinit-utils 3.08-1 > > Versions of packages initscripts recommends: > ii e2fsprogs 1.47.0-2+b1 > ii psmisc 23.6-1 > > initscripts suggests no packages. > > -- no debconf information >
Bug#979466: dh-sysuser: Create users in preinst instead of postinst
Hi Christopher,
On Thu, 21 Sep 2023 16:19:25 +0200
Christopher Odenbach wrote:
>
> Hi,
>
> I just stumbled across the same problem: Creating a package which
> creates a system user and then gives this user ownership of a
> directory.
> Currently this is not possible as the user is created in
> the postinst script at the very last point.
Well, you can write your code after the #DEBHELPER# token.. but I guess
this doesn't work for your use case?
Do you have the same problem as Lars -
" move the `#DEBHELPER#` marker to the top of the postinst script.
But this would lead to related services being restarted (via the other
debhelper snippets) before the directory permissions are configured. "
or there is another use case where the current order does not work?
If you have another example I'm interested in hearing it.
>
> The logical approach would be:
>
> - create the system user (preinst)
> - install all files and directories ("inst")
> - transfer ownership (postinst)
>
> In your last email you said you wanted to discuss this matter on
> Debian Devel. So could you please be so kind?
Yeah that was the idea, but then I realized that writing in preinstall
doesn't work with this package design: the preinstall snippet will
call sysuser-helper which is not guaranteed to be installed yet :(
So far I can think of the following:
1. The code can be written entirely in the preinstall but this defeats
the idea of having the code in a separate binary (sysuser-helper) which
has drawbacks like this bug but also has other advantages that I would
like not to give up; maybe there can be a specific option to do this?
2. dh-sysuser can grow an interface similar to systemd-tempfiles but
less complex and specialized in changing mode and ownership to
files and dirs and makes sure that the snippet in postinstall is run
after the creation of the user (I'm not particularly eager to do
this..)
3. declare that for such cases systemd-tmpfiles is mandatory (but I
still need to check that the order is correct)
In case 1. is not feasible, do you dislike 2? Would it work for your use
case?
> I really like the idea
> of your package, but currently it does not really help me.
I neglected a bit this package during the last cycle, hopefully I'll
manage to do better in this cycle
Regards,
Lorenzo
>
> Thank you,
>
> Christopher
>
Bug#1051554: RFS: runit-services/0.5.5~deb12u1 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, Please upload to stable; this has already been approved by release team in #1050722 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050722 * Package name : runit-services Version : 0.5.5~deb12u1 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : CC0-1.0, BSD-3-Clause * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.5~deb12u1.dsc Git : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/bookworm-pu?ref_type=heads Changes since the last upload: runit-services (0.5.5~deb12u1) bookworm; urgency=medium . * Rebuild for bookworm. Regards, Lorenzo
Bug#1050722: bookworm-pu: package runit-services/0.5.5~deb12u1
Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: runit-servi...@packages.debian.org, plore...@disroot.org Control: affects -1 + src:runit-services [ Reason ] The version in stable (0.5.4) is currently affected by #1033542, where in most cases the dhclient service fails to start and syslog is flooded with failure messages at a very high rate, hiding other potentially relevant logs. The flood is a consequence of runit supervision design: when a service wanted status is 'up' and the service crashes, it's automatically restarted after a 1 second grace time. Bug #1033542 was filed with severity 'normal' during the freeze and at the time I thought that it was not worth an unblock request; now, given several complains I've received about this, I'm reconsidering. Dhclient is enabled and started by default for runit-init users; it may take time to notice the flood on syslog and even then, for a user that is not expert in runit, it's not easy to understand what is causing it. The attached debdiff is for a no change rebuild of the same version that is currently in unstable/testing [ Tests ] I tested the fix personally and it solves the issue [ Risks ] Low [ Checklist ] [x] *all* changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in stable [x] the issue is verified as fixed in unstable [ Changes ] * stop hardcoding eth1 in dhclient run file * adapt the check file for empty $INTERFACE Regards, Lorenzo
Bug#1042082: Please take over udev SysV init script
On Thu, 27 Jul 2023 11:11:41 +0100
Mark Hindley wrote:
Hi Mark,
> On Wed, Jul 26, 2023 at 08:22:15PM +0100, Matthew Vernon wrote:
> > Hi,
> >
> > On 26/07/2023 19:43, lorenzo wrote:
> >
> > > may I suggest to add this script to initscripts
> > > package(sysvinit:src) instead of o-s-s?
> > > A system without udev is not very common after all and the vast
> > > majority of scripts strictly needed to boot and shutdown the
> > > system are shipped there.
> >
> [...]
>
> I can see some logic to this approach.
>
> I am away until next week, but can look at it then.
>
I'm attaching git patches that can be 'git am' on top of the master
branch at
https://salsa.debian.org/debian/sysvinit/-/tree/master?ref_type=heads
Since I'm on holiday and away from from my testing setup, I did no test
to ensure that this warks as intended, so consider it as experimental.
Also, the "breaks and replaces" patch need to be amended with the
version of systemd that removes the udev script, which is unknwnown to
me (I used the unreleased 254.1-3, which of course is wrong).
Anyway I think there need to be some work on udev's side to ensure that
the udev script is not removed when the initscripts package is
installed in the system.
Hope this helps,
Lorenzo
> Mark
>From db26e458e3d84430069a063d928d7ee8bffb59a4 Mon Sep 17 00:00:00 2001
From: Lorenzo Puliti
Date: Sat, 19 Aug 2023 18:07:30 +0200
Subject: [PATCH 1/5] Import udev script from systemd:src
import udev script as a copy of udev.init from systemd source
---
debian/src/initscripts/etc/init.d/udev | 255 +
1 file changed, 255 insertions(+)
create mode 100644 debian/src/initscripts/etc/init.d/udev
diff --git a/debian/src/initscripts/etc/init.d/udev b/debian/src/initscripts/etc/init.d/udev
new file mode 100644
index ..bb54f610
--- /dev/null
+++ b/debian/src/initscripts/etc/init.d/udev
@@ -0,0 +1,255 @@
+#!/bin/sh -e
+### BEGIN INIT INFO
+# Provides: udev
+# Required-Start:mountkernfs
+# Required-Stop: umountroot
+# Default-Start: S
+# Default-Stop: 0 6
+# Short-Description: Start systemd-udevd, populate /dev and load drivers.
+### END INIT INFO
+
+PATH="/sbin:/bin"
+NAME="systemd-udevd"
+DAEMON="/lib/systemd/systemd-udevd"
+DESC="hotplug events dispatcher"
+PIDFILE="/run/udev.pid"
+CTRLFILE="/run/udev/control"
+OMITDIR="/run/sendsigs.omit.d"
+
+# we need to unmount /dev/pts/ and remount it later over the devtmpfs
+unmount_devpts() {
+ if mountpoint -q /dev/pts/; then
+umount -n -l /dev/pts/
+ fi
+
+ if mountpoint -q /dev/shm/; then
+umount -n -l /dev/shm/
+ fi
+}
+
+# mount a devtmpfs over /dev, if somebody did not already do it
+mount_devtmpfs() {
+ if grep -E -q "^[^[:space:]]+ /dev devtmpfs" /proc/mounts; then
+mount -n -o remount,nosuid,size=$tmpfs_size,mode=0755 -t devtmpfs devtmpfs /dev
+return
+ fi
+
+ if ! mount -n -o nosuid,size=$tmpfs_size,mode=0755 -t devtmpfs devtmpfs /dev; then
+log_failure_msg "udev requires devtmpfs support, not started"
+log_end_msg 1
+ fi
+
+ return 0
+}
+
+create_dev_makedev() {
+ if [ -e /sbin/MAKEDEV ]; then
+ln -sf /sbin/MAKEDEV /dev/MAKEDEV
+ else
+ln -sf /bin/true /dev/MAKEDEV
+ fi
+}
+
+# shell version of /usr/bin/tty
+my_tty() {
+ [ -x /bin/readlink ] || return 0
+ [ -e /proc/self/fd/0 ] || return 0
+ readlink --silent /proc/self/fd/0 || true
+}
+
+warn_if_interactive() {
+ if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then
+return
+ fi
+
+ TTY=$(my_tty)
+ if [ -z "$TTY" -o "$TTY" = "/dev/console" -o "$TTY" = "/dev/null" ]; then
+return
+ fi
+
+ printf "\n\n\nIt has been detected that the command\n\n\t$0 $*\n\n"
+ printf "has been run from an interactive shell.\n"
+ printf "It will probably not do what you expect, so this script will wait\n"
+ printf "60 seconds before continuing. Press ^C to stop it.\n"
+ printf "RUNNING THIS COMMAND IS HIGHLY DISCOURAGED!\n\n\n\n"
+ sleep 60
+}
+
+make_static_nodes() {
+ [ -e /lib/modules/$(uname -r)/modules.devname ] || return 0
+ [ -x /bin/kmod ] || return 0
+
+ /bin/kmod static-nodes --format=tmpfiles --output=/proc/self/fd/1 | \
+ while read type name mode uid gid age arg; do
+[ -e $name ] && continue
+case "$type" in
+ c|b|c!|b!) mknod -m $mode $name $type $(echo $arg | sed 's/:/ /') ;;
+ d|d!) mkdir $name ;;
+ *) echo "unparseable line ($type $name $mode $uid $gid $age $arg)" >&2 ;;
+esac
+
+if [ -x /sbin/restorecon ]; then
+ /sbin/restorecon $name
+fi
+ done
+}
+
+
+##
+
+
Bug#1050016: RFS: runit/2.1.2-56 -- system-wide service supervision
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit": * Package name : runit Version : 2.1.2-56 Upstream contact : Gerrit Pape * URL : http://smarden.org/runit/ * License : BSD-3-clause, CC0-1.0, GPL-3+ * Vcs : https://salsa.debian.org/debian/runit Section : admin The source builds the following binary packages: runit - system-wide service supervision runit-run - service supervision (systemd and sysv integration) runit-systemd - transitional package for runit-systemd users getty-run - runscripts to supervise getty processes runit-init - system-wide service supervision (as init system) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-56.dsc Git repo: https://salsa.debian.org/debian/runit/-/tree/next?ref_type=heads Changes since the last upload: runit (2.1.2-56) experimental; urgency=medium . * cpsv: - revert "cpsv: use sv.current symlink as source" - use sv.src symlink as source for runscript * runit.preinst: - fix wrong target for sv.current link - create sv.src link to make cpsv source configurable * trigger_sv: - maintain a runtime copy of services in sv.now - add a hook to atomically update services - look both in /etc and /usr to enable a service, /etc/sv/ is always preferred * 40-runit: also test /usr/share/runit/sv.current * update-service: - look in /usr/ and /etc/ for services; - stop requiring full path; - prefer services in /etc/ over services in /usr: * run_sysv_script: check /etc/service instead of /etc/sv (Closes: #1022837) * runit-init: drop obsolete Replaces without Breaks * runit: duplicate triggers as mitigation for usrmerge. + Thanks to Helmut Grohne (Closes: #1043419) * d/rules: fix FTBFS after successful build (Closes: #1046998) Regards, Lorenzo
Bug#1043303: RFS: runit-services/0.5.5 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.5.5 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : CC0-1.0, BSD-3-Clause * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.5.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/bookworm-pu?ref_type=heads Changes since the last upload: runit-services (0.5.5) unstable; urgency=medium . * dhclient: don't hardcode eth1 interface to avoid flood of syslog in systems where eth1 does not exist (Closes: #1033542) Regards, Lorenzo
Bug#1042488: gerbera: trouble during install or purge
Hi, On Sat, 29 Jul 2023 10:43:05 +0200 Patrice Duroux wrote: > Package: gerbera > Version: 1.12.1+dfsg-0.1+b1 > Severity: normal > > Dear Maintainer, > > I do not know if it is a (temporary) general problem in the current > Debian Sid. But there some bad interaction with the gerbera.service > during the install: > > Unpacking gerbera (1.12.1+dfsg-0.1+b1) ... > Setting up gerbera (1.12.1+dfsg-0.1+b1) ... > invoke-rc.d: policy-rc.d denied execution of start. > Created symlink > /etc/systemd/system/multi-user.target.wants/gerbera.service -> > /lib/systemd/system/gerbera.service. /usr/sbin/policy-rc.d returned > 101, not running 'start gerbera.service' Could you please do #dpkg -S /usr/sbin/policy-rc.d and post the output? /usr/sbin/policy-rc.d is not supposed to exist in a standard install Regards, Lorenzo > > and during the purge (the service have been started since): > > Removing gerbera (1.12.1+dfsg-0.1+b1) ... > /usr/sbin/policy-rc.d returned 101, not running 'stop gerbera.service' > invoke-rc.d: policy-rc.d denied execution of stop. > Purging configuration files for gerbera (1.12.1+dfsg-0.1+b1) ... > info: Removing crontab ... > info: Removing user `gerbera' ... > userdel: user gerbera is currently used by process 2553 > fatal: `/usr/sbin/userdel gerbera' returned error code 8. Exiting. > info: Removing group `gerbera' ... > groupdel: cannot remove the primary group of user 'gerbera' > fatal: `/sbin/groupdel gerbera' returned error code 8. Exiting. > > Thanks, > Patrice > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable-debug > APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, > 'experimental-debug'), (1, 'experimental') Architecture: amd64 > (x86_64) Foreign Architectures: i386 > > Kernel: Linux 6.4.0-1-amd64 (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_WARN > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages gerbera depends on: > ii adduser 3.137 > ii fonts-font-awesome 5.0.10+really4.7.0~dfsg-4.1 > ii fonts-lato 2.0-2.1 > ii libavcodec607:6.0-4 > ii libavformat60 7:6.0-4 > ii libavutil58 7:6.0-4 > ii libc6 2.37-6 > ii libcurl3-gnutls 7.88.1-11 > ii libduktape207 2.7.0-2 > ii libebml51.4.4-1 > ii libexif12 0.6.24-1+b1 > ii libexiv2-27 0.27.6-1 > ii libffmpegthumbnailer4v5 2.2.2+git20220218+dfsg-1+b2 > ii libfmt9 9.1.0+ds1-2 > ii libgcc-s1 13.1.0-9 > ii libixml11 1:1.14.17-2 > ii libjs-bootstrap44.6.1+dfsg1-4 > ii libjs-jquery3.6.1+dfsg+~3.5.14-1 > ii libjs-jquery-ui 1.13.2+dfsg-1 > ii libjs-popper.js 1.16.1+ds-6 > ii libjs-prototype 1.7.3-1 > ii libmagic1 1:5.44-3 > ii libmariadb3 1:10.11.4-1 > ii libmatroska71.7.1-1 > ii libpugixml1v5 1.13-0.2 > ii libspdlog1.10 [libspdlog1.10-fmt9] 1:1.10.0+ds-0.4 > ii libsqlite3-03.42.0-1 > ii libstdc++6 13.1.0-9 > ii libtag1v5 1.13.1-1 > ii libupnp17 1:1.14.17-2 > ii libuuid12.39.1-3 > ii node-js-cookie 3.0.1+~3.0.0-3 > > gerbera recommends no packages. > > Versions of packages gerbera suggests: > ii firefox [www-browser] 115.0.2-1 > pn gerbera-doc > ii google-chrome-stable [www-browser] 115.0.5790.110-1 > ii lynx [www-browser] 2.9.0dev.12-1 > ii vivaldi-stable [www-browser]6.1.3035.204-1 > > -- no debconf information >
Bug#1042082: Please take over udev SysV init script
Dear Matthew and Sysvinit maintainers, may I suggest to add this script to initscripts package(sysvinit:src) instead of o-s-s? A system without udev is not very common after all and the vast majority of scripts strictly needed to boot and shutdown the system are shipped there. Lorenzo On Wed, 26 Jul 2023 15:36:58 +0100 Matthew Vernon wrote: > On 26/07/2023 15:16, Luca Boccassi wrote: > > On Wed, 26 Jul 2023 14:24:09 +0200 Michael Biebl > > wrote: > >> Package: orphan-sysvinit-scripts > >> Severity: normal > >> X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org > >> > >> Hi, > >> > >> in one of the upcoming releases of udev, the legacy SysV init > >> script will be dropped. > >> > >> Please take over the file as you see fit. > > > > You can find a copy of the script at this stable link: > > > > https://salsa.debian.org/systemd-team/systemd/-/blob/6e720b91dd837b71dd81c1d959b21f1b0a48ae29/debian/udev.init > > Thanks. Are you able to clarify the copyright status of that file, > please? The debian/* section in debian/copyright is 51 lines long, > and I doubt all of those people should be considered copyright > holders in the init script? > > Regards, > > Matthew > >
Bug#1040364: orphan-sysvinit-scripts: add triggers to restart daemons
On Wed, 5 Jul 2023 21:56:14 +0200 (CEST) Thorsten Glaser wrote: > On Wed, 5 Jul 2023, g...@libero.it wrote: > > >But [o-s-s] should also invoke-rc.d try-restart, for > >perfection. > > I don’t think so. I think the postinst of the services in question > restart the service, and that ought to “just work”, independent of > the init system in use, as long as an initsystem-compatible service > initscript is present (no matter whether it’s in the package itself > or in a separate one). > > After all, not all packages restart services on upgrade; some pak‐ > kages contain more than one service, not all of which are restarted > always, etc. > even if debhelper is changed to inject maintscripts regardless of the *.init script file in the source, non default actions are passed to dh_installinit in the rules file, so in the case of an uncooperative maintainer, there is no way for debhelper to know that it has to inject non-default actions in the snippets. > bye, > //mirabilos
Bug#1038425: runit-services: missing dependency on net-tools for ifconfig
Hi Olaf, On Sat, 17 Jun 2023 15:48:03 +0900 Olaf Meeuwissen wrote: > Package: runit-services > Version: 0.5.4 > Severity: normal > > The sv/dhclient/check file uses ifconfig. This is part of the > net-tools package. The package is Priority: important, so would > normally be installed. However, iproute2 mentions in its package > description that `ifconfig` is a legacy tool. That led me to remove > net-tools. I have been doing mostly fine without net-tools but this > hit me when I pulled in runit-services, unintentionally, during an > upgrade. I'm thinking of removing the entire check file: it checks that the network is up but it can lead to false positives/negatives (the network may be down but dhclient can be up, and vice versa) > > I've since uninstalled runit-services but thought I'd let you know. thanks for reporting, Lorenzo > -- > Olaf Meeuwissen
Bug#448105: mplayer: Illegal Instruction in init_audio_codec
Thanks for looking at this again On Mon, 5 Jun 2023 20:33:15 +0200 =?utf-8?Q?Reimar_D=C3=B6ffinger?= wrote: > While it's still plenty messy, FFmpeg has runtime detection of > altivec, and MPlayer itself has no altivec code itself. But I don't > think it works, the problem is the compiler options: > [ ... ] > So maybe it is possible to get to work now, but probably separate > builds would remain the better approach. On the plus side, if FFmpeg > works, and since Debian links MPlayer to FFmpeg dynamically, > --disable-altivec should be all that is needed - assuming the > performance degradation on altivec enabled systems mentioned above is > considered acceptable. Disable altivec for everyone doesn't seem a good compromise to me, I'm going to build twice on powerpc and let the user decide which one to use Best, Lorenzo > > Best regards, > Reimar > > >
Bug#1036751: RFS: mini-httpd/1.30-4 [ITA] -- Small HTTP server
Hi Alexandru, On Thu, 01 Jun 2023 12:05:51 + Alexandru Mihail wrote: > Hi Nicholas, > I've uploaded again to mentors, the (now gone) lintian warning > complained about missing the SystemD service for the package. I've > added one from scratch and upon initial testing it performs OK. I > modified debian/rules to take the service into consideration though > this raises some concerns for non-systemd Debian installations. I > assume further modifications are required to intelligently enable or > ignore the service (use old init.d mechanism). (looking at your rules file) override_dh_installinit: dh_installinit --no-stop-on-upgrade --no-start --name=mini-httpd override_dh_installsystemd: dh_installsystemd --name=mini-httpd if the '--no-stop-on-upgrade --no-start' is to avoid a conflict between the systemd service and the init.d file, you don't need that: debhelper generated scripts should do the right thing. If you look at generated maintscripts you see that systemctl calls are guarded by a test for /run/systemd/system (it imply that systemd is the running init); the equivalent code for sysvinit (invoke.rc.d) is not guarded but that's ok since other inits are supposed to mask initscripts and systemd already does that. Regards, Lorenzo > Kind regards, > Alexandru Mihail >
Bug#1035837: dhclient: memory limit too low on kFreeBSD
Package: runit-services Version: 0.6.0 Severity: normal dhclient service fails to start on kFreeBSD port, the current memory limit is too low and need to be doubled (12 --> 24) compared to linux kernel -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: kfreebsd-amd64 (x86_64) Kernel: kFreeBSD 10.3-0-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit-services depends on: ii runit 2.1.2-54 ii runit-helper 2.15.2 Versions of packages runit-services recommends: ii runit-init 2.1.2-54 Versions of packages runit-services suggests: pn socklog -- no debconf information
Bug#1034867: smplayer: crash when playing video files using mplayer under Wayland
Hi James, thanks for reporting this > This is reproducible if launching mplayer standalone to play the > video file with the 'wid' argument specified manually. Audio will > play, but video does not appear. > > What is worse, however, is that when the 'nokeepaspect' parameter is > added, as is the case with smplayer, then mplayer itself crashes with > a floating-point math exception. This appears to occur here: > https://sources.debian.org/src/mplayer/2%3A1.5%2Bsvn38408-1/libvo/vo_xv.c/#L365-L367 I've opened an issue for this at mplayer upstream tracker https://trac.mplayerhq.hu/ticket/2411 let's see if this can be addressed in mplayer Lorenzo
Bug#1007892: firmware-realtek: no stable connection
Package: firmware-realtek Version: 20230210-4 Followup-For: Bug #1007892 X-Debbugs-Cc: lorenzobertin...@gmail.com Dear Maintainer, as stated before, connection seems to come and go with realtek 8821ce driver provided. It's only fixed after installing the dkms module from https://github.com/tomaspinho/rtl8821ce. I don't know much about firmware and drivers, so I can't tell what's in that repository that is not already in the package. Maybe a package realtek-dkms could be a fix? Don't hesitate to ask for more info, and thank you. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-7-amd64 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-realtek depends on no packages. firmware-realtek recommends no packages. Versions of packages firmware-realtek suggests: ii initramfs-tools 0.142 -- no debconf information
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
Hi, On Tue, 28 Mar 2023 20:30:59 +0200 Andras Korn wrote: > On Tue, Mar 28, 2023 at 01:10:36AM +0200, Lorenzo wrote: > > I propose the following: > > > > * patch runit-helper, update-service and /lib/runit/trigger_sv so > > that every (package provided) runit service is always represented > > in /etc/service/, either with a foo symlink (enabled) or with a > > .foo symlink (disabled). > > OK, this works (although I don't see why it's necessary), as long as > nothing gets confused by the existence of both symlinks. For example, > under this scheme, I may have: Both links should not happen, a service is either enabled or disabled > > /service/ssh -> /some/dir/where/I/keep/my/services/ssh > # created "manually" ok this should already override the default link to /etc/sv, there is no code that replaces your link with one to /etc/sv/ > /service/.ssh -> /etc/sv/ssh > # created during container provisioning to prevent > the ssh package from installing its version of the service (otherwise > it creates /etc/service/ssh/ssh) old bug, runit-helper code didn't check for the existance of the symlink and there was an infinite loop of symlinks (it doesn't create problem to the service, but in any case should not happen), I thought I already fixed this, will have another look > > If there is potential for confusion, then a mechanism to delete the > .ssh symlink if/when the plain ssh symlink is present would also be > needed. > > > This way I (as a packager) can test /etc/service/ to know if a > > runscript exists in /etc/sv/. > > You can, but I'm not sure I see why you have to. The /etc/sv location > is not special per se; why does it matter whether there is anything > there in particular? Since I want to provide the nanny-automation (enable a service when the package that ships the corresponding bin is installed and disable it when such package is removed) I have to know where the stash of available runit services is, to check if a native service exists and to enable it by creating a symlink to it. That's what other inits like Sysv and systemd do, and users that come from those other inits expect such automation: that would be the case for a large part of the ~350 runit-init users in Devuan. > > > For users that have their own runscripts collection somewhere in > > the filesystem: they will enable their services by creating the foo > > symlink, and they can have the sysv emulation skip certain services > > (let's say a bar service) by creating a /etc/service/.bar symlink. > > That's a needless extra hoop to jump through. When deciding whether > to skip invoking /etc/init.d/bar, why is it better to check for the > existence of "/etc/service/.bar" than "/etc/service/bar"? The latter > needs to exist anyway, because that's what will cause runit to start > the service. Reason is that if none of the two link is there I'm sure that no package provided runit service is available. For a use case on user side, see at the bottom. > > * turn the run_sysv_scripts into a runit service that test for > > /etc/service/$name. Two main reason for this: > > This needs to be thought through carefully (it would need to only run > once, but finish before other services are started -- for example, it > could do a runsvchdir in ./finish). Not necessarily: by default in runit services are started asynchronously so in principle there is no reason to run sysv scripts sequentially and strictly before any runit service. Of course there are dependencies, my bet is that no more than two maybe three loop are needed. Of course there is an entire Debian cycle to prove me wrong. > > > 1. users can disable it, or change it at their will, while any > > change into /lib/runit/run_sysv_scripts is overwritten by the > > package, so users are forced to change stage 2 and create their own > > version of the script > > You could also achieve this by preferring > /etc/runit/lib/run_sysv_scripts if it is executable, and only running > /lib/runit/run_sysv_scripts if not. Even more complex setups would > also be possible, with /lib/runit/run_sysv_scripts relying on shell > functions that a user-supplied sourced file could override, but I > think that would go too far. The point is that I would like to drop this sysv emulation; runit need to be able to run scripts before runsvdir starts services, an it can be done in stage2, but such scripts don't necessarily need to be sysv scripts, and don't need to obey the sysv (insserv) order. For now I'm just going to separate the two mechanism. > > > 2. when runit services are mixed with sysv scripts in the start > > sequence, the run_sysv_scripts can be RC-buggy, see #1024969 [1] > > for an example > > Ye
Bug#1033615: RFS: runit-services/0.6.0 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.6.0 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : BSD-3-Clause, CC0-1.0 * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.6.0.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next Changes since the last upload: runit-services (0.6.0) experimental; urgency=medium . * update-copyright script: allow "Comment:" line * new runscripts: avahi-daemon, avahi-dnsconfd, uuidd, bluetooth, network-manager, connman (Closes: #1032657) * dhclient: don't hardcode interfaces (Closes: #1033542) * update copyright * testsuite: - block all systemd services - fix pkgname detection with systemd service Regards, Lorenzo
Bug#1033542: runit-services: dhclient spamming syslog (eth1 hardcoded)
Control: tags -1 patch
Hi Dimitris,
since the fix for this goes to experimental and it may takes some time,
I'm attaching a patch that should stop the flooding of logs; you need
to manually edit files in /etc/sv/dhclient/* thought ..
diff --git a/sv/dhclient/check b/sv/dhclient/check
index e406a77..ad2a474 100755
--- a/sv/dhclient/check
+++ b/sv/dhclient/check
@@ -1,5 +1,9 @@
#!/bin/sh
-. ./conf/interfaces || exit 1
-for i in $INTERFACES; do
- ifconfig $i |grep 'inet' >/dev/null || exit 1
-done
+. ./conf/interfaces
+if [ -n "$INTERFACES" ]; then
+ for i in $INTERFACES; do
+ifconfig $i |grep 'inet' >/dev/null || exit 1
+ done
+else
+ ifconfig |grep 'inet' >/dev/null || exit 1
+fi
diff --git a/sv/dhclient/conf/interfaces b/sv/dhclient/conf/interfaces
index c5f1bb2..1f9775b 100644
--- a/sv/dhclient/conf/interfaces
+++ b/sv/dhclient/conf/interfaces
@@ -1 +1 @@
-INTERFACES=eth1
+INTERFACES=
diff --git a/sv/dhclient/run b/sv/dhclient/run
index 2cc7fca..7bc3482 100755
--- a/sv/dhclient/run
+++ b/sv/dhclient/run
@@ -1,10 +1,10 @@
#!/usr/bin/env /lib/runit/invoke-run
#Copyright: 2005-2008 Gerrit Pape
-# 2022 Lorenzo Puliti
+# 2022-2023 Lorenzo Puliti
#License: BSD-3-Clause
exec 2>&1
. ./conf/interfaces || exit 162
-exec chpst -m1200 dhclient -d $INTERFACES
+exec chpst -m1200 dhclient -d ${INTERFACES:-}
--
On Mon, 27 Mar 2023 11:06:55 +0300 "Dimitris T."
wrote:
> Package: runit-services
> Version: 0.5.4
> Severity: normal
>
> Hey Lorenzo,
>
> have been flooded with syslog entries of :
>
> "
> 2023-03-26_18:39:14.63103 Internet Systems Consortium DHCP Client
> 4.4.3-P1 2023-03-26_18:39:14.63109 Copyright 2004-2022 Internet
> Systems Consortium. 2023-03-26_18:39:14.63110 All rights reserved.
> 2023-03-26_18:39:14.63116 For info, please visit
> https://www.isc.org/software/dhcp/ 2023-03-26_18:39:14.63117
> 2023-03-26_18:39:14.65832 Cannot find device "eth1"
> 2023-03-26_18:39:14.67499 Failed to get interface index: No such
> device 2023-03-26_18:39:14.67502
> 2023-03-26_18:39:14.67503 If you think you have received this message
> due to a bug rather 2023-03-26_18:39:14.67503 than a configuration
> issue please read the section on submitting 2023-03-26_18:39:14.67504
> bugs on either our web page at www.isc.org or in the README file
> 2023-03-26_18:39:14.67505 before submitting a bug. These pages
> explain the proper 2023-03-26_18:39:14.67509 process and the
> information we find helpful for debugging. 2023-03-26_18:39:14.67510
> 2023-03-26_18:39:14.67511 exiting. "
>
> those log entries are written every second(!) in syslog AND
> /var/log/runit/dhclient/current... source of the "problem" seems to
> be that /usr/share/runit/sv/dhclient/conf/interfaces uses hardcoded
> "eth1" by default, when there is no "eth1" on this system.. maybe
> option value should be empty by default or commented out (?). not
> sure what's the best approach for defaults in this runit service.
>
> thx in advance,
> d.
>
>
>
> -- System Information:
> Debian Release: 12.0
> merged-usr: no
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 6.1.18-antix.1-amd64-smp (SMP w/4 CPU threads; PREEMPT)
> Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8),
> LANGUAGE not set Shell: /bin/sh linked to /bin/dash
> Init: runit (via /run/runit.stopit)
>
> Versions of packages runit-services depends on:
> ii runit 2.1.2-54
> ii runit-helper 2.15.2
>
> Versions of packages runit-services recommends:
> ii runit-init 2.1.2-54
>
> Versions of packages runit-services suggests:
> pn socklog
>
> -- no debconf information
>
>
Bug#1033610: RFS: dh-sysuser/1.3.10+really1.4.4 -- debhelper addon to handle creation of system users
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dh-sysuser": * Package name : dh-sysuser Version : 1.3.10+really1.4.4 Upstream contact : [fill in name and email of upstream] * URL : https://salsa.debian.org/debian/dh-sysuser * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-sysuser Section : admin The source builds the following binary packages: dh-sysuser - debhelper addon to handle creation of system users sysuser-helper - dh-sysuser implementation detail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-sysuser/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.10+really1.4.4.dsc Git repo: https://salsa.debian.org/debian/dh-sysuser/-/tree/next Changes since the last upload: dh-sysuser (1.3.10+really1.4.4) experimental; urgency=medium . * Fix typo in postrm snippet (Closes: #1032947) * update copyright years Regards, Lorenzo
Bug#1022837: /lib/runit/run_sysv_scripts uses wrong test to skip initscripts
Hi Andras, Please follow up and let me know if my idea would solve this issue or at least improve the situation from your point of view: > > Checking for /etc/sv/$name and skipping initscripts if those > directories exist is wrong for two reasons: > > 1. /etc/sv/$name may not be symlinked into /etc/service (false > positive); > > 2. /etc/service may contain a symlink to a service directory for > this service that is elsewhere in the filesystem, not in /etc/sv > (false negative). > > As a minimum, I suggest the following: instead of /etc/sv/$name, > check for /etc/service/$name (and $name-daemon if necessary), and not > with "-d" but "-L" (because when running rcS.d, the target of the > symlink may only appear later, for example when a new filesystem is > mounted). I propose the following: * patch runit-helper, update-service and /lib/runit/trigger_sv so that every (package provided) runit service is always represented in /etc/service/, either with a foo symlink (enabled) or with a .foo symlink (disabled). This way I (as a packager) can test /etc/service/ to know if a runscript exists in /etc/sv/. For users that have their own runscripts collection somewhere in the filesystem: they will enable their services by creating the foo symlink, and thay can have the sysv emulation skip certain services (let's say a bar service) by creating a /etc/service/.bar symlink. This would also prevent runit package (and runit-helper) to enable the bar service, if any /etc/sv/bar exists, because the logic in runit-helper and sv_trigger only test if the symlink (or dot-symlink) exists, but it doesn't care where it points. In any case runit/runit-helper only creates and remove links in the /etc/runit/runsvdir/default directory, so if you point runsvdir to another directory runit package doesn't enable or disable anything for you. * turn the run_sysv_scripts into a runit service that test for /etc/service/$name. Two main reason for this: 1. users can disable it, or change it at their will, while any change into /lib/runit/run_sysv_scripts is overwritten by the package, so users are forced to change stage 2 and create their own version of the script 2. when runit services are mixed with sysv scripts in the start sequence, the run_sysv_scripts can be RC-buggy, see #1024969 [1] for an example > > This is still imperfect during boot because /etc/service may point to > some directory that is not the one we'll switch to with runsvdir in > stage 2. I don't know what the best way of handling this (likely > rare) case is, but the following solutions come to mind: I think with the above solution this should be no longer a problem as we run the sysv emulation from within runsvdir. Hopefully this will make your "runit" life easier (?) > András > Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%231024969
Bug#1032943: runit-init: halt called with unsupported options during poweroff
Hi, On Fri, 17 Mar 2023 19:56:01 +0900 Olaf Meeuwissen wrote: > > When runit is init, calling halt or reboot at the end of stage3 is > > unecessary, so an easy solution to silent those warnings is to skip > > halt and reboot scripts during the shutdown loop, so that reboot or > > poweroff is carry on by runit code as stage 3 returns. > > Apologies if I sound a bit clueless, but if runit is *not* init, it > would still have to call halt and reboot scripts, right? Not really: when runit is not init (like with runit-run package) boot and shutdown are performed by the init in charge (sysvinit or systemd). Runit-run package only runs stage 2 to spawn a runsvdir process. In case of Sysvinit, scripts in /etc/rc0.d/ or /etc/rc6.d/ are run by Sysv via /etc/init.d/rc script and Sysv's halt is used, so no problem with "unsupported options". Lorenzo > > > There will be still one warning left for the -w flag but that is > > already tracked in #992648 [2]. > > Ack. > > > I prefer not to silence the warning in shutdown.c: > > > > * It nice for the user to be warned that a used flag is noop > > * (more important) halt/reboot are called by other scripts or > > programs in the system, and I don't have a complete picture of > > that, so I'm using the warning to make debug easier in such > > situations. > > Ack and let me state, for the record, that I have even less of a > picture of how all these bits fit together :-/ > > > Olaf, let me know if you would be unsatisfyied with the above > > solution; > > If it solves my (wishlist) issue and does not unduly inconvenience > other use cases, I'm fine with it. > > > [1] https://bugs.devuan.org/cgi/bugreport.cgi?bug=749 > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992648 > > Hope this helps, > -- > Olaf Meeuwissen
Bug#1032947: dh-sysuser: typo in postrm snippet turn purge into noop
Package: dh-sysuser Version: 1.3.9+really1.4.3 Severity: important X-Debbugs-Cc: plore...@disroot.org I just discovered a typo that happened when #1000478 was fixed: the 'postrm-sysuser' snippet that calls sysuser-helper with 'prerm' instead of 'postrm'. Because of this the purge action becomes a noop. This need to be fixed in dh-sysuser and than all package that use it will have to be rebuilded. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages dh-sysuser depends on: ii perl 5.36.0-7 dh-sysuser recommends no packages. dh-sysuser suggests no packages. -- no debconf information
Bug#1032943: runit-init: halt called with unsupported options during poweroff
Package: runit-init Version: 2.1.2-54 Severity: minor X-Debbugs-Cc: Olaf Meeuwissen , Mark Hindley , plore...@disroot.org >From Devuan bug #749 [1] > > Every time I `poweroff` my machine, I see error message flash by that > complain about `halt` being called with unsupported options. I think > I have tracked this down to /etc/init.d/halt making blind assumptions > about the options supported by the `halt` command. When runit is init, calling halt or reboot at the end of stage3 is unecessary, so an easy solution to silent those warnings is to skip halt and reboot scripts during the shutdown loop, so that reboot or poweroff is carry on by runit code as stage 3 returns. There will be still one warning left for the -w flag but that is already tracked in #992648 [2]. I prefer not to silence the warning in shutdown.c: * It nice for the user to be warned that a used flag is noop * (more important) halt/reboot are called by other scripts or programs in the system, and I don't have a complete picture of that, so I'm using the warning to make debug easier in such situations. Olaf, let me know if you would be unsatisfyied with the above solution; Mark, I think the Devuan bug can be closed or marked as reassigned to this one (I don't know how to manipulate the Devuan BTS). Best, Lorenzo [1] https://bugs.devuan.org/cgi/bugreport.cgi?bug=749 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992648 -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages runit-init depends on: ii getty-run2.1.2-54 ii initscripts 3.06-2 ii insserv 1.24.0-1 ii mount2.38.1-5 ii runit2.1.2-54 Versions of packages runit-init recommends: ii runit-services 0.5.4 runit-init suggests no packages. -- no debconf information
Bug#1031955: RFS: dh-sysuser/1.3.9+really1.4.3 [RC] -- debhelper addon to handle creation of system users
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "dh-sysuser": * Package name : dh-sysuser Version : 1.3.9+really1.4.3 Upstream contact : [fill in name and email of upstream] * URL : https://salsa.debian.org/debian/dh-sysuser * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-sysuser Section : admin The source builds the following binary packages: dh-sysuser - debhelper addon to handle creation of system users sysuser-helper - dh-sysuser implementation detail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-sysuser/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.9+really1.4.3.dsc Git repo: https://salsa.debian.org/debian/dh-sysuser/-/tree/next Changes since the last upload: dh-sysuser (1.3.9+really1.4.3) unstable; urgency=medium . * sysuser-helper: depends on passwd (Closes: #1031833) Regards, Lorenzo
Bug#1031854: orphan-sysvinit-scripts: should cope with defective rsyslog-rotate
On Fri, 24 Feb 2023 12:00:39 + Matthew Vernon wrote: > > No (and in general I don't want to end up with > orphan-sysvinit-scripts conflicting with anything). rsyslog-rotate is > part of the rsyslog package, and the problem relates to its > integration with logrotate. > I misunderstood your bug report, I thought you were going to call the rsyslog-rotate in /etc/init.d/rsyslog
Bug#1031854: orphan-sysvinit-scripts: should cope with defective rsyslog-rotate
Hi, On Fri, 24 Feb 2023 09:20:29 + Matthew Vernon wrote: > > rsyslog-rotate should HUP rsyslog as appropriate for the installed > init system. It doesn't, so orphan-sysvinit-scripts should work around > this on sysvinit systems, without causing problems on systemd systems. > Isn't a conflict with systemd-sysv package enough? As systemd starts rsyslog with '-iNONE' another approach could be to test for the PID file before HUP Lorenzo
Bug#1029116: [PATCH] wifi: mt76: mt7921: correctly handle removal in the absence of firmware
> Trying to probe a mt7921e pci card without firmware results in a
> successful probe where ieee80211_register_hw hasn't been called. When
> removing the driver, ieee802111_unregister_hw is called unconditionally
> leading to a kernel NULL pointer dereference among other things.
>
> As with other drivers that delay registration after probe, we track the
> registration state in a flag variable and conidtionalize deregistration.
>
> Link: https://bugs.debian.org/1029116
> Link: https://bugs.kali.org/view.php?id=8140
> Reported-by: Stuart Hayhurst
> Fixes: 1c71e03afe4b ("mt76: mt7921: move mt7921_init_hw in a dedicated work")
> Signed-off-by: Helmut Grohne
> Cc: sta...@vger.kernel.org
> Sponsored-by: Freexian and Offensive Security
Hi Helmut,
Thx for working on this. I would say it is a more general issue since we have
dbdc support in mt7915/mt7996/mt7915 devices. I think we can move the check in
mac80211.c, what do you think? Something like (please note this patch is not
tested):
diff --git a/drivers/net/wireless/mediatek/mt76/mac80211.c
b/drivers/net/wireless/mediatek/mt76/mac80211.c
index b117e4467c87..34abf70f44af 100644
--- a/drivers/net/wireless/mediatek/mt76/mac80211.c
+++ b/drivers/net/wireless/mediatek/mt76/mac80211.c
@@ -539,6 +539,7 @@ int mt76_register_phy(struct mt76_phy *phy, bool vht,
if (ret)
return ret;
+ set_bit(MT76_STATE_REGISTERED, >state);
phy->dev->phys[phy->band_idx] = phy;
return 0;
@@ -549,6 +550,9 @@ void mt76_unregister_phy(struct mt76_phy *phy)
{
struct mt76_dev *dev = phy->dev;
+ if (!test_bit(MT76_STATE_REGISTERED, >state))
+ return;
+
if (IS_ENABLED(CONFIG_MT76_LEDS))
mt76_led_cleanup(phy);
mt76_tx_status_check(dev, true);
@@ -719,6 +723,7 @@ int mt76_register_device(struct mt76_dev *dev, bool vht,
return ret;
WARN_ON(mt76_worker_setup(hw, >tx_worker, NULL, "tx"));
+ set_bit(MT76_STATE_REGISTERED, >state);
sched_set_fifo_low(dev->tx_worker.task);
return 0;
@@ -729,6 +734,9 @@ void mt76_unregister_device(struct mt76_dev *dev)
{
struct ieee80211_hw *hw = dev->hw;
+ if (!test_bit(MT76_STATE_REGISTERED, >phy.state))
+ return;
+
if (IS_ENABLED(CONFIG_MT76_LEDS))
mt76_led_cleanup(>phy);
mt76_tx_status_check(dev, true);
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h
b/drivers/net/wireless/mediatek/mt76/mt76.h
index 4ffb6be63571..38c311760d15 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -402,6 +402,7 @@ struct mt76_tx_cb {
enum {
MT76_STATE_INITIALIZED,
+ MT76_STATE_REGISTERED,
MT76_STATE_RUNNING,
MT76_STATE_MCU_RUNNING,
MT76_SCANNING,
Regards,
Lorenzo
> ---
> drivers/net/wireless/mediatek/mt76/mt7921/init.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h | 1 +
> drivers/net/wireless/mediatek/mt76/mt7921/pci.c| 3 ++-
> drivers/net/wireless/mediatek/mt76/mt7921/sdio.c | 3 ++-
> drivers/net/wireless/mediatek/mt76/mt7921/usb.c| 3 ++-
> 5 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> index 542dfd425129..d5438212d5ff 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/init.c
> @@ -315,6 +315,7 @@ static void mt7921_init_work(struct work_struct *work)
> dev_err(dev->mt76.dev, "register device failed\n");
> return;
> }
> + dev->hw_registered = true;
>
> ret = mt7921_init_debugfs(dev);
> if (ret) {
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
> b/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
> index 15d6b7fe1c6c..e3b5d8ebf243 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/mt7921.h
> @@ -288,6 +288,7 @@ struct mt7921_dev {
> bool hw_full_reset:1;
> bool hw_init_done:1;
> bool fw_assert:1;
> + bool hw_registered:1;
>
> struct list_head sta_poll_list;
> spinlock_t sta_poll_lock;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> index cb72ded37256..1841eb7345dc 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci.c
> @@ -110,7 +110,8 @@ static void mt7921e_unregister_device(struct mt7921_dev
> *dev)
> struct mt76_connac_pm *pm = >pm;
>
> cancel_work_sync(>init_work);
&
Bug#1031658: plasma-desktop: Depends on plasma-workspace-wayland looks wrong
Package: plasma-desktop Version: 4:5.27.0-1 Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear maintainer, Latest update (4:5.27.0-1) of this package adds a dependency on plasma-workspace-wayland (it already dependes on plasma-workspace); however it looks like this is not accurate since plasmadesktop works just fine with plasma-workspace/kwin-x11, as I'm doing right now. Please consider to add an OR dependency like plasma-workspace-wayland | plasma-workspace so that users can choose to install only packages that they need, like only X11 or only wayland. Thanks, Lorenzo -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages plasma-desktop depends on: ii accountsservice 22.08.8-6 ii breeze 4:5.27.0-1 ii kactivitymanagerd5.27.0-1 ii kde-cli-tools4:5.27.0-1 ii kded55.103.0-1 ii kio 5.103.0-1 ii kpackagetool55.103.0-1 ii layer-shell-qt 5.27.0-1 ii libaccounts-qt5-11.16-2 ii libc62.36-8 ii libglib2.0-0 2.74.5-1 ii libibus-1.0-51.5.27-5 ii libkaccounts24:22.12.1-1 ii libkf5activities55.103.0-1 ii libkf5activitiesstats1 5.103.0-1 ii libkf5authcore5 5.103.0-1 ii libkf5baloo5 5.103.0-1 ii libkf5bookmarks5 5.103.0-1 ii libkf5codecs55.103.0-1 ii libkf5completion55.103.0-1 ii libkf5configcore55.103.0-1 ii libkf5configgui5 5.103.0-1 ii libkf5configwidgets5 5.103.0-1 ii libkf5coreaddons55.103.0-1 ii libkf5crash5 5.103.0-1 ii libkf5dbusaddons55.103.0-1 ii libkf5globalaccel-bin5.103.0-1 ii libkf5globalaccel5 5.103.0-1 ii libkf5guiaddons5 5.103.0-1 ii libkf5i18n5 5.103.0-1 ii libkf5iconthemes55.103.0-1 ii libkf5itemviews5 5.103.0-1 ii libkf5jobwidgets55.103.0-1 ii libkf5kcmutils5 5.103.0-1 ii libkf5kcmutilscore5 5.103.0-1 ii libkf5kdelibs4support5 5.103.0-1 ii libkf5kiocore5 5.103.0-1 ii libkf5kiofilewidgets55.103.0-1 ii libkf5kiogui55.103.0-1 ii libkf5kiowidgets55.103.0-1 ii libkf5newstuffcore5 5.103.0-1 ii libkf5notifications5 5.103.0-1 ii libkf5notifyconfig5 5.103.0-1 ii libkf5package5 5.103.0-1 ii libkf5plasma55.103.0-1 ii libkf5plasmaquick5 5.103.0-1 ii libkf5quickaddons5 5.103.0-1 ii libkf5runner55.103.0-1 ii libkf5service-bin5.103.0-1 ii libkf5service5 5.103.0-1 ii libkf5solid5 5.103.0-1 ii libkf5sonnetcore55.103.0-1 ii libkf5sonnetui5 5.103.0-1 ii libkf5widgetsaddons5 5.103.0-1 ii libkf5windowsystem5 5.103.0-1 ii libkf5xmlgui55.103.0-1 ii libkworkspace5-5 4:5.27.0-1 ii libnotificationmanager1 4:5.27.0-1 ii libpackagekitqt5-1 1.1.0-1 ii libphonon4qt5-4 4:4.11.1-4 ii libprocesscore9 4:5.27.0-1 ii libqt5concurrent55.15.8+dfsg-2 ii libqt5core5a 5.15.8+dfsg-2 ii libqt5dbus5 5.15.8+dfsg-2 ii libqt5gui5 5.15.8+dfsg-2 ii libqt5network5 5.15.8+dfsg-2 ii libqt5qml5 5.15.8+dfsg-2 ii libqt5quick5 5.15.8+dfsg-2 ii libqt5quickwidgets5 5.15.8+dfsg-2 ii libqt5sql5 5.15.8+dfsg-2 ii
Bug#1031215: ITP Gradience
Il 15/02/23 20:19, matthias.geiger1...@tutanota.de ha scritto: Hi Lorenzo, I saw you mail. Gradience could probably be maintained with the Debian GNOME team since it's somewhat related. There you could easily find someone to sponsor you upload. At the moment there is the debian freeze in place for the bookworm release, meaning no new packages will be uploaded. This doesn't mean you can't start working on the package. For gradience to be distributed all dependencies have to be in debian. Looking at https://github.com/GradienceTeam/Gradience/blob/main/requirements.txt <https://github.com/GradienceTeam/Gradience/blob/main/requirements.txt> there might be some missing ones which in turn might need packaging first. For an example of a gnome/gtk python app and the packaging you can take a look at https://salsa.debian.org/gnome-team/wike <https://salsa.debian.org/gnome-team/wike> . Feel free to send me an email if any questions arise. CC Jeremy: Looks like someone was faster ;) Happy hacking, Matthias Geiger (werdahias) Thanks for the input! I'll ask the gnome team right away. -- lorenzo
Bug#1031285: reportbug: redshift-gtk closes returning from monitor standby
Package: redshift Version: 1.12-4.2 Severity: normal Dear Maintainer, I started receiving error messages from redshift-gtk when I changed my monitors configuration. Now I have an external monitor as my main monitor and the monitor of my notebook turned off. The message says: > Failed to run Redshift > Failed to start adjustment method wayland. > Trying next method... > Waiting for initial location to become available... > `RANDR Set CRTC Gamma' returned error 148 > Temperature adjustment failed. Then redshift-gtk closes. This occurs every time I return from monitor standby. If I reopen redshift-gtk, it works as usual, until my monitor goes standby again. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-21-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_AUX Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages redshift depends on: ii libc6 2.31-13+deb11u5 ii libdrm2 2.4.104-1 ii libglib2.0-02.66.8-1 ii libwayland-client0 1.18.0-2~exp1.1 ii libx11-62:1.7.2-1 ii libxcb-randr0 1.14-3 ii libxcb1 1.14-3 ii libxxf86vm1 1:1.1.4-1+b2 Versions of packages redshift recommends: ii geoclue-2.0 2.5.7-3 redshift suggests no packages. -- no debconf information
Bug#1031244: mariadb-server.postinst: line 236: [: too many arguments
Package: mariadb-server Version: 1:10.11.1-4 Severity: normal X-Debbugs-Cc: plore...@disroot.org Hello, During the last upgrade of mariadb in Sid, when the unversioned package replaced the versioned one, I run into the following output: [...] Processing triggers for mailcap (3.70+nmu1) ... Processing triggers for desktop-file-utils (0.26-1) ... Processing triggers for hicolor-icon-theme (0.17-2) ... Setting up mariadb-server (1:10.11.1-4) ... Installing new version of config file /etc/init.d/mariadb ... Installing new version of config file /etc/logrotate.d/mariadb ... Installing new version of config file /etc/mysql/mariadb.conf.d/50-server.cnf ... /var/lib/dpkg/info/mariadb-server.postinst: line 236: [: too many arguments insserv: warning: current start runlevel(s) (empty) of script `mariadb' overrides LSB defaults (2 3 4 5). [...] I suspect this is another instance of #1029136. I use apt-get to upgrade and it doesn't automatically purge removed packages; for this reason I'm not affected by #1029136 but also I have several old postrm files in the system ls /var/lib/dpkg/info/* | grep mariadb-server- /var/lib/dpkg/info/mariadb-server-10.0.list /var/lib/dpkg/info/mariadb-server-10.0.postrm /var/lib/dpkg/info/mariadb-server-10.1.list /var/lib/dpkg/info/mariadb-server-10.1.postrm /var/lib/dpkg/info/mariadb-server-10.3.list /var/lib/dpkg/info/mariadb-server-10.3.postrm /var/lib/dpkg/info/mariadb-server-10.5.list /var/lib/dpkg/info/mariadb-server-10.5.postrm /var/lib/dpkg/info/mariadb-server-10.6.list /var/lib/dpkg/info/mariadb-server-10.6.postrm So the test in postinstall line 236 fails and dh snippets in postrm files are not removed. Regards, Lorenzo -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages mariadb-server depends on: ii adduser 3.131 ii debconf [debconf-2.0] 1.5.82 ii galera-426.4.13-1 ii gawk1:5.1.0-1 ii iproute26.1.0-1 ii libc6 2.36-8 ii libdbi-perl 1.643-4 ii libpam0g1.5.2-6 ii libssl3 3.0.8-1 ii libstdc++6 12.2.0-14 ii lsof4.95.0-1 ii mariadb-client 1:10.11.1-4 ii mariadb-common 1:10.11.1-4 ii mariadb-plugin-provider-bzip2 1:10.11.1-4 ii mariadb-plugin-provider-lz4 1:10.11.1-4 ii mariadb-plugin-provider-lzma1:10.11.1-4 ii mariadb-plugin-provider-lzo 1:10.11.1-4 ii mariadb-plugin-provider-snappy 1:10.11.1-4 ii mariadb-server-core 1:10.11.1-4 ii passwd 1:4.13+dfsg1-1 ii perl5.36.0-7 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 ii pv 1.6.20-1 Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 ii mailutils [mailx] 1:3.15-3+b2 pn mariadb-test pn netcat-openbsd -- debconf information: mariadb-server/old_data_directory_saved: mariadb-server/postrm_remove_databases: false mariadb-server/nis_warning:
Bug#1031215: ITP: gradience -- Gradience is a tool for customizing Libadwaita applications and the adw-gtk3 theme
Package: wnpp Severity: wishlist Owner: Lorenzo Bertini X-Debbugs-Cc: debian-de...@lists.debian.org, lorenzobertin...@gmail.com * Package name: gradience Version : 0.4.0 Upstream Contact: * URL : https://github.com/GradienceTeam/Gradience * License : GPL-3.0 Programming Lang: Python Description : Gradience is a tool for customizing Libadwaita applications and the adw-gtk3 theme Gradience is a tool for customizing Libadwaita applications and the adw-gtk3 theme. The main features of Gradience include the following: * Changing any color of Adwaita theme * Applying Material 3 color scheme from wallpaper * Usage of other users presets * Changing advanced options with CSS * Extending functionality using plugins This program is widely used for libadwaita and general gtk3-4 theming. It has over 700 start on github, while adw-gtk3 has over 900, it's actively maintained. This package doesn't really have an alternative or programs with similar functionality. I use it frequently and I would like to maintain it. I'm familiar with building programs, and I know how to make a debian package. I read in the wiki that I need a sponsor, so I wait for further guidance.
Bug#1031111: orphan-sysvinit-scripts: please add a script for Avahi daemon
Package: orphan-sysvinit-scripts
Version: 0.12
Severity: wishlist
Tags: patch
X-Debbugs-Cc: plore...@disroot.org
Hi,
Michael just dropped [1] another init script (actually two), this time is avahi.
I think it would be nice to add the scripts to this package for bookworm,
if possible. I'm attaching the last version of the init script from avahi 0.8-7;
mapping is:
avahi-daemon.service avahi-daemon
avahi-dnsconfd.service avahi-dnsconfd
License is GNU Lesser General Public License, version 2 or any later version
Not sure if the scripts are from upstream or Debian:
Utopia Maintenance Team
or
Upstream Avahi developers
Best Regards,
Lorenzo
[1]
https://tracker.debian.org/news/1417862/accepted-avahi-08-8-source-into-unstable/
and also
https://salsa.debian.org/utopia-team/avahi/-/commit/41a296309334853ed3164544bd39d872a8fc70a4
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND,
TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages orphan-sysvinit-scripts depends on:
ii ucf 3.0043+nmu1
orphan-sysvinit-scripts recommends no packages.
orphan-sysvinit-scripts suggests no packages.
#!/bin/sh
### BEGIN INIT INFO
# Provides: avahi avahi-daemon
# Required-Start:$remote_fs dbus
# Required-Stop: $remote_fs dbus
# Should-Start: $syslog
# Should-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Avahi mDNS/DNS-SD Daemon
# Description: Zeroconf daemon for configuring your network
#automatically
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DESC="Avahi mDNS/DNS-SD Daemon"
NAME="avahi-daemon"
DAEMON="/usr/sbin/$NAME"
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
# Include avahi-daemon defaults if available.
test -f /etc/default/avahi-daemon && . /etc/default/avahi-daemon
DISABLE_TAG="/var/run/avahi-daemon/disabled-for-unicast-local"
#
# Function that starts the daemon/service.
#
d_start() {
$DAEMON -c && return 0
if [ -e $DISABLE_TAG -a "$AVAHI_DAEMON_DETECT_LOCAL" != "0" ]; then
# Disabled because of the existance of an unicast .local domain
log_warning_msg "avahi-daemon disabled because there is a unicast
.local domain"
exit 0;
fi;
$DAEMON -D
}
#
# Function that stops the daemon/service.
#
d_stop() {
if $DAEMON -c ; then
$DAEMON -k
fi
}
#
# Function that reload the config file for the daemon/service.
#
d_reload() {
$DAEMON -c && $DAEMON -r
}
#
# Function that check the status of the daemon/service.
#
d_status() {
$DAEMON -c && { echo "$DESC is running"; exit 0; } || { echo "$DESC is not
running"; exit 3; }
}
case "$1" in
start)
log_daemon_msg "Starting $DESC" "$NAME"
d_start
log_end_msg $?
;;
stop)
log_daemon_msg "Stopping $DESC" "$NAME"
d_stop
log_end_msg $?
;;
reload|force-reload)
log_daemon_msg "Reloading services for $DESC" "$NAME"
d_reload
log_end_msg $?
;;
restart)
log_daemon_msg "Restarting $DESC" "$NAME"
d_stop
if [ "$?" -eq 0 ]; then
d_start
log_end_msg $?
else
log_end_msg 1
fi
;;
status)
d_status
;;
*)
echo "Usage: $SCRIPTNAME
{start|stop|restart|force-reload|reload|status}" >&2
exit 3
;;
esac
exit 0
#!/bin/sh
### BEGIN INIT INFO
# Provides: avahi-dnsconfd
# Required-Start:$remote_fs avahi-daemon
# Required-Stop: $remote_fs avahi-daemon
# Should-Start: $syslog
# Should-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Avahi Unicast DNS Configuration Daemon
# Description: A DNS configuration daemon using mDNS in a
#DHCP-like fashion
### END INIT INFO
PATH=/sbin:/bin:/usr/sbin:/usr/bin
DESC="Avahi Unicast DNS Configuration Daemon"
NAME="avahi-dnsconfd"
DAEMON="/usr/sbin/$NAME"
SCRIPTNAME=/etc/init.d/$NAME
# Gracefully exit if the package has been removed.
test -x $DAEMON || exit 0
. /lib/lsb/init-functions
#
# Function that starts the daemon/service.
#
d_start() {
$DAEMON -c && return 0
if [
Bug#1031054: RFS: runit/2.1.2-54 -- system-wide service supervision
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit": * Package name : runit Version : 2.1.2-54 Upstream contact : Gerrit Pape * URL : http://smarden.org/runit/ * License : CC0-1.0, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/debian/runit Section : admin The source builds the following binary packages: runit - system-wide service supervision runit-run - service supervision (systemd and sysv integration) runit-systemd - transitional package for runit-systemd users getty-run - runscripts to supervise getty processes runit-init - system-wide service supervision (as init system) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-54.dsc Git: https://salsa.debian.org/debian/runit/-/tree/next Changes since the last upload: runit (2.1.2-54) unstable; urgency=medium . * stage2: fix inverted test for no.emulate.sysv. + Thanks to Andras Korn (Closes: #1030224) * stage 2: stop mounting a tmpfs for now (Closes: #1030225) * d/rules: undo changelog trimming for runit package Regards, Lorenzo
Bug#1030224: Inverted test for /etc/runit/no.emulate.sysv in /etc/runit/2
Hi, On Wed, 1 Feb 2023 11:35:17 +0100 Andras Korn wrote: > (I still also think that /etc/sv is the wrong place to check; the > directory monitored by runsvdir, e.g. /etc/service, could contain a > symlink to a service that resides somewhere else, not in /etc/sv/, > and the existence of such a symlink should also cause the initscript > invocation to be skipped.) Please see my last message/idea in #1022837 and comment there > > For this particular issue in /etc/runit/2, I recommend just replacing > the || with &&, so the snippet becomes: Done in git, will be in *-54, thanks for catching this > András >
Bug#1030225: /etc/runit/2 assumes it runs in an environment that can mount filesystems
Hi, On Wed, 1 Feb 2023 11:43:43 +0100 Andras Korn wrote: > /etc/runit/2 ships with this snippet: > > mkdir -p /run/runit/supervise > mkdir -p /run/runit/sv > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv > cp -a /etc/sv/* /run/runit/sv/ #TODO do this with > 'CPSV_DIR=/run/runit/sv cpsv --sync' > > If runit is used in an unprivileged container, with runit you mean runit as init or simply respawn runsvdir via stage 2? The mount can be moved to stage 1, where other mount invocations already happen; however this will cause a relevant difference when runit is used as init vs when only stage 2/runsvdir is run.. > the mount command may > fail. Currently this is just a cosmetic problem (/lib/runit/sv will > not be a separate filesystem and an error will be printed), but > please don't start depending on this mount succeeding. Noted; that was a preliminary step for a development that didn't happen so far (because of the complexity, the freeze approaching and also because of your comments in #1022837); for now I'm just removing or commenting those lines, for the future (after bookworm releaee) I still have to think about it. > > Please also provide some reasoning (e.g. in a README.Debian file) why > you're doing this at all, what the motivation is. I'm not going to write a README.Debian for something that is not there (yet), but I'm providing one here: ---RATIONALE- > mount -t tmpfs -o size=20M,mode=0755 runtimesv /run/runit/sv the idea is to have a copy of services there and to run services there, like /etc/service points to /etc/runit/runsvdir/deafult.run that contains links to directories in /run/runit/sv/ without that mount line: Problem 1: run is mounted 'noexec', so each runsv fails Problem 2: there are mechanism (cpsv) that copy services in /run and by limiting the size I want to avoid that an abuse of such mechanism could result in eating all space in /run mount (very unlikely but still..) Reasons why I'm thinking of running services in /run/runit/sv/ : A) anything in /etc/sv is a conffile, so special care is needed when upgrade happens to detect and not overwrite local changes. That is handled by dpkg or ucf, but they work on files, while a service for runit is a directory. I think ideally the entire service should be considered locally modified if the run file (or finish, or control/* and probably also log/run) has local changes. I can think of many ways to break a service by retaining the local version of a run file while finish or control/* are changed/upgraded. B) related to A, but different problem: think of what happens if a foo service crashes while dpkg is upgrading (file by file) the service directory: the automatic restart performed by runsv can exec a mix of old and new files inside foo directory, with unexpected results like in A, but temporary (only during the upgrade). Ideally the entire service directory should be updated atomically but that requires to address the old.directory with a symlink, creating a new.directory on upgrade and swap the symlink old-->new. Also a plus would be a setup that works on a system where /etc is stateless or mounted readonly. As a possible solution to A and B I thought something like: A 3 layer services setup, like [stock] /usr/share/runit/sv/ --> original copy managed by dpkg [local] /etc/sv/ --> local modified copy, if any [live] /run/runit/sv/--> copy supervised by runsv where /etc/sv can be empty, and [live] is populated with copies of services from [local] if any, from [stock] otherwise. the above allow me (maintainer) to upgrade the [live] copy for service foo with [stock] unless [local] foo exists; much simpler than when the service in under /etc/sv It also separates service directories supervised by runsv and services directories managed by dpkg (necessary to fix both A and B). Also to address B /run/runit/sv can be a symlink to a timestamped /run/runit/sv.time dir that contains copies of services dirs; each upgrade adds a new sv.time dir and switches the symlink to the new sv.time(you can roll back a service dir upgrade, there will be multiple sv.time under /run/runit and so on); again it avoid the added complexity of conffiles ( and a pile of sv.time dirs that accumulates under /etc/) right now I'm taking some time to think about this: nobody complained so far about A or B [1], no runit user requested any of the above features; there is added complexity with this setup and it requires a relevant effort on my side. Also,some people will likely be unhappy about this. Overall I'm tempted to just sit and wait until someone complains and spend my time to solve other runit issues meanwhile. [1] I think a large number of users and dpkg-provide services are needed to trigger A or B; none of the two is true right
Bug#1029485: RFS: runit/2.1.2-53 [RC] -- system-wide service supervision
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "runit": * Package name : runit Version : 2.1.2-53 Upstream contact : Gerrit Pape * URL : http://smarden.org/runit/ * License : CC0-1.0, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/debian/runit Section : admin The source builds the following binary packages: runit - system-wide service supervision runit-run - service supervision (systemd and sysv integration) runit-systemd - transitional package for runit-systemd users getty-run - runscripts to supervise getty processes runit-init - system-wide service supervision (as init system) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-53.dsc Git repo: https://salsa.debian.org/debian/runit/-/tree/next Changes since the last upload: runit (2.1.2-53) unstable; urgency=medium . * runit-init: - depends on mount [linux-any] (Closes: #1028181) - change architecture field to any, because of mount - recommends runit-services * runit: suggests runit-services * getty-run: - enable the serial getty-ttyS0 by default - make getty-ttyS0 device configurable - automatically set device for getty-ttyS0 from kernel `console=' command line (Closes: #1028270) * d/copyright: update copyright years * d/tests: update init-switch test Regards, Lorenzo
Bug#1029209: RFS: runit-services/0.5.4 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.5.4 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : BSD-3-Clause, CC0-1.0 * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.4.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next Changes since the last upload: runit-services (0.5.4) unstable; urgency=medium . * Add a flaky autopkgtest - d/tests/control file - blacklist services that are too hard or impossible to test - test all non-blacklisted services * update copyright * dbus.dep-fixer: wait for elogind only if it's enabled * isc-dhcp-server: - test config and lease - default to -4 - configurable (empty by default) interfaces * dbus: simplify run script Regards, Lorenzo
Bug#1028307: rocminfo and other packages have the same name as packages in the rocm repository
Il 09/01/23 20:19, Étienne Mollier ha scritto: Hi Lorenzo, Lorenzo Bertini, on 2023-01-09: Dear maintainer, rocminfo, rocm-device-libs and rocm-cmake packages have the same names as their counterparts in the "official" repo in https://repo.radeon.com/rocm/apt/. When I add this repository, apt tries to install the system version, so I have to manually force the version the other packages in the repo need. How should this be handled? Thanks for your report, I must admit that has been bothering me as well at some point, but AMD actually provides an escape hatch for this case. Since ROCm 3.3, each package in repo.radeon.com has a versioned equivalent, e.g. rocminfo5.4.1 for the rocminfo command of ROCm 5.4.1. Note that if you use the versioned package names, you need to use it consistently for your whole ROCm installation. However this makes upgrading version a bit less transparent than using the unversioned packages allows; but I recall having read in ROCm documentation that certain version jumps used to require a full reinstallation anyway. An other option involves pinning package versions, but I'm not personally comfortable with this particular way of managing packages, but I believe it would work if you have to deal with older ROCm versions than 3.3. If you are trying to keep up with the lastest/ stream of packages, I'm not sure I have a good solution at hand right now. In hope this helps, Pinning packages is what I'm doing right now and it was surprisingly less painful than I tought, except that my package manager (synaptic) doesn't seem to care and I have to resort to apt. However, your suggestion of using rocm-X.Y.Z package seems better. Don't know why I didn't think about it. Also, the hierarchy of rocm packages seems to change sometimes, so updating requires reinstalling a lot of components often :). Thank you. -- Lorenzo
Bug#1028307: rocminfo and other packages have the same name as packages in the rocm repository
Package: rocminfo Version: 1.0.0.50400-72~22.04 Severity: normal X-Debbugs-Cc: lorenzobertin...@gmail.com Dear maintainer, rocminfo, rocm-device-libs and rocm-cmake packages have the same names as their counterparts in the "official" repo in https://repo.radeon.com/rocm/apt/. When I add this repository, apt tries to install the system version, so I have to manually force the version the other packages in the repo need. How should this be handled? -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rocminfo depends on: ii hsa-rocr 1.7.0.50400-72~22.04 ii kmod 30+20221128-1 ii pciutils 1:3.9.0-2 ii rocm-core 5.4.0.50400-72~22.04 rocminfo recommends no packages. rocminfo suggests no packages. -- no debconf information
Bug#1028181: runit-init makes the system unbootable
Hi Helmut, thanks for taking the time to test runit On Sun, 8 Jan 2023 07:08:36 +0100 Helmut Grohne wrote: > The biggest problem here is the lack of mount. mount is not essential > and nothing depends on it, so it goes missing. Something in the runit > ecosystem should definitely depend on mount. right > > It seems like runit requires checking the filesystem, but e2fsprogs is > not essential anymore and it fails hard. Nowadays, checking ext4 > filesystems is optional and systemd skips doing it in the absence of > e2fsprogs. This need to be adjusted in the initcripts package, as a quick fix I'm going to add a dependency on e2fsprogs too. > > So I went on to retry with e2fsprogs added and this is what I got: > > | Begin: Running /scripts/local-bottom ... done. > | Begin: Running /scripts/init-bottom ... done. > | [1.484294] Not activating Mandatory Access Control as [...] > | Cleaning up temporary files > | Cleaning up temporary files > | - runit: leave stage: /etc/runit/1 > | - runit: enter stage: /etc/runit/2 > | runsvchdir: default: current. > > In particular, the user has no way to log into the system as no getty > is being spawned. I see that the autopkgtest has to do this manually > via "ln -s /etc/sv/getty-ttyS0 /etc/service/". Do you think there > could be a better way to achieve this such that at least the console= > kernel command line parameter is automatically issued a getty? This one is a separate issue: true that a serial-getty is not automatically started (there are gettys on tty[1-6] for standard usage) but a getty-ttyS0 service that can be enabled and tuned to the right device exists, so I don't think that this last part is RC.. Sure there is no documentation on how to do it and anyway there is room for improvement. I've opened a separate (#1028270) bug for the "no way to login" issue above, if you disagree with the non-RC severity of #1028270 please change the severity of that one as I'm going to close this one by adding two dependency to runit-init. Best, Lorenzo > Helmut
Bug#1028270: getty-run: enable a serial getty to increase testability of runit-init
Package: getty-run Version: 2.1.2-52 Severity: important X-Debbugs-Cc: Helmut Grohne , plore...@disroot.org Hi Helmut, >From #1028181 > | Activating swapfile swap, if any...done. > | Cleaning up temporary files > | Cleaning up temporary files > | - runit: leave stage: /etc/runit/1 > | - runit: enter stage: /etc/runit/2 > | runsvchdir: default: current. > > In particular, the user has no way to log into the system as no getty > is being spawned. I see that the autopkgtest has to do this manually > via "ln -s /etc/sv/getty-ttyS0 /etc/service/". Note that the "user has no way to log into the system" is true if the only mean to login is a serial port; by default the user has 6 getty on tty[1-6] enabled. Said that I agree that it's nice to provide a setup that works out of the box; the quick fix that hopefully can improve the situation is that getty-run ship that service as enabled (it's disabled by default right now) so that the manual creation of the link is no longer needed. However I'm afraid that, since /dev/ttyS0 is hardcoded in the service, it won't work in environments where the serial device has a different name (let's say ttyS1)... > Do you think there > could be a better way to achieve this such that at least the console= > kernel command line parameter is automatically issued a getty? (just to be sure that I'm not misunderstanding the above) are you suggesting that runit grep /proc/cmdline for `console=' and if there is a match extract the device name and start a getty on that device? Or there is another more obvious way that I'm not considering? Lorenzo > > Helmut Note to myself: * the command= parameter can take several forms and there are comma separated options [1] * see also what systemd does with the getty-generator [2] [1] https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html [2] https://manpages.debian.org/testing/systemd/systemd-getty-generator.8.en.html
Bug#1028267: initscripts: runs fsck unconditionally but does not depends on e2fsprogs
Package: initscripts Version: 3.06-2 Severity: normal X-Debbugs-Cc: plore...@disroot.org Hi all, there are 2 scripts that run fsck without testing if the command is available in the system: checkroot.sh and checkfs.sh This package "only" recommands e2fsprogs, so I think it should just print a warning and go ahead if fsck is not available. The current behaviour can fail to boot in some cases https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028181 Lorenzo -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.1.0van (SMP w/4 CPU threads; PREEMPT) Kernel taint flags: TAINT_CPU_OUT_OF_SPEC, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: runit (via /run/runit.stopit) Versions of packages initscripts depends on: ii sysv-rc 3.06-2 ii sysvinit-utils 3.06-2 Versions of packages initscripts recommends: ii e2fsprogs 1.46.6~rc1-1+b1 ii psmisc 23.6-1 initscripts suggests no packages. -- Configuration Files: /etc/init.d/mountall.sh changed [not included] -- no debconf information
Bug#1006971: runit-init: Add runit-init as Pre-Depends of init metapackage [tracker]
Update * The bug request for requirements for being a pre-dep of init is #1028115 [1] About the list of TODO in #923450; > * If the init system is booted in the most obvious way on a simple TUI > system (similar to a default Debian install with Priority: standard > packages), it should start at least one console getty on a VT for > interactive login, without the sysadmin needing to set this up > manually. DONE The runit-init package depends on getty-run package, that provides six gettys enabled on /dev/tty[1-6] by default on linux. > * It should be possible to configure the init system to provide a > getty > on a serial console, for testability on headless servers and VMs, > and it should be documented how to do this. > (systemd makes this very convenient, by starting a getty on the > kernel > console by default, and I would encourage this approach. sysvinit is > less convenient here, but does at least have a relatively well-known > way to enable a getty on a serial console.) The getty-run package also provides a getty-ttyS0 service that is disabled by default. TODO: - document how to enable the getty on a serial console or - enable it by default >* If the init system is booted in the most obvious way on a simple GUI > system, it should be possible to start an X11 display manager and log > in to a simple X11 GUI by merely installing packages, again without > needing manual setup. I think it's fine to have non-default init > systems > that don't satisfy the dependencies of major desktop environments > like GNOME and KDE (which need systemd-logind, which in turn needs > systemd), but something like xdm + openbox should always be possible, > and ideally any desktop environment whose dependencies are met should > work without further sysadmin intervention. DONE even major DE like KDE (and probably also GNOME, but did not tested it) works; the main problem right now is switching init and installing elogind without having the DE entirely removed, but this is beyond the scope of runit-init. Once the user has managed to switch to runit, things works as expected. >* If the init system is booted in the most obvious way on a server > with popular/important server daemons (particularly OpenSSH since > that's a > common way to log in, but also things like Apache httpd, Exim, > Postfix, > PostgreSQL, dbus-daemon), then those server daemons should work > correctly without further sysadmin intervention. DONE The openssh-server package provides a runit service; other important services are included in the runit-services package which is now in testing > * As a "lowest common denominator" to enable the majority of services > to work, the init system should be able to run services that are > defined > by LSB init scripts, either directly (as sysv-rc does) or by > translating > them into its own representation of a service (as systemd does). DONE The runit package ships a /lib/runit/run_sysv_scripts script that starts sysv scripts (S links in rc2) in the right order at boot and stops sysv scripts at shutdown. A sysv script is skipped when a native runit scripts with the same basename exists in the system. This approach is not free from potential bugs [2] but it works as expected right now > * It should be straightforward for maintainers of unrelated packages > to > boot the init system on a virtual machine for testing. I see that on > #838480, Martin Pitt suggested an autopkgtest that would codify how > to > do this and verify that it works, and I think that's an excellent > idea. A runit-init switch autopkgtest called `init-switch' was added in runit 2.1.2-32 and a rule to manually run the test was added in runit 2.1.2-33. The test installs runit-init and then reboot into it, so both the init switch and runit boot are tested. TODO: update the test to include runit-services package. > * The init system should have a CLI broadly compatible with the common > interface of sysvinit and systemd: reboot, poweroff, telinit and > so on. Unfortunately this is mostly defined by Unix folklore rather > than a formal specification, but comparing the commands provided by > sysvinit and systemd would be a good starting point, and so would > comparing each of sysvinit and systemd with the list of executables > mentioned in the FHS. > > I agree with your comment on #838480 that shutdown's time > specification > feature is perhaps more complicated than you would want to implement, > but it might be reasonable to consider implementing it so all time > specifications other than 'now' are errors? DONE The runit-init package ships compatibility symlinks for halt, poweroff, reboot, shutdown, runlevel. The runit package ships its own implementation of shutdown that provides an interface for halt, poweroff and reboot; it's also capable of talking with the initctl pipe so that an init switch like systemd --> runit or sysvinit --> runit does not require an hard reset. The
Bug#1028115: init: Document requirements for being an alternative pre-dependency of init
Package: init Version: 1.65.2 Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear i-s-h maintainers, I intend to ask for the inclusion of runit-init into the pre-dep list of this package right after the bookworm release. For now I'm following the list of suggestions provided by Simon McVittie [1] in #923450 msg#15; please document your requirements. Regards, Lorenzo [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923450
Bug#1005899: mplayer: should not release with bookworm
Hi Sebastian, Could you please clarify if this package should be maintained inside the Debian-Multimedia Team or outside? I.e. an uploader or a new maintainer? Regards, Lorenzo On Wed, 16 Feb 2022 23:25:00 +0100 Sebastian Ramacher wrote: > Source: mplayer > Version: 2:1.4+ds1-3 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > Tags: sid bookworm > > Let's stop pretending that mplayer is maintained. The upstream mailing > list infrastructure is gone and development has been minimal over the > last couple of months and years. So I think we should not include > mplayer in bookworm. mpv is a worthy replacement for mplayer. > > Cheers > -- > Sebastian Ramacher
Bug#1027300: RFS: runit-services/0.5.3 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.5.3 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : BSD-3-Clause, CC0-1.0 * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.3.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next Changes since the last upload: runit-services (0.5.3) unstable; urgency=medium . * update Readme * runit-services: depends on runit >= 2.1.2-51 * Bump Standards-Version * bump B-D dh-runit >= 2.15.2, to get rid of duplicates metafiles * release to unstable Regards, Lorenzo Puliti
Bug#1027291: RFS: dh-sysuser/1.3.8+really1.4.2 -- debhelper addon to handle creation of system users
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dh-sysuser": * Package name : dh-sysuser Version : 1.3.8+really1.4.2 Upstream contact : [fill in name and email of upstream] * URL : https://salsa.debian.org/debian/dh-sysuser * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-sysuser Section : admin The source builds the following binary packages: dh-sysuser - debhelper addon to handle creation of system users sysuser-helper - dh-sysuser implementation detail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-sysuser/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-sysuser/dh-sysuser_1.3.8+really1.4.2.dsc Git repo: https://salsa.debian.org/debian/dh-sysuser/-/tree/next Changes since the last upload: dh-sysuser (1.3.8+really1.4.2) unstable; urgency=medium . * No longer impose a strictly minor version for sysuser-helper: it doesn't save the need for a transition in case of a major version bump and it also forces the use of +really in package version * bump Standards-Version to 4.6.2 * dh_sysuser: declare our $VERSION Regards, Lorenzo Puliti
Bug#1027052: RFS: dh-runit/2.15.2 -- debhelper add-on to handle runit runscripts
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dh-runit": * Package name : dh-runit Version : 2.15.2 Upstream contact : Lorenzo Puliti * URL : https://salsa.debian.org/debian/dh-runit * License : GPL-3+ * Vcs : https://salsa.debian.org/debian/dh-runit Section : admin The source builds the following binary packages: dh-runit - debhelper add-on to handle runit runscripts runit-helper - dh-runit implementation detail To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-runit/dh-runit_2.15.2.dsc git repo: https://salsa.debian.org/debian/dh-runit/-/tree/next Changes since the last upload: dh-runit (2.15.2) unstable; urgency=medium . * bump Standards-Version * release to unstable Regards, Lorenzo Puliti
Bug#1027030: RFS: runit/2.1.2-52 -- system-wide service supervision
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "runit": * Package name : runit Version : 2.1.2-52 Upstream contact : Gerrit Pape * URL : http://smarden.org/runit/ * License : CC0-1.0, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/debian/runit Section : admin The source builds the following binary packages: runit - system-wide service supervision runit-run - service supervision (systemd and sysv integration) runit-systemd - transitional package for runit-systemd users getty-run - runscripts to supervise getty processes runit-init - system-wide service supervision (as init system) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit/runit_2.1.2-52.dsc git repo: https://salsa.debian.org/debian/runit/-/tree/next Changes since the last upload: runit (2.1.2-52) unstable; urgency=medium . * upload to unstable * run_sysv_scripts: remove test for name-daemon case * stage1: special case for alsa-utils initscript * bump Standards-Version, no changes required * shellcheck on cpsv, trigger_sv * cpsv: - fix wrong (old) metafiles path for make_svlinks - update also log/run with -f - stop using a tmp dir - exclude conf pattern with diff - small optimizations - update manpage Regards, Lorenzo Puliti
Bug#1026836: RFS: runit-services/0.5.2 -- UNIX init scheme with service supervision (services)
Package: sponsorship-requests Severity: normal X-Debbugs-Cc: plore...@disroot.org Dear mentors, I am looking for a sponsor for my package "runit-services": * Package name : runit-services Version : 0.5.2 Upstream contact : [fill in name and email of upstream] * URL : [fill in URL of upstream's web site] * License : BSD-3-Clause, CC0-1.0 * Vcs : https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services Section : admin The source builds the following binary packages: runit-services - UNIX init scheme with service supervision (services) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/runit-services/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/runit-services/runit-services_0.5.2.dsc Git repo: https://salsa.debian.org/Lorenzo.ru.g-guest/runit-services/-/tree/next Changes since the last upload: runit-services (0.5.2) experimental; urgency=medium . * Improve purge documentation (Closes: #1024962) * Fix wrong boot order for sysv dbus-services (Closes: #1024969) * Automate d/copyright update for runscripts: - add a simple copyright header to each runfile - add d/copyright.in - add a script that automatically update d/copyright based on copyright.in and runscripts headers * update copyright and copyright.in * d/prerm: fix wrong path for meta files * All runscripts cleanup: - do not set -e, relevant commands are tested - do not use redundant 'sv check' for checking service dependencies, 'sv start' is enough Regards, -- Lorenzo Puliti
Bug#1026039: lyx: LyX is listed as proprietary software in Gnome-software
Package: lyx Version: 2.3.6.1-1 Severity: normal X-Debbugs-Cc: lorenzobertin...@gmail.com Dear Maintainer, LyX is listed on my system as proprietary software in gnome-software. Looking online I found several people having this issue with other programs, and the cause was always that the license couldn't be read by gnome-software properly. Please ensure that gnome-software can properly read the license. If the bug is not on our end, let me know and I will contact gnome-software developers. Thank you, Lorenzo -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-5-amd64 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lyx depends on: ii libc62.36-6 ii libenchant-2-2 2.3.3-1 ii libgcc-s112.2.0-9 ii libmagic11:5.41-4 ii libmythes-1.2-0 2:1.2.5-1 ii libqt5core5a 5.15.6+dfsg-5 ii libqt5gui5 5.15.6+dfsg-5 ii libqt5svg5 5.15.6-2 ii libqt5widgets5 5.15.6+dfsg-5 ii libstdc++6 12.2.0-9 ii lyx-common 2.3.6.1-1 ii xdg-utils1.1.3-4.1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages lyx recommends: ii atril [pdf-viewer] 1.26.0-2 ii dvipng 1.15-1.1+b1 ii evince [pdf-viewer] 43.1-2 ii fonts-lyx2.3.6.1-1 ii ghostscript 10.0.0~dfsg-8 ii imagemagick 8:6.9.11.60+dfsg-1.3+b4 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1.3+b4 ii poppler-utils22.08.0-2.1 ii preview-latex-style 12.2-1 ii psutils 1.17.dfsg-4 ii texlive-fonts-recommended2022.20220923-2 ii texlive-latex-extra 2022.20220923-3 ii texlive-latex-recommended2022.20220923-2 ii texlive-plain-generic2022.20220923-3 ii texlive-science 2022.20220923-3 Versions of packages lyx suggests: pn chktex pn gnuhtml2latex pn groff ii inkscape1.1.2-3+b1 pn latex2rtf ii librsvg2-bin2.54.5+dfsg-1 pn libtiff-tools pn linuxdoc-tools pn noweb pn rcs pn sgmltools-lite ii texlive-plain-generic [tex4ht] 2022.20220923-3 ii texlive-xetex 2022.20220923-2 pn writer2latex pn wv -- no debconf information
