#833888 kbd: Consider including upstream vlock

Package:
kbd
Source:
kbd
Description:
Linux console font and keytable utilities
Submitter:
Cesare Leonardi
Date:
2024-01-09 11:51:02 UTC
Severity:
wishlist
Tags:
#833888#5
Date:
2016-08-09 22:51:09 UTC
From:
To:
Upstream kbd provides a vlock binary but it's not included in the
Debian package. Looking from Debian's changelog it's like that since
february 2013.

I know that Debian already provides a separate vlock package (i use
it), but it was last updated in 2014, it is currently orphaned and
upstream source looks unreacheable (#833843).

In light of this, i wonder if the kbd's vlock inclusion could be
reconsidered. I don't know if it could be taken as an entire substitute
for the vlock package.

Looks like Opensuse, Gentoo and Ubuntu still carry a vlock package from
the same source as Debian, while Fedora and Archlinux don't have it in
their repository and use the one provided with kbd.

Cesare.

#833888#10
Date:
2016-08-10 07:07:03 UTC
From:
To:
Hello Cesare Leonardi.

Thanks for your bug report.


When I initially got involved in the kbd packaging in Debian this
was one of the things I looked into. I don't really see a problem
with shipping the kbd vlock program other than the "next generation"
vlock first needs to go away. IIRC the "next generation" vlock
has run pretty wild with features so even if it goes away it might
be that we need to ship one Debian release without any vlock before
we can reclaim the vlock binary name..... unless someone can come
up with a plan on how we can migrate from the current to the kbd vlock
without causing any problems for any configuration of the current
vlock users. Seems pretty unlikely anyone would go through all that
work....

I'd suggest first reaching out to people with potential interest
in the current vlock implementation and see if they have any
objections or suggestions.

Since I personally have no real plans to do all this work I'll likely
tag this bug report somehow... not sure if wontfix or moreinfo is best.
This tag should not be considered a final decision, just a current
status. If someone does the work and lays out a plan on how we can
safely and debian-policy compliantly reintroduce the kbd vlock then
we could certainly just untag and proceed again.

Thanks for this overview.....

Regards,
Andreas Henriksson

#833888#17
Date:
2016-08-10 12:37:01 UTC
From:
To:
Hello again.

I don't think the release team cares much about this issue.

I'd say if the package has no maintainer, try the last few uploaders and
maybe even check if you can find anyone using it or caring about it
on debian-devel or possibly also debian-user.

Please do feel free to send information on the subject to this bug report
and use it for coordinating the effort.

Please do direct your mails to the bug report rather than to me, so that
the information gets properly/publicly archived. (I'll get a copy of it
any way.)

My (possibly incorrect) understanding is that Frank started the fork,
rewrote it basically from scratch with a new design and many more features.

Possibly instead of going back to kbd vlock someone should just pick
up the maintenance of franks vlock implementation and ask kbd upstream
to deprecate their implementation....

Regards,
Andreas Henriksson

#833888#22
Date:
2016-08-10 13:23:01 UTC
From:
To:
I'm very sorry, i didn't noticed that my reply was directed to you
rather that the bug report.

It's possible.
In the meantime i've updated #833843, because i've found that Frank has
a github page with a vlock repo, so i think it's the current home of the
project.

Thank you very much, Andreas, for your suggestions and considerations.

Cesare.