devel September 2004

devel@lists.fedoraproject.org

251 participants
243 discussions

Midi-player for FC - an will there be anyone in FC3?
by Kyrre Ness Sjobak 18 Sep '04

18 Sep '04

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

5 15

[fedora.us] More bugzilla ticket reassignments
by Michael Schwendt 18 Sep '04

18 Sep '04

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.

4 6

Re: RPM debuginfo problems
by Eric Smith 18 Sep '04

18 Sep '04

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

1 0

Inn
by Lukasz Trabinski 18 Sep '04

18 Sep '04

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 ]*

1 0

rawhide report: 20040918 changes
by Build System 18 Sep '04

18 Sep '04

Updated Packages: rpmdb-fedora-2.91-0.20040918 ----------------------------

1 0

Re: Gnome 8.0.... Gnome 2.8
by James Harrison 18 Sep '04

18 Sep '04

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

3 2

Re: rawhide report: 20040917 changes
by Reuben Farrelly 18 Sep '04

18 Sep '04

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

2 1

certwatch: SSL certificate expiry warning tool
by Joe Orton 18 Sep '04

18 Sep '04

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

2 1

MIME registration breaks readonly /usr/share
by Enrico Scholz 17 Sep '04

17 Sep '04

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

1 0

/dev/dri/* and SE Linux
by Russell Coker 17 Sep '04

17 Sep '04

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

3 5

← Newer
1
...
9
10
11
12
13
14
15
...
25
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel September 2004