Package review statistics 2013-04-01 - 2013-04-16

Hi, Here are some statistics on package reviews from the first of April. We'll try and get them around more regularly, hopefully on a weekly basis, in the future. Tom, Shawn and Kalev have done more reviews in this period. In total, there were 92 reviews completed: Start Date: 2013-04-01 00:00:00

Another UEFI testing request

Hi folks - thanks for helping out with the last UEFI testing request, it was very helpful. If we could impose again, it would be really helpful if anyone with a UEFI-capable system could try a UEFI native install of Alpha RC3: https://dl.fedoraproject.org/pub/alt/stage/19-Alpha-RC3/ and repor

[Test-Announce] Fedora 19 Alpha Release Candidate 3 (RC3) Available Now!

NOTE: All DVD and Live images except KDE Live and SoaS Live are still oversize (as they have been since Alpha TC3). As per the Fedora 19 schedule [1], Fedora 19 Alpha Release Candidate 3 (RC3) is now available for testing. Content information, including changes, can be found at https://fedorahoste

Re: meswa-libs* breaks X11 fedora 19

On Ter, 2013-04-16 at 03:05 +0100, Sérgio Basto wrote: > On Seg, 2013-04-15 at 23:20 +0100, Sérgio Basto wrote: > > On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: > > > I've a dell E6500 running F19. Did a yum upgrade from F18. All has been > > > working great > > > untill I tried to

Re: meswa-libs* breaks X11 fedora 19

On Seg, 2013-04-15 at 23:20 +0100, Sérgio Basto wrote: > On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: > > I've a dell E6500 running F19. Did a yum upgrade from F18. All has been > > working great > > untill I tried to upgrade the following: > > > > > > mesa-libEGL.i686 9

Re: meswa-libs* breaks X11 fedora 19

On Seg, 2013-04-15 at 07:49 -0500, Brian Millett wrote: > I've a dell E6500 running F19. Did a yum upgrade from F18. All has been > working great > untill I tried to upgrade the following: > > > mesa-libEGL.i686 9.1-6.fc19updates-testing > mesa-libEGL.x86_64 9.1-6.fc

Re: Expanding the list of "Hardened Packages"

les wrote: > I do not believe that C or C++ are > inherently less secure than other languages, nor do I believe that there > is some statistical way of proving that fact. One can write good or bad > code in all languages. I believe you are wrong. Some languages are more secure than other language

Re: Expanding the list of "Hardened Packages"

On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote: > Now, what to move to? I currently don't have see any language/runtime I > could recommend, which is in itself rather frightening. Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc. All these languages are viable

Re: next pkgdb?

On Mon, 15 Apr 2013 08:41:56 -0500 Bruno Wolff III wrote: > On Mon, Apr 15, 2013 at 12:55:35 +0200, > You might want to have some way to handle getting combinations of > access. For example if you request acl access, you really should > request all of the rest by default. Commit access should get

Re: Expanding the list of "Hardened Packages"

> From: les >Maybe I'm wrong, but given that I won't likely be around by the time > these newer languages have become senior, I won't see my statement > refuted. You needn't wait long. Ada has been around for three some decades already. ;-) -- John Florian -- devel mailing list devel@l

Re: Expanding the list of "Hardened Packages"

On Mon, 2013-04-15 at 20:17 +0200, Miloslav Trmač wrote: > On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald > wrote: > > Am 15.04.2013 18:48, schrieb Miloslav Trmač: > > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > mailto:h.rei...@thelounge.net>> > wrote:

What to move to? (was: Expanding the list of "Hardened Packages")

Miloslav Trmač wrote: > The logical conclusion from this is to move to a language with automatic > memory management. The "top vulnerability" reports for programs written in > C/C++ and most other languages so different that starting a new project > that processes untrusted data in C/C++ is becomi

Re: Expanding the list of "Hardened Packages"

On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald wrote: > > Am 15.04.2013 18:48, schrieb Miloslav Trmač: > > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > > h.rei...@thelounge.net>> wrote: > > > > which raises the question again: > > > > would it be not the better way to build the whole

Re: Expanding the list of "Hardened Packages"

Am 15.04.2013 18:48, schrieb Miloslav Trmač: > On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald > wrote: > > which raises the question again: > > would it be not the better way to build the whole distribution hardened > by expierience that nearly anythin

Re: Expanding the list of "Hardened Packages"

On 04/13/2013 07:43 PM, Kevin Kofler wrote: Richard W.M. Jones wrote: This would be excellent, and projects in this area could make a significant contribution. I suspect that any general code-to-policy translator will hit the Halting Problem, since it seems trivial to write a program which wo

Re: Trimming (or obsoleting) %changelog?

On 04/15/2013 09:05 AM, Pierre-Yves Chibon wrote: > On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: >> Richard Hughes wrote: >> >>> Is there any guidance as when to trim %changelog down to size? Some >>> packages have thousands of lines of spec file dating back over 15 >>> years which seem kin

Re: Trimming (or obsoleting) %changelog?

Once upon a time, Vít Ondruch said: > Not sure if the age of entry is the only metrics which should be used. > What if there was no change in last 3 years? Then we will have just one > changelog entry? Just thinking loud ... Especially if there was no upstream release in the last 3 years and th

Re: next pkgdb?

On Mon, 2013-04-15 at 16:55 +0100, Richard W.M. Jones wrote: > On Mon, Apr 15, 2013 at 12:08:24PM +0200, Pierre-Yves Chibon wrote: > > Please tell me, what's wrong with pkgdb and feel free to suggest how it > > could be fixed. > > I don't know if "pkgdb" covers this bit of UI: > > https://admin

Re: Expanding the list of "Hardened Packages"

On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald wrote: > which raises the question again: > > would it be not the better way to build the whole distribution hardened > by expierience that nearly anything is exploitable over the long and > performance comes after security > The logical conclusion f

Re: Trimming (or obsoleting) %changelog?

On Mon, 15 Apr 2013 11:03:34 -0500 Richard Shaw wrote: > On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi > wrote: > > > If I remember, I tend to trim off changelog entries that are more > > than two years old once a year for packages that I own. Two years > > is twice the length of a Fedora E

Re: Trimming (or obsoleting) %changelog?

Dne 15.4.2013 18:03, Richard Shaw napsal(a): On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi > wrote: If I remember, I tend to trim off changelog entries that are more than two years old once a year for packages that I own. Two years is twice the len

Re: Trimming (or obsoleting) %changelog?

On Mon, Apr 15, 2013 at 11:00 AM, Toshio Kuratomi wrote: > If I remember, I tend to trim off changelog entries that are more than two > years old once a year for packages that I own. Two years is twice the > length of a Fedora EOL cycle and since it grows to three years during the > interim, that

Re: Trimming (or obsoleting) %changelog?

On Mon, Apr 15, 2013 at 11:30:20AM +0100, Richard Hughes wrote: > Is there any guidance as when to trim %changelog down to size? Some > packages have thousands of lines of spec file dating back over 15 > years which seem kinda redundant now we're using git. > I believe we've had this discussion be

Re: next pkgdb?

On Mon, Apr 15, 2013 at 12:08:24PM +0200, Pierre-Yves Chibon wrote: > Please tell me, what's wrong with pkgdb and feel free to suggest how it > could be fixed. I don't know if "pkgdb" covers this bit of UI: https://admin.fedoraproject.org/pkgdb but it'd be nice if the "Applications" button was

Re: Keeping old versions of packages

On Sun, Apr 14, 2013 at 12:31 PM, Richard Hughes wrote: > On 13 April 2013 23:09, Kevin Kofler wrote: > > Sure you can! It's a basic rule of QA that small isolated changes can be > > debugged much better than a huge hodgepodge of many totally unrelated > > changes. > > Not true for the majority o

[Bug 952130] Provide perl-podlators

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 --- Comment #4 from Gianluca Sforna --- And anyway, I can't see how adding a Provides for something which is actually provided qualifies as a new feature. Thanks anyway for the prompt reply. -- You are receiving this mail becaus

[Bug 952130] Provide perl-podlators

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952130 --- Comment #3 from Gianluca Sforna --- This is weird. So it seems it took four commits to fprintd to settle on a suboptimal one :) http://pkgs.fedoraproject.org/cgit/fprintd.git/commit/?id=f40f69460a2cd7f6e09e87f9f5694499b7891cfd

Re: Expanding the list of "Hardened Packages"

On Mon, 2013-04-15 at 09:12 +0100, Richard W.M. Jones wrote: > which I interpret to mean that after using -fstack-protector-all and > removing prelink, SELinux would become obsolete because no executable > can be exploited. No; there are plenty of exploits which aren't due to buffer overflows. Pa

