F-15 Branched report: 20110311 changes

[Branched Report]

Compose started at Fri Mar 11 13:15:33 UTC 2011

Broken deps for x86_64
--
Io-language-extras-20080330-4.fc15.x86_64 requires 
libevent-1.4.so.2()(64bit)
bugzilla-3.6.4-4.fc15.noarch requires perl(DBD::Oracle)
bugzilla-3.6.4-4.fc15.noarch requires perl(DBI::db)
bugzilla-3.6.4-4.fc15.noarch requires perl(DBI::st)
bugzilla-3.6.4-4.fc15.noarch requires perl(sanitycheck.cgi)
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)
cvs2cl-2.72-4.noarch requires 
perl(CVS::Utils::ChangeLog::EntrySet::Output)
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)
gno

[Bug 672068] dspam web interface completely broken

[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=672068

Fedora Update System  changed:

   What|Removed |Added

 Status|ON_QA   |CLOSED
   Fixed In Version|dspam-3.9.0-13.el5  |dspam-3.9.0-17.fc14
 Resolution||ERRATA
Last Closed|2011-02-04 14:51:46 |2011-03-11 15:57:32

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

[Bug 672068] dspam web interface completely broken

[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=672068

--- Comment #26 from Fedora Update System  
2011-03-11 15:57:27 EST ---
dspam-3.9.0-17.fc14 has been pushed to the Fedora 14 stable repository.  If
problems still persist, please make note of it in this bug report.

-- 
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: Updating SSL keys on fedoraproject.org 2011-03-10

[Elio Maldonado]

On 03/11/2011 12:18 PM, 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

- 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)

By the way, man pages for the nss tools are in development
https://bugzilla.redhat.com/show_bug.cgi?id=606020#c3
as you can see, they still need a lot of work

- 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)

Once I had a SHA512 signed cert, OpenSSL recognized it and recognized
the SHA512 signature.  It looks like NSS can't just look at cert PEM
file; you have to create a cert database and import the cert; I did
that, and it didn't give an error, but I didn't see a way to be
"verbose" about it to see that it actually recognized the signature
algorithm.

This was all on F14.  I tried a few RHEL servers as well; on RHEL 4,
OpenSSL did not recognize the signature algorithm (RHEL 5/6 did).

I didn't try to set up Apache with a SHA512 cert to see what browsers
recognized it.





smime.p7s
Description: S/MIME Cryptographic Signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Outage: Serverbeach servers downtime 2011-03-16 03:00 UTC -> 2011-03-16 09:00 UTC

[Stephen Smoogen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1



There will be an outage starting at 2011-03-16 03:00 UTC, which will last
approximately 6 hours. [Outages should be only 10-30 minutes long but
the window for the outage is 6 hours thus the large window.]

To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:

date -d '2011-03-16 03:00 UTC'

Reason for outage:

Affected Services:

DNS - ns1.fedoraproject.org,
Fedora Hosted - https://fedorahosted.org/
Fedora Talk - http://talk.fedoraproject.org/
Email for fedoraproject.org


Contact Information:

Please join #fedora-admin in irc.freenode.net or respond to this email to
track the status of this outage.

- --
Smooge [Temporary Interim Chief Cat Wranglger]
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org/

iJwEAQECAAYFAk16iskACgkQAsLqwWFAN9vihAQAhJH1+JaVMknFpopSzCFdx33w
9r/tjQDaqBb9k6Vud9fMjZAPjl14+2S6VuZvvwNnz3dVLr6KRCNbDnu04WA8K9Fp
59L+SZwhPSh6wS/S1WVaId946FlpinzsDeElN6JDoTxyo77stmRBqYXwx8xGcldW
F1IQOzU3kz2TrXcI3j0=
=Ddlu
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[389-devel] Please review: [Bug 668909] Can't modify replication agreement in some cases

[Noriko Hosoi]

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

https://bugzilla.redhat.com/attachment.cgi?id=483808&action=diff
https://bugzilla.redhat.com/attachment.cgi?id=483808&action=edit

Description: Code to modify nsds5ReplicaPort in replication agreement
was not implemented.  This patch adds it.

When an agreement change is detected in conn_connect, it resets
the values needed to make a connection including the port number.


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

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

[Chris Adams]

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

- 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)

- 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)

Once I had a SHA512 signed cert, OpenSSL recognized it and recognized
the SHA512 signature.  It looks like NSS can't just look at cert PEM
file; you have to create a cert database and import the cert; I did
that, and it didn't give an error, but I didn't see a way to be
"verbose" about it to see that it actually recognized the signature
algorithm.

This was all on F14.  I tried a few RHEL servers as well; on RHEL 4,
OpenSSL did not recognize the signature algorithm (RHEL 5/6 did).

