Re: rpm cpio error: prelink and SBCL
On Thu, Dec 17, 2009 at 5:13 PM, Jerry James loganje...@gmail.com wrote: Is that due to prelink? If so, what is broken? SBCL, because it You probably have a prelinked file in BUILD ROOT (objdump -s file | grep prelink) . Try to get rid of this in %install with prelink -u Regards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Fwd: Junior Jobs]
2009/10/19 Miroslav Suchý msu...@redhat.com: May be good idea for Fedora as well... Look like similar to the kernel janitor project initiative http://janitor.kernelnewbies.org/ Mirek Původní zpráva Předmět: [opensuse-packaging] Junior Jobs Datum: Tue, 13 Oct 2009 14:46:58 +0200 Od: Michal Hrusecky mhruse...@suse.cz Komu: opensuse-packag...@opensuse.org Hi, lately we formulated concept of openSUSE Junior Jobs[1]. Maintainers of openSUSE packages can choose some of theirs easy bugs and mark them as Junior Jobs. Then anybody from community can volunteer and fix these issues. These tasks will be easily fixable and their purpose is to let people learn how to contribute and to create some easy task so anybody can join and start participating. [1] http://en.opensuse.org/Junior_Jobs -- Miroslav Suchy Red Hat Satellite Engineering -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal: Python 3 in Fedora 13
On Thu, Oct 1, 2009 at 7:15 PM, David Malcolm dmalc...@redhat.com wrote:
Proposal: Python 3 in Fedora 13
Evolutionary, not revolutionary: build a python 3 stack
parallel-installable with the python 2 stack.
= High-level summary =
- Python 3.0 was released almost 10 months ago, on 2008-12-03, and the
latest release of the 3.* branch is 3.1.1, released on 2009-08-17.
- Other distros have python 3, though not necessarily with anything
on top resembling the full python 2 stack.
- We have a working, valuable python 2 stack, which is used by
critical system components (yum and anaconda): we must not destabilize
the python 2 stack.
- Python 3 is sufficiently different from python 2 that we need them
to be independent software stacks.
- I plan to spend a large chunk of my $DAYJOB over the next few months
trying to build a useful Python 3 stack for Fedora 13, for some
definition of useful (help will be appreciated!)
- I don't want to add extra work for package maintainers: if you
maintain an SRPM of a python 2 module that's working for you, you
shouldn't feel obligated to own a separate SRPM for python 3. If
someone has a need for the module on python 3, they can take on that
work.
= Background =
Python 3 is intended by upstream to be the future of Python, but we have
many critical components that use Python 2. Python 2 and Python 3 are
sufficiently different that we need both (try writing print in each).
Python 2 will be around for a long time.
An interesting summary of Python 3 adoption can be seen here:
http://renesd.blogspot.com/2009/09/py3kpython3-more-than-one-year-on-096.html
An earlier proposal about python 3 in Fedora is here:
https://www.redhat.com/archives/fedora-devel-list/2008-May/msg02417.html
Going forward, I will have plenty of time to spend, as part of my
dayjob, on Python in Fedora [1]
= Proposal =
I want to get python 3 into Fedora, but I don't want to break yum or
anaconda (or anything else, for that matter!)
How to do this? I propose that Fedora shall have separate,
parallel-installable Python 2 and Python 3 stacks. I believe we can get
things to the point where on a Fedora box you'd be able to install both
stacks, and have some processes running python 2 code, and some running
python 3, simultaneously.
Where I would draw the line is on having both python 2 and python 3
running within the same _process_: the two libraries share most of their
symbol names, but with differing implementations, and the result of
trying to dynamically link the two into the same address space would be
highly unstable.
As an example, you'd be able to install both mod_python and mod_python3
rpms, but you wouldn't be able to (sanely) configure httpd to have both
running simultaneously (I guess we should add a run-time warning for
this case)
Scoping:
- this work would target Fedora 13. I'd avoid pushing it into F12
until it's proven safe to do so
- the proposal is for python 2 vs python 3. It could be extended to
support having multiple minor-versions of Python as well, but that's a
big extension of the work involved and not something I'm planning to
work on myself.
= Details =
We should split python 2 and python 3 at the source RPM level, where
possible.
The easy case is when upstream release separate tarballs for the python
2 and python 3 versions of code. For example, given package
python-foo in packaging CVS, there would be a separate python3-foo
for the python 3 version. There would be no expectation that the two
would need to upgrade in lock-step. (The two SRPMS could have different
maintainers within Fedora: the packager of a python 2 module might not
yet have any interest in python 3)
The more difficult case is when the python module is emitted as part of
the build of a larger module. Some examples:
- the build of rpm itself emits an rpm-python subpackage.
- Another example is the postgres srpm, which emits a
postgresql-python subpackage.
In a quick attempt at seeing other examples, on my laptop (F11), here
are the packages installed that provide python modules where the package
name differs from the srpm name:
$ rpm -qf /usr/lib/python2.*/site-packages/* | grep -v is not owned |
SIA, this is off of topic , i am sure. BUT, it is very strange that could be
exists, perhaps, some file or directory not owned by someone. Isn't it ?
sort | uniq | xargs rpm -q --qf %{NAME}-%{VERSION}-%{RELEASE}
%{SOURCERPM}\n | sed -es/.src.rpm// | squeal -f table col0, col1 from
- where col0 != col1
col0| col1|
+--+
at-spi-python-1.26.0-1.fc11| at-spi-1.26.0-1.fc11|
audit-libs-python-1.7.13-1.fc11| audit-1.7.13-1.fc11|
cracklib-python-2.8.13-4| cracklib-2.8.13-4|
Re: sed -i symlink behavior...
On Thu, Sep 3, 2009 at 9:47 PM, Peter Bloomfield peterbloomfi...@bellsouth.net wrote: On 09/02/2009 10:07 AM, Warren Togami wrote: On 09/02/2009 11:39 AM, Jerry James wrote: On Wed, Sep 2, 2009 at 9:35 AM, Warren Togamiwtogami redhat com wrote: What is the correct behavior? Is this a bug that it changed? Read up on the --follow-symlinks option to sed. This is a new option it seems, meaning I can't rely on sed -i at all anymore. I'm rather displeased that a core utility fundamentally changed its own behavior. Warren Apparently [1] upstream sed always broke symlinks, and Red Hat made a patch to follow them instead. Fedora packages from some point up to sed-4.1.5-12.fc11 seem to have used it. So the default behavior in Fedora sed is now consistent with upstream, instead of with the prior patched version. That's inconvenient if you're accustomed to the Red Hat version, but better for interoperability! Peter [1] http://www.nabble.com/Re:-sed:-Patch-to-follow-symlinks-and--c-option-td7471749.html In fact the comment in this link is I want sed -i and perl -i to behave as similarly as possible. Hence, the patch is rejected as is. --copy is rejected for the same reason. . as i have already commented out previously. Regards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm/mock: can't upbuild FC10 targets on FC9 host
On Wed, Sep 2, 2009 at 11:52 PM, Philip Prindeville
philipp_s...@redfish-solutions.com wrote:
Seems to be an rpm versioning issue:
[r...@builder SRPMS]# mock -r fedora-10-x86_64 --rebuild
perl-Net-Patricia-1.15_01-1.fc9.src.rpm
INFO: mock.py version 0.9.14 starting...
State Changed: init plugins
State Changed: start
INFO: Start(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64)
State Changed: lock buildroot
State Changed: clean
State Changed: init
State Changed: lock buildroot
Mock Version: 0.9.14
INFO: Mock Version: 0.9.14
INFO: enabled root cache
State Changed: unpacking root cache
INFO: enabled yum cache
State Changed: cleaning yum metadata
INFO: enabled ccache
State Changed: running yum
State Changed: setup
ERROR: Exception(perl-Net-Patricia-1.15_01-1.fc9.src.rpm)
Config(fedora-10-x86_64) 0 minutes 15 seconds
INFO: Results and/or logs in: /var/lib/mock/fedora-10-x86_64/result
ERROR: Command failed:
# /usr/bin/yum --installroot /var/lib/mock/fedora-10-x86_64/root/
resolvedep ccache 'perl(ExtUtils::MakeMaker)'
rpmdb: Program version 4.3 doesn't match environment version
error: db4 error(-30974) from dbenv-open: DB_VERSION_MISMATCH: Database
environment version mismatch
error: cannot open Packages index using db3 - (-30974)
error: cannot open Packages database in
/var/lib/mock/fedora-10-x86_64/root/var/lib/rpm
Traceback (most recent call last):
File /usr/bin/yum, line 29, in module
yummain.user_main(sys.argv[1:], exit_code=True)
File /usr/share/yum-cli/yummain.py, line 229, in user_main
errcode = main(args)
File /usr/share/yum-cli/yummain.py, line 84, in main
base.getOptionsConfig(args)
File /usr/share/yum-cli/cli.py, line 184, in getOptionsConfig
enabled_plugins=self.optparser._splitArg(opts.enableplugins))
File /usr/lib/python2.5/site-packages/yum/__init__.py, line 192, in
_getConfig
self._conf = config.readMainConfig(startupconf)
File /usr/lib/python2.5/site-packages/yum/config.py, line 774, in
readMainConfig
yumvars['releasever'] = _getsysver(startupconf.installroot,
startupconf.distroverpkg)
File /usr/lib/python2.5/site-packages/yum/config.py, line 844, in
_getsysver
idx = ts.dbMatch('provides', distroverpkg)
TypeError: rpmdb open failed
[r...@builder SRPMS]#
The host was originally an FC8 host, that was yum updated to FC9. I use
it to build FC9 and FC10 packages via Mock.
Unfortunately, it looks like it doesn't want to use the old RPM database
from the previous FC8 install.
I am pretty sure that it is because this rpm proposed patch was rejected
upstream.
https://bugzilla.redhat.com/show_bug.cgi?id=464752.
https://bugzilla.redhat.com/show_bug.cgi?id=464752
The maintainer has already expressed his opinion on this topic also on this
mailing list and is unnecessary to discuss further.
It seems however that without this patch, or something similar, can lead to
the situation reported in the last comments.
How do I clobber all of this to that the database gets written afresh?
Apparently, mock -r fedora-10-x86_64 --clean isn't adequate. Perhaps
mock --nuke would be useful here following an version update to zap
stale state?
Or should I just uninstall and reinstall mock?
Thanks,
-Philip
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: sed -i symlink behavior...
On Wed, Sep 2, 2009 at 5:35 PM, Warren Togami wtog...@redhat.com wrote: I just noticed some behavior changes within sed. Run the following commands in various distros. #!/bin/bash set -x echo abc original.txt ln -s original.txt symlink.txt sed -i 's/abc/123/' symlink.txt if [ -L symlink.txt ]; then echo yes symlink else echo not symlink anymore fi cat original.txt cat symlink.txt RHEL5 = [u...@rhel5 ~]$ echo abc original.txt [u...@rhel5 ~]$ ln -s original.txt symlink.txt [u...@rhel5 ~]$ sed -i 's/abc/123/' symlink.txt sed: ck_follow_symlink: couldn't lstat s/original.txt: No such file or directory [u...@rhel5 ~]$ cat symlink.txt abc [u...@rhel5 ~]$ cat original.txt abc original.txt is unmodified, symlink.txt is still a symlink. Fedora 10 = [u...@fedora10 ~]$ echo abc original.txt [u...@fedora10 ~]$ ln -s original.txt symlink.txt [u...@fedora10 ~]$ sed -i 's/abc/123/' symlink.txt [u...@fedora10 ~]$ cat symlink.txt 123 [u...@fedora10 ~]$ cat original.txt 123 original.txt is modified, symlink.txt is still a symlink. Fedora 11 and 12 [u...@fedora11 ~]$ echo abc original.txt [u...@newcaprica ~]$ ln -s original.txt symlink.txt [u...@newcaprica ~]$ sed -i 's/abc/123/' symlink.txt [u...@newcaprica ~]$ cat original.txt abc [u...@newcaprica ~]$ cat symlink.txt 123 original.txt is not modified, symlink.txt is no longer a symlink. symlink.txt now contains a modified version of original.txt as a plain file. What is the correct behavior? Is this a bug that it changed? Also perl -pi -e 's/abc/123/g' symlink.txt always have got the same result. Warren Togami wtog...@redhat.com -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Cannot rely on /dev being present in %post scripts?
On Wed, Aug 12, 2009 at 4:18 PM, David Woodhouse dw...@infradead.orgwrote: According to bug #517013, %post scripts should not assume that /dev is available -- so we can't do anything that requires the existence of /dev/null, /dev/urandom, etc. Is this a known and expected packaging rule, or is it a bug in the way that the user is attempting to install the packages? IMHO, if i want to install something in a chroot i have to create /dev, and /proc entry at least or put a bind mount to these. So, i think that it is the user have do some error in installaling the package. Regards -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Fri, Jul 31, 2009 at 4:26 PM, Jussi Lehtolajussileht...@fedoraproject.org wrote: On Mon, 2009-07-27 at 13:01 +0200, Michael Schroeder wrote: Hi folks, I'm the author of the libsatsolver library, a library solves package dependencies with a SAT algorithm. This library is currently used in SUSE by YaST/zypp. I'm currently trying to make it less SUSE specific like adding support for package coloring and different repo handling, but I'm pretty sure I didn't catch all things where Fedora is different from SUSE. To test things I've written a small application called solv that works like a very tiny package manager. It's available via: http://software.opensuse.org/search?baseproject=Fedora:11q=libsatsolver-demo Impressive: after the repository data has been downloaded, the calculation of the update from Fedora 10 (x86_64) to Fedora 11 takes less than two seconds (practically instantaneous!) on an Athlon64 X2 4600+. Sure. It is impressive. I already know because have already tried some time ago on fedora e suse. The principal problem remain : wants sat solver become a project cross distribution or not? The project rpm is already - with some local difference btw, but this don't change what i have said. Do think the author of SAT solvers that an open source cross platform solution could be beneficial to everyone, and to the sat solver project itself ? A project is a project, a distro is another thing. But i perhaps asked in different word the same question alreay asked : no answer. A good open source project should have more widespread audience instead to be tied to issues that perhaps are not so technical in nature. Best Regards Please release this as a separate project to help cross-distro development. This would be a pretty nifty tool in Fedora as well. PS. Some kind of a download progress bar (speed % of completion) would be nice. -- Jussi Lehtola Fedora Project Contributor jussileht...@fedoraproject.org -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Testing libsatsolver on Fedora
On Mon, Jul 27, 2009 at 1:01 PM, Michael Schroeder m...@suse.de wrote: Hi folks, I'm the author of the libsatsolver library, a library solves package dependencies with a SAT algorithm. This library is currently used in SUSE by YaST/zypp. I'm currently trying to make it less SUSE specific like adding support for package coloring and different repo handling, but I'm pretty sure I didn't catch all things where Fedora is different from SUSE. To test things I've written a small application called solv that works like a very tiny package manager. It's available via: http://software.opensuse.org/search?baseproject=Fedora:11q=libsatsolver-demo (To get the src rpm search for libsatsolver) The package contains just a single file, /usr/bin/solv. It can be run as normal user, but then the transaction can't be commited. Also, the repository metadata caching mechanism needs write access to /var/cache/solv. If it can't write there, it still works but downloads the metadata again every time it is called. So, if you have some spare time, could you give it a try and tell me where it works well/ does stupid things/ doesn't work at all? Thanks, Michael. BTW, if you want a wider audience for your project, outside the narrow circle of people involved in rpm development :=) for example, so that it can be considered for inclusion in different distributions from OpenSUSE, you should, as usual, publish it as a separate and autonomous project. This is what do yum and smart for example, both in Fedora repository. Regards (aside) in a (perhaps old but not i cannot check now the latest release) RHEL5 release glibc don't have qsort_r ( http://sourceware.org/bugzilla/show_bug.cgi?id=173) so the code don't compile. http://sourceware.org/ml/glibc-cvs/2007-q4/msg00436.html -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Lower Process Capabilities
On Mon, Jul 27, 2009 at 5:29 PM, Adam Jacksona...@redhat.com wrote: On Mon, 2009-07-27 at 19:25 +1000, James Morris wrote: On Sun, 26 Jul 2009, Steve Grubb wrote: The basic idea goes something like this: We would like to do something to prevent priv escalation for processes running as root. For this example, lets take cupsd to be a good case in point. If the attacker can find a vuln with cupsd, then they can have root privs and all that goes with it. (SE Linux may prevent total compromise, but some people turn it off.) We should put effort into improving SELinux rather than papering things over with new or previously discarded security schemes. Capabilities are inherently problematic in that you can't meaningfully reason about overall system behavior with them. e.g. what does CAP_SYS_ADMIN actually mean? Here's where the symbol is found in the kernel source: http://www.cs.fsu.edu/~baker/devices/lxr/http/ident?i=CAP_SYS_ADMIN I challenge anyone to explain the boundary of privilege for any process which has this capability, and how the propagation of that privilege is bounded within the system as a whole. We can do that with SELinux (in fact it's been somehwat designed for this purpose), and that's how we should approach the problem. I agree with this, with some caveats. Capabilities are hard to reason about, and not just because they're coarse-grained. Practically speaking they don't get used, so kernel developers are careless about picking the right capable() check for a given action, since it ends up being a fancy way of checking current-euid. To pick a favorite example: CAP_SYS_RAWIO is documented to mean iopl, ioperm, and /dev/kcore. It actually means significantly more than that. It's effectively equivalent to root, though, because write access to /dev/kcore means you can change your uid. You might like it to mean can do raw I/O to peripherals like the name suggests, but the one most useful thing that could mean - r/w maps of PCI BARs - is covered under CAP_SYS_ADMIN instead. Which is not merely equivalent to root, but so coarse that it's basically useless. So it's hard for me to justify trying to make X use capabilities, since I'm not meaningfully limiting X's privileges in doing so. Caps are also wrong in that they're effectively a partitioning of root's privileges above those of a user. You would like the ability to do more than that. For example, you'd like to be able to remove your ability to clone() or exec(). SELinux can do this, kinda. Put an example, thanks. And, of course, at an implementation level caps are just a dword bitmask, which is not nearly enough granularity. However, the inheritance model is _not_ hard to reason about. I find it slightly easier to understand than selinux transitions, in fact. And capabilities have the notable advantage of being something I can drop for myself when I don't need them, a safety model I'm used to from setuid. I would like to use SELinux as a defensive development practice, but I'm not aware of any good way to do so. All I have is the hope that the user is running with the policy enabled. - ajax -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Need a sponsor: mod_proxy_html (apache)
Wow. Who knew sponsors were that hard to come by? Especially when most of the work is already done... FWIW, having I the need to use this module on Fedora and RHEL I have already included it in my RPM repository, and so I am using it in production without a problem. Regards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
On Sat, Jul 11, 2009 at 12:26 AM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Jul 10, 2009 at 11:29:43PM +0200, yersinia wrote: Ok. But prelink it or not a requisite for ASLR or not ? In other word, besides performance is disabling prelink a security matter or not ? It is not bad to have some answer on this. ASLR happens with prelink or without. Particularly, PIEs (should be used for most of suid/network facing or otherwise security exposed programs) are always randomized, both the binary itself and all shared libraries it uses. Other than that, on prelinked system libraries are assigned random addresses whenever reprelinked, while when not prelinked, libraries are given random addresses on every exec. Non-PIE binaries have always fixed address. Jakub Thank a lot for your answer: this was a delicate and very interesting issue, for me almost. Best regards -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: an update to automake-1.11?
On Tue, Jul 7, 2009 at 6:45 PM, Braden McDaniel bra...@endoframe.comwrote: On Tue, 2009-07-07 at 01:17 -0700, Toshio Kuratomi wrote: On 07/06/2009 08:09 PM, Braden McDaniel wrote: On Mon, 2009-07-06 at 16:36 -0700, Toshio Kuratomi wrote: On 07/06/2009 03:57 PM, Braden McDaniel wrote: On 7/6/09 6:10 PM, Toshio Kuratomi wrote: [snip] Introducing side-effects is something to watch out for but patching configure instead of the true source is a short term fix, not a long term solution. *Any* patch should be viewed as a short-term fix. A patch that needs to persist indefinitely suggests broken maintainership somewhere along the line--either upstream, of the Fedora package in question, or elsewhere in Fedora's infrastructure. nod But one of those patches is upstreamable and the other is not. The upstreamable patch is a step on the road to the long term fix. The non-upstreamable one is a dead-end. Creating a patch to configure/Makefile.in in no way precludes a package maintainer from sending an analogous patch to configure.ac/Makefile.am upstream. So, yes, it's a dead end that: 1. reduces the size of the changeset between the upstream package and the one Fedora actually builds and 2. improves the resiliency of the package build to changes to Fedora's autotools chain. Perhaps but it doesn't decrease the work that the maintainer has to do. It very well might if Fedora upgrades to a new autoconf, automake, or libtool that is not 100% backward compatible with the previous version. It is not hard at all to have ALL the version of autotool installed. Simply pick one (for example for automake) version for the default (for example 1.10 ) and call this package automake. If you want also automake 1.11 package this as automake-1.11 rpm and, if the developer want, it is its choice, use this instead of the default via the autotool env var. I do this in RHEL also for libtool 2.2 ecc. -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr.
rviny...@cs.nmsu.eduwrote:
Michael Schwendt wrote:
On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote:
What is the effect on non-Fedora and older distributions (pre F10) if I
mark a subpackage (such as documentation) with BuildArch: noarch?
You can evaluate the %fedora variable to use this new feature only
for Fedora = 10:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
Excellent. That's what I was looking for.
No, it is not right for me. The BuildArch issue depends on the RPM version
and not from from distro version. It is simply bad style, IMHO, defining
in the SPEC file something that depends from the distribution (in the
large sense not only fedora). I never see
this style in RHEL package (appart some little package for the rpm keys
ecc). Ok is SUSE yes but, again, i don't like define a dependency based on
a distro version, if possible anyway.
regards
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Thu, Jul 9, 2009 at 2:48 PM, Ben Boeckel maths...@gmail.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
yersinia wrote:
On Wed, Jul 8, 2009 at 5:07 PM, Rick L. Vinyard, Jr.
rviny...@cs.nmsu.eduwrote:
Michael Schwendt wrote:
On Wed, 8 Jul 2009 07:59:43 -0600, Jr. wrote:
What is the effect on non-Fedora and older distributions
(pre F10) if I
mark a subpackage (such as documentation) with BuildArch:
noarch?
You can evaluate the %fedora variable to use this new
feature only
for Fedora = 10:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
Excellent. That's what I was looking for.
No, it is not right for me. The BuildArch issue depends on the
RPM version
and not from from distro version. It is simply bad style,
IMHO, defining
in the SPEC file something that depends from the
distribution (in the
large sense not only fedora). I never see
this style in RHEL package (appart some little package for the
rpm keys
ecc). Ok is SUSE yes but, again, i don't like define a
dependency based on
a distro version, if possible anyway.
regards
I don't think you should use a spec file for two distros. AFAIK,
SuSE uses /opt for stuff. Fedora uses /usr. The file listings
would be different for each. I don't think you can have an
every-rpm-distro-under-the-sun specfile and not have it either
messy or wrong.
No everyone agreed with this or would the spec/rpm version frammentation go
forever.
http://www.mail-archive.com/rpm-ma...@lists.rpm.org/msg00885.html
http://www.mail-archive.com/rpm-ma...@lists.rpm.org/msg00939.html
Regards
- --Ben
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkpV5zgACgkQiPi+MRHG3qTg4wCbBmmc7nSkN9NNF0xK94Evs11f
4xEAoLtciGgwjRkCl6wiGYt1v3pazh6l
=L40w
-END PGP SIGNATURE-
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
On Thu, Jul 9, 2009 at 4:55 PM, Ulrich Drepper drep...@redhat.com wrote: Adam Miller wrote: I am curious as to this answer as well because prelink has been something that actually hurt my netbook in performance so I nuked it. Performance only ever can be hurt because prelink runs periodically to prelink newly installed code or re-randomize to increase security. prelink has two benefits: - almost all relocations a program has to perform are avoided. These can be very expensive when many dependencies and/or large symbol tables are involved. The latter is somewhat mitigated by the new symbol table hashing we implemented some time back but still. - as a side effect of the first point some pages in the loaded binary are not copied-on-write. This can obviously have good effects on systems with little memory (netbooks). Just run your own tests on apps with many relocations and dependencies. FF, OO.org, most GUI apps come into mind. Use LD_DEBUG=statistics some/program to compare numbers. Run it with and without prelink (but always with hot disk cache to be fair). The number of cycles for total startup is representative of the win. Note, also small but frequently used apps benefit. I run gcc etc a lot and like every single saved cycle. But something one have to pay a security prize on not disabling it : it render impossible to have a centralizzated security integrity management (e.g. rfc.sf.net for example) or one have to skip from check the prelink binary. Very bad i think. -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
On Thu, Jul 9, 2009 at 5:12 PM, Jakub Jelinek ja...@redhat.com wrote: On Thu, Jul 09, 2009 at 05:07:05PM +0200, yersinia wrote: But something one have to pay a security prize on not disabling it : it render impossible to have a centralizzated security integrity management (e.g. rfc.sf.net for example) or one have to skip from check the prelink binary. Very bad i think. That's what prelink -y is for, it verifies the binary would prelink from unprelinked state to bitwise same file and gives you the bits before prelinking, which you can use for verification. rpm -V uses this, why can't other security integrity apps do the same? Yes I know that rpm do this. But other centralizzated integrity checker, perhaps for portability between posix platform, at max permit to skip the check - OSSSEC for example iirc do this - on prelinked binary. regards Jakub -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: prelink: is it worth it?
On Thu, Jul 9, 2009 at 8:19 PM, Steve Grubb sgr...@redhat.com wrote: On Thursday 09 July 2009 10:45:55 am devzero2000 wrote: There are also other two big problem, imho, now, with prelink support: 1 - it render impossibile to do a centralizzated integrity checker (with as example rfc.sf.net ): very very bad The aide program in rawhide is prelink friendly. So there are integrity checkers that can be used. As for security, prelink stirring around address space randomization is good for security. For example, this hack needed prelink not to have run to get the exploit reliable: http://invisiblethingslab.com/pub/xenfb-adventures-10.pdf There are more examples like this. i know this ref. Tell me something other. I follow only 15 mailing list on these subjects. Anyway if prelink is a good thing for ASLR IT MUST BE DOCUMENTATED BETTER. I am sure anyone agreed on this. regards -Steve -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr.
rviny...@cs.nmsu.eduwrote:
Jussi Lehtola wrote:
On Thu, 2009-07-09 at 18:28 +0200, Farkas Levente wrote:
Except it should be:
%if 0%{?fedora} 9 || 0%{?rhel} 5
it'd be nice if _all_ packages which have noarch subpackage use this
since most fedora packager reply to my such patches that they don't care
about rhel/centos:-(
This should really be a macro in rpm, as it has to be duplicated in so
many places. Say, %{_noarch_subpackage} which would expand to
%if 0%{?fedora} 9 || 0%{?rhel} 5
BuildArch:noarch
%endif
Yes, it really should. Otherwise, some will look like:
%if 0%{?fedora} 9
BuildArch: noarch
%endif
and others like:
%if 0%{?fedora} 9 || 0%{?rhel} 5
BuildArch: noarch
%endif
If you need further proof of the confusion simply look to this thread.
Plus it is more expressive as to what the intent of the check is for,
allowing a smoother migration process if, in the future, a check is put in
for the rpm version.
So you agreed that the check is on the rpm version, not distro version.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: noarch subpackages
On Thu, Jul 9, 2009 at 10:14 PM, Jussi Lehtola
jussileht...@fedoraproject.org wrote:
Lainaus yersinia yersinia.spi...@gmail.com:
On Thu, Jul 9, 2009 at 8:50 PM, Rick L. Vinyard, Jr.
rviny...@cs.nmsu.eduwrote:
Jussi Lehtola wrote:
This should really be a macro in rpm, as it has to be duplicated in so
many places. Say, %{_noarch_subpackage} which would expand to
Yes, it really should. Otherwise, some will look like:
clip
If you need further proof of the confusion simply look to this thread.
Plus it is more expressive as to what the intent of the check is for,
allowing a smoother migration process if, in the future, a check is put
in
for the rpm version.
So you agreed that the check is on the rpm version, not distro version.
That would be up to the distro guys to do, since they can define the macro
how they wish.
He, macro %configure exist everywhere. Not bad at all to have everywhere a
rpm_version macro upstream. Also in the past this could be useful (think to
the %check stanza)
SuSe might define it to use their corresponding %{dist} variable. Or, it
could be defined to evaluate to empty, if the rpm version doesn't support
it. Or, it could evaluate just the noarch bit.
The beauty of this is, of course, that you could even skip the conditionals
and just define the macro per distro basis (e.g. in the redhat-rpm-macros
package): the macro in F-10 could be just %{nil} and in F-11 BuildArch:
noarch.
There has been some discussion about versioning rpm specfiles, but I don't
know whether that discussion lead anywhere.
Noone care of this. the rpm world is different from the deb world : it is
just a matter of fact, not sharp criticism at all.
--
Jussi Lehtola
Fedora Project Contributor
jussileht...@fedoraproject.org
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: rpm AutoRequires/AutoProvides and dsos not in linker path, do we care ?
On Wed, Jun 17, 2009 at 6:49 PM, Chris Adamscmad...@hiwaay.net wrote:
Once upon a time, Adam Jackson a...@redhat.com said:
Really we just need the moral equivalent of %exclude for autoreqprovs.
Yeah, I said that years and years ago, but RPM didn't want it.
Just for info, PLD some time ago have included a run-time dependency
filtering in RPM
that don't break file-color dependency for multilib system. Some other RPM fork
had already included it.
Here, an examples from opera
...
%prep
%ifarch %{ix86}
%if %{with qt4}
%setup -q -T -b 13 -n %{name}-%{version}-%{buildid}.gcc4-qt4.i386
%define _noautoreq 'libpng12.so.0(.*)'
%else
...
that filter matching Requires. This PLD patch provide also _noautoprov
and _noautoreqfiles.
The good thing, for someone almost, is that the filtering is possible
globally for platform and not in unportable way between distro in the
SPEC file.
Regards
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: the end of life for flash player (HTML5)
Enter silverlight :( And monolight http://www.mono-project.com/Moonlight --CJD -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Proposal (and yes, I'm willing to do stuff!): Must Use More Macros
On Fri, Jun 5, 2009 at 8:05 PM, Adam Williamson awill...@redhat.com wrote:
On Fri, 2009-06-05 at 13:50 -0400, Ray Strode wrote:
It seems to me it'd make sense to convert all these kinds of snippets
into macros. Am I right, or is there a reason against doing this?
It would be awesome to get rid of the boilerplate. Honestly though,
I'd rather the solution was just works than replace giant glob of
muck with %{glob_of_muck}
Yes indeed, this would be best in many cases. Some can't really be done
like that, though - like the snippets for Tcl and Python to define the
version, directories for certain types of file and so on. They're
just...informational. Defining them as macros seems the optimal
solution.
For instance, if a file gets dropped under /usr/share/icons/something
rpm should run gtk-update-icon-cache /usr/share/icons/something
automatically.
the gtk2 package should be able to drop a file in /usr/lib/rpm/redhat
that makes that happen. likewise, desktop-file-utils should be able
to drop a file there to make update-desktop-database get run and so
on.
I don't know how hard it would be to fix rpm to allow for that though.
This is definitely possible; Mandriva (I know I talk about MDV a lot,
I'm sorry, it's what I know! :) does this, via an implementation called
'file triggers'. This is not yet upstream, though.
In @rpm5.org, yes.
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
