Richard W.M. Jones wrote:
I'm not convinced yet this is a glibc issue. It could be a problem in
the threaded work-queue code in git-grep which is just exposed by the
change in glibc. No one will know until we finally diagnose the bug.
The analysis in the bug is now that this is indeed a bug
On Mon, Oct 24, 2011 at 10:46:31AM -0700, Adam Williamson wrote:
On Mon, 2011-10-24 at 18:50 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
We have lots of suggestions. As I've said at least fifty times, it's
pointless going too far with the slapping of band-aids on the current
On Mon, Oct 24, 2011 at 11:34:46PM +0200, Jim Meyering wrote:
Jim Meyering wrote:
Adam Williamson wrote:
... The only breakage
in one which was approved was to do with compiling things - which, sure,
is a pain in the ass, but it's not the kind of problem critpath was
introduced to deal
On Tue, 2011-10-25 at 08:32 +0100, Richard W.M. Jones wrote:
You snipped the part where Kevin wrote [...] if the maintainer
demonstrates incompetence at taking these decisions, the offending
maintainer needs to be replaced. The problem here appears to be a
human one, not something that
On 10/23/2011 07:47 PM, Henrik Nordström wrote:
Disable automatic push to stable when there is any negative karma,
requiring the package maintainer to initiate the push even if karma
kriteria have been met.
This idea has been suggested:
https://fedorahosted.org/bodhi/ticket/618
--
devel
On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote:
The fact that a glibc with showstoppers of this kind got pushed to stable
shows that the karma system does not work at all. It just hinders getting
legitimate fixes out and does nothing to stop regressions. glibc is even
critpath, yet
On Mon, 2011-10-24 at 02:47 +0200, Henrik Nordström wrote:
Don't automatically push to stable until at least X days (3?) have
passed, enabling sufficient time for regressions to be detected. Package
maintainer can initiate push earlier by Push to stable if needed and
confident there is no
On Sun, 2011-10-23 at 17:04 -0500, Rex Dieter wrote:
The fail(*), imo, was with 12.999 going stable containing known-regressions.
So, any suggestions, if any, to prevent any similar series of events?
We have lots of suggestions. As I've said at least fifty times, it's
pointless going too far
On Sun, 2011-10-23 at 23:43 -0700, Adam Williamson wrote:
On Sun, 2011-10-23 at 04:14 +0200, Kevin Kofler wrote:
The fact that a glibc with showstoppers of this kind got pushed to stable
shows that the karma system does not work at all. It just hinders getting
legitimate fixes out and
On Sun, Oct 23, 2011 at 4:14 AM, Kevin Kofler kevin.kof...@chello.at wrote:
Jim Meyering wrote:
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While most things work, and it fixed two problems that affected me,
it caused me some
On Sun, Oct 23, 2011 at 05:04:48PM -0500, Rex Dieter wrote:
So, any suggestions, if any, to prevent any similar series of events?
Do the development in Rawhide and cherry pick only well-tested bug fix
commits to the stable branch (F16 in this case).
Rich.
--
Richard Jones, Virtualization
On 10/24/2011 02:47 AM, Henrik Nordström wrote:
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
The fail(*), imo, was with 12.999 going stable containing known-regressions.
So, any suggestions, if any, to prevent any similar series of events?
My suggestions:
Disable automatic push to
sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
This would cause significant problems around crunch times. We would wind
up having to have releng super-push far more updates because we simply
don't always *have* three days to wait to hit deadlines.
note that I only proposed
Once upon a time, Adam Williamson awill...@redhat.com said:
Oh - and remember, the goal of the critpath process is to ensure we
don't send out updates that break people's systems. It worked fine in
this case: no glibc update which breaks systems was approved. All the
ones which caused major
On Mon, 2011-10-24 at 11:06 +0200, Henrik Nordström wrote:
sön 2011-10-23 klockan 23:45 -0700 skrev Adam Williamson:
This would cause significant problems around crunch times. We would wind
up having to have releng super-push far more updates because we simply
don't always *have* three
On Mon, 2011-10-24 at 09:51 -0500, Chris Adams wrote:
Once upon a time, Adam Williamson awill...@redhat.com said:
Oh - and remember, the goal of the critpath process is to ensure we
don't send out updates that break people's systems. It worked fine in
this case: no glibc update which breaks
Adam Williamson wrote:
We have lots of suggestions. As I've said at least fifty times, it's
pointless going too far with the slapping of band-aids on the current
karma system, because it's fundamentally too simplistic: it's never
going to be perfect and there is a definite point of diminishing
On Mon, 2011-10-24 at 18:50 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
We have lots of suggestions. As I've said at least fifty times, it's
pointless going too far with the slapping of band-aids on the current
karma system, because it's fundamentally too simplistic: it's never
Adam Williamson wrote:
... The only breakage
in one which was approved was to do with compiling things - which, sure,
is a pain in the ass, but it's not the kind of problem critpath was
introduced to deal with in the first place.
The problem is bigger than it first seemed, and still not
Jim Meyering wrote:
Adam Williamson wrote:
... The only breakage
in one which was approved was to do with compiling things - which, sure,
is a pain in the ass, but it's not the kind of problem critpath was
introduced to deal with in the first place.
The problem is bigger than it first
Am 23.10.2011 04:14, schrieb Kevin Kofler:
Jim Meyering wrote:
glibc-2.14.90-12.999, which has just made it to stable provokes
a hard-to-diagnose (for me at least) problem.
While most things work, and it fixed two problems that affected
me, it caused me some frustration:
Kevin Kofler wrote:
Jim Meyering wrote:
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While most things work, and it fixed two problems that affected me,
it caused me some frustration:
https//bugzilla.redhat.com/747377
sön 2011-10-23 klockan 17:04 -0500 skrev Rex Dieter:
The fail(*), imo, was with 12.999 going stable containing known-regressions.
So, any suggestions, if any, to prevent any similar series of events?
My suggestions:
Disable automatic push to stable when there is any negative karma,
Jim Meyering wrote:
glibc-2.14.90-12.999, which has just made it to stable provokes a
hard-to-diagnose (for me at least) problem.
While most things work, and it fixed two problems that affected me,
it caused me some frustration:
https//bugzilla.redhat.com/747377
glibc-2.14.90-12.999 also
On Fri, Oct 21, 2011 at 1:21 AM, Rahul Sundaram methe...@gmail.com wrote:
I'd vote for #1, but that's a much longer conversation that should be
had upstream and before we even get close to bringing it to FESCo.
FESCo is the entity which can have that conversation with Glibc upstream
on behalf
Josh Boyer jwbo...@gmail.com writes:
On Fri, Oct 21, 2011 at 1:21 AM, Rahul Sundaram methe...@gmail.com wrote:
FESCo is the entity which can have that conversation with Glibc upstream
on behalf of Fedora. Who else can?
The Glibc package maintainer. I'm pretty sure he understands
upstream,
The Glibc package maintainer. I'm pretty sure he understands
upstream, and FESCo should probably start the discussion with him
first anyway.
I'm not exactly sure what glibc upstream (defined as people without
commit rights to Fedora git) have to do with this at all. The issue
AIUI
On Fri, Oct 21, 2011 at 1:55 PM, David Airlie airl...@redhat.com wrote:
The Glibc package maintainer. I'm pretty sure he understands
upstream, and FESCo should probably start the discussion with him
first anyway.
I've started a dialog with the glibc packager and explained the
concerns I'm
On Wed, 2011-10-19 at 20:35 -0400, Josh Boyer wrote:
Except that Fedora _has_ been glibc's development platform for as long
as I can remember. The Fedora project might not think so, but it's
exactly what upstream glibc does.
Indeed, this has been the case since it was still called Red Hat
On 10/20/2011 06:05 AM, Josh Boyer wrote:
Except that Fedora _has_ been glibc's development platform for as long
as I can remember. The Fedora project might not think so, but it's
exactly what upstream glibc does.
I am aware of this but our policies have changed and either they need to
On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
I spent too many hours debugging this today, so feel obliged to warn
about this. Plus, I feel a little guilty for giving it positive
karma initially. Today's -1 was too late.
glibc-2.14.90-12.999, which has just made it to stable
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ?
AFAIK Several people had to downgrade from -11 because of nsswitch
issues ... seem glibc is not in good shape :-(
You get to pick your breakage. If glibc maintainers would kindly stop
pulling random git snapshots
Simo Sorce wrote:
On Wed, 2011-10-19 at 20:51 +0200, Jim Meyering wrote:
...
To recover an F16 system that works better, I ran this:
yum downgrade glibc glibc-static glibc-devel glibc-common glibc-headers \
glibc-utils nscd
What did you downgrade to ?
AFAIK Several people had to
On Wed, Oct 19, 2011 at 12:36:36 -0700,
Adam Williamson awill...@redhat.com wrote:
You get to pick your breakage. If glibc maintainers would kindly stop
pulling random git snapshots into a pending stable release that would be
nice, but then, I'd also like a solid gold toilet and that
On Wed, 2011-10-19 at 15:25 -0500, Bruno Wolff III wrote:
On Wed, Oct 19, 2011 at 12:36:36 -0700,
Adam Williamson awill...@redhat.com wrote:
You get to pick your breakage. If glibc maintainers would kindly stop
pulling random git snapshots into a pending stable release that would be
Am 19.10.2011 23:09, schrieb Richard W.M. Jones:
On Wed, Oct 19, 2011 at 12:36:36PM -0700, Adam Williamson wrote:
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ? AFAIK Several people had to
downgrade from -11 because of nsswitch issues ... seem glibc is
not
On Wed, 2011-10-19 at 23:36 +0200, Heiko Adams wrote:
Am 19.10.2011 23:09, schrieb Richard W.M. Jones:
On Wed, Oct 19, 2011 at 12:36:36PM -0700, Adam Williamson wrote:
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ? AFAIK Several people had to
downgrade
On 10/20/2011 01:06 AM, Adam Williamson wrote:
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ?
AFAIK Several people had to downgrade from -11 because of nsswitch
issues ... seem glibc is not in good shape :-(
You get to pick your breakage. If glibc
On Wed, 19 Oct 2011 23:36:43 +0200, HA (Heiko) wrote:
IMHO Rawhide should be the only place where version-control-snapshots
of such an important component like glibc should be allowed.
Maybe it would be better to let the value of positive karma depend on
the severity of the package. That
On Thu, 2011-10-20 at 00:30 +0200, Michael Schwendt wrote:
On Wed, 19 Oct 2011 23:36:43 +0200, HA (Heiko) wrote:
IMHO Rawhide should be the only place where version-control-snapshots
of such an important component like glibc should be allowed.
Maybe it would be better to let the value
On Wed, Oct 19, 2011 at 5:51 PM, Rahul Sundaram methe...@gmail.com wrote:
On 10/20/2011 01:06 AM, Adam Williamson wrote:
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ?
AFAIK Several people had to downgrade from -11 because of nsswitch
issues ... seem glibc
On Wed, Oct 19, 2011 at 8:35 PM, Josh Boyer jwbo...@gmail.com wrote:
On Wed, Oct 19, 2011 at 5:51 PM, Rahul Sundaram methe...@gmail.com wrote:
On 10/20/2011 01:06 AM, Adam Williamson wrote:
On Wed, 2011-10-19 at 15:30 -0400, Simo Sorce wrote:
What did you downgrade to ?
AFAIK Several people
42 matches
Mail list logo
