Greetings,
LLVM 2.9 is scheduled to be released on April 3rd, and is currently in
the first of hopefully two testing periods (http://llvm.org/)
I'm not sure if we should be pushing this for F-15 -- the first test
release was not ready in time for our alpha -- but I'll be tracking the
2.9 pre-releases in Rawhide (f16).
Here are the packages that should be affected, if you know of anything
else, please let me know:
$ repoquery --enablerepo=rawhide-source --repoid=rawhide-source
--archlist=src --whatrequires llvm-devel
OpenGTL-0:0.9.15-2.fc15.src
ldc-0:0.9.2-31.20110115hg1832.fc15.src
pure-0:0.45-4.fc15.src
pure 0.47 will be out soon; 0.46 is not LLVM 2.9 compatible so I'm
skipping that release entirely. I'll try rebuilding the other two,
unless the maintainers have any objection.
Best regards,
--
Michel Alexandre Salim
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
Here are the latest set of changes to the Fedora Packaging Guidelines:
---
The Emacs packaging guidelines were updated to handle cases where a
package's principal functionality does not require (X)Emacs, but the
package also includes some auxiliary Elisp files to provide support for
the package in (X)Emacs.
https://fedoraproject.org/wiki/Packaging:Emacs
---
The Scriptlet Snippets section dealing with the order that scriptlets
are invoked has been updated to include %trigger scripts.
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Scriptlet_Orderi…
---
A subsection was added to the Packaging Guidelines section on Filesystem
Layout in which it is made explicit that binaries in /bin or /sbin must
NOT depend on any libraries in /usr/lib or /usr/lib64.
https://fedoraproject.org/wiki/Packaging:Guidelines#Binaries_in_.2Fbin_and_…
---
The section on Epochs was improved, and clarifying language about Epoch
use in Requires was added to the Packaging Guidelines.
https://fedoraproject.org/wiki/Packaging:Guidelines#Use_of_Epochshttps://fedoraproject.org/wiki/Packaging:Guidelines#Requires
---
New guidelines were added covering the packaging of Ada programs.
https://fedoraproject.org/wiki/Packaging:Ada
---
The section on Boostrapping in the Treatment of Bundled Libraries page
in the Packaging Guidelines has been amended to add the following:
Packages which are built in such a bootstrapping mode must not be tagged
for a final release (or pushed as an update for any stable release). FPC
will track the progress of approved bootstrapping exceptions via the
ticket requesting the bootstrap bundling exception.
https://fedoraproject.org/wiki/Packaging:Treatment_Of_Bundled_Libraries#Boo…
---
Macro forms of system executables (such as %{__rm}) should not be used
except when there is a need to allow the location of those executables
to be configurable.
https://fedoraproject.org/wiki/Packaging:Guidelines#Macros
---
These guidelines (and changes) were approved by the Fedora Packaging
Committee (FPC).
Many thanks to Hans Niedermann, Jonathan Underwood, Pavel Zhukov, 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,
~spot
_______________________________________________
devel-announce mailing list
devel-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel-announce
I haven't used bespin in quite some time and as such it has gone a
little neglected. I am orphaning it, it has a co-maintainer so before
claiming it, please coordinate with the co-maintainer (rdieter).
-AdamM
If you're a Fedora package maintainer, you will be surely interested in this topic.
AutoQA [1] is a framework for automatic test execution written for Fedora needs. It is developed by Fedora QA [2] team. We have finally reached the state where we can experimentally share some tests results with the wide public. They were already available in the autoqa-results [3] mailing list, but that's not really what we mean by public consumption. Let's improve that.
Now prepare the drums... ready?... we are going to post the results into Fedora Update System [4] (a.k.a. Bodhi)!
After you propose an update in Bodhi (either to -updates or to -updates-testing), you will start receiving AutoQA results as Bodhi comments.
Example comment: http://kparal.files.wordpress.com/2011/03/bodhi-comment.png
A few very important notes:
* The test results are purely *informative*. We won't block/reject your updates if they fail some test. But we hope that you (or RelEng team members) will have a look at the issue and it will help you/them to decide whether it is ok to push this update or not.
* The two tests which will be executed (described below) are designed to check for issues that don't offer too much speculation. We don't want new updates to break the dependencies, ever. We want new updates to keep upgradepath constraint, always. If the result is _failed_, there is either a problem in the update or a problem in our test. If you believe the latter is the case, please, report the problem to us - AutoQA [1], autoqa-devel [5]. Those tests are very complex and there is at least one bug in every program. We know that it will be a bumpy road until we have them perfect.
* It's very easy to disable Bodhi comment posting if something goes really wrong. We will probably do that if we discover some serious issue and re-enable it again after we fix it. So don't be afraid, we won't flood your inbox (the doomsday is not until 2012, you know), and also don't be surprised if the comments don't arrive sometimes.
There are two tests whose results will be posted to Bodhi:
* depcheck [6] - This test checks the dependencies (provides/requires/conflicts/obsoletes flags) of the proposed packages coming into -updates or -updates-testing. It tries to decide whether your update would break the repository (i.e. some packages would have unresolved dependencies in that case). There's a lot of very complex logic behind it.
* upgradepath [7] - This test checks whether the _upgradepath_ requirement is fulfilled. In an example with Fedora 13 and package foo-1.1-1.fc13 it means that every higher Fedora release (14, 15, 16) must contain same or higher NVR of the foo package than is the currently proposed one (and vice versa for lower Fedora releases). This constraint is currently checked only for -updates repository requests.
Next to every result you'll see an URL pointing to the full results log. You'll want to inspect that if your package was marked as failing some test. Example URL:
http://autoqa.fedoraproject.org/results/70273-autotest/qa03.c.fedoraproject…
The results directory is currently a little bit chaotic, but the important files are:
* <testname>/results/output.log where you'll see a shortened output of the test with important highlights as the first lines
* debug/client.DEBUG contains full debug log as created by the framework
In those files you should be able to find the reason why your package failed the test (search for your NVR).
The tests are executed fairly often (almost for every update request), which means that after you correct the problem (if there was any), you should quickly receive another comment saying that your package now passes the test. If your package fails again however, you won't receive another comment - we don't want to spam you with Bodhi notification emails too often. Currently we wait at least three days before inserting two subsequent _fail_ comments.
Feedback/comments welcome.
[1] https://fedoraproject.org/wiki/AutoQA
[2] http://fedoraproject.org/wiki/QA
[3] https://fedorahosted.org/pipermail/autoqa-results/2011-March/thread.html
[4] https://admin.fedoraproject.org/updates/
[5] https://fedorahosted.org/mailman/listinfo/autoqa-devel
[6] https://fedoraproject.org/wiki/QA:Depcheck_Test_Case
[7] https://fedoraproject.org/wiki/QA:Upgrade_Path_Test_Case