Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 12:13:02PM +0800, Cameron Patrick wrote: > > Yeah, but you can do that on any given port whether it's open or not. e.g. > > cat /dev/zero | nc -u victim 12345 > > (nc in UDP mode seems to ignore "ICMP port unreachable" packets in my > testing... if it doesn't you can always use iptables to make sure it > does.) > > There's no way to /stop/ someone from sending you data, whether you want > it or not. Sure, with UDP you're stuffed regardless. Do we really need to be shipping sarge with it listening on more (TCP) ports than necessary though? Andrew
problem with Build-Depends
Source: pam Section: base Priority: optional Maintainer: Sam Hartman <[EMAIL PROTECTED]> Standards-Version: 3.5.8 Build-Depends: cracklib2-dev, bzip2, debhelper, patch, libdb3-dev, libcap-dev [!hurd-i386 !freebsd-i386 !netbsd-i386], libselinux1-dev Build-Depends-Indep: linuxdoc-tools, linuxdoc-tools-latex, latex2html, tetex-extra, groff, opensp Above is the Build-Depends for a package I am trying to rebuild. When I try and build it on my system which lacks cracklib2-dev the package builds (dpkg-buildpackage does not complain). dpkg-buildpackage works correctly in other situations (when I first tried to build the package it complained about linuxdoc-tools, linuxdoc-tools-latex, and opensp). Any suggestions? # dpkg -l cracklib2-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- pn cracklib2-dev (no description available) -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: problem with Build-Depends
* Russell Coker <[EMAIL PROTECTED]> [2003-10-19 16:13]: > Above is the Build-Depends for a package I am trying to rebuild. When I try > and build it on my system which lacks cracklib2-dev the package builds > (dpkg-buildpackage does not complain). dpkg-buildpackage works correctly in It's probably #212796 (broken dpkg which still has not been fixed). -- Martin Michlmayr [EMAIL PROTECTED]
how to ask for packages rebuilding
On Fri, Oct 17, 2003 at 10:55:41AM +0200, Sven Luther wrote: > So all seems well, and to be in the hand of the autobuilders. The Actually the situation is still the same, so I think that we should do something. I've never understood which is the right/polity way of requests for triggering a new rebuild of packages. Should I ask on -devel, -admin, the per architecture mailing lists or where? TIA, Cheers. -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney signature.asc Description: Digital signature
Re: Bug#88029: Package which uses jam (instead make)
On Sat, Oct 18, 2003 at 04:37:45PM -0500, Manoj Srivastava wrote: > > 88029 > > yeah well. That is not all the dfiscussion there was on it. In > March 2001, we had more than those comments on it: Nah, I saw that one as well, and I'm fairly sure I answered it back then. If not, please let me know and I'll repeat it. > I still think that what we have now is a long established > interface to the build system; saying that the ./debian/rules file is > a Makefile is a short hand for describing an extended version of the > interface defined It's possible to interpret it that way now. But it's a historic injustice, it was "rules file is an executable makefile" originally, which can very well mean that the point being made is that dpkg-buildpackage will be calling debian/rules without an explicit interpreter specified. Which is what it does today as well. > Pretending that this is not an interface that we have now > depended upon for years is hiding from the facts Actually, nobody is doing that. The fact is that whenever we extended dpkg-buildpackage and afterwards the policy manual, it was the interface that was amended in simple terms, there was never "we'll now use this-and-that function of Make" (so far I remember only two of those, when the DEB_BUILD_OPTIONS env. variable was added and when testing for existence of build-arch was added). So in effect, we have been doing the right thing all along, but the mistake that the conversion to must-should-may verbiage caused, was never corrected. And now you can use that as a precedent against my argument. If I was a cynic, I'd call your argument self-perpetuating :) -- 2. That which causes joy or happiness.
Re: Other nethack options
On Sat, 18 Oct 2003, Lukas Geyer wrote: > Colin Watson <[EMAIL PROTECTED]> writes: > > It's trivial to reconfigure it in nethack's option screen, just like any > > other option. I'm not sure why this one should be special. hjkl is extremely newbie-unfriendly. Arrows require the player to manually turn NumLock on. Both things need some action from a first-time user (be it reading the help files, or finding out NumLock needs to be on). > > IMO, leave it at the upstream default; you'll surprise nethack players > > coming from non-Debian systems less that way. And it's not like nethack > > doesn't have a host of other quirks. :) > Right, that reminds me of a default option which I always change, > namely pickup_types. I don't know what the default is at the moment > (in woody it seems to be just $), but IMHO things to be auto-pickuped > are "$!?+/=, WONDERFUL idea! A good default for the newbies, and it would save old players from having to set this by hand! > and some characters might even leave out the spellbooks, Due to their weight, not uselessness. Even for a barb, it's easier to charm those archons than to whack them hand-to-hand. > though one can at least sell them for decent money. Uh oh, it's vanilla nethack, not slashem. What do you need money for (apart from the priests, who want it in big heaps anyway)? You can wait until you can smash the shopkeeps yourself or feed them to a dragon... > Making nethack > options debconf question seems a bit silly to me, but I don't see why > we should stick to upstream defaults when they are wrong... Hell yeah. Besides, IIRC the upstream default is autopickup everything... 1KB /---\ Shh, be vewy, vewy quiet, | [EMAIL PROTECTED] | I'm hunting wuntime ewwows! \---/ Segmentation fault (core dumped)
Bug#214931: New maintainer gutenbook
Package: wnpp Severity: wishlist Followup-For: Bug #214931 I'd like to take over the maintenance for this orphaned package. -- Michael Potter [EMAIL PROTECTED]
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 11:20:33AM +0200, Josip Rodin wrote: > this-and-that function of Make" (so far I remember only two of those, when > the DEB_BUILD_OPTIONS env. variable was added and when testing for existence > of build-arch was added). ... which was a fiasco. Doogie finally implemented the proposal and revert it dpkg (1.10.15) unstable; urgency=low * Back out debian/rules build-arch detection. It is *not* possible *at all* to detect available targets in a rules file. Period. -- Adam Heath <[EMAIL PROTECTED]> Fri, 19 Sep 2003 20:02:19 -0500 The rationale are not available to me, but I trust him since he really tried. At this point I see only two alternative: 1) use dependencies build: build-arch binary-indep: build-indep This is not good to run build-indep as root, but only the maintainer run binary-indep, and there is no need to change dpkg-buildpackage. 2) Set a make variable BUILD and do ifdef BUILD build: $(BUILD) else build: build-arch build-indep endif This require dpkg-buildpackage to call debian/rules with BUILD=build-arch or BUILD=build-indep accordingly. Of course, variants using environment variables exist. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Bug#214931: New maintainer gutenbook
[EMAIL PROTECTED] wrote: > Package: wnpp > Severity: wishlist > Followup-For: Bug #214931 > I'd like to take over the maintenance for this orphaned package. Cool. See http://www.debian.org/devel/wnpp/ for informations about adopting. cu andreas -- http://people.debian.org/~mpalmer/debian-mentors_FAQ.html Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Re: faster boot
On Fri, Oct 17, 2003 at 11:53:18AM +0200, Erich Schubert wrote: > minit is already really small. All it does is running processes and > restarting them when they die. There seems to be little difference > between what i can do with minit and with multiple runsv. > And yes, i do know about shared memory. > I admit that runsvdir has some nice features - like something similar to > runlevels, but way easier to understand. > Just change the symlink to the new runlevel and it will terminate > services not in the new runlevel, while starting new services. Nice! > > But i don't see why i need that many processes: [...] As I already said in my last mail: modularity. Consider a multi-user server system, and you want to provide one or more users with their own personal service management. You can run additional instances of the runsvdir program under the uid and gid of the user as a service, so he can manage his own daemon processes with a guaranteed process state, logging, and supervision. Or use the runsv program to provide him with just a single service facility. On the other hand consider an embedded device, e.g. a kiosk system. You possibly don't want to use runsvdir and runsv at all, but run an X-server as the only service daemon on the system, running a gui application. If X exits the system shuts down. I could think of more scenarios. Each of the separated programs perform certain tasks: runit: clean process state, process 1 duties; runsvdir: privilege separation, service management, last-resort-log; runsv: user interface, supervision, logging. Running them in a process hierarchy makes it possible to recombine these features differently. I cannot see what's wrong with having some more processes running, very small ones which sleep most of the time. They don't hurt the system. Regards, Gerrit. -- Open projects at http://smarden.org/pape/.
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 12:18:51PM +0200, Bill Allombert wrote: > > this-and-that function of Make" (so far I remember only two of those, when > > the DEB_BUILD_OPTIONS env. variable was added and when testing for existence > > of build-arch was added). > > ... which was a fiasco. Doogie finally implemented the proposal and revert it > > dpkg (1.10.15) unstable; urgency=low > > * Back out debian/rules build-arch detection. It is *not* possible *at > all* to detect available targets in a rules file. Period. > > -- Adam Heath <[EMAIL PROTECTED]> Fri, 19 Sep 2003 20:02:19 -0500 > > The rationale are not available to me, but I trust him since he really > tried. I'd be interested to see doogie's rationale, but it's amusing enough as it stands, because the policy still says: If one or both of the targets `build-arch' and `build-indep' are not provided, then invoking `debian/rules' with one of the not-provided targets as arguments should produce a exit status code of 2. Usually this is provided automatically by make if the target is missing. ...thereby, in its trend of hinting at Make-specific stuff, going against the judgement of not one but two dpkg maintainers. -- 2. That which causes joy or happiness.
Re: Other nethack options
On Sun, Oct 19, 2003 at 11:11:15AM +0200, Adam Borowski wrote: > On Sat, 18 Oct 2003, Lukas Geyer wrote: > > Colin Watson <[EMAIL PROTECTED]> writes: > > > It's trivial to reconfigure it in nethack's option screen, just like any > > > other option. I'm not sure why this one should be special. > > hjkl is extremely newbie-unfriendly. And? Come on, this is *nethack*. It's the hardest game I know of, bar none. You have to learn a pile of keystroke commands when you first start up nethack anyway. Leave the newbie-friendliness to falconseye, which actually stands some chance of managing that rather than making a tiny concession in the form of number_pad. > Arrows require the player to manually turn NumLock on. > Both things need some action from a first-time user (be it reading the > help files, or finding out NumLock needs to be on). How long is a first-time user going to survive without reading the keystroke help files anyway? Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 02:57:44PM +1000, Andrew Pollock wrote: > On Sun, Oct 19, 2003 at 12:13:02PM +0800, Cameron Patrick wrote: > > Yeah, but you can do that on any given port whether it's open or not. e.g. > > > > cat /dev/zero | nc -u victim 12345 > > > > (nc in UDP mode seems to ignore "ICMP port unreachable" packets in my > > testing... if it doesn't you can always use iptables to make sure it > > does.) > > > > There's no way to /stop/ someone from sending you data, whether you want > > it or not. > > Sure, with UDP you're stuffed regardless. Do we really need to be shipping > sarge with it listening on more (TCP) ports than necessary though? Getting worried about this kind of denial of service is pointless. Denial of service attacks are only worth worrying about when they're significantly cheaper for the attacker than for you, and even then they are often better handled at an upstream router. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: how to ask for packages rebuilding
Op zo 19-10-2003, om 10:44 schreef Stefano Zacchiroli: > On Fri, Oct 17, 2003 at 10:55:41AM +0200, Sven Luther wrote: > > So all seems well, and to be in the hand of the autobuilders. The > > Actually the situation is still the same, so I think that we should do > something. > > I've never understood which is the right/polity way of requests for > triggering a new rebuild of packages. Should I ask on -devel, -admin, > the per architecture mailing lists or where? You should first check what the status of your package is, by going to http://buildd.debian.org/stats/ . I wrote some documentation on what the different states actually mean; you can find it at http://people.debian.org/~wouter/wanna-build-states If that convinces you that human intervention is required (that's not always the case), you should contact the people that can actually do something about it, so the per architecture mailing lists. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
销售各种透视镜。
本公司新进一批透视镜，有需要的朋友请速联系。 1、数码相机（或者摄像机）红外线透视镜，各种规格，戴上它，能穿透各种针织物品、纤维物品、塑料等。 价格：90元/片。 2、麻将透视隐形眼镜，在微弱的灯光下，就能清晰地看见所有麻将牌，随时都能让您想赢就赢。 价格：120元/付。 3、覆盖密码透视眼镜，戴上这眼镜，无需刮卡即可以清晰地看出任何充值卡等覆盖下的密码。 价格：85元/付。 E-mail:[EMAIL PROTECTED] 精益公司
Bug#216518: ITP: oneliner-el -- Extensions of Emacs standard shell-mode
Package: wnpp Severity: wishlist * Package name: oneliner-el Version : 0.3.5 Upstream Author : Kiyoka Nishiyama <[EMAIL PROTECTED]> * URL or Web page : http://oneliner-elisp.sourceforge.net/ * License : GPL2 Description : Extensions of Emacs standard shell-mode oneliner-el provides nice extensions for UNIX shell masters, who loves one-liner scripts. This package has the following functions. . - You can connect command input/output to/from Emacs buffer with easy operation. - You can sync directory-value between shell-mode and shell process. - Oneliner-el gives you notice with beep when command execution was complete. - Oneliner-el handles control codes. OHURA Makoto: [EMAIL PROTECTED](Debian Project) [EMAIL PROTECTED](LILO/Netfort) GnuPG public key: http://www.netfort.gr.jp/~ohura/gpg.asc.txt fingerprint: 54F6 D1B1 2EE1 81CD 65E3 A1D3 EEA2 EFA2 77DC E083 http://www.netfort.gr.jp/~ohura/ pgpsmZTEfK5hR.pgp Description: PGP signature
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
Cc'd to debian-devel, because I'm honestly unsure about this... On Sun, 2003-10-19 at 09:51, Adam Conrad wrote: > Package: libtool > Version: 1.5-3 > Severity: serious > > libtool fails to build from source on all the buildds[1] due to a missing > build-dep on texi2html. > libtool (and libtool1.4) *have* a build-dep on texi2html (and texinfo): Build-Depends-Indep: debhelper (>= 4.0), texi2html, texinfo Build-Depends: debhelper (>= 4.0), file, g77 | fortran77-compiler, gcj [!hppa !mips !mipsel] My reading of policy suggests that this is correct: 8<8<8<8<8<8<8<8< `Build-Depends-Indep', `Build-Conflicts-Indep' The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must be satisfied when any of the following targets is invoked: `build', `build-indep', `binary' and `binary-indep'. [1] If you make "build-arch" or "binary-arch", you need Build-Depends. If you make "build-indep" or "binary-indep", you need Build-Depends and Build-Depends-Indep. If you make "build" or "binary", you need both. >8>8>8>8>8>8>8>8 texinfo and texi2html are used in the "build" target. As far as I can tell this means that the buildd should be ensuring both Build-Depends and Build-Depends-Indep are installed before running it. Have I read policy wrong, or is policy not entirely in accord with reality? > [1] http://buildd.debian.org/build.php?arch=&pkg=libtool > [2] http://buildd.debian.org/build.php?arch=&pkg=libtool1.4 > The hppa, mipsel and mips builds didn't fail because of this -- they failed because they couldn't satisfy the dependency on gcj which is marked [!hppa !mips !mipsel]. Is this dpkg being broken? Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 01:20:26PM +0200, Josip Rodin wrote: > I'd be interested to see doogie's rationale, but it's amusing enough as it > stands, because the policy still says: > > If one or both of the targets `build-arch' and `build-indep' are > not provided, then invoking `debian/rules' with one of the > not-provided targets as arguments should produce a exit status > code of 2. Usually this is provided automatically by make if the > target is missing. I believe something among the line of "Not-provided targets as arguments should produce a exit status code of 2, but the converse is not true, therefore we cannot discriminate between unprovided targets and targets that lead to an error condition." Independently of the `Manoj vs Wichert' match, I would be interested at fixing the build-arch issue at last. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: ITH: gnugo, gnugo-dv
Martin Godisch <[EMAIL PROTECTED]> writes: > I intend to hijack the gnugo package, and to ask for removal of the > gnugo-dv package. Both packages were updated last time around 18 months > ago, there are outstanding bug reports, none with a maintainer's comment, > and I'd like to get the new upstream release into unstable. gnugo-dv was > intended to be the development version of gnugo, but is now older than > gnugo itself. I tried talking to the maintainer two times, without reply. > Please CC me, if you have any objections. I don't have objections, I just found it curious that Brian is actually not MIA, e.g. his latest mail to #171769 is only 6 days old. Brian, I think it would be best just to tell Martin that it is OK to take the package. And Martin, it really looks like he doesn't particularly care about the package, so if you already have a package ready, I don't mind you hijacking it to get it in sarge. And for a development version which is not actively maintained, well... kill it. :) Best regards, Lukas
Re: Source only uploads?
Hi, Wouter Verhelst wrote:
> Sven Luther:
>> Well, we just need an arch: all autobuilder and that's it, or one of the
>> autobuilders building the arch: all stuff.
>
> Feel free to set up one.
I have my personal i386 autobuilder running that way for some months now.
It makes sense; I certainly have caught quite a few problems with it --
there's not just the missing-dependency problem that makes packages
non(re)buildable.
Sure, some uploaded packages will be unbuildable, which would generate
more work for the builders, but that problem is solveable. For example, we
could block a package from building when two other autobuilders have
reported a failure on it. That would have the added benefit to place
somewhat less load on already-overworked architectures like m68k.
My vote would be to Just Do It. I can certainly help set up and/or admin a
few autobuilders for i386, if that's what it takes.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Nasrudin called at a large house to collect for charity. The servant said
"My master is out." Nasrudin replied, "Tell your master that next time he
goes out, he should not leave his face at the window. Someone might steal it."
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
Scott James Remnant <[EMAIL PROTECTED]> wrote: > On Sun, 2003-10-19 at 09:51, Adam Conrad wrote: [...] >> libtool fails to build from source on all the buildds[1] due to a missing >> build-dep on texi2html. > libtool (and libtool1.4) *have* a build-dep on texi2html (and texinfo): > Build-Depends-Indep: debhelper (>= 4.0), texi2html, texinfo > Build-Depends: debhelper (>= 4.0), file, g77 | fortran77-compiler, gcj [!hppa > !mips !mipsel] > My reading of policy suggests that this is correct: > 8<8<8<8<8<8<8<8< > `Build-Depends-Indep', `Build-Conflicts-Indep' > The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must > be satisfied when any of the following targets is invoked: > `build', `build-indep', `binary' and `binary-indep'. > > [1] If you make "build-arch" or "binary-arch", you need Build-Depends. If > you make "build-indep" or "binary-indep", you need Build-Depends and > Build-Depends-Indep. If you make "build" or "binary", you need both. > >8>8>8>8>8>8>8>8 > texinfo and texi2html are used in the "build" target. As far as I can > tell this means that the buildd should be ensuring both Build-Depends > and Build-Depends-Indep are installed before running it. > Have I read policy wrong, or is policy not entirely in accord with > reality? [...] Afaik the latter, the buildds don't build the binary-all target and won't install Build-Depends-Indep. This works: * If your package only builds arch-dependent packages, don't use Build-Depends-Indep * If your package only builds binary-all packages, you can choose whether to use Build-Depends-Indep or Build-Depends. However many packages need Build-Dependencies for the clean target (dh_clean), if this applies you must use "Build-Depends". * If your package builds both binary-arch and binary-all packages, list anything needed for build, clean, build-arch and binary-arch in "Build-Depends" and anything _additionally_ needed for binary-indep in "Build-Depends-Indep". It is noteworthy that the split build-arch/build-all seems to be next to useless, as dpkg-buildpackage invokes build (because the former two a optional) and "the build target should depend on those of the targets build-arch and build-indep that are provided in the rules file." If you want to keep the buildds from running/requiring texi2html do it in the binary-all target. cu andreas
Re: Other nethack options
Colin Watson <[EMAIL PROTECTED]> writes: > On Sun, Oct 19, 2003 at 11:11:15AM +0200, Adam Borowski wrote: > > hjkl is extremely newbie-unfriendly. > > And? Come on, this is *nethack*. It's the hardest game I know of, bar > none. You have to learn a pile of keystroke commands when you first > start up nethack anyway. Have you tried slashem? Well, it is a nethack variant, so maybe you included it in the statement, but I would actually say it is harder than nethack. :) > Leave the newbie-friendliness to falconseye, which actually stands some > chance of managing that rather than making a tiny concession in the form > of number_pad. I don't like number_pad either, because my main computer is a laptop, but I don't really care either way. > > Arrows require the player to manually turn NumLock on. > > Both things need some action from a first-time user (be it reading the > > help files, or finding out NumLock needs to be on). > > How long is a first-time user going to survive without reading the > keystroke help files anyway? Funnily, I know some newbies/computer illiterates who like to play nethack. And they have probably never read the help file, but had someone explain the keystrokes to them. (Some people seem to get allergic shock reactions when exposed to manuals...) However, I agree with Colin that nethack is not intended to be self-explanatory without the manuals or help files. I like this discussion because I like nethack, and arguing about best options or ascension equipment. (Do you wear amulet of life saving or reflection? A crystal ball to detect the portals on the elemental planes? Do you use cockatrice eggs? ...) However, I also find this discussion utterly insignificant, as nethack is only a game and num_pad is really something that can be changed in a second by the user. It would be slightly more relevant to discuss what compile-time options to turn on, but then I also leave that to the discretion of the maintainer(s). Lukas
Re: Source only uploads?
On Sat, Oct 18, 2003 at 09:39:05PM +0100, Andrew Suffield wrote: > On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: > > Its good for the autobuilders to check again if a package builds in a > > mainly minimal environment. > > That's an argument for building it *once* in such an environment. It > is definitely not an argument that it should only be built in such an > environment, which was the point in question. Ok, no problem. I suppose you just volunteered to fix all the bugs against my packages that fail due to broken dependency brought in by using experimental packages. And you also volunteer to replace the autobuilders and build _every_ package out there by hand on _every_ architecture ? Have you seriously thought about what you are proposing here ? Naturally, i build my packages in my own enviornment, but i try not to upload those, since i may miss build-dependencies, and some of the stuff running on my system may break the upload. I run upstream out of CVS X for example, and have the experimental X packages installed too. Friendly, Sven Luther
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Sun, Oct 19, 2003 at 03:22:11PM +0200, Andreas Metzler wrote: > It is noteworthy that the split build-arch/build-all seems to be next > to useless, as dpkg-buildpackage invokes build (because the former two > a optional) and "the build target should depend on those of the > targets build-arch and build-indep that are provided in the rules > file." Why exactly is this? Is this really the correct behavior? Shouldn't dpk-buildpackage be invoked using the -B option? -- gram signature.asc Description: Digital signature
RE: Bug#216492: FTBFS (unstable/all) missing build-dep
Graham Wilson wrote: > > Why exactly is this? Is this really the correct behavior? Shouldn't > dpk-buildpackage be invoked using the -B option? It is. `dpkg-buildpackage -B' invokes debian/rules clean, build, binary-arch. ... Adam
Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 04:20 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > But it's a historic injustice, Help! Help! I'm being repressed! The Man is keeping me down! Up with perl, down with make! Power to the people! Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
Graham Wilson <[EMAIL PROTECTED]> wrote: > On Sun, Oct 19, 2003 at 03:22:11PM +0200, Andreas Metzler wrote: >> It is noteworthy that the split build-arch/build-all seems to be next >> to useless, as dpkg-buildpackage invokes build (because the former two >> a optional) and "the build target should depend on those of the >> targets build-arch and build-indep that are provided in the rules >> file." > Why exactly is this? Is this really the correct behavior? Shouldn't > dpk-buildpackage be invoked using the -B option? It is, and quoting /usr/bin/dpkg-buildpackage ... | -B) binaryonly=-B; checkbuilddep_args=-B; binarytarget=binary-arch; [...] | if [ x$sourceonly = x ]; then | withecho debian/rules build | withecho $rootcommand debian/rules $binarytarget | fi ... this invokes debian/rules build Afaict the reason for this is that build-arch and build-all are optional targets per policy. cu andreas -- Hey, da ist ein Ballonautomat auf der Toilette! Unofficial _Debian-packages_ of latest unstable _tin_ http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote: > > But it's a historic injustice, > > Help! Help! I'm being repressed! > The Man is keeping me down! > Up with perl, down with make! > Power to the people! We share an enthusiasm for overloaded phrases, I see :) but a small verbal blunder doesn't invalidate the issue at hand. -- 2. That which causes joy or happiness.
Re: how to ask for packages rebuilding
On Sun, Oct 19, 2003 at 12:15:40PM +0200, Wouter Verhelst wrote: > Op zo 19-10-2003, om 10:44 schreef Stefano Zacchiroli: > > On Fri, Oct 17, 2003 at 10:55:41AM +0200, Sven Luther wrote: > > > So all seems well, and to be in the hand of the autobuilders. The > > > > Actually the situation is still the same, so I think that we should do > > something. > > > > I've never understood which is the right/polity way of requests for > > triggering a new rebuild of packages. Should I ask on -devel, -admin, > > the per architecture mailing lists or where? > > You should first check what the status of your package is, by going to > http://buildd.debian.org/stats/ . I wrote some documentation on what the > different states actually mean; you can find it at > http://people.debian.org/~wouter/wanna-build-states Yep, this is the case, we naturally check these kind of things first. > If that convinces you that human intervention is required (that's not > always the case), you should contact the people that can actually do > something about it, so the per architecture mailing lists. Packages that need to be rebuilt on m68k are : gdome2-xslt, gtkmathview and lablgtkmathview => gdome2-xslt was last tried on Oct 12, and failed to build because of gdome2, altough gdome2 was sucessfully built on Oct 9. The two other packages depend on gdom2-xslt in a chained way (first gtkmathview and then lablgtkmathview). netclient, ocamlnet, pcre-ocaml, xstr and pxp. => netclient depends on ocamlnet, which depends on pcre-ocaml which depends on findlib, which was sucessfully built in the same Oct 12 run the other failed. pxp depends on ocamlnet and findlib and wlex, xstr depends on findlib, which was built in the same run. All these packages could be built without problem, if they are rescheduled and built in order. So, i know you maintain a m68k autobuilder, could you do it, or should i ask on debian-68k ? This is in an effort to get all the 40 or so ocaml packages ready to enter testing by friday/saturday next week, so it would be nice if they could be rebuilt. Friendly, Sven Luther
x windows wont start
refuses to start and the retry process fails also...??? thanks for any advice. stuart stuart [EMAIL PROTECTED]
Re: x windows wont start
On Sun, Oct 19, 2003 at 07:21:57PM +0100, stuart whittaker wrote: > refuses to start and the retry process fails also...??? > > > thanks for any advice. > > stuart > > stuart [EMAIL PROTECTED] This sounds like a user question and not a dev question. No? Usually x doesn't start because of problems with the server configuration. Have you looked at the X log (/var/log/XFree86*) ?
Re: Source only uploads?
On Sun, Oct 19, 2003 at 05:57:55PM +0200, Sven Luther wrote: > On Sat, Oct 18, 2003 at 09:39:05PM +0100, Andrew Suffield wrote: > > On Sat, Oct 18, 2003 at 03:32:41PM +0200, Goswin von Brederlow wrote: > > > Its good for the autobuilders to check again if a package builds in a > > > mainly minimal environment. > > > > That's an argument for building it *once* in such an environment. It > > is definitely not an argument that it should only be built in such an > > environment, which was the point in question. > > Ok, no problem. I suppose you just volunteered to fix all the bugs > against my packages that fail due to broken dependency brought in by > using experimental packages. You have a significant number of such bugs? That's like standing up in a crowded room and announcing you have a highly contagious skin disease. > And you also volunteer to replace the autobuilders and build _every_ > package out there by hand on _every_ architecture ? > > Have you seriously thought about what you are proposing here ? What are you talking about? I'm not the one proposing anything. The proposal was "All packages should be built in an artificial environment of this form". I have pointed out that this is a braindamaged idea. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Bug#216492: FTBFS (unstable/all) missing build-dep
On Sun, Oct 19, 2003 at 01:20:39PM +0100, Scott James Remnant wrote:
> On Sun, 2003-10-19 at 09:51, Adam Conrad wrote:
>
> > Package: libtool
> > Version: 1.5-3
> > Severity: serious
> >
> > libtool fails to build from source on all the buildds[1] due to a missing
> > build-dep on texi2html.
> >
> libtool (and libtool1.4) *have* a build-dep on texi2html (and texinfo):
>
> Build-Depends-Indep: debhelper (>= 4.0), texi2html, texinfo
> Build-Depends: debhelper (>= 4.0), file, g77 | fortran77-compiler, gcj [!hppa
> !mips !mipsel]
>
> My reading of policy suggests that this is correct:
>
> `Build-Depends-Indep', `Build-Conflicts-Indep'
> The `Build-Depends-Indep' and `Build-Conflicts-Indep' fields must
> be satisfied when any of the following targets is invoked:
> `build', `build-indep', `binary' and `binary-indep'.
>
> [1] If you make "build-arch" or "binary-arch", you need Build-Depends. If
> you make "build-indep" or "binary-indep", you need Build-Depends and
> Build-Depends-Indep. If you make "build" or "binary", you need both.
>
> texinfo and texi2html are used in the "build" target. As far as I can
> tell this means that the buildd should be ensuring both Build-Depends
> and Build-Depends-Indep are installed before running it.
Other people have covered why this breaks. Here's the solution I use:
Make your build target do nothing.
That is, make build an empty target that does _not_ depend on
build-arch and build-indep. Then make sure that binary-{arch,indep}
will result in the right things getting run anyway.
This a) preserves the desired effect of the time consuming arch-indep
stuff not being run on the buildds, and b) actually works. While it's
not strictly in accord with policy as written, it has the advantage of
doing what policy expected to happen, and I've never seen a better
idea.
Ultimately we should either deprecate the build* targets, or make
build-{arch,indep} mandatory and deprecate build.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: udev 0.3 package
* Marco d'Itri wrote: > http://www.bofh.it/~md/debian/ Any plans for an upload to unstable? -- - nobse
Re: how to ask for packages rebuilding
Op zo 19-10-2003, om 20:04 schreef Sven Luther: > On Sun, Oct 19, 2003 at 12:15:40PM +0200, Wouter Verhelst wrote: > > Op zo 19-10-2003, om 10:44 schreef Stefano Zacchiroli: > > > I've never understood which is the right/polity way of requests for > > > triggering a new rebuild of packages. Should I ask on -devel, -admin, > > > the per architecture mailing lists or where? > > > > You should first check what the status of your package is, by going to > > http://buildd.debian.org/stats/ . I wrote some documentation on what the > > different states actually mean; you can find it at > > http://people.debian.org/~wouter/wanna-build-states > > Yep, this is the case, we naturally check these kind of things first. > > > If that convinces you that human intervention is required (that's not > > always the case), you should contact the people that can actually do > > something about it, so the per architecture mailing lists. > > Packages that need to be rebuilt on m68k are : > > gdome2-xslt, gtkmathview and lablgtkmathview > > => gdome2-xslt was last tried on Oct 12, and failed to build because > of gdome2, altough gdome2 was sucessfully built on Oct 9. The two > other packages depend on gdom2-xslt in a chained way (first > gtkmathview and then lablgtkmathview). > > netclient, ocamlnet, pcre-ocaml, xstr and pxp. > > => netclient depends on ocamlnet, which depends on pcre-ocaml which > depends on findlib, which was sucessfully built in the same Oct 12 run > the other failed. pxp depends on ocamlnet and findlib and wlex, xstr > depends on findlib, which was built in the same run. These all boil down to the same problem: ocaml was upgraded to ocaml-3.07, while the packages that were available at the time depended on ocaml-3.06-1. Since that doesn't exist anymore, they'll never become needs-build again. Under normal circumstances we find such things ourselves, but since we've got quite some backlog currently... I just instructed wanna-build to pretend ocaml-3.06-1 is available; all packages depending on ocaml-3.06-1 should at least be in needs-build again. > All these packages could be built without problem, if they are > rescheduled and built in order. > > So, i know you maintain a m68k autobuilder, could you do it, or should i > ask on debian-68k ? Does that help? ;-) > This is in an effort to get all the 40 or so ocaml packages ready to > enter testing by friday/saturday next week, so it would be nice if they > could be rebuilt. I can't promise anything about that, but at least they're re-scheduled again. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org If you're running Microsoft Windows, either scan your computer on viruses, or stop wasting my bandwith and remove me from your addressbook. *now*. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Source only uploads?
Op zo 19-10-2003, om 15:25 schreef Matthias Urlichs:
[...]
> For example, we
> could block a package from building when two other autobuilders have
> reported a failure on it. That would have the added benefit to place
> somewhat less load on already-overworked architectures like m68k.
Please, no. Our autobuilder architecture is only half-automated for a
reason. I won't trust any computer to *reliably* decide whether a build
failed because of a transitional problem (unresolved build-depends,
network problems, ...), because it shouldn't be built ("architecture"
header in debian/control), because of architecture-specific problems
(toolchain), or because there was a bug in the package. Your suggestion
would only be The Right Thing in the last case...
(no particular objection to the rest of your mail, though)
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
If you're running Microsoft Windows, either scan your computer on
viruses, or stop wasting my bandwith and remove me from your
addressbook. *now*.
signature.asc
Description: Dit berichtdeel is digitaal ondertekend
Re: how to ask for packages rebuilding
On Sun, Oct 19, 2003 at 12:15:40PM +0200, Wouter Verhelst wrote: > You should first check what the status of your package is, by going to > http://buildd.debian.org/stats/ . I wrote some documentation on what the > different states actually mean; you can find it at > http://people.debian.org/~wouter/wanna-build-states Thanks, this really helps. > If that convinces you that human intervention is required (that's not > always the case), you should contact the people that can actually do > something about it, so the per architecture mailing lists. Ok Cheers. -- Stefano Zacchiroli -- Master in Computer Science @ Uni. Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} - http://www.bononia.it/zack/ " I know you believe you understood what you think I said, but I am not sure you realize that what you heard is not what I meant! " -- G.Romney signature.asc Description: Digital signature
Re: Bug#88029: Package which uses jam (instead make)
On 19-Oct-03, 13:03 (CDT), Josip Rodin <[EMAIL PROTECTED]> wrote: > On Sun, Oct 19, 2003 at 11:50:41AM -0500, Steve Greenland wrote: > > > But it's a historic injustice, > > > > Help! Help! I'm being repressed! > > The Man is keeping me down! > > Up with perl, down with make! > > Power to the people! > > We share an enthusiasm for overloaded phrases, I see :) > but a small verbal blunder doesn't invalidate the issue at hand. No, it doesn't, but it doesn't validate it either. I've yet to see a technical argument for allowing debian/rules to be a non-makefile. If you really want to write the script in a different format, it's trivial to meet the letter of Policy: #!/usr/bin/make -f % : debian/my_rules.py $@ That I've never seen such done (in my admittedly limited and random selection of packages to build by hand at various times) suggests that there's not much practical demand. Whenever it's come up, it seems to be someone trying to prove a point, rather than a technical need. Perhaps those who think alternative debian/rules should be allowed should implement the above, and see what breaks and what complaints it generates. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Source only uploads?
Wouter Verhelst writes:
> Our autobuilder architecture is only half-automated for a reason. I won't
> trust any computer to *reliably* decide whether a build failed because of
> a transitional problem (unresolved build-depends, network problems, ...),
> because it shouldn't be built ("architecture" header in debian/control),
> because of architecture-specific problems (toolchain), or because there
> was a bug in the package.
Yes, but it seems to me that if a package fails on the first two (or maybe
three) architectures that it might be a good idea to suspend further
autobuilding until someone can look into the problem. It doesn't seem
likely that many packages are going to fail on the first three
architectures and then succeed on all the others.
--
John Hasler
[EMAIL PROTECTED] (John Hasler)
Dancing Horse Hill
Elmwood, WI
Re: Source only uploads?
Hi, John Hasler wrote:
> Yes, but it seems to me that if a package fails on the first two (or maybe
> three) architectures
Thanks for the "first"; that additional word improves the heuristic
significantly.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Decorate your home. It gives the illusion that your life is more
interesting than it really is.
-- C. Schulz
Re: Bug#215945: ITP: etw -- arcade-style soccer game
Il mer, 2003-10-15 alle 17:58, Sam Hocevar ha scritto: > Package: wnpp > Severity: wishlist > > * Package name: etw > Version : CVS > Upstream Author : Gabriele Greco <[EMAIL PROTECTED]> > * URL : http://etw.sourceforge.net/ > * License : GPL > Description : arcade-style soccer game Yeah, a free and real soccer game! Now we are ready for the world domination! ;-)
Re: Bug#88029: Package which uses jam (instead make)
On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: > I've yet to see a technical argument for allowing debian/rules to be a > non-makefile. I've yet to see a technical argument for disallowing debian/rules from being a non-makefile. See, those two statements make the same amount of sense. Anyone can throw in gobs of make features that are handy, and also gobs of other interpreters' features that are handy as well. That doesn't make any one of them technical arguments for either. > If you really want to write the script in a different format, it's trivial > to meet the letter of Policy: And it's also trivial to change the letter of Policy, too. Contrary to what some may have said, replacing the crude "must" rule will not cause anything to happen other than fixing a spurious requirement that exists in the documentation only. No, new maintainers won't suddenly start shipping precompiled a.out debian/rules files. They probably won't start using vertical Perl either. In fact the most likely result is that not one thing will change, except that a tiny fraction of packages will no longer be in "violation of policy". > That I've never seen such done (in my admittedly limited and random > selection of packages to build by hand at various times) suggests that > there's not much practical demand. Whenever it's come up, it seems to be > someone trying to prove a point, rather than a technical need. I have had packages the rules file of which is not a makefile for years now. You didn't notice them, did you? That's probably because they (*gasp*!) work. And none of those purported NMUers ever complained about them either. Arguably that's because of other favourable circumstances, but nevertheless. The interface to the rules file is defined well enough, there's absolutely nothing wrong with having other things than /usr/bin/make abide by the same rules. -- 2. That which causes joy or happiness.
Bug#214946: Would like to take over this orphaned package.
Package: wnpp Severity: wishlist Followup-For: Bug #214946 Description: Display and edit lyrics with XMMS This "X Multi Media System" (XMMS) plugin displays formated lyrics. It also contains a lyrics editor, which can be used to tag timestamps in a song. Upstream Author: Jan-Marek Glogowski <[EMAIL PROTECTED]> Liscense: GPL Web site: http://stud.fbi.fh-darmstadt.de/~glogow/ Version: 0.1.28 -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux debian 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C
Re: Bug#88029: Package which uses jam (instead make)
On Mon, Oct 20, 2003 at 12:35:04AM +0200, Josip Rodin wrote: > On Sun, Oct 19, 2003 at 03:58:19PM -0500, Steve Greenland wrote: Summary of the auction so far: Steve bet on Manoj and Josip on Wichert. Deuce. > The interface to the rules file is defined well enough, there's absolutely > nothing wrong with having other things than /usr/bin/make abide by the same > rules. The interface to the rules file is insufficient since there is no mechanism to expand it while keeping backward compatibility. Since at this point, backward compatibility is more important that any new feature we might add, the problem calls for a technical solution that may or may not require debian/rules to be a Makefile (with a capital M). Solving this is in my opinion more important than continuing an historical flamewar. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here.
Re: Source only uploads?
On Sun, Oct 19, 2003 at 08:08:11PM +0100, Andrew Suffield wrote: > > And you also volunteer to replace the autobuilders and build _every_ > > package out there by hand on _every_ architecture ? > > > > Have you seriously thought about what you are proposing here ? > > What are you talking about? I'm not the one proposing anything. > > The proposal was "All packages should be built in an artificial > environment of this form". I have pointed out that this is a > braindamaged idea. Autobuilders already build packages "in an artificial" environment" for every architecture except the one the maintainer used for uploading. Surely making every package consistant on every architecture should be a goal for Debian? Sure, ideally the package should build exactly the same way where ever it is built, but differences can emerge with out being obvious, for instance if a package detects an extra library is installed on the maintainers machine and automatically uses it without the maintainer being aware of what is happening (this happened with early versions of Heimdal and libhesiod0 in fact). -- Brian May <[EMAIL PROTECTED]>
Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 01:53:15PM +1000, Andrew Pollock wrote: > On Sat, Oct 18, 2003 at 01:40:51AM -0400, Matt Zimmerman wrote: > > On Sat, Oct 18, 2003 at 11:04:31AM +1000, Andrew Pollock wrote: > > > > It's pretty trivial with netkit-inetd as well; you edit /etc/inetd.conf and > > comment out what you don't want. > > > > Additional packages that wish to register an (x)inetd based service can > just plonk a file in /etc/xinet.d, which is a bit more elegant than having > to script modifying a flat config file though. It's a bit more elegant, but no more or less functional. xinetd has enough problems that I don't think this particular feature justifies a switch. -- - mdz
Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 01:37:58PM +1000, Andrew Pollock wrote: > On Sat, Oct 18, 2003 at 09:32:54PM -0400, Matt Zimmerman wrote: > > Yes, it receives data from the network and throws it away. But I don't see > > how this figures into your example. If you can give me an scenario where > > this service would allow a malicious remote user to DoS anything other than > > the discard service itself, that would be interesting. Otherwise, I'm > > inclined to say that it's quite harmless (and indeed useful). > > Hmm, am I the only one that thinks > > dd if=/dev/zero | nc victim discard > > is a bad thing, in an environment where the victim is paying cents per meg > for inbound traffic? I'm no so much talking about DoSing anything, but > causing financial damage. Yes, I think you are the only one so far who thinks that this is any different, in terms of potential harm, from spraying exactly the same packets without anything listening on the discard port on the remote host. -- - mdz
何不付2天的薪水雇佣一名忠诚高效的业务员?
debian-devel:您好!何不付2天的薪水雇佣一名忠诚高效的业务员? 工作能力：一、整套的营销方案，低成本高效率。 二、任何网上可以找到的客户，我都可以联系上。 三、让更多的客户主动来点击公司的网站。 本工作室铁定是您最佳的合作伙伴，给您带来很多客户资源，我们的目标是降低公司40%的广 告成本、成为公司销售第一名。请您联系我，没有我做不到，只有我想不到，如果您没有联系 我，我不会灰心，我会继续联系您，请原谅我的坚持，因为这是我的个性。 个人简历： 姓名：创艺网络营销工作室（三亿二千万邮件地址库，邮件群发软件，信息发布软件、 定行业、定地区、定国家邮件地址搜索) 年龄：1岁 爱好：开发新客户，挖掘任何网上有价值的信息。 特点：找到任何行业、地区、国家的客户邮箱地址，做到高效、完全个性化的群发邮件 （文字、图片、网页、附件）。 学习情况：2位大学毕业生2年时间不断探索网络新生。 工作情况：在1年内不断积累经验自我完善,至今倍受好评。 我的要求：给我一个演示的机会 联系方式：0519-6996612（晚6点后） http://www.cework.com/email.asp 致 礼! 张先生 [EMAIL PROTECTED] 2003-10-20
Bug#120237: ITP: jboss
Package: wnpp Severity: wishlist Followup-For: Bug #120237 I intend to package jboss. I'll upload my.debgs to mentors.debian.org because I'm not an official debian developer yet. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux morpheus.int.abacus.ch 2.4.21-5-686 #1 Sun Aug 24 15:25:33 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
Re: nethack popularity contest - number_pad?
Adam Borowski <[EMAIL PROTECTED]> writes: > Call me a wimp wimp > The problem lies not in the basic four directions (hjkl), but in the > completely mad diagonals. They're plain unnatural and cumbersome to > use I _completely_ disagree -- I find the rogue diagonals astonishly smooth and natural to use (and requiring very little hand/finger movement). When I have the misfortune to use vi for something I constantly find myself trying to move diagonally! > By using these or similar, you can easily play using number_pad, without > having to suffer all the pains of vi keys. Of course, you _could_ just gird your loins a bit and learn to use the excellent keys that are already there. Wimp. -miles -- A zen-buddhist walked into a pizza shop and said, "Make me one with everything."
Re: netkit-inetd in sarge
On Sun, Oct 19, 2003 at 08:39:58PM -0400, Matt Zimmerman wrote: > > Yes, I think you are the only one so far who thinks that this is any > different, in terms of potential harm, from spraying exactly the same > packets without anything listening on the discard port on the remote host. Righto, back in my box then. Andrew
Re: faster boot
I had some preliminary modifications of the parallel loading system proposed by James Hunt from IBM working for Debian, but it looked like it would speed things up less than 10%, which wasn't enough to lure me away from SysV, so I said it aside. I still have some of the files around, if you want 'em. I don't subscribe to this list, though, so email me directly. Z > hello > > there has been a lot of interest lately on tecniques to obtain a faster boot; for example > http://www-106.ibm.com/developerworks/linux/library/l-boot.html http://www.fefe.de/minit/ http://www.ussg.iu.edu/hypermail/linux/kernel/0204.0/0674.html http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/ > I would be delighted to have a faster boot: my boot times (excluding BIOS) are > 60sec-90sec (using the ditributed kernel by Herbert XU), and this is very long > (particularly for my Freevo-box) is anyone trying to implement the above in Debian? is anyone interested? > a.
