Re: [PROPOSED 0/4] memset_explicit patches

Paul Eggert writes: > Here's a proposed set of patches to add support for C23's > memset_explicit function, along with the corresponding fallout in > Gnulib. The idea is to prefer memset_explicit, but continue to > support explicit_bzero (which is not marked as obsolescent, as it's > too soon

explicit_bzero and -std=c99

no, what is the better idiom to use here instead of explicit_bzero? Other thoughts? /Simon Simon Josefsson via Discussion list for GNU Libtasn1 writes: > Vincent Fortier writes: > >> While preparing a gnutls update I ended-up updating libtasn1 from >> 4.16. Going to 4.17 works but

Re: Build issue since version 4.18 using gcc-4.9

Vincent Fortier writes: > While preparing a gnutls update I ended-up updating libtasn1 from > 4.16. Going to 4.17 works but anything after that fails with: Thanks for the report! I can reproduce this using: ./configure ac_cv_func_explicit_bzero=no CPPFLAGS="-std=c99" In other words, the

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

Thanks, I have reported this to pkgconf upstream: https://github.com/pkgconf/pkgconf/issues/278 /Simon signature.asc Description: PGP signature

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

Thanks, I have reported this to pkgconf upstream: https://github.com/pkgconf/pkgconf/issues/278 /Simon signature.asc Description: PGP signature

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

tor 2022-11-17 klockan 10:38 +0100 skrev Sebastian Ramacher: > On 2022-11-17 08:57:12 +0100, Simon Josefsson wrote: > > ons 2022-11-16 klockan 23:55 +0100 skrev Sebastian Ramacher: > > > Source: libgssglue > > > Version: 0.7-1 > > > Severity: serious >

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

tor 2022-11-17 klockan 10:38 +0100 skrev Sebastian Ramacher: > On 2022-11-17 08:57:12 +0100, Simon Josefsson wrote: > > ons 2022-11-16 klockan 23:55 +0100 skrev Sebastian Ramacher: > > > Source: libgssglue > > > Version: 0.7-1 > > > Severity: serious >

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

ons 2022-11-16 klockan 23:55 +0100 skrev Sebastian Ramacher: > Source: libgssglue > Version: 0.7-1 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgssglue/28379714/log.gz > > Removing autopkgtest-satdep (0) ... >

Bug#1024278: libgssglue: autopkgtest failure with pkgconf

ons 2022-11-16 klockan 23:55 +0100 skrev Sebastian Ramacher: > Source: libgssglue > Version: 0.7-1 > Severity: serious > X-Debbugs-Cc: sramac...@debian.org > > https://ci.debian.net/data/autopkgtest/testing/amd64/libg/libgssglue/28379714/log.gz > > Removing autopkgtest-satdep (0) ... >

[PATCH] vc-list-files-tests: Avoid OpenPGP private key operations.

been a harmless one). I think this behaviour should generally be considered a bug. I wonder if there are more examples of this hidden deep inside scripts. /Simon From 0ab73798b5bc703233195c1d37f96d977fc26ad8 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Sun, 13 Nov 2022 11:50:51 +0100

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Rene Engelhard writes: > Committed and uploaded. Thank you! > (Though I needed to add the diff to the source package, building > directly from the git checkout gave me: ... > /bin/bash: line 1: ./gdoc: No such file or directory I'm not sure how you built it, but from the error it looks like

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Rene Engelhard writes: > Committed and uploaded. Thank you! > (Though I needed to add the diff to the source package, building > directly from the git checkout gave me: ... > /bin/bash: line 1: ./gdoc: No such file or directory I'm not sure how you built it, but from the error it looks like

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Thank you -- the CI/CD caught this on ArchLinux before reading your email, and it is fixed now. Feel free to upload a new Debian package with your fix or the official one, and also feel free to push fixes to https://salsa.debian.org/debian/oath-toolkit

Bug#1023038: Acknowledgement (oath-toolkit: FTBFS with xmlsec1 1.2.35)

Thank you -- the CI/CD caught this on ArchLinux before reading your email, and it is fixed now. Feel free to upload a new Debian package with your fix or the official one, and also feel free to push fixes to https://salsa.debian.org/debian/oath-toolkit

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Simon Josefsson writes: > Would you like to make a new release? Hi Ludovic, I pushed out 3.7.10 to improve maintainer rules a bit. Would you like to make a 3.7.11 shortly? To test the release process and get your OpenPGP key into distributions' keyring. I'm hoping the process is jus

[gnutls-help] guile-gnutls-3.7.10 released [stable]

: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg

Re: [PATCH] maintainer-makefile: Fix Apple Xcode 'make syntax-check'.

ion -- q > Usage: grep -hblcnsviw pattern file . . . > > The portable alternative is > grep 'GNU indent' > /dev/null Thank you! I installed these two fixes, which caught the unportable usages in scripts for some packages. /Simon From 4555e788613f1f5d1e8519427591bef3274d3124 Mon Sep 17 0

[PATCH] maintainer-makefile: Fix Apple Xcode 'make syntax-check'.

Hi. I installed this to let 'make syntax-check' on Mac OS succeed, I don't think it is useful to use non-GNU indent. /Simon From 4ad0eedf4ff8d294a10c20b8945d0e59aa8141db Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Mon, 31 Oct 2022 09:42:42 +0100 Subject: [PATCH] maintainer-makefile

inetutils-2.4 released [stable]

] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate

[PATCH] gendocs: Output timestamp in English.

S= LC_ALL= LANGUAGE= date '+%B %d, %Y' October 25, 2022 jas@latte:~/src/gnulib$ The attached patch fixes this. /Simon From 1575cb2bb925bd0b4bd160e06e05d39303c5cca5 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Tue, 25 Oct 2022 23:39:15 +0200 Subject: [PATCH] gendocs: Output timestamp in Engli

inetutils-2.4 released [stable]

] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command. gpg --locate

