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 support devices that can't be serviced and have no console. Instead we can remove old keys and install new keys [passing appropriate selinux/ima/etc security methods] by updating files. It also allows developers to open up devices for user control by installing secondary keys for user-packages to 'unlock' an otherwise locked device. -- 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/857#issuecomment-535605541___ 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 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? In the former case, the ABI is compatible with armv7 and older.. in the later case, it's a new ABI. If you can make it clear ARMv8 is just the compatible with everything else version -- then it's just another marker... someone can add something new for ilp32 mode, if it is ever implemented. -- 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/425#issuecomment-382121817___ 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 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 claims are true or not, as I've not directly worked on that processor. Thus the mass confusion continues. But I agree with you, all aarch64 CPUs I have seen include all of the prescribed hardware as indicated by the spec. There may be some instruction scheduling differences, but so far the instruction set has been consistent and compatible. But with that said, I agree with what @n3npq mentioned above. Having these indicates as part of the package 'name' (other then for human readable purposes) really no longer makes sense. Between compatibility frameworks, emulators, etc... the system and users should be able to specify compatibility and priority and just 'go from there'. Same with package generation. It would make my life easier (using RPM in embedded systems) to get rid of this rpmrc notion for anything more then 'human readable'. -- 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/425#issuecomment-378942526___ 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 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 -mfloat-abi=hard -mfpu=neon +optflags: armv8l -O2 -g -march=armv8-a aarch32 is the new marketing name for what we used to call the 'arm instruction set'. armv8 is the most current incarnation of the 32-bit ARM instruction set. While the armv8 spec strongly suggests the inclusion of the VFP/Neon and other instructions. It is not strictly required. So yes, softfloat is still being used and is needed in some cases. There are multiple ARM licenses who claim to have armv8 compatible CPUs that do not have floating point units. (Note, all of the cases I know of these are 32-bit CPUs -- and all are geared toward embedded.) -- 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/425#discussion_r178826605___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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. -- 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/422#issuecomment-376968477___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 Brownwrote: >> >> 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 an configure switch, and > default to /var/lib/rpm. Most people have literally no reason to move > it. The switch would move the rpmdb to the alternate location of > /usr/lib/rpmdb (or whatever the agreed alternate path is). > > This wouldn't really affect rpm-ostree, as they'd adjust the dbpath > the same way they've always done it. But for people changing the > system rpmdb location everywhere, the configure switch makes it clear > there's only two supported paths. It should be very clear that you're > on your own for anything else. > > I agree with this. I see no compelling reason for my applications to move the location of the database from one version to another. Moving the DB will also complicated OS upgrades (package based) and other things. I don't object to be it being configurable, but I'd like the option to remain at the current location for as long as I and my customers need it there. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: https://github.com/rpm-software-management/rpm/pull/324#issuecomment-328868191___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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. -- 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/324#issuecomment-328535004___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 resolution. -- 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/193#issuecomment-292934699___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[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 This introduces color value of '4', that indicates MIPS64 n32. This works if the system is installing MIPS64 n32 vs MIPS64 (colors 4 vs 2) and I have the preferred color set to one or the other. However, if I add the third library of '1', or MIPS(32) then it can't resolve a three way conflict properly. I've identified that in the lib/transaction.c file, handleColorConflict function. The issue is that the system needs a final 'else' clause to deal with the situation where neither is the preferred type. I've been working on a patch to resolve this, but I can't figure out how to make it work properly: rConflicts = 0; + } else { + /* +* If neither is already skipped, we skip the old one, and +* install the new one (last in wins). +*/ + if (ofs && !XFA_SKIPPING(rpmfsGetAction(ofs, ofx)) && +fs && !XFA_SKIPPING(rpmfsGetAction(fs, fx))) { + rpmfsSetAction(ofs, ofx, FA_SKIPCOLOR); + rpmfsSetAction(fs, fx, FA_CREATE); + } + rConflicts = 0; } When I have do an install with ELF32, ELF64 and MIPS64 n32 (specified in that order as the rpm transaction), setting the preferred color to '2' (ELF64), the system will still install the n32 version. (If I change the order so MIPS64 n32 is not the last in the transaction order then it works fine.) What I appear to be getting during processing is: conflict -- MIPS64 n32 vs ELF32 -- resolved to ELF32 (via the else I added) conflict -- ELF32 vs ELF64 -- resolved to ELF64 (via existing mechanism) conflict -- ELF64 vs ELF32 -- resolved to ELF64 (via existing mechanism) conflict -- ELF32 vs MIPS64 n32 -- resolves to MIPS64 n32 (via the else I added) So the conflict appears resolved, and both ELF64 and MIPS64n32 are installed, with the n32 version being 'last', so that is the version on the disk. Any help would be appreciated on this three way resolution. -- 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/193___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 fixed. (The original defect being resolved by this patch set was related to the "shdr.sh_type" being in the binary endian, not the running system endian.) So it appears there is no need for the specific patch related: https://patchwork.openembedded.org/patch/46887 -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/171#issuecomment-284739345___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 does not. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/171#issuecomment-284464186___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 RPMSENSE_MISSINGOK. This way they are ignored when not available, but directly affect the installer ordering during dependency resolution. I know the complaint in the past is third party tools don't know how to process MISSINGOK. (IMHO that's a bug in the external tools, they should be updated.) One alternative could be to use the new weak dependency tags and 'adapt' them to the MISSINGOK internally so that the dep solver could continue to work as it has. (It still causes some issues for me with the actual package contents/format though.) Note: rpm 'suggests' had previously been implemented to work the same way that 'recommends' was implemented in Debian.. so the swap in names may be a bit confusing -- but the purpose is that this is something that should be installed if available, but not fail. the other, 'recommends', was something that was added to work like 'suggests' from Debian. It's just suggested to the user, but does affect the install in any way. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 IA32, X32, and X64. The former is a 32-bit architecture, and the latter are both ABIs layered upon the 64-bit architecture. ARM and Intel aren't alone in this, there are others out there doing similarly fun things. Rpm does have limited provisions for multilib/multiarch of course (that's how x86_64 etc multilib archs work on Fedora/RHEL), but what's there is not sufficient for generic multiarch/multiabi parallel support. To outline the issues: Actually rpm already supports (and has a for a while) tri-arch/abi setups on MIPS. MIPS64 already has o32, n32 and n64 support. Generally speaking they're installed into /lib, /lib32 and /lib64 respectively. 1) Location of libraries and the like: the libraries for different ABI's need to go to separate paths. Currently the non-debian world knows /lib and /lib64, and while it's of course possible to add /libx32 and whatnot, that gets *extremely* ugly real soon and simply does not scale to things like cross-toolchains. The debian multiarch spec seems rather nice in this regard: simply stuff it all into separate libraries in $(prefix)/lib/$(arch)-$(abi) style distinct paths, without differentiating between native and other archs/abis. As mentioned above, /lib, /lib32 and /lib64 are known. We intend to add /libx32 to our work in the near future. It's already part of the embedded OE-Core work. This is something that can't be decided and solved by rpm alone, the entire distro and the compiler/linker toolchains are involved. Yes, the distro as a whole needs to agree on naming. Not something that a packaging system can do. 2) Dependencies: there needs to be a way to distinguish between (including but not limited to) libraries with identical soname-version but different ABI. Rpm currently only knows of two kinds of soname dependencies: ones with ()(64bit) postfix and ones without it. This kinda works for what it gets used now, but is full of weird wrinkles like some 64bit architectures not getting the (64bit) marker etc, and obviously does not scale to full-fledged multi/cross-arch dependencies. So the autogenerated soname dependencies would need to encode full arch+abi(+maybesomethingelsetoo) into the dependencies. The problem here is that changing the way dependencies are encoded is a MASSIVE backwards-compatibility breakage, and probably would need both old-style and new-style dependencies to be generated (although some of this might be possible to arrange at runtime) for a transition period. On mips, we have a ()(32bit) as well.. So we end up with (o32) libfoo.so, (n32) libfoo.so()(32bit), (n64) libfoo.so()(64bit)... For manually added dependencies %{_isa} goes a long way, but probably not sufficient in its current form for a full-scale multiarch, multiabi system. So far this has scaled well in our trials. Soon to be adding in x32 may test this further. BTW n32 is our default ABI for mips64 in our products. Then there's the issue of dependency satisfiability across architectures and abi's. Rpm has some provisions for this (dependency colors), but its currently limited to just differentiate between 32bit vs 64bit (and obviously other) and there's no way to express allowed/prohibited dependency matches across architectures. Actually there are three bits defined.. 32-bit, 64-bit and n32. The same coloring system is used to resolve elf-file conflicts on common paths. This rather crazy system can be entirely avoided by better/more fine-grained packaging: always place libraries and the like into separate (sub)packages to eliminate conflict potential. Based on the debian notes, dpkg apparently has issues with identical files shared across multiple packages, but this is not an issue for rpm: it's always been possible for multiple packages to share files, as long as the files are identical. The conflict resolution works well, but it's much better to break the problem up so you don't need to use it much. That is what we've tried to do for the most part. 3) Package naming resolution: when in multilib mode (in rpm jargon, colored transaction), packages with identical name but different architecture can co-exist relatively peacefully. However the use of arch alone is limiting from multiabi perspective, it'd require every single different arch/abi combination to have arch of their own. Other possibility is differentiating in the package name, but its klunky too. I didn't (yet) see what debian is planning wrt this. I didn't think that was true. I thought that the coloring system would allow you to use the same arch. Maybe this isn't true in the rpm.org world, but it is in
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 types. The same thing largely applies to interpreted languages too, executables and libraries are quite different beasts and typically require rather different handling. Changing that is a compatibility issue, This is great news for me :) Removing the executability requirement is a bit touchier subject though: the executable bit is what rpm has traditionally (as in, always) used for determining whether dependency exctraction should be performed on a file or not (of course there are already several exceptions to that, like perl and python modules..). I think this is true, but not for libraries. Because all the shared libraries should be generate the dependencies as well as all executable binaries. When the program without a executable bit, then no easy way to run it. However, the linker will use the library even without a executable bit. So, if a program is linked with the shared library without a executable bit, then rpm package containing the program receives an unmet dependency. people are using it do selectively disable dependency generation on eg private library modules. Which is not a particularly good mechanism, there just hasn't been any better way to generally do it. I think that the library depending should be generated only when it is the standard path e.g. /lib(64)?, /usr/lib(64)? ... and of course should be mechanism to add some directory to this list. The fact that now the dependence is generated for all elf files, but not all this files are libraries or programs. There is one more class files - plugins and modules. The programs don't link with them and use it in runtime. Usually they don't have a SONAME. These plugins are usually located in the subdirectories and do not need to generate for them. Just using the items from the standard library directories is not enough. Between programs that add components to ld.conf, and other programs that have rpath or similar usage.. this is problematic. It really does need to scan everything in the system and return back full results. With a way to selectively disable a file, or dependency. --Mark One easy way out is to make it distro-configurable, eg something like this in elflib.attr: %__elf_flags %{?_executable_shared_libs:exeonly}%{nil} ...punting the decision to somebody else, but dunno. Thank you. I will correct it. While splitting this up, might as well disable/remove __elf_provides, as the executables never provide anything elf-related (they could of course provide something else through other attributes but that's their business). Yes. Note that these need to be called %__elflib_foo Yes. I already found this bug. Also FWIW, while %__elflib_flags is subject to the compatibility ponderings above just a general note: there's no requirement for all the __foo_bar macros to be defined, you only need to define what's relevant for that particular attribute. So you can just leave %__elflib_flags out instead of defining it to %nil. Ok. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 chroot...) --Mark Seth Vidal wrote: https://bugzilla.redhat.com/show_bug.cgi?id=503195#c13 as I said: if, from the python bindings, I open a file with a name starting with '/' while in a transaction then as expected, the file is opened inside the installroot however, if I open a file with a name NOT starting with '/' then the file is opened OUTSIDE of the installroot. Does this make any sense? B/c I admit I don't quite grok why it would be this way. Thanks, -sv ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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: Version:2.3 Provides: libfoo = %{version} ObsoleteBy: libfoo = 2.4 What do you think about such feature? What does this get you that isn't already handled by 'Obsoletes'? If you're introducing a pkg later why not put 'Obsoletes' in it? As an author of a private libfoo-mybranch, I don't want to modify the mainline libfoo package. This concept may be usable for installation of packages from different sources: mainline + my addon. Now I have no chance to terminate packages in my addon, when all features were upstreamed. Package manager auto-updates always tries to update to the latest libfoo-mybranch. I have no chance to provide an update, that terminates the support of libfoo-mybranch and offers users to upgrade to the latest mainline libfoo. Well, I have a very similar problem with Requires in openSUSE nowadays: Mainline packages contains gnome-panel and banshee. gnome-panel does not require banshee. But if I install downstream gconf2-branding-openSUSE, which adds banshee to the default gnome-panel configuration, then gnome-panel starts to require banshee. I cannot add it directly to gnome-panel (because mainline gnome-panel does not depend on banshee). I cannot add it to gconf2-branding-openSUSE (if gconf2-branding-openSUSE is installed but gnome-panel is not, I have to need to have banshee installed). That is why a more generic feature may be: If this package is installed, then it adds Add Requires:/Provides:/Supplements:/Recommends:/Conflicts:... to another package dependencies (if it exists). ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 can't run software in the chroot, because the chroot contains software that is incompatible with the CPU you are installing from.) You will need to run the semodule program on the host, but ensure all of the data structures and such are configured for the target environment. --Mark Steve Lawrence wrote: On Wed, 2009-08-26 at 10:55 +0300, Panu Matilainen wrote: Finally getting back to this after vacations and all, apologies for the lenghty delay... On Tue, 7 Jul 2009, Joshua Brindle wrote: Panu Matilainen wrote: Hi, On Mon, 6 Jul 2009, Stephen Lawrence wrote: snip Obviously I'm glossing over many implementation details that would need to be worked out. The point of this email is strictly to get feedback on our approach. Below is a patch that implements the beginnings of what I describe above. Any and all feedback is appreciated. Loading the policies at pre-trans stage is how it needs to be done, but calling out to semodule is a no-go. It'd work for upgrades more or less, but on initial installation (to an empty chroot) the pre-trans stage happens in a complete void, there's just nothing there, not even /bin/sh. It needs to be done through API calls, no way around it. On the surface it doesn't look that bad, skipping over details like error handling, rpmtsLoadPolicy() might be something like: We wanted to fork/exec semodule because there would be a domain transition and we could give semodule permission to update the policy without giving rpm that permission. This feeds in to our ultimate desire to break RPM in to less privileged pieces. FWIW the library executes apps as well, for example setfiles is run to validate the file contexts files when new policy is loaded. This is how we break out functionality in SELinux to let pieces be less privileged. I don't think we can attain our end goals if fork/exec is never allowed. It's not so much a matter of allowing or not, but what's possible. Chroot'ed operation (initial install and otherwise) is not an oddball corner case but one of the most important use-cases for rpm, and needs to be taken into account as such everywhere. But ok... looking that little bit closer: unlike %pretrans scriptlets, the policy load happens *outside* any chroot using the hosts /usr/sbin/semodule always. This changes the landscape considerably and mostly eliminates my early bootstrap concerns, sorry for missing that previously. Although we don't do it currently, when the --root option is given, we do plan to chroot(2). This is necessary to ensure that the policy that is changed is the one in the chroot rather than the one in the parent system. So your 'early bootstrap' example is still an issue. That said, we do have an idea as to how we can solve this. Some odds and ends that come to mind: - What to do in various failure cases, such as to-be-installed packages containing loadable policies but /usr/sbin/semodule doesn't exist on the host and --nopolicy was not specified? Aborting the transaction in while already in rpmtsRun() seems rather unfriendly when the situation is detectable earlier. Dynamic rpmlib() dependency might be one option. In the cases where semodule does not exist (e.g. initial install or install into an empty chroot), we will automatically fall back to using libsemanage. We believe this is a good compromise between added separation with semodule in the common case (normal rpm installations) and allowing empty chroot/initial installations to still work. - The /usr/sbin/semodule path should be macroized (a no-brainer) Agreed. - Is there some particular reason why installPolicy() is in the PSM? It seems like an unnecessary complication to me, as AFAICT the operation doesn't need any of the other PSM machinery (unlike %pretrans which uses PSM to do chroot in+out + executing scriptlets from headers) Agreed. This was done when we were fairly unfamiliar with the rpm code. We realized the over complication and have changed it to a more reasonable method. This change, as well as the semodule macro and libsemanage fallback, will be in our next patchset. Thanks, - Steve ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 how the value for 'Build Host:' gets set/defined? Giles Anderson ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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. Direct API calls also limit it to the running system environment. As for the initial install situation, I don't believe SE Linux should be configured during an initial install. This would be setting up contexts and such for the installer's kernel and not the end resulting filesystem. A flag or something to disable this type of setup for the initial install might be necessary. [or the script/program run could be passed the install root and know what to do, or not to do in a new system install context. Just has to run outside of the chroot...] --Mark Panu Matilainen wrote: Hi, On Mon, 6 Jul 2009, Stephen Lawrence wrote: RPM currently has support for security policies to be stored in an rpm header but it doesn't currently do anything with the policies. We'd like to get some feedback on a prototype implementation that adds support for using those policies in an SELinux environment. First of all thanks for looking into this! First, a bit of background. SELinux policy is currently installed through %post scripts. This presents several problems. First, this means that policy for a given application may not be loaded at the time the files are written to disk, preventing those files from being labeled properly, because the symbols used to label files need to be in the policy loaded into the kernel. Secondly, this means that if multiple packages install policy, each of their %post scripts will reload the policy, which is a very expensive operation. Consequently, policy is generally kept in a single package to avoid this, despite containing many application specific policy modules that would be more suited to be included in their application package. So, what we would like to do is to start including SELinux policy as part of the rpm and have rpm install all policies together before files start to hit the disk. To do this, we would like to use the already supported %policy directive, which stores the policy in the archive header. We would then install the policy before pretrans. This policy load would involve gathering all the policies to be installed from all packages, writing them to a temporary location, and calling out to semodule to install the SELinux policy modules. Obviously I'm glossing over many implementation details that would need to be worked out. The point of this email is strictly to get feedback on our approach. Below is a patch that implements the beginnings of what I describe above. Any and all feedback is appreciated. Loading the policies at pre-trans stage is how it needs to be done, but calling out to semodule is a no-go. It'd work for upgrades more or less, but on initial installation (to an empty chroot) the pre-trans stage happens in a complete void, there's just nothing there, not even /bin/sh. It needs to be done through API calls, no way around it. On the surface it doesn't look that bad, skipping over details like error handling, rpmtsLoadPolicy() might be something like: static int rpmtsLoadPolicies(rpmts ts) { int rc; rpmte p; semanage_handle_t *sh = NULL; rpmtsi pi = rpmtsiInit(ts); while ((p = rpmtsiNext(pi, TR_ADDED)) != NULL) { /* If no pre/post-transaction script, then don't bother. */ if (!rpmteHavePolicies(p, stag)) continue; /* only set up semanage transaction if we have policies */ if (sh == NULL) { sh = semanage_handle_create(); semanage_connect(sh); semanage_begin_transaction(sh); } if (rpmteOpen(p, ts, 0)) { /* ... fish the policies from te header, b64decode ... */ semanage_module_install(sh, ...); rpmteClose(p, ts, 0); } } if (sh) { semanage_commit(sh); semanage_disconnect(sh); semanage_handle_destroy(sh); } pi = rpmtsiFree(pi); return rc; } ...but I've a feeling there's more than one devil in the details. The base policy seems to be a bit special as it even has a separate loader function, which I suppose would have to be loaded first if one is present, but how would rpm know what's a base policy and what's not? Are there other order dependencies in the modules? I guess not but dunno. Another open question is upgrade/remove semantics. Maybe it's sufficient just to semanage_module_install() on install+upgrade, and semanage_module_remove() on non-upgrade removal (direct erase or obsoletion), all in the pre-trans stage. I'm just wondering could there be cases where successful removal requires the package's policy to be loaded? If so, the module removals would either have to be done at the middle of transaction individually
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 defines, it's a simple search/replace type operation when the shell scripts are generated for building. The only time they really operate like macros are when there are certain semantics like %(...), or %{?...}, or %{eval:...} This looks to me like you are trying to come up with a solution to make your packages look more uniform, while adding complexing and incompatibility to the macros. I've done this before, and it was one of the greatest mistakes you can make when working with RPM. Use the macros your distribution provides, when you deviate or make changes from that then maintenance becomes a huge burden. While it might save you 10 minutes today, it'll cost you an hour when you upgrade. --Mark Ritesh Sood wrote: I had sent the following mail to rpm-l...@lists.rpm.org mailto:rpm-l...@lists.rpm.org, but haven't received a response. Perhaps rpm-maint is a more appropriate forum for my queries. Hi all, I'm not a regular rpm builder, but have the need to build some at the moment. I've been successful in building the few rpm's that I need and now want to fine tune the process. Please take a look at my .rpmmacros below. In particular, the addition to the %configure macro in the last line (which is more like what I want to do, but I'm not sure of the syntax): --- start .rpmmacros %packager Ritesh Sood riteshs...@gmail.com mailto:riteshs...@gmail.com %vendorDept. of ECE, UC Davis (Internal Use) %_topdir%(echo $HOME)/ECESysAdmin/Syslog-ng/RPM-Build %configure \ CFLAGS=${CFLAGS:-%optflags} ; export CFLAGS ; \ CXXFLAGS=${CXXFLAGS:-%optflags} ; export CXXFLAGS ; \ ./configure --host=%{_host} --build=%{_build} \\\ ... (original code from /usr/lib/rpm/macros) ... %{?pkg_config_flags} --- end .rpmmacros The idea being that if I want to build the package ``pcre-ece which requires configure time flags, the spec file would be something like --- start pcre-ece.spec %define name pcre-ece %define orig_name pcre %define version 7.8 %define release 1 %define _prefix /usr/local %define _docdir %{_datadir}/doc/%{orig_name} %define pkg_config_flags --enable-unicode-properties --enable-pcregrep-libz --enable-pcregrep-libbz2 --disable-pcretest-libreadline Summary: Perl-compatible regular expression library Name: %{name} Version: %{version} Release: %{release} Source: %{orig_name}-%{version}.tar.bz2 URL: http://www.pcre.org/ License: BSD Group: System Environment/Libraries BuildRoot: %{_builddir}/%{orig_name}-root Prereq: /sbin/ldconfig BuildPrereq: sed . . . --- end pcre-ece.spec Coming back to ``%{?pkg_config_flags} in .rpmmacros above, if the spec file defines ``pkg_config_flags, then it would be appended to the default expansion of the ``configure macro; if not, nothing would be appended. The ``? in the above is a conjectured syntax to achieve what i've stated above. I'm not able to find good documentation on the syntax and rules of these macros (i'm familiar with those of ``make). Neither at http://rpm.org/wiki/Docs#PackagerDocumentation nor in the books http://www.rpm.org/max-rpm-snapshot/ http://docs.fedoraproject.org/drafts/rpm-guide-en/ Any help in finding documentation is much appreciated. Secondly, it would be good to have the facility to append per-package flags to other macros. I found the following in one of Suse linux's RPM spec file --- start code %build %{expand: %%define optflags %{optflags} -fPIC} --- end code So just to add the ``-fPIC flag, poor guy has to jump through all those hoops. How about something like the following appearing in the ``configure macro instead: --- start code CFLAGS=${CFLAGS:-%optflags:-%{?pkg_cflags}} ; export CFLAGS ; \ CXXFLAGS=${CXXFLAGS:-%optflags:-%{?pkg_cxxflags}} ; export CXXFLAGS ; \ --- end code and while we're at it, might as well add --- start code LDFLAGS=${LDFLAGS:-%{?pkg_ldflags}} ; export LDFLAGS ; \ --- end code Again, the syntax is my guess as to what it might look like, but you get the idea. Looking forward to feedback on the above suggestions. Ritesh ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list
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 ; cd tmp_dir rpm2cpio source_pkg | cpio -id mv specfile SPECS_DIR mv * SOURCES_DIR [rough, probably doesn't work.. but gives you an idea of what it's doing..] --Mark Jeff Sheltren wrote: On Jan 21, 2009, at 7:46 AM, Maciej Pilichowski wrote: Hello, Not a big issue, however odd -- rpm can install source rpm file, but it cannot list it or uninstall, user has to to it manually. It would be useful to have additional flag for rpm, like --src to include source rpms rpm -qa --src would list also src.rpms, in uninstall, lists, etc. My main point is -- tool which is able to install X should be able to uninstall X as well. Your thoughts? I wouldn't consider SRPMs to be packages like RPMs are. As a non-root user, I can install an SRPM into (in my case) /home/jeff/rpmbuild which is the setting for %_topdir in my ~/.rpmmacros I don't think the system needs to track this. -Jeff ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
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 foo.rpm to allow for ISO media. (Short answer, if version or release are wrong, you need to rebuild to fix it.) --Mark Andy Harrison wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Aug 20, 2008 at 5:45 PM, Nitzan Gurfinkel wrote: I hope I'm on the right lit and I apologize if not. During the build process the RPMs get their names through the following Makefile line: $(M4) -DBUILDNUMBER=$(BUILDNUMBER) -DUSERNAME=$(USERNAME) -DRELEASETEXT=$(RELEASETEXT) -I$(RPM_TMPL_DIR) $(EXTRA_M4DEFINES) $(PKGDIR)/$(RPM_TEMPLATE) $(PKGDIR)/$(RPM_TEMPLATE:%.tmpl=%.spec) The final name looks like: host-1.1.1.2-pre.XXX.rpm It turned out that there was a mistake in the build and $(RELEASETEXT) should not be pre but a different string. Is it OK to rename the file, or does the $(RELEASETEXT) somehow internally integrated into the RPM and there is a need to build again? Although renaming the file won't break anything, you can tailor the name of the resulting rpm yourself anyway. Without knowing your operating system and/or related versions, the default that rpm uses for naming is contained in the _build_name_fmt macro. Were you to drop this in the ~/.rpmmacros file of the user performing the rpmbuild, your rpm name would be the same as the default: %_build_name_fmt%%{ARCH}/%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm - -- Andy Harrison public key: 0x67518262 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIvs1wNTm8fWdRgmIRAss1AJwMR4/0e1q/Br7elYbb3iGr8fDIvwCg+UAP v+mw4u8Bt0ybQw+H60y4UFg= =l2bL -END PGP SIGNATURE- ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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), libtool achives, .a static libraries, headers, pkgconfig, etc. The list below is an alternative way to breakup the package that is more SuSE oriented. Fedora and other environments have different standard breakdown structures. So whatever you are targeting with your package, you will want to find out what their policies are. (Note, base/devel is a minimal breakdown everyone uses.) --Mark Pavol Rusnak wrote: holmes86 wrote: I am a make rpm newbie.I have a question now.when I was making rpm package,I don't know which parts are base package and which parts are devel package one? Is they any rule? thanks very much! Rough explanation: Assume project called foo, we could split into following packages: * base package - foo - binaries (eg. /usr/bin/*) - documentation (could go into separate foo-doc if very large) - icons, desktop files, etc. * shared library package - libfooXXX (XXX is .so major number eg libfoo3 for libfoo.so.3.24.3) - only library! (/usr/lib/libfooXXX.so.*) * devel package - libfoo-devel (no XXX here) - .so symlink - /usr/lib/libfoo.so - includes - /usr/include/* - pkgconfig file - /usr/lib/pkg-config/* We usually do not package .a or .la files (you could avoid building .a with --disable-static passed to configure, you have to manually delete .la files though). Base package should require libfoo-devel and devel package should require particular lib package (libfooXXX). Hope that helps. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 maybe we're just not using RPM right. The problems we've seen so far: (1) The default __os_install_post script does a lot of stuff which is not just irrelevant, but in fact dangerous. In particular it runs Linux 'strip' on Windows binaries which corrupts them. What we'd want it to do is to run the Windows-aware 'i686-pc-mingw32-strip' (from mingw-binutils) on Windows binaries/libraries instead. You will want to probably define _strip as true or provide a custom __os_install_post. This is a necessity if you are creating a cross compiler with binaries for another architecture. For packages compiled to run on a different target the right approach is to provide a macro file that will be autoloaded by rpm using --target=i686-mingw32. In this file you can specify all of the things that a target package uses to compile, strip, etc. (2) The default RPM_OPT_FLAGS are wrong in several respects for cross-compiling. One big problem is that they include '-m32' or '-m64' depending on the host architecture (I think). Our target architecture is always 32 bit, so using -m64 is always wrong for us. Also, defaults like -fstack-protector don't work properly on Windows. Simply don't use the RPM_OPT_FLAGS, or use the --target= approach above. (3) Auto-dependency generation doesn't work at all, so we end up with manual 'Requires:' in the spec files. I'm not even sure if there is a naming convention for Windows library deps. Since RPM doesn't have knowledge of anything but ELF, you will need to provide a custom dependency generation script (tie it into the above target macro file), or add AutoReqProv: no, and manually specify all of your dependencies. (4) Running configure in a subdirectory is common (ie. mkdir build; cd build; ../configure). This doesn't easily let me use %configure although in the end I found a really gross hack which worked. Don't use %configure then. Nothing forces you to use it, it's just there for convenience. It's not going to work in all circumstances. (All of the packages I've worked on for the last 8 years or so have been cross compiled.. usually linux - linux but the approaches are the same no matter what the target.) --Mark If you want to see some of our work, including example specfiles, then take a look at (or 'hg clone'): http://hg.et.redhat.com/misc/fedora-mingw--devel/ Please read the README file first since it explains the order in which you have to build the packages. Rich. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 would make sense to me. RPM already has this capability.. --target=foo This will change the internal value of %{_target} which you can use to load alternative version of %configure. I don't think this will ever be possible :-) And I don't think that this should be a goal. I just wanted to remind that there ARE situations in which you need to pass cache variables to autoconf and I don't want to export them when I need them only for one command (configure). A good example of why this is needed OUTSIDE of the cross compile world is to build a component with intentional limited functionality. I.e. I have a component that checks for pam but doesn't have an --enable-pam or --with-pam type switch. Occasionally the only way to disable it is to use ac_pam=no. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 by autotools in the time of the source release. autoreconf -f -i I think there is some argument that running the autotools at the end of the %prep may be appropriate. It all depends on what you expect out of the %prep. If the purpose of %prep is simply to unpack and patch the source, then autoreconf is not appropriate there. If the purpose of %prep is to prepare the software to be configured/built then autoreconf may be appropriate. I think once a statement is made, then the appropriate solution can be chosen and explained. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 mechanism. Our builds may or may not be based on spec files.. But we never ship SRPMs, and we don't ship spec files outside of our build environment. We expect customers to use our build environment to produce the RPM package (or use packages produced external to our environment...) So --short-circuit is critical for us to be able to create the binary rpms that we use ever day. For us, rpmbuild is useful primarily to cpio up a filesystem and attach metadata. rpm is useful to manage the system on the target made up of the cpio and metadata. So my short answer is, if you take away --short-circuit, we'll be forced to resurrect it, or go with some alternative mechanism to create the RPM binary package. (I doubt we're the only environment like this.) --Mark Per Øyvind Karlsen wrote: On Thursday 12 June 2008 19:48:37 Tom spot Callaway wrote: On Thu, 2008-06-12 at 19:38 +0200, Pixel wrote: Tom \spot\ Callaway [EMAIL PROTECTED] writes: The only reason we use mktemp in there is because we couldn't make rpm code changes to use the native glibc functions. As to rpm --short-circuit, well, I honestly think we should think long and hard about whether we want to keep it around. well, as for mandriva, i think it is mandatory to keep a similar feature. and since nowadays distributions use build systems, i really don't see how this can be dangerous. the usefulness to adjustate %install and %files on big pkgs is quite obvious (my example: gcc) but i'm not against slowly obsoleting --short-circuit which has some drawbacks in favor of the following (that mandriva inherited from conectiva) Hm. FWIW, my opinion is that people shouldn't be short-circuiting builds like you're describing, it only opens the door to non-reproducable builds. Obviously, others disagree with that. :) That'd be the analogy of always requiring people to do 'make clean' before running 'make' on some project they're working on.. Rather non-sense or oblivious about the relevant details, but whatever, --short-circuit saves my day every now and then several times a day without it affecting any packages of mine in the distro.. ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
[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 against arm*b-* to determine whether the target is big-endian or not. Using the 'v' is a bit of a hack, but I can't come up with anything better. We haven't found any configure scripts that change when VFP is enabled or not. E.g. if you try to compile gcc for a big-endian ARM system, the build will certainly break if you pass it armv5teb_vfp-* or armv5eb_vfp-* or something like that. We don't pass the RPM arch into the configure. The configure is called w/ simply armv5eb and armv5el.. (add t if thumb is enabled). The ARCH references a set of macros, but does not actually define the value. You just need to set the macro properly and not inherit the RPM Arch value. So as long as the compiler is doing the right thing and the RPM macros are setup to properly list the gnu style arch, I think this is a better answer. It's a lot more obvious as to what is being attempted then embedding the 'v'. That's generally how features are encoded on ARM, though. Like how 'ARMv5, Thumb, Extended DSP instructions' is encoded as 'armv5te' and not as 'armv5_thumb_edsp'. Right now, the rpm arch name for ARMv5TE little-endian is is 'armv5tel', and it would be kind of weird to have the Thumb and EDSP capabilities encoded as single letters but to have VFP encoded as _vfp in the same arch name. My concern is simply that VFP encoding isn't defined in the ARM spec. Either there has to be agreement among all of the (linux) arm community or a new encoding shouldn't be created. ARM Ltd or someone else may already have a defined use for that, so I believe conflicts are inevitable. ... The problem with that would be that RPM package file names for VFP and non-VFP packages would be identical. Sure, but remember rpm package file names don't actually mean anything other then the name of the file. :) Just a suggestion. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
[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 RPM packages for ARM systems that have a VFP floating point unit. So e.g. glibc-2.7-2.armv5tel.rpm is the regular (softfloat) glibc that we have now, and glibc-2.7-2.armv5tevl.rpm would then be a glibc built to use VFP instructions, installable only on systems that have HWCAP_VFP. As far as I was aware there wasn't a standard naming convention for VFP in the arm cpu name. Yeah, that's correct. It's not one of the feature letters. 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 against arm*b-* to determine whether the target is big-endian or not. Using the 'v' is a bit of a hack, but I can't come up with anything better. We haven't found any configure scripts that change when VFP is enabled or not. So as long as the compiler is doing the right thing and the RPM macros are setup to properly list the gnu style arch, I think this is a better answer. It's a lot more obvious as to what is being attempted then embedding the 'v'. (I would really like not to have to parse /proc/cpuinfo, but I don't see how to get at _dl_hwcap or AT_HWCAP -- as far as I see, ld.so uses this info to determine its library search path but doesn't export the info.) The HWCAP stuff in in the aux vector of course. I found a reference to reading it from /proc/self/auxv, but I swear there is another way to read this information w/o having to open any files. I had a quick look at glibc, but I don't see any place where it makes the info available. If you have this working, I'd be interested. glibc does not export it directly. According to the glibc maintainers the only proper way to do this is either w/ an additional argument to main or reading the contents of /proc/self/auxv. The main arg way is easier of course, but requires a more structural change. Ideas? An alternative suggestion. Instead of changing the name or the arch, would it make sense to use HWCAP settings as a run-time dependency. This would allow in-kernel VFP emulation (if there ever was a such a thing implemented) to set the capability and run/install the code as appropriate. I don't understand that last sentence -- how does the approach I proposed not allow having an in-kernel VFP emulator set HWCAP_VFP? RPM could set an internal dependency (provide) when VFP is available. The rpm packages that use VFP, could have an associated dependency (require) for that item. It may not be as obvious because it's not in the arch name.. but really all ARCH is, is a form of dependencies. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 builders are defining spec file with empty files inside? e.g. the rpm package for rpm utility defines empty files __db.000, __db.001, , __db.009, but I cannot find any file on my system...and rpm -Vv seems to be happyis it checking only not empty files? Thx pazzodalgagre ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] rpm packages with empty files..
There is a bit that is set by the rpm package that controls various aspects of validation. md5sum, attributes, size, ghost (if it may or may not exist), etc. To properly validate a system, you have to pay attention to these attributes and ignore certain changes based on those attributes. (Everything is available via query flags.. you may have to look at the RPM sources for the actual bit values.) rpm -Va does this today. --Mark Pazzo Da Legare wrote: Thank you Mark. So if one wants to check the integrity of the system( = i.e. all files from each rpm installed package are presents) only for all f in files from some rpm s.t. (f is on filesystemf has size 0 declared in rpm) || ( f is on filesystem with size 0 f has size == 0 declared in rpm) in other words, one should consider a ghost file for a check only if it has size0 on fs ... or simply discard ghost files checkprobably 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 database mechanisms (actually berkleyDB). --Mark Pazzo Da Legare wrote: Dear All, Could you please explain why rpm packages builders are defining spec file with empty files inside? e.g. the rpm package for rpm utility defines empty files __db.000, __db.001, , __db.009, but I cannot find any file on my system...and rpm -Vv seems to be happyis it checking only not empty files? Thx pazzodalgagre ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 course doesn't cover how the RPM binary is organized though..) --Mark Panu Matilainen wrote: On Thu, 1 Nov 2007, Paul Elliott wrote: How do I find the documentation on rpm internals; specificly how an rpm file is laid out, how digital signing is implemented? What does the guts of an rpm file look like and where is this documented? rpm.org carries some documentation regarding the file format: http://wiki.rpm.org/FileFormat http://rpm.org/api/4.4.2.2/pkgformat.html I don't think the digital signing is documented other than read the source, you might find something in the doxygen docs: http://rpm.org/api/4.4.2.2/index.html - Panu - ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 continues ... The patch below removes AC_CANONICAL_TARGET from configure.ac and changes $target to $host. Background: AC_CANONICAL_TARGET is supposed to take the target of a cross-tool, not the target of cross-compiling a package (== a configure script's --host). Older configure scripts often got this wrong - rpm's configure isn't an exception ;) Ralf diff -r 98f1a954345f configure.ac --- a/configure.acMon Aug 06 14:24:29 2007 +0300 +++ b/configure.acMon Aug 06 13:41:00 2007 +0200 @@ -1,6 +1,6 @@ AC_PREREQ(2.61) AC_PREREQ(2.61) AC_INIT(rpm, 4.4.90, rpm-maint@lists.rpm.org) -AC_CANONICAL_TARGET + AC_CONFIG_SRCDIR([rpmqv.c]) AM_CONFIG_HEADER([config.h]) @@ -90,7 +90,7 @@ dnl dnl AC_MSG_CHECKING(flag used by libtool to link rpm) if test X$GCC = Xyes ; then - case $target in + case $host in *-*-linux*) LDFLAGS_STATIC=-all-static ;; *-*-solaris*) LDFLAGS_STATIC=-static;; *-*-hpux*) LDFLAGS_STATIC=-static;; @@ -99,7 +99,7 @@ if test X$GCC = Xyes ; then *-*-*) LDFLAGS_STATIC=;; esac elif test X$CC = Xcc ; then - case $target in + case $host in *-*-linux*) LDFLAGS_STATIC=-all-static;; *-*-freebsd*) LDFLAGS_STATIC=-all-static;; *-*-osf*) LDFLAGS_STATIC=;; # OSF5 has no shared pthreads libs @@ -275,7 +275,7 @@ addlib() { addlib() { l=$1 shift - case $target in + case $host in *-*-solaris*)LIBS=$LIBS -L$l -R$l $*;; *) LIBS=$LIBS -L$l $*;; esac @@ -611,7 +611,7 @@ AC_SUBST(DBLIBOBJS) AC_SUBST(DBLIBOBJS) dnl AmigaOS and IXEmul have a fork() dummy - case $target in + case $host in m68k-*-amigaos ) echo Building for AmigaOS: using vfork() instead of fork(); CFLAGS=$CFLAGS -Dfork=vfork @@ -892,7 +892,7 @@ fi WITH_SELINUX_LIB= with_selinuxval=no -case $target in +case $host in *-*-linux*) with_selinuxval=yes ;; esac withval=${with_selinuxval} ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 unable to be cross compiled. Like with any other autoconf'ed project, just do configure --build=build-host --host=target It's how any autoconf'ed project works. Please validate that it's still working then. In the past when folks have made these changes they have always lead to the target version of RPM getting host system definitions and special flags. --Mark ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [patch] rpm is not a cross-tool
The easiest way to check this. (Conceptually.. tailor to suit) On a non-linux host, such as solairs, configure to run on a linux host. If you following the paths through configure, you'll see it checks and hardcodes values based on the settings. I'm not an autoconf expert so I'll leave which variables are the right ones to you.. but the key is that when you configure, picking the solaris CFLAGS, and other configurations is obviously wrong when targeting linux. A little less extreme. Configuring on an x86_32 linux host, to run RPM on arm linux machine. Again, there is another set 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 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. Like with any other autoconf'ed project, just do configure --build=build-host --host=target It's how any autoconf'ed project works. Please validate that it's still working then. How can I? You'd have to tell me how you have been configuring/building rpm and using rpm? What this patch does is to fix cross-building rpm, i.e. cross-building the rpm package for a foreign target, e.g. to build a solaris rpm on i386-linux. In the past when folks have made these changes they have always lead to the target version of RPM getting host system definitions and special flags. Ralf ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint
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 the packages I've worked with, this has always been policy. It's not difficult to ensure that all of the proper symlinks are always shipped in a package. (Using ldconfig to generate missing symlinks is a really bad crutch, IMHO, that should be avoided. Most people don't realize this, but ldconfig (and ld.so.cache) aren't actually needed for a linux system to operator correctly.) --Mark Opinions? Bill ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org https://lists.rpm.org/mailman/listinfo/rpm-maint