Bug#1068759: quickml: quickml fails to install

[Benda Xu]

Hi Sudip,

Thanks for using quickml and investigating this.

The Debian policy[1] specifies that a working Debian system has the
/etc/mailname file.  I don't want to create it by the quickml package.
A runtime warning could be more useful.

Yours,
Benda

1. 
https://www.debian.org/doc/debian-policy/ch-customized-programs#s-mail-transport-agents

Bug#869108: ongoing effort

[Benda Xu]

Hi Ethan and Mehmet,

Welcome!  Are you still interested in packaging
python-speechrecognition for Debian?  I am happy to serve as a mentor
and join your effort.

https://github.com/mertyildiran/speech_recognition returned 404 to me
though.  It is migrated to somewhere else?

Yours,
Benda

Bug#1032192: In-A-Dyn request

[Benda Xu]

Hi Hans,

Hans-Joachim Hoetger  writes:

> i'm using In-A-Dyn to write only my IPv6 address to SpDyn. The address
> is provided via DHCP by my Router (FritzBox). Unfortunately dhcp with
> ipv4 is much faster than dhcp with ipv6. The interface has its v4
> address about 20s earlier than its v6 address. As dirty hack, i added
> a 'sleep 30' to 'checkip-command' in /etc/inadyn.conf
>
> --> checkip-command = "/usr/bin/sleep 30; /bin/ip address show wlp2s0
> | grep inet6 | egrep -v 'mngtmpaddr|temporary' | grep 'scope global' |
> awk -F '[ ]+|/' '{print $3}'"
>
> Then i found an option 'startup-delay' in the man pages, but could not figure 
> out, how to set this in inadyn.conf. Thats why i asked on the project 
> homepage:
> --> https://github.com/troglobit/inadyn/issues/428
>
> Joachim Wiberg pointed out, that he ships a inadyn.service file, that
> parses /etc/default/inadyn for environment variables $INADYN_OPTS and
> $INADYN_ARGS. The contents is then passed to inadyn. Can we have this
> in debian bookworm, too?

Thanks for reporting.  I am forwarding your request to bug 1032192.

Yours,
Benda


signature.asc
Description: PGP signature

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Luca Boccassi  writes:

>> I take care of packages that do not meet the proposed policy. And I
>> don't have a systemd test environment.  I am curious what is the
>> recommended way to go forward.
>>
>> - upload a generator-converted .service without any test;
>> - set low-NMU to encourage interested party to upload a .service;
>> - leave the lack-of-systemd-service bug open until some one submit a
>>   patch or a merge request;
>> - you name it.
>
> Have you already tried booting a test environment in a container
> (lxc/nspawn/podman/docker) or in a VM?

Thanks, Luca.  That's doable.

The problem is that I am now too overloaded and therefore less motivated
to maintain a test environment that I don't use myself.

Russ Allbery  writes:

> systemd unit files for "typical" daemons are very simple to write (simpler
> than an init script in a lot of cases) and generally don't change much.  I
> would, if I were you, be tempted to just write an obvious and simple unit
> file and upload it and let people report bugs if it breaks.  This isn't
> ideal, but at least for simple daemons the risk is probably relatively
> low?  Maybe I'm too cavalier, though.
>
> I suspect there are also a fair number of people who would be happy to
> help write systemd unit files for packages, since (at least in my opinion)
> it's kind of fun.  This isn't the right place to coordinate that, but
> there must be some good spot in Debian.  debian-mentors, maybe?

Thanks Russ!  Your comments alleviated my hesitations to go for option
1.  Then hopefully everyone would be happy :)

Yours,
Benda

Bug#1039102: debian-policy: make systemd units mandatory for packages shipping system services

[Benda Xu]

Hi Luca,

Luca Boccassi  writes:

>> On Sun, 2023-06-25 at 18:51 +0100, Luca Boccassi wrote:
>> > Patch attached and pushed to
>> > https://salsa.debian.org/bluca/policy/-/commits/mandatory_units?ref_type=hea
>>
>> There is one part I think should not be changed: we currently don't
>> require integration with service management at all. That should
>> probably not be changed.  So please consider reverting
>>
>> +---
>> | Packages that include system services must include ``systemd`` service
>> +---
>>
>> to the original
>>
>> +---
>> | Packages that include system services should include ``systemd`` service
>> +---
>
> How about:
>
> -Packages that include system services should include ``systemd`` service
> -units to start or stop those services.
> +Packages shipping system services should integrate with service management.
> +If they choose to do so, they must include ``systemd`` service units to start
> +or stop those services.

I take care of packages that does not meet the proposed policy. And I
don't have a systemd test environment.  I am curious what is the
recommended way to go forward.

- upload a generator-converted .service without any test;
- set low-NMU to encourage interested party to upload a .service;
- leave the lack-of-systemd-service bug open until some one submit a
  patch or a merge request;
- you name it.

Cheers,
Benda

Bug#1029596: ITP: scmutils -- scheme mathematical library

[Benda Xu]

Package: wnpp
Severity: wishlist
Owner: Benda Xu 
X-Debbugs-Cc: debian-de...@lists.debian.org, s...@l.airelinux.org

* Package name: scmutils
  Version : 20220518
  Upstream Contact: Gerald Jay Sussman 
* URL : https://groups.csail.mit.edu/mac/users/gjs/6946
* License : GPL-2+
  Programming Lang: Scheme
  Description : scheme mathematical library

 An integrated library of procedures, embedded in the programming
 language Scheme, and intended to support teaching and research in
 mathematical physics and electrical engineering.  Scmutils and Scheme
 are particularly effective in work where the almost-functional nature
 of Scheme is advantageous, such as classical mechanics, where many of
 the procedures are most easily formulated as quite abstract
 manipulations of functions.
 .
 This code was developed for educational and research use at the
 Massachusetts Institute of Technology.


This is the library accompanying the Structure and Interpretation of
Classical Mechanics (SICM) by Gerald Jay Sussman and Jack Wisdom to do
variational calculus and much more.  A group of students and I at
Tsinghua University are holding seminars to learn and extend it.  Our
members encountered errors when trying to install scmutils and set up
its integration with emacs on Debian.

We believe SICM will become the bible for classical mechanics as SICP
did for programming.  We want to lower the barrier of SICM to those
who are not (yet) tech-savvy, especially students majoring physics and
mathematics.  Such consideration justifies our intention to bring this
package to Debian.

I shall maintain this package as long as I hold this seminar, which is
expected to be at the time scale of a decade.

Bug#918887: adopt quickml

[Benda Xu]

Hi Bekks and Marcelo,

Thank you for offering help!  I have set up a collaborative maintenace
repository on salsa[1].  I converted the full upstream CVS history[2] in
the "upstream" branch, and the full debian packaging history from
snapshots[3] since 2004 in the "master" branch.

I intend to take over the upstream developments in the same repository.
You are more than welcomed to send merge requests!

Cheers,
Benda

1. https://salsa.debian.org/debian/quickml
2. https://sourceforge.net/p/quickml/code
3. https://snapshot.debian.org/package/quickml

Bug#1027051: ITP: cl-fiasco -- a test framework for Common Lisp

[Benda Xu]

Package: wnpp
Severity: wishlist
Owner: Benda Xu 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-common-l...@lists.debian.org

* Package name: cl-fiasco
  Version : 0~git20221227
  Upstream Contact: João Távora 
* URL : https://github.com/joaotavora/fiasco
* License : public-domain
  Programming Lang: Common Lisp
  Description : a test framework for Common Lisp
  
Fiasco is a fork of the abandoned Stefil test framework, simple and
powerfull, with a focus on interactive debugging.

- It is a build dependency of the unit tests of stumpwm.

- I would like to maintain it collaboratively under the Debian Common
  Lisp Team.

Bug#1026311: ITS: cl-clx-sbcl

[Benda Xu]

Package: cl-clx-sbcl
Version: 0.7.4.20160323-1.1
Severity: important
X-Debbugs-Cc: debian-common-l...@lists.debian.org

Dear Milan,

I would like to salvage cl-clx-sbcl.

The interest occurs to me when I am trying to fix the RC bug for
stumpwm (Bug 1020162).  The latest version (22.11) of stumpwm requires
a newer clx.

The package in Debian is outdated. It was even suggested at the
upstream issue tracker to uninstall Debian clx packages to manually
compile stumpwm[1,2,3].

At present the cl-clx-sbcl uses a very old Debian standard since 2016
and has 2 bugs (#816749, #1013680) unanswered.  

I think you might be occupied and need help to get this package in
shape.  Shall we put it into group maintenance of the common lisp
team?  I tracked my efforts to bump it by creating a new repository
under the common lisp team at salsa and drafted a merge request[4].

Looking forward to your messages.

Cheers,
Benda

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-18-amd64 (SMP w/256 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE, TAINT_SOFTLOCKUP
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to C.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages cl-clx-sbcl depends on:
ii  cl-asdf  2:3.3.6-1
ii  dpkg 1.21.9

Versions of packages cl-clx-sbcl recommends:
ii  sbcl  2:2.2.9-1

cl-clx-sbcl suggests no packages.

-- no debconf information

1. https://github.com/stumpwm/stumpwm/pull/625
2. https://github.com/stumpwm/stumpwm/issues/576#issuecomment-519038015
3. https://github.com/stumpwm/stumpwm/issues/903#issuecomment-869825931
4. https://salsa.debian.org/common-lisp-team/cl-clx-sbcl/-/merge_requests/1

Bug#1016722: cvmfs sponor

[Benda Xu]

Hi Stephan,

> that would be very useful to have indeed! I looked at this very
> briefly and figured it is probably not trivial to package, so good
> luck.  Let me know if you need a sponsor or any other help for this.

Thank you so much for offering help.  I have been working with Yachen in
the past 2 months.  Now the package is in shape with only few minor
update before uploading to the NEW queue.

  https://salsa.debian.org/hpc-team/cvmfs

It would be great if you could have a review of the draft package.

Cheers,
Benda

Bug#1003677: reproduced

[Benda Xu]

Thanks Vasilis, I could reproduce this error.  The fix will come
together with the new version.

Yours,
Benda

Bug#990201: extra vendor/ directory

[Benda Xu]

Hi Andreas,

Many thanks for taking care of the 3.9 series!


I am confused of the 'vendor/' directory in tag 'upstream/3.9.5+ds1'.

The upstream release at

  https://github.com/sylabs/singularity/releases/tag/v3.9.5

does not have the directory anymore. Neither does the git repo

  https://github.com/sylabs/singularity


What mechanism are we using to re-vendor things into the +ds tarballs?

Cheers,
Benda

Bug#995171: 3.9.2 has new dependencies

[Benda Xu]

I looked upon singularity-3.9.2.  It has several dependencies that will
need coordinated updates of the go packages.

Benda

Bug#879872: inadyn 2.8.1-1 pending for review

[Benda Xu]

Tags: patch

A merge request has been created for review,

  https://salsa.debian.org/debian/inadyn/-/merge_requests/1

with which we will release 2.8.1-1 into sid.

Cheers,
Benda

Bug#994882: ITS: vitables

[Benda Xu]

Anton Gladky  writes:

> Thanks for your contribution. I have approved and merged your MR. Also
> I have added you to the Debian Science group on salsa.
>
> @PICCA Frederic-Emmanuel, would you want also to check those changes?

Thanks Anton!

I will wait for Picca's ack for a month before I go ahead to add myself
to uploaders list.

Yours,
Benda

Bug#994882: ITS: vitables

[Benda Xu]

Package: vitables
Version: 3.0.2-1
Severity: normal
X-Debbugs-Cc: Debian Science Maintainers 
, Dmitrijs Ledkovs 
, Picca Frédéric-Emmanuel 

Dear Maintainer,

I am interested in co-maintaining vitables by joining the science team
and appending myself as an uploader.

The newest version (3.0.0-1.1) was NMU-ed and has not been included in
the package Vcs for more than a year. Bug 966056 (a year old) prevents
the version in bullseye to function if python3-sip is not installed. I
think the current uploads need help.

I have contributed to the present 3.0.0-1 release in 2019 and I would
like to support packaging vitables in the long run, as I am an active
user of it and giving my lectures with it.

The diff is in the merge request:

  https://salsa.debian.org/science-team/vitables/-/merge_requests/4

Thanks for your consideration!
Benda

-- System Information:
Debian Release: bullseye/sid
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-5-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: OpenRC (via /run/openrc), PID 1: init

Versions of packages vitables depends on:
ii  python3  3.9.2-2
ii  python3-numexpr  2.7.2-2
ii  python3-numpy1:1.19.5-1
ii  python3-qtpy 1.9.0-3
ii  python3-tables   3.6.1-3

vitables recommends no packages.

vitables suggests no packages.

-- no debconf information

Bug#971713: NMU in delayed/5

[Benda Xu]

Hi Matthew,

Matthew Vernon  writes:

> I've taken Trek's patches and incorporated them into an NMU which I've
> pushed to delayed/5.
>
> We may still want to get the new version into bullseye once Jesse
> publishes it, but at least this way the fix for this bug will be in.
>
> I hope that's OK!

Thank you so much for taking care of it.  Hope it will get through soon.

Yours,
Benda

Bug#879872: adopting inadyn

[Benda Xu]

Hi Federico,

I have found that you are working on packaging inadyn-2.5[1] just after
I filed ITA to this bug.  Are you still interested in adopting it?
Maybe we can work together.

Cheers,
Benda

1. https://salsa.debian.org/debian/inadyn

Bug#981113: ITP: root -- open-source data analysis framework

[Benda Xu]

Steffen Möller  writes:

> cern-root ?

+1


FYI, the following is the previous CERN ROOT changelog.  The old name
was root and changed to root-system since 5.15.07-1.

  
http://metadata.ftp-master.debian.org/changelogs/main/r/root-system/unstable_changelog

Benda

Bug#951229: babeld: Please make another source-only upload to allow testing migration

[Benda Xu]

Hi Stéphane,

Stéphane Glondu  writes:

> Le 12/02/2020 à 21:34, Boyuan Yang a écrit :
>> I noticed that the latest upload of package babeld was not a source-only
>> upload. As a result, this upload will not migrate to testing. Please consider
>> making another source-only upload. You may find more information about 
>> source-
>> only upload at https://wiki.debian.org/SourceOnlyUpload .
>
> Isn't a binNMU sufficient? I've scheduled one.
>
>> BTW: Please also consider pushing the missing source code of the new version
>> onto Salsa packaging repo.
>
> Benda, you did the last upload. Could you push your changes to salsa ?

Thanks, I have pushed my changes to salsa.  Sorry I did not notice
Ondřej's change.  The conflicts in the changelog were handled by an
explicit merge.

Cheers,
Benda

Bug#923387: udisks2: Please support new logind virtual packages

[Benda Xu]

Hi Michael,

What is the status of this bug?


elogin now provides sd_uid_is_on_seat:

$ nm -D /lib/elogind/libelogind-shared-241.3.so | grep sd_uid_is_on_seat
  
000b5b90 T sd_uid_is_on_seat


Please express your concern.

Yours,
Benda

Bug#950235: marked as done (cl-asdf build fails on sbcl-2.0.1)

[Benda Xu]

Thank you, Sébastien!

Benda


signature.asc
Description: PGP signature

Bug#950235: cl-asdf build fails on sbcl-2.0.1

[Benda Xu]

Package: cl-asdf
Version: 2:3.3.3-3
Severity: important

Dear Common Lisp Team,

asdf stops working after the sbcl upgrade:

$ sbcl --eval '(require "asdf")' --eval '(asdf:load-system :asdf)'

This is SBCL 2.0.1.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
; compiling file "/usr/share/common-lisp/source/cl-asdf/build/asdf.lisp" 
(written 12 OCT 2019 06:53:15 AM):  
  
;
; caught WARNING:
;   :SB-EVAL is no longer present in *FEATURES*


; wrote 
/home/heroxbd/.cache/common-lisp/sbcl-2.0.1.debian-linux-x64/usr/share/common-lisp/source/cl-asdf/build/asdf-tmpGHU3ALSV.fasl
  
; compilation finished in 0:00:03.907

debugger invoked on a UIOP/LISP-BUILD:COMPILE-FILE-ERROR in thread
#:
  COMPILE-FILE-ERROR while compiling #

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [RETRY] Retry
 compiling #.
  1: [ACCEPT   ] Continue, treating
 compiling #
 as having been successful.
  2: Retry ASDF operation.
  3: [CLEAR-CONFIGURATION-AND-RETRY] Retry ASDF operation after resetting the
 configuration.
  4: [CONTINUE ] Ignore runtime option --eval 
"(asdf:load-system :asdf)".
  5: [ABORT] Skip rest of --eval and --load options.
  6: Skip to toplevel READ/EVAL/PRINT loop.
  7: [EXIT ] Exit SBCL (calling #'EXIT, killing the 
process).

(UIOP/LISP-BUILD:CHECK-LISP-COMPILE-RESULTS NIL T T 
"~/asdf-action::format-action/" ((# . 
#))) 
   
   source: (ERROR 'COMPILE-FILE-ERROR :CONTEXT-FORMAT CONTEXT-FORMAT
  :CONTEXT-ARGUMENTS CONTEXT-ARGUMENTS)
0]


But with sbcl 1, it works:

$ sbcl --eval '(require "asdf")' --eval '(asdf:load-system :asdf)'
This is SBCL 1.4.16.debian, an implementation of ANSI Common Lisp.
More information about SBCL is available at .

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* 

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-6-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

cl-asdf depends on no packages.

Versions of packages cl-asdf recommends:
ii  sbcl [lisp-compiler]  2:2.0.1-1

Versions of packages cl-asdf suggests:
ii  cl-launch  4.1.4-1

-- no debconf information

Bug#946197: Let's switch to OpenRC?

[Benda Xu]

Hi Thomas,

Thomas Goirand  writes:

>> The last time I looked (years ago), there were features in sysvinit
>> which weren't in OpenRC (yet). IIRC not having concurrent execution of
>> boot scripts was one of the missing features and the reason for e.g.
>> our derivative distribution GRML to not switch to OpenRC some years
>> ago.
>
> OpenRC does have parallel execution of scripts, it works well, but when
> activated, the display output is still a bit ugly. I'm not sure why (I
> haven't investigated). If the issue is just the screen output, then
> probably it can be worked on.

The ugly output is caused by
/lib/lsb/init-functions.d/20-left-info-blocks from lsb-base.

Thomas Goirand  writes:

> Benda Xu  wrote:
>> I think it would be time when OpenRC has a systemd .ini parser, to
>> also make use of systemd units.
>
> Do you think this could be written?

I think so.  It's on my agenda.  Anyone is welcomed is she wants to
join.

Yours,
Benda

Bug#946197: Let's switch to OpenRC?

[Benda Xu]

Hi Thomas,

Thomas Goirand  writes:

> OpenRC is actively maintained upstream, and is a full replacement of
> sysv-rc, including many improvements.
>
> Currently, packages are stuck with long, non-declarative sysv-rc
> scripts, and cannot switch to superior runscripts, interpreted by
> /sbin/openrc-run, which enable declarative-only scripts.
>
> So, my proposal is to get rid of sysv-rc provided by sysvinit, in the
> favor of OpenRC, so that developers can start replacing their init
> scripts by superior runscripts.
>
> Note that this doesn't mean we completely get rid of the sysvinit
> source package, as we still need a large chunk of it, like for example
> the PID 1 in OpenRC can continue to be sysvinit. We also probably need
> other components, like for example bootlogd, sysvinit-utils, and maybe
> others.
>
> I'm opening this discussion in the BTS, as I would like to see what
> the opinion of sysvinit maintainers is.
>
> I'm also unsure what would be technically needed to get sysv-rc
> automatically be replaced by OpenRC. Maybe we could make sysv-rc
> become a metapackage that depends on OpenRC?

I think it would be time when OpenRC has a systemd .ini parser, to also
make use of systemd units.

Yours,
Benda

Bug#875250: Intend to port to Qt 5

[Benda Xu]

Hi Moritz,

I started to work on qt5 port of SCIM.  There is some remaining blocks.
I will work on it for another 10 days.

I want to postpone to deadline to Dec 15, if that does not drag the QT5
migration too much.

Thank you for your understanding!

Yours,
Benda

Bug#875250: Intend to port to Qt 5

[Benda Xu]

Hi Moritz,

I am listed as a uploader on src:scim.

I am going to try to port scim to Qt 5 before removing scim-qt-immodule.
Please give me 10 days.  If until Dec 1 I cannot port scim qt5, I will
do the upload authored by https://github.com/leggewie-DM/scim/pull/1.

Thanks!
Benda

Bug#922358: override: vitables:science/optional

[Benda Xu]

Package: ftp.debian.org
Severity: normal
Control: block 820390 by -1

Dear FTP masters,

As per Bug #820390, we would like to override vitables to the science
section, because vitables is a python application for scientists.  In
addition, by Debian standards update, we would like to set it to
priority optional.

Thanks!
Benda

Bug#918746: pam-ssh-agent-auth alternative

[Benda Xu]

Bálint Réczey  writes:

> I picked the patch used in Gentoo and FreeBSD to make the package
> build again, but it does not resurrect upstream.
>
> I'd say with this change there is no immediate need for removal, but I
> removed myself from uploaders since I did not have enough time to take
> care of the package properly and let the final word on removal for the
> Security Team.

Thank you Bálint!  You have done a great job keep it in shape.

Yours,
Benda

Bug#918746: pam-ssh-agent-auth alternative

[Benda Xu]

Hi Moritz,

That needs to be seriously considered.  I am using this package
extensively.  Do you any alternatives to it?

Yours,
Benda

Bug#746221: initscripts: Debian should have an init script for saving/restoring backlight level on laptops

[Benda Xu]

Hi Dmitry,

Dmitry Bogatov  writes:

> Dear co-maintainers, what do you think? While personally I never used
> this feature, I believe it would not introduce much of complexity into
> initscripts. Neither I believe this functionality deserves separate
> binary package. So, objections to inclusion?

Recently I have been tuning the backlight of my laptop manually.

We have, for example `xbacklight` in the repository that needs to be
updated to support newer laptop models.

Benda

Bug#826214: Please would 40-systemd honour __init_d_script_name

[Benda Xu]

Ian Jackson  writes:

> I think reimplementing init-d-script in C is the wrong solution to
> this bug.  Certainly, if the only thing it is buying is us an ability
> to manipulate $0.  I infer from Dmitry's closing of #913247 which
> requests init-d-script in C, that he also doesn't like that idea.
>
> So I think both Dmitry and I are in agreement that the right solution
> here is the first of Dmitry's two bullet points above.  Ie, the
> sysvinit maintainers are of the opinion that this should be fixed by
> amending 40-systemd, which is part of the systemd package.
>
> I'm therefore reassigning this bug.  Benda, if you disagree; or,
> Dmitry, if I have misunderstood your view: please do say.

I agree with Ian and Dmitry, and have no objections to this decision.

Thank you to all the parties coming together to fix this.

Yours,
Benda

Bug#823660: initscripts: Restore locked root account access by using sulogin --force

[Benda Xu]

Hi Andreas,

Andreas Henriksson  writes:

> On Thu, Nov 15, 2018 at 05:47:03PM +0800, Benda Xu wrote:
> [...]
>> I think it a common Debian practice to set root passwords.  Disabling
>> root login and put everything on `sudo` feels very Ubuntu. 
>
> The debian-installer supports both things out of the box equally.
> (Although very few people seem to pay any attention to the root
> password prompt and thus it's quite common people don't know this.)
> Ubuntu only does locked-root-account, and I think there are well
> established reasons to do so and wish it would be more obvious to
> Debian users how d-i works. I don't really see the point in comparing
> to others though. Debian should do what's best for Debian.
>
>> Therefore I think you are right saying "it was 'closed' by moving to
>> util-linux sulogin".
> [...]
>
> I'm personally absolutely not an advocate of passwordless root shells,
> but in my view for sysvinit it's very important to not break legacy
> setups. Specially when most users will not realize until they're
> doing disaster recovery and will get a not obvious situation that's
> just a dead end for them.
>
> If you think breaking this decades worth of how it has worked is ok,
> then I guess that's up to you.
> I personally mostly want to avoid being blamed for having broken it
> myself, through the move to util-linux sulogin. I've offered my
> assistance in getting it fixed, but if you opt out then I'm ok
> with your decision.
> OTOH this absolutely doesn't make sysvinit secure to use in a kiosk
> setup, so I don't see anything won by breaking the old setup.

Thank you for your patience and nice explanation.  I do not think we
should impose surprises to the long-term Debian users.

Therefore, I reserve my view and don't object to adding `--force` to
`sulogin`.  I will chop that option off my setup locally instead.

Cheers,
Benda

Bug#825975: Invitation to sysvinit maintenance

[Benda Xu]

Benda Xu  writes:

> I have reformed the sysvinit maintenance team and mailing list (in the
> Cc).
s/I/we/

A bad typo.  I am terribly sorry to our colleagues.
Benda

Bug#799329: sysvinit: does not work inside systemd-nspawn

[Benda Xu]

Control: tags -1 + fixed

Thanks Andreas,

Andreas Henriksson  writes:

> Control: tags -1 + patch
>
> Hello again,
>
> Trivial patch attached for below suggestion for your convenience.
>
> (Making it convenient to test will have to be implemented in a higher
> level tool that enables the provided example.)
>
> On Thu, Nov 15, 2018 at 01:20:02PM +0100, Andreas Henriksson wrote:
>> I'd say it's probably overkill. I'm thinking similar to this
>> would be enough:
>> 
>> https://salsa.debian.org/debian/sysvinit/commit/321e38634d9a11a1c2fb72b924a6ef513431654a
>> 
>> (OTOH, /etc isn't really the place to provide examples but oh well...)
>  
> Regards,
> Andreas Henriksson
>
> PS. inittab uses undocumented legacy syntax for getty in
> other/preexisting places in inittab and should be updated to use
> documented syntax (because who knows when the undocumented syntax stops
> working). Someone should file this as a separate issue.

Patch applied (commit 19a732b6ba475e).  And yes, the present handling of
/etc/inittab is suboptimal.

Yours,
Benda

Bug#825975: Invitation to sysvinit maintenance

[Benda Xu]

Hi Samuel,

Sorry for this long delay into incorporate your patch.  I have reformed
the sysvinit maintenance team and mailing list (in the Cc).  Please
consider this email an invitation to join the sysvinit team for
the GNU/Hurd port.

Thanks for your patience!
Benda

Bug#718416: closed by Dmitry Bogatov ()

[Benda Xu]

Thorsten Glaser  writes:

> I find it unsatisfactory and did not find much consensus.

Sorry Thorsten for this confusion and inconvenience.  As you said, it is
a matter of 

  sed -i 's|1:2345:respawn:/sbin/getty|1:2345:respawn:/sbin/getty --noclear|' 
/etc/inittab

I guess it is not too annoying apply this to your machines.

Yours,
Benda

Bug#823660: initscripts: Restore locked root account access by using sulogin --force

[Benda Xu]

Greetings Mr. Andreas Henriksson,

Andreas Henriksson  writes:

> I'll comment in more detail below, but in general I have to start out by
> saying I think you've misunderstood this gravely. You should probably
> try to clear your mind and start over on trying to understand this.

Thanks.

> [...]

snip

> On Thu, Nov 15, 2018 at 12:13:26PM +0800, Benda Xu wrote:
>> Hi Andreas,
>> 
>> Dmitry Bogatov  writes:
>> 
>> > [2016-05-07 11:12] Andreas Henriksson 
>> >> [...]
>> >> The initscripts package (src:sysvinit) needs equivalent changes to
>> >> restore the old status quo (and thus ignoring potential kiosk mode usecase
>> >> problems -- kiosk mode users should alter their init scripts and remove
>> >> the --force flag to be secure).
>> >
>> > Sounds convincing to me. So I prepared commit wip/bug-823660.  Dear
>> > co-maintainers, any objections?
>> 
>> 
>> @Andreas, what do you mean by "kiosk mode"?  Could you please define it
>> precisely?
>
> I think others will explain it better than I can, so I'll just refer
> to first and second hit I get on google for kiosk mode:
>
> https://www.kioware.com/resources.aspx?resid=45
>
> https://en.wikipedia.org/wiki/Kiosk_software

I see. It is a common concept I am not aware of.  Now I understand what
you mean.  Much appreciated.

>> I don't think sysvinit should blindly follow behaviors of systemd.
>
> This has absolutely nothing to do with systemd. This is about sulogin
> move from (debian patched version of) sysvinit sulogin to debian using
> sulogin from util-linux.

Okay, let's forget about systemd.  That's generally a good idea to use
util-linux version of sulogin to align the behavior with upstream.
Debian-specific hacks should either accepted upstream or ultimately
abandoned.

>> Entering the system as root without password prompt is a severe security
>> hole.
>
> A "severe security hole" that's been present in sysvinit sulogin for
> decades (in debian atleast, IIRC upstream is not to blame for it).
> It was "closed" by moving to util-linux sulogin, but that also left
> those who have a locked root account (using sudo) being unable to login
> via sulogin.

I think it a common Debian practice to set root passwords.  Disabling
root login and put everything on `sudo` feels very Ubuntu.  Therefore I
think you are right saying "it was 'closed' by moving to util-linux
sulogin".

> This bug report is limited in scope to just restoring the old status quo
> by adding a flag when sysvinit invokes sulogin to get behaviour similar
> to the old sysvinit sulogin version. (You're welcome that I helped out
> with shephearding the needed util-linux changes upstream for your
> convenience.)

Good job for bringing it upstream.  Thank you.

> Implementing flexibility in sysvinit to be able to accomodate for both
> use-cases is left as an excersise to the reader. 

We already have that flexibility: if your system is absolutely
physically safe, add --force to `sulogin` in the sysvinit configuration
files. If not, leave it alone.

I might be wrong and I am all ears to counter arguments.  But the
"Debian previous status quo", "Many users do not set root passwords" and
"systemd has put sulogin --force everywhere" did not convince me. I am
sorry.

> I'm not interested in sysvinit feature development myself. I'm only
> interested in trying to avoid it deteriorating too much.

You are being very nice and considerative, Mr. Henriksson.  We all have
more to worry in daily lives.  I will not waste your precious
intellectual power anymore, and will keep the discussion within the
interested party.

> [... rest of message snipped as is seems to go further into
> misunderstanding land ...]

Thanks again for baring with my grave misunderstanding and good luck!
Benda

Bug#686895: initscripts: /forcefsck: fsck -f undefined (e2fsck-ism)

[Benda Xu]

Hi Dmitry,

Dmitry Bogatov  writes:

> control: tags -1 +patch
>
> [2014-11-24 22:30] Petter Reinholdtsen 
>> Given that -f is force only for ext*, I suspect a more sensible
>> approach is to only enable forcefsck for ext*, not disable it for
>> btrfs.
>
> Like this?
>
> diff --git a/debian/src/initscripts/etc/init.d/checkroot.sh 
> b/debian/src/initscripts/etc/init.d/checkroot.sh
> index 9f70527a..c6c21344 100755
> --- a/debian/src/initscripts/etc/init.d/checkroot.sh
> +++ b/debian/src/initscripts/etc/init.d/checkroot.sh
> @@ -22,6 +22,18 @@ FSCK_LOGFILE=/var/log/fsck/checkroot
>  . /lib/lsb/init-functions
>  . /lib/init/mount-functions.sh
>  
> +_want_force_fsck () {
> + set -- $(findmnt / | tail -n1)
> + case "$3" in
> + # Only ext* file systems support `-f' option to fsck. See #686895
> + (ext*)
> + [ -f /forcefsck ] || grep -q -s -w -i "forcefsck" /proc/cmdline
> + ;;
> + (*)
> + return 1

Do we need ';;' after this line?  Otherwise looks good to me.

> + esac
> +}
> +

Yours,
Benda

Bug#823660: initscripts: Restore locked root account access by using sulogin --force

[Benda Xu]

Hi Andreas,

Dmitry Bogatov  writes:

> [2016-05-07 11:12] Andreas Henriksson 
>> [...]
>> The initscripts package (src:sysvinit) needs equivalent changes to
>> restore the old status quo (and thus ignoring potential kiosk mode usecase
>> problems -- kiosk mode users should alter their init scripts and remove
>> the --force flag to be secure).
>
> Sounds convincing to me. So I prepared commit wip/bug-823660.  Dear
> co-maintainers, any objections?


@Andreas, what do you mean by "kiosk mode"?  Could you please define it
precisely?

I don't think sysvinit should blindly follow behaviors of systemd.
Entering the system as root without password prompt is a severe security
hole.

You may argue that if a cracker gets physical access to the machine, the
system is actually compromised.  Well, a cracker, sometimes a thief,
usually has a limited time penetrating a computer physically, while a
system administrator has virtually infinite amount of time.  Therefore,
the ease of not entering root password for sysadmin, does not shift the
risk that the system gets compromised quickly.

> Andreas Henriksson 
>
> The systemd package has been updated to pass the --force flag.

As the sulogin(8) says,

> Only use the -e option if you are sure the console is physically
> protected against unauthorized access.

Systemd imposes a big security risk to all the ignorant users without
telling them they need to make sure their console is physically
protected against unauthorized access, which is a harmful move we should
not follow.

Yours,
Benda

Bug#822753: /lib/init/init-d-script: exit 0 at end of script prevents all other exit codes

[Benda Xu]

Hi Petter,

Dmitry Bogatov  writes:

> I do agree, that this line looks strange. It was introduced at commit
> `f611a05d16b3094139c2ea540817c00bdf93347a' with following comment:
>
>   Make sure init-d-script exit at the end, to make sure init.d
>   script is only sourced once.
>
> at 20 Feb 2014. Dear co-maintainers, do you understand (or remember),
> what is going on?

Do you think init-d-script unconditionally returning 0 is a typo?
Should it be `exit $?` instead?

Yours,
Benda

Bug#374039: shutdown behavior (Was: Addressing more sysvinit bugs)

[Benda Xu]

Hi Jesse,

Jesse Smith  writes:

> 374039 (I think the reporter is confusing initscripts (init.d) with the
> sysvinit programs as they're mixing up script variables with sysvinit
> manual pages. Can close this report.)

Jidanni's concern is in the shutdown(8) manpage.

1. `shutdown` is no longer a script. The manpage should reflect that.

2. INIT_HALT is handled in /etc/init.d/halt, not /sbin/halt.

3. use `shutdown -h -H` with caution.  I don't have a clue.

4. It is not interesting to mention "Debian Sarge" in manpage anymore.


It would be great if they could be addressed upstream.

Yours,
Benda

Bug#598891: Addressing more sysvinit bugs

[Benda Xu]

Tags: fixed-upstream

Thanks Jesse!

Jesse Smith  writes:

> 598891 (Accepted suggestion to make shutdown command quiet. Applied
> upstream. Can close bug report.)

Bug#512821: wontfix?

[Benda Xu]

Hi Dmitry,

I think you will be the one to judge and close this bug :)

Yours,
Benda

Bug#372668: Addressing more sysvinit bugs

[Benda Xu]

Tags: fixed-upstream

Hi Jesse,

Jesse Smith  writes:

> 372668 (The suggested documentation changes have been made upstream. Can
> close bug.)

Thank you!  We will close this when sysvinit-2.92 hits Debian.

Yours,
Benda

Bug#630661: fixed upstream

[Benda Xu]

Tags: fixed-upstream

Thanks Jesse!

Yours,
Benda

Bug#846590: dolphin interaction with udisks2 for permissions

[Benda Xu]

reassign 846590 dolphin
thanks

Hi Maximiliano,

It looks like dolphin does not work happily when udisks2 is running on a
sysvinit-powered box.

Yours,
Benda

Bug#710747: tftpd cannot bind to 0.0.0.0

[Benda Xu]

forwarded 706676 https://bugzilla.syslinux.org/show_bug.cgi?id=6
reassign 706676 tftpd-hpa
tags -1 upstream
thanks

Hi Ron,

According to the discussion above, this seems to be a bug of tftpd-hpa.

Thanks,
Benda

Bug#706676: to be closed by the LXC team

[Benda Xu]

reassign 706676 lxc
thanks

Dear LXC Maintainers,

I think this bug has been addressed as I can't reproduce it anymore with
my stretch as host and sid as lxc guest.

That said, I regard it is more proper for you guys to judge and close
it.

Thanks,
Benda

Bug#361935: Some progress on Debian bugs

[Benda Xu]

Hi Jesse,

Jesse Smith  writes:

> 361935 (addressed in documentation)

Could you please show which documentation has addressed this bug?

Yours,
Benda

Bug#890041: fixed upstream in 2.89 and will appear in debian 2.91-1

[Benda Xu]

tags 890041 fixed
thanks

Thank you all!  This is fixed upstream in 2.89 and will appear in debian
2.91-1 and later.

Yours,
Benda

Bug#614893: Some progress on Debian bugs

[Benda Xu]

Hi Jesse,

Jesse Smith  writes:

> 614893 (fixed)

Could you please elaborate about how this bug is fixed?  I can't find
relevant commits in the upstream repository.

Yours,
Benda

Bug#375274: tag upstream

[Benda Xu]

tags 375274 upstream
thanks

Thank you Jesse, I understand the meaning of '-t' now.

Yours,
Benda

Bug#580773: [Pkg-sysvinit-devel] Bug#580773: Fixed

[Benda Xu]

Control: tags 580773 upstream

Jesse Smith  writes:

> Updated insserv to handle both --dryrun and --dry-run. Can also use
> either --show-all or --showall. Updated manual pages to match upstream.
>
> This change will appear in insserv 1.18.0.

Thank you Jesse!

Bug#910444: OpenRC called by update-rc.d should read defaults from headers

[Benda Xu]

Hi Adam,

Adam Borowski  writes:

> But something is amiss: that refactorization happened a year ago, yet there
> was no breakage I nor anyone else noticed.  And I obviously installed quite
> a few daemons in the meantime on systems running unstable (although I don't
> recall any on unstable in last 1-2 months).  Yet on current unstable
> installing new init scripts with openrc is broken (tested with 0.38 and
> 0.34.something) -- if it could have worked before, what did change?
> I'm pretty confused...

The update-rc.d calling of OpenRC is designed to be like this: insserv
makes new symlinks in /etc/rc?.d/, and then OpenRC interprets the
symlinks to populate the state to its own /etc/runlevels.

However, after the refactorization, OpenRC runs before insserv.  With a
refresh new installation of /initscripts/, OpenRC finds nothing in
/etc/rc?.d and it does nothing.  Only after that insserv installs
symlinks there.  At this stage, OpenRC knows nothing of /initscripts/.

But, the next time if some other daemon is installed, OpenRC is called
again by update-rc.d and it finds the left overs of /initscripts/
symlinks and synchroizes them.  Bug disappears!

That's why this bug is so hard to discover.  Many thanks to Axel!

Cheers,
Benda

Bug#910444: OpenRC called by update-rc.d should read defaults from headers

[Benda Xu]

Control: reassign 910444 init-system-helpers
Control: forwarded 910444 
https://salsa.debian.org/debian/init-system-helpers/merge_requests/6
Control: tags 910444 patch

Hi,

With the input and help from biebl, I was able to chase down this bug to
update-rc.d.  After refactorization by fsateler, the execution order was
changed and the previous assumption does not hold anymore.

Please find the pull request at
https://salsa.debian.org/debian/init-system-helpers/merge_requests/6

Cheers,
Benda

Bug#910444: necessary services are deleted from initscript

[Benda Xu]

Hi Axel,

While I haven't tried to reproduce the bug with Sid yet, Bug 874685
looks extremely suspicious for causing this.

Yours,
Benda

Bug#856044: Not reproduced as of 2018, may be obsolete

[Benda Xu]

Hi Michael,

Michael Biebl  writes:

> Well, "-n" was indeed broken and has been removed completely
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856415
>
> Which indeed makes this bug report obsolete.

I see. Thank you for responding this issue.

> Benda, please always CC the maintainers of the package you are
> reassigning a bug report to. I usually use $p...@packages.debian.org

Will do next time.  Thanks!

Yours,
Benda


signature.asc
Description: PGP signature

Bug#856044: Not reproduced as of 2018, may be obsolete

[Benda Xu]

Tags: unreproducible
Control: reassign 856044 init-system-helpers

Hi Stefano,

`update-rc.d` has been moved to init-system-helpers package.  Are you
still experiencing this bug?  I can't reproduce it.

Yours,
Benda

Bug#910444: Filesystems listed in /etc/fstab are no more automatically mounted since switching to OpenRC

[Benda Xu]

Hi Axel,

Axel Beckert  writes:

>> Thank you for raising this up.  Are you using openrc with sysvinit-core?
>
> Yes. Since the package "init" doesn't allow openrc as option,
> sysvinit-core is installed, too. I though don't know the difference
> between those two modes (OpenRC with and without sysvinit-core).

That's the expected setup.  No problem.  In short, there is no
difference for OpenRC with and without sysvinit-core.  At present in
Debian, sysvinit-core is the most viable option.

Traditionally, OpenRC is only a service manager, which need to be
started by some pid 1 process, like sysvinit.

Cheers,
Benda

Bug#910444: Filesystems listed in /etc/fstab are no more automatically mounted since switching to OpenRC

[Benda Xu]

Hi Axel,

Adam Borowski  writes:

> On Sat, Oct 06, 2018 at 02:40:22PM +0200, Axel Beckert wrote:
>> Package: openrc
>> Version: 0.34-3
>> Severity: grave
>> Justification: renders package unusable
>
>> I just installed Debian Buster/Sid from scratch on a GPD Pocket 1 and
>> then switched from systemd to OpenRC.

Thank you for raising this up.  Are you using openrc with sysvinit-core?

>> Since then, /home (on LVM on LUKS), /boot and /boot/efi (i.e. anything
>> from /etc/fstab except the root file system) are no more mounted
>> automatically despite they're listed in /etc/fstab and "mount -a"
>> mounts them without issues.
>
> It works for continously upgraded systems.  I can't check a fresh one anytime
> soon (explanation below), but it appears that installing a new daemon[1]
> doesn't properly register it for requested runlevels (you can still run
> update-rc.d to fix that).  Not sure if this is the cause, would need to look
> more.  Too bad, init-system-helpers didn't have an update in almost two
> months so the culprit might be something else.
>
> Benda: could you please take a look?  The package being unusable on new
> systems sounds pretty urgent...

@Adam, acknowledged.  I do need to look more closely into OpenRC, to get
it well prepared for buster.

>> Swap hasn't been activated by "mount -a", though. (Probably expected,
>> just wanted to mention it.)
>
> Sounds consistent with init scripts not having been registered.

@Axel, what is the output of `rc-update` of the said system?
/etc/init.d/mountall.sh from initscripts is called by OpenRC by default
to handle /etc/fstab.

Confirmation check: if you execute `invoke-rc.d mountall.sh start`
instead of `mount -a`, does it work as well?

Yours,
Benda

Bug#864827: Please go ahead adding explanations to the wiki

[Benda Xu]

Hi Stefan,

> This bug basically makes the package unusable.  

Unfortunately that's true.

> I understand that adapting the packaging to the new structure of
> Zotero-5 will take some time, but in the mean time, could someone add
> a page to the Debian wiki outlining how to install Zotero-5 by hand on
> a Debian system

You are more than welcomed to do so.  Everyone can contribute to the
Debian wiki.

Yours,
Benda

Bug#898586: Babeld 1.8.1 is buggy, please upgrade to 1.8.2

[Benda Xu]

Hi Juliusz and Stéphane,

Stéphane Glondu  writes:

> On 14/05/2018 00:46, Juliusz Chroboczek wrote:
>> Babeld-1.8.1 has a rather serious bug, that makes it unsuitable for
>> traditional IPv4 networks (as opposed to pure meshes).  1.8.2 fixes the
>> bug.
>> 
>>   
>> https://github.com/jech/babeld/commit/157e44a4a507786f5626070d9b1f3e371389
>> 
>> Please upgrade to 1.8.2.
>
> I can't sign Debian stuff before the next keyring update (I've created a
> new subkey last week). Benda, can you take care of that?

Thanks for kindly sending this reminder.

I have just uploaded 1.8.2-1.

But I have forgot the mention this bug number in the changelog.  Closing
this bug manually.

Cheers,
Benda

Bug#886911: RFC: stumpwm bump to 1.0.0

[Benda Xu]

Hi Common Lisp Team,

I have prepared a version bump for stumpwm at

  https://github.com/heroxbd/stumpwm

because my membership with https://salsa.debian.org/common-lisp-team is
pending and I cannot commit to

  https://salsa.debian.org/common-lisp-team/stumpwm

Would you please kindly help review the commits I have made and sponsor
an upload of stumpwm-2:1.0.0-1?

Cheers,
Benda

Bug#891400: tinc: Incorrect ICMPv6 Checksum

[Benda Xu]

Package: tinc
Version: 1.0.33-1
Severity: important

Dear Guus,

I have been using tinc since 2009 and it is great!

When PMTUDiscovery=yes and Mode=switch, and if ipv6 is used inside
tinc, the ICMPv6 "Packet Too Big" packets have incorrect checksums.
It can be reproduced by `ping6  -s 1800` and `tcpdump -i
`.  Consequently, the host ignores the tinc-generated
ICMPv6 packets, PMTUDiscovery does not work and the connections freeze
when data flows are big.

I find the bug is gone if the function "inet_checksum" in route.c is
not inlined, either by compiling tinc with "-O2
-fno-inline-functions", or apply a patch such as,

diff --git a/src/route.c b/src/route.c
index ff82c06e..cd55383a 100644
--- a/src/route.c
+++ b/src/route.c
@@ -60,7 +60,7 @@ static const size_t opt_size = sizeof(struct nd_opt_hdr);

 /* RFC 1071 */

-static uint16_t inet_checksum(void *data, int len, uint16_t prevsum) {
+__attribute__ ((noinline)) static uint16_t inet_checksum(void *data, int len, 
uint16_t prevsum) {
uint16_t *p = data;
uint32_t checksum = prevsum ^ 0x;



I have tested with gcc-7.3.0 and gcc-5.4.0.  They behaved the same.  I
am not good at assembly to find out what really happened, but it is
for sure that inet_checksum does not work as expected if compiled
inline.

Thanks!

Yours,
Benda

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tinc depends on:
ii  libc6  2.26-2
ii  liblzo2-2  2.08-1.2+b2
ii  libssl1.1  1.1.0g-2
ii  lsb-base   9.20170808
ii  zlib1g 1:1.2.8.dfsg-5

tinc recommends no packages.

tinc suggests no packages.

Bug#885537: nullmailer: /etc/init.d/nullmailer from version 1.3 works

[Benda Xu]

Hi David,

David Bremner <da...@tethera.net> writes:

> Well, you might be right, but that would mean we didn't need the patch
> made by the previous maintainer. How about logging? As far as I know
> nullmailer-send logs to stdout / stderr.

That's a good point.  nullmailer does not have logging builtin.  That
said, it is straight-forward to make use of the '--no-close' of
start-stop-daemon and process substitution of bash:

,
| start-stop-daemon --start --quiet --user mail --chuid mail --no-close \
| --pidfile $PIDFILE --make-pidfile --background \
| --oknodo --exec "$DAEMON" > >(logger -p mail.notice -t nullmailer) 2>&1
`

> Benda Xu <hero...@gentoo.org> writes:
> >
> > # ps ax | grep nullmailer
> > 24301 ?S  0:00 /usr/sbin/nullmailer-send -s
> >
> > # cat /var/run/nullmailer.pid 
> > 24301
> >
> >
> > I have also tested by sending an email from shell, and it also works.
> > And this message is sent by nullmailer 1:2.1-5.
> >

> Did you also test by sending mail with network disconnected and making
> sure the message is delivered after reconnection?

Yes, it works.  I have unpluged the network on Jan 12 18:18:56 and
pluged it back on 21:00:00.  Here is the mail.log by produced syslog:

,
| Jan 12 18:17:29 cerium nullmailer: Rescanning queue.
| Jan 12 18:18:03 cerium nullmailer: Trigger pulled.
| Jan 12 18:18:03 cerium nullmailer: Rescanning queue.
| Jan 12 18:18:03 cerium nullmailer: Starting delivery, 1 message(s) in queue.
| Jan 12 18:18:03 cerium nullmailer: Starting delivery: host: d.g.o protocol: 
smtp file: 1515748683.5573
| Jan 12 18:18:03 cerium nullmailer: From: <heroxbd@c.e.a.o> to: <heroxbd@g.c>
| Jan 12 18:18:03 cerium nullmailer: Message-Id: 
<1515748683.166936.5572.nullmailer@c.e.a.o>
| Jan 12 18:18:07 cerium nullmailer: smtp: Succeeded: 250 2.0.0 Ok: queued as 
D1D57335C4C
| Jan 12 18:18:07 cerium nullmailer: Sent file.
| Jan 12 18:18:07 cerium nullmailer: Delivery complete, 0 message(s) remain.
| Jan 12 18:18:56 cerium nullmailer: Trigger pulled.
| Jan 12 18:18:56 cerium nullmailer: Rescanning queue.
| Jan 12 18:18:56 cerium nullmailer: Starting delivery, 1 message(s) in queue.
| Jan 12 18:18:56 cerium nullmailer: Starting delivery: host: d.g.o protocol: 
smtp file: 1515748736.5685
| Jan 12 18:18:56 cerium nullmailer: From: <heroxbd@c.e.a.o> to: <heroxbd@g.c>
| Jan 12 18:18:56 cerium nullmailer: Message-Id: 
<1515748736.925284.5684.nullmailer@c.e.a.o>
| Jan 12 18:18:56 cerium nullmailer: smtp: Failed: Connect failed
| Jan 12 18:18:56 cerium nullmailer: Sending failed: Temporary error in 
gethostbyname
| Jan 12 18:18:56 cerium nullmailer: Delivery complete, 1 message(s) remain.
| Jan 12 18:19:56 cerium nullmailer: Rescanning queue.
| Jan 12 18:19:56 cerium nullmailer: Starting delivery, 1 message(s) in queue.
| Jan 12 18:19:56 cerium nullmailer: Starting delivery: host: d.g.o protocol: 
smtp file: 1515748736.5685
| Jan 12 18:19:56 cerium nullmailer: From: <heroxbd@c.e.a.o> to: <heroxbd@g.c>
| Jan 12 18:19:56 cerium nullmailer: Message-Id: 
<1515748736.925284.5684.nullmailer@c.e.a.o>
| Jan 12 18:19:57 cerium nullmailer: smtp: Failed: Connect failed
| Jan 12 18:19:57 cerium nullmailer: Sending failed: Temporary error in 
gethostbyname
| Jan 12 18:19:57 cerium nullmailer: Delivery complete, 1 message(s) remain.
| [...] 5 more "Failed: Connect failed" messages
| Jan 12 20:25:57 cerium nullmailer: Rescanning queue.
| Jan 12 20:25:57 cerium nullmailer: Starting delivery, 1 message(s) in queue.
| Jan 12 20:25:57 cerium nullmailer: Starting delivery: host: d.g.o protocol: 
smtp file: 1515748736.5685
| Jan 12 20:25:57 cerium nullmailer: From: <heroxbd@c.e.a.o> to: <heroxbd@g.c>
| Jan 12 20:25:57 cerium nullmailer: Message-Id: 
<1515748736.925284.5684.nullmailer@c.e.a.o>
| Jan 12 20:25:57 cerium nullmailer: smtp: Failed: Connect failed
| Jan 12 20:25:57 cerium nullmailer: Sending failed: Temporary error in 
gethostbyname
| Jan 12 20:25:57 cerium nullmailer: Delivery complete, 1 message(s) remain.
| Jan 12 22:33:57 cerium nullmailer: Rescanning queue.
| Jan 12 22:33:57 cerium nullmailer: Starting delivery, 1 message(s) in queue.
| Jan 12 22:33:57 cerium nullmailer: Starting delivery: host: d.g.o protocol: 
smtp file: 1515748736.5685
| Jan 12 22:33:57 cerium nullmailer: From: <heroxbd@c.e.a.o> to: <heroxbd@g.c>
| Jan 12 22:33:57 cerium nullmailer: Message-Id: 
<1515748736.925284.5684.nullmailer@c.e.a.o>
| Jan 12 22:34:03 cerium nullmailer: smtp: Succeeded: 250 2.0.0 Ok: queued as 
9720C335C46
| Jan 12 22:34:03 cerium nullmailer: Sent file.
| Jan 12 22:34:03 cerium nullmailer: Delivery complete, 0 message(s) remain.
`

Attached is the patch against /etc/init.d/nullmailer of
nullmailer_1.13-1.2.

Cheers,
Benda

--- nullmailer	2014-08-01 07:20:54.0 +0

Bug#885537: nullmailer: /etc/init.d/nullmailer from version 1.3 works

[Benda Xu]

Package: nullmailer
Version: 1:2.1-5
Followup-For: Bug #885537

Dear Maintainer,

I have extracted /etc/init.d/nullmailer from version 1:1.13-1.2, and
called:
# invoke-rc.d nullmailer start

It works:

# ps ax | grep nullmailer
24301 ?S  0:00 /usr/sbin/nullmailer-send -s

# cat /var/run/nullmailer.pid 
24301


I have also tested by sending an email from shell, and it also works.
And this message is sent by nullmailer 1:2.1-5.


In debian/changelog, I see no justification of this entry:

  * Drop support for sysvinit, due to dropping --daemon divergence from upstream

Because /etc/init.d/nullmailer does not rely on '--daemon' at all.  It
uses start-stop-daemon's '--background' and '--make-pidfile' to
daemonize nullmailer.


Could you please add back /etc/init.d/nullmailer and drop the
dependency on system-sysv?

Yours,
Benda


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nullmailer depends on:
ii  debconf [debconf-2.0]  1.5.65
ii  libc6  2.25-6
ii  libgnutls303.5.16-1
ii  libstdc++6 7.2.0-18
ii  lsb-base   9.20170808

Versions of packages nullmailer recommends:
ii  rsyslog [system-log-daemon]  8.31.0-2

nullmailer suggests no packages.

-- debconf information excluded

Bug#886911: stumpwm: new upstream release 1.0.0

[Benda Xu]

Package: stumpwm
Severity: normal

Dear Maintainer,

A new version of stumpwm 1.0.0 has been released

  https://github.com/stumpwm/stumpwm/releases/tag/1.0.0

Please consider bump the version in Debian.

I have tested with the 1.0.0 with some updates in debian/*. Would you
like to use them?

Yours,
Benda

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) (ignored: LC_ALL set to 
en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Bug#802919: version bump to unison-2.48.4

[Benda Xu]

Benda Xu <hero...@gentoo.org> writes:

> Thank you for your comments and diagnosis.  But the bug does not go away
> by itself.  If you are too busy to bump it, please speak out explicitly.
> We are willing to help maintaining unison.

Sorry I have overlooked the upload of unison-2.48.4 on 30 Oct 2017.  The
version 2.48.4 works well.  Thanks for your efforts, Stéphane.

Shall we close this bug?

Yours,
Benda

Bug#802919: version bump to unison-2.48.4

[Benda Xu]

severity 802919 important
thanks

Hello Stéphane (the *uploader* of unison),

Regarding this bug has actually rendered unison unusable without manual
compilation, and unison-2.48.4 has been released, could *you* please
bump unison to 2.48.4?  This will give us a rebuild of latest unison
against ocaml-4.05.

Thank you for your comments and diagnosis.  But the bug does not go away
by itself.  If you are too busy to bump it, please speak out explicitly.
We are willing to help maintaining unison.

Cheers,
Benda

Bug#884493: 1.8.0 packaged in git

[Benda Xu]

Hi,

It looks like this package has not been touch upon for almost 2 years.
I went ahead and committed version 1.8.0 to collab-maint/babeld.

  https://anonscm.debian.org/git/collab-maint/babeld.git

The compiled package works smoothly on jessie, stretch and sid.

Cheers,
Benda

Bug#883393: ITP: jool -- Open Source SIIT and NAT64 Translator for Linux

[Benda Xu]

Thanks Bjoern, I am building and using jool on Debian.  Your effort is
really appreciated.

Benda

Bug#651919: Any update on this bug?

[Benda Xu]

Hi,

What is the recommended way to use netns with ifupdown?

Benda

Bug#874790: /lib/rc/bin/lsb2rcconf: Boot dependency does not work for nfs-common

[Benda Xu]

Thanks Adam,

Adam Borowski <kilob...@angband.pl> writes:

> On Sun, Nov 19, 2017 at 10:46:12PM +0900, Benda Xu wrote:
>> Do you have a quick idea of parsing /etc/insserv.conf.d/* along with
>> /etc/insserv.conf in lsb2rcconf?
>
> I've looked at it before, but somehow I got distracted and didn't mark this
> on my TODO.  The way real insserv parses file names is _thoroughly_ insane:
> details are in this bug report (https://bugs.debian.org/874790).  Looking at
> all current users in Debian, I'd suggest filtering files in
> /etc/insserv.conf.d/* by /^[a-zA-Z0-9_-]+$/ rather than copying insserv
> exactly.  This should be safe enough for expected out-of-archive uses.
>
> Also, affected daemons look significant enough (rpcbind (NFS), postfix,
> mariadb, unbound, ...) that I believe this bug should be bumped to at least
> severity:important and fixed in stable.
>
> (Well, unbound works for me, but NFS is broken.)

I have read your dissection of insserv and I think /^[a-zA-Z0-9_-]+$/ is
a good choice.  It looks like the glibc regex_t is good to go,

  https://www.gnu.org/software/libc/manual/html_node/Regular-Expressions.html

Just want to see what Demitry thinks and if he would like to integrate
it into lsb2rcconf.

Cheeers,
Benda

Bug#874790: /lib/rc/bin/lsb2rcconf: Boot dependency does not work for nfs-common

[Benda Xu]

Hi Demitry,

Do you have a quick idea of parsing /etc/insserv.conf.d/* along with
/etc/insserv.conf in lsb2rcconf?

Yours,
Benda

Bug#871502: Clarification of Situation

[Benda Xu]

Hi Emmanuel,

> * The possibility of synchronizing 4.x with the Zotero site (an
>   important feature for collaboration) will be terminated in a few
>   months.

Is it possible to support zotero 4.x synchronization until End-of-life
of firefox 52 ESR (till June 26, 2018)?

Benda

Bug#811377: Bug#851747: sysvinit-utils: unmaintained package should not be Essential

[Benda Xu]

Hi Ian,

Thank you for the follow up.

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> I see that we have offers of help from various people in #811377.
>
> I have also added Benda Xu, based on
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811377#25
> I see that Benda doesn't seem to be a DD.  Needless to say I am happy
> to sponsor uploads and/or review and push git branches.

Yeah, that work for me.  I am a DM seeking to be a DD.

Fingerprint: C3A504840B678260DA12766AD25D611C8E192076
Uid: Benda Xu <h@g.o>

> With sysvinit being maintained in collab-maint, I think Benda won't be
> able to push to it directly. Benda, I suggest that if you want to
> contribute you make a git branch in a tree of your own on alioth, and
> use git-request-pull.

I have a guest account on alioth and I am on the list of collaborative
maintainers:

  https://alioth.debian.org/projects/collab-maint

No problem pushing to the sysvinit git repo.

> Benda, and Simon, are you subscribed to pkg-sysvinit-devel ?

Yes, I am in the list.

> We should have a conversation on the devel list about what changes we
> want to see in stretch (and what bugs we want and/or need to fix).

Ah-ha, will dig out the mailing list archive.

Yours,
Benda

Bug#850212: lxc: lxc init script should depend on cgroupfs-mount

[Benda Xu]

Package: lxc
Version: 1:2.0.6-1~bpo8+1
Severity: important

Dear Maintainer,

lxc requires cgroupfs to be properly mounted.  This task is either done by
cgroupfs-mount init script or systemd.  The former does nothing if started
by systemd:

  # Test for systemd and bail (we have to test before sourcing init-functions, 
or systemd hijacks us)
  # We bail because systemd already mounts cgroups sanely, so we just silently 
pretend we were successful in mounting them here
  if [ -d /run/systemd/system ]; then
  exit 0
  fi

Therefore adding cgroupfs-mount to the service dependency of lxc fix startup
issue on non-systemd systems.

  ### BEGIN INIT INFO
  # Provides: lxc
  # Required-Start: $syslog $remote_fs cgroupfs-mount
  # Required-Stop: $syslog $remote_fs cgroupfs-mount

-- System Information:
Debian Release: 8.6
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages lxc depends on:
ii  init-system-helpers  1.29
ii  libapparmor1 2.9.0-3
ii  libc62.24-4
ii  libcap2  1:2.24-8
ii  liblxc1  1:2.0.6-1~bpo8+1
ii  libseccomp2  2.1.1-1
ii  libselinux1  2.3-2
ii  lsb-base 4.1+Debian13+nmu1
ii  python3-lxc  1:2.0.6-1~bpo8+1
pn  python3:any  

Versions of packages lxc recommends:
ii  bridge-utils  1.5-9
ii  debootstrap   1.0.67
ii  dirmngr   2.1.16-3
ii  dnsmasq-base  2.72-3+deb8u1
ii  gnupg 2.1.16-3
ii  iptables  1.4.21-2+b1
pn  libpam-cgfs   
pn  lxcfs 
ii  openssl   1.0.1t-1+deb8u5
ii  rsync 3.1.1-3
pn  uidmap

Versions of packages lxc suggests:
pn  apparmor 
ii  btrfs-tools  4.7.3-1~bpo8+1
ii  lvm2 2.02.111-2.2+deb8u1

-- Configuration Files:
/etc/apparmor.d/lxc/lxc-default [Errno 2] No such file or directory: 
u'/etc/apparmor.d/lxc/lxc-default'
/etc/apparmor.d/lxc/lxc-default-with-mounting [Errno 2] No such file or 
directory: u'/etc/apparmor.d/lxc/lxc-default-with-mounting'
/etc/init.d/lxc changed:
log_daemon_msg () {
echo $@
}
test ! -r /lib/lsb/init-functions ||
. /lib/lsb/init-functions
start() {
# Setup host /dev for autodev containers.
log_daemon_msg "Starting LXC autoboot containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers start
}
stop() {
log_daemon_msg "Stopping LXC containers: "
/usr/lib/x86_64-linux-gnu/lxc/lxc-containers stop
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart|reload|force-reload)
$0 stop
$0 start
;;
*)
echo "Usage: $0 {start|stop|restart|reload|force-reload}"
exit 2
;;
esac
exit $?

/etc/lxc/default.conf [Errno 2] No such file or directory: 
u'/etc/lxc/default.conf'

-- no debconf information
diff --git a/init.d/lxc b/init.d/lxc
index 1205d8c..e2e620a 100755
--- a/init.d/lxc
+++ b/init.d/lxc
@@ -7,8 +7,8 @@
 #
 ### BEGIN INIT INFO
 # Provides: lxc
-# Required-Start: $syslog $remote_fs
-# Required-Stop: $syslog $remote_fs
+# Required-Start: $syslog $remote_fs cgroupfs-mount
+# Required-Stop: $syslog $remote_fs cgroupfs-mount
 # Should-Start:
 # Should-Stop:
 # Default-Start: 2 3 4 5

Bug#846915: Fixing OpenRC halt/reboot behavior by updating initscripts

[Benda Xu]

lumin <cdlumin...@gmail.com> writes:

> On Mon, 2016-12-05 at 15:29 +0900, Benda Xu wrote:
>> It turns out /etc/init.d/rc can be used to separate reboot and halt.
>> Please test openrc_0.22-1.
>
> openrc_0.22-1 really fixed the bug on kfreebsd-amd64. Thanks!
>
> with apt source:
> deb http://incoming.debian.org/debian-buildd/buildd-sid main

Glad to hear it. Thank you!

Yours,
Benda

Bug#844685: [PKG-OpenRC-Debian] Bug#844685: openrc: System reboots instead of shutting down (su -c halt)

[Benda Xu]

Hi lumin,

lumin  writes:

> I encountered the same problem after replacing sysv-rc
> with openrc on sid/kfreebsd-amd64. "sudo poweroff" just
> triggers a reboot instead of real poweroff.
>
> This can be fixed by installing sysv-rc back.

Thanks for the report.  I can reproduce this bug on Linux, too.

Yours,
Benda

Bug#784044: Patches for opensuse 42.1

[Benda Xu]

Hi,

After applying the obs-build patch in
https://github.com/lxc/lxc/pull/1260, the attached patch allows openSUSE
42.1 to be bootstrapped on Debian.

Yours,
Benda

1. openSUSE forbids root login. chpasswd may not work from missing PAM modules.
2. during bootstrap zypper need to import archive keys without checking.
3. dependency of iproute2 could not be resolved during bootstrap.

Index: templates/lxc-opensuse
===
--- templates.orig/lxc-opensuse
+++ templates/lxc-opensuse
@@ -116,7 +116,6 @@ EOF
 touch $rootfs/etc/sysconfig/kernel
 
 echo "Please change root-password !"
-echo "root:root" | chpasswd -R $rootfs
 
 return 0
 }
@@ -150,7 +149,7 @@ download_opensuse()
 else
 zypper --quiet --root $cache/partial-$arch-packages --non-interactive ar http://download.opensuse.org/update/$DISTRO/ update || return 1
 fi
-	zypper --quiet --root $cache/partial-$arch-packages --non-interactive --gpg-auto-import-keys update || return 1
+zypper --quiet --root $cache/partial-$arch-packages --non-interactive --gpg-auto-import-keys --no-gpg-checks update || return 1
 zypper --root $cache/partial-$arch-packages --non-interactive in --auto-agree-with-licenses --download-only zypper lxc patterns-openSUSE-base bash iputils sed tar rsyslog || return 1
 cat > $cache/partial-$arch-packages/opensuse.conf << EOF
 Preinstall: aaa_base bash coreutils diffutils
@@ -188,12 +187,6 @@ EOF
 echo "Support: dhcpcd" >> $cache/partial-$arch-packages/opensuse.conf
 fi
 
-# Leap doesn't seem to have iproute2 utils installed
-if [ $DISTRO == "leap/42.1" ]
-then
-echo "Support: net-tools iproute2" >> $cache/partial-$arch-packages/opensuse.conf
-fi
-
 if [ "$arch" = "i686" ]; then
 mkdir -p $cache/partial-$arch-packages/var/cache/zypp/packages/repo-oss/suse/i686/
 for i in "$cache/partial-$arch-packages/var/cache/zypp/packages/repo-oss/suse/i586/*" ; do

Bug#816494: me too

[Benda Xu]

I am meeting the same bug with inkscape 0.91-11.

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Bug#830991: Summary of needed changes

[Benda Xu]

Michael Biebl  writes:

> Benda, can you please file a bug against initscripts+sysvinit-core about
> getting openrc added as alternative.

Since sysvinit has no active maintainer and the change is trivial, I went
ahead to commit the change.

  
http://anonscm.debian.org/cgit/collab-maint/sysvinit.git/commit/?id=071aba18010e3cd3baac72f66896ba2ae207c0f6

> We can then block the openrc bug for dropping the Provides with those
> bugs against initscripts+sysvinit-core.

I can track this manually.

> If there is no maintainer upload of sysvinit in the near future, I'll
> can take care of that as I plan to NMU sysvinit anyway, once the
> priorities have been adjusted in the archive.

Alright, thanks!

Benda


signature.asc
Description: PGP signature

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Very nice wrap-up.  Thank you!

Michael Biebl  writes:

>> I can see sysvinit-core Depends: initscripts (>= 2.88dsf-13.3).
>
> Sure. My point was, that installing openrc should lead to a system
> booting with openrc as init. This was my premise.
> And sysvinit-core depending on initscripts would therefor not help.
>
> You made clear that this is *not* how you want openrc to be seen.
>
> Afaics, you only want providers of /sbin/init to be treated as init
> system. And only those packages need to make sure that the resulting
> system is bootable. I acknowledge there is some logic in that.
>
>
>>> If openrc depends on initscripts to boot a system successfully, it
>>> should depend on it.
>> 
>> Hmm, I think we can express the dependency chain as
>> 
>>  sysvinit-core -> sysv-rc/openrc -> initscripts
>>
>> and drop sysvinit-core -> initscripts.

On a second thought, this is not optimal.  We'd better do

  sysvinit-core -> initscripts -> sysv-rc/openrc

> Well, given your explanations about how you see the purpose of openrc, I
> no longer think this change is needed.

FYI, I am planning to introduce openrc-native initscripts packaged as
"openrc-initscripts" as an alternative to initscripts.  Also in bug
827733, we will have busybox-init in the future. All the following
systems are valid to boot:

  sysvinit-core | busybox-init -> initscripts -> sysv-rc | file-rc | openrc
  sysvinit-core | busybox-init -> openrc-initscripts -> openrc

> So, with Benda's input here, I think what should happen is
>
> a/ Add a Pre-Depends: init-system-helpers to openrc for #829488

Done in openrc package git repo.

> b/ Make the Conflicts: openrc in systemd versioned, related to #829488,
> as it avoids the switch to file-rc during the dist-upgrade

Done in systemd package git repo.

> c1/ Drop the Provides: sysv-rc from openrc

Yes, but c2 should happen first.

> c2/ Update initscripts and sysvinit-core and add openrc as an
> alternative to sysv-rc | file-rc

> d/ Clarify the openrc package description, make it clear that it is not
> supposed to be an init system and that booting with openrc requires a
> compatible /sbin/init to be installed.

Done in openrc package git repo.

> Benda, is that a fair summary in your POV?

Yes, we are reaching consensus here.

> we should probably merge #830991 and #831053 and retitle it, asking
> for a clarification in the package description.

Yeah!

> I think c/ is related to #829488 as well. systemd in jessie has a
> Depends: sysv-rc, as this was supposed to ensure compatible
> implementations of invoke-rc.d/update-rc.d are installed. That obviously
> did not work out, due to openrc providing sysv-rc.
>
> So I think, dropping Provides: sysv-rc should be done as part of
> #829488. Or instead of merging #830991 and #831053 we repurpose one to
> deal with Provides: sysv-rc.
>
> Benda, any preferences?

I prefer the former.

Cool.  I can sense an ultimate resolution around the corner.
Benda


signature.asc
Description: PGP signature

Bug#827733: Better manage /sbin/init by busybox

[Benda Xu]

Hi Jon,

Very interesting patch!

A package busybox-init, similar to busybox-syslogd, makes more sense to
me.  It can be made openrc-neutral.

The Debian openrc package is a drop-in replacement to sysv-rc, the
latter provides /etc/init.d/rc and /etc/init.d/rcS.  OpenRC follows this
convention so that /etc/inittab (of sysvinit) is not needed to be
updated.

It is also desirable to run busybox-init + sysv-rc or busybox-init +
file-rc.  It can be achieved if the /etc/inittab of busybox-init is
written as that in the appendix.


@debian-boot team, do you think such a busybox-init package feasible?  If
so I am going to reassign this bug to src:busybox.

Yours,
Benda

Appendix: busybox-inittab

::sysinit:/etc/init.d/rcS
::wait:/etc/init.d/rc 2
::shutdown:/etc/init.d/rc 0

# What to do when CTRL-ALT-DEL is pressed.
::ctrlaltdel:/etc/init.d/rc 6

# /sbin/getty invocations for the runlevels.
#
::respawn:/sbin/getty 38400 tty1
::respawn:/sbin/getty 38400 tty2
::respawn:/sbin/getty 38400 tty3
::respawn:/sbin/getty 38400 tty4
::respawn:/sbin/getty 38400 tty5
::respawn:/sbin/getty 38400 tty6

# Example how to put a getty on a serial line (for a terminal)
#
#::respawn:/sbin/getty -L ttyS0 9600 vt100
#::respawn:/sbin/getty -L ttyS1 9600 vt100

# Example how to put a getty on a modem line.
#
#::respawn:/sbin/mgetty -x0 -s 57600 ttyS3

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Michael Biebl  writes:

>> I agree that systemd-sysv version-conflict with openrc (<0.20.4-1).
>
> I chose 0.20.4-2.1, as this also contained the cleanup of the diversions
> from previous versions.
>
>> Do you have an estimated date for that?
>
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=1ab8d4836dcca0485cd7b8307b2469c295584898
>
> Will be in the next upload of systemd. We don't have a date for that
> yet, but it should be soonish.

Great. Thanks!

>> This is the only reason to stop openrc from providing sysv-rc.  But
>> systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
>> anymore, if we don't want to touch jessie.

> I think dropping that Provides is logically correct and should be done
> in any case, maybe not for stretch, but in sid for sure.

In the long run, yes. It was a hack as a drop-in replacement of sysv-rc.

> > >  plus depends on initscripts, to be safe and add Depends:
> > > initscripts
> > 
> > I don't think so.
> > 
> >   initscripts Depends: sysv-rc | file-rc
> > 
> > and openrc provides sysv-rc.  The dependence relation is already there.

> Ahem, no. It's the inverse dependency
> With initscripts no longer being installed by default, nothing will
> guarantee that initscripts will be installed. 

I can see sysvinit-core Depends: initscripts (>= 2.88dsf-13.3).

> If openrc depends on initscripts to boot a system successfully, it
> should depend on it.

Hmm, I think we can express the dependency chain as

 sysvinit-core -> sysv-rc/openrc -> initscripts

and drop sysvinit-core -> initscripts.

> > >  systemd-sysv: Make Conflicts against openrc versioned << y.z.
> > 
> > openrc (<<0.20.4-1) to be precise.
> > 
> > > Benda, if you push such changes, I'll sponsor the uploads.
> > 
> > In conclusion, the bugs are resolved if openrc Pre-Depends
> > init-system-helpers and systemd-sysv only conflicts with a older version
> > of OpenRC.

> The Pre-Depends and versioned Conflicts only address the failing dist
> upgrade (#829488).
> They don't address that the prioritoy of initscripts will be lowered for
> stretch and is no longer installed by default.

As stated above.

> The package description says "dependency based init system".

> If you want openrc to be treated as you say,i.e. not as an init, you
> should make that super-clear in the package description that installing
> openrc will *not* necessarily lead to a system booting with openrc.

> Otherwise it's highly confusing.

Good point and nice catch!

Thanks!
Benda


signature.asc
Description: PGP signature

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

I would like to clarify that OpenRC is a service manager, not an init.
Treat it as a shell script that can call (or supervise) a set of tools.
OpenRC is not at all exclusive. It can coexist with anything provided
there is no file conflict.

So...

Michael Biebl  writes:

> So, my POV is, that a user that runs apt install openrc get's a system
> that will boot with openrc. At least that would be my expectation. 

Although common, this is not all the use cases of OpenRC.  It is
perfectly fine to execute openrc by the user at any time.

A user does not install OpenRC to get his system to boot.  He should
install runit / sysvinit / systemd / s6 instead.  If the user *happens*
to install both sysvinit and OpenRC, he will have a system that booted
with sysvinit and OpenRC.

> So openrc should make sure to pull in all necessary bits and pieces.

That said, an openrc Suggests: sysvinit-core could make sense.

If it is not a dependency, no need to depend on it.

> A Conflicts: systemd-sysv in openrc isn't the correct solution to
> ensure this,

I agree, they can coexist.  Systemd can call openrc, no problem at all.

No conflict here.   The only point of the conflict was
{update,invoke}-rc.d, which is now gone thanks to init-system-helpers.

> as you might get an arbitrary /sbin/init implementation (like upstart,
> which I'm not sure actually works with openrc)

Sure upstart works with OpenRC.  (Only that upstart is removed from
Debian.)

> or no /sbin/init at all (init is no longer essential).

This is acceptable, no problem at all.  You can boot with init=/bin/bash
and manually invoke openrc as you like.  A docker instance, for example,
behaves like that.

Yours,
Benda


signature.asc
Description: PGP signature

Bug#830991: [PKG-OpenRC-Debian] Bug#830991: Summary of needed changes

[Benda Xu]

Hi Thomas,

Thanks for the summarization.

Thomas Goirand  writes:

> Continuing our discussions in #debian-systemd, here's what need to happen.
>
> Drop Provides: sysv-rc

>  zigo: in jessie, systemd-sysv tries to ensure correct combination
> of packages by depending on sysv-rc ... unfortunately openrc provides
> sysv-rc, so satisfies that. Which means you can start out with a messy
> situation which only goes downhill from there when also throwing file-rc
> into the mix.

This is the only reason to stop openrc from providing sysv-rc.  But
systemd-sysv in sid no longer depend on sysv-rc.  No need to do that
anymore, if we don't want to touch jessie.

>  openrc (sid/stretch): replace Recommends: init-system-helpers
> with
> Pre-Depends: init-system-helpers (>= 1.29) 

Ok.  That seems to be the only to guarantee availability of 
{update,invoke}-rc.d.

>  plus depends on initscripts, to be safe and add Depends:
> initscripts

I don't think so.

  initscripts Depends: sysv-rc | file-rc

and openrc provides sysv-rc.  The dependence relation is already there.

>  openrc (stable + sid): add Depends: sysvinit-core, 

  sysvinit-core Depends: sysv-rc | file-rc

The same logic applies.

>  systemd-sysv: Make Conflicts against openrc versioned << y.z.

openrc (<<0.20.4-1) to be precise.

> Benda, if you push such changes, I'll sponsor the uploads.

In conclusion, the bugs are resolved if openrc Pre-Depends
init-system-helpers and systemd-sysv only conflicts with a older version
of OpenRC.

Benda

Bug#830991: Summary of needed changes

[Benda Xu]

Hi Michael,

Michael Biebl  writes:

> For openrc that is no longer the case in newer versions, that's why we
> want to make that versioned.

I agree that systemd-sysv version-conflict with openrc (<0.20.4-1).

Do you have an estimated date for that?

Thanks,
Benda


signature.asc
Description: PGP signature

Bug#675715: Reproduced the bug with scim-1.4.16 on xterm

[Benda Xu]

Hi Tz-Huan,

Tz-Huan Huang  writes:

> What input module do you use? I have tried scim-pinyin but I cannot
> get the black boxes as you provided. Here is my screenshot for your
> reference
>
> https://www.csie.ntu.edu.tw/~tzhuan/tmp/sid.png

It seems to be exclusive on xterm.  What terminal emulator are you
using?

Cheers,
Benda

Bug#620391: marked as done (scim keeps crashing)

[Benda Xu]

Hi Rolf,

Rolf Leggewie  writes:

> Benda, it would have been helpful if the closing mail had included a
> mentioning of the missing information that had been requested from
> Michal and without which there isn't anything we can do.

Thanks for pointing this out.

Will do next time.

Cheers,
Benda

Bug#686924: RFC: casacore-2.1.0-1 debian package

[Benda Xu]

Hi folks,

I have just pushed my working branch of casacore packaging to

  https://anonscm.debian.org/cgit/debian-astro/packages/casacore.git

I consider it ready to be uploaded. Please have a review and share your
thoughts.

To build it,

  $ git clone git://anonscm.debian.org/debian-astro/packages/casacore.git
  $ cd casacore
  $ git branch upstream --track origin/upstream
  $ gbp buildpackage


casacore-1.7.0-1 was uploaded two years ago and rejected by ftp-masters
with some minor license issues[1].  Now that the upstream has removed
the problematic sources in the 2.1.0 release, it is time to upload
again.

I would like to thank Ole (the initial packager and my mentor) and Gijs
(now an upstream developer) for their help through the packaging.

Yours,
Benda

1. https://lists.debian.org/debian-astro/2014/11/msg8.html

Bug#819258: [PKG-OpenRC-Debian] Bug#819258: openrc: dependency resolving fails using init-system-helpers

[Benda Xu]

Hi,

Thanks for the report.

Kevin Velghe  writes:

> On Sat, Mar 26, 2016 at 03:02:00AM +0100, Adam Borowski wrote:

>> I've tried multiple scenarios but failed to reproduce your problem.
>> Including dist-upgrades:
>>   jessie sysv-rc -> unstable -> openrc
>>   jessie sysv-rc -> openrc -> unstable
>> 
>> So there's something more complex on your system than just lvm2.  Letting us
>> know what might be helpful in trying to find out what's amiss for
>> you.

I cannot reproduce the bug by installing lvm2 on sid or jessie.

> The problem at boot might be related to the fact /boot is located on a
> lvm partition, otherwise I can't think about anything.
>
> OK, I'll check the installation problem on a container later, but if I
> install sysv-rc or current openrc package, then the installation of lvm2
> fails because the dependencies aren't enabled. 

[...]
> Yesterday, I upgraded lvm2. During the upgrade, I got the following error:
>  insserv: Service mountdevsubfs has to be enabled to start service lvm2
>  insserv: exiting now!

> This was fixed by manually enabling mountdevsubfs using insserv, after
> which I could finish upgrading. 

Why was mountdevsubfs not enabled?

Could you please paste the output of "ls -l /etc/rc*.d/*mountdev*" and
"rc-update | grep mountdev"?

On my system, they produce:

# ls -l /etc/rc*.d/*mountdev*
lrwxrwxrwx 1 root root 26 Feb 18 23:16 /etc/rcS.d/S02mountdevsubfs.sh -> 
../init.d/mountdevsubfs.sh

# rc-update | grep mountdev
 mountdevsubfs.sh |sysinit

> This morning however, booting hanged at lvm.

Did it hang with openrc?

> Downgrading lvbm2 didn't solve the problem, so I tried booting using
> sysv-rc, which had the same problem. systemd booted well, as did
> openrc 0.20.4-1.

Didn't openrc+lvm2 hang? Confused:(

>> As you say that sysv-rc failed too, it doesn't sound like anything related
>> to openrc.

> Yes, it is related to openrc, as openrc seems only affected because of
> the use of init-system-helpers to provide update-rc.d, which does not
> seem to use openrc to determine the dependencies.

The new update-rc.d from init-system-helpers calls rc-update to handle
the runlevels for openrc.  It is different from the old update-rc.d
shipped with openrc only in that it also calls insserv, too.

So the question really becomes: is your mountdevsubfs.sh enabled?

Benda


signature.asc
Description: PGP signature

Bug#811377: [Pkg-sysvinit-devel] Adopting Sysvinit

[Benda Xu]

Petter Reinholdtsen <p...@hungry.com> writes:

> And I just approved Benda Xu.  Lots of bugs to address in BTS, so I hope
> you have lots of time to spend on the package. :)
>
> Also, I am involved upstream, which also consist only of inactive
> people, so let me know if you want to send fixes upstream. :)

Thanks Petter!  Nice to know that we have control upstream, too.

Simon, I resonate with your new plan and would like to participate. How
is it going on?

Yours,
Benda

Bug#817006: [PKG-OpenRC-Debian] Bug#817006: ack to NMU

[Benda Xu]

Hi Adam,

Adam Borowski  writes:

> The popcon for openrc is 83, which, assuming that 10% of users run popcon
> (a wild-ass guess) means 830 users.  I have no idea what part of this is
> unstable, but as openrc in Debian is quite experimental, I guess quite a
> bunch of such users are affected.
>
> The breakage is pretty severe -- it does match the description of "critical"
> after all.  Every affected user would have to research the fix and apply
> it manually.  Thus, I don't think it's a good idea to ignore this bug,
> especially that the fix is easy.

Okay, I will take this lesson. Thank you for your help!

>> That said, I understand theoretically your NMU is the correctly way to
>> go.  So if you intend to do so, consider this email as an ack to NMU
>> from the maintainer team.
>
> I'll upload it then.

Great!  It is in Sid now.

>> One thing to notice is that we are tracking the package at
>> 
>>   http://anonscm.debian.org/cgit/openrc/openrc.git
>> 
>> Would you mind if I ask you to prepare a commit to the master
>> corresponding to the NMU?
>
> Of course.  I don't have push rights to that repository, so two commits are
> attached to this mail (one for the fix, one for changelog).

Applied and pushed.

You could apply at

https://alioth.debian.org/projects/openrc

to get push rights.

>> BTW, if you are interested in OpenRC, you are welcomed to join the
>> maintenance team.
>
> I'm afraid I don't really know inner workings of openrc, I use it on only
> one machine (which happens to be my main desktop, but still...).  Everywhere
> else I'm on sysv-rc.

Ah-ha. Me too, desktops, laptops or newly installed servers (those I
could access the consoles).

> This said, keeping openrc viable seems important for resisting
> systemd-ization of Debian so I probably should help in _some_ way.

Agreed.

>> 1. 0.20.4-1 was uploaded in a hurry to keep itself in testing.  The pts
>> system lied and we did not make it.  divert should not have existed in
>> OpenRC.
>
> It can be removed in some time, after the affected systems are fixed.

Okay.


Also I would like to thank Andreas for pointing this out.

Yours,
Benda

Bug#817006: ack to NMU

[Benda Xu]

Hi Adam,

Thank you for your report.  I appreciate your enthusiasm.

Sorry, I forgot to append my reply to Andreas to #811708:

  
http://lists.alioth.debian.org/pipermail/openrc-devel/Week-of-Mon-20160307/000436.html

Basically, my taking to this bug is to ignore it, leaving the users to
fix the breakage by

  dpkg-divert --remove /usr/sbin/invoke-rc.d
  dpkg-divert --remove /usr/sbin/update-rc.d

manually.  

0.20.4-1 lasted only 10days.  Only few users would be affected.
Provided OpenRC have already been removed from testing thanks to i-s-h
[1], such a breakage is tolerable for unstable.


That said, I understand theoretically your NMU is the correctly way to
go.  So if you intend to do so, consider this email as an ack to NMU
from the maintainer team.


One thing to notice is that we are tracking the package at

  http://anonscm.debian.org/cgit/openrc/openrc.git

Would you mind if I ask you to prepare a commit to the master
corresponding to the NMU?

BTW, if you are interested in OpenRC, you are welcomed to join the
maintenance team.

Yours,
Benda


1. 0.20.4-1 was uploaded in a hurry to keep itself in testing.  The pts
system lied and we did not make it.  divert should not have existed in
OpenRC.

Bug#811377: Adopting Sysvinit

[Benda Xu]

Dear Ben,

I am Benda Xu, one of the maintainers of OpenRC, which uses sysvinit by
default.

I would like to adopt sysvinit, as I have been and will be an active
user.

Could you please grant me the upload permission?  I am in the Debian
maintainer database with key 8E192076 and fingerprint:

  C3A5 0484 0B67 8260 DA12  766A D25D 611C 8E19 2076

Thanks!
Benda

Bug#811708: init-system-helpers openrc branch pull request

[Benda Xu]

Dear Martin and Michael,
Cc Andreas,

I have added openrc support to invoke-rc.d and update-rc.d in
collab-maint/init-system-helpers.git[1].  Does it look good to be
uploaded?

replying to Andreas below:

Andreas Henriksson <andr...@fatal.se> writes:

> On Fri, Feb 19, 2016 at 03:36:38PM +0900, Benda Xu wrote:
>> I have pushed an openrc branch into
>> collab-maint/init-system-helpers.git[1], to have openrc supports in
>> invoke-rc.d and update-rc.d.  I didn't add a changelog item though.
>
> Great that you implemented what I consider the preferred solution
> by implementing it in the same version as supports other init systems.

Yeah, as I said in the last email I agree it is the right way to move
forward to benefit everyone.

>> 
>> Could you please help review it?
>
> I've quickly looked at it and while not knowing anything in particular
> about openrc from the viewpoint of other init systems I don't see
> how your changes could possibly cause any problems for those.

Thanks for your positive comments.

>> 
>> After init-system-helpers make a version bump supporting openrc, I will
>> bump openrc to finish the transition.
>
> Please beware that I'm *not* the maintainer of init-system-helpers
> so please contact them for final review, merge and upload.

Probably it's a good chance to join to maintain invoke-rc.d and
update-rc.d for the long term.

Yours,
Benda

1. 
http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/log/?h=openrc

Bug#811708: init-system-helpers openrc branch pull request

[Benda Xu]

Hi Andreas,

I have pushed an openrc branch into
collab-maint/init-system-helpers.git[1], to have openrc supports in
invoke-rc.d and update-rc.d.  I didn't add a changelog item though.

Could you please help review it? 

After init-system-helpers make a version bump supporting openrc, I will
bump openrc to finish the transition.

Thanks Svante, and thanks Adam for the report.

Cheers,
Benda

1. 
http://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/log/?h=openrc

Bug#811708: pong on update-rc.d

[Benda Xu]

Hey guys,

Thanks for the report.  update-rc.d in OpenRC is a hack based on that
from sysv-rc.  I think the right way forward is to extend
init-system-helpers to support OpenRC.

I will try to figure it out.  If I couldn't make it in time, Svante's
patch will be upload to close this bug.

Cheers,
Benda