Re: Fwd: freeport(1)

Hi Thanks for the contribution. Given the simplicity of this tool, together with the inherent race condition, and the availability of a shell script that offers similar functionality suggested by Alex Colomar in a reply, my preference is that it is not worth the maintenance burden to introduce a

Re: [PATCH] ifconfig: Support prefix length.

I have committed this patch here: https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=afe3168ee9f15783c71653bee0ec97536daaf217 Btw, please add NEWS entries next time. I added the following, corrections welcome:

Re: [PATCH] ifconfig: Support prefix length.

I have committed this patch here: https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=afe3168ee9f15783c71653bee0ec97536daaf217 Btw, please add NEWS entries next time. I added the following, corrections welcome:

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Hi. I have commited this now: https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=0b35abbd7a5d074c7e245a49585b2de036d4dec7 /Simon signature.asc Description: PGP signature

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Hi. I have commited this now: https://git.savannah.gnu.org/cgit/inetutils.git/commit/?id=0b35abbd7a5d074c7e245a49585b2de036d4dec7 /Simon signature.asc Description: PGP signature

libidn2-2.3.4 released [stable]

and the corresponding tarball. Then, run a command like this: gpg --verify libidn2-2.3.4.tar.gz.sig The signature should match the fingerprint of the following key: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson If that command fails

Re: getdelim: Work around buggy implementation on macOS 10.13

Bruno Haible writes: > While testing a GNU sed snapshot on macOS 10.13, I see this test failure: ... > ==85029== Invalid read of size 16 ... > An out-of-bounds read. Oh oh. When I reconfigure and recompile with the > environment variable > gl_cv_func_working_getdelim=no > this test succeeds.

Re: [exim] Thread-Index header too long

Heiko Schlittermann via Exim-users writes: > Heiko Schlittermann (Mo 17 Okt 2022 23:58:03 CEST): >> how do you deal whith incoming messages having a Thread-Index header (an >> other header indicates that the originating MUA was MS Outlook 16.0) >> with about 1200 chars. > > To be more precise:

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Ludovic Courtès writes: > I’ve prepared the Guix package (will push soon) and it went smoothly. > > Two things we could/should do: > > 1. LT_INIT([disable-static]) because it doesn’t make sense to build .a > files—pushed as 006d53214a7fd2bf2ef04acecde89f6ae4fdfb3d; Thanks, I didn't

Re: stdbool module unconditionally #define true

Bruno Haible writes: > Paul Eggert wrote: >> > Shouldn't the following cause a compilation error? >> > >> > root@18544d251872:/# cat>foo.c >> > int main (void) { >> > int true = 42; >> > return true; >> > } >> >> Yes if you have a C23 compiler, which GCC 12 isn't. To get a proper >>

Re: stdbool module unconditionally #define true

Bruno Haible writes: > Simon Josefsson wrote: >> rlogind.c: In function 'rlogind_mainloop': >> rlogind.c:1112:7: error: expected identifier or '(' before numeric constant >> 1112 | int true; >> | ^~~~ >> >> The file does not include s

stdbool module unconditionally #define true

Hi. Upgrading gnulib in inetutils causes a build failure: rlogind.c: In function 'rlogind_mainloop': rlogind.c:1112:7: error: expected identifier or '(' before numeric constant 1112 | int true; | ^~~~ The file does not include stdbool.h. Apparently this has worked for many years

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Andreas Metzler writes: > I just quickly ported the Debian packaging (excluding any copyrigght > checks) and it looked reasonable. Thank you for testing! > Nitpicks: > Supporting ./configure --disable-guile don't build GNU Guile bindings > does not make a lot of sense. > > I am not

[gnutls-help] Guile-GnuTLS 3.7.9

Guile-GnuTLS provides Guile bindings for the GnuTLS library, see https://gitlab.com/gnutls/guile for more information. The release is available here: https://gitlab.com/gnutls/guile/-/releases/v3.7.9 The following OpenPGP-signed tarballs are available:

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Simon Josefsson writes: > I'll move it to https://gitlab.com/gnutls/guile/ and release as 3.7.9 > within a few days, but I'm happy to include any fixes you would like to > see go into it. We can always fix more things after the release too. I > am aware of the following nits: &g

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Hi I have created https://gitlab.com/jas/guile-gnutls/ now that appears to build: https://gitlab.com/jas/guile-gnutls/-/pipelines/663945143 Could you please test the following tarball as if it were a new release of the new guile-gnutls project?

Re: "git-version-gen" prints "Print a version string." three times

Bjarni Ingi Gislason writes: > "sh -x build-aux/get-version-gen" outputs: I don't think that's a bug -- running the script under 'sh -x' is not a supported by of invoking it, but a way to invoke shell debugging of the script. I don't see anything unexpected in the debug output, it doesn't

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Ludovic Courtès writes: >> git clone https://gitlab.com/gnutls/gnutls.git guile-gnutls >> cd guile-gnutls/ >> git-filter-repo --path configure.ac --path .gitignore --path >> doc/.gitignore --path README.md --path doc/ --path guile/ --path >> Makefile.am --path m4/guile.m4 --path NEWS >> git

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

Andreas Metzler writes: > On 2022-10-07 Simon Josefsson wrote: > [...] >> One question is about version numbers.. it should probably have its own >> version number, right? Would starting at 0.0.0 be a problem for >> packaging, or should we start with 3.7.8

Re: [gnutls-help] Guile-Gnutls bindings to separate git repo?

> > I’m fine having it as a sub-project under gitlab.com/gnutls.  > Otherwise, > if it’s not a sub-project, it can just as well be on notabug.org say. > > Building the new repo will require ‘git filter-branch’ magic to get > guile/, doc/, and maybe configure.ac bits. Now there is

[gnutls-help] Guile-Gnutls bindings to separate git repo?

Hi The GnuTLS developers talked about separating the Guile bindings for GnuTLS into a separate git repository, with the advantages being 1) simplify core GnuTLS maintenance and reduce complexity, 2) allow a separate release schedule for guile-gnutls. What do you think? Is there any disadvantage

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Samuel Thibault writes: > Hello, > > Simon Josefsson, le mer. 28 sept. 2022 13:46:52 +0200, a ecrit: >> have you signed copyright assignment papers for InetUtils, > > I didn't know there was copyright assignment for InetUtils :/ > > I now have sent the form to the cler

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Both your patches looks good to me -- however, have you signed copyright assignment papers for InetUtils, or how are these contributed? Generally I'm not sure how useful it is to require copyright assignment for smaller InetUtils contributions -- the majority of the code is not copyright by FSF

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Samuel Thibault writes: > Hello, > > Simon Josefsson, le mer. 28 sept. 2022 13:46:52 +0200, a ecrit: >> have you signed copyright assignment papers for InetUtils, > > I didn't know there was copyright assignment for InetUtils :/ > > I now have sent the form to the cler

Re: [PATCH] ifconfig hurd: Notify pfinet of interfaces