I didn't try to set up Apache with a SHA512 cert to see what browsers
recognized it.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Till Maas]

On Fri, Mar 11, 2011 at 08:37:39PM +0100, Ralf Ertzinger wrote:
> Hi.
> 
> On Fri, 11 Mar 2011 20:22:55 +0100, Till Maas wrote
> 
> > I assume he meant since Januar 2011. This is at least the official
> > statement for Germany:
> > 
> > http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html
> > http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf
> 
> For those not fluent in German:
> 
> this document is about a quite special case (regarding lawfully binding
> digital signatures) and not about SSL in general.

Thanks, I meant to mention this, too. Btw. Petr was referring to these
kind of signatures as well as far as I understand him:

| All quallified CA's [...]
  ^^

Regards
Till


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

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

[Ralf Ertzinger]

Hi.

On Fri, 11 Mar 2011 20:22:55 +0100, Till Maas wrote

> I assume he meant since Januar 2011. This is at least the official
> statement for Germany:
> 
> http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html
> http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf

For those not fluent in German:

this document is about a quite special case (regarding lawfully binding
digital signatures) and not about SSL in general.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Till Maas]

On Fri, Mar 11, 2011 at 08:44:55AM -0600, 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?  https://europa.eu/ uses SHA-1 on a cert issued in February 2010.
> Of course, they also haven't disabled the weak SSL ciphers, so it's hard
> to claim high security.

I assume he meant since Januar 2011. This is at least the official
statement for Germany:

http://www.bundesnetzagentur.de/DE/Sachgebiete/QES/Veroeffentlichungen/Algorithmen/algorithmen_node.html
http://www.bundesnetzagentur.de/cae/servlet/contentblob/192414/publicationFile/10008/2011AlgoKatpdf.pdf

The relevant pages in the PDF document are pages 3 and 4, especially the
table on page 4.

Regards
Till


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

2011-03-11 - F-15-Beta blocker bug #1 - recap

[James Laska]

#fedora-bugzappers: F-15-Beta blocker review


Minutes:
http://meetbot.fedoraproject.org/fedora-bugzappers/2011-03-11/f-15-beta-blocker-review.2011-03-11-17.00.html
Minutes (text):
http://meetbot.fedoraproject.org/fedora-bugzappers/2011-03-11/f-15-beta-blocker-review.2011-03-11-17.00.txt
Log:
http://meetbot.fedoraproject.org/fedora-bugzappers/2011-03-11/f-15-beta-blocker-review.2011-03-11-17.00.log.html


Meeting summary
---
* Roll call  (jlaska, 17:00:16)

* Useful information  (jlaska, 17:03:54)
  * Our purpose is to review proposed beta blocker and nice-to-have bugs
and decide whether to accept them, and to monitor the progress of
fixing existing accepted blocker and nice-to-have bugs.  (jlaska,
17:04:03)
  * LINK: https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting
(jlaska, 17:04:16)
  * LINK: http://bit.ly/f15-beta-blocker-proposed   (jlaska, 17:04:16)
  * LINK: http://bit.ly/f15-beta-blocker-accepted   (jlaska, 17:04:16)
  * LINK: http://bit.ly/f15-beta-nth-proposed   (jlaska, 17:04:17)

* Proposal for MODIFIED anaconda bugs  (jlaska, 17:05:15)
  * Clumens and I reviewed the MODIFIED anaconda bugs that are already
fixed and available for testing in anaconda-15.22-1  (jlaska,
17:05:53)
  * LINK: http://jlaska.fedorapeople.org/boot.iso   (jlaska, 17:07:22)
  * AGREED: accept all MODIFIED anaconda bugs fixed_in <=
anaconda-15.22-1  (jlaska, 17:08:40)
  * ACTION: jlaska will add whiteboard:AcceptedBlocker to all MODIFIED
fixed anaconda bugs  (jlaska, 17:10:00)

* https://bugzilla.redhat.com/show_bug.cgi?id=677080  (jlaska, 17:10:04)
  * 'F14' artwork is shown during F-15 installation  (jlaska, 17:10:16)
  * AGREED: 677080 - Valid Alpha release blocker, accepted as Beta
blocker - whiteboard:AcceptedBlocker  (jlaska, 17:13:44)

* https://bugzilla.redhat.com/show_bug.cgi?id=681062  (jlaska, 17:14:48)
  * F15 Alpha RC2: broken quicklauncher present in default panel
configuration  (jlaska, 17:14:57)
  * AGREED: 681062 - AcceptedBlocker - impacts beta desktop criteria
(jlaska, 17:19:19)

* https://bugzilla.redhat.com/show_bug.cgi?id=629311  (jlaska, 17:20:05)
  * install allows use of preexisting root filesystem without reformat
