FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

LinkBack Thread Tools
Old 06-26-2008, 11:44 PM
Matthew Jurgens

I am referring to Nagios v3

Fedora-packaging mailing list
Old 06-27-2008, 12:59 PM
"William L. Maltby"

On Fri, 2008-06-27 at 07:22 -0500, Johnny Hughes wrote:
> William L. Maltby wrote:
> <snip>

> >
> >> # yum update
> >> <omit the usual verbosity>
> >>
> >> Resolving Dependencies
> >> --> Running transaction check
> >> ---> Package java-1.4.2-gcj-compat.i386 0: set to be
> >> updated
> >> --> Processing Dependency: /usr/bin/rebuild-security-providers for
> >> package: java-1.4.2-gcj-compat
> >> --> Processing Dependency: /usr/bin/rebuild-security-providers for
> >> package: java-1.4.2-gcj-compat
> >> --> Processing Dependency: /usr/bin/rebuild-security-providers for
> >> package: java-1.4.2-gcj-compat
> >> --> Processing Dependency: /usr/bin/rebuild-security-providers for
> >> package: java-1.4.2-gcj-compat
> >> --> Finished Dependency Resolution
> >> Error: Missing Dependency: /usr/bin/rebuild-security-providers is needed
> >> by package java-1.4.2-gcj-compat
> >> ========================================
> >>
> >> ========================================
> >> # yum whatprovides /usr/bin/rebuild-security-providers
> >> <omit the usual verbosity>
> >> jpackage-utils.noarch : JPackage utilities
> >> =========================================
> >><snip>

> There is a newer version of jpackage-utils in the testing repo that
> should have that file in it:
> http://dev.centos.org/centos/5/testing/i386/RPMS/jpackage-utils-1.7.5-1jpp.1.el5.centos.noarch.rpm
> See if this helps

Update worked! Thanks!

> Thanks,
> Johnny Hughes
> <snip sig stuff>

Thanks again,

CentOS mailing list
Old 06-28-2008, 10:40 PM
Nicolas Mailhot

[adding jpp-discuss to the list]

-------- Message transféré --------
De: Jason L Tibbitts III <tibbs at math.uh.edu>
Sujet: [Fedora-packaging] Ownership of /etc/maven/fragments
and /usr/share/maven2/poms
Date: 28 Jun 2008 17:22:51 -0500

Sorry for the resend; this should have the correct address for the
java list.

I hope I'm CC'ing this sufficiently; I do not know if any
representatives form the Java group are members of fedora-packaging.

I was reviewing my first maven-using package and ran into an issue
with the Java packaging guidelines. Namely that they specify that
every maven-using package should own /etc/maven/fragments and
/usr/share/maven2/poms, which contradicts our usual policy on
directory ownership by multiple packages.

I don't really understand why the packages would need to own those
directories; jpackage-utils already serves as a kind of filesystem
package for java, it already owns /etc/maven and several
java-related directories in /usr/share, and all of the packages which
would own files in the two directories at issue already depend on it.
So I think jpackage-utils should just own /etc/maven/fragments and
/usr/share/maven2/poms and we can tweak the guidelines to not specify
that the individual packages own these directory.

Another possibility would be to shift this off to a java-filesystem
package analogous to our other *-filesystem packages which could own
these and various other java directories.

This would fix ownership issues for 22 packages currently.

Another separate bug related issue is the fact that the contents of
/etc/maven/fragments do not seem to be configuration files, and so
probably should not live under /etc. I do not have sufficient Java
knowledge to propose a solution, however.

- J<

Fedora-packaging mailing list

Nicolas Mailhot
Fedora-packaging mailing list
Old 06-30-2008, 01:28 PM
Andrew Overholt

Has anyone from JPackage or Fedora spoken with the Debian java people?

----- Forwarded message from Matthew Johnson <mjj29@debian.org> -----