Both your patches looks good to me -- however, have you signed copyright assignment papers for InetUtils, or how are these contributed? Generally I'm not sure how useful it is to require copyright assignment for smaller InetUtils contributions -- the majority of the code is not copyright by FSF

Re: [gnutls-help] planning meeting

Daiki Ueno writes: > Alexander Sosedkin writes: > >> Quoting zfrid...@redhat.com (2022-09-20 13:39:27) >>> Hello, >>> >>> I will attend the meeting as well. My preferred date and time would be for >>> instance 4.10. or 27.9. around 9:30 - 12:00 in the morning (Czech, Brno >>> time). >>> But any

Re: How to check for perl or usable printf tools?

Erik Auerswald writes: > Hello Simon, > > On 25.09.22 11:19, Simon Josefsson wrote: >> Erik Auerswald writes: >> >>> Hi all, >>> >>> On Mon, Sep 12, 2022 at 12:45:32PM +0200, Erik Auerswald wrote: >>>> On Mon, Sep 12, 2022 at 05:16

Re: How to check for perl or usable printf tools?

;> binary input from the fuzzer. > > I have just done this, see commit d3270b73ecf1207d30d852ecc50119cbc4422464. Thank you! I committed some minor fixes to make CI/CD build, see https://gitlab.com/jas/inetutils/-/pipelines/ /Simon From e1a74879088865d9bb01ac7a61ded2b5ecc13fdf Mon Sep 17 00

Bug#1020542: inetutils: telnet[d] descriptions: suggest different alternative packages

Guillem Jover writes: > Control: tag -1 moreinfo > > Hi! > > On Fri, 2022-09-23 at 02:20:21 +0200, Bastian Germann wrote: >> Source: inetutils >> Version: 2:2.3-5 >> Severity: wishlist >> Control: block 1018949 by -1 > >> To help with #1018949 (netkit-telnet: Drop in favour of

Bug#1018949: netkit-telnet: Drop in favour of netkit-telnet-ssl

Bastian Germann writes: > Am 09.09.22 um 12:57 schrieb Simon Josefsson: >>> Just to be clear on this: There is one thing that you need to do to >>> enable clear-text use of in.telnetd: >>> It needs the command line argument -z nossl. This should be stated in >>

Re: lib/malloca.c: warning about [-Wsign-compare]

similar comment to the manual: it is handy with a reference for people like me who cannot remember all different warning flags and whether they are generally useful or not. /Simon From 54c09c98a67219ba2cf70c4bb23f80990db37066 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Fri, 23 Sep 2022 09:06:22 +02

Bug#959190: gssproxy: Log flooded by gssproxy

Hi I'm trying to understand this bug report -- my reading is that there is excessive debug messages in the log, but they go away if you disable debug logging. Is that right? I think that is expected, and also that debug logging is disabled by default. Am I missing something here? /Simon

Bug#950518: gssproxy: segfault when debug is enabled

Hi. I can't reproduce this with 0.8.2-2 nor recent 0.9.1-1, can you show me your other /etc/gssproxy/*.conf? I suspect they are triggering something. See my attempt to reproduce your problem below. /Simon root@latte:~# tail -v -n +1 /etc/gssproxy/*.conf ==> /etc/gssproxy/80-httpd.conf <==

Re: fixing the ftp crashes found via fuzzer

Erik Auerswald writes: > I'll try to commit and push regression tests and fixes for the first, > third, and fourth problem during the weekend. Thank you. > What do you all think regarding recursive macros (the second problem)? Having an arbitrary sized recusion limit of, say, depth 100, while

Re: [gnutls-help] planning meeting

o time). > But any day in the upcoming weeks would do unless it's a holiday or a > weekend. > > Regards, > Zoltan > > On Mon, Sep 19, 2022 at 12:51 PM Daiki Ueno wrote: > > Simon Josefsson writes: > > > > > I could try to attend, is the approach

Re: [gnutls-help] planning meeting

Hi I could try to attend, is the approach to meetings documented anywhere? Irc, chat, video, telephone, etc? Maybe that could be one agenda item :) /Simon Daiki Ueno writes: > Hello, > > Simon's post[1] on gnutls-help reminded me that it might be time for a > new branch (i.e., 3.8.x), as it

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

Jim Meyering writes: > This would be an envvar for which we do not commit to any level of > support in future releases. Would the envvar be documented? Would it be a deprecated feature, with a removal plan? It seems we traded removing [ef]grep into introducing new unsupported features which

Re: Possible draft non-free firmware option with SC change

Lucas Nussbaum writes: > On 13/09/22 at 14:49 +0200, Simon Josefsson wrote: >> Lucas Nussbaum writes: >> >> > Right. I think that it's important to realize that the FSF and Debian >> > use different tactics to promote Free Software. The FSF focuses o

Re: Possible draft non-free firmware option with SC change

Lucas Nussbaum writes: > Right. I think that it's important to realize that the FSF and Debian > use different tactics to promote Free Software. The FSF focuses on > promoting a clean ideology to the point of ignoring practical problems. > The risk is becoming irrelevant, because very few people

Re: Possible draft non-free firmware option with SC change

Tobias Frost writes: > On Tue, Sep 13, 2022 at 07:29:05AM +0200, Simon Josefsson wrote: > >> My reason for using Debian is that I can rely on getting a 100% free >> system, and then add non-free works on top of it when I chose to do so. >> >> For example,

Re: Possible draft non-free firmware option with SC change

Ansgar writes: > Hi, > > On Mon, 2022-09-12 at 21:03 +0200, Simon Josefsson wrote: >> My experience is the same as you describe, with the free installer: >> if you pick the right hardware, Debian works directly today. > > By "right hardware", I assume you

Re: Possible draft non-free firmware option with SC change

Thanks for long post, thoughtful and I only have a reflection left: >> Okay. But given a situation when someone comes to you with a hardware >> component that requires non-free software to work, and asks you to >> install Debian on it, would you resolve that by > >>1) install the free Debian

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> I recall that it took ~5 years until hardware (usually audio, video, >> network cards) was well supported with stable releases of free software >> distributions in the 1990's. Often it was never possible to get

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> Thanks -- this helps me understand the two principles at play here: > >> 1) having a free Debian > >> 2) having a Debian that works on as much hardware as possible > > This summary is moving in the righ

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: > Many common laptops in the last 5-10 years don't come with wired > ethernet; it's becoming rarer over time. They ~all need firmware > loading to get onto the network with wifi. Many now need firmware for > working non-basic video, and audio also needs firmware on some of

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: >>I think the difference of opinion is that your proposal is based on the >>argument that it is worth compromising on the ideals of free software in >>order to allow users to be able to run free software. I disagree with >>that opinion. If you disagree with my

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > I think it is possible to argue in good faith that the Debian installer is > not part of the Debian system as defined in SC 1. I would not personally > make that argument, but I don't think it's an unreasonable argument to say > that the Debian system is the packages in

Summarizing options

: > On Sun, 2022-09-11 at 10:28 +0200, Simon Josefsson wrote: > >> * Would it prevent the current presentation of the non-free installer? >> tl;dr: No >> * Would it prevent the alternative presentation suggested in >> https://lists.debian.org/msgid-search/683a7c0e69b08

Re: maint.mk: public-submodule-commit rule is broken

Btw, see my concerns with this code earlier here: https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00040.html https://lists.gnu.org/archive/html/bug-gnulib/2022-08/msg00044.html Instead of the patch, I have merely disabled it when I ran into issues, since it doesn't add value for me and

Re: How to check for perl or usable printf tools?

Erik Auerswald writes: > I am trying to use the reported input file that crashes tftp for the test. > This file contains non-printable characters (i.e., it is a "binary" file). > I do not want to add this binary file as-is to the git repository. Why? I don't see anything fundamentally wrong

Re: Changing how we handle non-free firmware

I was asked offlist to answer how Proposal D would affect the display of the non-free installer on Debian websites, and in particular: * Would it prevent the current presentation of the non-free installer? tl;dr: No * Would it prevent the alternative presentation suggested in

Re: Possible draft non-free firmware option with SC change

Paul Wise writes: > On Sat, 2022-09-10 at 09:16 +0200, Simon Josefsson wrote: > >> So the practical problems facing people requiring non-free software >> appears solved or possible to solve. > > As I understand it there are two problems solved by proposal A/E: &g

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Simon Josefsson writes: > >> No, not like now. Today we and our users can chose to download non-free >> content if they want. Some do. Some don't. With Steve's proposal, as >> I understand it, that choice will be taken away. > > S

Re: Possible draft non-free firmware option with SC change

