| Newsgroups |
gmane.linux.lfs.beyond.devel |
| Message-ID |
<[email protected]> |
On 7/25/25 11:33 AM, Bruce Dubbs ([email protected] via
blfs-dev Mailing List) wrote:
> On 7/25/25 11:23 AM, "Douglas R. Reno" ([email protected]
> via blfs-dev Mailing List) wrote:
>> On 7/25/25 11:11 AM, Bruce Dubbs ([email protected] via
>> blfs-dev Mailing List) wrote:
>>> On 7/24/25 11:05 PM, "Douglas R. Reno" ([email protected]
>>> via blfs-dev Mailing List) wrote:
>>>> On 7/24/25 10:48 PM, Randy McMurchy ([email protected] via
>>>> blfs-dev Mailing List) wrote:
>>>>> On 7/24/2025 10:08 PM, Randy McMurchy ([email protected] via
>>>>> blfs-dev Mailing List) wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> The sharutils-4.15.2 package is broken with GCC 15. Here's a fix:
>>>>>>
>>>>>> https://lists.gnu.org/archive/html/bug-gnu-utils/2025-03/msg00000.html
>>>>>>
>>>>>>
>>>>>> You'll have to run autoreconf after installing the 3 patches.
>>>>>>
>>>>>> Perhaps someone can combine all 3 into one gcc-15.x patch.
>>>>>>
>>>>> Better still would be to combine the 3 sed commands and the echo
>>>>> command with the 3 patches all into one sharutils-4.15.2_fixes.patch
>>>>> (or whatever the naming conventions for patches are now.)
>>>>>
>>>>> Then it's just a patch and autoreconf -i added to the book.
>>>>
>>>> Hi Randy,
>>>>
>>>> With the amount of seds required for this package already, I think
>>>> a consolidated patch is definitely the best approach as well!
>>>> Bruce, what do you think?
>>>>
>>>> I just ran into an issue building GNU Time as well (the Time-1.9
>>>> page in the book) because it uses K&R style function declarations.
>>>> If Bruce is on board with the patch approach I'll file tickets for
>>>> both later
>>>>
>>>> Thank you for the report and the solutions!
>>>
>>> I wonder if sharutils should be archived. It has not been updated
>>> in 10 years. The only place it is referenced is in lynx for
>>> uudecode where it is optional. Checking Arch Linux,
>>> uudecode/sharutils is not mentioned as a dependency for lynx.
>>>
>>> That said, I created
>>> https://wiki.linuxfromscratch.org/blfs/ticket/21884#ticket to
>>> address the issue.
>>>
>>> -- Bruce
>>>
>> I've thought about the archiving perspective as well. The biggest
>> concern that I have is that it's required for POSIX compliance. When
>> I was taking a Linux class in college a few years back (2020...), we
>> were also using sharutils in class to use uudecode and uuencode, but
>> I don't know how many people are going to end up encountering
>> information which they need to use uudecode/encode on in the near
>> future. It can apparently be used by Automake during it's test suite,
>> but that shouldn't hold us up from a potential archival.
>>
>> Does anyone know of a mailing list where you still have to use
>> uuencode/decode or shar/unshar?
>>
>> It might be worth considering archiving it after 12.4 is out, and
>> including a note in the release announcement asking users to contact
>> us if they still use it. If we do remove it though we will also need
>> to remove our notes about being POSIX compliant. On that note, we
>> should also update our POSIX information in the LFS books to mention
>> POSIX.1-2024, and probably check in that to see if sharutils is still
>> mentioned and if there's any other changes we might need to make.
>
> I asked google and got:
>
> "According to the available information, the
> sharutils suite, which includes shar, unshar, uuencode, and uudecode,
> is not listed as a mandatory or optional utility within the
> POSIX.1-2024 (Issue 8) standard. The Open Group Base Specifications,
> Issue 8, which is the current iteration of the POSIX standard, defines
> a set of standard utilities that promote application portability
> across UNIX system environments. A thorough review of the listed
> mandatory and optional utilities in the standard does not include
> sharutils."
>
> I am in favor of archiving it now.
>
> -- Bruce
>
Let's see if anyone else speaks up, but otherwise we can archive it in
the next day or so.
- Doug
--
http://lists.linuxfromscratch.org/sympa/info/blfs-dev
Unsubscribe: See the above information page