Re: Fedora-Review 0.2.0
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
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)
- 元のメッセージ - | 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
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
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
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
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"?
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
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
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]
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
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
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
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
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
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
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
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"?
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
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
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
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
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"?
> 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"?
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"?
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
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
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
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
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)
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.
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
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
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
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
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
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
- 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
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
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
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
- 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
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
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