File XML-LibXML-2.0016.tar.gz uploaded to lookaside cache by ppisar

A file has been added to the lookaside cache for perl-XML-LibXML: d3bbc3437f6b39eca5825e9d0b0c187a XML-LibXML-2.0016.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/mailm

Re: Expanding the list of "Hardened Packages"

On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote: > which I interpret to mean that after using -fstack-protector-all and > removing prelink, SELinux would become obsolete because no executable > can be exploited. I would say there is a place for SE Linux even if we compiled everythin

Re: next pkgdb?

On Mon, Apr 15, 2013 at 12:55:35 +0200, Pierre-Yves Chibon wrote: We're also thinking of a "Become comaintainer" button that applies for you to all ACLs for the latest 2 branches (for example). You'd probably want the default to be all active Fedora branches rather than the latest 2. You

Re: Trimming (or obsoleting) %changelog?

On 15 Apr 2013 14:16, "Pierre-Yves Chibon" wrote: > > On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: > > Richard Hughes wrote: > > > > > Is there any guidance as when to trim %changelog down to size? Some > > > packages have thousands of lines of spec file dating back over 15 > > > years whi

Re: Trimming (or obsoleting) %changelog?

At the moment, my best judgment is "trim anything older than one year" and that's what I've been doing to my packages. Thanks for the sanity check. Richard On 15 April 2013 13:43, Rex Dieter wrote: > Richard Hughes wrote: > >> Is there any guidance as when to trim %changelog down to size? Some >

[perl-File-Temp] Teach rpmlint

commit f1535f9e905d616a69913d335f5c250f82b38f1c Author: Petr Písař Date: Mon Apr 15 15:10:00 2013 +0200 Teach rpmlint .rpmlint |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..62edac9 --- /dev/null +++ b/.

[perl-File-Temp] 0.2301 bump

commit 8533e181dc3025e3b18a7c043db8daf3193b8463 Author: Petr Písař Date: Mon Apr 15 15:09:04 2013 +0200 0.2301 bump .gitignore |1 + perl-File-Temp.spec | 26 -- sources |2 +- 3 files changed, 18 insertions(+), 11 deletions(-) --- di

File File-Temp-0.2301.tar.gz uploaded to lookaside cache by ppisar

A file has been added to the lookaside cache for perl-File-Temp: 75a8aec1916ebbe88988ce68e84ccdd7 File-Temp-0.2301.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

Re: Trimming (or obsoleting) %changelog?

On Mon, 2013-04-15 at 07:43 -0500, Rex Dieter wrote: > Richard Hughes wrote: > > > Is there any guidance as when to trim %changelog down to size? Some > > packages have thousands of lines of spec file dating back over 15 > > years which seem kinda redundant now we're using git. > > To me, common

Re: Broken dependencies: rubygem-pam

Hi Bryan, If you are OK with: * making the .spef file F19+ compatible only * dropping the ruby-pam sub-package I can fix the .spec file for you. Please let me know. Vít Dne 15.4.2013 13:54, Bryan Kearney napsal(a): I am not sure how to fix this. The current spec file in master and f19 h

[Bug 952179] perl-File-Fetch-0.42 is available

Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=952179 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version|

meswa-libs* breaks X11 fedora 19

I've a dell E6500 running F19. Did a yum upgrade from F18. All has been working great untill I tried to upgrade the following: mesa-libEGL.i686 9.1-6.fc19updates-testing mesa-libEGL.x86_64 9.1-6.fc19updates-testing mesa-libEGL-devel.x86_64 9.1-6.fc19

[perl-File-Fetch] Teach rpmlint

commit b5288b83ada5420e29ddbe876420a754e1a3b9cb Author: Petr Písař Date: Mon Apr 15 14:46:46 2013 +0200 Teach rpmlint .rpmlint |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- diff --git a/.rpmlint b/.rpmlint new file mode 100644 index 000..21e112e --- /dev/null +++ b/.

[perl-File-Fetch] Revert "Teach rpmlint"

commit 19e7a110abbd77817d909a6e5715f48d336c91a9 Author: Petr Písař Date: Mon Apr 15 14:46:03 2013 +0200 Revert "Teach rpmlint" This reverts commit 787a690ec94d904da883b726dc88aa4098ff8056. .build-0.38-1.fc20.log| 94 -- .build-0.42-1.fc20.log

Re: Trimming (or obsoleting) %changelog?

