Re: Problem with F17 yum requesting old repodata?

[Zdenek Pavlas]

> This is what I get for the last few days:
> # yum --skip-broken update

This is a fairly common scenario.  Let me explain..
Repository cachecookie was older than 6 hours,
Yum updates the metalink.xml file:

> updates/17/x86_64/metalink  |  16 kB 00:00

The repomd.xml timestamp stored in metalink.xml has changed.
Yum retrieves new repomd.xml from some mirror:

> updates | 4.7 kB 00:00

Then, $hash-primary.sqlite.bz2 referenced by the new repomd.xml
needs to be retrieved.  But 1st mirror Yum tried didn't have it:

> http://ftp.informatik.uni-frankfurt.de/fedora/updates/17/x86_64/repodata/00c7410a78aa8dd0f4934ed4935377b99e0339101cee369c1b1691f3025950ac-primary.sqlite.bz2:
> [Errno 14] HTTP Error 404 - Not Found

Yum tries the same relative URL on other mirror.
This time the DL was successful:

> Trying other mirror.
> updates/primary_db  | 6.9 MB 00:06

Metadata are pushed to mirrors as independent files.  Probably
the tiny repomd.xml is way ahead of primary.sqlite.bz2,
so there's a race possible.

But since we handle it (by trying other mirror, or reverting
to previous metadata when all mirrors fail), I don't consider
this a bug.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

File IO-Socket-SSL-1.79.tar.gz uploaded to lookaside cache by pghmcfc

[Paul Howarth]

A file has been added to the lookaside cache for perl-IO-Socket-SSL:

a8a68e432e02d58a67c3e99742c07f83  IO-Socket-SSL-1.79.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

LibRaw: possible license issues

[Debarshi Ray]

I came across what looks like a possible licensing issue with LibRaw and
applications that link to it. I am not totally sure that there is a problem,
but I have enough reason to have doubts. I welcome any clarifications and
advice.

LibRaw's License tag was changed from "LGPLv2 or CDDL" to GPLv3 when the two
demosaic packs were added [1]. One of the demosaic packs is GPLv2+ and the
other is GPLv3+.

However, http://www.libraw.org/ mentions LibRaw's license as GPLv2+, while the
source files continue to claim that they are under LGPLv2 or CDDL.

Shotwell, which uses LibRaw, is LGPLv2+. By my reading of the compatibility
matrix [2], it means that Shotwell is now effectively GPLv3. If that is the
case, then has Yorba been notified of that? I doubt they would suddenly want
their code to become GPLv3 instead of LGPLv2+.

Thanks,
Debarshi

[1] https://bugzilla.redhat.com/show_bug.cgi?id=760638
[2] https://fedoraproject.org/wiki/Licensing:Main#GPL_Compatibility_Matrix

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


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

Re: Looking for a freemind maintainer

[Caterpillar]

Il 23/11/2012 15:33, Johannes Lips ha scritto:
> Hi all,
>
> I am looking for a new freemind maintainer. I've stated the reason for
> this in this mail to java-devel:
> http://lists.fedoraproject.org/pipermail/java-devel/2012-November/004561.html
>
> Perhaps someone would like to take over...
>
> Johannes
>
>
Hi, I often use freemind for my studies, but I have never mantained a
package. What level of knowledge does the freemind manteinance require?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[Test-Announce] 2012-11-26 @ 16:00 UTC - Fedora QA Meeting

[Adam Williamson]

# Fedora Quality Assurance Meeting
# Date: 2012-11-26
# Time: 16:00 UTC
(https://fedoraproject.org/wiki/Infrastructure/UTCHowto)
# Location: #fedora-meeting on irc.freenode.net

Greetings testers!

It's meeting time again tomorrow. We finally signed off on Beta, so we
just need to wrap up any documentation, F17 update pushes etc that may
be needed.

This is a reminder of the upcoming QA meeting.  Please add any topic
suggestions to the meeting wiki page:
https://fedoraproject.org/wiki/QA/Meetings/20121126

The current proposed agenda is included below.

== Proposed Agenda Topics ==
1. Previous meeting follow-up 
2. Fedora 18 Beta review / Final planning
3. Test case / criteria revision
4. Open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

___
test-announce mailing list
test-annou...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

mod_auth_shadow retirement

[Jan Klepek]

Hi,

I have retired mod_auth_shadow for F18 and anything newer. Package will be
blocked (hopefully soon, ticket for this was raised to rel-eng).

If there is somebody who wants to maintain this, please go ahead and pick
ownership in PKGDB.

Reason for retirement is that upstream is dead (no working contact to
person who developed this mod) and that mod_auth_shadow is not compatible
with Apache 2.4 shipped with F18 (it requires that mod is rewritten to
remove old Apache API and use the new one).

Regards,
Jan Klepek

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

Re: raising warning flag on firewalld-default feature

[Simon Lukasik]

On 11/25/2012 05:12 PM, Richard W.M. Jones wrote:
> On Fri, Nov 23, 2012 at 11:43:01AM +0100, Simon Lukasik wrote:
>> On 11/22/2012 09:07 PM, Richard W.M. Jones wrote:
>>> On Tue, Nov 20, 2012 at 12:52:30PM -0500, Przemek Klosowski wrote:
 Interpreters do not preclude simple data: they just scale better,
 from simple linear declarative data to complex, Turing-cranking
 swamp. The only argument against it is runtime overhead, which isn't
 a problem in many, if not most, cases.
>>>
>>> It's NOT the only argument against it.  Having Turing-complete
>>> configuration files makes it impossible to have other programs parse
>>> and understand the configuration.  Programs including:
>>>
>>>  - OpenSCAP, or any other security scanner
>>>  - libvirt (hello, old Xen's python config files)
>>>  - multiple libguestfs tools like virt-sysprep
>>>  - Augeas and all the tools that use it
>>>
>>
>> Moreover, If the application (polkit) uses its embedded interpreter to
>> assess configuration and the scanner (OpenSCAP) uses it's own way how to
>> assess it (even if it differs in a version of the interpreter). --> It
>> only opens door for very subtle bugs.
>>
>> Which leads me to thinking that the applications (which use Turing
>> complete languages for configuration) shall provide a comprehensive API
>> to query the configuration.
> 
> This isn't going to work for SCAP.  SCAP (or more specifically, OVAL)
> is a standardized XML schema for assessing the configuration of
> systems.  Steve will correct me if I'm wrong here, but I don't believe
> there's no room for it to be calling out to arbitrary custom
> libraries.

Sure, there is no room for *arbitrary* and custom libraries. On the
other hand, there are libraries which are already in use. Consider
librpm which is even namely regarded by OVAL specification. Thus, If
there was comprehensive interface to query polkit configuration, I could
imagine SCAP using it in similar way how it uses librpm.

But my point was more like: If there was an comprehensive interface to
read and write that configuration, there couldn't be a complain about
compliance checks.

> http://oval.mitre.org/language/index.html
> http://oval.mitre.org/language/about/definition.html
> 
> Like it or not, this sort of scanning is extremely useful for cloud
> administrators who want to be able to automatically scan disk images
> uploaded from non-trusted sources and find out whether they contain
> vulnerabilities.  The requirements for configuration files to be
> simple and non-Turing-complete are not going to go away.
> 
> Rich.
> 

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

Re: Orphaning libunwind

[Mat Booth]

Won't you need to retire it when elfutils obsoletes it?


On 24 November 2012 07:40, Jan Kratochvil  wrote:
> Hi,
>
> as elfutils package is going to contain unwinder in its next release orphaning
> the libunwind library.
>
> https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
>
>
> Jan
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel



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

Re: raising warning flag on firewalld-default feature

[Richard W.M. Jones]

You're asking for something very open-ended, and which is not even
possible to implement in general -- what if the inspecting operating
system is Linux, and the inspected operating system needs custom Mac OS X
libraries?

In any case, the correct place to request this is with the SCAP
standards team.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Looking for a freemind maintainer

[Kalpa Welivitigoda]

On Mon, Nov 26, 2012 at 3:55 PM, Caterpillar  wrote:
> Il 23/11/2012 15:33, Johannes Lips ha scritto:
>> Hi all,
>>
>> I am looking for a new freemind maintainer. I've stated the reason for
>> this in this mail to java-devel:
>> http://lists.fedoraproject.org/pipermail/java-devel/2012-November/004561.html
>>
>> Perhaps someone would like to take over...
>>

I am a frequent freemind user and I would like to take over.

>> Johannes
>>
>>
> Hi, I often use freemind for my studies, but I have never mantained a
> package. What level of knowledge does the freemind manteinance require?

Perhaps you may join as a co-maintainer.

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



--
Best Regards,

Kalpa Welivitigoda
http://about.me/callkalpa
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning libunwind

[Jan Kratochvil]

On Mon, 26 Nov 2012 12:23:16 +0100, Mat Booth wrote:
> Won't you need to retire it when elfutils obsoletes it?

The development is not yet at that point, it may happen later:

(1) elfutils needs to integrate it and get released first (January/February),
being worked on with Mark Wielaard:

https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/thread.html

$ repoquery -q --whatrequires libunwind --archlist x86_64
libunwind-devel-0:1.0.1-4.fc18.x86_64
perf-0:3.7.0-0.rc6.git4.1.fc19.x86_64
gperftools-libs-0:2.0-7.fc18.x86_64

(2) perf is being actively ported from libunwind API to elfutils API
with Jiri Olsa; but it is also not upstreamed yet:
git://git.jankratochvil.net/linux
unwind4-fix-cache

(3) gperftools is using libunwind API, so far I did not plan to port it
myself, I could later after the projects above get completed.


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

Splitting out PackageKit-Qt -- help required

[Richard Hughes]

I'm here asking advice. PackageKit used to ship subpackages of
PackageKit-glib, PackageKit-glib-devel, PackageKit-qt, and
PackageKit-qt-devel amoung others.

Upstream PackageKit-Qt has been split out into another separate
project as it had different API and ABI promises to PackageKit-glib
and it was being maintained by another team who wanted to use the
cmake build system.

The only application in Fedora that requires PackageKit-qt is apper,
the package manager we ship in the KDE spin.

Now, to avoid breaking apper, and the KDE spin, I've tried to be a
nice maintainer and done a package review for the new package (package
review most welcome):
https://bugzilla.redhat.com/show_bug.cgi?id=880155

I've also done a new PackageKit release in rawhide with the
PackageKit-qt bits removed.

So, I need a plan of action and a list of things to provide and
obsolete in each of the PackageKit.spec, PackageKit-Qt.spec and what
to require in apper.

So far, what I'm thinking is that I should have in PackageKit.spec:

Obsoletes: PackageKit-qt < %{version}-%{release}

and in PackageKit-Qt.spec I should have:

Provides: PackageKit-qt

and then as a belt-and-braces fix also switch apper.spec to
BuildRequiring PackageKit-Qt-devel rather than PackageKit-qt-devel.

Sanity check most appreciated, thanks.

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

Re: Orphaning libunwind

[Josh Boyer]

On Mon, Nov 26, 2012 at 7:14 AM, Jan Kratochvil
 wrote:
> On Mon, 26 Nov 2012 12:23:16 +0100, Mat Booth wrote:
>> Won't you need to retire it when elfutils obsoletes it?
>
> The development is not yet at that point, it may happen later:
>
> (1) elfutils needs to integrate it and get released first (January/February),
> being worked on with Mark Wielaard:
> 
> https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/thread.html
>
> $ repoquery -q --whatrequires libunwind --archlist x86_64
> libunwind-devel-0:1.0.1-4.fc18.x86_64
> perf-0:3.7.0-0.rc6.git4.1.fc19.x86_64
> gperftools-libs-0:2.0-7.fc18.x86_64
>
> (2) perf is being actively ported from libunwind API to elfutils API
> with Jiri Olsa; but it is also not upstreamed yet:
> git://git.jankratochvil.net/linux
> unwind4-fix-cache

So are you not orphaning libunwind until that is merged into the
upstream kernel?

What about perf releases that support libunwind in older Fedora
releases?  Will you wait until all of those have been rebased?

If perf winds up getting stuck relying on an orphaned library for some
non-trivial amount of time, I'd rather just turn off libunwind support
in perf now.  It's only enabled in rawhide at the moment because it is
a 3.7 feature.  Before we bring 3.7 back to f17-f18, we should probably
decide.

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

Re: Orphaning libunwind

[Jan Kratochvil]

On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
> So are you not orphaning libunwind until that is merged into the
> upstream kernel?

To get the terminology right:
I am 'orphaning' it now.  Later it may be 'obsolsted'.

If I should keep it formally maintaining I could.  But factically it won't
change what I really do with the libunwind package.  I have not fixed any
libunwind bug since 2009 and there is no one filed in RH BZ now; except
https://bugzilla.redhat.com/show_bug.cgi?id=863781
rebase to 1.1 which I do not find meaningful for Fedora anymore, at least not
from my perspective.

I know about too many bugs in libunwind and I have found it easier to rather
reimplement the remaining few bits of elfutils so that elfutils can unwind on
its own.


> What about perf releases that support libunwind in older Fedora
> releases?  Will you wait until all of those have been rebased?

As I said I have not fixed anything in libunwind for the past 3 years and also
I have even never found the non-ia64 part of libunwind meaningful before.

I can write my name into pkgdb ownership field back if you wish so.


> If perf winds up getting stuck relying on an orphaned library for some
> non-trivial amount of time,

AFAIK that is common in Fedora there are orphaned libraries in use for
a release or two.


> I'd rather just turn off libunwind support in perf now.  It's only enabled
> in rawhide at the moment because it is a 3.7 feature.  Before we bring 3.7
> back to f17-f18, we should probably decide.

That is more a question to Jiri Olsa, the author of perf libunwind client.


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

Re: Orphaning libunwind

[Jan Kratochvil]

On Mon, 26 Nov 2012 15:22:08 +0100, Jan Kratochvil wrote:
> On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
> > So are you not orphaning libunwind until that is merged into the
> > upstream kernel?
> 
> To get the terminology right:
> I am 'orphaning' it now.  Later it may be 'obsolsted'.

Probably rather:
  I am 'orphaning' it now.  Later it may be 'deprecated'.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning libunwind

[Jiri Olsa]

On Mon, Nov 26, 2012 at 03:22:08PM +0100, Jan Kratochvil wrote:
> On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:
> > So are you not orphaning libunwind until that is merged into the
> > upstream kernel?
> 
> To get the terminology right:
> I am 'orphaning' it now.  Later it may be 'obsolsted'.
> 
> If I should keep it formally maintaining I could.  But factically it won't
> change what I really do with the libunwind package.  I have not fixed any
> libunwind bug since 2009 and there is no one filed in RH BZ now; except
>   https://bugzilla.redhat.com/show_bug.cgi?id=863781
> rebase to 1.1 which I do not find meaningful for Fedora anymore, at least not
> from my perspective.
> 
> I know about too many bugs in libunwind and I have found it easier to rather
> reimplement the remaining few bits of elfutils so that elfutils can unwind on
> its own.
> 
> 
> > What about perf releases that support libunwind in older Fedora
> > releases?  Will you wait until all of those have been rebased?
> 
> As I said I have not fixed anything in libunwind for the past 3 years and also
> I have even never found the non-ia64 part of libunwind meaningful before.
> 
> I can write my name into pkgdb ownership field back if you wish so.
> 
> 
> > If perf winds up getting stuck relying on an orphaned library for some
> > non-trivial amount of time,
> 
> AFAIK that is common in Fedora there are orphaned libraries in use for
> a release or two.
> 
> 
> > I'd rather just turn off libunwind support in perf now.  It's only enabled
> > in rawhide at the moment because it is a 3.7 feature.  Before we bring 3.7
> > back to f17-f18, we should probably decide.
> 
> That is more a question to Jiri Olsa, the author of perf libunwind client.

it will be configurable for both libunwind and elfutils unwinders,
and making default the one with better results or available

I should send upstream perf changes within this week

CCing Arnaldo

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

[perl-CGI/f16] 3.52 bump to fix CVE-2012-5526

[Petr Pisar]

commit 2e05079f215ab2f2c3a9d804461f780c8274a728
Author: Petr Písař 
Date:   Mon Nov 26 15:02:09 2012 +0100

3.52 bump to fix CVE-2012-5526

 .gitignore |1 +
 ...n_cookies.patch => CGI-3.51-CVE-2012-5526.patch |0
 perl-CGI.spec  |   11 ---
 sources|2 +-
 4 files changed, 10 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 879a835..3db305c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,2 +1,3 @@
 /CGI.pm-3.50.tar.gz
 /CGI.pm-3.51.tar.gz
+/CGI.pm-3.52.tar.gz
diff --git a/CGI-3.51-escape_new_lines_in_cookies.patch 
b/CGI-3.51-CVE-2012-5526.patch
similarity index 100%
rename from CGI-3.51-escape_new_lines_in_cookies.patch
rename to CGI-3.51-CVE-2012-5526.patch
diff --git a/perl-CGI.spec b/perl-CGI.spec
index dafa504..e4e079e 100644
--- a/perl-CGI.spec
+++ b/perl-CGI.spec
@@ -1,12 +1,12 @@
 Name:   perl-CGI
 Summary:Handle Common Gateway Interface requests and responses
-Version:3.51
-Release:6%{?dist}
+Version:3.52
+Release:203%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
 Source0:
http://search.cpan.org/CPAN/authors/id/M/MA/MARKSTOS/CGI.pm-%{version}.tar.gz
 # CVE-2012-5526, RHBZ #876974
-Patch0: CGI-3.51-escape_new_lines_in_cookies.patch
+Patch0: CGI-3.51-CVE-2012-5526.patch
 URL:http://search.cpan.org/dist/CGI
 Requires:   perl(:MODULE_COMPAT_%(eval "`%{__perl} -V:version`"; echo 
$version))
 BuildArch:  noarch
@@ -75,6 +75,11 @@ rm -rf %{buildroot}
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Nov 26 2012 Petr Pisar  - 3.52-203
+- 3.52 bump
+- Fix CVE-2012-5526 (escape new-lines in Set-Cookie and P3P response headers
+  properly (bug #876974)
+
 * Fri Nov 16 2012 Petr Pisar  - 3.51-6
 - Improper new-line escaping in Set-Cookie and P3P headers is known as
   CVE-2012-5526 (bug #876974)
diff --git a/sources b/sources
index 3fbe366..d83777a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-53534654f745a1388bbda477022cf971  CGI.pm-3.51.tar.gz
+6ec43c813175e71ad9b19598899f  CGI.pm-3.52.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

abrt server report: 20121126

[Richard Marko]

Hot problems:

ID Components Count
---
90599  kernel   406
91614  kernel   303
90633  gnome-packagekit 212
92490  zenity   170
83012  tracker  163
19369  control-center   154
83612  tracker  145
92352  kernel   137
21780  control-center   137
20085  gnome-terminal   135


URL: http://retrace.fedoraproject.org/faf/problems/hot/

Long-term problems:

ID Components Count
---
90599  kernel  1449
19369  control-center  1047
90633  gnome-packagekit 834
83012  tracker  811
20085  gnome-terminal   657
45076  tracker  613
54879  tracker  545
21794  control-center   526
83612  tracker  520
92490  zenity   513


URL: http://retrace.fedoraproject.org/faf/problems/longterm/

Most destabilized components:

Component   Jump Graph
--
kernel 5   ???

gnome-terminal14   ???

ailurus4   ???

gnome-packagekit  14   ???

alacarte   3   ???



Most stabilized components:

Component   Jump Graph
--
tracker  -20   ???

evolution-11   ???

rhythmbox-14   ???

control-center-5   ???

java-1.7.0-openjdk-5   ???



Server URL: http://retrace.fedoraproject.org/faf/
Report a bug: https://fedorahosted.org/abrt/newticket?component=faf
Server sources: http://git.fedorahosted.org/cgit/faf.git/

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

Re: Orphaning libunwind

[Josh Boyer]

On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa  wrote:
>> > If perf winds up getting stuck relying on an orphaned library for some
>> > non-trivial amount of time,
>>
>> AFAIK that is common in Fedora there are orphaned libraries in use for
>> a release or two.
>>
>>
>> > I'd rather just turn off libunwind support in perf now.  It's only enabled
>> > in rawhide at the moment because it is a 3.7 feature.  Before we bring 3.7
>> > back to f17-f18, we should probably decide.
>>
>> That is more a question to Jiri Olsa, the author of perf libunwind client.
>
> it will be configurable for both libunwind and elfutils unwinders,
> and making default the one with better results or available
>
> I should send upstream perf changes within this week

Those won't make it into the kernel until 3.8 though.  So for 3.7, I'm
thinking we should just disable perf libunwind support entirely.  Once
elf-utils gets its unwinder and the patches for perf hit rawhide we can
turn it back on.

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

Re: Orphaning libunwind

[Jiri Olsa]

On Mon, Nov 26, 2012 at 09:34:35AM -0500, Josh Boyer wrote:
> On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa  wrote:
> >> > If perf winds up getting stuck relying on an orphaned library for some
> >> > non-trivial amount of time,
> >>
> >> AFAIK that is common in Fedora there are orphaned libraries in use for
> >> a release or two.
> >>
> >>
> >> > I'd rather just turn off libunwind support in perf now.  It's only 
> >> > enabled
> >> > in rawhide at the moment because it is a 3.7 feature.  Before we bring 
> >> > 3.7
> >> > back to f17-f18, we should probably decide.
> >>
> >> That is more a question to Jiri Olsa, the author of perf libunwind client.
> >
> > it will be configurable for both libunwind and elfutils unwinders,
> > and making default the one with better results or available
> >
> > I should send upstream perf changes within this week
> 
> Those won't make it into the kernel until 3.8 though.  So for 3.7, I'm
> thinking we should just disable perf libunwind support entirely.  Once
> elf-utils gets its unwinder and the patches for perf hit rawhide we can
> turn it back on.

currently if the libunwind is not found during build time, it's not compiled in

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

File Net-GitHub-0.48.tar.gz uploaded to lookaside cache by psabata

[Petr Šabata]

A file has been added to the lookaside cache for perl-Net-GitHub:

024925e1df996838ca8dd6ae518afac3  Net-GitHub-0.48.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

[perl-Net-GitHub] 0.48 bump

[Petr Šabata]

commit 38bc297279c2040a428e65be7e6f28e4e7c8ce2c
Author: Petr Šabata 
Date:   Mon Nov 26 15:45:24 2012 +0100

0.48 bump

 .gitignore   |1 +
 perl-Net-GitHub.spec |   11 ---
 sources  |2 +-
 3 files changed, 6 insertions(+), 8 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 9bfcf58..4181a34 100644
--- a/.gitignore
+++ b/.gitignore
@@ -8,3 +8,4 @@ Net-GitHub-0.22.tar.gz
 /Net-GitHub-0.45.tar.gz
 /Net-GitHub-0.46.tar.gz
 /Net-GitHub-0.47.tar.gz
+/Net-GitHub-0.48.tar.gz
diff --git a/perl-Net-GitHub.spec b/perl-Net-GitHub.spec
index 4db701a..a2beaba 100644
--- a/perl-Net-GitHub.spec
+++ b/perl-Net-GitHub.spec
@@ -1,6 +1,6 @@
 Name:   perl-Net-GitHub
 Summary:Perl interface for github.com
-Version:0.47
+Version:0.48
 Release:1%{?dist}
 License:GPL+ or Artistic
 Group:  Development/Libraries
@@ -10,17 +10,12 @@ Requires:   perl(:MODULE_COMPAT_%(eval "`perl 
-V:version`"; echo $version))
 BuildArch:  noarch
 BuildRequires:  perl(Any::Moose)
 BuildRequires:  perl(Carp)
-BuildRequires:  perl(CPAN)
-BuildRequires:  perl(Crypt::SSLeay)
 BuildRequires:  perl(ExtUtils::MakeMaker) >= 6.42
-BuildRequires:  perl(File::Slurp)
-BuildRequires:  perl(HTML::TreeBuilder)
 BuildRequires:  perl(HTTP::Request)
 BuildRequires:  perl(HTTP::Request::Common)
 BuildRequires:  perl(inc::Module::Install)
 BuildRequires:  perl(JSON::Any)
 BuildRequires:  perl(MIME::Base64)
-BuildRequires:  perl(Test::MockModule)
 BuildRequires:  perl(Test::More)
 BuildRequires:  perl(Test::Pod) >= 1.22
 BuildRequires:  perl(URI)
@@ -45,7 +40,6 @@ make %{?_smp_mflags}
 %install
 make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
-find %{buildroot} -depth -type d -exec rmdir {} 2>/dev/null ';'
 %{_fixperms} %{buildroot}/*
 
 %check
@@ -57,6 +51,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Nov 26 2012 Petr Šabata  - 0.48-1
+- 0.48 bump
+
 * Wed Nov 07 2012 Petr Šabata  - 0.47-1
 - 0.47 bump
 
diff --git a/sources b/sources
index f6f74bb..cfc5a03 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-4d9a083080b6492bb509d507e3875bfb  Net-GitHub-0.47.tar.gz
+024925e1df996838ca8dd6ae518afac3  Net-GitHub-0.48.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: Orphaning libunwind

[Josh Boyer]

On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa  wrote:
> On Mon, Nov 26, 2012 at 09:34:35AM -0500, Josh Boyer wrote:
>> On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa  wrote:
>> >> > If perf winds up getting stuck relying on an orphaned library for some
>> >> > non-trivial amount of time,
>> >>
>> >> AFAIK that is common in Fedora there are orphaned libraries in use for
>> >> a release or two.
>> >>
>> >>
>> >> > I'd rather just turn off libunwind support in perf now.  It's only 
>> >> > enabled
>> >> > in rawhide at the moment because it is a 3.7 feature.  Before we bring 
>> >> > 3.7
>> >> > back to f17-f18, we should probably decide.
>> >>
>> >> That is more a question to Jiri Olsa, the author of perf libunwind client.
>> >
>> > it will be configurable for both libunwind and elfutils unwinders,
>> > and making default the one with better results or available
>> >
>> > I should send upstream perf changes within this week
>>
>> Those won't make it into the kernel until 3.8 though.  So for 3.7, I'm
>> thinking we should just disable perf libunwind support entirely.  Once
>> elf-utils gets its unwinder and the patches for perf hit rawhide we can
>> turn it back on.
>
> currently if the libunwind is not found during build time, it's not compiled 
> in

Yes, I'm aware of that.  At the moment, it is found because the library
is in Fedora.  However, I don't want to build 3.7 perf against a library
that is orphaned and clearly not really supported.  So I'm going to
disable it with NO_LIBUNWIND=1 and we can revisit perf with unwind
support for the 3.8 kernel when elf-utils is ready.

Basically, if something better is going to come along the next version
then I really don't see a reason to ship the already obsolete and
orphaned support today.

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

[Bug 876974] CVE-2012-5526 perl-CGI: Newline injection due to improper CRLF escaping in Set-Cookie and P3P headers [fedora-all]

[bugzilla]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=876974

--- Comment #11 from Fedora Update System  ---
perl-CGI-3.52-218.fc17,perl-5.14.3-218.fc17 has been submitted as an update for
Fedora 17.
https://admin.fedoraproject.org/updates/perl-CGI-3.52-218.fc17,perl-5.14.3-218.fc17

-- 
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: Orphaning libunwind

[Jiri Olsa]

On Mon, Nov 26, 2012 at 10:00:52AM -0500, Josh Boyer wrote:
> On Mon, Nov 26, 2012 at 9:41 AM, Jiri Olsa  wrote:
> > On Mon, Nov 26, 2012 at 09:34:35AM -0500, Josh Boyer wrote:
> >> On Mon, Nov 26, 2012 at 9:29 AM, Jiri Olsa  wrote:
> >> >> > If perf winds up getting stuck relying on an orphaned library for some
> >> >> > non-trivial amount of time,
> >> >>
> >> >> AFAIK that is common in Fedora there are orphaned libraries in use for
> >> >> a release or two.
> >> >>
> >> >>
> >> >> > I'd rather just turn off libunwind support in perf now.  It's only 
> >> >> > enabled
> >> >> > in rawhide at the moment because it is a 3.7 feature.  Before we 
> >> >> > bring 3.7
> >> >> > back to f17-f18, we should probably decide.
> >> >>
> >> >> That is more a question to Jiri Olsa, the author of perf libunwind 
> >> >> client.
> >> >
> >> > it will be configurable for both libunwind and elfutils unwinders,
> >> > and making default the one with better results or available
> >> >
> >> > I should send upstream perf changes within this week
> >>
> >> Those won't make it into the kernel until 3.8 though.  So for 3.7, I'm
> >> thinking we should just disable perf libunwind support entirely.  Once
> >> elf-utils gets its unwinder and the patches for perf hit rawhide we can
> >> turn it back on.
> >
> > currently if the libunwind is not found during build time, it's not 
> > compiled in
> 
> Yes, I'm aware of that.  At the moment, it is found because the library
> is in Fedora.  However, I don't want to build 3.7 perf against a library
> that is orphaned and clearly not really supported.  So I'm going to
> disable it with NO_LIBUNWIND=1 and we can revisit perf with unwind
> support for the 3.8 kernel when elf-utils is ready.
> 
> Basically, if something better is going to come along the next version
> then I really don't see a reason to ship the already obsolete and
> orphaned support today.

ok, no problem with that..

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

Re: Splitting out PackageKit-Qt -- help required

[Rex Dieter]

Richard Hughes wrote:

> I'm here asking advice. PackageKit used to ship subpackages of
> PackageKit-glib, PackageKit-glib-devel, PackageKit-qt, and
> PackageKit-qt-devel amoung others.
> 
> Upstream PackageKit-Qt has been split out into another separate
> project as it had different API and ABI promises to PackageKit-glib
> and it was being maintained by another team who wanted to use the
> cmake build system.
> 
> The only application in Fedora that requires PackageKit-qt is apper,
> the package manager we ship in the KDE spin.
> 
> Now, to avoid breaking apper, and the KDE spin, I've tried to be a
> nice maintainer and done a package review for the new package (package
> review most welcome):
> https://bugzilla.redhat.com/show_bug.cgi?id=880155
> 
> I've also done a new PackageKit release in rawhide with the
> PackageKit-qt bits removed.
> 
> So, I need a plan of action and a list of things to provide and
> obsolete in each of the PackageKit.spec, PackageKit-Qt.spec and what
> to require in apper.
> 
> So far, what I'm thinking is that I should have in PackageKit.spec:
> 
> Obsoletes: PackageKit-qt < %{version}-%{release}
> 
> and in PackageKit-Qt.spec I should have:
> 
> Provides: PackageKit-qt
> 
> and then as a belt-and-braces fix also switch apper.spec to
> BuildRequiring PackageKit-Qt-devel rather than PackageKit-qt-devel.

I'll help with the review, if still needed.

Imo, the Obsoletes/Provides should only go in the new and sepearate -qt 
package

-- rex

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

[perl-Rose-DB/f18] Update to 0.770

[Bill Pemberton]

Summary of changes:

  f3696b6... Update to 0.770 (*)

(*) This commit already existed in another branch; no separate mail sent
--
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

File XML-LibXSLT-1.79.tar.gz uploaded to lookaside cache by ppisar

[Petr Pisar]

A file has been added to the lookaside cache for perl-XML-LibXSLT:

92dfd4188353d50f0aa1f848f379914f  XML-LibXSLT-1.79.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

[perl-XML-LibXSLT] 1.79 bump

[Petr Pisar]

commit 0d2419553c088d4164ededed82eabd87b1ffd494
Author: Petr Písař 
Date:   Mon Nov 26 16:27:33 2012 +0100

1.79 bump

 .gitignore|1 +
 perl-XML-LibXSLT.spec |8 +---
 sources   |2 +-
 3 files changed, 7 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 6b58e65..c1de8b5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -7,3 +7,4 @@ XML-LibXSLT-1.70.tar.gz
 /XML-LibXSLT-1.76.tar.gz
 /XML-LibXSLT-1.77.tar.gz
 /XML-LibXSLT-1.78.tar.gz
+/XML-LibXSLT-1.79.tar.gz
diff --git a/perl-XML-LibXSLT.spec b/perl-XML-LibXSLT.spec
index 46501b2..c4a792c 100644
--- a/perl-XML-LibXSLT.spec
+++ b/perl-XML-LibXSLT.spec
@@ -1,6 +1,6 @@
 Name:  perl-XML-LibXSLT
 # NOTE: also update perl-XML-LibXML to a compatible version.  See below why.
-Version:   1.78
+Version:   1.79
 Release:   1%{?dist}
 Summary:   Perl module for interfacing to GNOME's libxslt
 Group: Development/Libraries
@@ -40,10 +40,9 @@ perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE="%{optflags}"
 make %{?_smp_mflags}
 
 %install
-make pure_install PERL_INSTALL_ROOT=%{buildroot}
+make pure_install DESTDIR=%{buildroot}
 find %{buildroot} -type f -name .packlist -exec rm -f {} ';'
 find %{buildroot} -type f -name '*.bs' -a -size 0 -exec rm -f {} ';'
-find %{buildroot} -type d -depth -exec rmdir {} 2>/dev/null ';'
 chmod -R u+w %{buildroot}/*
 
 %check
@@ -56,6 +55,9 @@ make test
 %{_mandir}/man3/*.3*
 
 %changelog
+* Mon Nov 26 2012 Petr Pisar  - 1.79-1
+- 1.79 bump
+
 * Fri Sep 14 2012 Jitka Plesnikova  - 1.78-1
 - 1.78 bump
 
diff --git a/sources b/sources
index f9e1905..2fe71ac 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-ec64aa8025e72171fd15e6e41c454354  XML-LibXSLT-1.78.tar.gz
+92dfd4188353d50f0aa1f848f379914f  XML-LibXSLT-1.79.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

Set fedora-cvs flag?

[Benjamin Kreuter]

Hi everyone,

I am trying to follow the procedure here:

https://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages

But I cannot set the fedora-cvs flag.  Am I missing some sort of
permissions?  What should I do?

Thanks,
Ben



-- 
Benjamin R Kreuter
UVA Computer Science
brk...@virginia.edu
KK4FJZ

--

"If large numbers of people are interested in freedom of speech, there
will be freedom of speech, even if the law forbids it; if public
opinion is sluggish, inconvenient minorities will be persecuted, even
if laws exist to protect them." - George Orwell


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

Re: rawhide report: 20121126 changes

[Mat Booth]

On 26 November 2012 13:10, Fedora Rawhide Report
 wrote:
>
> - no need to drop upstream commits patch as some twat blew it away

Bonus expletives today!


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

Re: Splitting out PackageKit-Qt -- help required

[Richard Hughes]

On 26 November 2012 15:19, Rex Dieter  wrote:
> I'll help with the review, if still needed.

Yes please, all help very welcome. I want to get the new version of PK
into F18 if possible, as it's got quite a few nice fixes that people
want.

> Imo, the Obsoletes/Provides should only go in the new and sepearate -qt
> package

Sure, that's somewhat easier. Something like:

Obsoletes: PackageKit-qt < 0.8.6
Provides: PackageKit-qt = 0.8.6

?

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

Re: Splitting out PackageKit-Qt -- help required

[Toshio Kuratomi]

On Nov 26, 2012 7:39 AM, "Richard Hughes"  wrote:
>
> On 26 November 2012 15:19, Rex Dieter  wrote:
> > Imo, the Obsoletes/Provides should only go in the new and sepearate -qt
> > package
>
> Sure, that's somewhat easier. Something like:
>
> Obsoletes: PackageKit-qt < 0.8.6
> Provides: PackageKit-qt = 0.8.6
>

http://fedoraproject.org/wiki/Packaging:Guidelines#Renaming.2FReplacing_Existing_Packages

So assuming that the split out package has a higher version, the new
package should have

Obsoletes: PackageKit-qt <= 0.8.7 #must be greater than the last nevr so it
has to be one higher version or release number.
Provides: PackageKit-qt = %{version}-%{release}
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

[perl-IO-Tty] Buildrequire perl(Cwd), simplify filters

[Petr Šabata]

commit 986b9b0cbdcd7ceeace3f7000af22d52ff9dca25
Author: Petr Šabata 
Date:   Mon Nov 26 17:07:41 2012 +0100

Buildrequire perl(Cwd), simplify filters

 perl-IO-Tty.spec |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)
---
diff --git a/perl-IO-Tty.spec b/perl-IO-Tty.spec
index 41d378c..56aa7d5 100644
--- a/perl-IO-Tty.spec
+++ b/perl-IO-Tty.spec
@@ -1,12 +1,13 @@
 Name:   perl-IO-Tty
 Version:1.10
-Release:8%{?dist}
+Release:9%{?dist}
 Summary:Perl interface to pseudo tty's
 License:(GPL+ or Artistic) and BSD
 Group:  Development/Libraries
 URL:http://search.cpan.org/dist/IO-Tty/
 Source0:
http://www.cpan.org/authors/id/T/TO/TODDR/IO-Tty-%{version}.tar.gz
 BuildRequires:  perl(Carp)
+BuildRequires:  perl(Cwd)
 BuildRequires:  perl(Exporter)
 BuildRequires:  perl(ExtUtils::MakeMaker)
 BuildRequires:  perl(IO::File)
@@ -14,11 +15,7 @@ BuildRequires:  perl(IO::Handle)
 BuildRequires:  perl(Test::More)
 Requires:   perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 
-# don't "provide" private Perl libs
-%global _use_internal_dependency_generator 0
-%global __deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE}; 
done | /bin/sort -u
-%global __find_provides /bin/sh -c "%{__grep} -v '%_docdir' | %{__grep} -v 
'%{perl_vendorarch}/.*\\.so$' | %{__deploop P}"
-%global __find_requires /bin/sh -c "%{__grep} -v '%_docdir' | %{__deploop R}"
+%{?perl_default_filter}
 
 %description
 IO::Tty and IO::Pty provide an interface to pseudo tty's.
@@ -46,6 +43,9 @@ make test
 %{_mandir}/man3/*.3pm*
 
 %changelog
+* Mon Nov 26 2012 Petr Šabata  - 1.10-9
+- Buildrequire perl(Cwd), simplify filters
+
 * Thu Nov 15 2012 Petr Šabata  - 1.10-8
 - Fix the dependencies
 - Re-enable the test suite
--
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 879963] perl-Rose-DB-0.770 is available

[bugzilla]

Product: Fedora
https://bugzilla.redhat.com/show_bug.cgi?id=879963

--- Comment #2 from Fedora Update System  ---
perl-Rose-DB-0.770-1.fc17 has been submitted as an update for Fedora 17.
https://admin.fedoraproject.org/updates/perl-Rose-DB-0.770-1.fc17

-- 
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: Latest rawhide may destroy /boot

[Eric Sandeen]

On 11/25/12 1:46 PM, darrell pfeifer wrote:
> Last night on my rawhide laptop I installed
> 
> kernel 3.7.0-0.rc6.git4.1.fc19.
> 
> Upon reboot I got a grub shell prompt. Turns out my /boot was empty.

Are you sure it was properly mounted, and you weren't just looking at the empty 
mountpoint?

-Eric

> I've been installing and using pretty much every recent kernel, including the 
> nodebug ones. I notice that I also installed a newer version of dracut a 
> couple of days ago. I'm pretty sure I've installed and run several kernels 
> since the newer dracut, so I'm not sure it is the problem.
> 
> For the record, my workaround was
> 
> Boot an F17 resuce disk
> chroot /mnt/sysimage
> Insert a slightly old F18 disk (that didn't have rescue mode)
> rpm --oldpackage of the kernel and dracut off the F18 disk
> reboot
> 
> darrell
> 
> 

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

Re: LibRaw: possible license issues

[Andrew Haley]

On 11/26/2012 10:14 AM, Debarshi Ray wrote:
> I came across what looks like a possible licensing issue with LibRaw and 
> applications that link to it. I am not totally sure that there is a problem, 
> but I have enough reason to have doubts. I welcome any clarifications and 
> advice.
> 
> LibRaw's License tag was changed from "LGPLv2 or CDDL" to GPLv3 when the two 
> demosaic packs were added [1]. One of the demosaic packs is GPLv2+ and the 
> other is GPLv3+.
> 
> However, http://www.libraw.org/ mentions LibRaw's license as GPLv2+, while 
> the source files continue to claim that they are under LGPLv2 or CDDL.
> 
> Shotwell, which uses LibRaw, is LGPLv2+. By my reading of the compatibility 
> matrix [2], it means that Shotwell is now effectively GPLv3.

If it's linked with a GPLv3+ demosaic pack, it must be GPLv3+.

> If that is the case, then has Yorba been notified of that? I doubt they would 
> suddenly want their code to become GPLv3 instead of LGPLv2+.

Why does it matter?  Their code hasn't changed, and has not become
GPLv3.  The package is GPLv3+.

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

File Rose-DB-Object-0.801.tar.gz uploaded to lookaside cache by wfp

[Bill Pemberton]

A file has been added to the lookaside cache for perl-Rose-DB-Object:

acd603db13869672f018268802558bfb  Rose-DB-Object-0.801.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

[perl-Rose-DB-Object] Update to 0.801

[Bill Pemberton]

commit f25f6ff74216d238ab8da2af024b1319465e83f7
Author: Bill Pemberton 
Date:   Mon Nov 26 11:21:53 2012 -0500

Update to 0.801

 .gitignore   |1 +
 perl-Rose-DB-Object.spec |5 -
 sources  |2 +-
 3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index d7732ea..bfd169a 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
 /Rose-DB-Object-0.798.tar.gz
 /Rose-DB-Object-0.799.tar.gz
 /Rose-DB-Object-0.800.tar.gz
+/Rose-DB-Object-0.801.tar.gz
diff --git a/perl-Rose-DB-Object.spec b/perl-Rose-DB-Object.spec
index ce20957..50440da 100644
--- a/perl-Rose-DB-Object.spec
+++ b/perl-Rose-DB-Object.spec
@@ -1,5 +1,5 @@
 Name:  perl-Rose-DB-Object
-Version:   0.800
+Version:   0.801
 Release:   1%{?dist}
 Summary:   Extensible, high performance object-relational mapper (ORM)
 License:   GPL+ or Artistic
@@ -68,6 +68,9 @@ make test
 %{_mandir}/man3/Rose::DB::Object*.3pm*
 
 %changelog
+* Mon Nov 26 2012 Bill Pemberton  - 0.801-1
+- update to version 0.801
+
 * Mon Sep 10 2012 Bill Pemberton  - 0.800-1
 - update to version 0.800
 
diff --git a/sources b/sources
index 7a62279..4493bd2 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-13839061bf39a30dd56ec30950b05590  Rose-DB-Object-0.800.tar.gz
+acd603db13869672f018268802558bfb  Rose-DB-Object-0.801.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: LibRaw: possible license issues

[Debarshi Ray]

>> If that is the case, then has Yorba been notified of that? I doubt they
>> would suddenly want their code to become GPLv3 instead of LGPLv2+.
> 
> Why does it matter?  Their code hasn't changed, and has not become
> GPLv3.  The package is GPLv3+.

It matters because Shotwell links to GStreamer.

GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions because
they might end up using proprietary or otherwise unfavourably licensed
GStreamer plugins .

Cheers,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


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

Re: rawhide report: 20121126 changes

[Mike Chambers]

On Mon, 2012-11-26 at 15:38 +, Mat Booth wrote:
> On 26 November 2012 13:10, Fedora Rawhide Report
>  wrote:
> >
> > - no need to drop upstream commits patch as some twat blew it away
> 
> Bonus expletives today!

Hahaha such way with words.

-- 
Mike Chambers
Madisonville, KY

"Best little town on Earth!"

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

Re: LibRaw: possible license issues

[Andrew Haley]

On 11/26/2012 04:26 PM, Debarshi Ray wrote:
>>> If that is the case, then has Yorba been notified of that? I doubt they 
>>> would suddenly want their code to become GPLv3 instead of LGPLv2+.
>> 
>> Why does it matter?  Their code hasn't changed, and has not become GPLv3.  
>> The package is GPLv3+.
> 
> It matters because Shotwell links to GStreamer.
> 
> GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions 
> because they might end up using proprietary or otherwise unfavourably 
> licensed GStreamer plugins .

Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.

Andrew.


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

Re: LibRaw: possible license issues

[Debarshi Ray]

>>> Why does it matter?  Their code hasn't changed, and has not become GPLv3.
>>> The package is GPLv3+.
>> 
>> It matters because Shotwell links to GStreamer.
>> 
>> GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions
>> because they might end up using proprietary or otherwise unfavourably
>> licensed GStreamer plugins .
> 
> Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.

You missed the "proprietary or otherwise unfavourably licensed"
part. :-) There are proprietary GStreamer plugins for patent
encumbered formats. eg., the MP3 codecs from Fluendo.

Granted that Fedora does not ship such GStreamer plugins, but some of
our downstreams do. (I don't think I am allowed to get into specifics here.)

Plus, this practice of either using LGPLv2+ or GPLv2+ with exceptions
for applications is so widespread in GStreamer land (Totem, PiTiVi,
Rhythmbox, Transmageddon, etc.) that I was not comfortable with having
a situation where the application silently ends up under a different
license due to another library.

Happy hacking,
Debarshi

-- 
There are two hard problems in computer science: cache invalidation, naming
things and off-by-one errors.


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

Re: LibRaw: possible license issues

[Ralf Corsepius]

On 11/26/2012 07:29 PM, Debarshi Ray wrote:

Why does it matter?  Their code hasn't changed, and has not become GPLv3.
The package is GPLv3+.


It matters because Shotwell links to GStreamer.

GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions
because they might end up using proprietary or otherwise unfavourably
licensed GStreamer plugins .


Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.


You missed the "proprietary or otherwise unfavourably licensed"
part. :-) There are proprietary GStreamer plugins for patent
encumbered formats. eg., the MP3 codecs from Fluendo.


I am not familiar with gstreamer's internals, but AFAIIK, these plugins 
aren't linked, but "dlopen'ed".


Otherwise these "plugins" would not be "plugins" ;)

Ralf

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

Re: LibRaw: possible license issues

[Matthew Garrett]

On Mon, Nov 26, 2012 at 07:40:10PM +0100, Ralf Corsepius wrote:

> I am not familiar with gstreamer's internals, but AFAIIK, these
> plugins aren't linked, but "dlopen'ed".
> 
> Otherwise these "plugins" would not be "plugins" ;)

The difference is an implementation detail, and so depending on it for 
legal purposes is a stretch. However, as far as *we're* concerned, I 
don't think there's a problem - everything we ship would be fine with 
GPLv3, and any additional combinations occur at the user's end. Upstream 
may care due to distributions with different policies, but I don't know 
that that's a discussion we need to have here.

-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Resurrecting deprecated system-config-network package for the time being

[Matthias Clasen]

On Thu, 2012-11-22 at 17:51 +0100, Nils Philippsen wrote:
> Hi,
> 
> as nmcli doesn't yet offer all functionality s-c-network-tui had for
> configuring networks on the command line, I want to resurrect
> system-config-network for the time being, i.e. until nmcli (or other
> tools) fill the gaps. I plan to rip out or otherwise disable the GUI
> side, and merge the -tui subpackage back into the main package.

Whats the functionality that you are missing ?

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

Re: Resurrecting deprecated system-config-network package for the time being

[Simo Sorce]

On Thu, 2012-11-22 at 17:51 +0100, Nils Philippsen wrote:
> Hi,
> 
> as nmcli doesn't yet offer all functionality s-c-network-tui had for
> configuring networks on the command line, I want to resurrect
> system-config-network for the time being, i.e. until nmcli (or other
> tools) fill the gaps. I plan to rip out or otherwise disable the GUI
> side, and merge the -tui subpackage back into the main package.

That would be nice.
Thanks.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

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

Re: LibRaw: possible license issues

[Ralf Corsepius]

On 11/26/2012 07:54 PM, Matthew Garrett wrote:

On Mon, Nov 26, 2012 at 07:40:10PM +0100, Ralf Corsepius wrote:


I am not familiar with gstreamer's internals, but AFAIIK, these
plugins aren't linked, but "dlopen'ed".

Otherwise these "plugins" would not be "plugins" ;)


The difference is an implementation detail, and so depending on it for
legal purposes is a stretch.


Well, dlopen'ed modules/plugins aren't directly linked, i.e. there is 
only an indirect dependency. AFAICT (IANAL), this is what makes the 
legal key-difference. However, it likely would require to have a 
precedent at court to have this topic clarified, because I am also aware 
there are people who do not share my view ;)



However, as far as *we're* concerned, I
don't think there's a problem - everything we ship would be fine with
GPLv3, and any additional combinations occur at the user's end. Upstream
may care due to distributions with different policies, but I don't know
that that's a discussion we need to have here.

Agreed.

Ralf


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

Re: Resurrecting deprecated system-config-network package for the time being

[Dan Williams]

On Mon, 2012-11-26 at 14:08 -0500, Matthias Clasen wrote:
> On Thu, 2012-11-22 at 17:51 +0100, Nils Philippsen wrote:
> > Hi,
> > 
> > as nmcli doesn't yet offer all functionality s-c-network-tui had for
> > configuring networks on the command line, I want to resurrect
> > system-config-network for the time being, i.e. until nmcli (or other
> > tools) fill the gaps. I plan to rip out or otherwise disable the GUI
> > side, and merge the -tui subpackage back into the main package.
> 
> Whats the functionality that you are missing ?

We've had a number of requests for the pseudo-graphical hand-holding
network configuration editing functionality of system-config-tui in the
past few years.  That's what nmcli is missing right now.

The plan of record for F19 (though not yet in a Feature Page) is to
enhance nmcli to provide most of this functionality, but we won't be
doing that with ncurses the way system-config-tui does.  I'd expect this
new feature to replace most all of the use-cases that system-config-tui
is useful for, so perhaps we should shelve this for another month or two
until we have a better idea of when the nmcli stuff will land?

Dan

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

Re: Set fedora-cvs flag?

[Matej Cepl]

Dne 26/11/12 16:29, Benjamin Kreuter napsal(a):
> Hi everyone,
> 
> I am trying to follow the procedure here:
> 
> https://fedoraproject.org/wiki/Package_SCM_admin_requests#Package_Change_Requests_for_existing_packages
> 
> But I cannot set the fedora-cvs flag.  Am I missing some sort of
> permissions?  What should I do?

Right above the line in the middle of the bug report page is Group named
"Flags" with a small link "(edit)". Click on it and you'll get of flags
which can be set. Find the "fedora-cvs" and set it to "?".

Matěj


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

Re: LibRaw: possible license issues

[Chris Adams]

Once upon a time, Ralf Corsepius  said:
> Well, dlopen'ed modules/plugins aren't directly linked, i.e. there is 
> only an indirect dependency. AFAICT (IANAL), this is what makes the 
> legal key-difference.

IANAL either, but neither is what matters in the legal sense; "derived
work" is what matters.  Linking is just an indicator (that is not 100%)
of a derived work.

As for when the linking is done, (static at build, dynamic at load,
dynamic during run), that makes zero difference as to whether something
is a derived work.

-- 
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: Heads up: rpm 4.11 alpha coming soon to rawhide near you

[Jon Ciesla]

On Fri, Nov 23, 2012 at 8:43 PM, Orion Poplawski wrote:

> On 11/22/2012 10:07 PM, Ben Boeckel wrote:
>
>> On Tue, Nov 20, 2012 at 18:15:26 GMT, Jon Ciesla wrote:
>>
>>> On Tue, Nov 20, 2012 at 12:08 PM, Panu Matilainen <
>>> pmati...@laiskiainen.org> wrote:
>>>
 -- Build files have been written to: /builddir/build/BUILD/wesnoth-
 1.10.5
 Scanning dependencies of target mo-update
 [  0%] mo-update [zh_TW]: Creating locale directory.
 [  0%] mo-update [af]: Creating locale directory.
 [  0%] mo-update [ang]: Creating locale directory.
 [  0%] mo-update [ang@latin]: Creating locale directory.
 [  0%] mo-update [ar]: Creating locale directory.
 [  0%] Scanning dependencies of target wesnoth-lua

 ...but in the f19 build, no such thing occurs:
 -- Build files have been written to: /builddir/build/BUILD/wesnoth-
 1.10.5
 Scanning dependencies of target wesnoth-lua
 [  0%] Scanning dependencies of target wesnoth-core
 [...]

 I thought not, but wanted to be sure.  It certainly f19-centric.
  Thanks!

>>>
>>> And if anyone see something obvious here let me know.
>>>
>>
>> It's missing a VERBOSE=1 parameter to make (or the appropriate parameter
>> to CMake which I can't remember off the top of my head) to show the
>> actual commands being run.
>>
>>
> If you use the %cmake macro, you'll get verbose builds.
>
>  Other than that, F19 has CMake 2.8.10.1 and F18 has 2.8.9. If using
>> CMake 2.8.9 works, it should be reported upstream as a regression.
>>
>> --Ben
>>
>>
> Must be cmake, switching to scons worked.  Orion, what do you want to see
in a bug report?

-J

>
> --
> Orion Poplawski
> Technical Manager 303-415-9701 x222
> NWRA/CoRA DivisionFAX: 303-415-9702
> 3380 Mitchell Lane  or...@cora.nwra.com
> Boulder, CO 80301  http://www.cora.nwra.com
> --
> devel mailing list
> devel@lists.fedoraproject.org
> https://admin.fedoraproject.**org/mailman/listinfo/devel




-- 
http://cecinestpasunefromage.wordpress.com/

in your fear, seek only peace
in your fear, seek only love

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

Re: LibRaw: possible license issues

[Andrew Haley]

On 11/26/2012 06:29 PM, Debarshi Ray wrote:
 Why does it matter?  Their code hasn't changed, and has not become GPLv3. 
 The package is GPLv3+.
>>> 
>>> It matters because Shotwell links to GStreamer.
>>> 
>>> GStreamer applications either opt for LGPLv2+ or GPLv2+ with exceptions 
>>> because they might end up using proprietary or otherwise unfavourably 
>>> licensed GStreamer plugins .
>> 
>> Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.
> 
> You missed the "proprietary or otherwise unfavourably licensed" part. :-) 
> There are proprietary GStreamer plugins for patent encumbered formats. eg., 
> the MP3 codecs from Fluendo.
> 
> Granted that Fedora does not ship such GStreamer plugins, but some of our 
> downstreams do. (I don't think I am allowed to get into specifics here.)

OK, so there are some proprietary or otherwise encumbered plugins
that might not be GPLv3-compatible but might be compatible with GPLv2.
And you're worried that some unwitting user might by mistake break
the terms of a licence.  Or, perhaps, some downstream might not be
able to ship a plugin because they fear it's not allowed.

> Plus, this practice of either using LGPLv2+ or GPLv2+ with exceptions for 
> applications is so widespread in GStreamer land (Totem, PiTiVi, Rhythmbox, 
> Transmageddon, etc.) that I was not comfortable with having a situation where 
> the application silently ends up under a different license due to another 
> library.

I don't think that's a problem because the whole purpose of the
"or any later version of the GPL, at your choice" is to allow
the GPL to be updated.

Andrew.

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

Re: Network interface renaming, where does INTERFACE_NAME get applied?

[Bill Nottingham]

Dan Williams (d...@redhat.com) said: 
> > > I see that initscripts in F18 ships this udev rule:
> > > 
> > > ACTION=="add", SUBSYSTEM=="net", PROGRAM="/lib/udev/rename_device",
> > > RESULT=="?*", ENV{INTERFACE_NAME}="$result"
> > > 
> > > I'm trying to tackle some problems related to interface renaming, and
> > > understanding how this works would be useful.
> > > 
> > > But I can't find which software component *applies* the INTERFACE_NAME
> > > variable set by the above rule, actually performing the interface
> > > rename. Can you explain?
> > > 
> > > FYI, I would imagine this area will also be susceptible to a current
> > > udev bug, https://bugs.freedesktop.org/show_bug.cgi?id=56929
> > 
> > IIRC support INTERFACE_NAME is gone for quite a while since udev stopped
> > to provide implicit permenanet naming since it was a trainwreck. People
> > should use biosdevname instead.
> 
> Which doesn't work for USB devices, in which case you have to write
> manual rules to do the rename.  And when you do, please make sure you
> rename the interface somewhere *not* in the kernel namespace, which
> means don't use "ethX", "usbX", "wwanX", "wlanX", etc.  Otherwise you'll
> race with the kernel when discovering network devices, and the rename
> will fail.

So what rename_device is trying to do here is to support naming specified
in the ifcfg files (i.e., admin-specified configuration). While it could
have issues while it's in the kernel namespace, it's best to at least try
and support it. I've committed (but not yet built) a patch to initscripts
so it will attempt to set the name here.

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

FESCo town hall: November 27 1700UTC

[Ankur Sinha]

Hi folks,

A gentle reminder that the FESCo town hall session for the F19 elections
is at 1700UTC on November 27[1][2]. It's a good chance to question the
candidates[3] before you cast your votes at the ballot. 

I hope to see you there.

More information on the elections can be found here[3].

PS: The initial announcement had the date wrong. A correction has been
sent out. 

[1] https://fedoraproject.org/wiki/Elections#FESCo_.28Engineering.29
[2]
http://timeanddate.com/worldclock/fixedtime.html?year=2012&month=11&day=27&hour=17&min=00&sec=0
[3] https://fedoraproject.org/wiki/Elections
-- 
Thanks, 
Warm regards,
Ankur: "FranciscoD"

Please only print if necessary. 

Looking to contribute to Fedora? Look here: 
https://fedoraproject.org/wiki/Fedora_Join_SIG

http://fedoraproject.org/wiki/User:Ankursinha
http://dodoincfedora.wordpress.com/


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: Orphaning libunwind

[Lennart Poettering]

On Mon, 26.11.12 11:23, Mat Booth (fed...@matbooth.co.uk) wrote:

> On 24 November 2012 07:40, Jan Kratochvil  wrote:
> > Hi,
> >
> > as elfutils package is going to contain unwinder in its next release 
> > orphaning
> > the libunwind library.
> >
> > https://admin.fedoraproject.org/pkgdb/acls/name/libunwind

Hmm, libunwind can now unwind coredumps. Can elfutils do that too?

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

need help with a package

[Alexander Aristotle Davis]

Hi,

A package called rssh has been marked as duplicate on Bugzilla and I am 
working on a 2.3.3 version and would like to update it to a new 
release.  Could you please inform me why this package have been orphaned.


I am not a packager; I am seeking a sponsor to help me review the file.

Thank you

Alex


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

Re: Orphaning many packages

[Ralph Bean]

On Mon, Nov 26, 2012 at 04:08:22PM -0800, Jesse Keating wrote:
> python-offtrac

I'll take this one!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning libunwind

[Toshio Kuratomi]

On Nov 26, 2012 8:22 AM, "Jan Kratochvil"  wrote:
>
> On Mon, 26 Nov 2012 14:00:17 +0100, Josh Boyer wrote:

> > If perf winds up getting stuck relying on an orphaned library for some
> > non-trivial amount of time,
>
> AFAIK that is common in Fedora there are orphaned libraries in use for
> a release or two.
>
It is somewhat common but not really what we want by design.  There's an
inherent race between something being orphaned and getting it out of the
repositories.

*once a package has been released for users we have no way to remove it.
So, at present you could get rid of this for f18+ but we'd keep it for f17
and less even if it was orphaned.
* we retire orphaned packages and block them from the repositories once a
cycle.  But if you orphan the package after we do that for this cycle it
will not get blocked unless you explicitly request it.

But these are just implementation.  Ideally we want every package that gets
released to the users to have a maintainer that is watching bug reports and
attempting to fix anything serious.

So if you know you aren't going to fix bugs for this package in f19, the
best answer is to block this package from f19 and get those packages that
currently depend on it to stop doing so (by disabling features or porting
to something else.) (And not necessarily in that order.) If you wanted to
do this for f18 as well it might be a little late since it's something that
requires cooperation with multiple packages.

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

Re: need help with a package

[Jon VanAlten]

- Original Message -
> From: "Alexander Aristotle Davis" 
> To: devel@lists.fedoraproject.org
> Sent: Monday, November 26, 2012 8:03:17 PM
> Subject: need help with a package
> 
> Hi,
> 
> A package called rssh has been marked as duplicate on Bugzilla and I
> am
> working on a 2.3.3 version and would like to update it to a new
> release.  Could you please inform me why this package have been
> orphaned.

Hi Alex,

First, welcome to Fedora-land

A little bit of searching goes a long way!  It seems the prior
maintainer orphaned it because it is dead upstream, contains a
known security flaw, upstream doesn't want to put effort into it,
and the old maintainer has no wish to fix the bug himself or
herself[1][2].  So, there in fact is no new release for this
software; the packages currently in fedora are the most current
version.

If you'd like to keep the package alive, I'd focus first on
fixing the security bug; getting the changes into the Fedora
package will be a simple matter, and you can get help for that
here when the time comes  If you have a fix for the security
bug, you may even be able to convince some existing maintainer
to adopt the package, with some assurance that you'll continue
to support it if other bugs are found.

In order for you to take over package maintenance yourself, you
will need to join the packager group[3].  If you want to get
sponsored by adding a new package to fedora, you'll have to find
a different one than rssh since (as you've found out) this
already exists in Fedora.

One comment about the spec you posted for review[4], even though
package review is not what is needed here I had a look anyways.
It seems like the main difference from existing spec in git is
the change in URL.  I'll just point out that, even though upstream
is not actively developing this software, changing the URL from
the upstream page to an empty wiki page seems not to be the best
idea.

Good luck!

jon

[1] http://lists.fedoraproject.org/pipermail/devel/2012-May/166874.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=820415
[3] https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group
[4] https://bugzilla.redhat.com/show_bug.cgi?id=879954
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Orphaning libunwind

[Jan Kratochvil]

On Mon, 26 Nov 2012 23:44:24 +0100, Lennart Poettering wrote:
> On Mon, 26.11.12 11:23, Mat Booth (fed...@matbooth.co.uk) wrote:
> > On 24 November 2012 07:40, Jan Kratochvil  wrote:
> > > Hi,
> > >
> > > as elfutils package is going to contain unwinder in its next release 
> > > orphaning
> > > the libunwind library.
> > >
> > > https://admin.fedoraproject.org/pkgdb/acls/name/libunwind
> 
> Hmm, libunwind can now unwind coredumps. Can elfutils do that too?

Yes:

https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002748.html
+/* Get innermost frame of first thread of core file COREFILE.  Returns NULL on
+   failure.  */
+extern Dwfl_Frame_State *dwfl_frame_state_core (Dwfl *dwfl,
+   const char *corefile);
Tested on core files generated in tests/run-backtrace.sh.

For non-x86* there are testcases (also via tests/run-backtrace.sh):

https://lists.fedorahosted.org/pipermail/elfutils-devel/2012-November/002752.html
* backtrace.ppc.core.bz2: New file.
* backtrace.ppc.exec.bz2: New file.
* backtrace.ppc64.core.bz2: New file.
* backtrace.ppc64.exec.bz2: New file.
* backtrace.s390.core.bz2: New file.
* backtrace.s390.exec.bz2: New file.
* backtrace.s390x.core.bz2: New file.
* backtrace.s390x.exec.bz2: New file.


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

Re: Orphaning libunwind

[Jan Kratochvil]

On Tue, 27 Nov 2012 02:48:00 +0100, Toshio Kuratomi wrote:
> But these are just implementation.  Ideally we want every package that gets
> released to the users to have a maintainer that is watching bug reports and
> attempting to fix anything serious.

There are serious bugs so that some cases are not properly unwound but nobody
has reported it in Fedora BZ yet.  And one of the reasons of the elfutils
extension was exactly to fix it.

I understand the formal rules in this case.  But do you think I will be fixing
known bugs in libunwind which were the reason I wrote the elfutils extension?

Maybe we should make a difference between functionality of the package
(unwinding) and its packaging; there may happen some issues with packaging
which are easy to fix in general and which I can do.  I have taken the
ownership back but (a) only for the packaging kind of bugs and
(b) only for f16+f17+f18, not for f19.


> So if you know you aren't going to fix bugs for this package in f19, the
> best answer is to block this package from f19 and get those packages that
> currently depend on it to stop doing so (by disabling features or porting
> to something else.)

gperftools remains unsolved in this regard.  I do not know more about it now.


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

Re: LibRaw: possible license issues

[Bastien Nocera]

On Mon, 2012-11-26 at 20:13 +, Andrew Haley wrote:
> On 11/26/2012 06:29 PM, Debarshi Ray wrote:
>  Why does it matter?  Their code hasn't changed, and has not become 
>  GPLv3. The package is GPLv3+.

If the license of libraw changed significantly, the libraw package
should be updated to reflect the true license of the combined work.

In this case, it's the package maintainer that added the flags:
--enable-demosaic-pack-gpl2 --enable-demosaic-pack-gpl3

If you want to keep shotwell with the same "combined work" license,
either revert those changes, or get a version of LibRaw without demosaic
compiled-in packaged.

> >>> It matters because Shotwell links to GStreamer.
> >>> 
> >>> GStreamer applications either opt for LGPLv2+ or GPLv2+ with
> exceptions because they might end up using proprietary or otherwise
> unfavourably licensed GStreamer plugins .
> >> 
> >> Which is fine, because GPLv3+ is compatible with LGPLv2+ or GPLv2+.
> > 
> > You missed the "proprietary or otherwise unfavourably licensed"
> part. :-) There are proprietary GStreamer plugins for patent
> encumbered formats. eg., the MP3 codecs from Fluendo.
> > 
> > Granted that Fedora does not ship such GStreamer plugins, but some
> of our downstreams do. (I don't think I am allowed to get into
> specifics here.)
> 
> OK, so there are some proprietary or otherwise encumbered plugins
> that might not be GPLv3-compatible but might be compatible with GPLv2.

No, they would be compatible with the LGPLv2, or with a GPLv2 +
exception.

> And you're worried that some unwitting user might by mistake break
> the terms of a licence.  Or, perhaps, some downstream might not be
> able to ship a plugin because they fear it's not allowed.
> 
> > Plus, this practice of either using LGPLv2+ or GPLv2+ with
> exceptions for applications is so widespread in GStreamer land (Totem,
> PiTiVi, Rhythmbox, Transmageddon, etc.) that I was not comfortable
> with having a situation where the application silently ends up under a
> different license due to another library.
> 
> I don't think that's a problem because the whole purpose of the
> "or any later version of the GPL, at your choice" is to allow
> the GPL to be updated.

It's (LGPLv2+) and (GPLv2+ with exception) that's compatible with
proprietary plugins. Naked GPL isn't.

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