FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 04-07-2010, 05:27 PM
Jeff Spaleta
 
Default geos soname bump in F-12 updates

On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski <orion@cora.nwra.com> wrote:
> Looks like the geos update for F-12 bumped the soname:
> python-basemap-0:0.99.2-6.fc12.i686

Sigh.... thanks for the heads up. I'll push a rebuild now.


-jef"Not to be picky, but it sure would be nice if there was some way
I could get a heads up about this sort of problem before a soname
change lands in updates-released so I can help as the basemap package
maintainer before unsuspecting users see breakage."spaleta
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-09-2010, 09:56 PM
Alex Lancaster
 
Default geos soname bump in F-12 updates

>>>>> "JS" == Jeff Spaleta writes:

JS> On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski <orion@cora.nwra.com> wrote:
>> Looks like the geos update for F-12 bumped the soname:
>> python-basemap-0:0.99.2-6.fc12.i686

JS> Sigh.... thanks for the heads up. I'll push a rebuild now.


JS> -jef"Not to be picky, but it sure would be nice if there was some
JS> way I could get a heads up about this sort of problem before a
JS> soname change lands in updates-released so I can help as the basemap
JS> package maintainer before unsuspecting users see breakage."spaleta

Indeed, that's what I've been requesting for about 3 years now:

https://fedorahosted.org/bodhi/ticket/79

i.e. a way of preventing pushes that break deps, and get warn
maintainers of abi/soname bumps that they need to co-ordinate with all
dependent packages to do a single co-ordinated push.

Broken deps in releases is my number 1 peeve with Fedora and although
it's been actively worked on now, it's taken a very long time to do so.
It would be nice if Red Hat put some more engineering resources into
part of QA because it definitely overlaps into the infrastructure side
of things that "community" maintainers don't have access to.

Alex


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-10-2010, 05:37 AM
Rahul Sundaram
 
Default geos soname bump in F-12 updates

On 04/10/2010 03:26 AM, Alex Lancaster wrote:
>
> Broken deps in releases is my number 1 peeve with Fedora and although
> it's been actively worked on now, it's taken a very long time to do so.
> It would be nice if Red Hat put some more engineering resources into
> part of QA because it definitely overlaps into the infrastructure side
> of things that "community" maintainers don't have access to

Is there parts of Fedora infrastructure that non Red Hat people don't
have any access to?

Rahul
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-10-2010, 02:53 PM
Seth Vidal
 
Default geos soname bump in F-12 updates

On Sat, 10 Apr 2010, Rahul Sundaram wrote:

> On 04/10/2010 03:26 AM, Alex Lancaster wrote:
>>
>> Broken deps in releases is my number 1 peeve with Fedora and although
>> it's been actively worked on now, it's taken a very long time to do so.
>> It would be nice if Red Hat put some more engineering resources into
>> part of QA because it definitely overlaps into the infrastructure side
>> of things that "community" maintainers don't have access to
>
> Is there parts of Fedora infrastructure that non Red Hat people don't
> have any access to?

releng and infrastructure are open to a small number of people. Whether
they work for red hat or not is immaterial.

-sv

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-12-2010, 11:50 AM
Devrim GÜNDÜZ
 
Default geos soname bump in F-12 updates

On Fri, 2010-04-09 at 17:56 -0400, Alex Lancaster wrote:
> JS> On Wed, Apr 7, 2010 at 8:50 AM, Orion Poplawski
> <orion@cora.nwra.com> wrote:
> >> Looks like the geos update for F-12 bumped the soname:
> >> python-basemap-0:0.99.2-6.fc12.i686
>
> JS> Sigh.... thanks for the heads up. I'll push a rebuild now.

It is my bad. I should have noticed it before pushing update...
--
Devrim GÜNDÜZ
PostgreSQL Danışmanı/Consultant, Red Hat Certified Engineer
PostgreSQL RPM Repository: http://yum.pgrpms.org
Community: devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org Twitter: http://twitter.com/devrimgunduz

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 04-12-2010, 04:36 PM
Jeff Spaleta
 
Default geos soname bump in F-12 updates

2010/4/12 Devrim GNDZ <fedora-list@gunduz.org>:
> It is my bad. I should have noticed it before pushing update...

No worries. I doubt it was maliciously intended.

However, this is the 3rd different issue with basemap in the same week
where another maintainer's actions updating one of the dependency
packages have caused basemap to be unusable. That sigh was a general
frustration over the whole thing.

One issue was an API change in EPEL when the python-matplotlib package
was updated...which I can't imagine being caught with any sort of
build or updating tooling.

Second issue was the ABI break in numpy in rawhide in F13...shows up
at runtime...simple rebuild fixes it. Again I'm not sure how our build
or update system could have caught it.

Unless we are running post-build tests..and even then the unit test
that tries to test basemap would have to run when numpy or matplotlib
was updated which I think gets a bit complex. I can surely build that
test...do we have that capability to run them and fail an update based
on their output?

Third issue was this geos bump. And its actually the easiest to catch
because repo closure tests will find it. The repoclosure report caught
it, and I got a bug report from a user.. and Orion caught it. Triple
notification for the win!. The only issue here is, can we do a better
job of automatically finding soname situations before they hit users?

And let me ask this question. What do we provide in terms of workflow
tools to help maintainers remember to check the package chain for
other packages that depend on a package that's being prepped for
updates? Beyond simple soname bumps and other things expressed in the
packaging metadata... other breakage like API and ABI breaks that
can't be expressed in packaging metadata will happen. How do we do a
better job trying to catch those? As a maintainer for niche packages
I certainly can't rely on testers to cover the installed package space
to catch the specific situations I need to test.

We have repoquery on the client yes. Anything else? What if bodhi
grew some capability to list packages which depend on a package when
you submit it for updating? If bodhi told you that basemap depended on
geos before you pushed the update to stable.. would you have done
something different? Would you have ping'd me or perhap tested basemap
yourself to some extent? If Bodhi had notified me as a maintainer of
basemap that geos was going into F12 testing or that matplotlib was
being updated in EPEL testing. I _might_ have remembered to test it
myself :->

-jef
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 09:57 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org