Re: Submission process for libtool?
Hey thanks for the kind words y'all. Honestly credit mostly goes to the folks who checked in unreleased changes and submitted patches over the last few years; but I'm glad to have given it the last push. I absolutely encourage package maintainers out there to reach out with any patches that they have needed to apply to the source tarballs over the last few years. I've been handling a few Nixpkgs ones myself in side branches ( still testing and working out kinks ) since that's my daily driver. As for CI style testing that's been my main focus over the last few months, but those are external to tye repository obviously. I will summarize some of that progress in another email. Essentially I've got Hydra kicking again and I'm expanding a matrix of versions for autoconf, automake, gcc, make, m4, binutils-gdb, and various other alternatives to test against. I am manually testing Darwin, Debian, and CentOS periodically, but Hydra can easily start driving the Linux ones in VMs. Once I have a workflow for Linux VMs on Hydra I think I'll add instructions for distro maintainers to plug their ISO in to test with the matrix of dependencies. Under the hood Nix is just using Qemu, so really the Nix parts could be stripped away eventually to make it more accessible. An important one I want to get automated is testing FreeBSD Coreutils as an input to account for my own blind spots, since I'm so used to the GNU flags and quirks. Really I want to get the test suite/CI automated to the point that contributors and myself can experiment more freely without having to "just know" the millions of platform, distro, and tool specific oddities that they might inadvertently break with a patch. Obviously there's always going to be a need to manually test some systems, but having more immediate feedback where we can could make the tool much easier to extend. On Thu, Mar 31, 2022, 9:24 PM Sam James wrote: > > > > On 31 Mar 2022, at 21:42, Richard Purdie < > richard.pur...@linuxfoundation.org> wrote: > > > > Hi, > > > > It was great to see a libtool release, thanks for that! > > > > I upgraded Yocto Project to it in time for our LTS release: > > > > > https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754 > > > > so far things seem reasonable, we've had a few minor issues but they're > not > > really libtool's fault or concern. One interesting quirk was that the > shell > > script optimisation changes made between 2.4.6 and 2.4.7 resulted in > very long > > (6,000+ character) pathnames being passed to the C library functions. > This upset > > our fakeroot emulation but we've fixed that to workaround the issue. > > > > Nice and smooth so far as well here. > > > Yocto Project is carrying a few patches. I did clean them up and shared > many of > > them in October: > > > > https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html > > > > Some are more important than others and there what I believe are good > bug fixes > > in there. My questions: > > > > a) Is there a possibility these could be considered for merging? > > > > [snip] > > > > Thanks for asking this and am wondering the same thing. Hoping for your > patches > to get in (as Yocto's needs often align with ours) and then I plan on > revisiting > our (Gentoo's) stack. > > > Thanks, > > Richard > > Best, > sam >
Re: Submission process for libtool?
> On 31 Mar 2022, at 21:42, Richard Purdie > wrote: > > Hi, > > It was great to see a libtool release, thanks for that! > > I upgraded Yocto Project to it in time for our LTS release: > > https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754 > > so far things seem reasonable, we've had a few minor issues but they're not > really libtool's fault or concern. One interesting quirk was that the shell > script optimisation changes made between 2.4.6 and 2.4.7 resulted in very long > (6,000+ character) pathnames being passed to the C library functions. This > upset > our fakeroot emulation but we've fixed that to workaround the issue. > Nice and smooth so far as well here. > Yocto Project is carrying a few patches. I did clean them up and shared many > of > them in October: > > https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html > > Some are more important than others and there what I believe are good bug > fixes > in there. My questions: > > a) Is there a possibility these could be considered for merging? > > [snip] > Thanks for asking this and am wondering the same thing. Hoping for your patches to get in (as Yocto's needs often align with ours) and then I plan on revisiting our (Gentoo's) stack. > Thanks, > Richard Best, sam signature.asc Description: Message signed with OpenPGP
Submission process for libtool?
Hi, It was great to see a libtool release, thanks for that! I upgraded Yocto Project to it in time for our LTS release: https://git.yoctoproject.org/poky/commit/?id=ff7b41573842a403c81f58bee41fc8163a9d7754 so far things seem reasonable, we've had a few minor issues but they're not really libtool's fault or concern. One interesting quirk was that the shell script optimisation changes made between 2.4.6 and 2.4.7 resulted in very long (6,000+ character) pathnames being passed to the C library functions. This upset our fakeroot emulation but we've fixed that to workaround the issue. Yocto Project is carrying a few patches. I did clean them up and shared many of them in October: https://lists.gnu.org/archive/html/libtool-patches/2021-10/msg00012.html Some are more important than others and there what I believe are good bug fixes in there. My questions: a) Is there a possibility these could be considered for merging? b) Should I rebase and repost them? I'm happy to do it if it would help. c) Am I using the right process for patch submission? I never did get a reply despite asking publicly and privately. If I'm doing something wrong process wise to submit them, I'd happily correct it. Yocto Project is interesting as we can quickly test changes against the software of a whole Linux stack across many architectures "quite quickly" (complete build and tests in a few hours). I'm going to try and more closely track libtool development so that we hopefully identify regressions from our perpective quickly. Thanks, Richard
Re: Libtool roadmap
On 3/31/22 11:02, Jeff Squyres (jsquyres) wrote: > Other than Bob's humorous reply, any comment from the Libtool team? I'm also interested in any thoughts about the long term roadmap for libtool. Like you, I think users can ask these questions out of a genuine interest to align downstream development where possible. Thanks for asking the question Jeff. -- Cheers, Carlos.
Re: Libtool roadmap
Other than Bob's humorous reply, any comment from the Libtool team? Thanks! -- Jeff Squyres jsquy...@cisco.com From: Bob Friesenhahn Sent: Friday, March 25, 2022 4:01 PM To: Jeff Squyres (jsquyres) Cc: libtool@gnu.org Subject: Re: Libtool roadmap On Fri, 25 Mar 2022, Jeff Squyres (jsquyres) wrote: > Congratulations on the Libtool 2.4.7 release! > (https://lists.gnu.org/archive/html/autotools-announce/2022-03/msg0.html) > > Given that this is the first Libtool release in ~7 years, should we -- the > general developer community -- take this as an indication that the GNU > Libtool is back under active development? If so, is there a roadmap and/or > set of timeframes for future GNU Libtool work? >From the above, it sounds like you are interested in being a libtool developer. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