> From: Matthew Johnson <mjj29@debian.org>
> To: Florian Grandel <jerico.dev@gmail.com>
> Cc: debian-java@lists.debian.org
> User-Agent: Mutt/1.5.17 (2007-11-01)
> Date: Mon, 30 Jun 2008 14:26:45 +0100
> Subject: Re: Developing with Java on Debian
> X-Mailing-List: <debian-java@lists.debian.org> archive/latest/9812
> On Mon Jun 30 10:01, Florian Grandel wrote:
> > Hi Java developers,
> >
> >> One problem that I haven't solved so far is how to get the classpath
> >> into the MANIFEST file as was proposed earlier in this thread.
> >
> > As you may have remarked from my earlier posts I am working with the
> > JPackage guys recently. Their "recommendation to Java developers" arguments
> > against adding classpaths to the manifest.
> Well, they are wrong.
> > Probably the first three arguments do not apply to the Debian
> > environment, but the last one may. I have not yet made up my mind on
> > that. I just didn't want you to loose their arguments:
> > "Do not use Class-Path references in MANIFESTs
> >
> > The Class-Path system of MANIFESTs is evil because:
> >
> > * It doesn't work with JDK 1.x.
> > * It only works at runtime, not at build time.
> > * It only works for a specific installation hierarchy.
> These are, as you say, not relevant for Debian. I particularly like the
> second point, since their solution of wrapper scripts means maintaining
> two lists of classpath, one in the build system and one in the wrapper
> _anyway_. The specific installation heirarchy thing is interesting. The
> wrapper script is going to have to have _some_ guess at the heirarchy
> and if that doesn't work you are just pushing the problem of creating
> the classpath onto the user, which is clearly bad.
> Sufficiently clever build systems should propagate the build CLASSPATH
> to the manifest automatically anyway.
> > * It can not be configured.
> It's unclear to me what they want to be configured at runtime by
> changing the classpath.
> > Wrapper scripts are much versatile and universal. We provide a set of
> > convenient shell helper functions for setting up such Unix scripts easily
> > (see jpackage-utils in project CVS)." [1]
> Wrapper scripts without classpath manifest items also result in
> large classpaths containing items you shouldn't have to know about (your
> dependencies' dependencies) and causes unnecessary transitions when
> these change.
> > You may also have a look at their build support system as they have some
> > quite useful helper scripts as well. jpackage-utils is available in
> > universe/contrib.
> But not available in Debian.
> > And as Richard was asking earlier how to identify dependencies within jar
> > packages: I am using Matthew's java-propose-classpath a lot and it works
> > fine (Thank you Matthew!). But sometimes it seems to miss some
> > dependencies, I have not yet found out why.
> Hmm, if you can give me a test case, I'd be very interested. It
> _should_ only suffer from giving you too many dependencies when there
> are multiple jars containing the same class.
> Matt
> --
> Matthew Johnson

----- End forwarded message -----

fedora-devel-java-list mailing list
Old 06-30-2008, 11:35 PM
David Relson

On Sun, 29 Jun 2008 18:13:20 -0400
Willie Wong wrote:

> On Sun, Jun 29, 2008 at 01:02:39PM -0400, Penguin Lover David Relson
> squawked:
> > Jun 29 12:53:02 fpc Failure writing to cs5535 codec
> > Jun 29 12:53:02 fpc Failure reading codec reg 0x7a,Last
> > value=0x7a800000
> >
> > I've got no idea why this started nor what software is responsible
> > for generating these messages.
> >
> > Any thoughts?
> >
> cs5535 seems to refer to the alsa audio driver
> the only thing software-wise that I can find with acronym fpc is the
> free pascal compiler... which I admit doesn't make much sense: why
> would a compiler care about writing to an audio driver?
> HTH,
> W

Hi Willie,

The box with the problem is named "fpc" which is why that string is in
the logging record.

