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

[Mark Hatle]

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)

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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)

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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)

[Mark Hatle]

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)

[Mark Hatle]

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)

[Mark Hatle]

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)

[Mark Hatle]

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

[Mark Hatle]

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)

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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?

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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?

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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?

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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

[Mark Hatle]

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!

[Mark Hatle]

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