Rene Weber MIA?
I've tried to contact him because of old dailystrips packages, but no reply in more or less one year... Probably other packages are not maintained too... >From devel/people: Weber, Rene <[EMAIL PROTECTED]> main: dailystrips, parchive, scanssh, swatch, txt2pdbdoc non-free: moria bye Christian
Auction R.S. Brookes
Title: Untitled Document AUCTION ON INSTRUCTIONS OF R F BROOKES (FOXHILL FOODS LTD) 10th March 2004 10.30am The Wern Industrial Estate. Rogerstone. Newport. NP10 9FQ FOLLOWING THE CLOSURE OF THEIR ROGERSTONE, NEWPORT PLANT APPROX. 1000 LOTS OF PRIMARY PROCESSING AND COMPLETE READY MEALS PLANT, PACKAGING EQUIPMENT AND REFRIGERATION THIS IS PROBABLY WITHOUT DOUBT THE MOST IMPORTANT AUCTION TO HAPPEN IN THE UK THIS YEAR. THE PLANT PRIMARY COMPRISES OF Complete all stainless steel mashed potato plant with blanchers, peelers, emulsifiers and mixers * Complete forming battering crumbing and frying lines Formax, Koppens and Stein * Refrigeration equipment throughout the plant * Complete make up lines * Cooking and cooling vessels some with scrape surface mixing * Spiral mixers * Urschel Gs, SLAs and Comitrols * Tray sealing machines rotary and inline * Numerous depositors by Turbo Baynflax etc some with screw augers some low level * Click-lock and Jacob White carton erectors * Complete pasta cooking lines and extruders * Label applicators * Metal detectors and check weighers * Multi head weighers Bilwenko etc * Nitrogen freezing tunnels * Box tapers * Lazy Susans * Multivac machines * Silverson mixers * Tray washers * Scales * fridge doors * Automatic Dip tanks * Stainless steel trolleys * Slicers * Laska and other all stainless steel bowl cutters * B6 and One All slicers * Complete contents of canteen * Sanitising air lock systems * Grote slicers * Waste compactors * Roll on roll off scales * Risco and other front end discharge mixers * Fuji and Ilapak flowrappers * Rack washers * Rondo pastry rollers * Mixer grinders * Automatic floor scrubbers * D C Norris vacuum cooling cooking systems with darlecs * Fully equipped laundry room * Grazelli and Maja derinders * Insectocuters * Batter mixers * Swissvac Jumbo and Transvac and double chamber vacuum packers * Icemakers * Stein batter crumbers and power packs * AEW and Biro bandsaws of various sizes * Complete contents of engineers workshop and stores * Complete contents of test kitchen and product development * Koppens filters * Batter enrobers * Sealpack tray sealers * Delford flowrappers and check weighers * Scrape surface mixers with cooling systems * Boot washers * Domino and Lincs inkjet printers * Trief and Holac dicers * Pizza machines * X-ray machines * Vemag vacuum stuffers latest model. If you are a food processor we believe that this is an auction you cannot afford to miss. Everything must go. For full catalogue and colour flyer contact the auctioneers:- CLARKE FUSSELLS TEL: 0845 602 4506 FAX : 0845 280 2570 Email: [EMAIL PROTECTED] Website: www.clarke-fussells.co.uk To unsubscribe please click here
Time to remove a few test kernels?
There are a few obsolete kernels/patches of 2.6, such as (i386 only): kernel-doc-2.6.0-test11 - Linux kernel specific documentation for version 2.6.0-test11. kernel-doc-2.6.0-test9 - Linux kernel specific documentation for version 2.6.0-test9. kernel-headers-2.6.0-test11-1 - Header files related to Linux kernel version 2.6.0-test11 kernel-headers-2.6.0-test11-1-386 - Linux kernel headers 2.6.0-test11 on 386 kernel-headers-2.6.0-test9-1 - Header files related to Linux kernel version 2.6.0-test9 kernel-image-2.6.0-test11-1-386 - Linux kernel image for version 2.6.0-test11 on 386. kernel-image-2.6.0-test9-1-386 - Linux kernel image for version 2.6.0-test9 on 386. kernel-source-2.6.0-test11 - Linux kernel source for version 2.6.0-test11 with Debian patches kernel-source-2.6.0-test9 - Linux kernel source for version 2.6.0-test9 with Debian patches The following patches apply to test kernels, they probably need updates for a current one. kernel-patch-evms - Enterprise Volume Management System (kernel patches) kernel-patch-kdb - Builtin kernel debugger kernel-patch-ltt - Linux Trace Toolkit - kernel patch kernel-patch-relayfs - High-Speed Data Relay Filesystem -- Francesco P. Lovergine
Re: Removing quickppp
reassign 188176 ftp.debian.org retitle 188176 Please remove quickppp thanks * Laurent Fousse <[EMAIL PROTECTED]> [2004-02-08 14:16]: > > >I once intended to take over this package, but after discussions, it > > >appears that the best solution would probably to remove this package > > >from the archive and advise the users to use pppconfig. > > > > > >Clément Stenac > > > > Can we get QA consensus here and file a removal bug against ftp.debian.org? > > I had a look at the code, tried pppconfig, and agree indeed with the > removal of quickppp. RoQA; orphaned, dead upstream, security bug and low code quality, and pppconfig is better anyway. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Time to remove a few test kernels?
On Mon, Feb 09, 2004 at 09:51:26AM +0100, Francesco Paolo Lovergine wrote: > The following patches apply to test kernels, they probably need updates for a > current one. > > kernel-patch-evms - Enterprise Volume Management System (kernel patches) The description lies; kernel-patch-evms was updated for 2.6.0 some time ago. Of course, 2.6.0 has known security problems, and 2.6.1 isn't in Debian yet. -- - mdz
Re: Time to remove a few test kernels?
On Mon, Feb 09, 2004 at 08:37:30AM -0800, you wrote: The description lies; kernel-patch-evms was updated for 2.6.0 some time ago. Of course, 2.6.0 has known security problems, and 2.6.1 isn't in Debian yet. Which is fine, since 2.6.2 is out :) Mike Stone
Re: Time to remove a few test kernels?
On Mon, Feb 09, 2004 at 11:48:24AM -0500, Michael Stone wrote: > On Mon, Feb 09, 2004 at 08:37:30AM -0800, you wrote: >> The description lies; kernel-patch-evms was updated for 2.6.0 some time >> ago. >> Of course, 2.6.0 has known security problems, and 2.6.1 isn't in Debian >> yet. > > Which is fine, since 2.6.2 is out :) And afaict from http://people.debian.org/~herbert/sid/ 2.6.2-1 has been uploaded on saturday. cu andreas
mondo and Debian
Hi Andree & Hugo, I'm a Debian quality assurance person and I noticed you commenting on some of mondo's bug in our Bug Tracking System recently. There were some license problems with our mindi-kernel package because it contained pre-compiled kernel modules without any source code. This might just have been a packaging issue, but the package maintainer didn't respond to email (although he seems to be around) so the package was removed (see http://bugs.debian.org/223993). Now, mindi is uninstallable in Debian because it depends on this removed mini-kernel package, and in turn mondo is uninstallable because it depends on mindi. Since there is some interest in mondo simply removing mindi and mondo from Debian to "fix" this dependency problem is perhaps not a good idea. Does mindi need those kernel modules or can it do without? Where is the source code for those modules? It would be great if you could shed some light on these issues, so we can better decide how to proceed. -- Martin Michlmayr [EMAIL PROTECTED]
mondo and Debian
Hi Andree & Hugo, I'm a Debian quality assurance person and I noticed you commenting on some of mondo's bug in our Bug Tracking System recently. There were some license problems with our mindi-kernel package because it contained pre-compiled kernel modules without any source code. This might just have been a packaging issue, but the package maintainer didn't respond to email (although he seems to be around) so the package was removed (see http://bugs.debian.org/223993). Now, mindi is uninstallable in Debian because it depends on this removed mini-kernel package, and in turn mondo is uninstallable because it depends on mindi. Since there is some interest in mondo simply removing mindi and mondo from Debian to "fix" this dependency problem is perhaps not a good idea. Does mindi need those kernel modules or can it do without? Where is the source code for those modules? It would be great if you could shed some light on these issues, so we can better decide how to proceed. -- Martin Michlmayr [EMAIL PROTECTED]
Re: Time to remove a few test kernels?
On Mon, Feb 09, 2004 at 08:37:30AM -0800, Matt Zimmerman wrote: > > The description lies; kernel-patch-evms was updated for 2.6.0 some time ago. > Of course, 2.6.0 has known security problems, and 2.6.1 isn't in Debian yet. > Good point: security. We have a lots of dangerous pre-2.4.24 kernels around too. Some of them are present for compatibilty on exotic :) archs, but we have a good deal of old kernels for more conventional ones too (i.e. i386). IMHO it's time to track them and require deletion. -- Francesco P. Lovergine
Re: Time to remove a few test kernels?
On Mon, Feb 09, 2004 at 07:47:10PM +0100, Francesco Paolo Lovergine wrote: > On Mon, Feb 09, 2004 at 08:37:30AM -0800, Matt Zimmerman wrote: > > > > The description lies; kernel-patch-evms was updated for 2.6.0 some time ago. > > Of course, 2.6.0 has known security problems, and 2.6.1 isn't in Debian yet. > > > > Good point: security. We have a lots of dangerous pre-2.4.24 kernels > around too. Some of them are present for compatibilty on exotic > :) archs, but we have a good deal of old kernels for more conventional > ones too (i.e. i386). IMHO it's time to track them and require > deletion. This is on my list for the sarge freeze. -- - mdz
RE: mondo and Debian
Martin Michlmayr [mailto:[EMAIL PROTECTED] wrote:- > I'm a Debian quality assurance person and I noticed you commenting on > some of mondo's bug in our Bug Tracking System recently. There were > some license problems with our mindi-kernel package because it > contained pre-compiled kernel modules without any source code. This > might just have been a packaging issue, but the package maintainer > didn't respond to email (although he seems to be around) so the > package was removed (see http://bugs.debian.org/223993). Now, mindi > is uninstallable in Debian because it depends on this removed > mini-kernel package, and in turn mondo is uninstallable because it > depends on mindi. Hi Martin, I am happy to help if I can. It is of course the Debian team's prerogative to decide which packages to include and how to include them. I respect and acknowledge that. Hector has already taken it upon himself to try to solve part of the source of this philosophical incompatibility between Debian and Mondo. Kudos, Hector! He is looking at rootfs, specifically - not what you're e-mailing me about, but still a matter for concern within Debian because rootfs contains precompiled binaries. I just thought I should mention that Hector is aware of Debian's peculiar (meaning specific, in this context) needs and is working with me to accommodate them. Bear in mind that the principle reason for the mindi-kernel's existence is (or was) the nonstandard nature of Debian's kernel. The use of cramfs in the kernel made it incompatible with Mindi. Mindi will run fine without mindi-kernel, so long as your kernel is sane. Debian's kernels, until recently, weren't, as has been discussed ad nauseam on Mondo's mailing list. The latest kernel (from the 3.0 r1 CD 4 or 5, I think but I'm not sure) was fine, though, IIRC. Anyway, the long-term fix is for someone on the Debian team to make Mindi work with the nonstandard Debian kernel that uses cramfs. Then mindi-kernel won't be necessary. The only people outside Debian who need it are Red Hat 6.x users, AFAIK. I hope I have been of some help. If you have any other questions or comments, please do not hesitate to contact me. -Hugo
Special NMU for pgperl
(Sorry if you got this email twice. My mail from yesterday vanished somehow, maybe it still appears on the list in some days). Hi QA! Some weeks ago I separated some auxillary postgresql packages out of the main source tree into separate proper source packages, among them pgperl. pgperl is the original upstream name, so I just used it; but after it was uploaded, I noticed that there already was an unrelated pgperl package which got overwritten by my upload. I already contacted pgperl's maintainer (Stephen, CCed) and the ftpmasters some days ago, but got no response so far. Do you think it is appropriate if I do the upload myself? I would only update the version number (so that it gets greater than the current one in unstable) and add an apropriate changelog entry. Do you see any things I must pay special attention to? Sorry again for the mess and thanks for any comments! Martin -- Martin Pitt Debian GNU/Linux Developer [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.piware.de http://www.debian.org signature.asc Description: Digital signature
