python-numeric missing on x86_64
by Shahms King
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Just reporting another x86_64 problem. The pygtk2 update requires
python-numeric which isn't build for x86_64.
- --
Shahms E. King <shahms(a)shahms.com>
Multnomah ESD
Public Key:
http://shahms.mesd.k12.or.us/~sking/shahms.asc
Fingerprint:
1612 054B CE92 8770 F1EA AB1B FEAB 3636 45B2 D75B
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iD8DBQFDJvqY/qs2NkWy11sRApJaAJ4wYlJmzzxpo4ejy96oS6hWnJzLAQCfVZbd
iuW8iAmGSTn5KbAokbKq/1I=
=8cCf
-----END PGP SIGNATURE-----
18 years, 7 months
Re: cupsd: minor nit
by Russell Coker
Thread taken from fedora-selinux-list to fedora-devel-list for a wider
audience. The general concept is that a daemon should never create a
directory under /var/cache (or similar non-specific places on the file
system) at run-time. If /var/cache/$DAEMON is needed then the package of
$DAEMON should provide that directory. This prevents the possible problem of
name conflicts and allows more restrictive SE Linux access control
(preventing a compromised daemon from performing a trivial DOS attack on
other daemons).
On Tuesday 13 September 2005 01:30, Tom London <selinux(a)gmail.com> wrote:
> OK, so the rubric here is that daemon-like services need to have their
> 'major' directory entries in places like /var created and labeled by their
> package, not created upon startup. This sounds quite reasonable.
Yes, that's my idea.
> So, the normal 'name space' conflicts will likely be detected during
> package install.
One of several benefits of it.
> Do we need to be concerned with possible 'widening' conflicts on such
> directories (e.g., two packages wanting to 'own' the same directory, one
> with a 'wider' label)?
What do you mean "wider"? Do you mean less restrictive permissions? If so
then it certainly would be a problem if two packages desired different
permissions for a single file system object, whether one is a superset of the
other or whether they are disjoint. It is something that we need to be
concerned about, but it will hopefully be rare and we can just fix it when it
occurs.
Detecting and solving such problems is an advantage of my suggestion. When we
have such directories in packages we can easily check for such conflicts. At
the moment I suspect that such daemon behavior is not uncommon and don't know
in what situations it may potentially bite us.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
18 years, 7 months
Re: FC4 state of affairs and FC5
by Gilboa Davara
Mark,
Im reaching the point of desperation concerning this problem
I doubt that Ill ever be fixed. (It's been here since FC4T2)
As you said, the RPMs in updates-testing doesnt solve the problem. (my Palm T3 starts syncing and quiets immediately. though at least gpilot stopped cashing... which is something, I guess...)
I cannot use your RPMs (Cheers for making them, though) as their versions collide with the updates and update-testing versions. (Can you bump the version numbers?)
Can someone please incorporate Mr. Adams fixes into the main trunk and release them into update-testing? Ill be forever in his debt. (And I make a killer Spaghetti Bolognese)
Gilboa
----- Original Message -----
From: "Mark G. Adams" <mark.g.adams(a)sympatico.ca>
Date: Monday, September 12, 2005 2:15 am
Subject: Re: FC4 state of affairs and FC5
> (apologies for lack of message threading - I just subscribed to be
> ableto chip into the conversation)
>
> > > >How can the yet-to-be founded FC foundation help external
> > > >contributers (Such as Mr. Adams) get their fixes into the system
> > > >faster?
> > > There is no need to way for a foundation for such things. Users
> or
> > > developers can report such issues in bugzilla. Precise and
> helpful
> > > information will probably result in a quicker fix
> > Patches are especially appreciated, even if they are incorrect in
> > some way. You don't have to be some kind of committer to be a
> developer.
> In this particular case, I did the analysis and had patches posted by
> June 27th since nothing seemed to be happening and this bug was a
> blocker for me:
> http://bugzilla.gnome.org/show_bug.cgi?id=274032
>
> This is referenced by the following bug in the RedHat bugzilla the
> sameday:
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160278
>
> Upon request, I put together RPMs (src, i386 and x86_64) a couple of
> weeks later (July 18th) since many others have been running into this
> bug and are waiting for a resolution.
>
> The issue in this particular case isn't a lack of analysis or a
> lack of
> patches, or even a lack of pulling them together to create new SRPMs
> which could be checked, tested and released. The issue is: why has it
> been almost 2.5 months since analysis & patches have been made
> availablebut no updated official packages have been made?
>
> (to be fair, the recently updated evolution and evolution-data-server
> packages do include the required patches; however, they're
> insufficientto solve this bug without updated gnome-pilot and pilot-
> link packages)
>
> //Mark
>
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
18 years, 7 months
Comments on X.Org X11 modularization project - rpm package driver naming
by Philip Prindeville
Sorry for missing the August 29th deadline... Hopefully better
late than never.
While I agree that moving to separate packing of the X drivers
is a good thing, I'm wondering if we don't need to release the
X server (as Xorg or Xfree86 or whatever) as a separate entity
as well, as in the case where additional functionality has been
added to support new driver features, or the server API has
changed internally.
Just an observation.
Would the X server proper, the Mesa and DRM/DRI drivers,
etc. continue to be released as part of the "xorg-x11" (tout
court) package? Or am I missing something?
Thanks,
-Philip
18 years, 7 months
anybody else having cups trouble?
by sean darcy
Don't know when it started, but within the last couple of days:
Starting cups: Traceback (most recent call last):
File "/usr/sbin/printconf-backend", line 7, in ?
import backend
File "/usr/share/printconf/util/backend.py", line 42, in ?
import rhpl.ethtool
ImportError:
/usr/lib64/python2.4/site-packages/rhpl/ethtool.so:
undefined symbol: iw_pr_ether
python-2.4.1-2
rhpl-0.170-1
system-config-printer-0.6.142-1
cups-1.1.23-17
Anybody else seeing this?
sean
18 years, 7 months
FC4 kernel 2.6.12-1.1450
by Bojan Smojver
Just a quick note that this one (from testing) appears to be much better
than 1447 in terms of ACPI on my notebook (HP ZE4201). Battery reporting
appears to work properly, even after suspend-resume cycles and there are
no more strange clock issues.
--
Bojan
18 years, 7 months
[Fwd: Plans for Sparc???]
by Rahul Sundaram
Hi
I am curious about this one too
regards
Rahul
------------------------------------------------------------------------
Subject:
Plans for Sparc???
From:
"Brian D. McGrew" <brian(a)visionpro.com>
Date:
Mon, 12 Sep 2005 13:29:12 -0700
To:
<fedora-list(a)redhat.com>
With fedora-i386 and fedora-ppc, will there be a fedora-sparc port???
-brian
Brian D. McGrew { brian(a)visionpro.com || brian(a)doubledimension.com }
---
>> Those of you who think you know it all,
>
>
really annoy those of us who do!
-- fedora-list mailing list fedora-list(a)redhat.com To unsubscribe:
http://www.redhat.com/mailman/listinfo/fedora-list
18 years, 7 months
Re: FC4 state of affairs and FC5
by Mark G. Adams
(apologies for lack of message threading - I just subscribed to be able
to chip into the conversation)
> > >How can the yet-to-be founded FC foundation help external
> > >contributers (Such as Mr. Adams) get their fixes into the system
> > >faster?
> > There is no need to way for a foundation for such things. Users or
> > developers can report such issues in bugzilla. Precise and helpful
> > information will probably result in a quicker fix
> Patches are especially appreciated, even if they are incorrect in
> some way. You don't have to be some kind of committer to be a developer.
In this particular case, I did the analysis and had patches posted by
June 27th since nothing seemed to be happening and this bug was a
blocker for me:
http://bugzilla.gnome.org/show_bug.cgi?id=274032
This is referenced by the following bug in the RedHat bugzilla the same
day:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160278
Upon request, I put together RPMs (src, i386 and x86_64) a couple of
weeks later (July 18th) since many others have been running into this
bug and are waiting for a resolution.
The issue in this particular case isn't a lack of analysis or a lack of
patches, or even a lack of pulling them together to create new SRPMs
which could be checked, tested and released. The issue is: why has it
been almost 2.5 months since analysis & patches have been made available
but no updated official packages have been made?
(to be fair, the recently updated evolution and evolution-data-server
packages do include the required patches; however, they're insufficient
to solve this bug without updated gnome-pilot and pilot-link packages)
//Mark
18 years, 7 months
samba 3.0.20 rpms
by Tom Diehl
Hi all,
Can anyone tell me if there are any plans to update the rawhide samba rpms to
3.0.20 anytime soon?
Regards,
Tom Diehl tdiehl(a)rogueind.com Spamtrap address mtd123(a)rogueind.com
18 years, 7 months
