Compose started at Tue Dec 4 09:15:31 UTC 2012
New package: brewtarget-1.2.5-4.fc18 An open source beer recipe creation tool
Removed package: mod_auth_shadow-2.3-2.fc18 Removed package: uxlaunch-0.56-8.fc18
Updated Packages:
RBTools-0.4.2-1.fc18 -------------------- * Fri Nov 16 2012 - Stephen Gallagher sgallagh@redhat.com - 0.4.2-1 - New upstream release 0.4.2 - http://www.reviewboard.org/docs/releasenotes/dev/rbtools/0.4.2/ - New Features: - * The .post-review-cookies.txt file is now made readable only by the calling user, improving security - * Improved debug output - * Updated our Plastic support for Plastic 4.0. This is no longer compatible with previous versions - * A revision to diff against can now be specified when using hgsubversion - Bug Fixes: - * General: - * Using UTF-8 in the summary or description no longer breaks - * The GNU diff error no longer mentions Subversion specifically - * Posting a diff to a submitted review request now displays an error instead of reopening the review request - * Clearcase: - * Fixed base path generation for Clear Case - * Git: - * Fix issues when running post-review within a git submodule with recent Git revisions - * Git diffs no longer include diffs from submodules, preventing useless diffs from being created - * post-review no longer breaks when run from a detached Git HEAD - * Mercurial: - * Fixed bailing on harmless warnings when running hg commands - * Fixed path calculation for hgsubversion when the path contains a username - * Subversion: - * Scanning for the right repository is much faster now when there are lots of Subversion repositories on the server - * Fix handling of revisions with deleted files for Subversion - * Handle modifications inside moved/copied directories for Subversion
asymptote-2.21-3.fc18 --------------------- * Tue Oct 23 2012 Tom Callaway spot@fedoraproject.org - 2.21-3 - more missing BR, conditionalize texlive hacks
* Sat Oct 20 2012 Jindrich Novy jnovy@redhat.com - 2.21-2 - fix (Build)Requires
* Wed Oct 10 2012 Tom Callaway spot@fedoraproject.org - 2.21-1 - update to 2.21
bsf-2.4.0-15.fc18 ----------------- * Thu Nov 22 2012 Tomas Radej tradej@redhat.com - 0:2.4.0-15 - Fixed URL of Source0
* Tue Nov 20 2012 Mikolaj Izdebski mizdebsk@redhat.com - 0:2.4.0-14 - Remove unneeded BR: jython
cronie-1.4.10-1.fc18 -------------------- * Tue Nov 27 2012 Marcela Mašláňová mmaslano@redhat.com - 1.4.10-1 - New release 1.4.10
* Fri Nov 23 2012 Marcela Mašláňová mmaslano@redhat.com - 1.4.9-2 - Re-add virtual provide on vixie-cron back because few packages still has incorrect requires on vixie-cron instead of dailyjobs.
* Thu Nov 22 2012 Marcela Mašláňová mmaslano@redhat.com - 1.4.9-1 - New release 1.4.9
* Mon Oct 15 2012 Marcela Mašláňová mmaslano@redhat.com - 1.4.8-14 - remove BRs not needed anymore
ctags-5.8-9.fc18 ---------------- * Mon Nov 05 2012 Marcela Mašláňová mmaslano@redhat.com - 5.8-9 - fix license field again
* Thu Oct 18 2012 Than Ngo than@redhat.com - 5.8-8 - fix the crash in cssparse
fonts-tweak-tool-0.1.2-1.fc18 ----------------------------- * Sat Nov 24 2012 Akira TAGOH tagoh@redhat.com - 0.1.2-1 - New upstream release - Fix broken icons issue on non-GNOME desktops (#879140)
* Wed Nov 21 2012 Akira TAGOH tagoh@redhat.com - 0.1.1-3 - Fix a typo
* Wed Nov 21 2012 Akira TAGOH tagoh@redhat.com - 0.1.1-2 - clean up and improve the spec file.
gdisk-0.8.5-1.fc18 ------------------ * Sat Nov 17 2012 Terje Rosten terje.rosten@ntnu.no - 0.8.5-1 - 0.8.5
git-1.8.0.1-1.fc18 ------------------ * Thu Nov 29 2012 Adam Tkac <atkac redhat com> - 1.8.0.1-1 - update to 1.8.0.1 - include git-subtree in git rpm (#864651)
gnome-keyring-3.6.2-2.fc18 -------------------------- * Fri Nov 23 2012 Tomas Bzatek tbzatek@redhat.com - 3.6.2-2 - Remove unused update-mime-database calls
mc-4.8.6-2.fc18 --------------- * Wed Nov 28 2012 Jindrich Novy jnovy@redhat.com 4.8.6-2 - sanitize of MC_EXT_SELECTED variable when viewing multiple files, CVE-2012-4463 (#862814) https://www.midnight-commander.org/ticket/2913
seamonkey-2.14-1.fc18 --------------------- * Thu Nov 22 2012 Dmitry Butskoy Dmitry@Butskoy.name 2.14-1 - update to 2.14 - fix elfhack compile
ugene-1.11.3-2.fc18 ------------------- * Tue Nov 27 2012 Rex Dieter rdieter@fedoraproject.org 1.11.3-2 - fix/update qt-related dependencies
Summary: Added Packages: 1 Removed Packages: 2 Upgraded Packages: 12 Compose finished at Tue Dec 4 13:32:30 UTC 2012
On Tue, Dec 4, 2012 at 9:07 AM, Tom Callaway tcallawa@redhat.com wrote:
On 12/04/2012 08:38 AM, Fedora Branched Report wrote:
Compose started at Tue Dec 4 09:15:31 UTC 2012
VICTORY! NO BROKEN DEPS in Fedora 18!
<pops cork>
Now, I ask you all, please, please. Help me keep it that way!
~tom
== Fedora Project -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Tue, Dec 04, 2012 at 10:07:15 -0500, Tom Callaway tcallawa@redhat.com wrote:
On 12/04/2012 08:38 AM, Fedora Branched Report wrote:
Compose started at Tue Dec 4 09:15:31 UTC 2012
VICTORY! NO BROKEN DEPS in Fedora 18!
Thanks for your work with this.
You inspired me to try to fix up some of the broken deps in rawhide that looked easy to fix and had been sitting around for a while.
Now I need to help Martin with getting stuff rebuilt for the latest Ogre.
P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages.
On 12/04/2012 10:21 AM, Bruno Wolff III wrote:
P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages.
If you can identify that, we'll go ahead and block those packages. Jindrich has been working hard to identify any remaining cases like you describe, and I'm happy to help.
~tom
== Fedora Project
On Tue, Dec 04, 2012 at 10:44:11 -0500, Tom Callaway tcallawa@redhat.com wrote:
On 12/04/2012 10:21 AM, Bruno Wolff III wrote:
P.S. There is still some texlive brokenness in F18. If you have the latest texlive stuff installed and try to install db-latex it pulls in some old texlive stuff (that I think should be removed) that has file conflicts with the corresponding new texlive packages.
If you can identify that, we'll go ahead and block those packages. Jindrich has been working hard to identify any remaining cases like you describe, and I'm happy to help.
I've been meaning to file bugs for the three affected packages. I'll get to it today. I don't think dblatex has a texlive varient yet, but maybe I can copy him on that one. For the two packages that appear to be obsolete, I'll file the bugs against the texlive variants so they are more likely to be seen by the right person.
On 12/04/2012 07:07 AM, Tom Callaway wrote:
On 12/04/2012 08:38 AM, Fedora Branched Report wrote:
Compose started at Tue Dec 4 09:15:31 UTC 2012
VICTORY! NO BROKEN DEPS in Fedora 18!
Now, I ask you all, please, please. Help me keep it that way!
Congratulations! Thank you, Tom! This merits an award!
As part of your acceptance speech, please summmarize, point to, and/or provide gentle instruction on what package maintainers should do (and not do), and how to diagnose and recover from mistakes. I believe that this will help preserve your victory.
On 12/04/2012 10:58 AM, John Reiser wrote:
On 12/04/2012 07:07 AM, Tom Callaway wrote:
On 12/04/2012 08:38 AM, Fedora Branched Report wrote:
Compose started at Tue Dec 4 09:15:31 UTC 2012
VICTORY! NO BROKEN DEPS in Fedora 18!
Now, I ask you all, please, please. Help me keep it that way!
Congratulations! Thank you, Tom! This merits an award!
As part of your acceptance speech, please summmarize, point to, and/or provide gentle instruction on what package maintainers should do (and not do), and how to diagnose and recover from mistakes. I believe that this will help preserve your victory.
An excellent suggestion. I will attempt this!
If you're building an update for Fedora, and it has shared libraries or versioned provides, look to see if any of the shared library versions have changed (or if the versioned provides have changed). Then, use repoquery to see if any other packages will be affected. If the answer is yes, consider holding on pushing that update until you can either rebuild those dependent packages or coordinate with their maintainers to accomplish this. Bodhi will let you temporarily tag your package as an override to get these builds done. (As an aside, the plan for Bodhi 2 is to not permit updates to push into the repo when it would result in broken deps.)
Listen to koji. If one of your packages has a broken dependency, koji will send you an email like this:
Subject: Broken dependencies: gambas3
gambas3 has broken dependencies in the F-18 tree: On x86_64: gambas3-3.3.3-1.fc18 requires libkitchen_sink.so.8()(64bit) On i386: gambas3-3.3.3-1.fc18 requires libkitchen_sink.so.8
*****
Now, what that usually means is that kitchen_sink has been upgraded in the Fedora 18 branch, and your package is linked against the old version. In 9 out of 10 cases, simply incrementing the Release, adding a new %changelog entry, and rebuilding your package will resolve the issue.
Sometimes, you'll see a version appear here, this happens if your package has a hardcoded version Requires and the version no longer matches. You'll need to check to see if the new version is also supported, and if so, adjust the versioned Requires, increment Release, add a new %changelog entry, and rebuild.
Rarely, this occurs when one of your dependencies has been retired or blocked for some reason. You can check to see if a package has been blocked by running:
koji list-pkgs --package $PACKAGENAME --show-blocked
(where $PACKAGENAME is the name of the dependent package)
In case that happens, you either need to unretire (and claim ownership) of the dependency, rebuild your code without it (may not be possible), or retire your package.
Documentation for these choices are here:
https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#Cl... https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
I strongly encourage testing new package builds locally first (either in mock or with fedpkg local). I keep VMs for all active Fedora branches so that I can quickly test a build and troubleshoot failures.
Don't be afraid to ask for help, either here on this mailing list, or on IRC (#fedora-devel). Lots of provenpackagers exist and we're usually happy to help.
Also, be sure to ensure that any change you make in a released (or branched) Fedora, you also reflect in rawhide (and kick off a new rawhide build).
Finally, keep rawhide up to date with the latest bits from upstream! We're a lot more forgiving of broken deps (in the short term) in rawhide.
hth,
~tom
== Fedora Project
On 12/04/2012 09:32 AM, Tom Callaway wrote:
If you're building an update for Fedora, and it has shared libraries or versioned provides, look to see if any of the shared library versions have changed (or if the versioned provides have changed).
I'm wondering if it wouldn't be a good idea in the packaging guidelines to suggest that people list the shared libraries in the %files section like:
%{_libdir}/libname.so.#*
With the soname version number explicitly listed. That way packagers would detect most soname bumps automatically when they do a build.
On Tue, Dec 04, 2012 at 10:51:17AM -0700, Orion Poplawski wrote:
On 12/04/2012 09:32 AM, Tom Callaway wrote:
If you're building an update for Fedora, and it has shared libraries or versioned provides, look to see if any of the shared library versions have changed (or if the versioned provides have changed).
I'm wondering if it wouldn't be a good idea in the packaging guidelines to suggest that people list the shared libraries in the %files section like:
%{_libdir}/libname.so.#*
With the soname version number explicitly listed. That way packagers would detect most soname bumps automatically when they do a build.
+1
This is an easy way how rpmbuild will whack a packager when the soname is bumped without his awareness before it breaks deps on koji side.
Jindrich
-- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA, Boulder Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 http://www.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 2012-12-04 20:30, Jindrich Novy wrote:
On Tue, Dec 04, 2012 at 10:51:17AM -0700, Orion Poplawski wrote:
I'm wondering if it wouldn't be a good idea in the packaging guidelines to suggest that people list the shared libraries in the %files section like:
%{_libdir}/libname.so.#*
With the soname version number explicitly listed. That way packagers would detect most soname bumps automatically when they do a build.
+1
This is an easy way how rpmbuild will whack a packager when the soname is bumped without his awareness before it breaks deps on koji side.
IMO if a maintainer of a shared lib package goes as far as submitting a koji build without noticing a soname bump in it, the maintainer should seriously consider stepping aside and finding someone else to take proper care of the package.
Not noticing it quite probably means that either the maintainer didn't bother to test anything besides at most "does it build" before submitting the build, or that s/he has no packages installed that depend on/actually use this shared lib package, both of which lead to the same conclusion, see above.
Hi
On Tue, Dec 4, 2012 at 2:35 PM, Ville Skyttä ville.skytta@iki.fi wrote:
IMO if a maintainer of a shared lib package goes as far as submitting a koji build without noticing a soname bump in it, the maintainer should seriously consider stepping aside and finding someone else to take proper care of the package.
If we can convert runtime errors to buildtime errors by enforcing a additional check, that's a good thing regardless of where the problem lies. Question is, can rpmbuild do anything automatically instead of per spec changes?
Rahul
On Tue, 2012-12-04 at 23:24 -0500, Rahul Sundaram wrote:
Hi
On Tue, Dec 4, 2012 at 2:35 PM, Ville Skyttä ville.skytta@iki.fi wrote: IMO if a maintainer of a shared lib package goes as far as submitting a koji build without noticing a soname bump in it, the maintainer should seriously consider stepping aside and finding someone else to take proper care of the package.
If we can convert runtime errors to buildtime errors by enforcing a additional check, that's a good thing regardless of where the problem lies. Question is, can rpmbuild do anything automatically instead of per spec changes?
This is the kind of thing that's traditionally been in rpmlint-type tools. It'd probably be trivial to add it to autoqa for e.g., as informative output on a bodhi update...
On Tue, 2012-12-04 at 23:24 -0500, Rahul Sundaram wrote:
Hi
On Tue, Dec 4, 2012 at 2:35 PM, Ville Skyttä ville.skytta@iki.fi wrote: IMO if a maintainer of a shared lib package goes as far as submitting a koji build without noticing a soname bump in it, the maintainer should seriously consider stepping aside and finding someone else to take proper care of the package.
If we can convert runtime errors to buildtime errors by enforcing a additional check, that's a good thing regardless of where the problem lies. Question is, can rpmbuild do anything automatically instead of per spec changes?
This is the kind of thing that's traditionally been in rpmlint-type tools. It'd probably be trivial to add it to autoqa for e.g., as informative output on a bodhi update...
Are we talking about something like this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... and this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... ?
We're doing very poor job announcing it, but we run the tool on every new package build in Koji.
On Thu, 2012-12-06 at 07:39 -0500, Kamil Paral wrote:
On Tue, 2012-12-04 at 23:24 -0500, Rahul Sundaram wrote:
Hi
On Tue, Dec 4, 2012 at 2:35 PM, Ville Skyttä ville.skytta@iki.fi wrote: IMO if a maintainer of a shared lib package goes as far as submitting a koji build without noticing a soname bump in it, the maintainer should seriously consider stepping aside and finding someone else to take proper care of the package.
If we can convert runtime errors to buildtime errors by enforcing a additional check, that's a good thing regardless of where the problem lies. Question is, can rpmbuild do anything automatically instead of per spec changes?
This is the kind of thing that's traditionally been in rpmlint-type tools. It'd probably be trivial to add it to autoqa for e.g., as informative output on a bodhi update...
Are we talking about something like this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... and this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... ?
We're doing very poor job announcing it, but we run the tool on every new package build in Koji.
Oh, yeah, exactly that. I forgot we had an rpmguard test.
On 12/06/2012 05:39 AM, Kamil Paral wrote:
Are we talking about something like this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... and this: http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguard/r... ?
We're doing very poor job announcing it, but we run the tool on every new package build in Koji.
While Ville makes the appropriate point that the attentive packager should catch this, the overworked packager may not :(. I missed a soname bump of one of many libraries (which turned out to be an upstream mistake) in a minor version update of openmpi, and it would have been good to have caught that before it was built in koji. I guess you can untag builds, but that is even more build-system voodoo to know.
In fact, I tend to try to avoid many wild cards in my packages to help notice unexpected changes.
-
Adam Williamson -
Bruno Wolff III -
Fedora compose checker -
Jindrich Novy -
John Reiser -
Jon Ciesla -
Kamil Paral -
Orion Poplawski -
Rahul Sundaram -
Tom Callaway -
Ville Skyttä