Re: Orphaning some packages

2011-03-14 Thread Ville Skyttä 
On 03/13/2011 09:39 PM, Christoph Wickert wrote:
> Am Montag, den 14.03.2011, 01:10 +0530 schrieb Ankur Sinha:
>> On Sun, 2011-03-13 at 20:15 +0100, Dominic Hopf wrote:
>>> Anyway, I still find it the best tool for editing MP3 tags around, so,
>>> is there any reason to not maintain it anymore from Fedora's point of
>>> view? 
>>
>> Nope. None that I can see. It really is an amazing tool and should be
>> available in the repos until something better comes up as a replacement
>> IMO.
> 
> easytag?

If the dependencies are not an issue, check out kid3 (KDE deps) or
kid3-qt (Qt deps).
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning some packages

2011-03-14 Thread Matej Cepl 
Dne 14.3.2011 00:31, Christoph Wickert napsal(a):
> $ rpm -qi easytag

Sorry, I have confused it with ExFalso which is IMHO the best tag
manager, except it is bound to quodlibet.

Matěj

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ld error

2011-03-14 Thread Nikola Pajkovsky 
 "AP" == Alain Portal  wrote:

AP> Le vendredi 11 mars 2011 20:07:29, Przemek Klosowski a écrit :
AP> > On 03/11/2011 10:58 AM, Alain Portal wrote:
AP> > > Le vendredi 11 mars 2011 14:58:03, Stephen Gallagher a écrit :
AP> > >> On 03/11/2011 08:12 AM, Alain Portal wrote:
AP> > >>> Hi,
AP> > >>> 
AP> > >>> I trying to update kicad but the built fails with a ld error:
AP> > >>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2903979
AP> > >>> and I don't succeed to fix it.
AP> > >>> 
AP> > >>> Can somebody help me?
AP> > >> 
AP> > >> Looks like you're not linking in BOARD::GetLayerColor(int) and
AP> > >> BOARD::GetLayerName(int) const correctly. You should figure out what
AP> > >> library or object file provides those and make sure they're listed in
AP> > >> the linking step.
AP> > > 
AP> > > These functions are provided by pcbnew/class_board.cpp and I don't know
AP> > > how to act on the linking step.
AP> > 
AP> > class_board.cpp.o is placed in libpcbcommon.o but the failing link step,
AP> > creating eeschema, only links to libcommon.o
AP> 
AP> As CMake do all the job, that don't help me to fix to build the package.

send me a source code directly (or url) and I'll send you a patch with
description.

-- 
Nikola
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 684410] perl-ExtUtils-XSpp-0.1601 is available

2011-03-14 Thread bugzilla 
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=684410

--- Comment #1 from Fedora Update System  2011-03-14 
05:20:08 EDT ---
perl-ExtUtils-XSpp-0.1601-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/perl-ExtUtils-XSpp-0.1601-1.fc15

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

G15Tools Packaging

2011-03-14 Thread Praveen Kumar 
On fedora package wish-list this package is listed. I tried to compile
its source after installing all its dependencies but its showing me
error during make

# make
make  all-recursive
make[1]: Entering directory `/home/daredevil/g15tools/trunk/G15Tools++'
Making all in src
make[2]: Entering directory `/home/daredevil/g15tools/trunk/G15Tools++/src'
/bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
-I.. -g -O2 -MT G15Canvas.lo -MD -MP -MF .deps/G15Canvas.Tpo -c -o
G15Canvas.lo G15Canvas.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT
G15Canvas.lo -MD -MP -MF .deps/G15Canvas.Tpo -c G15Canvas.cpp  -fPIC
-DPIC -o .libs/G15Canvas.o
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT
G15Canvas.lo -MD -MP -MF .deps/G15Canvas.Tpo -c G15Canvas.cpp -o
G15Canvas.o >/dev/null 2>&1
mv -f .deps/G15Canvas.Tpo .deps/G15Canvas.Plo
/bin/sh ../libtool --tag=CXX   --mode=compile g++ -DHAVE_CONFIG_H -I.
-I.. -g -O2 -MT G15Screen.lo -MD -MP -MF .deps/G15Screen.Tpo -c -o
G15Screen.lo G15Screen.cpp
libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -g -O2 -MT
G15Screen.lo -MD -MP -MF .deps/G15Screen.Tpo -c G15Screen.cpp  -fPIC
-DPIC -o .libs/G15Screen.o
G15Screen.cpp: In member function 'int
G15Tools::G15Screen::setKeyboardBacklight(unsigned char)':
G15Screen.cpp:74:28: error: 'G15DAEMON_KB_BACKLIGHT' was not declared
in this scope
make[2]: *** [G15Screen.lo] Error 1
make[2]: Leaving directory `/home/daredevil/g15tools/trunk/G15Tools++/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/daredevil/g15tools/trunk/G15Tools++'
make: *** [all] Error 2

Actually  there is no G15DAEMON_KB_BACKLIGHT declared but
G15DAEMON_BACKLIGHT is their and when I use G15DAEMON_BACKLIGHT
instead of G15DAEMON_KB_BACKLIGHT then it make successfully. I also
mailed to upstreamer but did not get any response yet. I never used
this tool if anybody used or using it please let me know about the
error.

Thanks and Regards
Praveen Kumar
Final year Undergraduate student
Information Technology Dept.
NIT Durgapur
http://kumar-pravin.blogspot.com
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating SSL keys on fedoraproject.org 2011-03-10

2011-03-14 Thread Petr Pisar 
On 2011-03-11, Chris Adams  wrote:
> Once upon a time, Petr Pisar  said:
>> This year? In Europe we are over. All quallified CA's are forbiden to
>> issue SHA-1 certificates since begin of 2010.
>
> Cite?
There is a study ETSI TS 102 176-1 V2.0.0 (called `ALGO Paper')
 by
ETSI that recommends algorithms and their safety in time. Then each
European country implements national standards. E.g. Czech Republic
requires at lest 2048b RSA with SHA-2 since 2010-01-01, the same applies
to Germany or Slovakia.

Unfortuntally none of documents I can find now are not in English.

AFAIK American NIST states federal beaureus should stop to use SHA-1 at
the end of 2010 (except HMAC, KDF or RNG usages).


> https://europa.eu/ uses SHA-1 on a cert issued in February 2010.

This is not a quallified (or more precisely system) certificate. This is
pure certificate you can buy from any one without any legal implications.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Updating SSL keys on fedoraproject.org 2011-03-10

2011-03-14 Thread Petr Pisar 
On 2011-03-11, Chris Adams  wrote:
> Once upon a time, Ralf Ertzinger  said:
>> this document is about a quite special case (regarding lawfully binding
>> digital signatures) and not about SSL in general.
>
> I took a short look at software support for other SSL hashes:
>
> - OpenSSL: openssl only offers md5, sha1, md2, mdc2, md4 for generating
>   a signing request or signing a cert
>
Not true:

$ openssl req -newkey rsa:2048 -sha256 -new -utf8 -out test.req
[...]
$ openssl req -noout -text  - NSS: certutil doesn't seem to offer the option to set the digest (I
>   didn't see one in -H output and there's no man/info page)
>
NSS is under-documented. E.g. I could not figure out how to select
a hardware cryptoengine.

> - GnuTLS: certtool supports up to SHA512 for signing, although it only
>   used SHA-1 for a signing request (it appeared to ignore the --hash
>   option when generating a request)
>
Yes, there is a bug with selecting hash algorithm.

-- Petr

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

fedpkg curl 404 failures

2011-03-14 Thread Ralf Corsepius 
Hi,

Any insights about what goes wrong here:

a) A local "fedpkg srpm" fails:

$ fedpkg srpm
Downloading HTTP-Server-Simple-PSGI-0.14.tar.gz
   % Total% Received % Xferd  Average Speed   TimeTime Time 
  Current
  Dload  Upload   Total   SpentLeft 
  Speed
   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0
curl: (22) The requested URL returned error: 404
Could not make an srpm: Command '['curl', '-H', 'Pragma:', '-o', 
'HTTP-Server-Simple-PSGI-0.14.tar.gz', '-R', '-S', '--fail', 
'--show-error', 
'http://pkgs.fedoraproject.org/repo/pkgs/perl-HTTP-Server-Simple-PSGI/HTTP-Server-Simple-PSGI-0.14.tar.gz/c26795112c9f616dbd37ece1c5895b55/HTTP-Server-Simple-PSGI-0.14.tar.gz']'
 
returned non-zero exit status 22
[fedora@beck master]$ ls
perl-HTTP-Server-Simple-PSGI.spec  sources

b) As well as do koji builds (from 
http://koji.fedoraproject.org/koji/getfile?taskID=2911464&name=root.log):

...
DEBUG util.py:247:  Downloading HTTP-Server-Simple-PSGI-0.14.tar.gz
DEBUG util.py:247:  Could not download sources: Command curl -H Pragma: 
-o ./HTTP-Server-Simple-PSGI-0.14.tar.gz -R -S --fail --show-error 
http://pkgs.fedoraproject.org/repo/pkgs/perl-HTTP-Server-Simple-PSGI/HTTP-Server-Simple-PSGI-0.14.tar.gz/c26795112c9f616dbd37ece1c5895b55/HTTP-Server-Simple-PSGI-0.14.tar.gz
 
returned code 22 with error:   % Total% Received % Xferd  Average 
Speed   TimeTime Time  Current
DEBUG util.py:247:   Dload  Upload 
Total   SpentLeft  Speed
DEBUG util.py:247:
   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0
   0 00 00 0  0  0 --:--:-- --:--:-- 
--:--:-- 0
DEBUG util.py:247:  curl: (22) The requested URL returned error: 404



I've tried "fedpkg new-sources", git pull/push, etc.
git status reports my git-clone to be in sync.

No idea what's going on or what I am supposed to do.

Ralf
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Kevin Fenzi 
Try again now. 

Looks like the iscsi mount on pkgs that is the lookaside storage
remounted itself read-only. ;( 

It did this once before and it was thought it was just a isolated
network hiccup, but this makes it sound like it's an ongoing real
issue.

It should be back for now, we will investigate further and try and
solve this once and for all. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File VOMS-Lite-0.11.tar.gz uploaded to lookaside cache by stevetraylen

2011-03-14 Thread stevetraylen 
A file has been added to the lookaside cache for perl-VOMS-Lite:

636307a733c8957edb5074b88d0eb3ef  VOMS-Lite-0.11.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Ralf Corsepius 
On 03/14/2011 06:04 PM, Kevin Fenzi wrote:
> Try again now.
>
> Looks like the iscsi mount on pkgs that is the lookaside storage
> remounted itself read-only. ;(
>
> It did this once before and it was thought it was just a isolated
> network hiccup, but this makes it sound like it's an ongoing real
> issue.
>
> It should be back for now, we will investigate further and try and
> solve this once and for all.

Out of luck - Same as before:

http://koji.fedoraproject.org/koji/taskinfo?taskID=2911552

Ralf

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Kevin Fenzi 
On Mon, 14 Mar 2011 18:22:00 +0100
Ralf Corsepius  wrote:

> On 03/14/2011 06:04 PM, Kevin Fenzi wrote:
> > Try again now.
> >
> > Looks like the iscsi mount on pkgs that is the lookaside storage
> > remounted itself read-only. ;(
> >
> > It did this once before and it was thought it was just a isolated
> > network hiccup, but this makes it sound like it's an ongoing real
> > issue.
> >
> > It should be back for now, we will investigate further and try and
> > solve this once and for all.
> 
> Out of luck - Same as before:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2911552

Sorry, should have been more clear: 

re-run new-sources again. Since the fs was read-only it was unable to
write your new sources out. If you re-run new-sources it should upload
and write it out correctly now. 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Jesse Keating 
On 3/14/11 10:22 AM, Ralf Corsepius wrote:
> Out of luck - Same as before:
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2911552

When the mount goes r/o, the upload attempt looks like it was 
successful, but isn't.

Looks like that's the case here, I don't see that tarball on the 
filesystem.  Can you re-upload the source and try again?

-- 
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ld error

2011-03-14 Thread Alain Portal 
Le lundi 14 mars 2011 10:22:51, Nikola Pajkovsky a écrit :
> 
> send me a source code directly (or url) and I'll send you a patch with
> description.

Here is the srpm:
http://dionysos.fedorapeople.org/SRPMS/kicad-2011.01.28-1.rev2765.fc12.src.rpm

Regards,
Alain


signature.asc
Description: This is a digitally signed message part.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

powertop2 vs powertop

2011-03-14 Thread jan.klepek 
Hi,

In not so recent past, powertop2 alpha has been released [1] and it is
currently in version 1.97. It is usuable and I was thinking about
packaging it for Fedora. However, there is already "old" powertop.
So I will have to package it as powertop2 because it is completely
different tool. 

Does it have sense to package it as powertop2? Or should rather powertop
package maintainer update powertop package with new sources (even when
they are considered as alpha)?
As both tools have same binary name, localization file and manpage,
should be source code updated and all occurence of word "powertop"
replaced with word "powertop2"? Or how this situation should be handled?

[1] http://blog.fenrus.org/?p=80

Regards,
Jan Klepek


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

rawhide emacs problem

2011-03-14 Thread Neal Becker 
http://koji.fedoraproject.org/koji/taskinfo?taskID=2911659

error is here:
 emacs -batch -l mercurial.el --no-site-file -f batch-byte-compile mercurial.el
emacs: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open 
shared object file: No such file or directory

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 630644] Review Request: perl-Bio-SamTools - Bio::SamTools Perl module

2011-03-14 Thread bugzilla 
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=630644

--- Comment #11 from Adam Huffman  2011-03-14 13:58:39 EDT 
---
Petr,

Many thanks for the comments with explanations.  I've updated to the latest
upstream source and applied most of the required changes.  I'll look tonight in
more detail to check which bioperl modules are required.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: powertop2 vs powertop

2011-03-14 Thread Dave Jones 
On Mon, Mar 14, 2011 at 06:53:31PM +0100, jan.klepek wrote:
 
 > In not so recent past, powertop2 alpha has been released [1] and it is
 > currently in version 1.97. It is usuable and I was thinking about
 > packaging it for Fedora. However, there is already "old" powertop.
 > So I will have to package it as powertop2 because it is completely
 > different tool. 
 > Does it have sense to package it as powertop2? Or should rather powertop
 > package maintainer update powertop package with new sources (even when
 > they are considered as alpha)?

Is powertop1 going to continue to be updated ?  I would assume not,
and having both in the archive is just going to cause confusion.

What's wrong with waiting for the non-alpha version, and then updating
the existing powertop package ?

Dave

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: powertop2 vs powertop

2011-03-14 Thread jan.klepek 
On Mon, 2011-03-14 at 13:13 -0500, Eric Sandeen wrote:
> On 3/14/11 1:03 PM, Dave Jones wrote:
> > On Mon, Mar 14, 2011 at 06:53:31PM +0100, jan.klepek wrote:
> >  
> >  > In not so recent past, powertop2 alpha has been released [1] and it is
> >  > currently in version 1.97. It is usuable and I was thinking about
> >  > packaging it for Fedora. However, there is already "old" powertop.
> >  > So I will have to package it as powertop2 because it is completely
> >  > different tool. 
> >  > Does it have sense to package it as powertop2? Or should rather powertop
> >  > package maintainer update powertop package with new sources (even when
> >  > they are considered as alpha)?
> > 
> > Is powertop1 going to continue to be updated ?  I would assume not,
> > and having both in the archive is just going to cause confusion.
> > 
> > What's wrong with waiting for the non-alpha version, and then updating
> > the existing powertop package ?
> > 
> > Dave
> > 
> 
> Er, isn't it already built for fedora?  I think the migration
> is well in hand.  :)
> 
> http://kojipkgs.fedoraproject.org/packages/powertop/1.97/
> 
> -Eric

Good to know, I somehow missed this in powertop fedora git :(
Thanks for info Eric.

Regards,
Jan

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Kevin Fenzi 
On Mon, 14 Mar 2011 18:11:56 +
Paul Howarth  wrote:

> On Mon, 14 Mar 2011 11:04:17 -0600
> Kevin Fenzi  wrote:
> 
> > Try again now. 
> > 
> > Looks like the iscsi mount on pkgs that is the lookaside storage
> > remounted itself read-only. ;( 
> > 
> > It did this once before and it was thought it was just a isolated
> > network hiccup, but this makes it sound like it's an ongoing real
> > issue.
> > 
> > It should be back for now, we will investigate further and try and
> > solve this once and for all. 
> 
> https://fedorahosted.org/rel-eng/ticket/4453 should probably be
> re-opened then.

Please see: 

https://fedorahosted.org/fedora-infrastructure/ticket/2647

We will continue to work on the issue there. 

thanks, 

kevin


signature.asc
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: powertop2 vs powertop

2011-03-14 Thread Eric Sandeen 
On 3/14/11 1:03 PM, Dave Jones wrote:
> On Mon, Mar 14, 2011 at 06:53:31PM +0100, jan.klepek wrote:
>  
>  > In not so recent past, powertop2 alpha has been released [1] and it is
>  > currently in version 1.97. It is usuable and I was thinking about
>  > packaging it for Fedora. However, there is already "old" powertop.
>  > So I will have to package it as powertop2 because it is completely
>  > different tool. 
>  > Does it have sense to package it as powertop2? Or should rather powertop
>  > package maintainer update powertop package with new sources (even when
>  > they are considered as alpha)?
> 
> Is powertop1 going to continue to be updated ?  I would assume not,
> and having both in the archive is just going to cause confusion.
> 
> What's wrong with waiting for the non-alpha version, and then updating
> the existing powertop package ?
> 
>   Dave
> 

Er, isn't it already built for fedora?  I think the migration
is well in hand.  :)

http://kojipkgs.fedoraproject.org/packages/powertop/1.97/

-Eric
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Paul Howarth 
On Mon, 14 Mar 2011 11:04:17 -0600
Kevin Fenzi  wrote:

> Try again now. 
> 
> Looks like the iscsi mount on pkgs that is the lookaside storage
> remounted itself read-only. ;( 
> 
> It did this once before and it was thought it was just a isolated
> network hiccup, but this makes it sound like it's an ongoing real
> issue.
> 
> It should be back for now, we will investigate further and try and
> solve this once and for all. 

https://fedorahosted.org/rel-eng/ticket/4453 should probably be
re-opened then.

Paul.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: rawhide emacs problem

2011-03-14 Thread Jerry James 
On Mon, Mar 14, 2011 at 11:56 AM, Neal Becker  wrote:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2911659
>
> error is here:
>  emacs -batch -l mercurial.el --no-site-file -f batch-byte-compile 
> mercurial.el
> emacs: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open
> shared object file: No such file or directory

Does the build succeed if you BR emacs-nox instead of emacs?
-- 
Jerry James
http://www.jamezone.org/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help needed building a lazarus application

2011-03-14 Thread Sergio Pascual 
It seems that lazarus needs to be rebuilt because its older than the
pascal compiler in rawhide and F-15:

fpc-2.4.2-2.fc15
lazarus.x86_64 0:0.9.28.2-1.fc14

https://bugzilla.redhat.com/show_bug.cgi?id=684986

2011/3/13 Sergio Pascual :
> Hello list.
>
> I'm trying to build an application that uses lazarus. It builds ok in
> F-14 but fails in F-15 and rawhide.
>
> This is a scratch build
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2909255
>
> The explicit error is this:
>
> /usr/bin/ppcx64 -MObjFPC -Sgi
> -Fu/usr/lib64/lazarus/packager/units/x86_64-linux/ -Fu./ -Fi./ -FE.
> -FUlib/x86_64-linux-gtk2 -Cg -dx86_64 synapse.pas
> Free Pascal Compiler version 2.4.2 [2011/02/09] for x86_64
> Copyright (c) 1993-2010 by Florian Klaempfl
> Target OS: Linux for x86-64
> Compiling synapse.pas
> Compiling blcksock.pas
> Compiling synafpc.pas
> Compiling synsock.pas
> Compiling synautil.pas
> Compiling synacode.pas
> Compiling synaip.pas
> Compiling ftpsend.pas
> Compiling httpsend.pas
> PPU Loading 
> /usr/lib64/lazarus/packager/units/x86_64-linux/lazaruspackageintf.ppu
> PPU Invalid Version 100
> Fatal: Can't find unit LazarusPackageIntf used by synapse
> Fatal: Compilation aborted
>
> Any hint?
>
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning some packages

2011-03-14 Thread Ben Boeckel 
Matej Cepl  wrote:
> Dne 14.3.2011 00:31, Christoph Wickert napsal(a):
>> $ rpm -qi easytag
> 
> Sorry, I have confused it with ExFalso which is IMHO the best tag
> manager, except it is bound to quodlibet.

I've got a bug filed[1] for that.

--Ben

[1]https://bugzilla.redhat.com/show_bug.cgi?id=677162

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Bug 630644] Review Request: perl-Bio-SamTools - Bio::SamTools Perl module

2011-03-14 Thread bugzilla 
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=630644

--- Comment #14 from Adam Huffman  2011-03-14 18:55:40 EDT 
---
Okay - will mention that the next time someone complains in a review - thanks.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

Re: rawhide emacs problem

2011-03-14 Thread Neal Becker 
Jerry James wrote:

> On Mon, Mar 14, 2011 at 11:56 AM, Neal Becker  wrote:
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2911659
>>
>> error is here:
>> emacs -batch -l mercurial.el --no-site-file -f batch-byte-compile
>> mercurial.el emacs: error while loading shared libraries:
>> libgtk-x11-2.0.so.0: cannot open shared object file: No such file or
>> directory
> 
> Does the build succeed if you BR emacs-nox instead of emacs?

Yes, that will fix it, although I don't think it should have failed.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-15 Branched report: 20110314 changes

2011-03-14 Thread Branched Report 
Compose started at Mon Mar 14 13:15:37 UTC 2011

Broken deps for x86_64
--
Io-language-extras-20080330-4.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
byzanz-0.2.2-1.fc14.x86_64 requires libpanel-applet-2.so.0()(64bit)
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Ograph2way) = 
0:7442f647b0a74ed48a5c9361fc42ccc4
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Flag) = 
0:522d7f86f1236405e53271ff74923515
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Osetb) = 
0:8f21a0a4f771662673604ed92a237d79
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassocb) = 
0:d873c4a1eeb6fa5c5333f8658c49d1db
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Setb) = 
0:93bdb588146a13126bfad4eab6c58206
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoc_buffer) = 
0:cf6fbee4fcc6644a0a90f07da8eb6c7b
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Mapb) = 
0:617c09a110cef9f040335b35078c7234
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Sexplib) = 
0:a990ea80438337d5407bbc0343c7236a
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Dumper) = 
0:76126ba149caeb2d34f12e11187a9d4e
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oassoch) = 
0:87f7dc2635e5a7ed1ab03b7cd5380ace
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(SetPt) = 
0:b69c030e8ca717d556d3d9bd2a5d22fd
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(ANSITerminal) = 
0:3d0d1700618d8b3a4e4b2308f28cefb6
coccinelle-0.2.5-0.rc4.2.fc15.1.x86_64 requires ocaml(Oseti) = 
0:a937e7661f510c17bfd21d4372507795
conmux-0.0-12.493svn.fc15.noarch requires perl(Payload)
conmux-0.0-12.493svn.fc15.noarch requires perl(Client)
cpm-0.23-0.3.beta.fc12.x86_64 requires libdotconf-1.0.so.0()(64bit)
db4o-7.4-2.fc13.x86_64 requires mono(Mono.GetOptions) = 0:2.0.0.0
dbmail-3.0.0-0.3.rc1.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
dbmail-auth-ldap-3.0.0-0.3.rc1.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
dh-make-0.55-3.fc15.noarch requires debhelper
drupal6-views_bulk_operations-1.10-6.fc15.noarch requires drupal6-views
ember-0.6.0-1.fc15.x86_64 requires libboost_thread-mt.so.1.44.0()(64bit)
eog-plugins-2.30.0-2.fc14.x86_64 requires libgdata.so.7()(64bit)
evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgtk-3.0.so.0()(64bit)
evolution-couchdb-0.5.1-5.fc15.x86_64 requires libgdk-3.0.so.0()(64bit)
1:fife-0.3.2-1.fc15.i686 requires libboost_regex.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_system.so.1.44.0
1:fife-0.3.2-1.fc15.i686 requires libboost_filesystem.so.1.44.0
1:fife-0.3.2-1.fc15.x86_64 requires libboost_regex.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires libboost_system.so.1.44.0()(64bit)
1:fife-0.3.2-1.fc15.x86_64 requires 
libboost_filesystem.so.1.44.0()(64bit)
file-browser-applet-0.6.6-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::ScrolledWindow)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Dialog)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Toolbar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::TreeView)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MenuBar)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::VBox)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::Window)
gcstar-1.6.1-3.fc15.noarch requires perl(Gtk2::MessageDialog)
gearmand-0.14-2.fc15.x86_64 requires libevent-1.4.so.2()(64bit)
glom-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit)
glom-libs-1.16.1-2.fc15.i686 requires libgdamm-4.0.so.12
glom-libs-1.16.1-2.fc15.x86_64 requires libgdamm-4.0.so.12()(64bit)
glunarclock-0.34.1-1.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-bubblemon-2.0.15-1.fc13.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-cpufire-1.6-3.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-globalmenu-0.7.9-1.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-grandr-0.4.1-2.fc12.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-music-2.5.1-5.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sensors-2.2.7-4.fc15.i686 requires libpanel-applet-2.so.0
gnome-applet-sensors-2.2.7-4.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
gnome-applet-sshmenu-3.18-3.fc15.noarch requires ruby(panelapplet2)
gnome-applet-window-picker-0.5.8-2.fc14.x86_64 requires 
libpanel-applet-2.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-3.so.0()(64bit)
1:gnome-applets-2.32.0-3.fc15.x86_64 requires 
libpanel-applet-2.so.0()(64bit)

lordsawar license corrected

2011-03-14 Thread Bruno Wolff III 
lordsawar should be GPL2+ and GFDL1.1+ as some of the help documentation is
licensed under the GFDL. As I do updates, I'll be using the updated license
tag in new builds.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: fedpkg curl 404 failures

2011-03-14 Thread Ralf Corsepius 
On 03/14/2011 06:26 PM, Kevin Fenzi wrote:
> On Mon, 14 Mar 2011 18:22:00 +0100
> Ralf Corsepius  wrote:
>
>> On 03/14/2011 06:04 PM, Kevin Fenzi wrote:
>>> Try again now.
>>>
>>> Looks like the iscsi mount on pkgs that is the lookaside storage
>>> remounted itself read-only. ;(
>>>
>>> It did this once before and it was thought it was just a isolated
>>> network hiccup, but this makes it sound like it's an ongoing real
>>> issue.
>>>
>>> It should be back for now, we will investigate further and try and
>>> solve this once and for all.
>>
>> Out of luck - Same as before:
>>
>> http://koji.fedoraproject.org/koji/taskinfo?taskID=2911552
>
> Sorry, should have been more clear:
>
> re-run new-sources again.
Done - worked.

At least to me it wasn't obvious if the file was actually missing, 
inaccessible or if something else might be going wrong.

> Since the fs was read-only it was unable to
> write your new sources out. If you re-run new-sources it should upload
> and write it out correctly now.

Thanks.

Ralf
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel