At 2022-07-16T11:41:44+, Werner LEMBERG wrote:
> ... not only groff is affected by the non-working of daily snapshots.
> For example, FreeType has exactly the same problem. IMHO, such
> snapshots do more harm than good in most cases.
[...]
> Hope this helps. I guess it makes sense asking the
>> > I think that if GNU doesn't have the infrastructure or personnel
>> > to support these, then, yes, the Savannah administrators should
>> > fork (or just patch) cgit to the extent necessary to suppress the
>> > exposure of these snapshot download links. I had no idea they
>> > weren't truly s
[dropped Bruno and bug-gnulib from distribution, added Werner]
At 2022-06-25T17:45:01-0500, Dave Kemper wrote:
> On 6/19/22, G. Branden Robinson wrote:
> > I think that if GNU doesn't have the infrastructure or personnel to
> > support these, then, yes, the Savannah administrators should fork (or
On 6/19/22, G. Branden Robinson wrote:
> I think that if GNU doesn't have the infrastructure or personnel to
> support these, then, yes, the Savannah administrators should fork (or
> just patch) cgit to the extent necessary to suppress the exposure of
> these snapshot download links. I had no ide
G. Branden Robinson wrote:
> I've
> become uncertain about whether groff's build is doing to the right thing
> with respect to the '.version' file that it creates in Makefile.am (by
> running git-version-gen).
GNU gettext's Makefile.am happens to have the same rules as groff's Makefile.am.
As far
Hi Bruno,
At 2022-06-19T16:43:51+0200, Bruno Haible wrote:
> Hi Branden,
>
> Have things worked out for you by now? Is the .tarball-version
> workflow clear? Should we document it better in the git-version-gen
> script?
Thanks for following up. I haven't had time to dig into this. I've
become
Hi Branden,
Have things worked out for you by now? Is the .tarball-version workflow
clear? Should we document it better in the git-version-gen script?
Bruno
===
I wrote:
> > > By the way, if submodules are not what you want,
Hi Branden,
> > By the way, if submodules are not what you want, i.e. if you always
> > want to use the newest gnulib, I suggest to use the
> > gnulib/top/gitsub.sh script.
>
> I have no principled objection to submodules; the decision to use them
> (well, just this one, for gnulib) was taken bef
Hi Bruno,
Thank you for the quick response!
At 2022-06-04T00:38:23+0200, Bruno Haible wrote:
> Hi Branden,
>
> > -elif test "x$fallback" = x || git --version >/dev/null 2>&1; then
> > +elif test "x$fallback" = x && ! git --version >/dev/null 2>&1; then
> > v=UNKNOWN
> > else
> > v=$fa
Hi Branden,
> -elif test "x$fallback" = x || git --version >/dev/null 2>&1; then
> +elif test "x$fallback" = x && ! git --version >/dev/null 2>&1; then
> v=UNKNOWN
> else
> v=$fallback
I don't think that's a bug. The --fallback option is documented like this:
--fallback VERSION
[please keep the groff list in CCs so its developers can see responses]
Hello gnulib team,
I'm trying to get groff shipshape for a release candidate and have been
trying many different build scenarios. One issue that I noticed, as did
others long before me[3], is that the snapshot archives that
11 matches
Mail list logo
