On 01/05/2011 11:52 PM, Hubert Bahr wrote:
I assume you are referring to bugs.centos.org. I have created an account there and set my preferences to centos 6 and I see 47 entries with status entries of confirmed, feedback, acknowledge, new,
assigned. I assume assigned are indeed that and don't need to be looked at.
Thats mostly on target. However, plenty of pkgs which dont have a report against them might also need to be looked at for various reasons - so its worth keeping an eye out for those.
What I usually recommend to people is : first consider the package set you are most interested in, either since thats the package set you are going to most use, or thats the target role you are most keen on deploying into ( in many case, both those are prolly the same thing anyway ). Once you have done those, move onto the rest.
guess the most of rest still need patches. I assume these are patches against the redhat source rpms. How do you want them submitted? I
patches should be named centos-<pkgname>-<functionality>.patch and attached as files on the tracker ( there are a few there you can look at already, or look in the c5 tree to see how they were done there ).
also assume severity "block" are first priority. Which end are you
Dont mark anything as block - thats something the QA / Automated Testing will throw up ( eg. a missing package in the final tree or invalid binary or unsigned packages etc ). In most cases, you should just report and leave the issue marked as 'new'. If you look at the AuditStatus page, the various status' also have some comments on what they mean or how we use them.
starting from. I assume numerical bug ID# tracker order. In building from Red Hat sources we also needed to patch several specs plus a
couple of source files.
This is an interesting conversation in itself - we dont patch spec files for buildtime issues. But if you bring up a few cases, we can talk about those.
Frakus submitted them upstream but they have not migrated through their process. Do you want those submitted? I think this is the area I prefer to work. I guess I will start at the high
end and work backwards.
When in doubt, submit a report :) we need to find more stuff for Fabian, Manuel and Jeff to do anyway!
- KB
note: moved to a new thread
On Thu, 2011-01-06 at 10:05 +0000, Karanbir Singh wrote:
This is an interesting conversation in itself - we dont patch spec files for buildtime issues. But if you bring up a few cases, we can talk about those.
http://bugs.centos.org/view.php?id=4646 We can not fool people :-)..
John
On 01/06/2011 03:26 PM, JohnS wrote:
This is an interesting conversation in itself - we dont patch spec files for buildtime issues. But if you bring up a few cases, we can talk about those.
http://bugs.centos.org/view.php?id=4646 We can not fool people :-)..
the lsb spec does not need anything changed in order to build - it has missing deps etc. The change is purely on branding issues. I think Hubert comment was more along the lines of buildtime issues.
- KB
On Thu, 2011-01-06 at 15:33 +0000, Karanbir Singh wrote:
On 01/06/2011 03:26 PM, JohnS wrote:
the lsb spec does not need anything changed in order to build - it has missing deps etc. The change is purely on branding issues. I think Hubert comment was more along the lines of buildtime issues.
I understand the symlink issue but this has to change.
You can not leave this in there:
%package graphics Group: System Environment/Base Summary: LSB graphics libraries support for Red Hat Enterprise Linux
The RHL has to come out... This shows up merely in a rpm -qa.
IANAL but the law is the law. It has to come out or you have to publish the Original source rpm in a public place to be gotten among other things.
John
On Thu, Jan 6, 2011 at 2:05 AM, Karanbir Singh mail-lists@karan.org wrote:
On 01/05/2011 11:52 PM, Hubert Bahr wrote:
> In building > from Red Hat sources we also needed to patch several specs plus a couple of source files.
This is an interesting conversation in itself - we dont patch spec files for buildtime issues. But if you bring up a few cases, we can talk about those.
Here is a potential candidate (virt-top build bug):
https://bugzilla.redhat.com/show_bug.cgi?id=661783
It's one of the many bugzilla reports filed by Levente Farkas and one of the few RH responded. Apparently they included a bogus dependency in the spec. So, the remedy is either patch the spec or add the required package in the build environment.
They are going to correct it in the next updated version.
Akemi
Hi Akemi,
On 01/06/2011 03:40 PM, Akemi Yagi wrote:
Here is a potential candidate (virt-top build bug):
https://bugzilla.redhat.com/show_bug.cgi?id=661783
It's one of the many bugzilla reports filed by Levente Farkas and one of the few RH responded. Apparently they included a bogus dependency in the spec. So, the remedy is either patch the spec or add the required package in the build environment.
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there is any buildtime or usage side implications. But it looks pretty clear for us, we need to build with that dep
- KB
On Thu, Jan 6, 2011 at 7:51 AM, Karanbir Singh mail-lists@karan.org wrote:
Hi Akemi,
On 01/06/2011 03:40 PM, Akemi Yagi wrote:
Here is a potential candidate (virt-top build bug):
https://bugzilla.redhat.com/show_bug.cgi?id=661783
It's one of the many bugzilla reports filed by Levente Farkas and one of the few RH responded. Apparently they included a bogus dependency in the spec. So, the remedy is either patch the spec or add the required package in the build environment.
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there is any buildtime or usage side implications. But it looks pretty clear for us, we need to build with that dep
But what if the spec file is missing, say, BuildRequires ? Would you add it to the CentOS spec ? Otherwise it won't build, of course. Apparently there is a known case in RHEL-6.
Akemi
Akemi Yagi wrote:
On Thu, Jan 6, 2011 at 7:51 AM, Karanbir Singh mail-lists@karan.org wrote:
Hi Akemi,
On 01/06/2011 03:40 PM, Akemi Yagi wrote:
Here is a potential candidate (virt-top build bug):
https://bugzilla.redhat.com/show_bug.cgi?id=661783
It's one of the many bugzilla reports filed by Levente Farkas and one of the few RH responded. Apparently they included a bogus dependency in the spec. So, the remedy is either patch the spec or add the required package in the build environment.
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs." Personally I was hoping this would not be the case. UpStream primarily responds to users that pay for support. As a result if the bug you identified is not also identified by a "pay for support customer" it may not even be considered. I thought CentOS was only dependent on the UpStream Sources, not on a recreation of their buggy build environment. Hubert
is any buildtime or usage side implications. But it looks pretty clear for us, we need to build with that dep
But what if the spec file is missing, say, BuildRequires ? Would you add it to the CentOS spec ? Otherwise it won't build, of course. Apparently there is a known case in RHEL-6.
Akemi _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Sat, Jan 8, 2011 at 8:30 PM, Hubert Bahr hab@hbahr.org wrote:
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs." Personally I was hoping this would not be the case.
Has to be like that, because CentOS must be binary compatible! Sometimes applications depend on a bug to work. If you fix it, then application behaviour would be different on CentOS than on upstream. That cannot be!
Of course, if CentOS crew finds a bug, it should be reported to the upstream vendor, and when it is fixed it will be fixed in CentOS too.
On 1/8/11 1:30 PM, Hubert Bahr wrote:
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs." Personally I was hoping this would not be the case.
Bug-for-bug compatibility sort-of makes sense as a goal for the shipped binaries. I'm not sure it does for things that relate to a build system that is neither public nor completely identical to upstream.
On 01/08/2011 09:30 PM, Hubert Bahr wrote:
Akemi Yagi wrote:
On Thu, Jan 6, 2011 at 7:51 AM, Karanbir Singh mail-lists@karan.org wrote:
Hi Akemi,
On 01/06/2011 03:40 PM, Akemi Yagi wrote:
Here is a potential candidate (virt-top build bug):
https://bugzilla.redhat.com/show_bug.cgi?id=661783
It's one of the many bugzilla reports filed by Levente Farkas and one of the few RH responded. Apparently they included a bogus dependency in the spec. So, the remedy is either patch the spec or add the required package in the build environment.
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs." Personally I was hoping this would not be the case. UpStream primarily responds to users that pay for support. As a result if the bug you identified is not also identified by a "pay for support customer" it may not even be considered. I thought CentOS was only dependent on the UpStream Sources, not on a recreation of their buggy build environment. Hubert
In several occasions, for serious offenders ( like kernel, but not only ) Centos has provided patched packages before RH came out with theirs. Obviously however that those packages were not distributed as part of the updates repo.
And yes, even the upstream bugs must stay in the official packages. As Morten has very well said it, "Sometimes applications depend on a bug to work. If you fix it, then application behaviour would be different on CentOS than on upstream.". Oddly enough, I've seen that happening once when I tried to use my patched rpm rather than waiting for upstream's one. And no, the problem was not my patch but the different behaviour of the application due to not exhibiting that particular bug. Go figure...
Manuel Wolfshant wrote:
Comment #5 from Rich clears it up quite nicely from our ( the CentOS ) side of things, the upstream package was built with that dep, so we would need to as well. I havent looked at the build logs to see if there
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs." Personally I was hoping this would not be the case. UpStream primarily responds to users that pay for support. As a result if the bug you identified is not also identified by a "pay for support customer" it may not even be considered. I thought CentOS was only dependent on the UpStream Sources, not on a recreation of their buggy build environment. Hubert
In several occasions, for serious offenders ( like kernel, but not only ) Centos has provided patched packages before RH came out with theirs. Obviously however that those packages were not distributed as part of the updates repo.
And yes, even the upstream bugs must stay in the official packages. As Morten has very well said it, "Sometimes applications depend on a bug to work. If you fix it, then application behaviour would be different on CentOS than on upstream.". Oddly enough, I've seen that happening once when I tried to use my patched rpm rather than waiting for upstream's one. And no, the problem was not my patch but the different behaviour of the application due to not exhibiting that particular bug. Go figure...
I can understand this position. However, could one still use the CentOS developers mailing list, and bugs.centos.org to share info about bugs discovered and their fixes so the users of CentOS would have a forum to share their problems and solutions while waiting on UpStream to provide "official fix". I personally do not like using packages that cannot be rebuilt from the distributions repository. I prefer to know that the source provided for the package can build it. Thus if I need to branch from it for my own applications I can blame any problems in a branched build on my own changes. I understand that there should be other locations for sharing full source/binarys other than the "CentOS Distribution" but having patches organized in the CentOS Bug Tracker as well as reporting them upstream could be valuable.
Hubert
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Sat, Jan 08, 2011 at 01:30:41PM -0600, Hubert Bahr wrote:
Personally I was hoping this would not be the case. UpStream primarily responds to users that pay for support. As a result if the bug you identified is not also identified by a "pay for support customer" it may not even be considered. I thought CentOS was only dependent on the
This is not, by the way, my experience at all. "UpStream" has been very serious about handling all clear bugs I've reported.
This is even true with trivially-fixed packaging bugs. You might not get an immediate errata released, but the problem will eventually get fixed.
The proper place to report these things *is* upstream, even if you're not a direct customer.
On Sun, Jan 9, 2011 at 2:35 PM, Matthew Miller mattdm@mattdm.org wrote:
On Sat, Jan 08, 2011 at 01:30:41PM -0600, Hubert Bahr wrote:
Personally I was hoping this would not be the case. UpStream primarily responds to users that pay for support. As a result if the bug you identified is not also identified by a "pay for support customer" it may not even be considered. I thought CentOS was only dependent on the
This is not, by the way, my experience at all. "UpStream" has been very serious about handling all clear bugs I've reported.
This is even true with trivially-fixed packaging bugs. You might not get an immediate errata released, but the problem will eventually get fixed.
Heh. My luck on that has been inconsistent. It took 4 years and a new OS release to restore the 'Minimal' kickstart installation option.
The proper place to report these things *is* upstream, even if you're not a direct customer.
Paying for at least one license to get contact with the support team is helpful, even if you can't afford RHEL licenses on your project or if you, personally, are doing a better job of support on paid time through CentOS than RHEL nominally provides. (I've been in that situation for various clusters I've done.)
On 01/08/2011 07:30 PM, Hubert Bahr wrote:
I interpret this statement to say, "if the upstream binary package is buggy, CentOS must provide the same bugs."
in the main distro, that has always been the case - within reason. If there is some blatant security issue then we should try and fix that right away ( as an example )
not even be considered. I thought CentOS was only dependent on the UpStream Sources, not on a recreation of their buggy build environment.
Right, were not dependant on their build system - technically the most important thing that we try and target is to no break third party expectations or change the user experience as much as possible. So matching what comes down bit for bit, is very high on the agenda.
I hope you see the reference to the 'main distro' and how that differs from what goes into the 'Plus repo'. There is a lot more flexibility there, from bringing in newer apps to changing behavioural expectations of existing apps in the distro. The idea and mechanism is there, how you want to target it is something that is completely upto you. We dont really have a formal process to induct packages into the Plus repo's - but given interest, thats not hard to work out.
- KB
On Sat, Jan 8, 2011 at 12:07 PM, Akemi Yagi amyagi@gmail.com wrote:
But what if the spec file is missing, say, BuildRequires ? Would you add it to the CentOS spec ? Otherwise it won't build, of course. Apparently there is a known case in RHEL-6.
Akemi
Been there, done that, got paid for it. SuSe 9.x had this problem: the kernel SRPM's had a completely bogus build requirement that was not actually required, it was some weird SuSE internal tool of the-world-knew-not-what-use. Replacing it with a completely bogus, empty, and locally built RPM, simply to solve the dependency, worked.
On 01/08/2011 05:07 PM, Akemi Yagi wrote:
But what if the spec file is missing, say, BuildRequires ? Would you add it to the CentOS spec ? Otherwise it won't build, of course. Apparently there is a known case in RHEL-6.
if that is the only change required - then no, we wont add it to the spec file, we add the component to the buildroots instead to match what happened upstream.
- KB
On Mon, Jan 10, 2011 at 8:58 AM, Karanbir Singh mail-lists@karan.org wrote:
On 01/08/2011 05:07 PM, Akemi Yagi wrote:
But what if the spec file is missing, say, BuildRequires ? Would you add it to the CentOS spec ? Otherwise it won't build, of course. Apparently there is a known case in RHEL-6.
if that is the only change required - then no, we wont add it to the spec file, we add the component to the buildroots instead to match what happened upstream.
I see. That way, I suppose it is easier to see all the required "tweaks" in one place rather than scattered in the packages.
Akemi
-
Akemi Yagi -
Hubert Bahr -
JohnS -
Karanbir Singh -
Les Mikesell -
Manuel Wolfshant -
Matthew Miller -
Morten Torstensen -
Nico Kadel-Garcia