Vincent Renardias <[EMAIL PROTECTED]> writes:
> About 1 week to get all the fixes in dists/proposed-updates (we still miss
> quite a few), plus a few days to recompile on non-i386...
I believe mush in slink has a y2k bug -- 53935.
--
.Adam Di [EMAIL PROTECTED]http://www.onShore.com/>
On Wed, 5 Jan 2000, Richard Braakman wrote:
> On Tue, Jan 04, 2000 at 01:37:29AM +, Philip Hands wrote:
> > 1) we fix it without changing the _r4
> >
> > 2) we fix it and go to _r5 for m68k only
> >
> > 3) we fix it and move to _r5 for everything
> >
> > 4) I fix it on the UK mirro
Previously Michael Schmitz wrote:
> Format: 1.5
> Date: Fri, 10 Dec 1999 15:07:21 +0100
> Source: boot-floppies
> Binary: boot-floppies
> Architecture: m68k
> Version: 2.1.9.2 < not a potato version number (slink.r2
> perhaps)
How would he know that's not a potato version number?
On Wed, Jan 05, 2000 at 10:36:16PM +0100, Michael Schmitz wrote:
> On the recent reject - I got a message on Jan. 1 stating that my upload
> from Dec. 13 or Dec. 14 (which was for r4) was _installed_ but a look at
> the contents of the archive revealed that it had been installed only
> partially. S
> > The users, on the other hand, often need CD images and mostly use stable.
> > At this time, though, there just are not enough maintainers to properly
> > support stable. And getting updates to the boot-floppies rejected because
> > they are not security related neither helps the users nor impro
> > Case in point: the current boot-floppies hassle. Let's rehash this
> once > again in more detail. > I wasted some time attempting to build
> new boot-floppies from the source > (the new slink source got uploaded
> to Incoming only days before the > release deadline IIRC).
>
> I apologize for
On Tue, Jan 04, 2000 at 01:37:29AM +, Philip Hands wrote:
> 1) we fix it without changing the _r4
>
> 2) we fix it and go to _r5 for m68k only
>
> 3) we fix it and move to _r5 for everything
>
> 4) I fix it on the UK mirror, and the ``official'' CDs are produced from
> somethin
Michael Schmitz <[EMAIL PROTECTED]> writes:
> The users, on the other hand, often need CD images and mostly use stable.
> At this time, though, there just are not enough maintainers to properly
> support stable. And getting updates to the boot-floppies rejected because
> they are not security rela
Michael Schmitz <[EMAIL PROTECTED]> writes:
> Case in point: the current boot-floppies hassle. Let's rehash this once
> again in more detail.
> I wasted some time attempting to build new boot-floppies from the source
> (the new slink source got uploaded to Incoming only days before the
> release
James Troup <[EMAIL PROTECTED]> writes:
> Philip Hands <[EMAIL PROTECTED]> writes:
>
> > 1) we fix it without changing the _r4
>
> This is not an option. Last time we did this, we upset lots of
> people, and we made promises that stable would only change when we
> bumped a revision.
Fair eno
Philip Hands <[EMAIL PROTECTED]> writes:
> 1) we fix it without changing the _r4
This is not an option. Last time we did this, we upset lots of
people, and we made promises that stable would only change when we
bumped a revision.
N.B.: I haven't had time to follow the rest of the discussion,
> > One thing that did cost a lot of time was the delay in the 'byhand'
> > install of the update files. Maybe the installer should alert the FTP
> > admins of these files separately? Or whoever uploads files that need
> > manual installation needs to CC: his changes file and perhaps a short
> > ru
I tend to agree with what Philip is saying.
> 2) we fix it and go to _r5 for m68k only
(other stuff)
> In conclusion, I think we should probably allow for point releases of
> stable to be made independently on different architectures, and we
> should make one now for m68k.
Why not treat arch sp
Richard Braakman <[EMAIL PROTECTED]> writes:
> The problem at this point (with respect to bug#53683) is that any
> change to slink requires an update to its changelog, and the release
> of 2.1r5. I mentally filed it under "stuff to do for the next slink".
> (And I fervently hope that I won't be t
Michael Schmitz <[EMAIL PROTECTED]> writes:
> I have to concede this kind of stuff happens, and just got #53967
> acknowledged (I refered to your bug report from Dec. 29 so Guy is aware
> that this is really the same bug). I hope you didn't file another report
> after that one?
No, I didn't.
> W
On Mon, Jan 03, 2000 at 10:12:22PM +0100, Michael Schmitz wrote:
> > We should be able to come up with a way of identifying, reporting and
> > fixing these problems in a timely manner, so lets do it so that we
> > don't have to go through this every release.
>
> One thing that did cost a lot of ti
> > bloody murder. To be fair, Phil tried to follow my instructions but it
> > didn't work out (maybe because of things like confusing .lha and .lzh and
> > such).
>
> I think I could have done the whole thing in another 10 minutes as it
> happens, I just misunderstood that I was meant to be doing
> > please accept the fact that the m68k people can't fix anything on the FTP
> > servers, including broken symlinks (and please accept my explanation that
> > changing the current symlink to 0606 isn't even near enough). The FTP team
> > needs to apply the fixes I outlined in my previous mail, tha
On Mon, Jan 03, 2000 at 07:14:19PM +0100, Michael Schmitz wrote:
>
> That's part one, but where I see another large problem is the latency
> between the time something gets known to need work, and the time the
> rebuilt package actually gets installed on the FTP site.
I never had any problems lik
Michael Schmitz <[EMAIL PROTECTED]> writes:
> When complaints about the inconsistent directories in disks-m68k surfaced
> (Dec. 20, I had never seen that my April updates were installed in June
> otherwise I'd have complained before) I checked the contents of these
> directories and described to P
"Christian T. Steigies" <[EMAIL PROTECTED]> writes:
> > Should I have reported this as a bug against debian-m68k, or some such?
> Because we dont react? I dont think the debian/m68k porters have to read
> that list, if you would read it, you would find reasons why not to read it.
No, that's not w
Michael Schmitz <[EMAIL PROTECTED]> writes:
> please accept the fact that the m68k people can't fix anything on the FTP
> servers, including broken symlinks (and please accept my explanation that
> changing the current symlink to 0606 isn't even near enough). The FTP team
> needs to apply the fixe
OK, time to set some things straight after blowing off steam on the lists.
I've trimmed CC: some ...
> > I'm afraid that that is not at all apparent to someone that's not
> > closely involved with the m68k port. Perhaps some sort of pointer
> > should be put somewhere so that there's some chance
On Mon, Jan 03, 2000 at 03:36:57PM +, Philip Hands wrote:
> "Christian T. Steigies" <[EMAIL PROTECTED]> writes:
>
> I'm afraid that that is not at all apparent to someone that's not
> closely involved with the m68k port. Perhaps some sort of pointer
> should be put somewhere so that there's s
"Christian T. Steigies" <[EMAIL PROTECTED]> writes:
> I think one reason why "we" did not react in time is, that all the problems
> were reported to the users (aka debian-68k) list. Not all of "us" are
> reading this list, or at least not very intensively, for various reasons.
> If you want to rea
On Mon, Jan 03, 2000 at 12:47:37PM +, Philip Hands wrote:
>
> To summarise, if you want CDs for your architecture, do whatever
> it takes to get the archive into a valid state, tell me you've done
> it, grab a copy of the CD once I've made it, and tell me it works.
"We" did not cry for the CDs
Michael Schmitz <[EMAIL PROTECTED]> writes:
> > My customers want m68k r4 CDs and they want them NOW. Please take whatever
> > action is necessary to provide them ASAP.
>
> Sorry, but as you will no doubt be aware, Debian is a volunteer project,
> and the m68k port in particular is a very small t
> Actually, I'm still tempted to put my foot down and say ``Until the
> m68k archive is valid, they cannot expect to see official m68k CDs
> released''. This might perhaps ensure that we don't get this
> happening for the potato release. The thing is, why should some CDs
> that were created by me
"J.A. Bezemer" <[EMAIL PROTECTED]> writes:
> My customers want m68k r4 CDs and they want them NOW. Please take whatever
> action is necessary to provide them ASAP.
>
> See threads
> http://www.debian.org/Lists-Archives/debian-68k-9912/msg00056.html
> and
> http://www.debian.org/Lists-Archives
> My customers want m68k r4 CDs and they want them NOW. Please take whatever
> action is necessary to provide them ASAP.
Sorry, but as you will no doubt be aware, Debian is a volunteer project,
and the m68k port in particular is a very small team (four or five
maintainers, primarily occupied with
"J.A. Bezemer" <[EMAIL PROTECTED]> writes:
> My customers want m68k r4 CDs and they want them NOW. Please take whatever
> action is necessary to provide them ASAP.
Last I heard the m68k guys decided that the April version of the
boot-floppies for m68k were fine. What features do you think 2.1r4
My customers want m68k r4 CDs and they want them NOW. Please take whatever
action is necessary to provide them ASAP.
See threads
http://www.debian.org/Lists-Archives/debian-68k-9912/msg00056.html
and
http://www.debian.org/Lists-Archives/debian-68k-9912/msg00087.html
Regards (and being a bit
32 matches
Mail list logo
