Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

There is no "new evaluate on declaration thing". Rpm always evaluates macros when it parses lines. How do you think macros like ``` %perl_req Requires: perl = %{perl_version} ``` work? You can also do something like this: ``` %define p0 Patch0: patch.diff %p0 ``` There is no way to get rid of

[Rpm-maint] [rpm-software-management/rpm] Warn on undefined macro uses in specs (#1170)

Implement a warn-on-undefined macro use flag in the macro engine, use when parsing specs. We only cover %{...} macros as specs consist of numerous directives starting with % that are not macros at all. This uncovers a mountain of dirt, including in our own test-suite. You can view, comment on, or

Re: [Rpm-maint] [rpm-software-management/rpm] Warn on undefined components in buildtree macros (#1169)

Actually, lets see if we can aim a little higher. -- 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/1169#issuecomment-610932495___

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> 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

Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)

Damns you're right: $ rpm -q rpm rpm-4.15.1-3.mga8 $ rpm --eval %mkrel %{1}.mga8 $  sudo urpmi --auto-select (…) $ rpm -q rpm rpm-4.15.90-0.git14971.0.3.mga8.x86_64 $ rpm --eval %mkrel %mkrel Here's the output of rpm --showrc|grep ^Macro for both: -Macro path:

Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)

Closed #1167. -- 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/1167#event-3213830018___ Rpm-maint mailing list

[Rpm-maint] [rpm-software-management/rpm] Warn on undefined components in buildtree macros (#1169)

Issue a warning if buildtree macros (%_sourcedir etc) contain undefined macros after expansion, such as things only defined during spec parse. This always was a murky case that doesnt work in all scenarios, so a warning seems appropriate. Actual behavior doesnt change here though. You can view,

Re: [Rpm-maint] [rpm-software-management/rpm] Duplicate provides not merged (manual + fileattr) (#1166)

Fair enough. I'll workaround it by recommending to remove the manual provides. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] Duplicate provides not merged (manual + fileattr) (#1166)

Closed #1166. -- 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/1166#event-3213673962___ Rpm-maint mailing list

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> After several days and multiple requests, you’ve still not proposed any > clear, common and future-proof place where to put Source declarations in > those specs. I think it's been pointed out several times now that it's not a matter of spec tag order, but macro definition. Citing @mlschroe

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> > 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

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> > 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

Re: [Rpm-maint] [rpm-software-management/rpm] fix testsuite on Mageia (#1156)

This looks like a symptom of something in the build environment rather than something to do "fix" in rpm. This isn't exactly my area of expertese, but if I had to hazard a guess, I'd say glibc isn't being entirely stripped of debuginfo data. -- You are receiving this because you are

Re: [Rpm-maint] RPM 4.16.0 alpha released!

On 4/7/20 6:18 PM, Thierry Vignaud wrote: Le lun. 23 mars 2020 à 15:47, Panu Matilainen > a écrit : On 3/23/20 3:22 PM, Panu Matilainen wrote: > > So soon you say? Well, its almost a year since 4.15 alpha and annual > release schedule isn't *that*

[Rpm-maint] [rpm-software-management/rpm] Support DSA2 in digest_libgcrypt.c (#1168)

For DSA2 we need to truncate the hash to the size of the pubkeys Q value. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/1168 -- Commit Summary -- * Support DSA2 in digest_libgcrypt.c -- File Changes -- M

Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)

Also with copy-pasting the %mkrel macro to my ~/.rpmmacros it works just fine. It's a matter of rpm not looking in the place that %mkrel is defined. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub:

Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)

I'm don't know what such a change would be. You're getting that error because %mkrel is undefined, for whatever reason - the error message clearly shows its not getting expanded at all. This is trivial to demonstrate: ``` [pmatilai︎lumikko SPECS]$ cat relmacro.spec Name: relmacro Version: 1.0

[Rpm-maint] [rpm-software-management/rpm] rpm-4.16.0a regression in rpmbuild: "Tag takes single token only" (#1167)

Hi There's a regression in rpmbuild in 4.16.0 alpha: $ rpmbuild -ba ~/rpmbuild/SPECS/foobar.spec error: line 5: Tag takes single token only: Release:%{mkrel 1} This basically breaks building all of 13 000 packages in Mageia because all of them use this: Release: %mkrel 1 Which expands

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> 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 continue to

Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: spec tag order and side-effects (#1161)

> You did not write which one was removed, but from the effects I see I suppose > it was the expansion on use, right? but from the effects I see I suppose it > was the expansion on use, right? Actually it was expanded more than twice, more like half a dozen times at different sites of use. >