Re: M68K boot floppies / CDs
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 of the mails going
> > to the right place.
> You are right in thats not that apparent. My excuse that I mentioned that
> address before is probably a very bad one.
Something that might help tremendously would be to retire the web pages
that currently serve as m68k port pages, and set up new ones on the Debian
web site(s). James didn't get around to it, and I forgot who announced to
do it after that, but it's another few months since.
> > We seem not to be closing the feedback loop that is required to make
> > things work. Not only are bug reports falling by the wayside (my
> > fault for not mailing them to the right place, probably), but when
> which bug report? 53683? Oh well, I prefer to think boot-floppies are
> Michaels stuff...
I prefer to protest violently. slink boot-floppies was my stuff until
release, plus the updates in April, but I have no slink machine to build
on anymore. I've said that on m68k-build as early as August '99 before I
left Berkeley. Potato boot-floppies has been David's thing BTW.
> > they do get to someone in the know, their attempts are not getting all
> > the way through the procedure that might actually result in them
> > being installed on the archive.
> >
> > What can we do to fix this?
> Talk about it, find a conclusion and then act according to it. This is step
> one, so we are making good progress already.
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.
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). Didn't work on a potato machine (no big surprise,
but I bet it wouldn't have worked without changes even on slink. Even
excluding those changes I reconstructed from memory; I lost the disk
with all slink boot-floppies stuff on it due to gross mishandling).
The next best thing to do (for me) was to take the updates from April and
reupload those. My mistake was to use a key that I had already submitted
to the keyring maintainers, assuming this would be integrated by then. It
wasn't (I got an inquiry about the new key only yesterday, a month after
submitting it), so the reupload got stuck (Dec. 13) and was only installed
Jan. 1 even though I re-signed the changes file with my old key on Dec.
14. boot-floppies is a notorious case because of the 'byhand' install
method, but that's why I invented those map files in the first place. No
one seems to get that point.
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 Phil how this situation could be remedied
(basically, merge 0606 and 0301 trees according to the map file). That was
on Dec. 21, the problem being that I didn't CC ftpmaster and didn't file a
bug report (those who know me a bit probably know that I abhor the BTS,
especially in cases where not a simple package is involved). Next thing I
hear is somebody I can't remember seeing any mails from before yelling
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).
The end of it: everybody's frustrated, and less willing to put in the
necessary effort than before. For my part, Debian has gotten way too
complicated and slow to react almost to bother. I've spent more time on
this discussion today than I could reasonably afford. But we need to find
out what to improve next time, so please suggest something...
> > Does each port need someone who is responsible for it overall?
> Add m68k-build@nocrew.org here for the m68k port.
> Seriously, I dont see anyone who wants to be responsible for it. Or better,
> who can be responsible. One of us is running the buildd, one is answering
> tons of user questions (many of those come up, only we were not allowed to
> update some slink packages, not security related, but I had allready
> closed that subject), one is tired answering questions and tries to keep
> contrib/non-free current and one has no working m68k machine(?). Did I miss
> anyone? We could need a dedicated slink machine on the net or in Michaels
> office ;-)
You forgot David who's been instrumental in getting glibc 2.1 up to speed,
and does the potato boot-floppies and the Mac kernel CVS. The TT in my
office was used to test potato but I haven't even had much time for that
lately. And I'm not going to waste another minute on slink boot-floppies
anyway.
What we should learn from this: a) there's going to be another year or so
before the next release is due after potato, and b) we're going to need a
networked, reasonably fast machine that remains running potato for that
period. A buildd on that box should take care of most.
> > 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.
Well, I read it, I post answers, and I'm baffled at times. Debian-68k
isn't any worse than some other lists though, one of the problems is that
people got hyped enough to believe Linux was as easy to install and use as
their other favorite OS, without bothering to either read FAQs or Linux
for Dummies guides first. There's too many rough edges that pose no real
problem for an experienced Unix user, but few Mac and Windose users are
Unix experienced.
Michael
Reply to: