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#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#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#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#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#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#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#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