(jlaska, 17:20:13)
  * AGREED: RejectedBlocker, AcceptedNTH - no specific beta criteria
covered, possibly impacts Final partitioning criteria.  (jlaska,
17:24:38)

* https://bugzilla.redhat.com/show_bug.cgi?id=676114  (jlaska, 17:25:24)
  * iscsi --target kickstart option not actually used  (jlaska,
17:25:33)
  * AGREED: 676114 - iSCSI impacts Final release criteria -
AcceptedBlocker for Final release.  (jlaska, 17:28:16)

* https://bugzilla.redhat.com/show_bug.cgi?id=678414  (jlaska, 17:30:55)
  * NFS ISO install fails during repo setup - umount.nfs4: /mnt/source:
device is busy  (jlaska, 17:31:02)
  * AGREED: 678414 - AcceptedBlocker for Beta, impacts NFS installation
source beta criteria  (jlaska, 17:34:17)

* https://bugzilla.redhat.com/show_bug.cgi?id=682141  (jlaska, 17:34:47)
  * gnome-shell failed to start when changing user language to
Chinese(China)  (jlaska, 17:35:01)
  * AGREED: 682141 - need to find out from rhe whether this results in
unusable desktop or fallback mode; if the former this will be
AcceptedBlocker and can be updated outside of meeting, if the
latter, will revisit next week  (adamw, 17:45:08)

* https://bugzilla.redhat.com/show_bug.cgi?id=679814  (jlaska, 17:45:56)
  * [abrt] gnome-user-share-2.30.2-4.fc15: do_pre_parse_initialization:
Process /usr/libexec/gnome-user-share was killed by signal 6
(SIGABRT)  (jlaska, 17:46:06)
  * AGREED: 679814 - AcceptedBlocker for Final release, AcceptedNTH for
Beta. Covered by no AVC or ABRT notification on login final criteria
(jlaska, 17:51:30)

* https://bugzilla.redhat.com/show_bug.cgi?id=677953  (jlaska, 17:52:09)
  * Unable to kickstart with ks.cfg file stored on hard drive  (jlaska,
17:52:17)
  * AGREED: 677953 - Need more information from hongqing on whether the
issue remains with anaconda-15.22-1, and the type of storage used.
Will revisit this bug next week.  (jlaska, 18:00:28)

* https://bugzilla.redhat.com/show_bug.cgi?id=678402  (jlaska, 18:00:40)
  * F15 livemedia are checking for updates  (jlaska, 18:00:51)
  * AGREED: 678402 - AcceptedBlocker for Beta, seems to be fixed in
spin-kickstarts, move to MODIFIED and verify fix  (jlaska, 18:05:51)

* https://bugzilla.redhat.com/show_bug.cgi?id=683179  (jlaska, 18:06:59)
  * desktop- backgrounds package no longer sets the default Fedora
background, due to changes in Gnome  (jlaska, 18:07:15)
  * AGREED: 638179 provisionally accepted as a blocker per Alpha artwork
criterion; if this fix turns out not to be  needed for our agreed
artwork approach for Fedora 15, this stops being a blocker  (jlaska,
18:14:31)

* https://bugzilla.re

Re: ld error

[Przemek Klosowski]

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

class_board.cpp.o is placed in libpcbcommon.o but the failing link step, 
creating eeschema, only links to libcommon.o
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Przemek Klosowski]

On 03/11/2011 09:44 AM, Chris Adams wrote:

> Cite?  https://europa.eu/ uses SHA-1 on a cert issued in February 2010.
> Of course, they also haven't disabled the weak SSL ciphers, so it's hard
> to claim high security.

On my systems all I get is a blank page saying:

   Access Denied (policy_denied)
   Your system policy has denied access to the requested URL.
   For assistance, contact your network support team.

I am guessing that it's their passive-aggressive way of saying "we use 
obsolete protocol but it's your problem"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

RE: Request for sponsered development...

[Christian Weiß]

Adam,

thanks for the very comprehensive explanation.

> -Original Message-
> From: Adam Jackson [mailto:a...@redhat.com] 
> Sent: Freitag, 11. März 2011 17:28
> To: Development discussions related to Fedora
> Cc: Christian Weiß
> Subject: Re: Request for sponsered development...
> 
>[skipped]
> For your purposes, AIGLX is merely a promise that GLX will be fast, 
> regardless of whether the X client and X server are on the same machine. 
>   The key is to remember that GLX is a rendering protocol, not a 
> remoting protocol.  Your viewer, wherever it is, will probably use GLX 
> to do the final rendering, but the the thing that moves your compressed 
> textures over the wire (along with the rest of the session) need not and 
> probably should not be X11.
>
> - ajax

So if fact, I should introduce my own protocol for getting the compressed 
images over the wire and have some X11 module within the clients X-server that 
takes the images and writes them into the frame buffer of the relevant window. 

Good enough. However, there is already XPutImage which enables me to transfer 
images and so I thought it isn't too far fetched adding a feature, which takes 
that image and, if a proper extension module is loaded within the clients 
X-server, decompress it and writes it to the buffer. Even with my own protocol, 
an extension module is required since no other application or service should 
run at the client. Depending on the capabilities of the clients hardware DRI 
may be used to efficiently address features of the graphics hardware. And yes, 
the key was the understanding, that GLX is not a remoting vehicle. In summary, 
GLX does not introduce extensions to the X protocol at all, right?

Anyway, the application-side is all clear now - I would probably need my "own" 
GLX driver as the connector to the render pipeline. Within that driver (upon 
glxSwapBuffers) the compressed image needs to be copied to the client. This is 
transparent to the application.

Thanks for the insight,

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

Re: Review swaps again

[Michel Alexandre Salim]

On 03/11/2011 05:07 PM, Peter Lemenkov wrote:
> Hello!
> 
> I would like to swap reviews. My stalled review requests are:
> 
> * https://bugzilla.redhat.com/652543 - erlang-riak_client
> * https://bugzilla.redhat.com/680488 - erlang-basho_stats
> 
> This review is different - it depends on previous one (erlang-basho_stats):
> 
> * https://bugzilla.redhat.com/652598 - erlang-riak_core
> 
I'm taking erlang-riak_client

Best regards,

-- 
Michel Alexandre Salim

()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

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

Re: Request for sponsered development...

[Adam Jackson]

On 3/11/11 8:01 AM, Christian Weiß wrote:

> Since AIGLX is a Fedora project, I hope that anyone here is able to
> provide me with further technical information about the protocol and
> the architecture - haven't found anything so far. As mentioned,
> whatever comes out of this I'll gladly contribute to the project.

AIGLX is mostly just a standard feature at this point.  And sort of an 
uninteresting one.

Let's break the acronym down.  GLX is GLX, the binding between OpenGL 
rendering and the X window system; it's how you get GL to draw to 
windows or pixmaps.  I is "indirect", because GLX has two modes.  In 
direct rendering, the X client sends most rendering commands to the 
hardware directly, and only interacts with the X server for coordination 
purposes (where in memory does a given pixmap live, when to swap, etc.) 
  But in indirect GLX, it behaves more like everything else in X, where 
both rendering and management commands are passed from client to server, 
and the server executes them.  Direct is an optimization for local 
clients, though they can use indirect too if they choose; remote clients 
can only use indirect.

"A" means accelerated, and the reason for that is somewhat historical. 
Back in the day (1999 through 2006 or so), the X server's rendering code 
for indirect GLX was a clever build of the software rendering code in 
Mesa.  This worked well enough for what it was, but was always sort of a 
hack.  The "A" bit came about when we taught the X server how to load 
DRI drivers the way libGL does on the client side.  The advantage to 
doing that is that indirect contexts become faster.

But at the time, the _real_ advantage to that was that it made this 
other extension actually feasible.  GLX_EXT_texture_from_pixmap is a GLX 
extension that does what it says on the box; it allows you to turn 
existing pixmap contents into a texture.  Back then, we didn't have any 
real memory management in the DRI drivers, so there was no easy way for 
the X server and GL clients to share memory (ie, pixmaps).  So in direct 
GLX there was basically no way to implement this.  In indirect GLX, 
however, you have the GL renderer and the X server in the same address 
space; turning pixmaps into textures is a small matter of passing around 
a pointer (and compensating for X and GL having a different Y axis 
convention).  So that was the whole motivation for AIGLX: you needed 
texture from pixmap to make compositors work, and the easiest way to 
make that go fast was to load the DRI driver in the X server.

(The competing solution for this was Xglx, which achieved the same goal 
of "accelerated 3d renderer in the same address space as your pixmaps" 
by being a proxy X server, itself a direct-rendering client of the 
backing X server.  Both approaches are valid enough, and the final 
decision to go with AIGLX was IMO driven mostly by parsimony: fewer 
moving parts, better symmetry between client and server.)

But now?  Sort of pointless.  GEM and TTM and whatnot serve the purpose 
of coordinating video memory between multiple apps, one of which just 
happens to be the X server, so sharing buffers between GL client and X 
server is trivial: you ask the kernel.  That means you can implement 
EXT_texture_from_pixmap in direct contexts efficiently, which means 
indirect GL loses its feature advantage.

For your purposes, AIGLX is merely a promise that GLX will be fast, 
regardless of whether the X client and X server are on the same machine. 
  The key is to remember that GLX is a rendering protocol, not a 
remoting protocol.  Your viewer, wherever it is, will probably use GLX 
to do the final rendering, but the the thing that moves your compressed 
textures over the wire (along with the rest of the session) need not and 
probably should not be X11.

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

Review swaps again

[Peter Lemenkov]

Hello!

I would like to swap reviews. My stalled review requests are:

* https://bugzilla.redhat.com/652543 - erlang-riak_client
* https://bugzilla.redhat.com/680488 - erlang-basho_stats

This review is different - it depends on previous one (erlang-basho_stats):

* https://bugzilla.redhat.com/652598 - erlang-riak_core

-- 
With best regards, Peter Lemenkov.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Retired BoxGrinder plugin packages

[Marek Goldmann]

Hi Bill,

It's for all branches I currently maintain. It's a major upgrade, but 
maintaining backwards-compatibility.

I created a block request ticket here:

https://fedorahosted.org/rel-eng/ticket/4523

--Marek

On 2011-03-11, at 17:04, Bill Nottingham wrote:

> Marek Goldmann (mgold...@redhat.com) said: 
>> I just retired following packages:
>> 
>> * rubygem-boxgrinder-build-ebs-delivery-plugin
>> * rubygem-boxgrinder-build-ec2-platform-plugin
>> * rubygem-boxgrinder-build-fedora-os-plugin
>> * rubygem-boxgrinder-build-local-delivery-plugin
>> * rubygem-boxgrinder-build-rpm-based-os-plugin
>> * rubygem-boxgrinder-build-s3-delivery-plugin
>> * rubygem-boxgrinder-build-sftp-delivery-plugin
>> * rubygem-boxgrinder-build-vmware-platform-plugin
>> 
>> Content of these packages was merged into rubygem-boxgrinder-build to 
>> reflect upstream changes.
> 
> Is this for rawhide, or for F-15 too? Do you need them blocked in koji?
> 
> Bill
> -- 
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel

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

Re: Retired BoxGrinder plugin packages

[Bill Nottingham]

Marek Goldmann (mgold...@redhat.com) said: 
> I just retired following packages:
> 
> * rubygem-boxgrinder-build-ebs-delivery-plugin
> * rubygem-boxgrinder-build-ec2-platform-plugin
> * rubygem-boxgrinder-build-fedora-os-plugin
> * rubygem-boxgrinder-build-local-delivery-plugin
> * rubygem-boxgrinder-build-rpm-based-os-plugin
> * rubygem-boxgrinder-build-s3-delivery-plugin
> * rubygem-boxgrinder-build-sftp-delivery-plugin
> * rubygem-boxgrinder-build-vmware-platform-plugin
> 
> Content of these packages was merged into rubygem-boxgrinder-build to reflect 
> upstream changes.

Is this for rawhide, or for F-15 too? Do you need them blocked in koji?

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

Re: ld error

[Alain Portal]

Le vendredi 11 mars 2011 14:58:03, Stephen Gallagher a écrit :
> On 03/11/2011 08:12 AM, Alain Portal wrote:
> > Hi,
> > 
> > I trying to update kicad but the built fails with a ld error:
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=2903979
> > and I don't succeed to fix it.
> > 
> > Can somebody help me?
> 
> Looks like you're not linking in BOARD::GetLayerColor(int) and
> BOARD::GetLayerName(int) const correctly. You should figure out what
> library or object file provides those and make sure they're listed in
> the linking step.

These functions are provided by pcbnew/class_board.cpp and I don't know how to 
act on the linking step.


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

Retired BoxGrinder plugin packages

[Marek Goldmann]

Hi,

I just retired following packages:

* rubygem-boxgrinder-build-ebs-delivery-plugin
* rubygem-boxgrinder-build-ec2-platform-plugin
* rubygem-boxgrinder-build-fedora-os-plugin
* rubygem-boxgrinder-build-local-delivery-plugin
* rubygem-boxgrinder-build-rpm-based-os-plugin
* rubygem-boxgrinder-build-s3-delivery-plugin
* rubygem-boxgrinder-build-sftp-delivery-plugin
* rubygem-boxgrinder-build-vmware-platform-plugin

Content of these packages was merged into rubygem-boxgrinder-build to reflect 
upstream changes.

--Marek

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

Re: Using LD_PRELOAD wrappers to identify problem use of shared library functions

[William Cohen]

On 03/11/2011 12:29 AM, John Reiser wrote:
> On 03/10/2011 08:25 AM, William Cohen wrote:
>> git repo at:
>>
>> http://fedorapeople.org/gitweb?p=wcohen/public_git/memstomp;a=summary
> 
> Actually: git clone 
> git://fedorapeople.org/home/fedora/wcohen/public_git/memstomp
> 
> The implementation has some properties:
> 1.  Not async signal safe [malloc, fprintf], as noted previously by Daniel 
> Berrange.
> 2.  Not thread safe: unguarded top-level static variables in 
> backtrace-symbols.c.
> 3.  Essentially bundles a private copy of libbfd.

backtrace code was copied from mutrace to get the memstomp proof-of-concept 
working. It would be preferable to not have static libbfd libraries. Improved 
backtrace code would address a number of the issues mentioned here (2, 3, and 
6).

> 4.  Needs work for a process tree that uses a mixture of 32-bit and 64-bit 
> programs.

In theory, if both the 32-bit and 64-bit versions of the shared libraries are 
installed in the usual directories, the ldconfig has been run, and absolute 
paths are not used in LD_PRELOAD then the loader should find the correct 
version of the library.

> 5.  Does not catch violations in compile-time inlined expansions.

Neither LD_PRELOAD nor patching glibc is going to catch the compile-time 
inlined expansions. The compiler is going to need to add some check code to 
catch the problems with the inlined expansions or people are going to need to 
compile code with "-fno-builtin".

> 6.  SIGSEGVs for violations from just-in-time compiled code: uninit local
> variables in backtrace_symbols() not set by calls to dl_iterate_phdr.
> 


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

[perl-Module-Install] - Update to 1.00. - Update build dependencies: + Archive::Tar >= 1.44 + ExtUtils::Install >= 1.5

[Steven Pritchard]

commit cc3cb9a7e56cb36379d6c7fdee1012773d3ccde7
Author: Steven Pritchard 
Date:   Fri Mar 11 08:47:02 2011 -0600

- Update to 1.00.
- Update build dependencies:
  + Archive::Tar >= 1.44
  + ExtUtils::Install >= 1.52
  + ExtUtils::ParseXS >= 2.19
  + JSON >= 2.14
  + LWP::UserAgent >= 5.812
  + Module::Build >= 0.29
  + Module::CoreList >= 2.17
  + Module::ScanDeps >= 0.89
- Update description (pulled from module).

 .gitignore   |1 +
 perl-Module-Install.spec |   40 +++-
 sources  |2 +-
 3 files changed, 29 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9a4820d..f89c637 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
 Module-Install-0.95.tar.gz
+/Module-Install-1.00.tar.gz
diff --git a/perl-Module-Install.spec b/perl-Module-Install.spec
index 766ecf1..2ebf3ec 100644
--- a/perl-Module-Install.spec
+++ b/perl-Module-Install.spec
@@ -1,6 +1,6 @@
 Name:   perl-Module-Install
-Version:0.95
-Release:3%{?dist}
+Version:1.00
+Release:1%{?dist}
 Summary:Standalone, extensible Perl module installer
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -13,18 +13,19 @@ BuildArch:  noarch
 # certain modules than is supported. (Especially under F-10.) However, 
 # all tests pass and AFAICT everything works just fine in normal usage.
 
-BuildRequires:  perl(Archive::Tar) 
+BuildRequires:  perl(Archive::Tar) >= 1.44
 BuildRequires:  perl(CPAN)
-BuildRequires:  perl(Devel::PPPort) 
-BuildRequires:  perl(ExtUtils::Install) 
+BuildRequires:  perl(Devel::PPPort)
+BuildRequires:  perl(ExtUtils::Install) >= 1.52
 BuildRequires:  perl(ExtUtils::MakeMaker)
-BuildRequires:  perl(ExtUtils::ParseXS)
+BuildRequires:  perl(ExtUtils::ParseXS) >= 2.19
 BuildRequires:  perl(File::Remove) >= 1.42
 BuildRequires:  perl(File::Spec)
-BuildRequires:  perl(JSON)
-BuildRequires:  perl(Module::Build)
-BuildRequires:  perl(Module::CoreList)
-BuildRequires:  perl(Module::ScanDeps)
+BuildRequires:  perl(JSON) >= 2.14
+BuildRequires:  perl(LWP::UserAgent) >= 5.812
+BuildRequires:  perl(Module::Build) >= 0.29
+BuildRequires:  perl(Module::CoreList) >= 2.17
+BuildRequires:  perl(Module::ScanDeps) >= 0.89
 BuildRequires:  perl(PAR::Dist) >= 0.29
 BuildRequires:  perl(Parse::CPAN::Meta) >= 1.39
 BuildRequires:  perl(Test::CPAN::Meta) >= 0.07
@@ -39,14 +40,14 @@ Requires:   perl(Module::Build)
 Requires:   perl(Module::CoreList)
 Requires:   perl(Module::ScanDeps)
 Requires:   perl(PAR::Dist) >= 0.29