Richard Hughes wrote: > Is there any guidance as when to trim %changelog down to size? Some > packages have thousands of lines of spec file dating back over 15 > years which seem kinda redundant now we're using git. To me, common sense dictates that it's perfectly ok to trim the length of the ch

Re: Broken dependencies: rubygem-pam

Hi, change ruby(abi) to Requires: ruby(release) as in guidelines [1] "Each Ruby package must indicate it depends on a Ruby interpreter. Use ruby(release) virtual requirement to achieve that: " This is due to support both MRI and JRuby in next Fedora releases. [1] https://fedoraproject.org/wiki

F-19 Branched report: 20130415 changes

Compose started at Mon Apr 15 09:15:16 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [alexandria] alexandria-0.6.9-4.fc19.noarch requires ruby(abi) >=

[pkgdb] perl-DBD-MySQL had acl change status

ppisar has set the watchcommits acl on perl-DBD-MySQL (Fedora 18) to Approved for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-DBD-MySQL -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list per

[pkgdb] perl-DBD-MySQL had acl change status

ppisar has set the watchcommits acl on perl-DBD-MySQL (Fedora 19) to Approved for perl-sig To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-DBD-MySQL -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list per

Broken dependencies: rubygem-pam

I am not sure how to fix this. The current spec file in master and f19 has the following requires: BuildRequires: ruby-devel >= 1.9 Requires: ruby(abi) >= 1.9 The current package is at 2.0 which should be ok. Is there an obvious change I need to make? -- bk Original Messa

rawhide report: 20130415 changes

Compose started at Mon Apr 15 08:15:47 UTC 2013 Broken deps for x86_64 -- [aeolus-conductor] aeolus-conductor-0.10.6-2.fc19.noarch requires ruby(abi) = 0:1.9.1 [amide] amide-1.0.0-4.fc19.x86_64 requires libvolpack.so.1()(64bit

Re: next pkgdb?

On Mon, 2013-04-15 at 12:34 +0200, Dan Horák wrote: > ownership of a package by a group On Mon, 2013-04-15 at 05:29 -0500, Bruno Wolff III wrote: > It would be nice to be able to change acls without having to enable javascript. On Mon, 2013-04-15 at 03:29 -0700, Dan Mashal wrote: > 1) It's slow.

Re: next pkgdb?

On Mon, 15 Apr 2013 12:08:24 +0200 Pierre-Yves Chibon wrote: > On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: > > It returns you to pkgdb to set acls and the relationships tab gives > > an error. I was mainly looking at it to manage permissions (right > > now). > > Packages is not meant fo

Trimming (or obsoleting) %changelog?

Is there any guidance as when to trim %changelog down to size? Some packages have thousands of lines of spec file dating back over 15 years which seem kinda redundant now we're using git. Richard. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo

Re: next pkgdb?

On Mon, Apr 15, 2013 at 12:08:24 +0200, Pierre-Yves Chibon wrote: On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: It returns you to pkgdb to set acls and the relationships tab gives an error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this

Re: next pkgdb?

On Mon, Apr 15, 2013 at 3:08 AM, Pierre-Yves Chibon wrote: > On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: >> It returns you to pkgdb to set acls and the relationships tab gives an >> error. I was mainly looking at it to manage permissions (right now). > > Packages is not meant for this > >

next pkgdb?

On Sun, 2013-04-14 at 15:28 -0700, Dan Mashal wrote: > It returns you to pkgdb to set acls and the relationships tab gives an > error. I was mainly looking at it to manage permissions (right now). Packages is not meant for this > And when I meant functional I meant FULLY functional, meaning I > w

Re: Expanding the list of "Hardened Packages"

On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: > Richard W.M. Jones wrote: > > I said it "doesn't implement full bounds checking for every C object", > > and I stand by that. I doesn't cover stack objects smaller than some > > cut-off size, nor any objects in static data or on the h

Re: Expanding the list of "Hardened Packages"

On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote: > I repeat: The proper solution is to prevent executing any machine code which > is not part of the program's source code. You're simply wrong about this. It's trivial to come up with a counter-example, if you're prepared to give it a

Re: Expanding the list of "Hardened Packages"

On 04/05/13 at 04:16pm, Jakub Jelinek wrote: > On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote: > > I repeated the benchmarks (mentioned in the above bug report) for > > Firefox 20.0 running on Fedora 18 64-bit. > > Firefox as benchmark doesn't look like a good idea (and I'm really sur