"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's maint.mk also add --rsyncable,
" argument.
And if you are always regenerating those files, you don't need to
audit the code, since they are going to them, no? And the generated
files from autoconf and friends have well understood licensing
concerns.
And by the way, all of your concerns about vendored files, and al
Ansgar 🙀 writes:
> In ecosystems like NPM, Cargo, Golang, Python and so on pinning to
> specific versions is also "explicitly intended to be used"; they just
> sometimes don't include convenience copies directly as they have tooling
> to download these (which is not allowed in Debian).
Yeah, thi
Hi,
On Sun, 2024-05-12 at 08:41 -0700, Russ Allbery wrote:
> "Theodore Ts'o" writes:
> > And yet, we seem to have given a pass for gnulib, probably because it
> > would be too awkward to enforce that rule *everywhere*, so apparently
> > we've turned
m4.
Or use a subdirectory named something like m4, so that you can put each
conceptually separate macro in a separate file and not mush everything
together, and use:
AC_CONFIG_MACRO_DIR([m4])
(and set ACLOCAL_AMFLAGS = -I m4 in Makefile.am if you're also using
Automake).
> Note that how w
would notice.
The best is when upstream ship a tarball consistent with what I dream
*.orig.tar.gz should be: free of vendored and pre-generated files.
Debian package maintainers can take action before this happens, to reach
nice properties within Debian. Maybe some upstream will adapt.
>>
On Sat, May 11, 2024 at 04:09:23PM +0200, Simon Josefsson wrote:
>The current approach of running autoreconf -fi is based on a
>misunderstanding: autoreconf -fi is documented to not replace certain
>files with newer versions:
>https://lists.nongnu.org/archive/html/bug
On 2024-05-11 07:09, Simon Josefsson via Gnulib discussion list wrote:
I would assume that (some stripped down
version of) git is a requirement to do any useful work on any platform
these days, so maybe it isn't a problem
Yes, my impression also is that Git has migrated into the realm o
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 packa
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],
* 'cargo fetch' for Rust source code
All, (going out to both debian-devel and bug-gnulib, please be
respectful of each community's different perspectives and trim Cc
when focus shifts to any Debian or gnulib specific topics)
(please pardon the accidental duplicate post to bug-gnulib...)
The content of ups
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 :)
>
> Thanks for releaving me.
>
> ...but then you bring up licensing, which has my special interest :-D
I am terribly
evel to
> allow others to help and to allow you from not having to feel a need to
> reply at all :)
Thanks for releaving me.
...but then you bring up licensing, which has my special interest :-D
> One of the things that bothered me with the gnulib Debian package that
> I've be
to
reply at all :)
One of the things that bothered me with the gnulib Debian package that
I've been too afraid to touch is the debian/copyright file. It triggers
a lot of lintian errors:
https://udd.debian.org/lintian/?packages=gnulib
For reference here is current debian/copyright:
htt
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 any
re per year to one architecture every other
year. And given the long tail of problems, porters have to fix gnulib
copies for a long time. People used to say that we can ship generated
configure scripts (and some still do). Now we autoreconf by default,
because arm64 was just too painful. gnulib af
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 pie
On Sun, Nov 13, 2022 at 02:01:50PM +, Reuben Thomas wrote:
> Some other Debian packages build-depend on Debian's gnulib package. This
> won't necessarily work for libpaper, because gnulib is not versioned:
> libpaper depends on a specific commit of gnulib, and there are o
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
t; libpaper1 to libpaper2.)
>
> Bastian Germann (b...@debian.org) is kindly helping with the packaging and
> sponsoring my upload.
>
> I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
> Thorsten Alteholz), who said "I didn't find any explanatio
libpaper1 to libpaper2.)
>
> I am a bit torn here: with my DM hat on, stripping out gnulib sources
> where possible and using Debian's gnulib package seems the right thing to
> do. With my upstream hat on it leads potentially to bug reports that don't
> correspond to an upstream rel
>>>>> "Reuben" == Reuben Thomas writes:
Reuben> I am a bit torn here: with my DM hat on, stripping out
Reuben> gnulib sources where possible and using Debian's gnulib
Reuben> package seems the right thing to do. With my upstream hat
Reuben&
Hi,
On So 13 Nov 2022 15:01:50 CET, Reuben Thomas wrote:
I am a bit torn here: with my DM hat on, stripping out gnulib sources where
possible and using Debian's gnulib package seems the right thing to do.
With my upstream hat on it leads potentially to bug reports that don't
corres
On Sun, 13 Nov 2022 at 14:01:50 +, Reuben Thomas wrote:
> I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
> Thorsten Alteholz), who said "I didn't find any explanation why you embedded a
> copy of gnulib in your source tarball. Do you really need
with the packaging and
sponsoring my upload.
I just got a rejection for libpaper_2.0.3-1 from ftp-master (in this case,
Thorsten Alteholz), who said "I didn't find any explanation why you
embedded a copy of gnulib in your source tarball. Do you really need that?"
Like many GNU packa
Package: wnpp
Severity: normal
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have hereby orphaned the gnulib package.
The package description is:
The GNU portability library is a macro system and C declarations and
definitions for commonly-used API elements and abstracted system behaviors
26 matches
Mail list logo
