Midi-player for FC - an will there be anyone in FC3?
by Kyrre Ness Sjobak
Hmm... Does anybody know why Fedora haven't included a simple
midi-player, which simply sends things to your soundcard for rendering,
which in turn plays it?? And does anybody know about a good such
program?
Kyrre Ness Sjøbæk
19 years, 8 months
[fedora.us] More bugzilla ticket reassignments
by Michael Schwendt
Yesterday evening I went through bugzilla.fedora.us new package
requests, preparing another batch of ticket reassignments. The tickets
will be assigned to the packager (i.e. assignee = package owner). That
makes it easier to sort http://fedora.us/QA by owner and look for
familiar names and e.g. look at who has packaged what.
So, don't be surprised when you receive "bugzilla spam" in your
mailbox and don't know how to interpret the re-assignments.
19 years, 8 months
Re: RPM debuginfo problems
by Eric Smith
About two weeks ago, I wrote:
> When I try to rebuild Fedora RPMs, I routinely complaints like:
> error: Could not open %files file
> /home/esmith/rpmbuild/BUILD/kernel-utils-2.4/debugfiles.list: No such
> file or directory
Michael Schwendt replied:
> Never heard about this problem before nor seen it myself.
>
> $ cat ~/.rpmrc
> include: /usr/lib/rpm/redhat/rpmrc
>
> $ rpm -q redhat-rpm-config
> redhat-rpm-config-8.0.28-1.1.1
>
> What else does your ~/.rpmmacros contain?
That was the problem. My system started with Red Hat 3.0.3, and has
been upgraded to every version through RH 9.0, then FC1 and FC2. But
it did not have redhat-rpm-config installed, nor did I know of it.
I used to rebuild packages just fine without it.
Is the need for redhat-rpm-config and the include in .rpmrc documented
somewhere?
Thanks,
Eric
19 years, 8 months
Inn
by Lukasz Trabinski
Hello
What's the reason that inn is still in 2.3.5 version? The latest version
of inn is 2.4.1.
--
*[ Łukasz Trąbiński ]*
19 years, 8 months
Re: Gnome 8.0.... Gnome 2.8
by James Harrison
Errrrr..
......Sorry typo : Gnome 2.8....... Not 8
--- James Harrison <jamesaharrisonuk(a)yahoo.co.uk> wrote:
> Hi,
>
> Is it too late in the FC3 development cycle to use Gnome 8?
>
> James
>
>
>
> __________________________________
> Do you Yahoo!?
> New and Improved Yahoo! Mail - Send 10MB messages!
> http://promotions.yahoo.com/new_mail
>
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail
19 years, 8 months
Re: rawhide report: 20040917 changes
by Reuben Farrelly
Hi,
At 03:39 a.m. 18/09/2004, Brian Millett wrote:
> >> udev-030-26
> >> -----------
> >> * Mon Sep 13 2004 Jeremy Katz <katzj(a)redhat.com> - 030-26
> >>
> >> - require a 2.6 kernel
> >> - prereq instead of requires MAKEDEV
> >> - obsolete and provide dev
> >> - add a trigger for the removal of /dev so that we set things up
> >>
> >> * Fri Sep 10 2004 Dan Walsh <dwalsh(a)redhat.com> - 030-25
> >>
> >> - Use matchmediacon
> >>
> >
> > Ok, right now after updating to this latest, I can not boot. I get to
> > the point of this:
> >
> > Red Hat nash version 4.1.9 starting
> > Mounted /proc filesystem
> > Mounting sysfs
> > Loading jdb.ko module
> > Creating block devices
> > Creating root device
> > Mounting root filesystem
> > kjournald starting. Commit interval 5 seconds
> > EXT3-fs: mounted file system with ordered data mode.
> > Switching to new root
> >
> >
> > Then it just hangs and nothing happens. It doesn't matter if I use
> > older kernels, same behavior. I have no clue. Is it because the dev
> > package was deleted? I had set in /etc/udev/udev.conf
> > UDEV_INITRD="no"
> > to avoid the many error messages at boot time, should that be set to
> > "yes"? Then remake the initrd?
>
>Well, normally I hate to answer my own post, but in this case I'm
>ecstatic. Setting UDEV_INITRD="yes" and regenerating the initrd fix my
>situation.
>
>kernel=2.6.8-1.549
>MAKEDEV-3.13-1
>udev-030-26
I was bitten by this too - the removal of dev broke things a bit. However,
I'm not using an initrd as I'm compiling my own kernels from kernel.org.
What is the best way to work around it in this situation? Am I about to be
forced to use an initrd?
Reuben
19 years, 8 months
certwatch: SSL certificate expiry warning tool
by Joe Orton
The latest version of the crypto-utils package in Raw Hide includes
certwatch(1), which can be used to check whether an X.509 certificate
has expired or is about to expire, and issue warning messages as
necessary.
It's implemented in /etc/cron.daily/certwatch to, by default, check all
certificates configured in the mod_ssl configuration, but this can be
extended to any other services which use SSL certificates.
Regards,
joe
19 years, 8 months
MIME registration breaks readonly /usr/share
by Enrico Scholz
Hello,
the current method to register MIME types (
| update-mime-database "/usr/share/mime"
in %post scriptlets) breaks[1] on setups where /usr/share is mounted
readonly. This bug seems to affect a lot of recent gnome packages so
that a general solution must be found.
The "right" thing would be probably to do the needed checks in the %post
scriptlets. But:
* rpm does not offer simple ways for this[2]
* every package whould need this check
Last point could be solved by a %__update_mime_database macro incorporating
the required tests and actions. But the first issue stays so that a quick
hack like checking for EROFS in 'update-mime-database' is perhaps the best
solution for now.
Enrico
Footnotes:
[1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=132847
[2] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=51193
19 years, 8 months
/dev/dri/* and SE Linux
by Russell Coker
In the latest CVS SE Linux policy xserver_macros.te has:
# Create and access /dev/dri devices.
allow $1_xserver_t device_t:dir { setattr rw_dir_perms };
allow $1_xserver_t dri_device_t:chr_file create_file_perms;
[...]
# Do not flood audit logs due to device node creation attempts.
dontaudit $1_xserver_t device_t:chr_file create;
[...]
allow $1_xserver_t device_t:dir { create };
It seems that the first and second sections don't work well together. Since
we changed /dev/dri to have type device_t instead of dri_device_t it seems
that attempts to create /dev/dri/whatever will be permitted on the
device_t:dir access but dontaudit'd on the device_t:chr_file access.
Does it even make sense to allow creating device nodes under /dev/dri now that
we have udev doing so much? Can't udev do this for 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
19 years, 8 months
