Re: Fedora-Review 0.2.0

2012-08-01 Thread Mathieu Bridon
On Wed, 2012-08-01 at 23:52 -0600, Nathanael D. Noblet wrote:
> Where would you like bug reports?
> 
> I tried it against one of my own review tickets. It found a number of 
> issues however almost all of them except one was wrong.
> 
> For example it complained of no clean section with a rm -rf %{buildroot} 
> which the specfile contained, same message except in the install section 
> etc.

Are you sure it wasn't complaining that the specfile actually contained
those lines?

The Fedora guidelines say those lines are not needed, and shouldn't be
there for new packages, unless the package maintainer wants to ensure
compatibility with EPEL 5.

So that's what Fedora Review (usually, I haven't tried for your specific
review) reports.


-- 
Mathieu


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

Re: Fedora-Review 0.2.0

2012-08-01 Thread Nathanael D. Noblet

Where would you like bug reports?

I tried it against one of my own review tickets. It found a number of 
issues however almost all of them except one was wrong.


For example it complained of no clean section with a rm -rf %{buildroot} 
which the specfile contained, same message except in the install section 
etc.


To try it out yourself try it against bug 841662

--
Nathanael d. Noblet
t 403.875.4613
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)

2012-08-01 Thread Akira TAGOH
- 元のメッセージ -
| Our default font set for most languages, DejaVu, ships carefully
| designed
| hinting bytecode written specifically for FreeType's bytecode
| interpreter,
| and its designers explicitly ask for it to be used rather than the
| autohinter. (Some people dislike the font's look with the hinting,
| but it is
| how the designers intended it to look.)

Sure. I'm not saying that there are no well-hinted fonts in free fonts. I'd 
respect their efforts.

Anyway, as I planned to prepare some references for comparison, I've done and 
put them at http://tagoh.fedorapeople.org/tmp/hints/. all.tar.xz may helps to 
see all smoothly on your machine.

I used pango-view this time to avoid the out of alignment on taking a 
screenshot as far as possible for easy comparison and to reduce the workload. 
also disabled most fontconfig rules at /etc/fonts/conf.d to avoid the 
side-effects of them on this testing because the user fonts.conf can't override 
it if it's changed after 50-user.conf. and only picked up the fonts packages 
installed by default.

My feeling on this testing is fifty-fifty to determine which should be better 
for default. there are some fonts that hinting is totally broken, and partly 
broken that depends on the pixel size. of course well-hinted fonts and no 
changes because of maybe no hinting or using ttfautohint perhaps.
Having said, from any possibilities that there may be the case other fonts 
can't get a win to be default because of its quality (of course it may be not 
necessarily the case), I'm still thinking that enabling autohinting by default 
may helps a lot.

FWIW I'm about to add a feature of hinting related things in fonts-tweak-tool 
so even if something goes wrong for self-installed fonts by users say, they can 
change it easily as needed.

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

Fedora ARM weekly status meeting minutes 2012-08-01

2012-08-01 Thread Paul Whalen
Good day all,

Thanks to those who were able to join us for the weekly status meeting today. 
For those that were unable, the minutes are posted below:

Minutes: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-08-01/fedora-meeting-1.2012-08-01-20.01.html
Minutes (text): 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-08-01/fedora-meeting-1.2012-08-01-20.01.txt
Log: 
http://meetbot.fedoraproject.org/fedora-meeting-1/2012-08-01/fedora-meeting-1.2012-08-01-20.01.log.html

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Sérgio Basto
On Qua, 2012-08-01 at 00:36 +0200, Kevin Kofler wrote: 
> I wrote:
> > I'm looking into these:
> > 
> > Bill Nottingham wrote:
> >> Package komparator (fails to build)
> >> Package krecipes (fails to build)
> >> Package qalculate-kde (fails to build)
> >> Package tesseract (fails to build)
> 
> I fixed these 4 packages now.
> 
> Note that krecipes and tesseract both have newer upstream versions 
> available:
> * krecipes:
>   - current in Fedora: 1.0-beta2 (kdelibs3)
>   - current upstream: 2.0-beta2 (kdelibs4)
>   Note that this will need significant packaging changes, being a KDE
>   Platform 4 app now (whereas the current Fedora specfile is for the
>   old kdelibs3 version).
> * tesseract:
>   - current in Fedora: 3.00
>   - current upstream: 3.01 (new features, bugfixes etc.)
> It looks like they both could use a new (co)maintainer.
> 
> For komparator and qalculate-kde, the respective kdelibs3-based versions 
> currently in Fedora are the latest (last?) upstream versions though. :-(

Hi,

repoquery -q  qalculate-kde  komparator 
komparator-0:0.9-5.fc15.x86_64
qalculate-kde-0:0.9.7-3.fc15.x86_64


Since komparator and qalculate-kde was not rebuild in F17. Shouldn't we
also update F17 ? at least.  

Thanks,
-- 
Sérgio M. B.

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

[Guidelines Change] Changes to the Packaging Guidelines

2012-08-01 Thread Tom Callaway
Here are the latest set of changes to the Fedora Packaging Guidelines:

---

A new section has been added to the SysV Initscripts section, discussing
the proper use of subsys locking. Even though Fedora packages should no
longer be using SysV Initscripts as a primary service mechanism, Red Hat
Enterprise Linux and EPEL do. Additionally,
Red Hat points partners to the Fedora Guidelines when they build for RHEL.

https://fedoraproject.org/wiki/Packaging:SysVInitScript#Careful_Handling_of_.2Fvar.2Flock.2Fsubsys.2F.3Cservice_name.3E_mechanism

---

The review guidelines now reflect the use of sha256sum (instead of
md5sum) to confirm upstream source integrity.

https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Things_To_Check_On_Review

---

The PHP Packaging guidelines have been updated to include guidance about
when it is appropriate to have an explicit Requires on httpd & mod_php,
how to handle explicit Requires on PHP extensions, and how to handle a
Requires for a minimum PHP version.

https://fedoraproject.org/wiki/Packaging:PHP#Apache_requirement
https://fedoraproject.org/wiki/Packaging:PHP#Extensions_Requires
https://fedoraproject.org/wiki/Packaging:PHP#Requiring_a_Minimum_PHP_version

---

A new section on Macros has been added to the Packaging Guidelines,
covering Packaging of Additional RPM Macros.

https://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_of_Additional_RPM_Macros

---

A new section on the Documentation= field in systemd unit files (F17+)
has been added.

https://fedoraproject.org/wiki/Packaging:Systemd#Documentation_field

---

A short section on the Group tag in Fedora packages has been added.
All current versions of Fedora (and their respective RPM versions) treat
the Group tag as optional. Packages may include a Group: field for
compatibility with EPEL, but are not required to do so.

https://fedoraproject.org/wiki/Packaging:Guidelines#Group_tag

---

The RHEL conditionalization has been removed from the Python3 example
spec file, as it is no longer valid.

https://fedoraproject.org/wiki/Packaging:Python#Example_spec_file

---

These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).

Many thanks to Remi Collet, David Malcolm, Vit Ondruch, Lennart
Poettering, Michael Scherer, Dave Sullivan, and all of the members of
the FPC, for assisting in drafting, refining, and passing these guidelines.

As a reminder: The Fedora Packaging Guidelines are living documents! If
you find something missing, incorrect, or in need of revision, you can
suggest a draft change. The procedure for this is documented here:
https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure

Thanks,

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Tom Lane
Tom Callaway  writes:
> On 08/01/2012 10:03 AM, Tom Lane wrote:
>> What this means, IMO, is that we need to split out libpng12 as a
>> separate package.  The current hack that I'm using (bundling 1.2 and 1.5
>> into a single SRPM) was never meant to be more than a very short-term
>> stopgap; I'm sure it violates all sorts of packaging guidelines.

> Rather than working around the review process, just go ahead and make
> the package, upload it somewhere, open a review ticket, and I'll review
> it after lunch today. I'm familiar with that package, so it should be a
> very quick review for me to complete, and the branching request should
> be able to be processed today.

Thanks for offering!  Review request is in bug #845110

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Use AutoQA to track changes in "provides" and "requires"?

2012-08-01 Thread Adam Williamson
On Wed, 2012-08-01 at 11:17 -0500, Richard Shaw wrote:
> On Wed, Aug 1, 2012 at 10:37 AM, Kamil Paral  wrote:
> > Something like this? [1] [2]
> 
> Yup! Something a lot like that! I did look over the AutoQA wiki before
> posting but didn't know enough about rpmguard to know that where I
> needed to look :)
> 
> 
> > We already do that in the form of 'rpmguard' test [3]. Currently you have 
> > to sign-up manually to receive rpmguard/rpmlint results for new package 
> > builds [4].
> 
> So you have to subscribe per package per release? I don't necessarily
> want them emailed to me but accessible somewhere would be nice.

All AutoQA results can be accessed via resultsdb:

http://autoqa.fedoraproject.org/resultsdb/frontend

You can do a search for a specific package and/or test case. On the
search page - http://autoqa.fedoraproject.org/resultsdb/frontend/search
- 'Envr' seems to be the place to put the package name. So if you put
'kernel' in the 'Envr' box, and 'rpmguard' in the 'Testcase' box, and
hit search, you get all the rpmguard tests for kernel package builds.

Kamil, perhaps the search interface could be made a bit friendlier? A
better name for the field than 'Envr', whatever the heck that's supposed
to mean? A drop-down list for 'testcase', rather than free text?
Friendly unicorn pictures? :)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

[Bug 845057] Review Request: perl-Sub-Exporter-Progressive - Only use Sub::Exporter if you need it

2012-08-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=845057

Paul Howarth  changed:

   What|Removed |Added

 CC||perl-devel@lists.fedoraproj
   ||ect.org

--- Comment #1 from Paul Howarth  ---
New upstream release:

Spec URL:
http://subversion.city-fan.org/repos/cfo-repo/perl-Sub-Exporter-Progressive/branches/fedora/perl-Sub-Exporter-Progressive.spec

SRPM URL:
http://www.city-fan.org/~paul/extras/perl-Sub-Exporter-Progressive/perl-Sub-Exporter-Progressive-0.001003-1.fc18.src.rpm

-- 
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: Provenpackager help needed to complete libpng/libtiff transition

2012-08-01 Thread Jon Ciesla
On Wed, Aug 1, 2012 at 12:53 AM, Tom Lane  wrote:
> There are still about half a dozen packages left that failed the recent
> mass rebuild because they contain source-code dependencies on obsolete
> versions of libpng and/or libtiff.  I've filed patches to fix them,
> but don't have permissions to do it myself.  If any provenpackagers
> have a bit of time to spare, could I pester you to look at these bugs?
>
> Pixie   843294
> dcmtk   819236
> fuse-emulator   843645
> grace   843647
> gshutdown   843648
> luakit  843652
> pngnq   843655
> tucnak2 843658

These are done.

-J

> Thanks!
>
> regards, tom lane
> --
> 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

[Bug 841133] CVE-2012-1151 perl-DBD-Pg: Format string flaws by turning db notices into Perl warnings and by preparing DBD statement [fedora-all]

2012-08-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=841133

--- Comment #6 from Fedora Update System  ---
perl-DBD-Pg-2.19.2-1.fc17 has been pushed to the Fedora 17 stable repository. 
If problems still persist, please make note of it in this bug report.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel

[Bug 840288] perlbrew-0.46 is available

2012-08-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=840288

--- Comment #6 from Fedora Update System  ---
perlbrew-0.46-1.fc17 has been pushed to the Fedora 17 stable repository.  If
problems still persist, please make note of it in this bug report.

-- 
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: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Jóhann B. Guðmundsson

On 08/01/2012 04:48 PM, Nicola Soranzo wrote:

bcfg2-server


I dont think it's necessary for it to depend on redhat-lsb-desktop 
anymore since that package has move to using unit files instead..


JBG

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

Re: [fedora-arm] Fedora ARM weekly status meeting 2012-08-01

2012-08-01 Thread Peter Robinson
On Wed, Aug 1, 2012 at 6:19 PM, Paul Whalen  wrote:
> Good day all,
>
> This weeks Fedora ARM status meeting will take place today (Wednesday Aug 
> 1st) in #fedora-meeting-1 on Freenode.
> Times in various time zones (please let us know if these do not work):
>
> PDT: 1pm
> MDT: 2pm
> CDT: 3pm
> EDT: 4pm
> UTC: 8pm
> BST: 9pm
> CST: 10pm
>
> Current items on the agenda:
>
> 1) F18 - Mass rebuild status
>- Defining release criteria for F18

I think we should be aiming for all that is required for a Primary
Arch promotion. If we don't meet that we're screwed for point 2.

>- F18 Alpha Release
>
> 2) Primary Architecture push

2.1 ) Enterprise HW status for koji build platform
2.2 ) Documentation status update
2.3 ) package build status
2.4 ) Status update on QA and QA process

> 3) Raspberry Pi Remix Update
>
> 4) Your topic here
>
> If you have any other items you would like to discuss that are not mentioned, 
> please feel free to send an email to the list or bring it up at the end of 
> the meeting.
>
> Paul
> ___
> arm mailing list
> a...@lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora ARM weekly status meeting 2012-08-01

2012-08-01 Thread Paul Whalen
Good day all,

This weeks Fedora ARM status meeting will take place today (Wednesday Aug 1st) 
in #fedora-meeting-1 on Freenode.
Times in various time zones (please let us know if these do not work):

PDT: 1pm
MDT: 2pm
CDT: 3pm
EDT: 4pm
UTC: 8pm
BST: 9pm
CST: 10pm

Current items on the agenda:

1) F18 - Mass rebuild status
   - Defining release criteria for F18
   - F18 Alpha Release
   
2) Primary Architecture push 

3) Raspberry Pi Remix Update

4) Your topic here

If you have any other items you would like to discuss that are not mentioned, 
please feel free to send an email to the list or bring it up at the end of the 
meeting.

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Jóhann B. Guðmundsson

On 08/01/2012 10:21 AM, Richard Hughes wrote:

On 1 August 2012 10:47, Rahul Sundaram  wrote:

>Fedora is not LSB compatible.  Is it?  Why do we even care about this at
>all?

I think I can speak for most of the core GNOME desktop developers and
state that we don't care about LSB one little bit.


Is not lsb as outdated as the rest of those so called standards?

Btw should not this package be called fedora-lsb-desktop or 
system-lsb-desktop...


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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Nicola Soranzo
Il giorno mer, 01/08/2012 alle 09.51 -0400, Adam Jackson ha scritto: 
> > Fedora is not LSB compatible.  Is it?  Why do we even care about this at
> > all?
> 
> It is if you install redhat-lsb.
> 
> The only intrinsic reason to care about LSB support is binary 
> compatibility; Fedora broadly doesn't, but that doesn't mean it's not a 
> useful end.  Personally I've definitely had occasion to need older 
> builds of things like boost and openssl on newer Fedora releases.
> 
> repoquery is also telling me there are things in Fedora that _do_ 
> require redhat-lsb, at least in F16.  I can't speak to the particulars 
> there, you'd need to look into that per-package.

In rawhide, the packages requiring redhat-lsb are:

bcfg2-server
rear
tomcat6

HTH,
Nicola

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Rahul Sundaram
On 08/01/2012 09:45 PM, Bill Nottingham wrote:

> 
> I can see assorted ways we could theoretically handle a desire to remove
> libpng 1.2 from the distribution, but merely dropping the req from
> redhat-lsb is the obviously wrong answer. 

Right.  I was obviously not suggesting it but perhaps dropping the LSB
package itself would be a appropriate move

Rahul

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

Re: Use AutoQA to track changes in "provides" and "requires"?

2012-08-01 Thread Richard Shaw
On Wed, Aug 1, 2012 at 10:37 AM, Kamil Paral  wrote:
> Something like this? [1] [2]

Yup! Something a lot like that! I did look over the AutoQA wiki before
posting but didn't know enough about rpmguard to know that where I
needed to look :)


> We already do that in the form of 'rpmguard' test [3]. Currently you have to 
> sign-up manually to receive rpmguard/rpmlint results for new package builds 
> [4].

So you have to subscribe per package per release? I don't necessarily
want them emailed to me but accessible somewhere would be nice.

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Bill Nottingham
Rahul Sundaram (methe...@gmail.com) said: 
> On 08/01/2012 01:06 PM, Adam Williamson wrote:
> 
> > Well, that's really it. The format of LSB is a bit odd to a lay reader,
> > but AFAICT, it really does mean: to be technically in compliance with
> > LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
> > functions. End of story. I don't see a workaround.
> 
> Fedora is not LSB compatible.  Is it?  Why do we even care about this at
> all?

If we are providing a redhat-lsb package that provides the requirements
specified in the LSB, it should be correct.

I can see assorted ways we could theoretically handle a desire to remove
libpng 1.2 from the distribution, but merely dropping the req from
redhat-lsb is the obviously wrong answer. 

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Bill Nottingham
Nikola Pajkovsky (npajk...@redhat.com) said: 
> Bill Nottingham  writes:
> 
> > Before we branch for Fedora 18, as is custom, we will block currently
> > orphaned packages and packages that have failed to build since Fedora 16.
> >
> > The following packages are currently orphaned, or fail to build. If
> > you have a need for one of these packages, please pick them up.
> > If no one claims any of these packages, they will be blocked before
> > we branch for Fedora 18. We will block these packages on Monday, August 06.
> >
> > Note that if you're receiving this mail directly, it's because you are
> > a co-maintainer of one of these packages. Please work with your
> > comaintainers to take up maintenance.
> 
> still there's no orphaned iptraf

Please follow the procedure at:

https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life

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

[perl-Danga-Socket/el6] changes root lib

2012-08-01 Thread Luis Enrique Bazán De León
commit 0b85f89dee70e9070f4334842497b046d325ce9f
Author: Luis Bazan 
Date:   Wed Aug 1 11:05:23 2012 -0500

changes root lib

 perl-Danga-Socket.spec |7 +--
 1 files changed, 5 insertions(+), 2 deletions(-)
---
diff --git a/perl-Danga-Socket.spec b/perl-Danga-Socket.spec
index 0bb0405..5894c32 100644
--- a/perl-Danga-Socket.spec
+++ b/perl-Danga-Socket.spec
@@ -37,10 +37,13 @@ make test
 %files
 %defattr(-,root,root,-)
 %doc CHANGES examples/
-%{perl_vendorlib}/Danga
-%{_mandir}/man3/Danga::Socket.*
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
 
 %changelog
+* Wed Aug 01 2012 Luis Bazan  - 1.61-4
+- changes lib root
+
 * Wed Aug 01 2012 Luis Bazan  - 1.61-3
 - rebuild againts to check log
 
--
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: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Tom Callaway
On 08/01/2012 10:03 AM, Tom Lane wrote:
> What this means, IMO, is that we need to split out libpng12 as a
> separate package.  The current hack that I'm using (bundling 1.2 and 1.5
> into a single SRPM) was never meant to be more than a very short-term
> stopgap; I'm sure it violates all sorts of packaging guidelines.
> 
> Is there any way we can fast-track that?  I see little value in going
> through the normal package review pushups, when this is absolutely
> nothing except a backwards-compatibility package --- it ought to be
> exactly like the F16 libpng package.  And I'd like to get it done
> before the F18 branch.

Rather than working around the review process, just go ahead and make
the package, upload it somewhere, open a review ticket, and I'll review
it after lunch today. I'm familiar with that package, so it should be a
very quick review for me to complete, and the branching request should
be able to be processed today.

~tom

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

Re: Use AutoQA to track changes in "provides" and "requires"?

2012-08-01 Thread Kamil Paral
> Just an idea I had and wanted to float it out to the group...
> 
> I think it would be nice to get an informational (obviously, not a
> blocking type check) to get changes in the requires or provides of a
> package. It would be a hassle to check it manually but I hope it
> would
> be fairly easy to automate.
> 
> I'm thinking the output would just be a simple log showing added or
> removed items and perhaps version/soversion changes.
> 
> One instance it might has helped in is BZ#842181, although in this
> case only rawhide was affected so as far as I know there's no real
> mechanism to "cancel" the update.
> 
> Thoughts?
> 
> Richard

Something like this? [1] [2]

We already do that in the form of 'rpmguard' test [3]. Currently you have to 
sign-up manually to receive rpmguard/rpmlint results for new package builds [4].


[1] 
http://autoqa.fedoraproject.org/results/409386-autotest/virt02.qa/rpmguard/results/1:blender-2.63a-5.fc.html
[2] 
http://autoqa.fedoraproject.org/results/409350-autotest/virt02.qa/rpmguard/results/1:libguestfs-1.19.27.html
[3] 
http://autoqa.fedoraproject.org/resultsdb/frontend/search?envr=&testcase=rpmguard&results=PASSED&results=INFO&results=FAILED&results=ABORTED&results=CRASHED&results=WAIVED&results=NEEDS_INSPECTION&results=RUNNING&arch=&limit=20
[4] 
http://jlaska.wordpress.com/2010/06/01/fedora-package-maintainers-want-test-results/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Use AutoQA to track changes in "provides" and "requires"?

2012-08-01 Thread Jon Ciesla
On Wed, Aug 1, 2012 at 10:05 AM, Richard Shaw  wrote:
> Just an idea I had and wanted to float it out to the group...
>
> I think it would be nice to get an informational (obviously, not a
> blocking type check) to get changes in the requires or provides of a
> package. It would be a hassle to check it manually but I hope it would
> be fairly easy to automate.
>
> I'm thinking the output would just be a simple log showing added or
> removed items and perhaps version/soversion changes.
>
> One instance it might has helped in is BZ#842181, although in this
> case only rawhide was affected so as far as I know there's no real
> mechanism to "cancel" the update.

You can untag the build if you catch it before the mash. . .

-J

> Thoughts?
>
> Richard
> --
> 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

Use AutoQA to track changes in "provides" and "requires"?

2012-08-01 Thread Richard Shaw
Just an idea I had and wanted to float it out to the group...

I think it would be nice to get an informational (obviously, not a
blocking type check) to get changes in the requires or provides of a
package. It would be a hassle to check it manually but I hope it would
be fairly easy to automate.

I'm thinking the output would just be a simple log showing added or
removed items and perhaps version/soversion changes.

One instance it might has helped in is BZ#842181, although in this
case only rawhide was affected so as far as I know there's no real
mechanism to "cancel" the update.

Thoughts?

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Sérgio Basto
On Ter, 2012-07-31 at 22:42 +0200, Kevin Kofler wrote: 
> I'm looking into these:
> 
> Bill Nottingham wrote:
> > Package komparator (fails to build)
can't resolve this fail 

g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/kde
-I/usr/lib64/qt-3.3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT  -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c -o kdatecombo.o
kdatecombo.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/kde
-I/usr/lib64/qt-3.3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT  -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c -o kfileitemext.o
kfileitemext.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/kde
-I/usr/lib64/qt-3.3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT  -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c -o klistviewitemdups.o
klistviewitemdups.cpp
g++ -DHAVE_CONFIG_H -I. -I.. -I/usr/include/kde
-I/usr/lib64/qt-3.3/include -I.   -DQT_THREAD_SUPPORT  -D_REENTRANT  -O2
-g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic -c -o
klistviewitemsingle.o klistviewitemsingle.cpp
kdatecombo.cpp:17:26: fatal error: kdatecombo.moc: No such file or
directory
compilation terminated.
make[2]: *** [kdatecombo.o] Error 1


