Crest, Kullervo & security
Hi! Some time ago Peter Palfrader from DSA asked me by mail how to proceed with Crest & Kullervo. He would like to get rid off it (DSA-wise) and hand it over to us. I mentioned this issue shortly during the Kiel Meeting and said that I would like to have at least one DD-accessible machine for all DDs under DSA control. Or at least using the LDAP from Debian. Another point is security support. Kullervo was used as a security buildd as well. Are there other security buildds? Do we need to rebuild security since we are now on debian-ports? How are security builds handled at the moment? My impression is that DSA wants to get rid off m68k because it's too slow, but having a DD accessible machine would be good for us. So, maybe if we can manage security for Crest and its chroots we could still use Debian LDAP but DSA would not need to care about m68k anymore? Would that be possible? -- Ciao...// Fon: 0381-2744150 Ingo \X/ http://blog.windfluechter.net gpg pubkey: http://www.juergensmann.de/ij_public_key.asc -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Crest, Kullervo & security
Ingo Juergensmann wrote: > Hi! > > Some time ago Peter Palfrader from DSA asked me by mail how to proceed with > Crest & Kullervo. He would like to get rid off it (DSA-wise) and hand it > over to us. > I mentioned this issue shortly during the Kiel Meeting and said that I would > like to have at least one DD-accessible machine for all DDs under DSA > control. Or at least using the LDAP from Debian. Would something similar as the kfreebsd hosts not work? Maybe it can even be hosted at d-ports.org? > Another point is security support. Kullervo was used as a security buildd as > well. Are there other security buildds? Do we need to rebuild security since > we are now on debian-ports? How are security builds handled at the moment? There is only security support for what's (was) in the release and for testing for other architectures... > My impression is that DSA wants to get rid off m68k because it's too slow, > but having a DD accessible machine would be good for us. So, maybe if we can > manage security for Crest and its chroots we could still use Debian LDAP but > DSA would not need to care about m68k anymore? Would that be possible? I'm not sure what (m68k specific?) release you would want to do security support for? I'm also not sure if it's a good precedent to take over (what seems to be) DSA tasks for a server which in DSA's eyes will probably not be (DSA) supported anyway? I think that having an unofficial porter machine would be very welcome and would probably be better supported by m68k enthiusiasts than an official porter machine would be :-) Cheers Luk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Crest, Kullervo & security
> Some time ago Peter Palfrader from DSA asked me by mail how to proceed with > Crest & Kullervo. He would like to get rid off it (DSA-wise) and hand it > over to us. Administration can be done by us I guess. > I mentioned this issue shortly during the Kiel Meeting and said that I would > like to have at least one DD-accessible machine for all DDs under DSA > control. Or at least using the LDAP from Debian. Seconded. One machine where all developers have access by default (i.e. LDAP) is a must. > Another point is security support. Kullervo was used as a security buildd as > well. Are there other security buildds? Do we need to rebuild security since > we are now on debian-ports? How are security builds handled at the moment? > > My impression is that DSA wants to get rid off m68k because it's too slow, > but having a DD accessible machine would be good for us. So, maybe if we can > manage security for Crest and its chroots we could still use Debian LDAP but > DSA would not need to care about m68k anymore? Would that be possible? We cannot manage security on our own unless one of us becomes part of the security team. Security advisories and patches are embargoed until such time as the advisory is released. After a security release, we can pick up the released source and build that, of course. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push
Hi, > > The reasons for this are: > > EtherNEC needs to be rewritten based on the current ne.c code. I'm not sure if > > ... > > processing before the ethernet device has been opened. > > I did recently rewrite the EtherNAT driver based on the current smc91x.c one. > > ... > > work out. > > > > SCSI needs to be rewritten and merged with the Mac 5380 driver (and perhaps a > > ... > > case. Given that the lock handling of IDE may be dodgy, that scares me a bit. > > Reasons enough for you? Oops. It was not my intention to offend anyone. Excuses if I did. I just thought that the reasons were more or less because of the process of submitting patches to linux/m68k. Now I see that it were just technical reasons. Thanks for explaining. > > I'll focus on getting SCSI fixed, first and foremost. First stab at this is > > attached (not fudging with the timeouts, but failing the request instead if the > > lock cannot be obtained). That would be great because in that case I could start to test the installation procedure again. Regards, Frank -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [patch 3/2] m68k: Atari EtherNAT - add writew_be for data push
Hi, > > > case. Given that the lock handling of IDE may be dodgy, that scares > me a bit. > > > > Reasons enough for you? > > Oops. It was not my intention to offend anyone. Excuses if I did. No offense taken, I assure you :-) > > > I'll focus on getting SCSI fixed, first and foremost. First stab at > this is > > > attached (not fudging with the timeouts, but failing the request > instead if the > > > lock cannot be obtained). > > That would be great because in that case I could start to test the > installation procedure again. I've come across a couple of other problems in the interaction between SCSI and IDE. Plus I'm seeing lost interrupts on IDE on occasion now, and I'm not sure if that is due to hardware trouble with my IDE disk, or SCSI hogging the interrupt for far too long. I have a hunch this may be at the core of the problem. On the other hand, the SCSI driver tested OK when used without IDE I/O so something's improved... I need to diagnose this in more detail really. I'll have to consult Stephen on how to replace modules in the install initrd image so kernel fixes can be tested without a full d-i rebuild. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