Andrey Rahmatullin writes: > On Fri, Sep 09, 2022 at 09:16:48AM +0200, Simon Josefsson wrote: >> With your proposal, Debian 'main' would still consists of free content, >> but to practically install and run any of it, we and our users would >> have to download non-free co

Re: Changing how we handle non-free firmware

Bart Martens writes: > Yes, let's do that, thanks. So here is the adapted proposal C: > > = > > The Debian project is permitted to make distribution media (installer images > and live images) containing non-free software from the Debian archive > available > for

Re: Possible draft non-free firmware option with SC change

Steve McIntyre writes: > On Thu, Sep 08, 2022 at 05:22:58PM +0200, Simon Josefsson wrote: >>Simon Richter writes: >> >>> The reason I'm in favor of changing the SC is not that I believe it to >>> be a good thing, but that I think we need to stay relevant fo

Re: Possible draft non-free firmware option with SC change

Simon Richter writes: > The reason I'm in favor of changing the SC is not that I believe it to > be a good thing, but that I think we need to stay relevant for running > on actual hardware, and changing the SC now is the only way to do so > given that the actual hardware is non-free. What has

Re: TFTP client crash seems to be caused by missing bounds check in makeargv()

Erik Auerswald writes: > Hi Simon, > > On Tue, Sep 06, 2022 at 08:05:04PM +0200, Simon Josefsson wrote: >> Erik Auerswald writes: >> > On 04.09.22 17:34, Erik Auerswald wrote: >> >> On 03.09.22 19:07, Erik Auerswald wrote: >> >>> On Sat, Sep

Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)

Guillem Jover writes: > [ Resending with To trimmed. ] > > Hi! > > On Tue, 2022-08-30 at 22:57:51 +0200, Guillem Jover wrote: >> On Sun, 2022-08-28 at 14:40:44 +0200, Erik Auerswald wrote: >> > On Sat, Aug 27, 2022 at 07:37:15PM +0200, Erik Auerswald wrote: >> > > someone has described a remote

Re: Changing how we handle non-free firmware

Kurt Roeckx writes: > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: >> As far as I can tell, both Steve's and Gunnar's proposal would make >> Debian less of a free software operating system than it is today. That >> makes me sad. My preference for an o

Re: Possible draft non-free firmware option with SC change

Russ Allbery writes: > Possible wording, which includes the existing option A verbatim: Thanks, I prefer this approach over Steve's initial proposal: it solves the problem that we would override a foundational document with a GR without the required 3:1 majority. I'm worried that if we publish

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

Paul Eggert via Bug reports for GNU grep writes: > $ grep '\Q' /dev/null > grep: warning: stray \ before Q > $ grep '[:alpha:]' /dev/null > grep: character class syntax is [[:space:]], not [:space:] Is the use of diagnostic warnings like this supported by POSIX? Personally, I'd rather have

bug#57604: [ef]grep usage -> POSIXLY_CORRECT?

Karl Berry writes: > But, whatever. Since it bothers you to use POSIXLY_CORRECT, let's invent > some other envvar that turns off the warning, like > "PLEASE_LET_ME_USE_EFGREP_I_DONT_CARE_ABOUT_POSIX", and Arnold and I > will set it and life can go on. > > https://bugs.gnu.org/49996 > > I'm

Re: TFTP client crash seems to be caused by missing bounds check in makeargv()

Erik Auerswald writes: > Hi, > > On 04.09.22 17:34, Erik Auerswald wrote: >> On 03.09.22 19:07, Erik Auerswald wrote: >>> On Sat, Sep 03, 2022 at 05:39:45PM +0200, Simon Josefsson wrote: >>>> [...] >>>> did you notice some fuzzing report that wasn

Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

Erik Auerswald writes: >> You might want to take a look at: >> >> > > Thanks for pointing out that patch. Without it telnet crashes when > it starts the

Re: TAR_OPTIONS after one decade

Hi. I have committed this. /Simon From 4b17a1ae49e69df1ac5dc35a4f60b20ab958baf2 Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Tue, 6 Sep 2022 14:32:05 +0200 Subject: [PATCH] gnumakefile: Improve tarball reproducibility. * top/GNUmakefile (TAR_OPTIONS): Add --sort=name. Suggested

Re: unictype/category-none tests: Fix a link error on MSVC

