Re: [Rpm-maint] [rpm-software-management/rpm] Use C.UTF-8 instead of C if available (PR #2616)

2023-08-15 Thread Panu Matilainen
FWIW, the C.UTF-8 availability detection seems ugly and clumsy, and I have no 
idea whether it works on non-glibc (tested on Fedora 38). Better ideas welcome.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2616#issuecomment-1678819069
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] macros.in: ___build_pre_env default to LANG=C.utf8 (PR #2607)

2023-08-15 Thread Panu Matilainen
Closed #2607.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2607#event-10096337074
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] macros.in: ___build_pre_env default to LANG=C.utf8 (PR #2607)

2023-08-15 Thread Panu Matilainen
Superceded by #2616 but thanks for the initiative!

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2607#issuecomment-1678817359
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Use C.UTF-8 instead of C if available (PR #2616)

2023-08-15 Thread Panu Matilainen
Mostly everything around us is UTF-8 these days, we need to get on with the 
times. Especially now that glibc >= 2.35 finally supports it too. Attempt to 
detect C.UTF-8 availability in cmake and prefer when available, fall back to C 
when not.

Fixes: #2587
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/2616

-- Commit Summary --

  * Use C.UTF-8 instead of C if available

-- File Changes --

M CMakeLists.txt (13)
M build/files.c (2)
M config.h.in (1)
M macros.in (2)
M rpmio/rpmglob.c (4)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/2616.patch
https://github.com/rpm-software-management/rpm/pull/2616.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2616
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] rpm-4.18.0 embeds build machine CPU count (Issue #2343)

2023-08-15 Thread Bernhard M. Wiedemann
Found another reproducibility problem with expanded .spec in
https://code.opensuse.org/package/texlive/blob/d820a867c61524278af352b4febbb115e9dad08f/f/texlive.spec#_287
```spec
%{expand: %%global options %(mktemp /tmp/texlive-opts.)}
```

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2343#issuecomment-1678814874
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Regression on detecting 7zip helper utility (Issue #2608)

2023-08-15 Thread Panu Matilainen
Closed #2608 as completed via #2614.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2608#event-10096181879
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Fix cmake transition regression on 7zip utility discovery (PR #2614)

2023-08-15 Thread Panu Matilainen
Merged #2614 into master.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2614#event-10096181720
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Panu Matilainen
Closed #2615.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#event-10095693899
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Panu Matilainen
Actually, scratch all that.

This is one of those cases where writing it down makes you come to your senses. 
You can't solve an ambiguity by flipping it to mean the other thing.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#issuecomment-1678716901
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Panu Matilainen
I'm curious: in what situation would you use %optflags in %check? (if you have 
a practical example in a spec, even better)

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#issuecomment-1678634886
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Tomasz Kłoczko
I want only point that %optflags could be used in %check.
I don not remember even one case when such change would be necessary.
👎 

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#issuecomment-1678625213
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


Re: [Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Panu Matilainen
To clarify, I'm not particularly hell-bent on pushing this through, my primary 
motivation here is to have some discussion on and around the topic.

For all I know, the existing behavior of letting host %optflags through to 
noarch packages could even be intentional. This gets kinda philosophical as to 
what a noarch package is: should only the output of the build process be 
considered wrt arch-independence, or does the build process and the tooling 
used there matter?

As in, if a package compiles a tool  that is then used to produce 
arch-independent data which is then packaged, is it a noarch package? If we 
consider anything but the output itself, it gets *extremely* blurry.

No matter which way one looks at it, it'll be wrong for somebody unless we 
separate all macros for build (the system on which the package is built) and 
host (the system where the built package will be used), and packagers adopt the 
convention of treating noarch builds as an actual cross-build kind of thing...

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615#issuecomment-1678587881
You are receiving this because you are subscribed to this thread.

Message ID: ___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint


[Rpm-maint] [rpm-software-management/rpm] Make %optflags empty on noarch target (PR #2615)

2023-08-15 Thread Panu Matilainen
As there hasn't been any optflags set for noarch, whatever flags from the 
current host end up there and even in the produced binary and source rpms. 
Which seems decidedly wrong for a noarch package, and hurts reproducibility of 
said packages for no good reason.

Inspired by this bug report which reveals that cmake use in otherwise noarch 
packages ends up on relying on %optflags being set up for the architecture 
we're running on:
https://bugzilla.redhat.com/show_bug.cgi?id=2231727
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/2615

-- Commit Summary --

  * Make %optflags empty on noarch target

-- File Changes --

M rpmrc.in (2)
M tests/rpmgeneral.at (17)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/2615.patch
https://github.com/rpm-software-management/rpm/pull/2615.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2615
You are receiving this because you are subscribed to this thread.

Message ID: 
___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint