Re: [Slackbuilds-users] [RFC] Adding features to .info format.
This RFC is not trying to make AARCH64 support mandatory, but is merely suggesting to allow such an entry in the info files. (I.e., allow sbolint to not bail out.) When people see such entries in .info files, some may assume that it's officially supported in SBo Also, this change will make the templates inconsistent as some application will have those entries while the others do not have. -- Willy Sudiarto Raharjo OpenPGP_signature.asc Description: OpenPGP digital signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
Willy Sudiarto Raharjo writes: > [[PGP Signed Part:Undecided]] >> There have been repeated discussions about two features that the current >> .info file format is missing: >> 1. aarch64 architecture. If in the past slarm64 was still an unofficial >> port, with -current it is official, and quite widely available, given >> the number of RPi machines available. >> 2. urls of the form https://example.test/address/ and >> https://example.test/address/1.json , which are either not supported >> by wget or can be mixed with each other, if downloaded into the same >> directory, which is especially bad with Golang and Haskell builds, >> which have many package-components, called 1.json. >> To address this issue, I propose a backward-compatible change to .info >> files format. >> 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated >> bash-string-list, identical in function to DOWNLOAD and >> DOWNLOAD_X86_64 >> 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and >> DOWNLOAD_X86_NAME, space-separated _optional_ strings, which, if >> present, specify what the results of download should be named. If >> they are absent, current logic is not changed. > > This is my personal opinion and does not reflect other admins: > > My take on aarch64 is NO official support in SBo, but we can take "ELSE IF" > in the > SlackBuild to pass needed flags to build if the maintainer is using aarch and > have > done some testing to make sure it builds fine on aarch64. I personally don't > have > RPi machines to test it and we don't have enough resources and time to handle > 3 > architecture at the same time with over 8k scripts in SBo with only few active > admins approving all the submissions that are coming in daily basis. > > I'm so grateful that Urchlay and Andrew has stepped up to help with the > linter and > semi-automatic CI engine in github. It really helped us to approve faster than > before, but still requires some manual actions and time to make sure > everything > works as expected. > > i can't imagine how long would it take for the next repository to be ready if > we > have to test 8k+ scripts x 3 architectures using the number of resources we > have. This RFC is not trying to make AARCH64 support mandatory, but is merely suggesting to allow such an entry in the info files. (I.e., allow sbolint to not bail out.) -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
since we are talking about the INFO files again, I hope you guys will reconsider your decision and allow for having variables within the downloads links, e.g. for the sources version... -p On Tue, 28 Nov 2023 at 11:47, Lockywolf wrote: > > Hello, colleagues > > There have been repeated discussions about two features that the current > .info file format is missing: > > 1. aarch64 architecture. If in the past slarm64 was still an unofficial >port, with -current it is official, and quite widely available, given >the number of RPi machines available. > > 2. urls of the form https://example.test/address/ and >https://example.test/address/1.json , which are either not supported >by wget or can be mixed with each other, if downloaded into the same >directory, which is especially bad with Golang and Haskell builds, >which have many package-components, called 1.json. > > To address this issue, I propose a backward-compatible change to .info > files format. > > 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated >bash-string-list, identical in function to DOWNLOAD and >DOWNLOAD_X86_64 > > 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and >DOWNLOAD_X86_NAME, space-separated _optional_ strings, which, if >present, specify what the results of download should be named. If >they are absent, current logic is not changed. > > Please, consider the upsides and downsides of this RFC. > > -- > Your sincerely, > Vladimir Nikishkin (MiEr, lockywolf) > (Laptop) > ___ > SlackBuilds-users mailing list > SlackBuilds-users@slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
On 11/28/23 7:03 AM, Willy Sudiarto Raharjo wrote: This is my personal opinion and does not reflect other admins: My take on aarch64 is NO official support in SBo, but we can take "ELSE IF" in the SlackBuild to pass needed flags to build if the maintainer is using aarch and have done some testing to make sure it builds fine on aarch64. [...] I hope that can change in future as I use /official/ arm(32|64) Slackware on Raspberry Pis... sbopkg & sbotools worked fine for me... didn't realize there was no official support but I didn't need a separate source code URL to install anything because nothing was arm-only. However to use fans I installed I'd have to either program them myself or switch to RaspiOS or something similar with systemd. :( ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
There have been repeated discussions about two features that the current .info file format is missing: 1. aarch64 architecture. If in the past slarm64 was still an unofficial port, with -current it is official, and quite widely available, given the number of RPi machines available. 2. urls of the form https://example.test/address/ and https://example.test/address/1.json , which are either not supported by wget or can be mixed with each other, if downloaded into the same directory, which is especially bad with Golang and Haskell builds, which have many package-components, called 1.json. To address this issue, I propose a backward-compatible change to .info files format. 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated bash-string-list, identical in function to DOWNLOAD and DOWNLOAD_X86_64 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and DOWNLOAD_X86_NAME, space-separated _optional_ strings, which, if present, specify what the results of download should be named. If they are absent, current logic is not changed. This is my personal opinion and does not reflect other admins: My take on aarch64 is NO official support in SBo, but we can take "ELSE IF" in the SlackBuild to pass needed flags to build if the maintainer is using aarch and have done some testing to make sure it builds fine on aarch64. I personally don't have RPi machines to test it and we don't have enough resources and time to handle 3 architecture at the same time with over 8k scripts in SBo with only few active admins approving all the submissions that are coming in daily basis. I'm so grateful that Urchlay and Andrew has stepped up to help with the linter and semi-automatic CI engine in github. It really helped us to approve faster than before, but still requires some manual actions and time to make sure everything works as expected. i can't imagine how long would it take for the next repository to be ready if we have to test 8k+ scripts x 3 architectures using the number of resources we have. -- Willy Sudiarto Raharjo OpenPGP_signature.asc Description: OpenPGP digital signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
>> My first thought was DOWNLOAD_X86 is not needed because the same end result
>> can be
>> achieved with DOWNLOAD, DOWNLOAD_X86_64, and DOWNLOAD_AARCH64. But now I
>> think I
>> agree with you because it has a different meaning: DOWNLOAD is a (mostly)
>> arch-independent download, where 1 or more of DOWNLOAD_* may be needed to
>> override
>> it. However, the absence of DOWNLOAD and the use of DOWNLOAD_* communicates
>> that
>> there are no arch-agnostic downloads; every download tarball is
>> arch-specific.
>>
>
>Sorry, _almost_ like this, but not quite. To maintain current behaviour,
>the absence of arch-agnostic downloads is indicated by
>DOWNLOAD="UNSUPPORTED".
That line currently means that the package does not build on ix86.
The DOWNLOAD_X86 line would effectively break backward compatibility.
But adding optional DOWNLOAD_{ARCH} for ARCH in ARM and AARCH64, and maybe
later RISCV who knows, alongside the existing X86_64, looks like a fully
backward-compatible evolution.
And not very hard to use in existing tools, and easy to understand for
maintainers, and users also.
So I am fully in favor of that evolution : allowing DOWNLOAD_{ARCH} for other
values, with the corresponding MD5SUM_{ARCH}. I already use it at home for
syncthing on arm and aarch64.
As for names, I'm unsure, but yeah, there are some problems with downloaded
files, depending on tool, content-disposition, source also, etc.
--
Yth.___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
Erich Ritz via SlackBuilds-users writes:
> On Tuesday, November 28th, 2023 at 3:21 AM, Lockywolf
> wrote:
>
>
>>
>>
>> Hello, colleagues
>>
>> There have been repeated discussions about two features that the current
>> .info file format is missing:
>>
>> 1. aarch64 architecture. If in the past slarm64 was still an unofficial
>> port, with -current it is official, and quite widely available, given
>> the number of RPi machines available.
>>
>> 2. urls of the form https://example.test/address/ and
>> https://example.test/address/1.json , which are either not supported
>> by wget or can be mixed with each other, if downloaded into the same
>> directory, which is especially bad with Golang and Haskell builds,
>> which have many package-components, called 1.json.
>>
>> To address this issue, I propose a backward-compatible change to .info
>> files format.
>>
>> 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated
>> bash-string-list, identical in function to DOWNLOAD and
>> DOWNLOAD_X86_64
>
> I think you mean DOWNLOAD_AARCH64 and DOWNLOAD_X86 function like
> DOWNLOAD_X86_64: they override DOWNLOAD for their respective arch. DOWNLOAD
> retains its current meaning.
>
> My first thought was DOWNLOAD_X86 is not needed because the same end result
> can be
> achieved with DOWNLOAD, DOWNLOAD_X86_64, and DOWNLOAD_AARCH64. But now I
> think I
> agree with you because it has a different meaning: DOWNLOAD is a (mostly)
> arch-independent download, where 1 or more of DOWNLOAD_* may be needed to
> override
> it. However, the absence of DOWNLOAD and the use of DOWNLOAD_* communicates
> that
> there are no arch-agnostic downloads; every download tarball is arch-specific.
>
Sorry, _almost_ like this, but not quite. To maintain current behaviour,
the absence of arch-agnostic downloads is indicated by
DOWNLOAD="UNSUPPORTED".
>>
>> 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and
>> DOWNLOAD_X86_NAME, space-separated optional strings, which, if
>> present, specify what the results of download should be named. If
>> they are absent, current logic is not changed.
>
> Similarly, DOWNLOAD_NAME is arch-agnostic, while DOWNLOAD_X86_NAME,
> DOWNLOAD_X86_64_NAME, and DOWNLOAD_AARCH64_NAME provide overrides for their
> respective arch.
>
Yes.
>>
>> Please, consider the upsides and downsides of this RFC.
>
> If this RFC is implemented, future changes could support DOWNLOAD_${ARCH} and
> DOWNLOAD_${ARCH}_NAME.
>
> By the way, I'm not explicitly supporting or NAKing this proposal. I'm just
> trying to help clarify the meaning of the new names.
>
> Erich
>
>>
>> --
>> Your sincerely,
>> Vladimir Nikishkin (MiEr, lockywolf)
>> (Laptop)
>> ___
>> SlackBuilds-users mailing list
>> SlackBuilds-users@slackbuilds.org
>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
>> FAQ - https://slackbuilds.org/faq/
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
--
Your sincerely,
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] [RFC] Adding features to .info format.
On Tuesday, November 28th, 2023 at 3:21 AM, Lockywolf
wrote:
>
>
> Hello, colleagues
>
> There have been repeated discussions about two features that the current
> .info file format is missing:
>
> 1. aarch64 architecture. If in the past slarm64 was still an unofficial
> port, with -current it is official, and quite widely available, given
> the number of RPi machines available.
>
> 2. urls of the form https://example.test/address/ and
> https://example.test/address/1.json , which are either not supported
> by wget or can be mixed with each other, if downloaded into the same
> directory, which is especially bad with Golang and Haskell builds,
> which have many package-components, called 1.json.
>
> To address this issue, I propose a backward-compatible change to .info
> files format.
>
> 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated
> bash-string-list, identical in function to DOWNLOAD and
> DOWNLOAD_X86_64
I think you mean DOWNLOAD_AARCH64 and DOWNLOAD_X86 function like
DOWNLOAD_X86_64: they override DOWNLOAD for their respective arch. DOWNLOAD
retains its current meaning.
My first thought was DOWNLOAD_X86 is not needed because the same end result can
be achieved with DOWNLOAD, DOWNLOAD_X86_64, and DOWNLOAD_AARCH64. But now I
think I agree with you because it has a different meaning: DOWNLOAD is a
(mostly) arch-independent download, where 1 or more of DOWNLOAD_* may be needed
to override it. However, the absence of DOWNLOAD and the use of DOWNLOAD_*
communicates that there are no arch-agnostic downloads; every download tarball
is arch-specific.
>
> 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and
> DOWNLOAD_X86_NAME, space-separated optional strings, which, if
> present, specify what the results of download should be named. If
> they are absent, current logic is not changed.
Similarly, DOWNLOAD_NAME is arch-agnostic, while DOWNLOAD_X86_NAME,
DOWNLOAD_X86_64_NAME, and DOWNLOAD_AARCH64_NAME provide overrides for their
respective arch.
>
> Please, consider the upsides and downsides of this RFC.
If this RFC is implemented, future changes could support DOWNLOAD_${ARCH} and
DOWNLOAD_${ARCH}_NAME.
By the way, I'm not explicitly supporting or NAKing this proposal. I'm just
trying to help clarify the meaning of the new names.
Erich
>
> --
> Your sincerely,
> Vladimir Nikishkin (MiEr, lockywolf)
> (Laptop)
> ___
> SlackBuilds-users mailing list
> SlackBuilds-users@slackbuilds.org
> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - https://slackbuilds.org/faq/
___
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - https://slackbuilds.org/faq/
[Slackbuilds-users] [RFC] Adding features to .info format.
Hello, colleagues There have been repeated discussions about two features that the current .info file format is missing: 1. aarch64 architecture. If in the past slarm64 was still an unofficial port, with -current it is official, and quite widely available, given the number of RPi machines available. 2. urls of the form https://example.test/address/ and https://example.test/address/1.json , which are either not supported by wget or can be mixed with each other, if downloaded into the same directory, which is especially bad with Golang and Haskell builds, which have many package-components, called 1.json. To address this issue, I propose a backward-compatible change to .info files format. 1. add DOWNLOAD_AARCH64 and DOWNLOAD_X86, a space-separated bash-string-list, identical in function to DOWNLOAD and DOWNLOAD_X86_64 2. add DOWNLOAD_NAME, DOWNLOAD_X86_64_NAME, DOWNLOAD_AARCH64_NAME, and DOWNLOAD_X86_NAME, space-separated _optional_ strings, which, if present, specify what the results of download should be named. If they are absent, current logic is not changed. Please, consider the upsides and downsides of this RFC. -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
