Bug#833888: kbd: Consider including upstream vlock
On 10/08/2016 14:37, Andreas Henriksson wrote: 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.) I'm very sorry, i didn't noticed that my reply was directed to you rather that the bug report. My (possibly incorrect) understanding is that Frank started the fork, rewrote it basically from scratch with a new design and many more features. 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.
Bug#833888: kbd: Consider including upstream vlock
Hello again. On Wed, Aug 10, 2016 at 01:56:45PM +0200, Cesare Leonardi wrote: > Hello Andreas and thank you for your detailed reply. > > On 10/08/2016 09:07, Andreas Henriksson wrote: > >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. > > I don't know who contact for this, perhaps the release team. Let's see. 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. > > Anyhow i write here some more notes just to add details for whom will > eventually decide about this. 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.) > From the man page and from "http://danlj.org/mkj/"; can be seen that the > initial vlock's author was Michael K. Johnson (Red Hat), then the development > was taken by Frank Benkstein. Looking in the kbd's git repository, the kbd's > implementation started in 2011 incorporating the source from Michael K. > Johnson, who is still cited as its author in the man page: > http://man7.org/linux/man-pages/man1/vlock.1.html > In the kbd's git i cannot find reference to Frank Benkstein's work, so i > assume that his work came after the fork. > Frank Benkstein's site, that is still marked as the upstream vlock package > repository, currently doesn't seem to exist anymore. > > The implementation from kbd has compatible options but has a subset of them. > It seems to lack all the features related to plugins: > - support for locking consoles from X; > - support disabling SysRq while consoles are locked; > - support for interact with screensaver. 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
Bug#833888: kbd: Consider including upstream vlock
Control: severity -1 wishlist Hello Cesare Leonardi. Thanks for your bug report. On Wed, Aug 10, 2016 at 12:51:09AM +0200, Cesare Leonardi wrote: > Package: kbd > Version: 2.0.3-2 > Severity: normal > > 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. 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. > > 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. Thanks for this overview. Regards, Andreas Henriksson
Bug#833888: kbd: Consider including upstream vlock
Package: kbd Version: 2.0.3-2 Severity: normal 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. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages kbd depends on: ii libc6 2.23-4 ii lsb-base 9.20160629 Versions of packages kbd recommends: ii console-setup 1.148 kbd suggests no packages. -- no debconf information