-Requires:   perl(YAML::Tiny) 
+Requires:   perl(YAML::Tiny)
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 
 %description
 Module::Install is a package for writing installers for CPAN (or CPAN-like)
 distributions that are clean, simple, minimalist, act in a strictly correct
-manner with both the ExtUtils::MakeMaker and Module::Build build systems,
-and will run on any Perl installation version 5.004 or newer.
+manner with ExtUtils::MakeMaker, and will run on any Perl installation
+version 5.005 or newer.
 
 %prep
 %setup -q -n Module-Install-%{version}
@@ -79,6 +80,19 @@ rm -rf $RPM_BUILD_ROOT
 %{_mandir}/man3/*
 
 %changelog
+* Thu Mar 10 2011 Steven Pritchard  1.00-1
+- Update to 1.00.
+- Update build dependencies:
+  + Archive::Tar >= 1.44
+  + ExtUtils::Install >= 1.52
+  + ExtUtils::ParseXS >= 2.19
+  + JSON >= 2.14
+  + LWP::UserAgent >= 5.812
+  + Module::Build >= 0.29
+  + Module::CoreList >= 2.17
+  + Module::ScanDeps >= 0.89
+- Update description (pulled from module).
+
 * Tue Feb 08 2011 Fedora Release Engineering  
- 0.95-3
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
 
diff --git a/sources b/sources
index 64865bd..bd03914 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-719fff3ea983818b176dea8770ccaa8e  Module-Install-0.95.tar.gz
+09067a39ba0330257f216effcf7f827c  Module-Install-1.00.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: Updating SSL keys on fedoraproject.org 2011-03-10

[Chris Adams]

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?  https://europa.eu/ uses SHA-1 on a cert issued in February 2010.
Of course, they also haven't disabled the weak SSL ciphers, so it's hard
to claim high security.
-- 
Chris Adams 
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

php-5.3.5-5.fc16, sphinx-0.9.9-2.fc14 - client version is higher than daemon version (client is v.1.23, daemon is v.1.22)

[Michał Piotrowski]

Hi,

I have a strange problem in php -> sphinx communication:

Mar 11 14:59:57 symfony [err] {Exception} searchd error: client
version is higher than daemon version (client is v.1.23, daemon is
v.1.22)

My system is based on F14 (with small changes) - because I had to use
MySQL 5.5 I had to build PHP. Previously, I had php-5.3.5-1 from F15 -
which was built without sphinx-0.9.9-2.fc14 package installed. Today I
built php-5.3.5-5.fc16 and have the same problem. I would be very
grateful if anyone could tell me what am I doing wrong. How can I
build php with proper sphinx version support? Or maybe the problem
lies elsewhere?

BTW. Sphinx from command line works perfectly fine, so I'm pretty sure
that this is not a problem with sphinx configuration.

-- 
Best regards,
Michal

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

Re: Orphaning packages

[lakshminaras2...@gmail.com]

I will take griffith and stow

On Wed, Mar 9, 2011 at 11:36 PM, Vivek Shah  wrote:

> Hi,
>I have orphaned a few packages owing to lack of time and non-usage.
>
> 1. struts
> 2. griffith
> 3. xqf
> 4. gquilt
> 5. quilt
> 6. stow
>
> Thanks and Regards,
> Vivek
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>



-- 
Regards
Lakshmi Narasimhan T V
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: ld error

[Stephen Gallagher]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03/11/2011 08:12 AM, Alain Portal wrote:
> Hi,
> 
> I trying to update kicad but the built fails with a ld error:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2903979
> and I don't succeed to fix it.
> 
> Can somebody help me?

Looks like you're not linking in BOARD::GetLayerColor(int) and
BOARD::GetLayerName(int) const correctly. You should figure out what
library or object file provides those and make sure they're listed in
the linking step.

- -- 
Stephen Gallagher
RHCE 804006346421761

Delivering value year after year.
Red Hat ranks #1 in value among software vendors.
http://www.redhat.com/promo/vendor/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk16KmsACgkQeiVVYja6o6N77QCgkx2M0mLfZASEOD83iaG3ML9z
XFEAoJxZENbaBAJD5rAsWs8uHB4fbgyu
=wiNB
-END PGP SIGNATURE-
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

ld error

[Alain Portal]

Hi,

I trying to update kicad but the built fails with a ld error:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2903979
and I don't succeed to fix it.

Can somebody help me?

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

RE: Request for sponsered development...

[Christian Weiß]

Petr,

to a certain extent, yes, VirtualGL is doing that.

However, VirtualGL is using VNC as the transport medium but I'd like to have a 
tighter integration with the Xorg architecture, otherwise Windows are bound the 
the VNC client space. Moreover, compression/decompression is handled by the CPU 
and I'd have this handled by the GPU (application and client side). But it's a 
good start and I've already contacted those folks.

In order to get all this closer into Xorg, here's what I have in mind: for 
rendering I'd like to use a TESLA board with an render pipeline written OpenCL 
or CUDA. Within a post-processing step the frame buffer (which is actually an 
off-screen buffer in OpenCL's global space) is compressed and picked-up by a 
GLX driver in user space. From what I read, AIGLX has the means transferring 
pixmap images directly to an GLX extension (GLX_pixmaptotexture or something) 
within the graphics driver. I'd use AIGLX to pass the image directly through to 
the (DRI) driver an let a pixel shader decompress the image. This way it goes 
effectively to the frame buffer of the clients X-server. 

Since AIGLX is a Fedora project, I hope that anyone here is able to provide me 
with further technical information about the protocol and the architecture - 
haven't found anything so far. As mentioned, whatever comes out of this I'll 
gladly contribute to the project.

Christian.

-Original Message-
From: devel-boun...@lists.fedoraproject.org 
[mailto:devel-boun...@lists.fedoraproject.org] On Behalf Of Petr Pisar
Sent: Dienstag, 08. März 2011 09:58
To: devel@lists.fedoraproject.org
Subject: Re: Request for sponsered development...

On 2011-03-06, Christian Weiß  wrote:
> Consider an installation of about ~600 low budget thin-clients (with
> almost no 3D support from the graphics chip) running as X-Terminals.
> Those thin-client stations are serviced by a host computer for 25-30
> stations each. This infrastructure should be the basis of an
> architectural/interior planning system with serious demands in terms
> of 3D rendering. It's all clear that the client hardware will not be
> able to provide the power, so it comes down to a server-based
> rendering approach. Therefore some of ATI's or Nvidia's latest boards
> should be attached to the host computers forming a CUDA cluster for
> their terminals. So, the question is: how to get the image to the
> client? 

This is already addressed by VirtualGL project
.

-- Petr

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

Linux IPC Benchmark

[Peter Penzov]

Hi,
   I'm interested is there IPC Benchmark test for Linux?

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

Re: 42 Orphaned packages

[Mat Booth]

On 10 March 2011 22:03, Richard W.M. Jones  wrote:
> On Wed, Mar 09, 2011 at 07:40:09AM +, Mat Booth wrote:
>> On 9 March 2011 06:37, Sven Lankes  wrote:
>> > After a dispute on the #fedora-kde IRC channel thomasj has orphaned a
>> > huge number of packages.
>> >
>>
>> Must have been some dispute. It's a shame it couldn't be resolved.
>>
>> > I extracted the list from scm-commits emails so I hope that I haven't
>> > missed any.
>> >
>> > The following packages are in need of new owners:
>> >
>> > recordmydesktop
>> > qt-recordmydesktop
>> > gtk-recordmydesktop
>>
>>
>> I really like this tool for making screencasts, if nobody takes this
>> by the time I get home from work, I will pick these up.
>
> I second that this is a great (albeit simple) tool; I don't have the
> time to maintain it though ...
>
> Rich.
>

I picked it up, co-maintainers welcome though. :-)



-- 
Mat Booth
http://fedoraproject.org/get-fedora
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Which fonts should be pulled in by desktop environments as dependencies?!

[Dominik 'Rathann' Mierzejewski]

On Monday, 28 February 2011 at 19:23, Bill Nottingham wrote:
> Hedayat Vatankhah (hedayat@gmail.com) said: 
> > Is it possible to depend on a group instead of a package at all?
> 
> No.

It is, however, possible to depend on virtual "package" which may be
provided by multiple real packages and will work as long as at least
one of them is installed.

Regards,
Dominik

-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org | MPlayer http://mplayerhq.hu
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

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

[Petr Pisar]

On 2011-03-10, Robert Relyea  wrote:
> SHA-1 is also used in the certificate. That, in theory, doesn't require
> TLS 1.2, though only TLS 1.2 includes protocol to tell servers what
> hashing algorithms the clients support, so in a strict sense only TLS
> tells you whether or not it's safe to use a cert with something other
> than SHA-1 or MD5. Most modern browers will support SHA-2 algorithms in
> the certificate (even when using SSL3, to TLS 1.x). The notable
> exceptions is verisons of Windows older than Windows XP service patch 3,
> and several older phones.
>
That's the hash usage I refered. I was amazed the certificate signature
algorithm is RSAwithSHA1. As it was said this does not dependend on TLS
version.

> Many CA's are apparently starting to move SHA-256 roots this year,
> mostly driven by NIST standards.
>
This year? In Europe we are over. All quallified CA's are forbiden to
issue SHA-1 certificates since begin of 2010.

-- Petr

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