Re: .gitmodules security

[Vincent Lefevre]

On 2022-02-06 19:49:36 -0500, Mike Frysinger wrote:
> the repository is pinned to a specific commit as you can see online:
> https://git.savannah.gnu.org/cgit/libtool.git/log/gnulib
> 
> so the normal git clone + submodule sync requires a sha1 collision.
> 
> if someone were to manually update the submodule to a newer version,
> then you only have to MITM new fake commits, but presumably a commit
> updating the pin would be detected fairly quickly as no one else is
> going to have those commits injected.

OK, but I was thinking in particular of the case of a manual update
without a commit updating the pin. The user may want to do that for
testing, e.g. in case of a problem with old gnulib code or to mimic
what is done on Debian (where the libtool uses the version from the
gnulib package, so that it is interesting to know the behavior with
the current gnulib).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: .gitmodules security

[Mike Frysinger]

On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> what is done on Debian (where the libtool uses the version from the
> gnulib package, so that it is interesting to know the behavior with
> the current gnulib).

eh ?  packages that leverage gnulib don't get libtool from gnulib.  they
get it from libtool.  so i don't know what you're referring to here, and
i'm having a hard time guessing what Debian might be doing.

packages.debian.org also says libtoolize & libtool & libtool m4 macros are
provided by the libtool package, not gnulib.
https://packages.debian.org/bullseye/all/libtool/filelist
https://packages.debian.org/bullseye/all/gnulib/filelist
-mike


signature.asc
Description: PGP signature

Re: new release?

[Frederic Berat]

On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
>
> On 06 Feb 2022 11:56, Daniel Herring wrote:
> > FWIW, libtool is a particularly difficult code base to release.  Long
> > history, many users, multi-platform, ...
> >
> > I would personally recommend the "slow" process unless you are confident
> > this release will "do no harm".  It was made for a reason, even if it
> > feels nobody is participating.  Relax, practice the release process,
> > spread the news and give people time to respond, build a good reputation,
> > have cover in case bugs are found later, ...
>
> no software is ever bug free.  being paralyzed by "is it ready yet" and
> never making a release as a result makes the problem worse.  infrequent
> releases tend to lead to large accumulation of changes which makes them
> even more unstable because the interactions are never tested.
>
> libtool has a testsuite.  if bugs are found, fix them, add more tests.
> iterate and move on.
> -mike

I'd agree with these statements.

What happened with autoconf is an extreme case, but is a good example of it.
Distros stuck to 2.69 for years, and when 1.70 finally came out, there
has been a big amount of breakage.

Releases are integrated by early distro adopters, who will find
problems that are not covered by the tests, and forward them here.
If you don't release your code, this wide coverage isn't here and the
machinery gets rusty.

Fred.

Re: .gitmodules security

[Vincent Lefevre]

On 2022-02-07 05:43:11 -0500, Mike Frysinger wrote:
> On 07 Feb 2022 09:32, Vincent Lefevre wrote:
> > what is done on Debian (where the libtool uses the version from the
> > gnulib package, so that it is interesting to know the behavior with
> > the current gnulib).
> 
> eh ?  packages that leverage gnulib don't get libtool from gnulib.  they
> get it from libtool.  so i don't know what you're referring to here, and
> i'm having a hard time guessing what Debian might be doing.

What I mean is that if I want to test libtool from the git repository,
I should also try with the latest gnulib from its git repository,
because this is what I will get in future Debian packages.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: new release?

[Alex Ameen]

Thanks for all of the advice y'all.

I'm going to get this release together as soon as possible and resolve
issues from there.

I agree that paralysis set in a bit as a result of me trying to test a bit
overboard on my own ( lots of VMs ). I appreciate the reality check :)

On Mon, Feb 7, 2022, 4:54 AM Frederic Berat  wrote:

> On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
> >
> > On 06 Feb 2022 11:56, Daniel Herring wrote:
> > > FWIW, libtool is a particularly difficult code base to release.  Long
> > > history, many users, multi-platform, ...
> > >
> > > I would personally recommend the "slow" process unless you are
> confident
> > > this release will "do no harm".  It was made for a reason, even if it
> > > feels nobody is participating.  Relax, practice the release process,
> > > spread the news and give people time to respond, build a good
> reputation,
> > > have cover in case bugs are found later, ...
> >
> > no software is ever bug free.  being paralyzed by "is it ready yet" and
> > never making a release as a result makes the problem worse.  infrequent
> > releases tend to lead to large accumulation of changes which makes them
> > even more unstable because the interactions are never tested.
> >
> > libtool has a testsuite.  if bugs are found, fix them, add more tests.
> > iterate and move on.
> > -mike
>
> I'd agree with these statements.
>
> What happened with autoconf is an extreme case, but is a good example of
> it.
> Distros stuck to 2.69 for years, and when 1.70 finally came out, there
> has been a big amount of breakage.
>
> Releases are integrated by early distro adopters, who will find
> problems that are not covered by the tests, and forward them here.
> If you don't release your code, this wide coverage isn't here and the
> machinery gets rusty.
>
> Fred.
>
>
>

Re: new release?

[Daniel Herring]

No worries.  Glad someone is carrying the project forward.

Next time, consider using the "slow process" as "outsourced QA testing". 
It might be easier and faster.  :)


-- Daniel


On Mon, 7 Feb 2022, Alex Ameen wrote:


Thanks for all of the advice y'all.
I'm going to get this release together as soon as possible and resolve issues 
from there.

I agree that paralysis set in a bit as a result of me trying to test a bit 
overboard on my own ( lots of VMs ). I appreciate the reality check
:) 