Bruno Haible writes: > On MSVC, with libunistring installed as a shared library, I get this link > error: > > /home/bruno/msvc/compile cl -nologo -MD -L/usr/local/msvc64/lib -o > test-categ_none.exe unictype/test-categ_none.obj libtests.a ../gllib/libgnu.a > libtests.a ../gllib/libgnu.a

gsasl-2.2.0 released [stable]

both the .sig file and the corresponding tarball. Then, run a command like this: gpg --verify gsasl-2.2.0.tar.gz.sig The signature should match the fingerprint of the following key: pub ed25519 2019-03-20 [SC] B1D2 BD13 75BE CB78 4CF4 F8C4 D73C F638 C53C 06BE uid Simon Josefsson

Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

Erik Auerswald writes: >> Please test commit access by pushing the patch, after writing >> a suitable NEWS entry. > > I have just committed and pushed the telnetd crash fix patch[1], > including a NEWS entry. > > [1] https://lists.gnu.org/archive/html/bug-inetutils/2022-08/msg2.html Looks

Re: [PATCH 3/3] telnet: Avoid command evaluation crashes.

fre 2022-09-02 klockan 20:37 +0200 skrev Erik Auerswald: > Hello Simon, > > On Sat, Jul 09, 2022 at 04:23:20PM +0200, Simon Josefsson wrote: > > [...] > > What's your savannah username? > > [...] > > My Savannah username is "auerswal" > <h

Re: ISO C 23 ahead

Paul Eggert writes: >> +if (ckd_mul (, plen, sizeof (CHAR)) >> \ > > Indeed it should. Thanks for reporting that. I installed the attached. Thank you! >> I wonder why no self-check has caught this? > > Apparently I tested it only on platforms with working

Re: ISO C 23 ahead

I think some of these patches introduced a build failure of GNU InetUtils on Debian 6, see build error below. The following looks strange: -if (INT_MULTIPLY_WRAPV (plen, sizeof (CHAR), ) \ -|| INT_ADD_WRAPV (new_used, plensize, _used)) \ +

Re: [BUG][PATCH] Someone described a remote DoS Vulnerability in telnetd (dereference NULL pointer ---> SEGV)

Erik Auerswald writes: >> I have attached a completely untested, not even compile >> tested, patch to do this (just the code changes, no NEWS >> or commit log or anything). Please test before committing. > > I have tested the patch now, it compiles and prevents the > crash by preventing the

Re: Changing how we handle non-free firmware

Steve McIntyre writes: > Hi Simon! > > On Mon, Aug 29, 2022 at 09:06:38AM +0200, Simon Josefsson wrote: >> >>== >> >>We continue to stand by the spirit of the Debian Social Contract §1 >>which says: >> >> Debian will remain

Re: Changing how we handle non-free firmware

Vincent Bernat writes: > On 2022-08-23 10:39, Simon Josefsson wrote: > >> Therefor we will not include any non-free software in Debian, nor in the >> main archive or installer/live/cloud or other official images, and will >> not enable anything from non-fr

Re: Changing how we handle non-free firmware

Jonas Smedegaard writes: > I view the official Debian install image as a component of Debian, and > consequently if the (only) official Debian install image were to contain > non-free bits then we would violate DSC#1. I also find this problematic. As far as I can tell, the alternatives on this

Re: Changing how we handle non-free firmware

Kurt Roeckx writes: > On Tue, Aug 23, 2022 at 10:39:57AM +0200, Simon Josefsson wrote: >> As far as I can tell, both Steve's and Gunnar's proposal would make >> Debian less of a free software operating system than it is today. That >> makes me sad. My preference for an o

Bug#1018259: nmu: libidn2_2.3.3-1

I could upload a real version too, maybe that is faster? Can do today unless someone objects. /Simon > 28 aug. 2022 kl. 14:40 skrev Johannes Schauer Marin Rodrigues > : > > Quoting Cyril Brulebois (2022-08-28 14:20:48) >> Johannes Schauer Marin Rodrigues (2022-08-28): >>> The current

Re: Creating a formula for Homebrew

Bruno Haible writes: > Hi, > > Wesley Viana wrote: >> So I was wondering how to contribute by "packing" gnulib into a brew >> formula. > > Packaging gnulib through a packaging system (such as Debian, pkg, BSD ports, > or brew) is, in the current state of things, not desirable. > > Gnulib is a

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