The box is a fit-pc -- a nifty little low power gentoo machine I got a
few months ago. The cs5535 problem went away after I upgraded its
kernel from 2.6.20 to 2.6.24. I still don't know the actual cause of
the problem and (since it's gone) have stopped worrying.

Thanks for taking the time to search & help.


gentoo-user@lists.gentoo.org mailing list
Old 07-01-2008, 04:25 AM
"Erik Ch. Ohrnberger"

Title: Blank Stationery


Erik Ch. Ohrnberger

1556 Crimson Drive
+1 (248) 524-0341

Troy, MI 48083
+1 (248)*515-4306

Personal Fax:
+1 (302) 372-2042
Old 07-01-2008, 08:46 AM

I am trying to install Debian Etch on a box that already has Fedora
but when using debootstrap I get the message

Installer error: Failure trying to run: chroot /target mount -t proc
proc /proc

There are more details below but could somebody enlighten me as to
its meaning and what's going wrong? Ta, M

Details: Fedora fc7 box is Core2 Duo with LVM, make a new partition /
debian_chroot, install debootstrap using yum, run debootstrap to
install etch for arch amd64 using UK mirror. Installs/verifies many
packages then gives above error. /var/log/messages is empty (!).

To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Old 07-02-2008, 04:15 AM
Daniel Iliev

Joerg, as far as I can tell you need medical attention.

Please, from now on do not annoy me with unwanted e-mail containing
advertisements of cdrtools or information about the attacks against you.

I'm done with you and your product.


localhost ~ # emerge -C cdrtools ; emerge -1 cdrkit


selected: 2.01.01_alpha34
protected: none
omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Unmerging app-cdr/cdrtools-2.01.01_alpha34...
No package files given... Grabbing a set.

[ CUT ]

<<< obj /usr/include/align.h
<<< obj /usr/bin/readcd
<<< obj /usr/bin/mkisofs
<<< obj /usr/bin/isovfy
<<< obj /usr/bin/isoinfo
<<< obj /usr/bin/isodump
<<< obj /usr/bin/devdump
<<< obj /usr/bin/cdrecord
<<< obj /usr/bin/cdda2wav
<<< obj /etc/default/rscsi.dfl
<<< obj /etc/default/cdrecord.dfl


Calculating dependencies ...
.. done!

>>> Emerging (1 of 1) app-cdr/cdrkit-1.1.6 to /


>>> Merging app-cdr/cdrkit-1.1.6 to /
--- /etc/
>>> /etc/wodim.conf
>>> /etc/netscsid.conf
--- /usr/
--- /usr/sbin/
>>> /usr/sbin/netscsid
--- /usr/bin/
>>> /usr/bin/readmult
>>> /usr/bin/devdump
>>> /usr/bin/icedax
>>> /usr/bin/pitchplay
>>> /usr/bin/readom
>>> /usr/bin/wodim
>>> /usr/bin/cdrecord -> /usr/bin/wodim
>>> /usr/bin/isovfy
>>> /usr/bin/isoinfo
>>> /usr/bin/genisoimage
>>> /usr/bin/cdda2ogg
>>> /usr/bin/isodebug
>>> /usr/bin/cdda2mp3
>>> /usr/bin/readcd -> /usr/bin/readom
>>> /usr/bin/isodump
>>> /usr/bin/dirsplit


>>> No packages selected for removal by clean
>>> Auto-cleaning packages...

>>> No outdated packages were found on your system.
* GNU info directory index is up-to-date.



Best regards,
gentoo-user@lists.gentoo.org mailing list
Old 07-02-2008, 02:11 PM
Ralf Mardorf

This might be interesting for the 64 Studio testing.

-------- Original Message --------
Subject: [Jack-Devel] [OT] Announcement: InConcert (live tap tempo
Date: Tue, 01 Jul 2008 23:26:58 -0500
From: Gabriel M. Beddingfield <gabriel@teuton.org>
To: jack-devel@jackaudio.org


In February I asked some questions about abusing the transport for a live
tap-tempo application (similar to TapStart). The code is now presentable and
working (but alpha). The project page is here:


It depends on Qt4, Jack, and ALSA. Suggestions and patches are appreciated.

Thanks to Fons Andriaensen, Daniel Schregenberger, Frank Brickle, and Daniel
James for your help, advice, and interest... and to Rui Nuno Capela for the
icons that I lifted from qjackctl. :-)


Feb e-mail: http://boudicca.tux.org/hypermail/jackit-devel/2008-Feb/0005.html
TapStart link: http://www.arnoldarts.de/drupal/?q=TapStart

64studio-users mailing list
Old 07-02-2008, 03:13 PM
"Nicolas Mailhot"

[FWD because Paul Hardy forrgot to subscribe]

I just finished the glyphs and posted them at
http://unifoundry.com/unifont.html on 20 June 2008. I then took a
vacation I had planned for a long time. I was trying to get something
in releasable form before my vacation, but it didn't happen.

I intend to package all the sources used to build the GNU Unifont: my
software, plus software that Roman Czyborra wrote originally, plus
software that Luis Gonzalez Miranda wrote to convert the .hex font into
a TrueType font with my modifications, in one source tree with make
files and man pages. I've been wrapping this up behind the scenes and
expect to finish this weekend.

I would like to go through the Fedora release process, starting with
just the font and then adding the whole source tree to build the font.
Qianqian Fang will be able to guide me through this process (and I've
been in frequent contact with him while adding the missing CJK glyphs),
but review by anyone else of course would be welcome.

If anyone would like updates on this, you can email me at
unifoundry@unifoundry.com and I'll keep you posted on the latest
developments. Thanks for your interest!

Paul Hardy

Le Mer 2 juillet 2008 10:59, Debarshi Ray a écrit :
>>>> The maintaining expense for both packages is not that much though.
>>>> I would be glad to maintain GNU Unifont, or show Paul how to do
>>>> that
>>>> if he wants. The spec files for both packages can be almost
>>>> identical.
>>> Do you still want to do this?
>>> It would be nice to have Unifont in Fedora.
>> Or more generaly to have more fonts in Fedora. It's been ages since
>> anyone but the usual suspects packaged a new font in Fedora (and a
>> fixed team does not scale)
> Is someone already doing this? If not, then I am interested. If yes,
> then I can help with the review.

There are lots of unclaimed fonts on

If you have the time and interest please do not block on Unifont. Our
packaging wishlist has other elements.


Nicolas Mailhot

Nicolas Mailhot

fedora-devel-list mailing list

Thread Tools

All times are GMT. The time now is 01:21 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org