On Fri, May 6, 2022 at 12:17 PM Marián Konček wrote:
>
> I agree with Vit, I want to add to this:
>
> * still having to maintain a custom script is not an improvement over our
> current situation.
> * make sure that $VERSION can be processed, there are cases when for example
> the tilde "~"
I agree with Vit, I want to add to this:
* still having to maintain a custom script is not an improvement over
our current situation.
* make sure that $VERSION can be processed, there are cases when for
example the tilde "~" needs to be swapped for dash "-".
* More complex case of $VERSION:
Dne 05. 05. 22 v 19:35 Fabio Valentini napsal(a):
On Tue, Apr 26, 2022 at 1:50 PM Marián Konček wrote:
Adding onto this, as I mentioned an additional step, I can also imagine
defining some macros which would be used in the .spec file. We could
have a simple generic one that would be available
On Tue, Apr 26, 2022 at 1:50 PM Marián Konček wrote:
>
> Adding onto this, as I mentioned an additional step, I can also imagine
> defining some macros which would be used in the .spec file. We could
> have a simple generic one that would be available within rpm with the
> extension possibility
Dne 26. 04. 22 v 12:40 Vít Ondruch napsal(a):
Dne 25. 04. 22 v 10:41 Vít Ondruch napsal(a):
We already have signature of source files as additional source.
Do you mean the 'sources' file?
I mean
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures
Miroslav
Adding onto this, as I mentioned an additional step, I can also imagine
defining some macros which would be used in the .spec file. We could
have a simple generic one that would be available within rpm with the
extension possibility of each working group defining their own macros
which they
> Dne 25. 04. 22 v 10:41 Vít Ondruch napsal(a):
>
> We already have signature of source files as additional source.
Do you mean the 'sources' file?
1) This is dist-git feature, external to RPM, which is quite unfortunate.
2) There are certainly requests to include this into .spec file:
> On Mon, Apr 25, 2022 at 10:51 AM Vít Ondruch I also assume that the CI you're talking about already calls spectool
> to download package sources for new versions
I don't think that Koji simple CI nor Zuul does this.
BTW sorry, I just noticed that I have not received ~5 mail from this thread.
On Tue, Apr 26, 2022 at 11:49 AM Fabio Valentini wrote:
>
> On Tue, Apr 26, 2022 at 10:08 AM David Bold
> wrote:
> >
>
> > I think it does require some changes to CI, otherwise, this will execute
> > untrusted code when all it was supposed to do is download. I do
> > currently assume that I
On Tue, Apr 26, 2022 at 10:08 AM David Bold wrote:
>
> I think it does require some changes to CI, otherwise, this will execute
> untrusted code when all it was supposed to do is download. I do
> currently assume that I can run `spectool -g` on an untrusted spec to
> look at the source code,
On 4/25/22 13:42, Fabio Valentini wrote:
On Mon, Apr 25, 2022 at 10:51 AM Vít Ondruch wrote:
2) Standalone script does not solve the main issue and that is a way CI could obtain the tarball.
Of course you mentioned "with support for extraction in spectool", but that is also part
of the
On 25/04/2022 14:54, Fabio Valentini wrote:
How would the program know if
this Source is one that should be executed, or not?
We can execute SourceX files with chmod 0755 and .sh extension.
Which is why I suggested to use a marker comment like "# SourceScript: foo.sh".
It will not be
Dne 25. 04. 22 v 10:41 Vít Ondruch napsal(a):
1) Standalone script is kind of against RPM philosophy, where the idea always was that the .spec file should contain
everything.
We already have signature of source files as additional source.
But the additional section as suggested by Marián
+1 to using an rpm macro to avoid adding an external script, if spectool can
work with it.
Something like:
%global source0_generate_script ( \
curl ... \
rm -rf ... \
tar ... )
I'm not sure if that syntax is correct.___
devel mailing list --
On Mon, Apr 25, 2022 at 2:46 PM Vitaly Zaitsev via devel
wrote:
>
> On 25/04/2022 13:42, Fabio Valentini wrote:
> > For example, we could use something like:
> > # SourceScript: gen_clean_tarball.sh
>
> Source1: gen_clean_tarball.sh
Well, doing that alone wouldn't work. How would the program
On Mon, Apr 25, 2022 at 7:51 AM Fabio Valentini wrote:
>
> On Mon, Apr 25, 2022 at 10:51 AM Vít Ondruch wrote:
>
> > 2) Standalone script does not solve the main issue and that is a way CI
> > could obtain the tarball. Of course you mentioned "with support for
> > extraction in spectool", but
On 25/04/2022 13:42, Fabio Valentini wrote:
For example, we could use something like:
# SourceScript: gen_clean_tarball.sh
Source1: gen_clean_tarball.sh
That would make it easy for spectool to parse this information from
the .spec file, and then execute the program with that name.
Can be
On Mon, Apr 25, 2022 at 10:51 AM Vít Ondruch wrote:
> 2) Standalone script does not solve the main issue and that is a way CI could
> obtain the tarball. Of course you mentioned "with support for extraction in
> spectool", but that is also part of the issue, because that would need the
>
I would also be interested in this. In our set of java packages we have
a few cases where upstream releases .jars with bundled binary files
which either cannot be stored within .src.rpm files because of licensing
issues or because they would be unreasonably large. Example here:
Dne 21. 04. 22 v 14:58 Miroslav Suchý napsal(a):
Dne 21. 04. 22 v 13:20 Vít Ondruch napsal(a):
Now I am looking for feedback about general approach. Of course it
could be somehow polished and improved to hide some boiler plate.
This part:
%{echo:%(
[ ! -e %{S:1} ] &&
Looks really clumsy.
On 21/04/2022 13:20, Vít Ondruch wrote:
It is quite common, to have some sources, which are not available as a
tarball from upstream. In case of rubygem- packages, they quite often do
not ship their test suites. In this case, our .spec file contains
something like [1]:
I prefer a separate
Dne 21. 04. 22 v 13:20 Vít Ondruch napsal(a):
Now I am looking for feedback about general approach. Of course it could be somehow polished and improved to hide some
boiler plate.
This part:
%{echo:%(
[ ! -e %{S:1} ] &&
Looks really clumsy. After reading the
22 matches
Mail list logo
