Looking back on my code, I see it required both the expanded and non expanded
variants. The general case is expansion (recursively, till there is nothing
else to process). However in less frequent but tricky cases expanding can be
premature and you really need to pass things as is (I've come to
If that works that will be terrific! However as usual the devil is in the
detail, is it available as a pre-built rpm somewhere or do one need to build
his own binary?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
BTW, the whole state of things is painful and frustrating to me too. If things
can not work out today let’s just forget about it for now. I’m not looking for
a fight and I have no energy left for arguing in circles.
--
You are receiving this because you are subscribed to this thread.
Reply to
@pmatilai Look, the only thing I care about lua side is being able to access
spec state easily and reliably. state = state of macros/variables, state of
flags and option passed to a macro, etc. The best macro logic in the world will
produce erroneous results if it is mistaken about spec state.
> Oh, looking closer:
>
> > @nim-nim wrote
> > [...]
> > exist because nil is not the same as false or empty
>
> Yes, nil is not same as empty. It however very explicitly is same as false,
> quoting https://www.lua.org/manual/5.4/manual.html#2.1:
(lua)
&g
https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/master/f/common.lua#_30
exists because nil is not the same as false lua-side.
And no I don’t remember out of hand all the problems it fixed. I definitely
*do* *not* want to remember them. Debugging the corner cases induced by the
@pmatilai given lua was added as a macro language because the built-in
constructs were driving everyone crazy as soon as you needed some non-trivial
processing I don’t find this argument too convincing :)
Anyway lua has built-in conventions for booleans and nil values, you can’t dump
blindly
@hroncok from the lua language POW you need a tristate for flags: nil (not
passed), true (passed as true), false (passed as false). Otherwise it’s real
easy to be confused when handling things that have a default state absent any
flag, or an antonym (with/without, quiet/verbose, etc), or
One
My understanding of the feature is that it will eventually require some
mecanism to reconciliate the subpackage metadata (that the feature directly
targets in the new section) and srpm metadata.
Because without such a mechanism, you’ll be asking packagers to be extra
careful to never put
That being said, the PR is a nice step in the right direction. It’s just that
its design has limits, and will probably not scale once you start mixing spec
generators with different ideas of where the dynamism should start or end. With
a single section at a single point of the spec generators
> %postbuild is misleading and dangerous. You need a dynamic starting point for
> every section that succeeds %post,
More generally, the problem you are attempting to solve, is not the lack or not
of a new rpm section, and the shredding or not of the existing spec file. Those
are all fuzzy
So here is some quick and hasty feedback (I was going to write a lot more, but
the laptop battery disagreed).
You need to make it possible to generate what exists in the preamble today,
because otherwise the common case where a SRPM generates a single subpackage,
and you want the SRPM metadata
Generally speaking it would be great to store more build-time information in
the spec. I’ve been requested to store the buildroot state for debuging and
reproducibility needs, for example.
If you wanted to fix %autosetup for multiple archives you’d need to change it
to behave the same way as %forgesetup/%forge_prep:
1. move things you’re used to pass on the macro CLI to control variables
attached to a specific source file, using naming tricks to implement the
attachment
2. make
I have an upstream that had the bright idea to put its project documentation
inside a
`5. Specimens & Test Files` (Specimen is jargon for rendering examples)
My automation correctly translates that into the following manifest lines, fed
to a `%files` section using -f
```rpm
%doc "./5.
Anyway, I needed to solve quite a lot of the problems involved in automated
packages to prepare the switch of Fedora Go packages to Go modules.
I will push soonish the result to redhat-rpm-config (not because the Go
automation is finished, I’d say it’s 90% done but in need of lots of testing,
rpm does not evaluate `%{name}` properly in sources, even when all the sources
have been moved to a separate `%sourcelist` section, after the preamble that
sets `%{name}`.
That breaks spectool
```console
$ rpmdev-spectool -R -g ~/fedora/fedpkg/fonts-rpm-macros/fonts-rpm-macros.spec
> @ffesti Thank you for sharing a different analysis and point of view. I’ll
> correct some things here (I don’t fundamentally disagree with what you wrote,
> but you made some shortcuts that would block a real-world design)
>
> > The current font and go macros are a pain to implement but -
@ffesti Thank you for sharing a different analysis and point of view. I’ll
correct some things here (I don’t fundamentally disagree with what you wrote,
but you made some shortcuts that would block a real-world design)
> The current font and go macros are a pain to implement but - obviously -
the
fonts code small and easy to read). The next set of go macros will start from
the factorisation achieved by the fonts macros (of course, go is intrinsically
harder, so it will probably stay more complex).
> But @nim-nim, I agree that we need this functionality natively in RPM.
I don’t dis
It is user friendly. It is not maintenance friendly because it workarounds rpm
defficiencies (a lot of the complexity is creating lua arrays when rpm does
expose an array element)
> Exactly because of this. I don't want to have overcomplicated macros, I want
> simple configuration which I can
And, you absolutely need the pivot and subvariables set spec-wide, in the
preamble or some early section, because a lot of the domain info will be used
in several spec sections, not just in %files, %build, %whatever.
For example Free Desktop people invented the idiotic appstream descriptor for
After lots of refactorings, I’re reduced the complexity of fonts/go (not
published yer) header generation to the trivial
https://pagure.io/fonts-rpm-macros/blob/009ccace3f337f3410cf0b4b789af692fce766d7/f/rpm/lua/srpm/fonts.lua#_135
And setting the rpm variables that uses in a safe way in
> So I guess this is waiting for me to put my thoughts here…
A lot of those things are already handled Fedora-side in our fonts and go
packaging macros.
1. you define a pivot `%{fooX}` variable, with X a suffixed index à la
%{SOURCEX}. If it is present in the spec file, that means you need to
(and again, there is also the possibility to provide a working %description
closing statement, which would enable putting Sources and Patches just before
`%prep`, which is the correct code flow location for those 1570 specs, and
aligns with your internal rpm behaviour requirements)
--
You are
@pmatilai I can not leave the specs “alone”. There are lots of packagers
involved. I can not forbid them to set sourcedir, and I can not forbid them to
add patches to their spec files, using %{name} as is the Fedora best practice,
which breaks instantaneously (as evidenced by the dejavu case).
> (The downside of expanding multiple times is that it is not easy to have a
> literal '%' character in the patch name.)
Not a problem anymore, there is a `%{literal}` (or whatever it ended up being
called) in rpm now
--
You are receiving this because you are subscribed to this thread.
Reply
@panu: then I will apply your advice blindly, as you give it blindly, and
you'll have 1570 FTBS packages in a week.
Do you think you’re the only one who can play the idiot?
Just give me a canonical pattern for those two specs and I’ll shut up.
You seem utterly unable to do so. Maybe that’s
> Please stop spreading FUD about thousands of specs breaking. They're building
> just fine, here's an
> example scratch-build:
> https://koji.fedoraproject.org/koji/taskinfo?taskID=43124256
The *documented* *official* packaging pattern this change broke is used by at
least fonts and go
> > sil-mondulkiri-fonts and sil-mondulkiri-extra-fonts are representative of ~
> > 1000 Fedora specs (not just fonts, I gave 2 fonts specs as testcases
> > because they are simpler without %build-related complexity).
>
> And to make this clear to anybody observing this discussion, these
> > Can it be fixed to expand on use? That’s the useful functional place to do
> > it.
>
> It's still effectively on the first use, the gotcha is that the first use is
> actually by rpm itself right
That’s 100% uninteresting for rpm users, because that make specs depend on
internal ill
@mlschroe Thanks for the clarification. You did not write which one was
removed, but from the effects I see I suppose it was the expansion on use,
right?
Can it be fixed to expand on use? That’s the useful functional place to do it.
To quote the first message in the issue:
> I tend to be of
@ffesti then please propose a solution for the two posted spec files. That’s
just 2 spec files. They’re not even doing any complex building, just copying
stuff around. That should not be hard if you understand the change implications
(I definitely do not).
If just 2 specs defeat you, how can
> @nim-nim, I'm also just stating facts I can verify. The changed behavior does
> exist in rpm 4.15, I can trivially reproduce that here. So somehow the lines,
> or facts, don't seem to meet. I don't know what to make of that, so I'm
> trying not to draw any conclusions before
@pmatilai I’m just stating facts, some of the broken specs were not even
written before april of this year, so it is 100% impossible they passed using
an older rpm version (and their main build box runs rawhide, not even F32 beta).
I gave you concrete, actual production Fedora spec files in the
The breakage didn’t land in Fedora in June 2019.
It breaks specs that passed validation and import as late as Fedora 32 freeze
(2020-02-25). ie stuff so recent and shiny it has not even landed user-side yet.
You won’t see any mass breakage from this change before the next Fedora mass
rebuild,
You can have the same effect with %{name} as part as the source or patch
filename (which is hardly unknown-of, and is the best practice Fedora-side for
naming patches for example), so the sourcedir part, while an easy way to
trigger the problem, is not the only way to trigger it.
--
You are
As i said in the rhbz issue, no problem adapting existing specs and guidelines
to some new ordering, as long as this ordering is clearly defined and rpm
upstream commits to it.
However, I am completely opposed to changing things that worked in the previous
undefined space, to something that
And BTW, please do not add more breakage just to prove rpm upstream can break
as many things as it wants to.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Then just back-out the change. It’s sole justification is to make things
“cleaner”. Now, as soon as it breaks existing specs, you tell us things are
arbitrary and will be continue arbitrary.
Well if that is the case there is *zero* justification to break the existing
spec landscape. If things
> I tend to be of the opinion that this is to be expected, you need to define
> values before you can use it,
> But all this does raise questions about the allegedly free order of spec tags
> (and sections). Clearly it never was entirely free due to side-effects such
> as the above, but it for
The change break specs that relied on early Source definition to workaround the
unbounded behaviour of `%description`
* SourceX then (sub)package headers →
```
error: Bad source:
/var/lib/builder/rpmbuild/SOURCES/%{name}/dejavu-fonts-version_2_37.tar.gz: No
such file or directory
```
That would be awfully nice. The more native elements (macros variable tags) can
be manipulated/set/unset from lua, the less we need to worry about the legacy
rpm tangle. I don’t think anyone wants to write and maintain complex logic
using the native rpm macro language, it’s just that pushing
Even you you do not touch the existing spec tangle, we need to produce new spec
tangles all the time, so what can rpm do to make the new spec tangles more
sane? State of upstream projects is not frozen, tooling needs to grow like the
projects it processes.
--
You are receiving this because
Well, if it existed I would not request it :)
It is part of adapting rpm to today’s software projects, that require more
subpackaging and more subpackaging context than traditional `make install`
things. Dev tools get more parametric, handling the result requires heavier
variable passing.
--
It’s not a lua vs non-lua thing. I’m an heavy lua user myself. I expect that
this feature would unlock more lua use, not less.
While very cool and useful, lua is ultimately limited by the stage at which lua
expressions are evaluated. So, no matter how much lua you add to a spec, you
need, at
Thanks for the feedback! It makes me realise, that I forgot to emphasise things
that were obvious to me (as a packager).
A scope needs an explicit name/anchor to be useful packaging side. It’s not a
local vs global thing, it’s a “I do build things for context X now” and an
later “I do checks
Right now a lot of things need special tags in rpm just because they have a
specific (usual subpackage) scope, and can be declared in multiple scopes
Please add a generic construct to specify the scope of a set of variable, so
those special Tag constructs can be ultimately replaced by easy to
Right now a lot of things need special tags in rpm just because they can be
declared multiple times (for example `Requires`).
Tags are hugely inconvenient to manipulate in spec automations because they all
come with their special handling requirements.
Please add real array primitives to rpm,
While anything would be better than the current situation, from a rpm user POW,
I'd like less magic and special things in rpm, and more generic operators and
constructs.
IE, everything is a variable, except for things that need multiple
declarations, and use tags.
SourceX as a tag is IMHO a
Thanks, I need to investigate if #860 solves the problem for me
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
FYI I’ve converged on this pattern for my own packaging macros
```rpm
%foometa → munge upstream metadata into rpm metadata
%foopkg -a → create package headers
%foobuild -a → build
%fooinstall -a → install
%foocheck -a → check
%foofiles -a → create files section
```
Some upstreams are very new to git and are committing license file with
executable permissions.
rpmlint rightly points out something is suspicious
Since I can’t imagine a case where we would want to package an executable
license file, please attr license files by default to 0644, so packagers
That would definitely be useful, thanks for looking at it! Can you extend the
concept to macro arguments please? My macro files are full of:
```lua
local processall = (rpm.expand("%{-a}") ~= "") and (rpm.expand("%{-z}") == "")
localverbose = (rpm.expand("%{-v}") ~= "")
--
You are
Closed #960.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/960#event-2846800783___
Rpm-maint mailing list
@mlschroe Thank you that works (even if it’s not too intuitive)
Unfortunately the end result did not work out, due to the usual differences in
evaluation time between the rpm and shell layer :( So I guess it’s back to
doing things in the wrong section, or using a file to pass data, for me.
--
I’d like to be able to declare rpm variables, with a name constructed from
other rpm variables
```rpmspec
%global something%{suffix} value
```
Because I need to pass info from `%build` to `%install`, and `%build` may
execute the same operation for multiple subpackages.
The current way to do
@pavlinamv scrap it, it can not be aliased just within a macro file, because it
depends on the next line starting just after the marker. Or is there a way to
eat this next line safely?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it
@pavlinamv: that should work, thanks for the idea!
However, it is so smart and unintuitive, I doubt many will thing about it. A
clean marker (even if it's just an alias) would be better. Is that something
that could be added to official rpm macros or do I need to push it
`redhat-rpm-config`
Sometimes rpm variables need contain long lines of things
https://src.fedoraproject.org/rpms/golang-sigs-k8s-kustomize/blob/master/f/golang-sigs-k8s-kustomize.spec#_20
and reviewers, prompted by rpmdevtool, will ask to break those lines to less
than 80 columns
Unfortunately there is no easy way
Fantastic, thank you very much!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/593#issuecomment-496427088___
Rpm-maint mailing
I didn't suggest to apply the patches. That's a different part of the spec and
different spec verbs.
*However* to apply the correct patches to the correct source archive, you need
to know the corresponding patch list. So basically as many “list of patches”
as you can have source archives.
A
It would be nice to extend the %patchlist concept to have a %patchlist0
(patches to apply after extracting %source0), %patchlist1 (patches to apply
after extracting %source1), etc
That would get one step closer to deprecate the byzantine way %setup expects to
specify patch ordering in
It turns out that even an historic package like elfutils has to hack this in
`%check` because it's not done by default.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@Conan-Kudo `BuildRequires` are not attached to the subpackage, they’re
attached to the srpm, they are not part of “subpackage evaluation”. What trips
eclipseo is not srpm-misplaced-inside-subpackages is plain
subpackages-which-are-irrelevant-for-srpm-creation.
--
You are receiving this
> @nim-nim, @eclipseo: It would be deeply flawed if `rpmbuild(8)` allowed an
> invalid spec file to be used for a package build
@Conan-Kudo The spec is perfectly fine and valid, and the assertion will pass.
At the *right* time, when the parts the assertion checks against are ava
@ignatenkobrain,
@eclipseo is trying to add a manual `%pre` to a spec to fix past packaging
mistakes, applying one of the fedora fixup guidelines. It fails because the pre
applies to a part of the spec that is not generated before `rpmbuild -bb` (not
`rpmbuild -bs`) stage.
The `rpmbuild -bs`
@xsuchy: that was I thought too but the first install report in the log does
not have the problem. Unless mock uses a different dnf for different build
stages?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
> I need to re-check why `-r` was not used, whether there is a good reason or
> if it was just lost in the other breakage noise. Nevertheless that will only
> work (if it works) for the symlinks we generate ourselves, not those produced
> by upstream tools.
Ok, I dig up why relative symlinks
@xsuchy the glued `ArchVersion` (without separator) in package install reports
seems like a mock bug
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
```
INFO: mock.py version 1.4.14 starting (python version = 3.7.3)...
Start: init plugins
[…]
Finish: chroot init
Start: build phase for golang-github-sirupsen-logrus-1.1.0-1.0.fc31.src.rpm
Start: build setup for golang-github-sirupsen-logrus-1.1.0-1.0.fc31.src.rpm
Building target platforms:
@Conan-Kudo empty `%build` didn’t work so in the past, you needed no `%build`
section at all. If someone changed the logic to empty `%build`, that's gonna
break loads of specs
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on
Ok, with `rpm-4.14.2.1-7.fc31+buildreqs.1.x86_64` and
`mock-1.4.14-1.git.34.3723a7c.fc31.noarch` I see the whole build chain working.
*However* something seems to have broken debug generation logic, I get the
dreaded
```
Empty %files file /builddir/build/BUILD/logrus-1.1.0/debugsourcefiles.list
I need to re-check why `-r` was not used, whether there is a good reason or if
it was just lost in the other breakage noise. Nevertheless that will only work
(if it works) for the symlinks we generate ourselves, not those produced by
upstream tools.
--
You are receiving this because you are
Sure, computing the list needs to be done by the build system, since it's the
system that actually assembles the build root. But the build system needs a way
to store the resulting list in one of the produced rpm files, since ultimately
only those files are lept long-term.
Unless I'm missing
@ignatenkobrain you'll quickly see how inconvenient that is when you get to
compose multiple generators (as will happen eventually since multi-tech
projects do exist). There’s a good reason `Requires` delegate this filtering to
rpm, via `Provides`. It is real hard to do at the generator level
The people who asked this just wanted to access the info computed by koji (or
mock or copr) in the produced rpm files, without needing to connect to koji
(or mock or copr)
Not to mention, than mock and copr do not archive all build roots they are
cleaned up regulartly, the only thing that
It is a lot harder to create relative symlinks reliably in spec files,
especially when part of the creating is given to manual packaging. (I
simplified the example, you can have multiple levels of directories). The whole
point of the FHS is not to have to worry about relative locations.
--
I the current way Go sources are organised, a "provides" is a directory
containing Go source files. And projects are renamed all the time so it is
common to alias previous names by symlinks (or http redirects in github)
so you have things like
```
/usr/share/gocode/src/oldname →
The current `Provides`/`Requires` generation operates on a staging directory
tree simulating the target deployment. This is mostly fine, except it breaks
absolute symlinks within the staging directory. And, in some cases, those
symlinks (and their target) participates in `Provides`/`Requires`
@ignatenkobrain `rpm-build-4.14.2.1-7.fc31+buildreqs.1.x86_64` works for me:
```console
$ grep BuildRequires ~/fedora/rpm/golist/golist.spec
$ LANG=C.utf8 rpmbuild -ba ~/fedora/rpm/golist/golist.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.t0kf16
+ umask 022
+ cd
> @ignatenkobrain can you please send me some spec/src.rpm with dynamic
> dependencies?
@xsuchy you have another one here
https://copr.fedorainfracloud.org/coprs/nim/macros-ng/build/881699/
(needs the rest of the copr, and obviously failing to build in copr)
--
You are receiving this because
@ignatenkobrain your releases are not big enough to be picked up over the rpm
version in koji rawhide
Koji rawhide is already at release 6
https://koji.fedoraproject.org/koji/packageinfo?packageID=319
Also, the modified rpm seems to break some copr assumptions
* with `
Yes, I know, it's a next step kind of thing, the usefulness of `BuildProvides`
is not really evident, until you start generating `BuildRequires` automatically.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
This is a follow up on issue #104 (which is awesome, please ship it!)
For most projects, issue #104 is going to simplify things a lot and will be
sufficient by itself.
However it won’t be sufficient for complex projects. We’ve all forgotten that
those projects can build multiple objects, some
> The idea is that if one of the dependency is provided by any other package
> generated by this source package, then it would be replaced by reference to a
> package with exact EVR.
I'm pretty sure this would break a lot of rpm bootstrapping and re-layouting
scenarii. They often rely on
@eclipseo My understanding of things is that you just need to have a BR
generator that supports this distinction, no need for special rpm support
```rpm
%if %{with check}
generate-foo-buildrequires --full
%else
generate-foo-buildrequires --without-tests
%endif
```
That's the nice thing of
>
> On Tuesday, March 12, 2019 9:55:29 AM CET nim-nim wrote: I think there are
> two different things here, how you format rpmbuild error output to stdout/err
> Why we should care about 'rpmbuild' stdout/stderr here?
Because people do write scripts that call rpmbuild. It's a
@praiskup
> -1. I think that rpmbuild should assure that the shape of the output file is
> as deterministic as possible, no matter whether the packages are or are not
> already installed. I think it should be just a list of build requires without
> any prefix or so, without any header message,
Yes it would be really nice to get to the point where we can test generator
integration within rpm !
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
@jasontibbitts you're missing the expand part in your test
One example of real-world code are
https://pagure.io/go-rpm-macros/blob/master/f/rpm/macros.d/macros.go-rpm.internal#_96
(I really should push it so work can focus on improving the code and making
workarounds unnecessary, at least for
Thanks for the pointer. I'm afraid very few people know about this (me the
first)!
Please don't just test for non-zero, test any write on stderr, otherwise you
get those weird stderr messages appearing without any trace of what triggered
them.
--
You are receiving this because you are
I had to deal recently with an upstream, whose state caused one of the autodep
commands to write to stderr (and not output any of the the expected deps). I
think the language the autodep binary is written in allows non-blocking errors.
Traces are written to stderr, but processing tries to
Well here you have an example where `%{lua:` is used for a lua block not to
abuse anything, and it would be completely weird and un-intuitive to have to
escape the single empty line and not all the other end of lines.
However I should also say that having to sprinkle `\`s all over your macro
> Mock will have to parse output of rpmbuild - in case the rpmbuild fails due `
> %generate_buildrequires`. Parsing the output for `_("Failed build
> dependencies:\n")` is suboptimal. Especially because of `_()` and because
> `rpmpsPrint()` use `fprintf(f, "\t%s\n", msg);`. Can I have something
Yes sure I can shorten it my side, and then others will shorten it with a
slightly other convention their side, and it will all end up a huge mess.
It would be much better if the naming root was shorter in the first place so
others do not have to shop it. That's why prep is much nicer than
That being said, the langage br computation is done in
https://github.com/nim-nim/go-macros/commit/52c4bcc3dc2637483d6daeaefdc41cff1e0de95d
it can be plugged in a mock/rpm stack as soon as this part is ready
--
You are receiving this because you are subscribed to this thread.
Reply
> I am not at all against having scripts for normal dependency generation. But
> their are a few important differences to the BuildRequires:
>
> * They have to be attached to a sub package and cannot be global
>
> * We may want to (be able to) associate the script to files - so we need
Some rpm consumers would like to analyse what deps were used to produce a
particular package.
https://github.com/gofed/go-macros/issues/2
Right now this is logged by tools like koji (because only the buildsystem knows
what it put in the buildroot), but having to access those tools post-build is
But anyway, it could be done with asciidoc syntax if you prefer. I don't care
much as long as paragraph breaks, lists, and probably bold and italic are
unambiguously specified and can be converted to other formats without brittle
heuristics. And probably support stripping of ` from
1 - 100 of 179 matches
Mail list logo
