bug#67656: 'man touch' text about --time hard to read compared to 'touch --help'
Hi, In the manpage of touch, 'touch' flag --time is described as: --time=WORD change the specified time: WORD is access, atime, or use: equivalent to -a WORD is modify or mtime: equivalent to -m ... whereas, in the --help text, --time is described as: --time=WORDchange the specified time: WORD is access, atime, or use: equivalent to -a WORD is modify or mtime: equivalent to -m The latter is far more readable, and the manpage appears to be mis-formatted (perhaps by help2man?). IMO, the help text should also say 'if WORD is ..., or ...: ...' to provide further clarity in the text. The formatting issue is more pressing, however, as it makes the manpage highly confusing compared to the help or manual texts. Could this be corrected? Thanks, have a lovely day! -- Arsen Arsenović signature.asc Description: PGP signature
bug#64326: Some more info about rm bug
Hi, LitHack writes: > Basically what it doing is that it doesn't recognise (-) this as a file > name part even when using (\-). This bug will work on most of utilities > like cat, cp etc This is simply how argument parsing and shell syntax work. 'rm \-abc' is equivalent to just 'rm -abc', which is parsed as 'rm -a -b -c'. To delete a file with a dash at the start of its name, use 'rm ./-file' and similar. Hope that helps, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
bug#63850: cp fails for files > 2 GB if copy offload is unsupported
Paul Eggert writes: > That's not surprising, as this sort of problem arises only when building for a > newer platform yields a package that will run incorrectly on an older > platform. Problems like these are relatively rare if the only such mismatch is > the Linux kernel version, because current glibc explicitly supports building > for Linux kernel>=3.2, even when glibc is built on newer kernels, these days > nobody doing this sort of thing cares about kernels older than 3.2, and most > packages rely entirely on glibc to access the kernel. There are exceptional > packages, though, and you may run into problems with those exceptions. > > If users build for newer platforms and it usually works on older platforms, > that's great! But you might want to document that it might not work. Because > it > might not. In this instance, we have a configure-time test that makes a false assumption (namely, that linux-headers version matches the linux version), preventing a very valid runtime test from being emitted. The cost for enabling this check is removing a dozen or so lines of code in copy-file-range.m4 (and the subsequent addition of a few instructions and a single syscall that is executed once). It is entirely reasonable to expect that a user will roll back a kernel update, as there are many reasons one might have to do so. This is not quite comparable to downgrading libraries (which will, reasonably, break as a result), because the kernel<->userspace boundary is of very different nature to the library<->* boundary (namely, the former is far more 'loose', in the sense that failure to implement something manifests as a runtime failure rather than a build-time, or even rtld-time failure). It is no coincidence that glibc explicitly supports kernels older than the linux-headers it's being built with. I'd understand not wanting to support this use-case in the cases where doing so is difficult, but here, it's more difficult to not support this use-case than to support it. Please reconsider dropping the configure-time version check. Thanks in advance, have a lovely day. -- Arsen Arsenović signature.asc Description: PGP signature
bug#63850: cp fails for files > 2 GB if copy offload is unsupported
Mike Gilbert writes: > The macro in copy-file-range.m4 performs a build time version check > against the installed linux headers (/usr/include/linux). > > In this case, headers from linux-6.1 are being used at build time. > However, the code is being run on a linux-4.19 kernel. > > Generally speaking, syscall checks must be done at run time on Linux, > not build time. Right, the replacement should always be emitted (perhaps with glibc stub detection, and omitted if one is found, though). linux-headers is a weird library, in that it makes no implication about the compatibility level of your resulting executable, so, no assumption about runtime versions or behavior can be made from static checks. -- Arsen Arsenović signature.asc Description: PGP signature
