Martin Dosch writes:
> Dear Simon,
>
> sorry for the late reply.
>
> On 11.05.2024 18:48, Simon Josefsson wrote:
>>So I believe debian/copyright should mention that file, since that's
>>where the copyright claim is made.
>
> I understood that the claim is in scal
kpcyrd writes:
> Dear list,
>
> As of May 2024, I have imported source code data from the following
> distributions:
This is awesome!
> Future plans:
Do you consider going back in time and adding source code packages from
older releases in scope of your effort?
/Simon
signature.asc
"Theodore Ts'o" writes:
> On Sun, May 12, 2024 at 04:27:06PM +0200, Simon Josefsson wrote:
>> Going into detail, you use 'gzip -9n' but I use git-archive defaults
>> which is the same as -n aka --no-name. I agree adding -9 aka --best is
>> an improvement. Gnulib'
Collin Funk writes:
> Hi Simon,
>
> On 5/12/24 3:56 AM, Simon Josefsson via Bug reports for the GNU Internet
> utilities wrote:
>> I have committed the attached patches giving us reproducible tarballs.
>>
>> The particular logic to verify this continously is
Package: gnulib
Severity: wishlist
The current logic of dh_gnulib_patch to try each patch in a .d
sub-directory and pick one patch that applies. It was suggested to use
a more clever method to pick the "right" patch. One more clever
approach would be "git merge --is-ancestor" to programtically
, and the
information is related. The new version adds an empty line which I
think is more consistent with the other paragraphs.
Thoughts?
/Simon
From 8be372e8ddfaa5b7202e2b58b22e55c00d9016c5 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sun, 12 May 2024 17:31:51 +0200
Subject: [PATCH
since it looks
pretty alarming and the alternative code path using git rev-parse work
correctly as intended.
/Simon
From 0c52a761fbe563f2aa6731fbb18b0572005bc548 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sun, 12 May 2024 17:07:30 +0200
Subject: [PATCH] maintainer-makefile: Silence
"Theodore Ts'o" writes:
>> 1) Use upstream's PGP signed git-archive tarball.
>
> Here's how I do it in e2fsprogs which (a) makes the git-archive
> tarball be bit-for-bit reproducible given a particular git commit ID,
> and (b) minimizes the size of the tarball when stored using
> pristine-tar:
>
results are here:
https://gitlab.com/gsasl/inetutils/-/pipelines/1287332401
With SHA256 checksum output comparisons done here:
https://gitlab.com/gsasl/inetutils/-/jobs/6831038807
/Simon
From 71226a79c9b9c7b1b0ef0d05f8f41ac79dd4e491 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Sun, 12 May
Collin Funk writes:
> With an exception for some Kerberos 4 stuff, which I cannot test. I
> assume the plan is still to remove that as mentioned in TODO?
Let's keep that question open for a while more...
> Also I think that ./configure --with-shishi is broken, or maybe it is
> because I have
Collin Funk writes:
> On 5/10/24 6:52 AM, Simon Josefsson wrote:>> $ ./configure
> CC="gcc-14.1" CFLAGS="-std=c23 -Wstrict-prototypes"
> --enable-authentication --enable-encryption --with-krb5
>>
>> Ah, you answered my request from the earlier em
Martin Dosch writes:
> Dear Simon,
>
>>Running 'lrc' catches a licensing problem:
>>
>>BSD-3-clause| BSD-1-Clause scalar.go
>>
>>It seems correct. Can you add the license block further down in
>>scalar.go to debian/copyright? I'm thinking of this:
>
> Funny that this is in scalar.go
Nilesh Patra writes:
> On Sat, May 11, 2024 at 12:47:14PM +, Martin Dosch wrote:
>> Dear Simon,
>>
>> On 10.05.2024 19:20, Simon Josefsson wrote:
>> > I reviewed the debian/sid changes and they look fine. Could you push
>> > the upstream & prist
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
&
Bruno Haible writes:
> Simon Josefsson wrote:
>> Finally, while this is somewhat gnulib specific, I think the practice
>> goes beyond gnulib
>
> Yes, gnulib-tool for modules written in C is similar to
>
> * 'npm install' for JavaScript source code packages [1],
&
Bruno Haible writes:
> Simon Josefsson wrote:
>> I've found it to only be cost
>> effective to setup my own runners for platforms that gitlab doesn't
>> support natively, such as arm64 or ppc64el.
>
> For GitHub runners, hosting your own runners comes with securi
eam
tarball with pre-generated content and gnulib code, and latest version
1.8-3 that builds from a minimal source-only tarball is small:
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Uploaders:
Simon Josefsson ,
Build-Depends:
debhelper-compat (= 13),
+ git,
+ gnulib
eam
tarball with pre-generated content and gnulib code, and latest version
1.8-3 that builds from a minimal source-only tarball is small:
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Uploaders:
Simon Josefsson ,
Build-Depends:
debhelper-compat (= 13),
+ git,
+ gnulib
on
1.8-3 that builds from a minimal source-only tarball is small:
--- a/debian/control
+++ b/debian/control
@@ -6,6 +6,8 @@ Uploaders:
Simon Josefsson ,
Build-Depends:
debhelper-compat (= 13),
+ git,
+ gnulib (>= 20240412~dfb7117+stable202401.20240408~aa0aa87-3~),
Standards-Version: 4.6.2
Martin Dosch writes:
> Dear Simon,
>
> On 10.05.2024 19:20, Simon Josefsson wrote:
>>I reviewed the debian/sid changes and they look fine. Could you push
>>the upstream & pristine-tar branches and the upstream/1.1.0 tag? I
>>wasn't able to build it.
>
&
Arnaud Rebillout writes:
> On 11/05/2024 16:59, Simon Josefsson wrote:
>> I feel uncomfortable having a salsa
>> write permission token in plain text on my laptop, which seemed required
>> to use some of the suggested tools
>
> Just passing by.
>
> What are you r
Following up on the namespace question separately. To clarify: I'm not
proposing any change. I'm mostly trying to learn and understand why
some decisions were made and if the rationale still apply.
Samuel Henrique writes:
> Downsides of keeping the packaging under debian/:
> * Lack of the
Thanks for adding me to the pkg-security group! To get started, I have
moved libntlm's git repo from the pkg-auth-maintainers group on Salsa to
the pkg-security. I did an upload updating debian/control, together
with some other fixes.
I'm not up to speed on all the pkg-security tooling, so
Martin Dosch writes:
> Dear all,
>
> I prepared the packaging for a new release of filippo.io-edwards25519:
> https://salsa.debian.org/go-team/packages/filippo.io-edwards25519
>
> I successfully ran ratt and would appreciate if someone would upload
> it to unstable.
I reviewed the debian/sid
Collin Funk writes:
> I've applied the attached patch to fix the following error building
> libtelnet. I think the only ones remaining are in telnet/*. Once I fix
> that maybe these are good for an existing CI job?
>
> $ ./configure CC="gcc-14.1" CFLAGS="-std=c23 -Wstrict-prototypes"
>
Collin Funk writes:
> Hi,
>
> I've pushed this patch already because it seems pretty
> uncontroversial.
>
> Basically converting some K functions to ISO C and not using empty
> argument lists:
Thanks -- okay with me, although it would have been nice to setup some
way to reproduce the issue and
"Adam D. Barratt" writes:
> On Thu, 2024-05-09 at 11:55 +0200, Simon Josefsson wrote:
>> By todays standards snapshot doesn't
>> contain a lot of data -- 3 big SSD disks holds it all
>
> How large are your SSDs? snapshot.d.o currently has 8 storage shards
> an
Bruno Haible writes:
> + int alarm_value = 50;
>signal (SIGALRM, SIG_DFL);
> - alarm (10);
> + alarm (alarm_value);
Nice trick, but doesn't the compiler optimize away this? Maybe a
'volatile' is needed.
/Simon
signature.asc
Description: PGP signature
fatih durmaz writes:
> Hello,
>
> I am research intern working on systems security in Imdea Software
> institute. I couldn't see a way to download all packages for a certain
> snapshot. I have tried downloading packages one by one but now the
> rate-limiter doesn't allow me anymore.
>
> Is
Simon Josefsson via writes:
> jas@kaka:~/src/libntlm$ guix git authenticate
> guix git: successfully authenticated commit
> a94c085b17dd72904d8913411e1e85477e12
> jas@kaka:~/src/libntlm$ git commit -m"maint: Mention guix git introductory
> commit." README.md
ementation seems confused by PGP subkeys. Verifying the
initial commit after adding .guix-authenticate works fine:
jas@kaka:~/src/libntlm$ git log -1 -p
commit 2e6e8027c75942450a0e4ae0f58e876715782cae (HEAD -> master)
Author: Simon Josefsson
Date: Thu May 9 10:34:15 2024 +0200
maint: Support
Collin Funk writes:
> Hi Simon and Gulliem,
>
> On 5/8/24 1:06 PM, Simon Josefsson via Bug reports for the GNU Internet
> utilities wrote:
>> Hi Guillem. I added the bootstrap files to the tarball now.
>>
>> I'm not convinced that this is a good idea, so let's
Collin Funk writes:
> Hi Simon,
>
> Are you okay with me pushing the following two patches?
>
> Patch 0001 removes most (all?) of the extern function decls that
> should be in the standard library. They seems harmless, but maybe they
> can mess with Gnulib declarations. We should probably just
Guillem Jover writes:
> Hi!
>
> On Mon, 2024-05-06 at 18:12:53 +0200, Simon Josefsson via Bug reports for the
> GNU Internet utilities wrote:
>> I have updated inetutils to latest gnulib (to get the u_* syntax-check
>> fixes, and the new faster gnulib-tool.py) and
NIIBE Yutaka writes:
> Hello,
>
> The Classic McEliece implementation assumes that unaligned access for
> 64-bit and 32-bit are OK. It is not the case for some architectures.
>
> Here is a patch to point out the issue. Better patch is welcome.
I forwarded this to DJB and a new release of
Collin Funk writes:
> On 5/6/24 6:03 PM, Collin Funk wrote:
>> So I am confident it is a bug. I've applied the attached patch which
>> seems to fix the issue. This is based on a quick glance of the code so
>> I would appreciate others looking it over. Thanks!
Thank you! I think we should
Collin Funk writes:
>> I do mostly agree, however there is another concern: frivolious changes
>> like this makes it harder to align code with BSD implementations for
>> auditing and security backports. I've sporadically coordinated some
>> security fixes with tnftp which seems to be the
Bruno Haible writes:
> Simon Josefsson wrote:
>> I forgot to mention: the pattern to provide re-usable GitLab CI/CD
>> definitions that I'm inspired by is Debian's pipeline project:
>>
>> https://salsa.debian.org/salsa-ci-team/pipeline/
>>
>> I
Bruno Haible writes:
>> I think the pattern of having the .gitlab-ci.yml outside of the core
>> Savannah project is a good one for those GNU projects who are not
>> embracing the GitLab platform. Then GitLab-related stuff stays on the
>> GitLab platform and doesn't invade the core project.
>
>
I have updated inetutils to latest gnulib (to get the u_* syntax-check
fixes, and the new faster gnulib-tool.py) and refreshed the bootstrap
scripts, please test and report if something broke!
/Simon
signature.asc
Description: PGP signature
I forgot to mention: the pattern to provide re-usable GitLab CI/CD
definitions that I'm inspired by is Debian's pipeline project:
https://salsa.debian.org/salsa-ci-team/pipeline/
It is easy to setup a new project to use their reusable pipeline -- just
add the CI/CD configuration file setting
Bruno Haible writes:
> gnulib-tool is used is many CI jobs. Just adding 'python3' to the
> prerequisites of such a job makes it run faster. Here are the execution
> times for a single run, before and after adding 'python3', for those
> CIs that I maintain or co-maintain. In minutes and seconds.
Werner Koch writes:
> On Mon, 6 May 2024 17:06, Simon Josefsson said:
>
>> Thank you! As far as I can tell this doesn't strongly bind eccPublicKey
>> and mlkemPublicKey to the KEK which may complicate a security proof.
>
> Can you give a reason for this? The fingerpr
Werner Koch via Gnupg-devel writes:
> On Mon, 6 May 2024 14:49, Simon Josefsson said:
>> Werner Koch via Gnupg-devel writes:
>>
>>> + - Prepare fixedInfo as specified above
>>>
>>>- Compute KEK := multiKeyCombine(eccKeyShare, eccCipherTex
2adbe3be9e278cfc66289bbd9c8c433db84d5ce4 Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Mon, 6 May 2024 14:56:08 +0200
Subject: [PATCH 1/2] inet-ntop, inet-pton: Avoid obsolete u_char type.
* lib/inet_pton.c (inet_pton6): Use unsigned char instead of u_char.
* lib/inet_ntop.c: Doc fix.
---
ChangeLog
Werner Koch via Gnupg-devel writes:
> + - Prepare fixedInfo as specified above
>
>- Compute KEK := multiKeyCombine(eccKeyShare, eccCipherText,
> mlkemKeyShare, mlkemCipherText, fixedInfo, 256) as defined in
> -Section [](#KEM-Key-Combiner).
> +Section [](#kem-key-combiner).
Lucas Nussbaum writes:
> - I got the OK to host a S3-backed snapshot mirror using the Debian AWS
> account (see thread in #1020217)
Is this s3 bucket public, or will it be?
I have been worried about the state of snapshot and I am mirroring its
data into local Git LFS. Since
Lucas Nussbaum writes:
> - I got the OK to host a S3-backed snapshot mirror using the Debian AWS
> account (see thread in #1020217)
Is this s3 bucket public, or will it be?
I have been worried about the state of snapshot and I am mirroring its
data into local Git LFS. Since
Collin Funk writes:
> There are some uses of 'caddr_t' in Inetutils. This is a prehistoric
> BSD type. I think it was because early versions of C didn't
> automatically convert 'void *' to the appropriate type.
...
> Patch 0001 adds a syntax check for this type and patch 0002 removes
> it's uses
How about adding inetutils u_* syntax-checks to gnulib's maint.mk?
sc_unsigned_char:
@prohibit=u''_char \
halt='don'\''t use u''_char; instead use unsigned char' \
$(_sc_search_regexp)
sc_unsigned_long:
@prohibit=u''_long \
halt='don'\''t use u''_long;
Collin Funk writes:
> At some point someone added syntax-checks to fail if old BSD types
> where used:
>
> u_char -> unsigned char
> u_short -> unsigned short
> u_long -> unsigned long
>
> But they forgot to do u_int. Patch 0001 adds one for u_int and patch
> 0002 removes them.
ver? Or did you use some tool
to discover this that isn't linked from the PTS?
A patch like the one below seems to fix this. But maybe we should raise
a lintian wishlist bug report too.
/Simon
From 4144c80941d5d099b2ff6678750bae5419c74b6a Mon Sep 17 00:00:00 2001
From: Simon Josefsson
Date: Fri, 3 May
Collin Funk writes:
> Hi Simon,
>
> On 5/2/24 11:25 AM, Simon Josefsson via Bug reports for the GNU Internet
> utilities wrote:
>>> Sadly, I cannot do this, at least not easily. After installing GNU
>>> indent, "make syntax-check" complains about ma
Collin Funk writes:
> Hi Simon,
>
> On 5/2/24 11:25 AM, Simon Josefsson via Bug reports for the GNU Internet
> utilities wrote:
>>> Sadly, I cannot do this, at least not easily. After installing GNU
>>> indent, "make syntax-check" complains about ma
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
1 - 100 of 7193 matches
Mail list logo