> > Package krecipes (fails to build)
> > Package qalculate-kde (fails to build)
> > Package tesseract (fails to build)
> 
> but since the build.log files are no longer available, I need to run new 
> builds first, so it's going to take a while. :-(
> 
> Are those build.log files really so large that they cannot be kept for 
> longer? :-( It's so annoying to see those build failures and to have no idea 
> why the builds failed.
> 
> I also really dislike the way FTBFS are handled now. In the past, bugs were 
> filed for the build failures and they were all tracked on a tracking bug in 
> Bugzilla, so it was always possible to see what needed fixing, and it was 
> possible for provenpackagers to work on that in a coordinated fashion. These 
> days, we get surprised with the failures at the last moment when they have 
> actually been happening for 2 or 3 releases (depending on whether they would 
> have built on F16 had there been a mass rebuild there)! We really need to 
> track those failures in Bugzilla again.
> 
> Kevin Kofler
> 

-- 
Sérgio M. B.

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Nikola Pajkovsky
Bill Nottingham  writes:

> Before we branch for Fedora 18, as is custom, we will block currently
> orphaned packages and packages that have failed to build since Fedora 16.
>
> The following packages are currently orphaned, or fail to build. If
> you have a need for one of these packages, please pick them up.
> If no one claims any of these packages, they will be blocked before
> we branch for Fedora 18. We will block these packages on Monday, August 06.
>
> Note that if you're receiving this mail directly, it's because you are
> a co-maintainer of one of these packages. Please work with your
> comaintainers to take up maintenance.

still there's no orphaned iptraf

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Jon Ciesla
On Tue, Jul 31, 2012 at 12:11 PM, Bill Nottingham  wrote:
> Before we branch for Fedora 18, as is custom, we will block currently
> orphaned packages and packages that have failed to build since Fedora 16.
>
> The following packages are currently orphaned, or fail to build. If
> you have a need for one of these packages, please pick them up.
> If no one claims any of these packages, they will be blocked before
> we branch for Fedora 18. We will block these packages on Monday, August 06.
>
> Note that if you're receiving this mail directly, it's because you are
> a co-maintainer of one of these packages. Please work with your
> comaintainers to take up maintenance.
>

> Package freenx-client (fails to build)

Fixed.


> Package pngcrush (fails to build)

Fixed.

>
> Package tritonus (orphan)

Taken.

-J

-- 
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: rawhide report: 20120801 changes

2012-08-01 Thread Adam Jackson

On 8/1/12 8:11 AM, Fedora Rawhide Report wrote:


[spring]
spring-88.0-2.fc18.x86_64 requires libGLEW.so.1.6()(64bit)
[toped]
toped-0.9.70.1-3.svn1794.fc17.i686 requires libGLEW.so.1.6
toped-0.9.70.1-3.svn1794.fc17.x86_64 requires libGLEW.so.1.6()(64bit)


I kicked rebuilds for the libGLEW update, but these two failed.  The 
errors appear to involve C++ being a travesty of a language, so I 
haven't investigated further.


- ajax

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

Re: Summary/Minutes from today's FESCo Meeting (2012-07-23)

2012-08-01 Thread Björn Persson
Adam Williamson wrote:
> I'm not sure it makes sense to worry about which approach is best for
> the really commonly used core fonts in deciding, because whichever
> approach we take, clearly we'll wind up taking care to make sure those
> fonts look good.

Of course – for somebody's idea of "good". As we found out in another branch 
of this thread, people can disagree on which rendering method makes a font 
look good.

Björn Persson

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

[Bug 842181] perl-SOAP-Lite drops provides for perl(IO::SessionSet) and perl(IO::SessionData) in rawhide version.

2012-08-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=842181

--- Comment #5 from Petr Šabata  ---
I've mailed Martin directly now.

I suspect this change wasn't intentional and will include the modules from
0.714 if he doesn't respond in near future.

-- 
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: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Tom Lane
Adam Williamson  writes:
> On Wed, 2012-08-01 at 00:21 -0700, Adam Williamson wrote:
>> A very quick search returns this:
>> http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html

Thanks.  The links I was given previously didn't lead me to that.

> Well, that's really it. The format of LSB is a bit odd to a lay reader,
> but AFAICT, it really does mean: to be technically in compliance with
> LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
> functions. End of story. I don't see a workaround.

Yeah, looks like it.  (I think redhat-lsb.spec is pretty broken in that
it onlu appears to be trying to force a particular soname version for
libpng, when the spec clearly demands a particular version for each of
these libraries.  But that's not very relevant right now.)

What this means, IMO, is that we need to split out libpng12 as a
separate package.  The current hack that I'm using (bundling 1.2 and 1.5
into a single SRPM) was never meant to be more than a very short-term
stopgap; I'm sure it violates all sorts of packaging guidelines.

Is there any way we can fast-track that?  I see little value in going
through the normal package review pushups, when this is absolutely
nothing except a backwards-compatibility package --- it ought to be
exactly like the F16 libpng package.  And I'd like to get it done
before the F18 branch.

regards, tom lane
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Adam Jackson

On 8/1/12 5:47 AM, Rahul Sundaram wrote:

On 08/01/2012 01:06 PM, Adam Williamson wrote:

Well, that's really it. The format of LSB is a bit odd to a lay reader,
but AFAICT, it really does mean: to be technically in compliance with
LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
functions. End of story. I don't see a workaround.


Fedora is not LSB compatible.  Is it?  Why do we even care about this at
all?


It is if you install redhat-lsb.

The only intrinsic reason to care about LSB support is binary 
compatibility; Fedora broadly doesn't, but that doesn't mean it's not a 
useful end.  Personally I've definitely had occasion to need older 
builds of things like boost and openssl on newer Fedora releases.


repoquery is also telling me there are things in Fedora that _do_ 
require redhat-lsb, at least in F16.  I can't speak to the particulars 
there, you'd need to look into that per-package.


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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread 80
 Le 31/07/2012 19:11, Bill Nottingham a écrit :

Package libgtksourceviewmm (fails to build)

 retired, since nobody claimed it.

 Package nvi (orphan)

 Package torque (orphan)


  Both taken and co-maintainers are very welcome !

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Richard Hughes
On 1 August 2012 10:47, Rahul Sundaram  wrote:
> Fedora is not LSB compatible.  Is it?  Why do we even care about this at
> all?

I think I can speak for most of the core GNOME desktop developers and
state that we don't care about LSB one little bit.

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread TASAKA Mamoru

Bill Nottingham wrote, at 08/01/2012 02:11 AM +9:00:

Before we branch for Fedora 18, as is custom, we will block currently
orphaned packages and packages that have failed to build since Fedora 16.

The following packages are currently orphaned, or fail to build. If
you have a need for one of these packages, please pick them up.
If no one claims any of these packages, they will be blocked before
we branch for Fedora 18. We will block these packages on Monday, August 06.

Note that if you're receiving this mail directly, it's because you are
a co-maintainer of one of these packages. Please work with your
comaintainers to take up maintenance.





Package ragel (fails to build)
Package xaos (fails to build)
Package xdrawchem (fails to build)


Fixed these.

Regards,
Mamoru


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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Jaroslav Reznik
- Original Message -
> - Original Message -
> > Before we branch for Fedora 18, as is custom, we will block
> > currently
> > orphaned packages and packages that have failed to build since
> > Fedora
> > 16.
> > 
> > The following packages are currently orphaned, or fail to build. If
> > you have a need for one of these packages, please pick them up.
> > If no one claims any of these packages, they will be blocked before
> > we branch for Fedora 18. We will block these packages on Monday,
> > August 06.
> > 
> > Note that if you're receiving this mail directly, it's because you
> > are
> > a co-maintainer of one of these packages. Please work with your
> > comaintainers to take up maintenance.
> > 
> > Package libqttracker (fails to build)
> > comaintained by: jreznik
> 
> I'm inclined to let it die but I'll take a look. It's leftover after
> unsuccessful MeeGo packaging efforts.

Let it die in Fedora too - upstream is dead. It was part of Maemo 6,
and as Nokia killed it, nobody is working anymore on it. It's needed for
Qt Mobility but only on Maemo 6/MeeGo platform. No dependencies in Fedora.

R.

> R.
> 
> > 
> > The script that generated this page can be found at
> > https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
> > There you can also report bugs and RFEs.
> > 
> 
> --
> Jaroslav Řezník 
> Engineering Program Manager
> 
> Office: +420 532 294 275
> Mobile: +420 602 797 774
> Red Hat, Inc.   http://www.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Rahul Sundaram
On 07/31/2012 10:41 PM, Bill Nottingham wrote:

> Removing: libgtkhotkey
> synapse requires libgtkhotkey.so.1

CC'ing Michel Alexandre Salim, synapse maintainer

Ideally the synapse maintainer should own this as well but since I use
synapse, I am going to take ownership of this for now to rescue synapse
from being removed.

Michel, if you want to maintain it, feel free to ask.

Rahul


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

[Bug 782599] RFE: Upgrade perl-CGI-Session

2012-08-01 Thread bugzilla
https://bugzilla.redhat.com/show_bug.cgi?id=782599

--- Comment #1 from hkoba  ---
Created attachment 601701
  --> https://bugzilla.redhat.com/attachment.cgi?id=601701&action=edit
Minimum patch to avoid qw warnings

If you do not have enough time to test newer CGI::Session,
please apply this patch as a minimum work around. Please!

-- 
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: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Rahul Sundaram
On 08/01/2012 01:06 PM, Adam Williamson wrote:

> Well, that's really it. The format of LSB is a bit odd to a lay reader,
> but AFAICT, it really does mean: to be technically in compliance with
> LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
> functions. End of story. I don't see a workaround.

Fedora is not LSB compatible.  Is it?  Why do we even care about this at
all?

Rahul

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

Re: [ACTION REQUIRED] [FINAL NOTICE] Retiring packages for F-18

2012-08-01 Thread Jaroslav Reznik
- Original Message -
> Before we branch for Fedora 18, as is custom, we will block currently
> orphaned packages and packages that have failed to build since Fedora
> 16.
> 
> The following packages are currently orphaned, or fail to build. If
> you have a need for one of these packages, please pick them up.
> If no one claims any of these packages, they will be blocked before
> we branch for Fedora 18. We will block these packages on Monday,
> August 06.
> 
> Note that if you're receiving this mail directly, it's because you
> are
> a co-maintainer of one of these packages. Please work with your
> comaintainers to take up maintenance.
> 
> Package libqttracker (fails to build)
>   comaintained by: jreznik

I'm inclined to let it die but I'll take a look. It's leftover after
unsuccessful MeeGo packaging efforts.

R.

> 
> The script that generated this page can be found at
> https://fedorahosted.org/rel-eng/browser/scripts/find-unblocked-orphans.py
> There you can also report bugs and RFEs.
> 

-- 
Jaroslav Řezník 
Engineering Program Manager

Office: +420 532 294 275
Mobile: +420 602 797 774
Red Hat, Inc.   http://www.redhat.com/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Adam Williamson
On Wed, 2012-08-01 at 00:21 -0700, Adam Williamson wrote:
> On Wed, 2012-08-01 at 02:17 -0400, Tom Lane wrote:
> > I have been working for the better part of a year on moving Fedora off
> > of libpng's obsolete 1.2.x release series and onto the current 1.5.x
> > series.  We are practically there now, and I had hoped to drop libpng
> > 1.2 from the distribution before the F18 branch.  However, I find that
> > redhat-lsb-desktop still has a dependency on 1.2, and it's not even
> > because that package contains any PNG-using code; rather, there's a
> > manually inserted version-specific dependency in the specfile:
> > 
> > %ifarch %{ix86}
> > Requires: libpng12.so.0
> > %endif
> > %ifarch x86_64
> > Requires: libpng12.so.0()(64bit)
> > %endif
> > 
> > This is unlike that specfile's treatment of any other library
> > it requires.  I have been told, at
> > https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
> > that the LSB standard requires libpng 1.2, but without any supporting
> > evidence.  I looked at the underlying ISO documents and don't see any
> > requirement for libpng at all, let alone 1.2 in particular.  I am
> > doubtful that every other Linux distro is maintaining this long-obsolete
> > libpng version, too.
> > 
> > I would like to know how to proceed here.  "You should keep libpng 1.2
> > around indefinitely, on the basis of no evidence" is not an answer
> > I intend to accept.
> 
> A very quick search returns this:
> 
> http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html
> 
> in the 'desktop' section of LSB 4.1. I'm looking at it more closely now.

Well, that's really it. The format of LSB is a bit odd to a lay reader,
but AFAICT, it really does mean: to be technically in compliance with
LSB-desktop, you need to ship a libpng12.so.0 which provides the listed
functions. End of story. I don't see a workaround.

See
http://lists.linuxfoundation.org/pipermail/lsb-infrastructure/2012-June/004006.html
 for e.g., for confirmation that it does mean what it seems to mean - that 
seems like a 'real world' (and relatively recent) case where someone says, yup, 
you need to ship a library called libpng12.so.0 with the right symbols in it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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

Re: redhat-lsb-desktop versus transition to current libpng

2012-08-01 Thread Adam Williamson
On Wed, 2012-08-01 at 02:17 -0400, Tom Lane wrote:
> I have been working for the better part of a year on moving Fedora off
> of libpng's obsolete 1.2.x release series and onto the current 1.5.x
> series.  We are practically there now, and I had hoped to drop libpng
> 1.2 from the distribution before the F18 branch.  However, I find that
> redhat-lsb-desktop still has a dependency on 1.2, and it's not even
> because that package contains any PNG-using code; rather, there's a
> manually inserted version-specific dependency in the specfile:
> 
> %ifarch %{ix86}
> Requires: libpng12.so.0
> %endif
> %ifarch x86_64
> Requires: libpng12.so.0()(64bit)
> %endif
> 
> This is unlike that specfile's treatment of any other library
> it requires.  I have been told, at
> https://bugzilla.redhat.com/show_bug.cgi?id=835777#c8
> that the LSB standard requires libpng 1.2, but without any supporting
> evidence.  I looked at the underlying ISO documents and don't see any
> requirement for libpng at all, let alone 1.2 in particular.  I am
> doubtful that every other Linux distro is maintaining this long-obsolete
> libpng version, too.
> 
> I would like to know how to proceed here.  "You should keep libpng 1.2
> around indefinitely, on the basis of no evidence" is not an answer
> I intend to accept.

A very quick search returns this:

http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Desktop-generic/LSB-Desktop-generic/libpng.html

in the 'desktop' section of LSB 4.1. I'm looking at it more closely now.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net

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