Re: [Rpm-maint] [rpm-software-management/rpm] Remove "support" for loading keyring from filesystem (#857)

Yes this is actively used by the Yocto Project. It allows us to have a single location in the system that contains all of the software keys, and can be updated dynamically by authorized systems/components. Having to load keys (manually) into the rpm database, makes it very difficult to

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

@pmatilai someone brought to my attention today there is various confusion as to what 'armv8' actually means (for a package type). Does it mean traditional 32-bit ABI using instructions available on an 'ARMv8' processor? or does it mean using ILP32 ABI using all of the aarch64 instructions?

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

@berolinux Just to be clear, I -have- a customer who has asked for armv8 WITHOUT NEON/VFP. This was obviously in the embedded space, but the same customer is saying that it's not for compatibility, but is actually a 32-bit 'armv8' processor. (No 64-bit support..) I have no idea if those

Re: [Rpm-maint] [rpm-software-management/rpm] Add armv8* arch variants to rpmrc.in (#425)

mhatle commented on this pull request. > @@ -80,6 +80,10 @@ optflags: armv6hl -O2 -g -march=armv6 -mfloat-abi=hard > -mfpu=vfp optflags: armv7l -O2 -g -march=armv7 optflags: armv7hl -O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 optflags: armv7hnl -O2 -g -march=armv7-a

Re: [Rpm-maint] [rpm-software-management/rpm] find-debuginfo.sh expects ELF-files to be executable (#422)

My understanding is that this was done as way to allow the package maintainer to PREVENT debug processing. There are numerous cases, where the debugedit split/strip behavior can trigger problems. So by using the executable flag, it was easy to disable special processing for those items. --

Re: [Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

On 10/12/17 4:52 AM, Neal Gompa wrote: > On Mon, Oct 9, 2017 at 11:25 AM, Richard Brown wrote: >> >> What do you all think? And if a change like this is on the cards as an rpm >> default, where would the likely >> location be? >> > > So, I think we should probably expose this as

Re: [Rpm-maint] [rpm-software-management/rpm] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

@Conan-Kudo patch for what? Generally speaking switching from fakeroot/fakechroot to pseudo should be seamless... (simple search/replace) -- 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] Revert "Revert "Only build bundled fts if system has a bad version th… (#324)

Instead of 'fakechroot', have you considered using 'pseudo'? It does support large filesystems and other APIs. http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/ Both inside and outside of the OpenEmbedded work, we exclusively use pseudo to replace 'fakeroot' and 'fakechroot' capabilities. --

Re: [Rpm-maint] [rpm-software-management/rpm] ELF file conflict 'color' resolution for tri-lib systems (#193)

Yes x32 has exactly the same issue. The RPM5 code for the resolver is very different then this code set. So unfortunately it can't be directly applied. I simply don't understand the conflict resolution loop in this code base enough to understand why I'm not able to do the three-way

[Rpm-maint] [rpm-software-management/rpm] ELF file conflict 'color' resolution for tri-lib systems (#193)

I am attempting to use rpm with a tri-lib system, mips64. (ELF 32, ELF64 and MIPS64 n32) I have a small patch that adds MIPS64 n32 ABI support to RPM: http://git.openembedded.org/openembedded-core/tree/meta/recipes-devtools/rpm/files/0001-Add-a-color-setting-for-mips64_n32-binaries.patch

Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)

I have tested the current rpm4 debugedit within the Yocto Project environment -without- the patch, with the known binary doing cross-compiled work (little to big endian) and have not been able to reproduce the issue. Either debugedit has had a tweak over the years or elfutils has had a bug

Re: [Rpm-maint] [rpm-software-management/rpm] debugedit.c patches (#171)

Re: https://patchwork.openembedded.org/patch/46887 The bug and related information are available at: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4089 I am currently working through this to see if the current rpm (4) version suffers from the same failure. I will update this if it does or

Re: [Rpm-maint] RPM 4.12.0 alpha released

On 6/27/14, 9:41 AM, Panu Matilainen wrote: - Support for weak dependency tags (suggests, recommends etc) I finally got a chance to look at this, and I'm a bit concerned with what is there. The 'SUGGESTS' and 'ENHANCES' combo should be using the Requires/Provides with the

Re: [Rpm-maint] Multiple ABI architectures (parallel installation, detection, handling)

On 9/16/11 4:02 AM, Panu Matilainen wrote: On 09/15/2011 01:55 PM, Jon Masters wrote: ... What I want out of this discussion is a decision around how multiple ABIs within an architecture will be handled in general. If you're allergic to ARM, consider that in the Intel space there is now

Re: [Rpm-maint] [PATCH] Split the processing programs and libraries

On 10/31/10 6:35 PM, Alexey Gladkov wrote: 31.10.2010 13:57, Panu Matilainen wrote: No objections to splitting elf libraries to a separate class as such, in fact this is one of the things I had in mind with the new dep generator: enabling much more finer grained handling of different file

Re: [Rpm-maint] odd chroot behavior inside the rpm transaction

during a chroot, cwd stays outside of the chroot generally. Normally you following a chroot by a cd / or similar to force the programs to move into the chroot. I'm not sure if RPM 4 does that or not. (Based on this it seems like it is not. This is done BTW so that you can escape the

Re: [Rpm-maint] idea for new keyword: ObsoleteBy

I believe conflicts has been used for this purpose in the past. While it's not an automatic replacement, it does alert the admin to remove the custom package, and replace it with the distro package that is conflicting. --Mark Stanislav Brabec wrote: Seth Vidal wrote: libfoo-mybranch.spec:

Re: [Rpm-maint] [RFC PATCH] install selinux policies from package header

This is related to the early install. Cross-install is simple a variant of the regular installer use-case... only you can't actually run software within the chroot. How would you do this if you were doing a cross install. I.e. installing a Power system from an Intel based system? (You

Re: [Rpm-maint] Build Host: localhost.localdomain

RPM queries the name of the local machine from the DNS. So if you have the IP set to 127.0.0.1, and the DNS entry of locahost.localdomain, then that is what you will get. Fix the host's IP address and DNS entry to get a reasonable value. --Mark Giles Anderson wrote: Could someone tell me

Re: [Rpm-maint] [RFC PATCH] install selinux policies from package header

I believe that calling out is the better solution, at least for me. I need to be able to install software into chroots and other non-host environments for other machines to run. If we call out, then I can intercept that and perform setup actions [or ignore actions] based on my configuration.

Re: [Rpm-maint] Fwd: Looking for documentation on rpm macros and some suggestions

Why don't you just use: %build %configure --enable-unicode-properties --enable-pcregrep-libz --enable-pcregrep-libbz2 --disable-pcretest-libreadline The thing you need to remember about rpm macros is that they're really a cross between macros and defines. In most caseses they are simply

Re: [Rpm-maint] [wish] src.rpm management

This may point out a misunderstanding of what RPM does with source packages.. It really just unpacks them and places them into the right macro locations.. it doesn't actually install them the way normal binary RPMS are installed. And alternative way to install a source package: mkdir tmp_dir ;

Re: [Rpm-maint] Question about changing the name of an RPM

The filename does not affect the contents of the RPM package. So if you set the version to 1, the release to 1. And then name filename: foo-2-300.bar.rpm RPM is going to install the package using a version of 1 and a release of 1. On many systems, the filename is truncated to be simply

Re: [Rpm-maint] base package or devel package?

base package items are generally those required at runtime. Executables, shared libraries, configuration files etc. devel package items are generally those required to build or link software against this component. Non-soname links to shared libraries (if you don't know what this is skip it),

Re: [Rpm-maint] Problems using RPM to build cross-compiled (MinGW/Windows) packages

Richard W.M. Jones wrote: Hi, I hope this is the right place to raise these issues. We've recently been trying to build MinGW (a Windows cross-compiler) plus MinGW packages for Fedora. This kinda works, but there are some problems because RPM itself doesn't understand cross-compilation, or

Re: [Rpm-maint] [draft] spec file unification: autotools based projects

Marc Haisenko wrote: And how is that supposed to work ? I would need a way for each spec to tell RPM I'm now compiling for environment X, grab me the appropiate %configure. I'm cross-compiling to several different architectures, if I were to only cross-compile to one then your suggestions

Re: [Rpm-maint] [draft] spec file unification: autotools based projects

Stanislav Brabec wrote: The standard %setup macro should unpack these packages in convenient way: %prep %setup -q Configuration and compilation %build Packagers are encouraged to call autoreconf whenever possible. It guarantees correct build of packages on platforms, that was not supported

Re: [Rpm-maint] Automatic BuildRoot by default?

Two camps of thought.. If you build a binary AND SRPM, you better not short-circuit or you won't have a reproducible build. In this case, short-circuit is bad and shouldn't be used for anything but working through problems. Then there are folks like us, we use RPM as a container/shipment

[Rpm-maint] Re: [PATCH,RFC] arm: add support for VFP architectures

Lennert Buytenhek wrote: On Mon, Jan 14, 2008 at 12:44:06PM -0600, Mark Hatle wrote: So I'm a bit concerned that adding ...evl (or ...evb) is going to be confusing in the name. What we have done is called it armv5el_vfp. I've considered that, but that breaks configure scripts that match

[Rpm-maint] Re: [PATCH,RFC] arm: add support for VFP architectures

Lennert Buytenhek wrote: On Thu, Jan 03, 2008 at 11:01:46AM -0600, Mark Hatle wrote: (please CC on replies, I'm not on rpm-maint@) The attached patch adds a 'v' near the end of the machine name if the (ARM) system we're running on supports VFP. This allows building and using VFP-optimised

Re: [Rpm-maint] rpm packages with empty files..

Those are ghost files. They don't have to exist for the system to be valid, but if they do exist, they are owned by the RPM package. These files are part of the RPM database mechanisms (actually berkleyDB). --Mark Pazzo Da Legare wrote: Dear All, Could you please explain why rpm packages

Re: [Rpm-maint] rpm packages with empty files..

probably they are useful when one are going to uninstall... Thank you again, pazzo 2008/1/11, Mark Hatle [EMAIL PROTECTED]: Those are ghost files. They don't have to exist for the system to be valid, but if they do exist, they are owned by the RPM package. These files are part of the RPM

Re: [Rpm-maint] documentation on internals; layout of rpm file?

I made a document a while back that lists how the data structures relate to each other: http://gate.crashing.org/~fray/rpm/ Look at the two rpm-xml-desc.* files. The documents were written to allow someone to read the xml output from RPM who didn't know anything about RPM packages. (This of

Re: [Rpm-maint] [patch] rpm is not a cross-tool

Umm... yes it is. I use RPM to cross-compile software ever day. I also cross compile RPM from one target to another routinely. You need to keep the $target references or you will make the rpm.org version of RPM unable to be cross compiled. --Mark Ralf Corsepius wrote: ... today's flood

Re: [Rpm-maint] [patch] rpm is not a cross-tool

Ralf Corsepius wrote: On Mon, 2007-08-06 at 09:02 -0500, Mark Hatle wrote: Umm... yes it is. I use RPM to cross-compile software ever day. I also cross compile RPM from one target to another routinely. You need to keep the $target references or you will make the rpm.org version of RPM

Re: [Rpm-maint] [patch] rpm is not a cross-tool

of things that check the host system and may configure values incorrectly.. This has been a constant source of problems to me... --Mark Ralf Corsepius wrote: On Mon, 2007-08-06 at 09:26 -0500, Mark Hatle wrote: Ralf Corsepius wrote: On Mon, 2007-08-06 at 09:02 -0500, Mark Hatle wrote: Umm... yes

Re: [Rpm-maint] [PATCH] [RFC] 33% speedup in RPM!

Bill Nottingham wrote: Testing used for the following patch: ... Of course, it's a complete buzzsaw of a patch. To make this work, we'd need: 1) define one run of this as a post-transaction tool 2) make it packaging policy that the proper symlinks always be shipped in the package In