7:38 a.m.
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(a)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(a)fedoraproject.org> - 2.21-3
- more missing BR, conditionalize texlive hacks
* Sat Oct 20 2012 Jindrich Novy <jnovy(a)redhat.com> - 2.21-2
- fix (Build)Requires
* Wed Oct 10 2012 Tom Callaway <spot(a)fedoraproject.org> - 2.21-1
- update to 2.21
bsf-2.4.0-15.fc18
-----------------
* Thu Nov 22 2012 Tomas Radej <tradej(a)redhat.com> - 0:2.4.0-15
- Fixed URL of Source0
* Tue Nov 20 2012 Mikolaj Izdebski <mizdebsk(a)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(a)redhat.com> - 1.4.10-1
- New release 1.4.10
* Fri Nov 23 2012 Marcela Mašláňová <mmaslano(a)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(a)redhat.com> - 1.4.9-1
- New release 1.4.9
* Mon Oct 15 2012 Marcela Mašláňová <mmaslano(a)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(a)redhat.com> - 5.8-9
- fix license field again
* Thu Oct 18 2012 Than Ngo <than(a)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(a)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(a)redhat.com> - 0.1.1-3
- Fix a typo
* Wed Nov 21 2012 Akira TAGOH <tagoh(a)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(a)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(a)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(a)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(a)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(a)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
9:07 a.m.
On Tue, Dec 4, 2012 at 9:07 AM, Tom Callaway <tcallawa(a)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(a)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
9:21 a.m.
On Tue, Dec 04, 2012 at 10:07:15 -0500,
Tom Callaway <tcallawa(a)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.
9:44 a.m.
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
10:16 a.m.
On Tue, Dec 04, 2012 at 10:44:11 -0500,
Tom Callaway <tcallawa(a)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.
9:58 a.m.
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.
--
10:32 a.m.
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...
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
11:51 a.m.
New subject: Detecting soname bumps
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.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
12:30 p.m.
New subject: Detecting soname bumps
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(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
--
Jindrich Novy <jnovy(a)redhat.com> http://people.redhat.com/jnovy/
Kdo víno má a nepije, kdo hrozny má a nejí je, kdo ženu má a nelíbá,
kdo zábavě se vyhýbá, na toho vemte bič a hůl, to není člověk, to je vůl.
--- Jan Werich
1:35 p.m.
New subject: Detecting soname bumps
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.
10:24 p.m.
New subject: Detecting soname bumps
Hi
On Tue, Dec 4, 2012 at 2:35 PM, Ville Skyttä <ville.skytta(a)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
2:28 a.m.
New subject: Detecting soname bumps
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(a)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...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:39 a.m.
New subject: Detecting soname bumps
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(a)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/rpmguar...
and this:
http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguar...
?
We're doing very poor job announcing it, but we run the tool on every new package
build in Koji.
7:56 a.m.
New subject: Detecting soname bumps
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(a)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/rpmguar...
and this:
http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguar...
?
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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:20 p.m.
New subject: Detecting soname bumps
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/rpmguar...
and this:
http://autoqa.fedoraproject.org/results/471217-autotest/virt02.qa/rpmguar...
?
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.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
4150
days inactive
4154
days old
15 comments
11 participants
participants (11)
-
Adam Williamson -
Bruno Wolff III -
Fedora compose checker -
Jindrich Novy -
John Reiser -
Jon Ciesla -
Kamil Paral -
Orion Poplawski -
Rahul Sundaram -
Tom Callaway -
Ville Skyttä