f17-gmp and glibc-2.14.90-13
by Jerry James
One of my packages (xemacs) failed the final build in the f17-gmp
build target [1], and was marked FTBFS [2]. I see that the f17-gmp
builds are now being merged into Rawhide. As I pointed out on that
bug, the xemacs build failure was due to building against glibc
2.14.90-13. I don't know the exact cause, but the build is happy
again with glibc 2.14.90-15. If other packages in the f17-gmp tag
were built against the buggy glibc, we might be merging a bunch of
buggy builds into Rawhide.
References:
[1] https://fedorahosted.org/rel-eng/ticket/4929
[2] https://bugzilla.redhat.com/show_bug.cgi?id=749236
--
Jerry James
http://www.jamezone.org/
11 years, 11 months
- 2
- 1
[Test-Announce] Fedora 16 Final Release Candidate 3 (RC3) Available Now!
by Andre Robatino
As per the Fedora 16 schedule [1], Fedora 16 Final Release Candidate 3
(RC3) is now available for testing. Please see the following pages for
download links (including delta ISOs) and testing instructions.
Serverbeach1 is still available as a mirror (but with approximately a 1
hour lag behind dl), so if you are getting a slow download, try
replacing "dl" with "serverbeach1" in the download URL.
Installation:
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
Base:
https://fedoraproject.org/wiki/Test_Results:Current_Base_Test
Desktop:
https://fedoraproject.org/wiki/Test_Results:Current_Desktop_Test
Security Lab:
https://fedoraproject.org/wiki/Test_Results:Current_Security_Lab_Test
Ideally, all Alpha, Beta, and Final priority test cases for Installation
[2], Base [3], Desktop [4], and Security Lab [5] should pass in order to
meet the Final Release Criteria [6]. Help is available on #fedora-qa on
irc.freenode.net [7], or on the test list [8].
Create Fedora 16 Final release candidate (RC) - live and traditional
https://fedorahosted.org/rel-eng/ticket/4967
F16 Final Blocker tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713568
F16 Final Nice-To-Have tracker bug:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=713566
[1] http://rbergero.fedorapeople.org/schedules/f-16/f-16-quality-tasks.html
[2] https://fedoraproject.org/wiki/QA:Installation_validation_testing
[3] https://fedoraproject.org/wiki/QA:Base_validation_testing
[4] https://fedoraproject.org/wiki/QA:Desktop_validation_testing
[5] https://fedoraproject.org/wiki/QA:Security_Lab_validation_testing
[6] https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
[7] irc://irc.freenode.net/fedora-qa
[8] https://admin.fedoraproject.org/mailman/listinfo/test
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
11 years, 11 months
- 1
- 0
Re: Packaging a Firefox extension
by Martin Stransky
On 10/30/2011 06:37 PM, Ville-Pekka Vainio wrote:
> Hi,
>
> I'm maintaining the Finnish spell checking extension for Firefox called
> Mozvoikko. Upstream recently released a Javascript-based version of the
> extension, which I've now packaged in Rawhide. Spec file here:
> <http://pkgs.fedoraproject.org/gitweb/?p=mozvoikko.git;a=blob;f=mozvoikko....>.
>
> Xulrunner maintainers, would you like me to push this new version to
> F-16 and F-15 as well? It would not need to be rebuilt every time
> Xulrunner is updated, but of course there is some risk in doing updates
> like this in stable releases.
I guess it's up to you. How compatible is the new version? Does it need
an update for new firefox versions? (extensions are incompatible with
new ff version sometime).
> For now, I've only packaged the extension for Firefox, but I would like
> to add Thunderbird support as well. What would be the best way to do
> that? I could probably symlink the extension directory from
> %{_datadir}/mozilla/extensions/%{firefox_app_id}/%{mozvoikko_ext_id} to
> %{_datadir}/mozilla/extensions/%{thunderbird_app_id/%{mozvoikko_ext_id}
> but are directory symlinks still probalematic for RPM? Should I just
> copy all the files to Thunderbird's extension directory too, to avoid
> the symlinking?
I think the symlinks are okay, we use them to link langpacks already.
ma.
11 years, 11 months
- 2
- 1