bug#60607: Making dvi target do nothing

On Sun, 8 Jan 2023 at 00:23, Karl Berry wrote: > How does this change to the doc look? --thanks, karl. > Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the assessment of technical accuracy to others.) -- https://rrt.sc3d.org

bug#60607: Making dvi target do nothing

On Sat, 7 Jan 2023 at 08:46, Nick Bowler wrote: > > This example in the manual is talking about writing a custom > Makefile, *without* using Automake, that you want to recurse > into using Automake's SUBDIRS feature. > Aha! Thanks for pointing this out. I think the manual is misleading in

bug#60607: Making dvi target do nothing

I'm using automake 1.16.5. The advice about how to disable the "dvi" target doesn't seem to work. In the manual it says: To make ‘dvi’ into a do-nothing target, see the example for ‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::. If I have: EMPTY_AUTOMAKE_TARGETS = dvi .PHONY:

Bug#1024789: xdg-utils: xdg-screensaver does not work on recent GNOME, and I have a fix

Package: xdg-utils Version: 1.1.3-4.1ubuntu3~22.04.1 Severity: important Tags: patch upstream I’m the upstream maintainer of Caffeine, and noticed that it was no longer working on my GNOME 42 system. Of course, the actual bug was in xdg-screensaver: until recently, gnome-screensaver ran on GNOME

Re: libpaper and gnulib

On Mon, 21 Nov 2022 at 21:30, Helmut Grohne wrote: > It is known to build and run on some architectures. Excellent point! I already mitigate this risk by building most of my (upstream) packages on macOS and Windows as well as GNU/Linux, but still. And if you decide to vendor gnulib anyway,

Re: libpaper and gnulib

On Wed, 16 Nov 2022 at 09:47, Helmut Grohne wrote: > > I think bug fixes is something you'd want. API changes less so. > My point was that there are frequently bug fixes and API changes since whatever version of gnulib is packaged in Debian. > Also note that gnulib is a piece that regularly

Re: libpaper and gnulib

Thanks very much to all those who have given advice, offered help, and spelt out some of the background of gnulib use in Debian. The summary seems to be that using gnulib in its usual way to embed files used by APIs a package uses is acceptable. -- https://rrt.sc3d.org

libpaper and gnulib

I am the upstream maintainer of libpaper (which used to be a pure-Debian project), and also a Debian Maintainer trying to get a new version of libpaper into Debian. (It involves an API/ABI transition, from the current libpaper1 to libpaper2.) Bastian Germann (b...@debian.org) is kindly helping

Re: Using relocatable-script in a GPLv2-only program

On Tue, 1 Nov 2022 at 22:24, Bruno Haible wrote: > > But first, the obligatory question: Can't you move the package to GPLv2+? > As you guessed, I can't (though it might be possible to get the original authors to, I haven't asked). > That's what would be most in line with GNU policies, since

Using relocatable-script in a GPLv2-only program

I am working on my new version of libpaper, collaborating with a Debian maintainer to get it into Debian. This has thrown up some licensing issues, most of which I have been able to resolve, thanks to gnulib's flexible licensing options. I have one remaining problem: I use a legacy script from

[Touch-packages] [Bug 1991495] [NEW] gnome-gmail does not work as a helper application

Public bug reported: To enable gnome-gmail to work, the sanitized_helper profile in /etc/apparmor.d/abstractions/ubuntu-helpers needs to allow the main script of gnome-gmail to be exec'ed. I have added a minimal change to allow that, which is attached to this bug: # Allow exec of gnome-gmail

bug#13028: inplace

On Mon, 16 May 2016 at 15:42, Pádraig Brady wrote: > > I just don't have the time at present to complete this. > > I did implement ACID file replacement using POSIX APIs a while ago in: > https://github.com/pixelb/crudini > The commit messages there have details on fsync()ing requirements etc. >

Re: [racket-users] Writing a "command-line front-end" for a language

On Mon, 5 Sept 2022 at 02:20, Shu-Hung You wrote: > > Okay, if you want to bypass the #lang protocol entirely, here is the > needed code. As you have expected, it uses eval and then calls > dynamic-require. > Thanks very much for this code and detailed explanation, that was a great help. --

Re: Fwd: [racket-users] Writing a "command-line front-end" for a language

On Sun, 4 Sept 2022 at 19:39, Philip McGrath wrote: > > You may indeed want a tool that supports files without #lang if you are > working with an existing language and there isn't a way to make the #lang > line acceptable to its existing grammar. > That's exactly it! > Despite the title of

Re: Fwd: [racket-users] Writing a "command-line front-end" for a language

On Sun, 4 Sept 2022 at 10:31, Reuben Thomas wrote: > On Sun, 4 Sept 2022 at 04:13, Philip McGrath > wrote: > >> >> However, in some cases you might really want a program other than >> `racket` as the entry point for your language: for instance, maybe you want >&

Re: Fwd: [racket-users] Writing a "command-line front-end" for a language

On Sun, 4 Sept 2022 at 04:13, Philip McGrath wrote: > > However, in some cases you might really want a program other than `racket` > as the entry point for your language: for instance, maybe you want to have > flags for controlling where the output goes. One example of such a program > is the

Re: [racket-users] Writing a "command-line front-end" for a language

On Sat, 3 Sept 2022 at 19:10, Shu-Hung You wrote: > Running `racket foo.asm` will produce the desired output, so a shell > script that directly passes the arguments to Racket could work. > Otherwise, just use (dynamic-require filename #f) in main.rkt. > Thanks for helping! Don't both of these

[racket-users] Writing a "command-line front-end" for a language

I'm a relative Racket newbie, and I've just enjoyed *Beautiful Racket*. I am working on a Racket implementation of a simple assembler (for the Hack VM in the NAND2Tetris course). I have a partial implementation up and running using #lang lines. I would like to add a more traditional command-line

Re: [Help-zile] Place where I can find zile personally made compilations of extensions / builds?

On Wed, 10 Aug 2022 at 16:29, Miki800 wrote: > > But it lacks 2 features that emacs have that are very important to me > python parsing and a terminal (that's it) > I'm afraid there's no plans to add either feature to Zile. (Indeed, in the past I removed syntax highlighting.) There's not a lot

Re: [Help-zile] Do zile have .zile.d like .emacs.d?

On Wed, 10 Aug 2022 at 16:29, Miki800 wrote: > If I want to extend zile like I can extend emacs > is there a standard path for that like there is ~/.emacs.d in emacs? > There's just ~/.zile, as documented. -- https://rrt.sc3d.org

Re: Using sc_po_check with --po-base

On Tue, 9 Aug 2022 at 10:26, Simon Josefsson wrote: > > I add the gnulib directories to the corresponding > exclude_file_name_regexp--sc_... entries in my cfg.mk, does that work > for you? Perhaps gnulib-tool could generate a gnulib.mk (included by > maint.mk) that add the appropriate sc_...

Using sc_po_check with --po-base

As suggested in the gnulib manual, I have converted a project (GNU a2ps) to use --po-base[=po-gnulib] and --po-domain, allowing gnulib to create an extra message catalog for gnulib sources. So, I have removed the gnulib files from po/POTFILES.in. However, sc_po_check in maint.mk now complains

hello-2.12.1 released [stable]

This release has no code changes since 2.12, but just a minor documentation fix and updated translations. Here are the compressed sources and a GPG detached signature[*]: https://ftpmirror.gnu.org/hello/hello-2.12.1.tar.gz https://ftpmirror.gnu.org/hello/hello-2.12.1.tar.gz.sig Use a mirror

Re: regex documentation

On Wed, 11 May 2022 at 22:22, Reuben Thomas wrote: > > Yes. I'll revise the patch. > Patch updated, now with correct (I hope!) documentation for \s and \S, modeled on that for \w and \W. (And with Bruno's stray comma removed.) -- https://rrt.sc3d

Re: regex documentation

On Wed, 11 May 2022 at 21:49, Paul Eggert wrote: > On 5/11/22 11:09, Reuben Thomas wrote: > > Sorry, I don't follow. The concrete example given is: \Sw matches any > > character that is > > not word-constituent. That seems to be [^[:alnum:]]? > > In glibc regex, \Sw

Re: regex documentation

On Wed, 11 May 2022 at 18:25, Paul Eggert wrote: > > Sorry, I should have been more specific. In glibc regex, \s is a synonym > for [[:space:]] and \S is a synonym for [^[:space:]], so the discussion > in regex.texi of @samp{\s@var{class}} etc. is wrong on a syntactic level > not just a semantic

Re: #ifdef emacs

On Wed, 11 May 2022 at 17:37, Paul Eggert wrote: > On 5/11/22 03:27, Reuben Thomas wrote: > > Mostly in alloca.c, with one case in parse-datetime.y. > Bruno handled alloca.c, and I did parse-datetime.y with the attached. > Thanks for reporting it. Thanks! I never cea

Re: regex documentation

On Wed, 11 May 2022 at 17:26, Paul Eggert wrote: > > Only thing I spotted offhand was that \s and \S mean something entirely > different in glibc as syntax classes are not programmable. > I think the documentation as I've edited it is correct. Perhaps it should say "character classes" instead

Re: regex documentation

On Wed, 11 May 2022 at 12:18, Bruno Haible wrote: > Reuben Thomas wrote: > > > I'm happy to prepare a patch in this case. I would simply remove all > > > mention of syntax tables, as that functionality is no longer available. > > > > Attached. > > Thanks!

Re: regex documentation

On Wed, 11 May 2022 at 09:15, Reuben Thomas wrote: > > I'm happy to prepare a patch in this case. I would simply remove all > mention of syntax tables, as that functionality is no longer available. > Attached. Here's the commit message to explain what I've done: Remove men

#ifdef emacs

Working on the regex documentation, I scanned gnulib for "#ifdef emacs", and found some instances (though not in the regex code). Should they be there? Mostly in alloca.c, with one case in parse-datetime.y. As far as I can see these are "native" gnulib modules, not maintained in sync with code

Re: regex documentation

On Wed, 11 May 2022 at 03:11, Bruno Haible wrote: > > I'd suggest to keep it. If we don't have time for a deep overhaul: please > just tell me which nodes of [1] have inaccurate information, and I'll add a > big warning "Note: The information on this page is out-of-date!" in each. > I would

Re: regex module has dropped support for syntax tables

On Wed, 11 May 2022 at 02:01, Paul Eggert wrote: > > > Failing that, you could also try GNU Emacs's regex implementation, which > >> is derived from GNU regex 0.12, and which may have fewer bugs than regex > >> 0.12. > > > > > > That's a good suggestion I hadn't thought of, thanks. I had a look

Re: regex module has dropped support for syntax tables

On Mon, 9 May 2022 at 20:29, Paul Eggert wrote: > On 5/8/22 15:54, Reuben Thomas wrote: > > > I sympathise if the gnulib maintainers don't want to reintroduce them; in > > that case, could their removal please be flagged up in the docs? > > Sure, I installed the attac

Re: regex module has dropped support for syntax tables

On Mon, 9 May 2022 at 02:53, Bruno Haible wrote: > Reuben Thomas asked: > > Also, do the maintainers have any better suggestion for what I should do > > than revert to GNU regex 0.12 for a2ps? > > AFAIU, regex syntax tables assume a 7-bit or 8-bit text encoding. But >

regex module has dropped support for syntax tables

I am working on GNU a2ps. I have tracked down a test failure to the lack of support for syntax tables in gnulib's regex module (removed by commit 151e40bb39 which switches from GNU regex 0.12 to the glibc version). This took me quite a long time to work out, since syntax tables are still

Re: rpl_free undefined

On Tue, 3 May 2022 at 03:24, Bruno Haible wrote: > > OK, so our effort from April 2021 to June 2021 fixed the problem; > recall that you initiated that through > . > OK, I will try to remember to make it an iron rule that I

Re: rpl_free undefined

On Mon, 2 May 2022 at 02:02, Bruno Haible wrote: > > I don't want to debug a gnulib version from more than 1 year ago, therefore > I'm using >./bootstrap --skip-git --gnulib-srcdir=$GNULIB_SRCDIR > (Argh. Why is this option not called --no-git, like in the other > 'bootstrap'?) > > Then I

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Mon, 2 May 2022 at 01:05, Bruno Haible wrote: > > We have documented hundreds of deficiencies of mingw [1] w.r.t. the POSIX > standard. MSYS is surely worse, not better, than mingw. I recommend to use > the respective modules, for those POSIX APIs that you use. > I'm happy to decide that on

Re: rpl_free undefined

On Sun, 1 May 2022 at 22:39, Bruno Haible wrote: > A link error is not a "minor" problem; it's a major one. > > More generally: How to reproduce? > Check out https://github.com/rrthomas/libpaper.git commit 8fe608f on MSYS Edit bootstrap.conf to remove the posix-free module ./bootstrap

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Sun, 1 May 2022 at 22:34, Bruno Haible wrote: > Reuben Thomas wrote: > > It's not really that I'm doing anything: gnulib seems to detect MSYS as > > being a POSIX platform. > > Not really; something in the configure step (which you haven't shown) > made it "detect

Re: setlocale with NULL locale (to read current locale) segfaults on MSYS

On Sat, 30 Apr 2022 at 12:44, Bruno Haible wrote: > Reuben Thomas wrote: > > on MSYS it goes wrong > > ... > > setlocale_null_with_lock (category=category@entry=0, buf=buf@entry > =0xbd80 > > "", bufsize=bufsize@entry=3221) at setlocale_null.c:228 >

setlocale with NULL locale (to read current locale) segfaults on MSYS

It works fine on mingw32 and mingw64, but on MSYS it goes wrong when calling pthread_mutex_lock. In the following gdb session, the first line is from my code; the rest is tracing through gnulib code. (gdb) n 171 char *old_locale = setlocale(LC_ALL, NULL); (gdb) s rpl_setlocale

Misleading --help for git-version-gen

Just noticed that it says: "Running without arguments will suffice in most cases." However, there is a mandatory argument! -- https://rrt.sc3d.org

[Bug 1700419] Re: caffeine 2.9.7 isn't working on Ubuntu 20.04

** Changed in: caffeine Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1700419 Title: caffeine 2.9.7 isn't working on Ubuntu 20.04 To manage notifications

[Bug 1966674] Re: Files install directly into /usr

Sorry, Andrej, I just changed the status of the Ubuntu bug by mistake, instead of the upstream one, and Launchpad won't let me change it back! ** Changed in: caffeine (Ubuntu) Status: In Progress => Fix Released ** Changed in: caffeine Status: New => Fix Committed -- You received

[Bug 1964469] [NEW] Changes file extension when shared to phone

Public bug reported: When I share a file whose extension is '.asc' it ends up on the phone as '.txt'. This is confusing: I exported my encryption keys from DeltaChat desktop, shared them to my phone, and was then unable to import them into DeltaChat on the phone (which was expecting '.asc'). **

Re: DD(s) to help DM land some long-overdue package updates?

On Fri, 4 Feb 2022 at 14:30, Reuben Thomas wrote: > > Having just now got the new Debian packaging building without error, I > shall now follow the ITS procedure and see what happens! > I have waited 8 days since posting debdiffs, and had no response, so I've now filed an ITS b

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 22:34, Reuben Thomas wrote: > On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote: > > > > I suggest this path: > > > > Send bug reports with your debdiff proposals for each package. If 8 days > > after you get no reply from th

hello-2.12 released [stable]

I’m happy to announce a minor update to 2.11. There are no code changes. Here are the compressed sources and a GPG detached signature[*]: https://ftpmirror.gnu.org/hello/hello-2.12.tar.gz https://ftpmirror.gnu.org/hello/hello-2.12.tar.gz.sig Use a mirror for higher download bandwidth:

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

On Mon, 31 Jan 2022 at 18:43, Reuben Thomas wrote: > > Thanks! I'll make a new release. I've released 2.12. -- https://rrt.sc3d.org

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

On Mon, 31 Jan 2022 at 18:37, Sergei Trofimovich wrote: > Your varian of atext-1 works on musl for me. Thank you! Thanks! I'll make a new release. -- https://rrt.sc3d.org

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

Thanks very much for the analysis and suggested patch. I don't think however that a code change is needed. Arguably, the correct fix would be to check the return value of wprintf, but in fact close_stdout() already checks if there was a previous error on the stream. I think that arbitrarily

Re: hello-2.11 fails multibyte-1 and atexit-1 on musl

On Wed, 26 Jan 2022 at 12:59, Sergei Trofimovich wrote: > Thanks for the report! > From what I understand at > > https://wiki.musl-libc.org/functional-differences-from-glibc.html#Character-sets-and-locale > musl deliberately supports any char -> wchar_t (and back) conversion for > any char

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Thu, 20 Jan 2022 at 13:24, Ryan Schmidt wrote: > If gnulib starts requiring a compiler newer than Apple gcc 4.2.1, that will > be problem for MacPorts on 10.6 and earlier. We might be able to bootstrap > our way to a newer compiler, but that wouldn't be possible if the newer > compiler or

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 20:56, Jeffrey Walton wrote: > > If you are OS X 10.8 and above, then you will likely be using Apple > Clang (or LLVM Clang), and you likely won't have troubles. > > OS X 10.6 switched to llvm-gcc. It should not have a problem with > inline.

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 18:38, Paul Eggert wrote: > > I'm not sure a newer compiler would fix the bugs, as they're typically > present in the ctype.h supplied by the OS. If the newer compiler comes > with a fixed ctype.h you're OK; if it reuses or copies the old ctype.h > you'll have a problem. I

Re: Broken "make distcheck" with automake 1.16

On Tue, 18 Jan 2022 at 14:51, Bruno Haible wrote: > > This has been fixed on 2022-01-08. Many thanks, sorry for the noise! -- https://rrt.sc3d.org

Broken "make distcheck" with automake 1.16

Building Recode[1], which uses a recent gnulib (commit 035ce56a33 of 5th January 2022), I find that when I run "make distcheck", some .deps/*.Plo files generated by the build are not removed by any clean rule, leading "make distcheck" to report: ERROR: files left in build directory after

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Tue, 18 Jan 2022 at 01:58, Ryan Schmidt wrote: > MacPorts itself still runs on Mac OS X 10.4 and later and we do still have a > number of users using older systems. More so than with other operating > systems, I think, Mac users care about support for older OS versions because > Apple

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 22:22, Reuben Thomas wrote: > > On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote: > > > > Although the workaround still functions on current macOS, it's better to > > use proper inline functions when available so I installed the attached > >

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 22:14, Paul Eggert wrote: > > Although the workaround still functions on current macOS, it's better to > use proper inline functions when available so I installed the attached > patch into Gnulib. Please give it a try. Thanks, I will. > I don't know whether the macOS

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 17:41, Paul Eggert wrote: > > Could you give complete instructions from scratch, to reproduce the > config.h that has this problem? Without that, it'll be hard for us to > understand or fix the problem. Sorry, I've failed to explain the problem clearly (or maybe there's a

Re: _GL_EXTERN_INLINE not defined correctly in config.h for macOS

On Mon, 17 Jan 2022 at 12:37, Bruno Haible wrote: > > Please, to help us reproduce the issue and verify a potential fix: > How to reproduce the issue? I.e. What did you try to do, and what were > the resulting diagnostics? $ gcc -dM -E config.h | grep GL_EXTERN #define _GL_EXTERN_INLINE static

_GL_EXTERN_INLINE not defined correctly in config.h for macOS

The definition of _GL_EXTERN_INLINE relies, on macOS, on __header_inline, which is not a compiler built-in, but is defined in sys/cdefs.h. Therefore, __header_inline is not defined when config.h is included, and the tests always assume, on macOS, that the compiler is buggy and does not support

Re: Time for a new release of GNU hello?

On Fri, 7 Jan 2022 at 20:45, Reuben Thomas wrote: > > This is correct. I'm mid-flight in submitting my current GPG key to > ftp-uplo...@gnu.org. Once I have completed the process I'll make a > release and help Sami if he needs it. I've released hello 2.11. Sami, if y

Re: Time for a new release of GNU hello?

On Fri, 7 Jan 2022 at 20:37, Bob Proulx wrote: > > Surely GNU Hello releases are made to https://ftp.gnu.org/gnu/hello/ > not to Savannah. That's handled by the FSF entirely. Savannah is not > involved in official GNU Project releases at all. This is correct. I'm mid-flight in submitting my

Time for a new release of GNU hello?

The current release was in 2014, and is signed with a GPG key that has since expired. Please could we have a new release? There have been plenty of improvements since then. -- https://rrt.sc3d.org

Re: Not a Big Thing But ...

On Mon, 3 Jan 2022 at 20:27, Reuben Thomas wrote: > > This particular one is my fault, I think: it's an old GPG key of mine. Not > sure why it would no longer be available though; I don't think I ever revoked > it. Any ideas? I'm very much at the "following HOWTOs and hoping

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 20:55, Wookey wrote: > > Hi Rebuen. I helped you with the last libpaper refurbishment in > 2012-2014. Happy to do that again, although as people have pointed out > complete rewrites are not really NMU material and we should follow the > salvage process. > > Well done for

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 20:43, Pierre-Elliott Bécue wrote: > > I suggest this path: > > Send bug reports with your debdiff proposals for each package. If 8 days > after you get no reply from the maintainer, file an ITS against the > packages for which you got no reply. > > If at the end of the

Re: DD(s) to help DM land some long-overdue package updates?

On Sat, 1 Jan 2022 at 19:48, Boyuan Yang wrote: > > That being said, while providing a list onto debian-devel is not a bad idea, > https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging > should be the correct choice. For a specific example, I just spotted >

DD(s) to help DM land some long-overdue package updates?

I'm a long-term Debian user and upstream maintainer, and a DM. I'm working to package updates to mature packages. All of them have maintainers who are at best sporadically responsive—I do not blame them! I'm sure they're all hugely overworked. (I'm also upstream for several packages with

Bug#996894: colordiff: Error messages interrupt output

Package: colordiff Version: 1.0.18-1 Severity: normal Error messages are not correctly interleaved with output; for example: -Foo diff: bar/baz.html+Bar : No such file or directory Here, the error message should say diff: bar/baz.html: No such file or directory but the (presumably stderr)

[Bug 1412687] Re: Caffeine 2.8.3 doesn't work automatically for hibernate/suspend mode.

Hi paulw2u: I think the bug should be marked either invalid or upstream. I'm not sure it was ever demonstrated in xdg-screensaver, but if there is a bug, it's almost certainly in xdg-utils. Certainly no fix was ever made in Caffeine. -- You received this bug notification because you are a member

[Bug 1412687] Re: Caffeine 2.8.3 doesn't work automatically for hibernate/suspend mode.

You're right, @paulw2u, I think this bug can be closed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1412687 Title: Caffeine 2.8.3 doesn't work automatically for hibernate/suspend mode. To manage

Bug#991340: ukui-polkit: Package description is hard to understand

Package: ukui-polkit Version: 1.2.1-1 Severity: normal The package description doesn’t make sense: “The ukui-polkit package supports general authentication and biometric authentication that the service is provided by the biometric-auth package. “ The problem is the words

zile-2.6.2 released [stable]

I'm happy to announce a new release of GNU Zile, the minimal Emacs clone. This release fixes a serious bug introduced in the 2.6 series, where visiting a file containing no newlines would cause an immediate crash. Apologies for this, and thanks to Martin Thierer for reporting it. Here are the

[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions

Reuben Thomas added the comment: D'oh! Sorry for the noise. And congratulations to the author/designer of `RawDescriptionHelpFormatter` for designing/implementing exactly what I wanted all along! -- resolution: -> not a bug stage: -> resolved status: open -&g

[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions

Reuben Thomas added the comment: (Tested with Python 3.9.4.) -- ___ Python tracker <https://bugs.python.org/issue43942> ___ ___ Python-bugs-list mailin

[issue43942] RawDescriptionHelpFormatter seems to be ignored for argument descriptions

New submission from Reuben Thomas : The documentation seems very clear on this subject: "RawTextHelpFormatter maintains whitespace for all sorts of help text, including argument descriptions. However, multiple new lines are replaced with one." But consider the following code:

[issue43875] glob.glob with ** does not always detect symlink loops

Change by Reuben Thomas : -- title: path.glob with ** does not always detect symlink loops -> glob.glob with ** does not always detect symlink loops ___ Python tracker <https://bugs.python.org/issu

[issue43875] path.glob with ** does not always detect symlink loops

Change by Reuben Thomas : -- components: +Library (Lib) versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue43875> ___ ___ Python-bugs-list m

[issue43875] path.glob with ** does not always detect symlink loops

New submission from Reuben Thomas : Example session: $ mkdir foo $ cd foo $ ln -s .. bar $ ln -s .. baz $ python3.9 Python 3.9.0+ (default, Oct 20 2020, 08:43:38) [GCC 9.3.0] on linux Type "help", "copyright", "credits" or "license" for more informa

Re: Interference between two installations of gnulib

On Sun, 11 Apr 2021 at 20:32, Bruno Haible wrote: > > Having two separate configure scripts is undesirable, because that would > increase the total configure time of the package (and people have already > complained about the configure time). > > The same problem is seen also in GNU gettext and

Interference between two installations of gnulib

I have made two installations of gnulib in a project, because I am using both relocatable-prog and relocatable-lib-lgpl. I have different modules installed for each, of course. I just had a problem where my library would not compile, because it was missing setlocale_null.h. GNULIB_SETLOCALE_NULL

Typo in relocatable-maint.texi?

In the following text, describing how to use multiple gnulib installations: Correspondingly for the programs you will have to add something like this: ... AM_CPPFLAGS = -I$(top_srcdir)/src/gnulib -I$(top_builddir)/src/gnulib ... LIBADD =

Re: Using relocatable-prog with relocatable libraries

On Fri, 9 Apr 2021 at 11:18, Reuben Thomas wrote: > On Fri, 9 Apr 2021 at 02:41, Ben Pfaff wrote: > >> Do you think it should be better documented, or documented somewhere >> else? (I'm only getting to my email now.) >> > One practical reminder that would be useful

Re: Using relocatable-prog with relocatable libraries

On Fri, 9 Apr 2021 at 02:41, Ben Pfaff wrote: > On Mon, Apr 5, 2021 at 3:43 PM Reuben Thomas wrote: > > > > On Mon, 5 Apr 2021 at 23:36, Reuben Thomas wrote: > >> > >> > >> The comment about "all the copies of relocatable.c" in progreloc.c

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 23:36, Reuben Thomas wrote: > > The comment about "all the copies of relocatable.c" in progreloc.c is > surely is clue, but I cannot see how more than one copy of relocatable.c is > ever compiled… > Finally found, in relocatable-maint.texi, &

Re: Using relocatable-prog with relocatable libraries

On Mon, 5 Apr 2021 at 22:55, Reuben Thomas wrote: > > Have I missed something? I was surprised that I hadn't come across this > problem before, but I found that I've used relocatable-lib-lgpl before, but > not relocatable-prog (because in fact I was working with an LGPL

Using relocatable-prog with relocatable libraries

I use relocatable-prog in a project which builds a binary that links against a library which itself is installed publicly. Therefore, I build gnulib with -DIN_LIBRARY. This causes gnulib to be built with a static copy of compute_curr_prefix, named local_compute_curr_prefix. Therefore, when

zile-2.6.1 released [stable]

I am delighted to announce the first in a new stable release series of Zile. This version should be just like the last for users, but has been completely rewritten in Vala, for easier maintenance. I hope this will allow me to keep maintaining Zile for the foreseeable future with less work.

Bug#149873: mmv: Options for dealing with this problem

Thanks, Axel for your kind words, and also for your analysis. I've had a look at renameutils, of which I was not aware, though I have it installed on my machine already! It seems to me that it covers interactive usage neatly, so I'd be happy to remove that from mmv, retaining the -n flag, but

Bug#149873: mmv: Options for dealing with this problem

Package: mmv Version: 1.01b-19build1 Followup-For: Bug #149873 Hi, I’m the (new) upstream maintainer of mmv, and I would like to fix this problem. Clearly, it is not possible to fix in a backwards-compatible way, so I see a few options: 1. Fix it in a backwards-incompatible way. For an

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 10:06, Bruno Haible wrote: > Hi Reuben, > > > Unfortunately, this doesn't help, because pathconf is not present on > mingw. > > Then use some fallback, e.g. 256 or PATH_MAX. > > > So the best I can do is #define _POSIX_ to get the value of NAME_MAX that > > it has. > >

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:16, Reuben Thomas wrote: > On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > >> Hi Reuben, >> >> > NAME_MAX is defined in limits.h. >> >> No. POSIX [1] specifies that it may be omitted from , and >> that pathconf (_PC_NAM

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > > I don't see anything Gnulib should do here. > Having looked into this, it seems that the same issues apply to PATH_MAX, yet gnulib has a pathmax module to define PATH_MAX. What's different in that case? -- https://rrt.sc3d.org

Re: NAME_MAX on MingW

On Mon, 8 Mar 2021 at 00:14, Bruno Haible wrote: > Hi Reuben, > > > NAME_MAX is defined in limits.h. > > No. POSIX [1] specifies that it may be omitted from , and > that pathconf (_PC_NAME_MAX) is the right way to access the maximum > length of a file name component. [2] > Ah, thanks for

NAME_MAX on MingW

NAME_MAX is defined in limits.h. And indeed it is there on Mingw, but guarded by the Windows-specific non-standard macro _POSIX_. I found this suggestion that Windows system headers have not used _POSIX_ since MSVC 2013: https://sourceforge.net/p/mingw-w64/mailman/message/33014416/ However, the

<    1   2   3   4   5   6   7   8   9   10   >