8:27 p.m.
Hi folks,
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Example of real build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
9:39 p.m.
On Mon, Jun 17, 2019, at 9:28 PM, Igor Gnatenko wrote:
Hi folks,
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Example of real build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
Here's the related commit
https://src.fedoraproject.org/rpms/rust-grep/c/0a403fe91cdcab17a37928f34e...
3:19 a.m.
Dne 18. 06. 19 v 3:27 Igor Gnatenko napsal(a):
Hi folks,
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Example of real build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
On the Change page we have two examples: one general minimal example and example of Rust.
If any of you have more examples how to dynamically generate BuildRequires e.g., for nojs,
ruby, golang... then please
send it to me privately or here in this thread. I would love to add it to the
documentation.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
4:39 a.m.
Le 2019-06-18 10:19, Miroslav Suchý a écrit :
Dne 18. 06. 19 v 3:27 Igor Gnatenko napsal(a):
> as of today, builders have been updated (thanks to Kevin) and
> DynamicBuildRequires finally work in Rawhide.
>
> Change Page:
> https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
> Example of real build:
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
On the Change page we have two examples: one general minimal example
and example of Rust.
If any of you have more examples how to dynamically generate
BuildRequires e.g., for nojs, ruby, golang... then please
send it to me privately or here in this thread. I would love to add it
to the documentation.
The necessary tooling is already available Go-side and has been pushed
as part of the
https://fedoraproject.org/wiki/Changes/Adopt_new_Go_Packaging_Guidelines
change last week (in rawhide only because it depends on changes in
redhat-rpm-config not available in previous releases).
As documented in the templates provided in go-rpm-templates, activating
them is just a
%go_generate_buildrequires
call in %generate_buildrequires
https://pagure.io/go-rpm-macros/blob/master/f/templates/rpm/spectemplate-...
(you need the rest of the Go packaging template for this to work)
As noted in the template, this generates un-versioned BuildRequires
(like our automated Go Requires).
Versioning information will be available after we switch to modules our
Go stack (the Golang module concept, not the Fedora one). That means Go
1.14 at the earliest, end of the year. The module support in Go 1.13,
scheduled for this summer, is not complete enough to be used in rpm
packages.
@eclipseo: that means you can re-add automated BuildRequires to our Go
packaging guidelibnes, it was removed because the Fedora infra was not
ready yet.
Regards
--
Nicolas Mailhot
4:16 a.m.
Le 2019-06-18 10:42, Miro Hrončok a écrit :
On 18. 06. 19 3:27, Igor Gnatenko wrote:
> Hi folks,
>
> as of today, builders have been updated (thanks to Kevin) and
> DynamicBuildRequires finally work in Rawhide.
All of the following works? Koji, mock and copr?
Mock already worked IIRC.
Regards.
--
Nicolas Mailhot
4:42 a.m.
* Koji -- yes
* Mock -- yes
* COPR -- no idea
Koji and Mock are definitely only if you use rawhide chroot.
On Tue, Jun 18, 2019 at 11:41 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
>
> On 18. 06. 19 3:27, Igor Gnatenko wrote:
> > Hi folks,
> >
> > as of today, builders have been updated (thanks to Kevin) and
> > DynamicBuildRequires finally work in Rawhide.
>
> All of the following works? Koji, mock and copr?
>
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
8:54 a.m.
Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a):
* Koji -- yes
* Mock -- yes
Since
https://github.com/rpm-software-management/mock/wiki/Release-Notes-1.4.15
but it has to be enabled manually in config.
Since version 1.4.17 (yet to be released) it will be enabled by default, and you will
option to disable it.
* COPR -- no idea
Not yet. Koji use patched version of Mock (Igor discovered one issue after release). In
Copr we will wait for Mock
1.4.17 and once it will hit Fedora stable, it will automagically start working in Copr.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
2:38 p.m.
On Tuesday, June 18, 2019 3:54:41 PM CEST Miroslav Suchý wrote:
Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a):
> * COPR -- no idea
Not yet. Koji use patched version of Mock (Igor discovered one issue after
release). In Copr we will wait for Mock
1.4.17 and once it will hit Fedora stable, it will automagically start working
in Copr.
I think Koji has mock 1.4.16-2 installed from infra tags repo [1]. The only
problem is that Copr uses F30 (koji is F29). Why not to build the same mock to
the f30 infra tags too, so Copr doesn't have to stay behind...?
[1] https://kojipkgs.fedoraproject.org/repos-dist/f29-infra/latest/x86_64/pkg...
Pavel
3:14 p.m.
On Wednesday, June 19, 2019 9:38:40 PM CEST Pavel Raiskup wrote:
On Tuesday, June 18, 2019 3:54:41 PM CEST Miroslav Suchý wrote:
> Dne 18. 06. 19 v 11:42 Igor Gnatenko napsal(a):
> > * COPR -- no idea
>
> Not yet. Koji use patched version of Mock (Igor discovered one issue after
> release). In Copr we will wait for Mock
> 1.4.17 and once it will hit Fedora stable, it will automagically start working
> in Copr.
I think Koji has mock 1.4.16-2 installed from infra tags repo [1]. The only
problem is that Copr uses F30 (koji is F29). Why not to build the same mock to
the f30 infra tags too, so Copr doesn't have to stay behind...?
[1] https://kojipkgs.fedoraproject.org/repos-dist/f29-infra/latest/x86_64/pkg...
Ok, f30 infra is still brokne -- but Mirek submitted regular update for
F30 [1] so even better (users will have *that* mock as well). Once it
reaches stable, it will be propagated to Copr builders automatically.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-efe97323a7
Pavel
2:32 a.m.
On Wednesday, June 19, 2019 10:14:34 PM CEST Pavel Raiskup wrote:
Mirek submitted regular update for F30 [1] so even better (users will
have
*that* mock as well). Once it reaches stable, it will be propagated to Copr
builders automatically.
[1] https://bodhi.fedoraproject.org/updates/FEDORA-2019-efe97323a7
I've checked this is working fine now [2] even in Copr. Thanks to everywone
involved!
[2]
https://copr-be.cloud.fedoraproject.org/results/praiskup/ping/fedora-rawh...
Pavel
4:15 a.m.
Le 2019-06-18 03:27, Igor Gnatenko a écrit :
Hi folks,
Hi
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page:
https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Example of real build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
Wonderful, that was quick. Just to be clear, does that include copr in
addition to koji, or is it limited to koji for now?
Regards,
--
Nicolas Mailhot
3:21 p.m.
On 6/17/19 8:27 PM, Igor Gnatenko wrote:
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page:https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
Example of real build:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1286391
Cool!
Any long term plans to support C/C++ apps?
I know those are all over the map with regards to build tools, but maybe cmake/meson
could be supported?
6:32 p.m.
>>>> "MC" == Michael Cronenworth
<mike(a)cchtml.com> writes:
MC> Any long term plans to support C/C++ apps?
Depends on what you mean by "support", really. Really there's just a
new spec section that gets run and it just needs to echo a list of build
dependencies. That's really all this does; the existing Rust support
just hides the script within %cargo_generate_buildrequires. (Honestly
I'm disappointed that the macro doesn't emit the %generate_buildrequires
line as well; the pattern used by Rust currently builds in the
assumption that the generator will be a shell script.)
If there are more general methods for extracting build dependencies from
various build systems which can be stuffed into macros, then by all
means we should be adding them.
MC> I know those are all over the map with regards to build tools, but
MC> maybe cmake/meson could be supported?
Well, how do those list build dependencies? How would you extract them
and convert them to package names (or something else which is provided
by the target packages)?
- J<
6:41 p.m.
On 6/21/19 6:32 PM, Jason L Tibbitts III wrote:
Well, how do those list build dependencies? How would you extract
them
and convert them to package names (or something else which is provided
by the target packages)?
Yes, something would have to be invented, and I guess that's why no one replied.
However, the data exists it is just not available in a standard, parsable format.
7:16 p.m.
>>>> "MC" == Michael Cronenworth
<mike(a)cchtml.com> writes:
MC> Yes, something would have to be invented, and I guess that's why no
MC> one replied.
Well I replied, bit I'm behind on email so...
MC> However, the data exists it is just not available in a standard,
MC> parsable format.
And that was really my question: what data exists and what format is it
in? Honestly, I don't know; that's why I'm asking. There's a lot that
could be done, and it doesn't have to be perfect. (Certainly it's
better if it misses things because you can always just add them as
regular BuildRequires:, but it's tougher to deal with things added
erroneously.)
This can easily be offloaded to a separate tool; RPM only cares about
the output.
- J<
6:37 a.m.
Le vendredi 21 juin 2019 à 19:16 -0500, Jason L Tibbitts III a écrit :
(Certainly it's
better if it misses things because you can always just add them as
regular BuildRequires:, but it's tougher to deal with things added
erroneously.)
That's trivial to handle too, just add a
| grep -v 'bad_dep'
after the command that generates the bad dep in the spec (assuming it's
a clean generator that generaties one line per dep not something awful
to untangle)
And then open a bug so the generator gets fixed
Regards,
--
Nicolas Mailhot
6:47 a.m.
Le vendredi 21 juin 2019 à 18:32 -0500, Jason L Tibbitts III a écrit :
> > > > > "MC" == Michael Cronenworth
<mike(a)cchtml.com> writes:
I'm disappointed that the macro doesn't emit the
%generate_buildrequires
line as well;
I'm not real sure, this would work, for projects that contain stuff
involving multiple generators (composing multiple thing is one of the
key rpm does well and other tech not so much).
That would require rpm to merge all the %generate_buildrequires
sections transparently. And that would open the door for packagers to
interleave %generate_buildrequires with other things, wich is unlikely
to end well.
The explicit %generate_buildrequires forces packagers to think how this
is all sequenced (especially with %prep and %build commands). The point
in the spec where %generate_buildrequires is executed is not as self-
evident as one may think. It took at least a year of discussion
upstream for everyone to agree the design was correct.
--
Nicolas Mailhot
8:39 a.m.
On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:
Hi folks,
as of today, builders have been updated (thanks to Kevin) and
DynamicBuildRequires finally work in Rawhide.
Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
I'm curious why the config-for-MM-YYYY filename needs to contain the
month and year? Both why it needs to have a date at all, and why --
if it needs a date -- that doesn't include the day.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
8:46 a.m.
Dne 26. 06. 19 v 15:39 Richard W.M. Jones napsal(a):
On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:
> Hi folks,
>
> as of today, builders have been updated (thanks to Kevin) and
> DynamicBuildRequires finally work in Rawhide.
>
> Change Page: https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
I'm curious why the config-for-MM-YYYY filename needs to contain the
month and year? Both why it needs to have a date at all, and why --
if it needs a date -- that doesn't include the day.
I just wanted to generate something dynamically. Such package does not even exists.
It can be even as simple as:
%generate_buildrequires
# this will build requires package:
# zsh
echo "zsh"
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
9:06 a.m.
Le 2019-06-26 15:39, Richard W.M. Jones a écrit :
On Tue, Jun 18, 2019 at 03:27:41AM +0200, Igor Gnatenko wrote:
> as of today, builders have been updated (thanks to Kevin) and
> DynamicBuildRequires finally work in Rawhide.
>
> Change Page:
> https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
I'm curious why the config-for-MM-YYYY filename needs to contain the
month and year? Both why it needs to have a date at all, and why --
if it needs a date -- that doesn't include the day.
It's just an example. It could have used fruit(cake)
I suppose the date call is here to show up the dynamic aspect of the
feature, though it's a bad example
I'm pretty sure one could do things like
BuildRequires: %(echo config-for-$(date '+%m-%Y'))
on previous rpm versions and it would work.
What would not work before dynamic BuildRequires, is something akin to
%generate_buildrequires
cat deps.txt
with deps.txt included in the upstream source archive with a content
that changes over time. Without dynamic buildrequires you have no way to
act on this file because it is not available for processing before %prep
is done.
Of course this is also an over-simplified example, because there is
little chance that deps.txt exists in an rpm-compatible format upstream.
Usually you have some form of json, yaml or xml file that needs a custom
helper to be converted in rpm build deps. So in the real world you have
%generate_buildrequires
generate-foo-deps
with generate-foo-deps reading the default filename containing deps for
foo language, and converting it to rpm syntax.
Regards,
--
Nicolas Mailhot
1784
days inactive
1792
days old
21 comments
10 participants
participants (10)
-
Igor Gnatenko -
James Cassell -
Jason L Tibbitts III -
Kevin Fenzi -
Michael Cronenworth -
Miro Hrončok -
Miroslav Suchý -
Nicolas Mailhot -
Pavel Raiskup -
Richard W.M. Jones