tiotest packaged, need sponsor
Hi, ive created a package of tiotest, which is a small relatively need benchmarking program being used a lot recently for raid benchmarks. Its the first package ive made, its only been packaged as i386, i havent tried getting it working on other platforms. Its a bit short on documentation, but if someone wants to look at it email me and ill send the package to you, its only 10KB Thanks Glenn McGrath
Re: tiotest packaged, need sponsor
Seems ive been beaten to it. ftp://ftp.cm.nu/pub/debian/ Oh well, plenty more potential packages out there bug1 wrote: > > Hi, ive created a package of tiotest, which is a small relatively need > benchmarking program being used a lot recently for raid benchmarks. > > Its the first package ive made, its only been packaged as i386, i havent > tried getting it working on other platforms. > > Its a bit short on documentation, but if someone wants to look at it > email me and ill send the package to you, its only 10KB > > Thanks > > Glenn McGrath > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A "progressive" distribution
"Bernhard R. Link" wrote: > > After reading this nice diskussion with all it's aspects, I want to > complete the mess and suggest a "distribution" called > e.g. "progressive" beetween stable(frozen) and unstable. > > As I understood the problem, at the moment, only the stable > distribution is able to be distributed, while the unstable branch is to > unstable and there's no distrubution in between. (To simplify I count the > frozen as stable short before release here.) > > When potate becomes stable, a branch called e.g. "progressive" could be > created between the branches "stable" and "unstable". This branch (sorry > for using this term, but I don't like distribution so much) would start > with the modules from stable and subsets of unstable would be added, if > they are usable. The term subset I use for packages that contain together > like one ore more basis packages (libc,xfree,perl,... or just something > like emacs) and those packages depending on this basis package. (Note that > I mean basis as basis of dependencies not basis of the whole or larger > parts of distribution) And usable shell mean, that this package can be > used for average use without the need of Debian-like-tability. > Do you mean like, Slink 2.1 r1, 3.1r2, 2.1r3, 2.1r4 ? Id like to see a rolling stable release, where unstable package have to meet a certain pre-defined criteria before they can be considered stable. Like to be stable, a package must not have any rc bugs, or have any rc bugs in its dependencies. It would also have to be exposed to the masses for a certain period of time in unstable before being considered for stable. This type of arangment could be automated prety well, it would depend on people reporting bugs and would place extra strain on bug tracking, but i think it would be easier than trying to get all the latest versions of each package bug free at one point in time. A "rolling" stable release such as this may well scale better than the traditional release model. Just a thought Glenn McGrath
Re: Embedded(/RT) Debian? Embeddian GNU/Linux?
Hi, ive been hanging around boot-floppies for a while, and am interested in minimum debian systems. I think what your trying to do could well cover a lot of ground boot-floppies tries to cover, if your not familiar with how the debian boot floppies work, you may get a bit out of it, i love the mklibs.sh script to minimise libraries. I think the way boot floppies current work leaves a fair way for improvements, and after potato stabilises i believe boot-floppies will become much more modular and hopefully closer to what you are looking for. I think a worthy challenge for debian is to get smaller as well as bigger. I was thinking today it would be great if there was some way to create a split debian package, like a normal package could be split into the necessary binaries, and config files in one package, and docs etc in a seperate package, this way you could install one part, then later install the other part and have it recognise the whole normal deb installed Im trying to get into frame buffers at the moment Ill checkout what youve got so far, maybe i can help you out... or learn something. Thanks Glenn McGrath Andreas Schuldei wrote: > > My first mail seems to got lost. excuse me if this turns up twice. > > In fact I am working on an minimal debian (-based) system. > > I am building an embedded system which tries to be as small as possible. > I started with the linux router project, took some parts from the > bootfloppys and wrote some Makefiles to take essential Binaries etc out > of my running potato. > > Right now (since half an hour) I have a 2.2.14 kernel, glibc-2.1.3, > busybox plus some other stuff in 1382 Kbytes (unpacked) in the ramdisk. > (this does not count the kernel, of cause. > > It is booted from floppy, where it takes 905 kbyte alltogether. > > It should be easyly adaptable and is modular by design (like lrp is). > > Anyone intersted should get back to me. I would be glad to cooperate. It > is gpl, of cause. > > I am not on this list, so please reply to me privatly, too. > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[package] drakxtools; diskdrake partition manager
Hi, ive made my first debian package, Mandrakes drakxtools, it contains a number of configuration tools, but my primary reason for packaging is to provide diskdrake. Diskdrake is a graphical partition manager, it allows resizing parititions etc. I originally thought this would be good during installation, but as it requires X and gtk i dont think it would be suitable. drakxtools also contains configuration tools XFdrake, keyboarddrake, mousedrake, lspcidrake, printerdrake, netdrake. drakxtools are nearly totally perl scripts, my perl skills arent that good, i couldnt work out how to efficiently seperate diskdrake from the rest, so the package contains all the tools. One problem is that these configuration tools all bahave as they should on a Mandrake system, they havent been modified to suit debian yet as i said i primarily wanted to package diskdrake. The various drakxtools are also called by lothar, which is a mandrake sponsored hardware detection program. lothar has been packaged by Dan Helfman <[EMAIL PROTECTED]> it is waiting for a sponsor Im not an official debian maintainer yet (but want to be) if anyone feels upto it i could do with some advice/feedback on my efforts so far. I still have a fair bit of work to do before this package is ready, but diskdrake does work. The package as it is so far is at ftp://computernerds.com.au/debian/drakxtools/ this is a permanent modem connection, so expect it to be slow. Thanks Glenn McGrath
build dependencies
It would be cool if packages had better support for build dependencies so its easier/more reliable to build from source. There would probably have to be a set of source base packages defined somewhere that are required as a base for building, but not a base for regular usage as base is currently defined. Better support for building from source could be very handy as the number of architectures increases. Maybe we could even have support in the installer to build from source, that way if the source was distributed with a minimal amount of binary packages for each architecture everything else could be built on the fly. Not ideal, but good if a user wants to experiment on a second architecture. Glenn
Re: build dependencies
Peter S Galbraith wrote: > > bug1 wrote: > > > It would be cool if packages had better support for build dependencies > > so its easier/more reliable to build from source. > > Something like this? > > Source: gri > Section: math > Priority: optional > Maintainer: Peter S Galbraith <[EMAIL PROTECTED]> > Build-Depends: debhelper, netcdfg-dev, tetex-bin, texinfo > Build-Depends-Indep: debhelper, tetex-bin, texinfo, imagemagick, info, gs, > gsfon > ts > Standards-Version: 3.1.1 > > > There would probably have to be a set of source base packages defined > > somewhere that are required as a base for building, but not a base for > > regular usage as base is currently defined. > > Something like this? > > http://www.debian.org/Packages/unstable/devel/build-essential.html > > > Better support for building from source could be very handy as the > > number of architectures increases. > > Maybe we could even have support in the installer to build from source, > > Something like this? > > # apt-get source --compile gri > > Or have I missed something? > No, looks like i had, thanks for pointing out. Glenn
