All,
I needed to build kernel-2.6.9-42.37.EL.c4test for this bug:
http://bugs.centos.org/view.php?id=1634
So ... that new kernel is available for others to try as well from the testing repository.
It has Xen kernels too.
It is not too much different than the 2.6.9-42.35 kernel released on Dec 26th by us to the testing repo (a lot of dm fixes that might help the above bug, which is why I built it). Here is a list of the changes from 2.6.9-42.35 to 2.6.9-42.37:
* Wed Jan 03 2007 Jason Baron jbaron@redhat.com [2.6.9-42.37]
-add qlogic iscsi driver (Mike Christie) [180363] -fix laptop shutdown behavior when closing lid (Jim Paradis) [154061] -s390: qeth driver fixes (Jan Glauber) [104646 200166 202047 212176] -add IBM Advanced Management Module 2 to the whitelist for USB storage for devices with multiple LUNs (Konrad Rzeszutek) [196809] -serial fifo fixes (Alan Cox) [168845] -update SCSI blacklist for HP and SEAGATE Tape Devices (Chip Coldwell) [197381] -fix oops in md device stop code (Doug Ledford) [199304] -fix race condition in sys_mincore() (Doug Chapman) [180663] {CVE-2006-4814} -fix console when no "console=" arguments are specified (Chris Lalancette) [220949] -fix oops bug in cdev_put() (Doug Ledford) [164649] -eClipz: CAS call crashing firmware (Janice Girouard) [220486]
* Fri Dec 22 2006 Jason Baron jbaron@redhat.com [2.6.9-42.36]
-s390: fix panic in do_sync_write()/do_sync_read() (Jan Glauber) [196348] -tg3: update to 3.64-rh (John Linville) [196786 198003 202063] -dm: add ioctl support for mapped devices (Milan Broz) [168801] -fix "Hardware P-state driver for AMD processors" for up kernel (Bhavana Nagendra) -dm mirror: fix deadlock in kmirrord when dirty log on mirror itself (Milan Broz) [186950] -dm: store and use md pointer in every table (Milan Broz) [199622] -dm: fix overwriting of extra slot in bi_io_vec (Milan Broz) [219615] -dm: fix suspend error path (Milan Broz) [219616] -dm multipath: rr path order is inverted (Milan Broz) [219630] -dm: add common biosets code (Milan Broz) [215939] -dm mirror: remove trailing space from table (Milan Broz) [215941] -revert: nfs: fix permission handling for truncate calls
----------------------
This is a test Kernel ... use at your own risk :-)
----------------------
Testing Repo info:
http://wiki.centos.org/Repositories
Thanks, Johnny Hughes
On Fri, Jan 05, 2007 at 05:07:42AM -0600, Johnny Hughes wrote:
All,
I needed to build kernel-2.6.9-42.37.EL.c4test for this bug:
http://bugs.centos.org/view.php?id=1634
So ... that new kernel is available for others to try as well from the testing repository.
It has Xen kernels too.
It is not too much different than the 2.6.9-42.35 kernel released on Dec 26th by us to the testing repo (a lot of dm fixes that might help the above bug, which is why I built it). Here is a list of the changes from 2.6.9-42.35 to 2.6.9-42.37:
- Wed Jan 03 2007 Jason Baron jbaron@redhat.com [2.6.9-42.37]
-add qlogic iscsi driver (Mike Christie) [180363]
Hi!
Which version is this qla4xxx driver?
I'm using qla4xxx drivers with many centos4 boxes.. nice to have it integrated.
-- Pasi
-fix laptop shutdown behavior when closing lid (Jim Paradis) [154061] -s390: qeth driver fixes (Jan Glauber) [104646 200166 202047 212176] -add IBM Advanced Management Module 2 to the whitelist for USB storage for devices with multiple LUNs (Konrad Rzeszutek) [196809] -serial fifo fixes (Alan Cox) [168845] -update SCSI blacklist for HP and SEAGATE Tape Devices (Chip Coldwell) [197381] -fix oops in md device stop code (Doug Ledford) [199304] -fix race condition in sys_mincore() (Doug Chapman) [180663] {CVE-2006-4814} -fix console when no "console=" arguments are specified (Chris Lalancette) [220949] -fix oops bug in cdev_put() (Doug Ledford) [164649] -eClipz: CAS call crashing firmware (Janice Girouard) [220486]
- Fri Dec 22 2006 Jason Baron jbaron@redhat.com [2.6.9-42.36]
-s390: fix panic in do_sync_write()/do_sync_read() (Jan Glauber) [196348] -tg3: update to 3.64-rh (John Linville) [196786 198003 202063] -dm: add ioctl support for mapped devices (Milan Broz) [168801] -fix "Hardware P-state driver for AMD processors" for up kernel (Bhavana Nagendra) -dm mirror: fix deadlock in kmirrord when dirty log on mirror itself (Milan Broz) [186950] -dm: store and use md pointer in every table (Milan Broz) [199622] -dm: fix overwriting of extra slot in bi_io_vec (Milan Broz) [219615] -dm: fix suspend error path (Milan Broz) [219616] -dm multipath: rr path order is inverted (Milan Broz) [219630] -dm: add common biosets code (Milan Broz) [215939] -dm mirror: remove trailing space from table (Milan Broz) [215941] -revert: nfs: fix permission handling for truncate calls
This is a test Kernel ... use at your own risk :-)
Testing Repo info:
http://wiki.centos.org/Repositories
Thanks, Johnny Hughes
Pasi Kärkkäinen wrote:
-add qlogic iscsi driver (Mike Christie) [180363]
Which version is this qla4xxx driver?
5.01.00-d3
Another issue I want to point out here is that please report all issues with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on here so we can verify and report upstream.
- KB
Karanbir Singh wrote:
Another issue I want to point out here is that please report all
issues
with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on
here
so we can verify and report upstream.
For the benefit of everyone, can you please clarify what bugs.centos.org is for? I see lots of open kernel/hardware bugs reported there and other things that should either be closed "wontfix" and/or reported upstream.
Would you like to have volunteers to step up and help manage the bug tracker? (ie, more clearly define what the centos bug tracker is for, and give some more people the ability to close bugs)
Greg
On Fri, 2007-01-05 at 11:50 -0700, Greg Swallow wrote:
Karanbir Singh wrote:
Another issue I want to point out here is that please report all
issues
with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on
here
so we can verify and report upstream.
For the benefit of everyone, can you please clarify what bugs.centos.org is for? I see lots of open kernel/hardware bugs reported there and other things that should either be closed "wontfix" and/or reported upstream.
Would you like to have volunteers to step up and help manage the bug tracker? (ie, more clearly define what the centos bug tracker is for, and give some more people the ability to close bugs)
Greg
Well ... it is a bug tracker, however we don't have paid support :P
It is really a tool for people to say, hey I have that problem to, and for other users to help.
CentOS requires the community to help each other, so we expect other users to help by commenting on bugs and helping users to fix problems.
The Developers do work on bugs and close them as we can ... though there are bugs that can be closed, etc.
Certainly there is a need for some "Trusted people" to manage CentOS Bugs ... and we would consider giving access to certain people to make that happen.
Thanks, Johnny Hughes
Johnny Hughes wrote:
Well ... it is a bug tracker, however we don't have paid support :P
I think you wrote one guideline there, if you really mean that it is a bug tracker and not a support tracker: 1. The bug tracker is for reporting bugs. Requests for support (How do I...?) are not appropriate here, and will receive more widespread attention on the Centos mailing list at http://lists.centos.org/mailman/listinfo/centos.
It is really a tool for people to say, hey I have that problem to, and for other users to help.
Sure, and once it is reported, it is searchable. But it's better to close off a bug and direct the reporter to the appropriate place (upstream bug tracker, mailing list) so that people who search for the same problem see the appropriate response.
CentOS requires the community to help each other, so we expect other users to help by commenting on bugs and helping users to fix problems.
That sounds like a support tracker, as opposed to a bug tracker. Wouldn't the mailing list be better place for support? The bug tracker IMO is more suited for packages that are under CentOS's control (ie, dev, centosplus, extras). I think bugs reported against upstream provided packages should be acknowledged with a standard response suggesting the user search the upstream bugzilla (and to report there if not already reported), and then immediately closed "WONTFIX".
The Developers do work on bugs and close them as we can ... though
there
are bugs that can be closed, etc.
Certainly there is a need for some "Trusted people" to manage CentOS Bugs ... and we would consider giving access to certain people to make that happen.
I'd like to help, but would like to have some idea what is appropriate for the bug tracker and what isn't first.
Thanks,
Greg
Greg Swallow wrote:
Karanbir Singh wrote:
Another issue I want to point out here is that please report all
issues
with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on
here
so we can verify and report upstream.
For the benefit of everyone, can you please clarify what bugs.centos.org is for?
its to report issues, however these testing kernels are a special case.
these testing kernels are being built after speaking with the guys upstream and the only reason why I did that is to get wider testing done on some of the patches before they go into the distro.
I fail to see what the problem with that might be ?
- KB
Karanbir Singh wrote:
Greg Swallow wrote:
Karanbir Singh wrote:
Another issue I want to point out here is that please report all
issues
with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on
here
so we can verify and report upstream.
For the benefit of everyone, can you please clarify what
bugs.centos.org
is for?
its to report issues, however these testing kernels are a special
case.
these testing kernels are being built after speaking with the guys upstream and the only reason why I did that is to get wider testing
done
on some of the patches before they go into the distro.
I fail to see what the problem with that might be ?
No problem, I was agreeing with you about reporting bugs upstream for packages that are just rebuilds of upstream, including the testing kernels. Maybe I should have made a new subject for the thread rather than half-hijacking the other one.
Greg
Greg Swallow wrote:
its to report issues, however these testing kernels are a special
No problem, I was agreeing with you about reporting bugs upstream for packages that are just rebuilds of upstream, including the testing kernels. Maybe I should have made a new subject for the thread rather than half-hijacking the other one.
Actually, that is mostly true - but not completely. What we would really prefer is if issues were reported on bugs.centos.org and then a triaging team could manage and work with the developers on resolving / closing them properly.
The reason why the pref to not upstream bugzilla is that in cases there might be a local centos induced problem, and we would never know about those - it has happened. Also, upstream is completely oblivious about CentOS and the process we follow etc, I dont blame them for it. So the decision to take a report upstream should really be from the CentOS bug handing team, most users should try and report issues there.
Add to that there are packages in the CentOS infrastructure that dont come from upstream, we use a different package manager, we use a different mirror network and are a lot more dependent on the community for feedback and support - reporting issues to bugs.centos.org is really the right way to do things.
Now, I mentioned two things here - a Triaging and a bug handing team. Neither of which exist. Both both of which _should_. And members will need to come from the users community and the existing developers. So if people are interested, feel free to step forward. And now will be a good time.
Btw, while I am still doing recruitment... I am still hoping that someone will step forward and offer to help with the Oracle's Linux offering -> CentOS migration guide...
- KB
On 1/5/07, Karanbir Singh mail-lists@karan.org wrote:
Greg Swallow wrote:
its to report issues, however these testing kernels are a special
No problem, I was agreeing with you about reporting bugs upstream for packages that are just rebuilds of upstream, including the testing kernels. Maybe I should have made a new subject for the thread rather than half-hijacking the other one.
Now, I mentioned two things here - a Triaging and a bug handing team. Neither of which exist. Both both of which _should_. And members will need to come from the users community and the existing developers. So if people are interested, feel free to step forward. And now will be a good time.
Ping!
Stephen John Smoogen wrote:
Now, I mentioned two things here - a Triaging and a bug handing team. Neither of which exist. Both both of which _should_. And members will need to come from the users community and the existing developers. So if people are interested, feel free to step forward. And now will be a good time.
Ping!
The process has been started, expect a visit from the men in black soon..
And thanks for offering to help :)
Karanbir Singh wrote:
Greg Swallow wrote:
Karanbir Singh wrote:
Another issue I want to point out here is that please report all
issues
with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on
here
so we can verify and report upstream.
For the benefit of everyone, can you please clarify what bugs.centos.org is for?
its to report issues, however these testing kernels are a special case.
"issues" is one of those weasel words, whose meaning I simply do not understand. Can you pleas expand on what you mean this time?
John Summerfield wrote:
its to report issues, however these testing kernels are a special case.
"issues" is one of those weasel words, whose meaning I simply do not understand. Can you pleas expand on what you mean this time?
The Cambridge dictionary defines it as : "a subject or problem which people are thinking and talking about"
seems quite clear to me.
- KB
On Sun, 2007-01-07 at 11:05 +0000, Karanbir Singh wrote:
John Summerfield wrote:
its to report issues, however these testing kernels are a special case.
"issues" is one of those weasel words, whose meaning I simply do not understand. Can you pleas expand on what you mean this time?
The Cambridge dictionary defines it as : "a subject or problem which people are thinking and talking about"
seems quite clear to me.
- KB
The really answer is this:
We want people to submit Bugs to the mantis ... and we want to community to look through and answer the bug requests. CentOS is community based.
We would also like a knowledgeable team of "Trusted Users" (thanks for volunteering to Steven Smoogen ... he is going to be one of these users) be able to provide answers, as well as have the knowledge to open upstream bugzilla entries when those are required. I do want to put links in the upstream bugzilla that point back to the centos entry, so that users searching in either can see both.
We (the developers) will also (from time to time) create "issue trackers" in the bugs database to report positive and negative feedback for packages that we put into the testing repo.
Mantis is good for both things. The argument goes that more people see it in the mailing list ... that is true, HOWEVER, for historical find purposes mantis is much easier to search and find items with than the mailing list. Mantis also allows us to easily tie issues together to make it easier for the Developers to find issues that we know about.
That does not mean we want to replace the mailing list with Mantis ... bugs.centos.org should be used for BUGS (ie, something is not working as it should and/or the package needs some action to fix it) ... OR ... the developers have created a specific "issue tracker" that we want to use Mantis as the back end for.
It is my feeling that items that are "Upstream required" actions should be listed both in bugs.centos.org and an upstream bugzilla ... and should not be "final actioned" until they are final actioned upstream. And maybe not even then ... as in the case of this bug:
http://bugs.centos.org/view.php?id=1637
That allows CentOS users to know about the bug if they search the centos bugs database, and it allows users of the upstream product see that CentOS is not just a "Sponge Project" that keeps taking and taking while giving nothing back. It is good for the upstream provider and their customers to know that CentOS is providing them a huge benefit by providing issues to support for correction (sometimes with suggested patches and solutions included).
Thanks, Johnny Hughes
Johnny Hughes wrote:
We want people to submit Bugs to the mantis ... and we want to
community
to look through and answer the bug requests. CentOS is community
based.
We would also like a knowledgeable team of "Trusted Users" (thanks for volunteering to Steven Smoogen ... he is going to be one of these
users)
be able to provide answers, as well as have the knowledge to open upstream bugzilla entries when those are required. I do want to put links in the upstream bugzilla that point back to the centos entry, so that users searching in either can see both.
If you want to trust me, I'm volunteering as well :-) I'd suggest another mailing list, maybe bugteam@lists.centos.org - and have that address get assigned any new bugs (and all unassigned old ones) so interested people (ie, the "Trusted Users") can get a copy of all the bug reports. It seems bugs get automatically assigned to you at the moment?
We (the developers) will also (from time to time) create "issue trackers" in the bugs database to report positive and negative
feedback
for packages that we put into the testing repo.
That's good - I think you could say that is similar to a "Package Review" bug report in the RedHat bugzilla for a new Fedora Extras package. Not everything has to be a "bug".
... It is my feeling that items that are "Upstream required" actions
should
be listed both in bugs.centos.org and an upstream bugzilla ... and should not be "final actioned" until they are final actioned upstream. And maybe not even then ... as in the case of this bug:
http://bugs.centos.org/view.php?id=1637
That allows CentOS users to know about the bug if they search the
centos
bugs database, and it allows users of the upstream product see that CentOS is not just a "Sponge Project" that keeps taking and taking
while
giving nothing back. It is good for the upstream provider and their customers to know that CentOS is providing them a huge benefit by providing issues to support for correction (sometimes with suggested patches and solutions included).
How about adding a Category called "Upstream-RHEL4", and changing bugs from whatever the category is currently to "Upstream-RHEL4" once it has been reported upstream? Easier to keep track of upstream bugs that way I think, and you can run a report on how many bugs were reported by CentOS users.
Greg
Greg Swallow wrote:
If you want to trust me, I'm volunteering as well :-) I'd suggest another mailing list, maybe bugteam@lists.centos.org - and have that address get assigned any new bugs (and all unassigned old ones) so interested people (ie, the "Trusted Users") can get a copy of all the bug reports.
But then you would need a request tracker to track which people are working on what bugs }:>
Seems to me that that one is a layer too much. But yes, a mailing list for that could be discussed, centos-devel probably would be cluttered by those mails.
It seems bugs get automatically assigned to you at the moment?
Yes, depending on which component the bug is filed against. But it is no problem to "take over" a bug - once you have an access level which allows you to, that is.
We (the developers) will also (from time to time) create "issue trackers" in the bugs database to report positive and negative feedback for packages that we put into the testing repo.
That's good - I think you could say that is similar to a "Package Review" bug report in the RedHat bugzilla for a new Fedora Extras package. Not everything has to be a "bug".
Yes. See (for example) #1603 and #1580.
How about adding a Category called "Upstream-RHEL4", and changing bugs from whatever the category is currently to "Upstream-RHEL4" once it has been reported upstream? Easier to keep track of upstream bugs that way I think, and you can run a report on how many bugs were reported by CentOS users.
Sounds good to me.
Ralph
Karanbir Singh wrote:
John Summerfield wrote:
its to report issues, however these testing kernels are a special case.
"issues" is one of those weasel words, whose meaning I simply do not understand. Can you pleas expand on what you mean this time?
The Cambridge dictionary defines it as : "a subject or problem which people are thinking and talking about"
seems quite clear to me.
Never heard of your dictionary:-)
dictionary.com lists 35 definitions, several of which might be intended, and that's my point.
It seems to me that the word "issue" is frequently used when someone doesn't wish to acknowledge a bug, outage or other problem or deficiency exists with their product or service.
John Summerfield wrote:
It seems to me that the word "issue" is frequently used when someone doesn't wish to acknowledge a bug, outage or other problem or deficiency exists with their product or service.
The reason why we prefer to think of it as being an issue tracker rather than a bug tracker is because we use the bugs.centos.org setup for things other than bugs as well.
eg. We often ask for good and bad feedback on packages in the testing repositories on the "issue tracker". We might also register an issue at bugs.centos.org and actually report it elsewhere where the bug really exists and use the bugs.centos.org ticket as just that - an issue tracker. There have also often been many situations where we've tracked specific driver issues ( some bugs, mostly just user issues ) there as well.
I suppose most organisations have a support system, a bug tracker, a contact and knowledge base setup. We just have the mailing lists and the issue tracker :)
- KB
Karanbir Singh wrote:
John Summerfield wrote:
It seems to me that the word "issue" is frequently used when someone doesn't wish to acknowledge a bug, outage or other problem or deficiency exists with their product or service.
The reason why we prefer to think of it as being an issue tracker rather than a bug tracker is because we use the bugs.centos.org setup for things other than bugs as well.
eg. We often ask for good and bad feedback on packages in the testing repositories on the "issue tracker". We might also register an issue at bugs.centos.org and actually report it elsewhere where the bug really exists and use the bugs.centos.org ticket as just that - an issue tracker. There have also often been many situations where we've tracked specific driver issues ( some bugs, mostly just user issues ) there as well.
I suppose most organisations have a support system, a bug tracker, a contact and knowledge base setup. We just have the mailing lists and the issue tracker :)
I'll try to remember that in CentOS, "issue" usually means "bug" or "problem:-)" I found myself wondering what on earth Johnny was talking about a few moments ago.
I have learned a fairly liberal interpretation of "bug," which can reasonably include documentation problems (including absence and lack of clarity) and suggestions for improvement. And design and even specification errors: it seems to me the fact that mkisofs can modify its source tree is a bug even though this behaviour is documented.
John Summerfield spake the following on 1/7/2007 4:35 AM:
Karanbir Singh wrote:
John Summerfield wrote:
It seems to me that the word "issue" is frequently used when someone doesn't wish to acknowledge a bug, outage or other problem or deficiency exists with their product or service.
The reason why we prefer to think of it as being an issue tracker rather than a bug tracker is because we use the bugs.centos.org setup for things other than bugs as well.
eg. We often ask for good and bad feedback on packages in the testing repositories on the "issue tracker". We might also register an issue at bugs.centos.org and actually report it elsewhere where the bug really exists and use the bugs.centos.org ticket as just that - an issue tracker. There have also often been many situations where we've tracked specific driver issues ( some bugs, mostly just user issues ) there as well.
I suppose most organisations have a support system, a bug tracker, a contact and knowledge base setup. We just have the mailing lists and the issue tracker :)
I'll try to remember that in CentOS, "issue" usually means "bug" or "problem:-)" I found myself wondering what on earth Johnny was talking about a few moments ago.
I have learned a fairly liberal interpretation of "bug," which can reasonably include documentation problems (including absence and lack of clarity) and suggestions for improvement. And design and even specification errors: it seems to me the fact that mkisofs can modify its source tree is a bug even though this behaviour is documented.
I would think that if someone is having a problem, it would be an "issue". But once it can be reproduced, it would be verified as a bug.
Scott Silva wrote:
I would think that if someone is having a problem, it would be an "issue". But once it can be reproduced, it would be verified as a bug.
That looks like a workable definition for what has happened at bugs.centos.org (and will/can/should happen).
Ralph
On Fri, Jan 05, 2007 at 06:13:37PM +0000, Karanbir Singh wrote:
Pasi Kärkkäinen wrote:
-add qlogic iscsi driver (Mike Christie) [180363]
Which version is this qla4xxx driver?
5.01.00-d3
Another issue I want to point out here is that please report all issues with these testing kernels upstream at http://bugzilla.redhat.com/
And if you have any issues - please do report them, or pass them on here so we can verify and report upstream.
Thanks!
This driver version requires also the separate qlogic qisioctl module for using the qlogic tools (sansurfer and cli).
-- Pasi
^ . . Linux / - \ Choice.of.the .Next.Generation.
On Fri, 2007-01-05 at 19:05 +0200, Pasi Kärkkäinen wrote:
On Fri, Jan 05, 2007 at 05:07:42AM -0600, Johnny Hughes wrote:
All,
I needed to build kernel-2.6.9-42.37.EL.c4test for this bug:
http://bugs.centos.org/view.php?id=1634
So ... that new kernel is available for others to try as well from the testing repository.
It has Xen kernels too.
It is not too much different than the 2.6.9-42.35 kernel released on Dec 26th by us to the testing repo (a lot of dm fixes that might help the above bug, which is why I built it). Here is a list of the changes from 2.6.9-42.35 to 2.6.9-42.37:
- Wed Jan 03 2007 Jason Baron jbaron@redhat.com [2.6.9-42.37]
-add qlogic iscsi driver (Mike Christie) [180363]
Hi!
Which version is this qla4xxx driver?
I'm using qla4xxx drivers with many centos4 boxes.. nice to have it integrated.
I have no idea as the redhat bug (#180363) is not open to the public :(
Johnny Hughes wrote:
On Fri, 2007-01-05 at 19:05 +0200, Pasi Kärkkäinen wrote:
On Fri, Jan 05, 2007 at 05:07:42AM -0600, Johnny Hughes wrote:
- Wed Jan 03 2007 Jason Baron jbaron@redhat.com [2.6.9-42.37]
-add qlogic iscsi driver (Mike Christie) [180363]
Hi!
Which version is this qla4xxx driver?
I'm using qla4xxx drivers with many centos4 boxes.. nice to have it
integrated.
I have no idea as the redhat bug (#180363) is not open to the public :(
Well, there is this patch: Patch2333: linux-2.6.9-scsi-qla4xxx.patch ...from Jan 3rd, with the line: +#define QLA4XXX_DRIVER_VERSION "5.01.00-d3"
Greg
-
Greg Swallow -
John Summerfield -
Johnny Hughes -
Johnny Hughes -
Karanbir Singh -
Pasi Kärkkäinen -
Ralph Angenendt -
Scott Silva -
Stephen John Smoogen