Re: [Rpm-maint] [rpm-software-management/rpm] transfiletriggerpostun doesn't work when rpms are removed. (Issue #2324)
It'd be really helpful if you can turn this into a minimal reproducer that we could then include in the test-suite. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2324#issuecomment-1352690084 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> > For backward-compatibility and to avoid surprises, default to building > > x86_64 even on v2+ capable machines. > > Tested by running rpm --eval %_target_cpu and using rpmbuild with various > > BuildArch values on a x86_64_v3 host. > > Looks like my fix for the platform macros generation broke that part a bit. > While with `BuildArch: x86_64_v3` it spits out an `x86_64_v3` RPM, it uses > the `x86_64` optflags still. The only way to end up with `x86_64_vX` optflags > is by using `--target x86_64_vX`. What's the best way to end up with better > semantics? The reason for that is that `BuildArch` only sets `%_target_cpu`, but not anything else like `%_target` or `%optflags`: https://github.com/rpm-software-management/rpm/blob/e2c504c08381519c81774791fe6b82eb064a072e/build/parseSpec.c#L1012-L1025 IMO this can be treated as a separate bug (or is this intentional?). Opinions? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352898530 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
See issue #2319 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352900998 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
(Bottom line being: only use BuildArch for `BuildArch: noarch`. All other uses are not tested and also not documented.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352902953 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] RFC: Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> > The missing BMI and BMI2 are included in git master with > > https://sourceware.org/pipermail/libc-alpha/2022-October/142395.html > > meanwhile. OSXSAVE was still missing, I sent a patch for that: > > https://sourceware.org/pipermail/libc-alpha/2022-December/143936.html > > Once that is merged, glibc, GCC and RPM have matching definitions. > > This is actually a fine example why such voodoo needs to be determined in > exactly one place that everybody else then uses. Agreed. Mostly because the feature detection is platform and language specific and annoying to perform though - not because it's easy to get wrong. The list of features is rather short and clearly defined in a single place, so I'm not concerned about inconsistencies as much. > It's also a fine example why glibc is a _much_ better place for it than rpm: > those guys clearly know what they're talking about, Funnily enough in this case glibc was the only place that got it wrong in a way that actually matters (missing BMI/BMI2)... ATM glibc is in sync even without my patch for OSXSAVE. It turns out that in some other files the absence of OSXSAVE actually marks features such as AVX as unusable, so checking for those is enough. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352905238 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] Add x86-64 architecture levels (v2-v4) as architectures (PR #2315)
> See issue #2319 Perfect match - so indeed a mostly independent topic. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2315#issuecomment-1352967373 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] cannot use lua libraries in rpm4.14 and later (Issue #2309)
You still haven't explained what you're actually trying to do, "use lua" or "use library x" doesn't explain anything at all. What is the problem you are solving with these tools? Like said, rpm macros are nothing but a fancy text pre-processor. Complicated programming doesn't really belong there in the first place. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1353139327 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] cannot use lua libraries in rpm4.14 and later (Issue #2309)
> You still haven't explained what you're actually trying to do, "use lua" or > "use library x" doesn't explain anything at all. > > What is the problem you are solving with these tools? Like said, rpm macros > are nothing but a fancy text pre-processor. Complicated programming doesn't > really belong there in the first place. In macros I agree, but in scriplets one might well want to be able to e.g. edit complex file formats. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1353459293 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] cannot use lua libraries in rpm4.14 and later (Issue #2309)
There's the thing that complex macros don't belong to rpm spec files nor macro files either because the syntax of these files is undefined. It's not possible to tell what the files mean, not possible to parse them, not possible to test them. Then if the macros cannot be in the spec files nor macro files and they need access to some rpm macros that are defined in the rpm environment the only available option are lua files. Using existing lua libraries that are already tested outside of the rpm environment reduces the amount of code that is exclusive to rpm. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/2309#issuecomment-1353544348 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 changed some bytes of statically linked library (Discussion #2313)
I did another test, pack the same files in directory1 twice, then extract them to different directory, There is still a difference between the static library file，only a few bytes was changed, i use %!xxd to convert binary to hexadecimal，here are the header of the two files, Indicate distinction by bolding them, do you know what was changed, time？or something else? ! / 16711557**68** 0 0 0 29038 000: 213c 6172 6368 3e0a 2f20 2020 2020 2020 ! / 16711557**20** 0 0 0 29038 000: 213c 6172 6368 3e0a 2f20 2020 2020 2020 !https://github.com/rpm-software-management/rpm/discussions/2313#discussioncomment-4415866 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
