Re: svn games
On Mon, Jun 26, 2006 at 06:32:47PM -0700, jurij@wooyd.org wrote:
> I would like to bring the following recent svn commits to the
> attention of the team. I have made a commit r6880 in Saturday morning
> (Pacific time):
> Switch to gcc-4.1 for sparc, because it works (tm).
This was after the 2.6.17-1 upload and implies an ABI change for the
sparc kernels. The change of the abiname is a last resort resolution
which have to be avoided if other possibilities exists.
I provided you this other solution: The rejection of the 2.6.17-1 upload
for sparc from NEW.
> This commit was neccessary because the 2.6.17-1 kernel was uploaded by
> Bastian on Friday, despite the fact that it has been known to be
> broken on sparc SMP systems [0]. At this point Bastian has pointed out
> to me on IRC that changing to a newer compiler is an ABI change. I
> have immediately asked Jeroen whether it is feasible to reject the
> sparc binaries from the NEW queue and got a response that since the
> source have been already been accepted to unstable, there is not too
> much point in such a rejection.
Than you asked the wrong thing. For me it looked like you didn't even
asked on of them because there are only two posibilities:
- It is already accepted.
- Okay, will do.
The first one was not possible as jvw said that is not in neither in the
new nor in the accepted queue.
> So I made the commit r6881:
>
> * Move new changelog entries to 2.6.17-2, as -1 is uploaded already.
> * Add sparc32-iotlb.patch.
> * Bump ABI to 2 as a result.
>
> This commit was *immediately* reverted by Bastian in r6883:
>
> Revert r6880, r6881 and r6882. Can't accept an ABI bump yet.
As I said, an abiname bump is a last resort solution and needs to be
coordinated. Frederik and I currently coordinate the uploads and other
core changes. So I think we have the right to veto such problematic
changes.
> I added myself to uploaders anticipating that we will be able to
> upload soon and fix the unfortunate sparc situation. When I've asked
> whether there are any other pending changes for 2.6.17-2, I was told
> by Bastian that there's not going to be any upload any time soon
> because we "don't want to trash the buildd network".
We got already a rebuke about our upload frequency, which was only once
each 4 days (mostly for security updates). Now you want to do an upload
two days after the last one which only includes a fix for an
architecture which is known to have broken kernels since months.
> I believe it was the first time I've added the stable point release to
> the tree. I've assumed that as the diff was pretty small, the
> possibility of failure was pretty minor, besides any such failure
> would have been caught by the snapshot builders.
A sparc build will have succedded. The problem was, that you did not
test if the source can be successfull patched (this is currently done by
calling debian/rules source-all). The buildds showed, it does not; the
vserver patch was not longer appliable on top of .22.
> To my astonishment soon I've noticed Bastian's commits
> r6890:
>
> Revert r6886. Untested changes.
I did not fix that myself because it does changes for a mostly abondened
tree. It only exists to help d-i to make there release.
If it fails to compile, I won't say anything. But if it fails to even
patch itself on 4 of arches after that, I get angry as this will cost
many cpu time, time to fix it but can be easily checked by the person
which does the change.
> Even if one ignores the derogatory remark, this does not make any
> sense, because the latter commit was made into 2.6.17 tree (trunk),
> which I have personally built and tested on sparc.
Both trees have the same responsibility.
Bastian
--
Sometimes a feeling is all we humans have to go on.
-- Kirk, "A Taste of Armageddon", stardate 3193.9
Reply to: