Erik Auerswald writes:
> Hi Simon,
>
> On Thu, May 02, 2024 at 08:08:07PM +0200, Simon Josefsson wrote:
>> tor 2024-05-02 klockan 20:05 +0200 skrev Erik Auerswald:
>> > On Thu, May 02, 2024 at 07:55:23PM +0200, Simon Josefsson via Bug
>> > reports for
tor 2024-05-02 klockan 20:05 +0200 skrev Erik Auerswald:
> Hi Simon,
>
> On Thu, May 02, 2024 at 07:55:23PM +0200, Simon Josefsson via Bug
> reports for the GNU Internet utilities wrote:
> > [...]
> > I worry about self-tests though, it would be nice to beef up on
> &g
Collin Funk writes:
> Hi,
>
> Is the TODO file generally up-to-date? Now that I have my copyright
> assignment done, maybe I can find some stuff to hack on.
Yay!
> Specifically, are these items still true?
I think you should pretty much assume very little is up to date or
correct in
Werner Koch via Gnupg-devel writes:
> Hi!
>
> Gniibe and me have been working on PQC Support in GnuPG for some time
> now. Now we have a first Beta version available. Because we have done
> no releases of the supporting libraries yet, a tarball with all sources is
> available:
>
>
Hi Vincent,
Vincent Lefevre writes:
> Thanks for the explanations. However, I think that it is not the
> goal of the Debian version string to entirely reflect all the
> Debian-side and upstream-side versions involved. This may be a
> good idea when the obtained version string is short enough
Hi
According to the mirror list
https://www.debian.org/distrib/archive
it should be possible to reach archive.debian.org via rsync, however
this fails for me. Is this intentional, or can this be fixed?
Further it seems mirrors are out of sync. I noticed that several
mirrors lack buster.
Jianfeng Liu writes:
> Hi Go team,
>
> I'm looking for a sponsor to upload the
> golang-github-cloudflare-apt-transport-cloudflared package for me.
> This package is a build-dep of
> golang-github-akihirosuda-apt-transport-oci, which will add oci deb
> repo support to apt.
>
>
>
Paul Eggert writes:
> You raise several good points. A couple of quick reaction:
>
> On 2024-04-25 09:26, Simon Josefsson via Gnulib discussion list wrote:
>
>> - the gnulib git submodule is huge. Not rarely I get out of memory
>>errors during 'git clone' in CI/CD jo
Bruno Haible writes:
> Hi Simon,
>
>> you can ... via
>> GNULIB_REVISION pick out exactly the gnulib git revision that libpaper
>> needs. ...
>> [1]
>> https://blog.josefsson.org/2024/04/13/reproducible-and-minimal-source-only-tarballs/
>> [2]
Bruno Haible writes:
> Since
> - IRIX 6.5 is end-of-life for more than 10 years [1],
> - I don't have access to an IRIX machine any more,
> - the AC_SYS_LARGEFILE macro no longer supports IRIX,
> I would suggest to remove mentions of IRIX support from the
> documentation.
+1
"On
Erik Auerswald writes:
> I have done that in the attached patch.
>
> I plan to push the changes in a couple of days, unless I receive negative
> feedback.
Looks great, thank you.
/Simon
signature.asc
Description: PGP signature
Reuben Thomas writes:
> TLDR: FTP Master rejected my libpaper package because it contains gnulib
> source files. I pointed out that other Debian packages for which I am
> upstream do exactly this and have been accepted, and that it is the
> standard way to use gnulib. A few senior Debian
Collin Funk writes:
> Hi Paul,
>
> On 4/23/24 11:22 PM, Paul Eggert wrote:
>> Why is telnetd.h including config.h? Only a top-level C file should
>> include config.h, and it should so so at the start.
>
> I don't disagree. Most of those lines are 20 years old, so I assume it
> wasn't a problem
Collin Funk writes:
> Hi Paul,
>
> On 4/23/24 11:22 PM, Paul Eggert wrote:
>> Why is telnetd.h including config.h? Only a top-level C file should
>> include config.h, and it should so so at the start.
>
> I don't disagree. Most of those lines are 20 years old, so I assume it
> wasn't a problem
Erik Auerswald writes:
> Hi,
>
> while "ifconfig -A" now accepts CIDR notation, it does not reject prefix
> length values outside of [0,32]. Also, with a prefix length of 0,
> undefined begavior is invoked, and at least on x86_64 a wrong netmask
> is computed.
>
> I think the attached patch
Janneke Nieuwenhuizen writes:
>> Also, from the diagrams in [1][2][3] it looks like the full-source bootstrap
>> uses tarballs frozen in time (make-3.80, gcc-2.95.3, gcc 4.7.3, etc.). So,
>> even if newer versions of 'make' or 'gcc' will use a Python-based
>> gnulib-tool,
>> there won't be a
Philip Hands writes:
> Mathias Gibbens writes:
>
>> On Sun, 2024-04-21 at 18:47 +0200, Simon Josefsson wrote:
> ...
>>> /usr/libexec/minio-client/bin/mc -> /usr/bin/mcli
>
> Might I suggest that the link goes the other way, so that the symlink
> lives
Bruno Haible writes:
> Janneke Nieuwenhuizen wrote:
>> Are are we creating a problem for
>> bootstrapping (or even a dependency cycle) when introducing this new
>> dependency into a certain package.
>
> I think you answered this question with "no", when writing in [1]:
>
> "Even more recently
Marco d'Itri writes:
> On Apr 21, Mathias Gibbens wrote:
>
>> While that might work for them, it obviously doesn't at a higher
>> packaging level. Per Policy Section 10.1, I'm bringing this to d-devel
>> for any comments or suggestions on my plan for packaging the MinIO
>> Client. Following
Package: gnulib
Severity: wishlist
I don't know how to implement this, so I'll describe it pending for
inspiration or someone else to come along who wants to work on this.
Let's say we are in a situation were Debian packages Build-Depends on
the gnulib package as the source for gnulib related
Bruno Haible writes:
> Hi,
>
> It's now time to call for beta-testers of the Python gnulib-tool.
> I plan to post the same text to info-gnu and to planet.gnu.org.
Confirmed success with oath-toolkit; identical generated files.
Old execution time was ~48 seconds, now it is at 0.7 seconds.
The
Jonas Smedegaard writes:
> Quoting Simon Josefsson (2024-04-18 09:34:26)
>> Jonas Smedegaard writes:
>>
>> > That said, you are welcome to try nudge me if some concrete task
>> > emerges where you image I might be of help.
>>
>> Thanks -- I'm mov
Sebastian Ramacher writes:
> Hi,
>
> as the progress on the t64 transition is slowing down, I want to give an
> overview of some of the remaining blockers that we need to tackle to get
> it unstuck. I tried to identify some clusters of issues, but there might
> be other classes of issues.
Caleb Herbert writes:
> Hi,
>
> I filed a bug report to Trisquel but bill-auger said to post here as well.
>
> In Trisquel, I find files with the following license:
>
> (C) International Organization for Standardization 1986
> Permission to copy in any form is granted for use with
>
Maytham Alsudany writes:
> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
>
> This field mimics the previous
Maytham Alsudany writes:
> In early 2022, Guillem added support for a new Static-Built-Using field to
> dpkg, encouraging packagers to use it over Built-Using to specify
> statically-linked dependencies [2]. The commit message states the following:
>
> This field mimics the previous
Vincent Lefevre writes:
> Package: gnulib
> Version: 20240412~dfb7117+stable202401.20240408~aa0aa87-2
> Severity: normal
>
> A long package version is annoying for the user (for the "dpkg -l"
> output and other reasons). I doubt that such a long version is
> necessary;
Hi Vincent and thanks for
Jonas Smedegaard writes:
> That said, you are welcome to try nudge me if some concrete task
> emerges where you image I might be of help.
Thanks -- I'm moving this out of 921954@bugs and cc'ing debian-devel to
allow others to help and to allow you from not having to feel a need to
reply at all
NIIBE Yutaka writes:
> Hello,
>
> Let us apply the patch of Classic McEliece mceliece6688128f.
Thank you.
> (Personally, I need to do this before adding more curves to ECC KEM.)
>
> On Tue, 30 Jan 2024 10:20 +0100, Simon Josefsson wrote:
>> This patch adds Classic M
Public bug reported:
Hi
I'm maintainer of the Debian Shishi package and also upstream of this
package.
You opened bug about t64 API and uploaded renamed packages into Debian:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062896
However my analysis is that no package renames is necessary
615498218a7995de98a201 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Mon, 15 Apr 2024 17:47:52 +0200
Subject: [PATCH] gitlog-to-changelog: Revert 2024-04-12 fix and add
documentation.
* build-aux/gitlog-to-changelog: Use localtime.
* doc/gitlog-to-changelog.texi: Add.
* doc/gnuli
Jonas Smedegaard writes:
> I am happy that gnulib is in good hands.
>
> I've moved on to other challenges, and have no interest in working on
> gnulib now. That said, you are welcome to try nudge me if some concrete
> task emerges where you image I might be of help.
Thank you for support!
Jonas Smedegaard writes:
> I am happy that gnulib is in good hands.
>
> I've moved on to other challenges, and have no interest in working on
> gnulib now. That said, you are welcome to try nudge me if some concrete
> task emerges where you image I might be of help.
Thank you for support!
Bruno Haible writes:
> Hi Simon,
>
> In the other thread [1][2][2a], but see also [3] and [4], you are asking
Hi Bruno -- thanks for attempting to bring som order to this complicated
matter! I am in agreement with most of what you say, although some
comments below.
>> Has this changed, so we
you think? I hope I'm not stepping on anyone's toes here. The
package was orphaned and is a critical component to be able to build
source-only tarballs for other packages in Debian.
/Simon
Simon Josefsson writes:
> Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnu
you think? I hope I'm not stepping on anyone's toes here. The
package was orphaned and is a critical component to be able to build
source-only tarballs for other packages in Debian.
/Simon
Simon Josefsson writes:
> Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnu
fre 2024-04-12 klockan 18:47 +0200 skrev Bruno Haible:
> The ChangeLogs are not random data. They are text files meant to be
> read
> and interpreted by humans. Shoving a "let's use GMT for everyone"
> attitude
> here is not the right way to handle the diversity of time zones.
>
> There was a
:~/src/gnulib$ build-aux/gitlog-to-changelog > foo
jas@kaka:~/src/gnulib$ TZ=UTC0 build-aux/gitlog-to-changelog > bar
jas@kaka:~/src/gnulib$ diff -ur foo bar
I have committed this.
/Simon
From dfb71172a46ef41f8cf8ab7ca529c1dd3097a41d Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri,
Simon Josefsson via Gnulib discussion list writes:
> My reaction was initially exactly the same as yours, until I found this
> piece of --help documentation, which actually is the first (and
> presumably highest priority) rule:
>
> * If the environment variable GNULIB_SRCDIR
Paul Eggert writes:
> On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
>> Is bootstrap intended to be reliable from within a tarball? I thought
>> the bootstrap script was not included in tarballs because it wasn't
>> designed to be ran that way, and t
Paul Eggert writes:
> On 4/10/24 13:36, Simon Josefsson via Gnulib discussion list wrote:
>> Is bootstrap intended to be reliable from within a tarball? I thought
>> the bootstrap script was not included in tarballs because it wasn't
>> designed to be ran that way, and t
Bruno Haible writes:
> Hi Simon,
>
>> Bug #2: ./bootstrap writes to the path indicated by --gnulib-srcdir with
>> the 'git checkout' command, and leaves the --gnulib-srcdir path at that
>> commit after ./bootstrap is finished. This happens to work in my
>> example since I pointed it to a
Hi
I'm trying to get ./bootstrap from a minimal source-only archive
generated via 'git archive' that has GNULIB_REVISION set in
bootstrap.conf, expecting this to work:
./bootstrap --gnulib-srcdir=/home/jas/src/gnulib
Bug #1: it seems GNULIB_REVISION in bootstrap.conf has no effect, and
this
Bruno Haible writes:
> Bernhard Voelker wrote:
>> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
>> > downloading the carefully prepared tarball from ftp.gnu.org, the first
>> > thing a distro does is to throw away the *.m4 files and regenerate the
>> > configure
Bruno Haible writes:
> Bernhard Voelker wrote:
>> > Last month, I spent 2 days on prerelease testing of coreutils. If, after
>> > downloading the carefully prepared tarball from ftp.gnu.org, the first
>> > thing a distro does is to throw away the *.m4 files and regenerate the
>> > configure
Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib and
intend to adopt it in Debian, but I’m happy to co-maintain it. My plan is to
keep it updated to latest upstream version, and see if we can offer some way
for it to be used to bootstrap various projects that depend on
Hi. I noticed gnulib in Debian was orphaned. I work upstream on gnulib and
intend to adopt it in Debian, but I’m happy to co-maintain it. My plan is to
keep it updated to latest upstream version, and see if we can offer some way
for it to be used to bootstrap various projects that depend on
Guillem Jover writes:
> But if as a downstream distribution I explicitly request everything to
> be considered obsolete via --force, then I really do want to get whatever
> is in the system instead of in the upstream package. Because then I
> can fix things centrally in a distribution dependency
Guillem Jover writes:
> But if as a downstream distribution I explicitly request everything to
> be considered obsolete via --force, then I really do want to get whatever
> is in the system instead of in the upstream package. Because then I
> can fix things centrally in a distribution dependency
Eric Blake writes:
> Widening the audience to include bug-gnulib, which is the upstream
> source of "# build-to-host.m4 serial 3" which was bypassed by the
> malicious "# build-to-host.m4 serial 30".
>
> On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote:
>> Hi!
>>
>> While analyzing
Eric Blake writes:
> Widening the audience to include bug-gnulib, which is the upstream
> source of "# build-to-host.m4 serial 3" which was bypassed by the
> malicious "# build-to-host.m4 serial 30".
>
> On Sun, Mar 31, 2024 at 11:51:36PM +0200, Guillem Jover wrote:
>> Hi!
>>
>> While analyzing
Colin Watson writes:
> On Mon, Apr 01, 2024 at 11:33:06AM +0200, Simon Josefsson wrote:
>> Running ./bootstrap in a tarball may lead to different results than the
>> maintainer running ./bootstrap in pristine git. It is the same problem
>> as running 'autoreconf -f
"G. Branden Robinson" writes:
> At 2024-03-31T22:32:49+, Stefano Rivera wrote:
>> Upstreams would probably prefer that we used git repositories
>> *directly* as source artifacts, but that comes with a whole other can
>> of worms...
>
> Speaking from my upstream groff perspective, I wouldn't
Gioele Barabucci writes:
> But pulling a successful collision attack is not a trivial task. For
> instance, the xz attacker did not have all that was required to carry
> it out (for example they had no direct access to the git
> servers... yet).
Is that necessary? It seems that if you have
Bastian Blank writes:
> On Sun, Mar 31, 2024 at 12:05:54PM +0500, Andrey Rakhmatullin wrote:
>> On Sat, Mar 30, 2024 at 11:22:33PM -0300, Santiago Ruano Rincón wrote:
>> > As others have said, the best solution is to relay on HSW for handling
>> > the cryptographic material.
>> Aren't these
Luis Guzman writes:
> Hi again!,
>
> En 30/03/24 06:13, Simon Josefsson escribió:
>> Hi. What would it take to enable riscv64 when we import 24.04 as the
>> base for trisquel 12?
>
> Talking from my own point of view, need more people involved on the
> develop
Russ Allbery writes:
> Simon Josefsson writes:
>> Sean Whitton writes:
>
>>> We did some analysis on the SHA1 vulnerabilities and determined that
>>> they did not meaningfully affect dgit & tag2upload's design.
>
>> Can you share that analys
Jonathan Carter writes:
> On 2024/03/30 11:05, Simon Josefsson wrote:
>>> 1. Move towards allowing, and then favoring, git-tags over source tarballs
>>
>> Some people have suggested this before -- and I have considered adopting
>> that approach myself, but one
Sean Whitton writes:
> Hello,
>
> On Sat 30 Mar 2024 at 12:19pm +01, Simon Josefsson wrote:
>
>> Relying on signed git tags is not reliable because git is primarily
>> SHA1-based which in 2019 cost $45K to do a collission attack for.
>
> We did some analys
Hi. What would it take to enable riscv64 when we import 24.04 as the
base for trisquel 12? While still a fairly experimental platform, I
think that during the lifespan of trisquel 12 the riscv64 platform may
become an important target. It would be nice to include riscv64
packages from Ubuntu
Nilesh Patra writes:
>> > https://github.com/go-git/go-git-fixtures/tree/master/data
>> >
>> > directly into the installed Debian package. Given the recent xz fiasco,
>> > I have doubts that this is a good idea -- there is a bunch of
>> > pre-generated compressed git repositories in that
Maytham Alsudany writes:
> Hi Simon,
>
> On Sat, 2024-03-30 at 09:48 +0100, Simon Josefsson wrote:
>> Maytham Alsudany writes:
>>
>> > https://salsa.debian.org/go-team/packages/golang-github-go-git-go-git-fixtures
>>
>> I looked at this update, and
Gioele Barabucci writes:
> Just as an example, bootstrapping coreutils currently requires
> bootstrapping at least 68 other packages, including libx11-6 [1]. If
> coreutils supported [2], the transitive closure of its
> Build-Depends would be reduced to 20 packages, most of which in
>
What a great easter gift! I have successfully installed it on a Talos
II Lite using trisquel-netinst_11.0.1_ppc64el.iso image with SHA256
3b4822f154631ce4348259720f4a2f5aa94bdc4e52e75a782f33355044aa8125.
Notes:
- Petitboot defaults to select 'Expert Install' instead of 'Default
Install' - not
Antonio Russo writes:
> 1. Move towards allowing, and then favoring, git-tags over source tarballs
Some people have suggested this before -- and I have considered adopting
that approach myself, but one thing that is often overlooked is that
building from git usually increase the Build-Depends
Maytham Alsudany writes:
> https://salsa.debian.org/go-team/packages/golang-github-go-git-go-git-fixtures
I looked at this update, and one of the proposed changes is to include
all of the pre-generated stuff from here:
https://github.com/go-git/go-git-fixtures/tree/master/data
directly into
Maytham Alsudany writes:
> Hi Simon,
>
> On Wed, 2024-03-27 at 16:30 +0100, Simon Josefsson wrote:
>> Hi -- happy to sponsor this -- are they in git on salsa for me to build
>> and sign and upload, or what shape are they in?
>
> They all ready to sign and upload. I
NIIBE Yutaka writes:
> Hello,
>
> In the task T6755, we introduced KEM API. ML-KEM is added.
>
> Today, I'd like to propose adding ECC KEM implementation in the API.
> The intention of mine is use in gpg-agent to support PQC (task T7014).
>
> Attached is a patch adding ECC KEM for X25519.
tor 2024-03-28 klockan 07:29 +0800 skrev Maytham Alsudany:
> Hi Simon,
>
> On Wed, 2024-03-27 at 17:14 +0100, Simon Josefsson wrote:
> > I wonder if the sha1cd test data is copyrighted and licensed as per
> > upstream's claims, but I have no fact to speak against the clai
Related analysis: https://bugzilla.samba.org/show_bug.cgi?id=14830
It appears to affect Debian too: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1067838
** Bug watch added: Samba Bugzilla #14830
https://bugzilla.samba.org/show_bug.cgi?id=14830
** Bug watch added: Debian Bug tracker
Maytham Alsudany writes:
> Hi Go team,
>
> I require a sponsor to review and upload the following packages for me.
>
> New packages:
> - golang-github-pjbgf-sha1cd
> - golang-github-skeema-knownhosts
I reviewed these, and have uploaded them. Builds fine:
Thanks -- alas I think this is the same as this one:
https://bugs.launchpad.net/ubuntu/+source/resolv-wrapper/+bug/2015570
Rebuild the binary package and installing it should make things work
again. Could you try that?
I'm not sure how to express this dependency, it seems some behaviour of
Package: coreutils
Version: 9.4-3.1
Hi.
Shouldn't dates past 2038 work on armhf?
I tried the following commands in a sid chroot on abel.debian.org -- it
seems 'date' handles y2k38 properly, but not 'touch --date'. I couldn't
find any earlier bug report about touch --date not handling y2k38.
Bruno Haible writes:
> Hi Simon and Collin,
>
>> > Could putting the following into bootstrap.conf be a method that
>> > we could recommend? Then developers can override it with
>> > GNULIB_TOOL_IMPL=sh ./bootstrap if they want.
>> >
>> > GNULIB_TOOL_IMPL=${GNULIB_TOOL_IMPL:-py}
>>
>> I'd
Edgar Lux via gnu-linux-libre writes:
> Hello. I would like to bring this to your kind attention:
>
> https://labs.parabola.nu/boards/11/topics/1679
I had the same problem on linux-libre 6.0 via Trisquel aramo:
(moving to bug-gnulib)
Collin Funk writes:
> On 3/22/24 2:18 PM, Simon Josefsson wrote:
>> Upgrading inetutils to use gnulib-tool.py would be nice. As a start, I
>> bumped the gnulib submodule.
>
> Bruno and I are still working on it with a test suite. We want the
>
Collin Funk writes:
> Hi Simon,
>
> On 3/22/24 12:51 PM, Simon Josefsson wrote:
>> Hi. Nice catch, thank you. I have added a CI/CD job to catch -lsystemd
>> regressions in the future:
>
> Nice, looks good to me.
>
>> Thank you for details -- I think t
Collin Funk writes:
> When building on GNU/Linux with:
>
> ./configure --enable-systemd
>
> there are linker errors due to '-lsystemd' not being passed to the
> linker. This is used by Gnulib's readutmp module.
Hi. Nice catch, thank you. I have added a CI/CD job to catch -lsystemd
regressions
Hi again,
I have uploaded a NMU with the patch below into DELAYED/10. Let me know
if you want to cancel it.
/Simon
Simon Josefsson writes:
> Hi Ruben, all,
>
> I have opened a merge request to resolve the bug below:
>
> https://salsa.debian.org/debian-mobcom-te
Collin Funk writes:
>> But in the current state, it fails for nearly every command. There's
>> no hope that you can expect identical results from the two implementations
>> as long as there are still items in the TODO list.
>
> Yes. I am working on it. I've added the following lines to my
>
* Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition. Closes: #1062896
> +
> + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 +
> +
> shishi (1.0.3-2) unstable; urgency=medium
>
>[ Simon Josefsson ]
> diff -Nru shishi-1.0.3/debian/contr
* Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition. Closes: #1062896
> +
> + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 +
> +
> shishi (1.0.3-2) unstable; urgency=medium
>
>[ Simon Josefsson ]
> diff -Nru shishi-1.0.3/debian/contr
* Non-maintainer upload.
> + * Rename libraries for 64-bit time_t transition. Closes: #1062896
> +
> + -- Benjamin Drung Thu, 29 Feb 2024 15:52:14 +
> +
> shishi (1.0.3-2) unstable; urgency=medium
>
>[ Simon Josefsson ]
> diff -Nru shishi-1.0.3/debian/contr
Package: libidn
Version: 1.42-1
All packages should build against libidn-dev now, not libidn11-dev.
Current stable release of Debian ships libidn-dev.
The transitional libidn11-dev package can be dropped when all reverse
dependencies have stopped using it.
root@68d340bc8331:/# apt-cache
Simon Josefsson writes:
> Package: freediameter
> Version: 1.2.1-8
> Tags: patch
>
> Hi! I'd like to drop the transitional package 'libidn11-dev' as most
> packages have already moved to use 'libidn-dev' which is in stable.
>
> How about this patch?
>
> /Simon
>
Package: freediameter
Version: 1.2.1-8
Tags: patch
Hi! I'd like to drop the transitional package 'libidn11-dev' as most
packages have already moved to use 'libidn-dev' which is in stable.
How about this patch?
/Simon
diff --git a/debian/control b/debian/control
index 335362a..2856eae 100644
Package: loudmouth
Version: 1.5.4-1
Tags: patch
Hi! I'd like to drop the transitional package 'libidn11-dev' as most
packages have already moved to use 'libidn-dev' which is in stable.
How about this patch?
/Simon
diff --git a/debian/control b/debian/control
index 853b197..963b1c3 100644
---
I like the plan to replace gnulib-tool with a faster implementation, and
a two-year migration phase sounds reasonable to see if it will work in
practice.
Trying gnulib-tool.py on OATH Toolkit (which use a somewhat unorthodox
gnulib usage style by adding code into git) results in error below. I
Bruno Haible writes:
> I guess we are thinking about slightly different things:
>
> * (A) I am thinking about
> - for P in { coreutils, gettext, ... }, taking a frozen(!) checkout of P,
> removing irrelevant source files (esp. all *.h, *.c, documentation,
> etc.),
> - and a
Bruno Haible writes:
> 5) Possibly it makes also sense to allow GNULIB_TOOL_IMPL to be set to
>'sh+py'. In this case the script will make a full copy of the destination
>dir, run the shell implementation and the Python implementation on the
>two destination dirs, separately, and
Dirk van Deun writes:
> On Wed, Mar 06, 2024 at 09:11:54PM +0100, Simon Josefsson wrote:
>> Dirk van Deun writes:
>>
>> > Hi,
>> >
>> > I really like the fact that you can use user_unknown=ignore to
>> > introduce pam_oath gradually, and it
Dirk van Deun writes:
> Hi,
>
> I really like the fact that you can use user_unknown=ignore to
> introduce pam_oath gradually, and it works fine if you use one users
> file to store all the secrets; but when you use a file per user
> (like with usersfile=/oath/${USER}), users that do not have a
Benjamin Drung writes:
> Source: oath-toolkit
> Dear maintainer,
>
> Please find attached a final version of this patch for the time_t
> transition. This patch is being uploaded to unstable.
>
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental
Benjamin Drung writes:
> Source: oath-toolkit
> Dear maintainer,
>
> Please find attached a final version of this patch for the time_t
> transition. This patch is being uploaded to unstable.
>
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental
Benjamin Drung writes:
> Source: oath-toolkit
> Dear maintainer,
>
> Please find attached a final version of this patch for the time_t
> transition. This patch is being uploaded to unstable.
>
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental
Would it make sense to change this to use an inclusive list of permitted
characters instead? How about checking the field names that is in use
today, and construct a regexp of permitted symbols out of that?
Starting point: [A-Za-z][A-Za-z0-9-_]*
/Simon
signature.asc
Description: PGP signature
Would it make sense to change this to use an inclusive list of permitted
characters instead? How about checking the field names that is in use
today, and construct a regexp of permitted symbols out of that?
Starting point: [A-Za-z][A-Za-z0-9-_]*
/Simon
signature.asc
Description: PGP signature
Pierre-Elliott Bécue writes:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre-Elliott Bécue
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: client-desktop-shell-integration-nautilus
> Version : 5.0.0
> Upstream Contact: Frank Müller
> * URL :
Pierre-Elliott Bécue writes:
> Package: wnpp
> Severity: wishlist
> Owner: Pierre-Elliott Bécue
> X-Debbugs-Cc: debian-de...@lists.debian.org
>
> * Package name: client-desktop-shell-integration-nautilus
> Version : 5.0.0
> Upstream Contact: Frank Müller
> * URL :
Tom Parkin writes:
> Hi folks,
>
> Would someone mind please reviewing and uploading
> golang-github-katalix-go-l2tp 0.1.7-1?
>
> https://salsa.debian.org/go-team/packages/golang-github-katalix-go-l2tp
Looks good, although there were no tag for the previous Debian upload so
diffing changes was
1 - 100 of 7139 matches
Mail list logo