On Mon, Feb 7, 2022, 4:54 AM Frederic Berat  wrote:
  On Sun, Feb 6, 2022 at 8:02 PM Mike Frysinger  wrote:
  >
  > On 06 Feb 2022 11:56, Daniel Herring wrote:
  > > FWIW, libtool is a particularly difficult code base to release.  Long
  > > history, many users, multi-platform, ...
  > >
  > > I would personally recommend the "slow" process unless you are 
confident
  > > this release will "do no harm".  It was made for a reason, even if it
  > > feels nobody is participating.  Relax, practice the release process,
  > > spread the news and give people time to respond, build a good 
reputation,
  > > have cover in case bugs are found later, ...
  >
  > no software is ever bug free.  being paralyzed by "is it ready yet" and
  > never making a release as a result makes the problem worse.  infrequent
  > releases tend to lead to large accumulation of changes which makes them
  > even more unstable because the interactions are never tested.
  >
  > libtool has a testsuite.  if bugs are found, fix them, add more tests.
  > iterate and move on.
  > -mike

  I'd agree with these statements.

  What happened with autoconf is an extreme case, but is a good example of 
it.
  Distros stuck to 2.69 for years, and when 1.70 finally came out, there
  has been a big amount of breakage.

  Releases are integrated by early distro adopters, who will find
  problems that are not covered by the tests, and forward them here.
  If you don't release your code, this wide coverage isn't here and the
  machinery gets rusty.

  Fred.

Re: New libtool maintainer

[Julien ÉLIE]

Hi Alex,

Feel free to reach out if you have pending patches/issues you want to 
"bump", ideas for improvements, general advice for a new GNU maintainer 
- and above all if you'd like to lend a hand toward getting `libtool' up 
and running again.


Many thanks for your work on Libtool!

I believe a good start would be to integrate suggestions and patches 
from the issue tracker


  https://savannah.gnu.org/patch/?group=libtool

and maybe also some patches Debian (and other distributions) have added 
over the years to the last 2.4.6 release.  For instance:


  https://sources.debian.org/patches/libtool/2.4.6-15/


Personaly, I would of course "bump" one of the patch I provided to make 
--preserve-dup-deps work again:

  https://savannah.gnu.org/patch/?

But I wouldn't mind if that's not your top priority (I perfectly 
understand that).


And thanks again,

--
Julien ÉLIE

« J'oubliais qu'Assurancetourix a une nouvelle corde à sa harpe ! »
  (Astérix)

Re: New libtool maintainer

[Ozkan Sezer]

On 2/8/22, Julien ÉLIE  wrote:
> Hi Alex,
>
>> Feel free to reach out if you have pending patches/issues you want to
>> "bump", ideas for improvements, general advice for a new GNU maintainer
>> - and above all if you'd like to lend a hand toward getting `libtool' up
>> and running again.
>
> Many thanks for your work on Libtool!
>
> I believe a good start would be to integrate suggestions and patches
> from the issue tracker
>
>https://savannah.gnu.org/patch/?group=libtool
>
> and maybe also some patches Debian (and other distributions) have added
> over the years to the last 2.4.6 release.  For instance:
>
>https://sources.debian.org/patches/libtool/2.4.6-15/

Some of the outstanding bugs with existing patches :
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38305
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23348
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21137
   (and its dups at 22895, 31900, and 36762)
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21503
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=22373
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46559

Some of the outstanding bugs without any suggested patches:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=45738
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=52253
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=53479

Re: new release?

[Sam James]

On Mon, 7 Feb 2022 12:14:29 -0600
Alex Ameen  wrote:

> Thanks for all of the advice y'all.
> 
> I'm going to get this release together as soon as possible and resolve
> issues from there.
> 
> I agree that paralysis set in a bit as a result of me trying to test
> a bit overboard on my own ( lots of VMs ). I appreciate the reality
> check :)

Just let us know if you do need help. It's okay to even just get to
a point where you're happyish, send an email asking for testers from
master, and ask people to send you e.g. test suite results. A fair
amount of projects do this.

Thanks again for taking up the torch and +1 to everything
vapier said in this thread.

Gentoo has a stack of patches we'd like to push forward but my intention
at least is to wait until this next release b/c:
1. it's a burden on you (with too many people sending lots of huge
changes);
2. a fair amount of our changes (and most distros'!) will actually
end up being either similar or the same, at least in the result they
produce, so it's hard to know what to send until stuff all lands in
master. It's therefore easier for everyone for the short-term (just
until this first release is out or so) and we know what we're rebasing
on, etc.

Keep at it!

best,
sam


pgpJ7sczWsYgS.pgp
Description: OpenPGP digital signature

Re: new release?

[Sam James]

On Sun, 6 Feb 2022 12:21:34 -0600 (CST)
Bob Friesenhahn  wrote:

> On Sun, 6 Feb 2022, Daniel Herring wrote:
> >
> > In my opinion, frequent slow releases are way better than rare fast
> > releases.  
> 
> That may be true for some software, but libtool has a really good
> test suite so if tests pass, there is high confidence of quality for
> the systems it has been executed on.  It is abnoxiously painful to
> build libtool starting from git sources so hardly anyone is testing
> the unreleased code.
> 
> Pushing out a release assures that the mechanics are working and that 
> it is even possible to create a release.
> 
> Users are much more apt to report bugs and patches against software 
> that they can easily use.

Yep!

Especially given that distros are obviously going to be careful with
testing libtool, even more so given they (we!) know development is
resuming after a long haitus, and we're checking which of our patches
are still relevant, etc. It's not like it'll be bumped downstream
without anybody doing due diligence :)

best,
sam



pgpBmoMpg8rkj.pgp
Description: OpenPGP digital signature