Bug#1103923: missing "remote" pam config

2025-04-22 Thread Christof Meerwald
On Tue, Apr 22, 2025 at 11:08:37PM +0200, Chris Hofstaedtler wrote: > Hi, > > thank you for the report. > > * Christof Meerwald [250422 22:42]: > > in login.c we have: > > > > rc = pam_start(cxt->remote ? "remote" : "login", > > &

Bug#1103923: missing "remote" pam config

2025-04-22 Thread Christof Meerwald
Package: login Version: 1:4.16.0-2+really2.41-4 in login.c we have: rc = pam_start(cxt->remote ? "remote" : "login", so it's either using "login" or "remote" for pam_start, but the package only ships a login configuration for pam. The old login from 1:4.13+dfsg1-1+b1 always used "login" with

Bug#1078023: login: SIGHUP upon executing 'login'

2025-04-05 Thread Christof Meerwald
Just saying that I am also seeing issues with the new login binary related to SIGHUP. In my case it's login being started by rsh-redone-server (85-4) (from xinetd). What seems to be happening is that the vhangup triggers a POLLHUP in in.rlogind, and the read on that file descriptor then returns EI

Bug#1101703: rlogind immediately disconnects

2025-03-30 Thread Christof Meerwald
Package: rsh-redone-server Version: 85-4 With login 1:4.16.0-2+really2.40.4-5 in.rlogind immediately disconnects as it can't handle the "vhangup" call used by login. See also Bug#1078023, it seems that rlogind needs some special handling to handle a read returning EIO; I have found this in the te

Bug#1069902: gropdf generates invalid CreationDate and ModDate

2024-04-26 Thread Christof Meerwald
Package: groff Version: 1.23.0-2 $ echo "" | groff -T pdf | grep -F -a Date 5 0 obj << /CreationDate (D:20240426202138+01'+00') /ModDate (D:20240426202138+01'+00') $ echo "" | groff -T pdf | grep -F -a Date 5 0 obj << /CreationDate (D:20240426202145+01'+00') /ModDate (D:20240426202145+01'+00') $ e

Bug#986736: RFP: xmake -- A cross-platform build utility based on Lua

2021-04-10 Thread Christof Meerwald
Package: wnpp Severity: wishlist xmake is a lightweight cross-platform build utility based on Lua. It uses xmake.lua to maintain project builds. Compared with makefile/CMakeLists.txt, the configuration syntax is more concise and intuitive. It is very friendly to novices and can quickly get started

Bug#866015: caused by missing TLS SNI support

2017-10-22 Thread Christof Meerwald
This seems to be due to missing support for SNI (server name indication), so related to #797968

Bug#733482: ELinks not built with lua support

2014-01-13 Thread Christof Meerwald
On Mon, Jan 13, 2014 at 04:59:25PM +0100, Moritz Muehlenhoff wrote: > Do you use Lua scripting or did you spot this from the build logs? > > Given that noone noticed that for 16 months I'm tempted to simply drop > the Lua build dep entirely. I am using Lua scripting for ELinks (mainly to rewrite

Bug#733482: ELinks not built with lua support

2013-12-29 Thread Christof Meerwald
Package: elinks Version: 0.12~pre6-4 The patch 09-Switch-to-use-lua-5.1.diff only updates configure.in, but doesn't update or rebuild the configure script. This means that lua5.1 is not detected by the configure script and elinks is therefore built without lua support. Also compare the lua configu