Booting - new idea?
Hello, booting takes usually tens of seconds and it's based on starting and running different programs. Is it possible to skip this part of booting? Particularly, is it possible to save the state of hardware and memories during shutdown and upload them during boot time? I suppose, this would minimize booting time, if it is technically possible to realize and start programs this way? If there is already this kind of project going on, I'd like to hear about it. Regards, Arto -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
Hi On Thu, 29 Jun 2006 13:57:09 +0300 Arto Inkala <[EMAIL PROTECTED]> wrote: > booting takes usually tens of seconds and it's based on starting and > running different programs. Is it possible to skip this part of booting? > > Particularly, is it possible to save the state of hardware and memories > during shutdown and upload them during boot time? I suppose, this would > minimize booting time, if it is technically possible to realize and > start programs this way? > > If there is already this kind of project going on, I'd like to hear > about it. Software suspend which exists in kernel for several years? -- Michal Čihař | http://cihar.com | http://blog.cihar.com signature.asc Description: PGP signature
Re: News from the python policy transition
On Wed, 28 Jun 2006, Raphael Hertzog wrote: > We also have many python applications (or badly packaged modules which > have not been caught by the first mass-bug filing) that have a dependency > "python (<< 2.4)" and that needs to be updated as well. Please find the > list below (~150 packages). The maintainers concerned have to follow the > same instructions than the maintainers of modules/extensions: > http://wiki.debian.org/DebianPython/NewPolicy Of course, it has been ported to my attention that packages already converted to the new policy but who are only supporting the current versions (like apps with private extensions) still have this dependency... and it's _normal_. So there are false positives in the list. It's also true that packages with (only) private extensions do not benefit much from the transition to the new policy, apart from offering a way to identify them more easily. The main point of the new policy was for public modules/extensions. In fact, the new dh_python even has a bug that lead to an incomplete dependency in some cases for packages with private extensions. (I have patch and I will send it to debhelper's BTS) Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem with root on LVM on RAID (was: RFT: please test mdadm/experimental)
also sprach martin f krafft <[EMAIL PROTECTED]> [2006.06.28.1927 +0200]: > Thank $DEITY for testers. We discovered another issue when root is > on LVM is on RAID. If that's your setup, please hold off on using > mdadm 2.5 until I managed to fix #375879. Sorry for the > inconvenience, and again, thanks to Alec Berryman for his help. He > also spotted the last issue. This issue is fixed in 2.5.2-2. While it's waiting for the mirror pulse, you can get it from http://debian.madduck.net/repo/dists/experimental/main/binary-i386/admin/mdadm_2.5.2-2_i386.deb http://debian.madduck.net/repo/dists/experimental/main/binary-amd64/admin/mdadm_2.5.2-2_amd64.deb mdadm (2.5.2-2) experimental; urgency=low . * The "if it weren't for Munich's wheat beer, there'd be no" release. * Removed -fno-strict-aliasing from compiler options, after upstream fixed the bug that led to its use (see #369779, #356153). Thanks to Elimar Riesebieter for pointing this out (closes: #375876). * Moved detection of RAID devices from initramfs hook to debconf control file, and added a (low-priority) debconf question as to which devices should be started early in the boot sequence. For the cases where we failed to auto-detect previously (e.g. root on LVM on RAID), it's paranoid and suggests to start them all (closes: #375879). Thanks to Alec Berryman for spotting this. * Fixed a typo in README.experimental, which could lead to an unbootable system with initramfs-tools 0.64 or before. Again, thanks to Alec for spotting this. * Extended bug script to include --examine output for all components (at least if called by root, which hopefully should never happen. Err, wait...) * Reworded the debconf templates due to a new question, and also for readability. * Disabled deprecation warning in mdrun until the transition is complete. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "zwei monologe, die sich gegenseitig immer und immer wieder störend unterbrechen, nennt man eine diskussion." -- charles tschopp signature.asc Description: Digital signature (GPG/PGP)
Re: Booting - new idea?
On Thu, 2006-06-29 at 13:57 +0300, Arto Inkala wrote: > Hello, > > booting takes usually tens of seconds and it's based on starting and > running different programs. Is it possible to skip this part of booting? > > Particularly, is it possible to save the state of hardware and memories > during shutdown and upload them during boot time? I suppose, this would > minimize booting time, if it is technically possible to realize and > start programs this way? You mean suspend to disk ? -- Yves-Alexis Perez
Re: additions to dpkg-architecture
Brendan O'Dea <[EMAIL PROTECTED]> writes: > On Fri, Jun 23, 2006 at 06:54:49PM +0200, Volker Grabsch wrote: >>I propose to add more CPU types to dpkg-architecture. In particular, >>I'd like to see the different i386 architectures there, i.e. >>i586, i686, k6, ... > [...] >>For instance, some programs with lots of calculations (e.g. mplayer) >>are compiled with different processor optimizations (e.g. mplayer-i586). >>Such packages are created by very redundant entries in debian/rules. >>Exactly such redundancy is removed by dpkg-cross. > > While there are certainly some packages which may benefit from > compilation with sub-architecture optimisations, those packages are the > exception rather than the norm. > > It may make sense to provide multiple versions of the kernel for > example, and perhaps glibc... but coreutils? grep? > > Do you propose re-building all packages for each sub-arch? If so, > please consider the resulting increace in archive size and impact on > mirrors. That would be quite wastefull as anyone can see. > If only a sub-set, how are you intending to change dpkg, apt and/or the > archive software to handle opportunistic installation of sub-arch > packages with fallback (i.e. try foo.i686, fallback to foo.i386)? You add multiple entries to apts sources.list or have an extra file listing allowed subarchs for a system (autodetection can't be used to allow installing on a different cpu than the final sytem will use). Apt then fetches multiple packages files and simply the order of the sources.list entries (or the archs in the extra file) will say what to prefer if there are overlaps. If you don't want to patch dpkg/apt for subarchs you can simply setup an archive with main, main-i586 and main-i686 all with packages for architecture i386 but different -mcpu/arch settings for gcc. Apt already handles that just fine. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
Volker Grabsch <[EMAIL PROTECTED]> writes: > Dear Debian Developers, > > I've been pleased to summarize some ideas for the general public. > More details and sources can be found at the end of this mail. > I'm not subscribed to all lists, so please CC any replies to me. > > -- > > I propose to add more CPU types to dpkg-architecture. In particular, > I'd like to see the different i386 architectures there, i.e. > i586, i686, k6, ... > > The dpkg-cross tool is currently only used for cross compiling > applications. However, dpkg-cross is a more generic tool. The > "dpkg-buildpackage" wrapper of dpkg-cross allows you to compile > a package with different compilers, without the need to change > your debian/rules. (usually, some compatibility changes are needed > to make the debian/rules file "cleaner", but that's all) > > For instance, some programs with lots of calculations (e.g. mplayer) > are compiled with different processor optimizations (e.g. mplayer-i586). > Such packages are created by very redundant entries in debian/rules. > Exactly such redundancy is removed by dpkg-cross. > > Also, these optimized versions get names like "mplayer-i586", > but their architecture is set to "i386". That means, the *real* > architecture is encoded in the package name instead of the package's > architecture. > > This is a work around the inability of apt to automatically use > the best suited binary packages. (e.g. uses on a i686 system the > mplayer-i586 instead if mplayer-i386, and the kernel-image-i686) > > If one day apt evolves, packages like mplayer-i586 will step in their > way. The "Package:" field should not contain architectural information. > The "Architecture:" field serves that purpose. > > Until APT becomes aware of multiple architectures, this won't change > much. However, there are still lots of interesting cases where > more architectures are desirable. The amd64 project has long ago patched apt for biarch (i386 + amd64). At the same time people have played around with having i[56]86 as subarchitectures of i386 as well. The patch to apt (and dpkg) for this is rather simple and adds the following syntax to sources.list: deb http://ftp.debian.org/debian sarge main deb http://ftp.debian.org/debian sarge(i586) main deb http://ftp.debian.org/debian sarge(i686) main If wanted the patches could be freshened up for etch/sid quickly. > For example, suppose you support a new OS, such as the w32 platform. > Currently, your only choice is "w32-i386", which means that you must > use an i486-mingw32msvc Compiler. However, for a w32 system a i486 > compile doesn't make a lot of sense. Since those systems (except very > old Windows versions) need at least a Pentium, it is reasonable to > compile such a distribution at least for i586, not i486. The only sensible choice would be w32, w32-i486 or w32-i586. Nothing dictates the use of -i386 in a new architecture name. > That means, the "linux" OS dictates that i386 should mean "at least > i486", while other OSes (e.g. win32) have different needs (e.g. "at > least i586"). Such dependencies between the OS and CPU type are simply > unnecessary and disturbing. > > In that example, there should be a "linux-i386" platform (which may > be abbreviated to i386), while dpkg-architecture should also allow > a Debian platform like "w32-i586". This proposal is similar to > the addition of multiple arm CPU variants to dpkg-architecture. > > Of course, if you want to allow, e.g. the -i386 packaes to be installed > on a -i586 distribution, some bigger parts of dpkg and apt would have > to be changed. However, that is not my proposal at all. I don't intend > to create a w32-i586 Debian distribution which must also accept w32-i386 > packages. I want to create an entire w32-i586 distribution. > (well, currently, I just want to provide cross compiling packages for > such a platform) The biggest challenge would be a good configuration of dpkg for what subarchs to allow on a system. Patching the architecture check to allow more archs is rather trivial then. Think about those people that install their harddisk on a fast Opetron and then put the disk back into their old i586 system. Having apt/dpkg install i686 packages there would be bad. > I also heard about people who compiled a whole (Debian based) system > for i586 to increase the overall performance of their system. They, > too, had the same problem: How to name this architecture/cpu? As far > as I remember, they "solved" that problem by adding a "pentium" line > (or similar, AFAIR) to their cputable. > > Thus, I don't think it is the question whether one wants to compile > for i586, i686, etc. There are always good reasons for some groups to > do so. IMHO, the more important question is how to name that thing. So > it would be very nice if dpkg-architecture would be flexible enough to > support that, instead of stepping in the way. The lack of any larger pus
Re: additions to dpkg-architecture
Baurzhan Ismagulov <[EMAIL PROTECTED]> writes: > On Tue, Jun 27, 2006 at 02:21:13PM +0200, Alexander Shishkin wrote: >> On 6/23/06, Volker Grabsch <[EMAIL PROTECTED]> wrote: >> >For instance, some programs with lots of calculations (e.g. mplayer) >> >are compiled with different processor optimizations (e.g. mplayer-i586). >> >Such packages are created by very redundant entries in debian/rules. >> >Exactly such redundancy is removed by dpkg-cross. >> mplayer is not in debian, so that doesn't make a good example. > > Just for the record, I had a problem with openssh having been compiled > for generic SPARC and running painfully slowly on SPARC v8 systems. > Rebuilding with v8 enabled helped dramatically (virtually instant > connection instead of 10+ seconds depending on the CPU model, measured > with a wrist watch). > > With kind regards, > Baurzhan. Sparc is the most extrem case that I know of though giving the biggest speedup for crypto code. This example has come up in the past and I thought someone would have added an ssh-sparc8 package with optimized ssh by now. This is one of the cases that are worth it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards
On Wed, Jun 28, 2006 at 10:32:30PM -0400, Bdale Garbee wrote: > On Wed, 2006-06-28 at 10:36 +0200, Bill Allombert wrote: > > In addition, I would suggest we reinstate the previous behaviour, but > > display a warning when wildcards are used but --wildcards is not set. > > The problem with this is that generating a new warning can also cause > people to need to update scripts, since lots of people seem to parse the > output of commands like tar in wrapper scripts. So, I'm not convinced > that this is really a good idea. I'm also always hesitant to deviate > Debian default behavior for utilities like tar from upstream. Well, but the new tar is already generating warning anyway and people parsing tar stderr output get what they deserve. It is Debian role to provide transition plan when upstream break backward compatibility, and we do that on a large scale. > All in all, I'm not yet convinced that reverting to the old wildcard > behavior is the right thing to do. I've only heard about problems in a > few (four?) packages so far, and all of them are Debian-specific > programs that should be easy for us to update. I see no need for panic, > though it's obviously and clearly regrettable that the packages in > questions are ones that affect processes like building and testing > Debian packages. But we have not yet even started to check for breakage. Someone could start to rebuild the whole archive with the new tar and report problem, check every maintainer script in sarge and etch, etc. I have to say I am a bit surprised you did not even test if the basic packaging tools still worked before uploading the package, especially given some previous incidents. In such case, it is better to upload the package to experimental, report bugs found in other packages, and then upload to unstable when the scope of the breakage is better understood. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: additions to dpkg-architecture
* Goswin von Brederlow <[EMAIL PROTECTED]> [060629 12:31]: > Baurzhan Ismagulov <[EMAIL PROTECTED]> writes: > > for generic SPARC and running painfully slowly on SPARC v8 systems. > > Rebuilding with v8 enabled helped dramatically (virtually instant > > connection instead of 10+ seconds depending on the CPU model, measured > > with a wrist watch). > > Sparc is the most extrem case that I know of though giving the biggest > speedup for crypto code. This example has come up in the past and I > thought someone would have added an ssh-sparc8 package with optimized > ssh by now. This is one of the cases that are worth it. | You have searched for the contents of libssl0.9.7 in stable, | architecture sparc. Package contains 9 files, displaying files 1 to 9. | | usr/lib/libcrypto.so.0.9.7 | usr/lib/libssl.so.0.9.7 | usr/lib/v8/libcrypto.so.0.9.7 | usr/lib/v8/libssl.so.0.9.7 | usr/lib/v9/libcrypto.so.0.9.7 | usr/lib/v9/libssl.so.0.9.7 | usr/share/doc/libssl0.9.7/changelog.Debian.gz | usr/share/doc/libssl0.9.7/changelog.gz | usr/share/doc/libssl0.9.7/copyright In other words: Problem solved since sarge. Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: News from the python policy transition
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : > So you don't have any excuse to not update your packages any more. > About 60% of the Python modules have already been updated, but 109 > are left to be done: > http://bugs.debian.org/from:[EMAIL PROTECTED] > > The bugs have been filled two weeks ago, it is now time to NMU the > remaining packages where the maintainer didn't gave any update plan > in the bug report. We need your help for that. I've done 16 of them already. that has also fixed 2 RC bugs as a side effect (uninstallability bugs). 7 other person like me, and it's old story ! -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAgdlvRLAT0.pgp Description: PGP signature
Re: News from the python policy transition
On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote: > Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : >> So you don't have any excuse to not update your packages any more. >> About 60% of the Python modules have already been updated, but 109 >> are left to be done: >> http://bugs.debian.org/from:[EMAIL PROTECTED] >> >> The bugs have been filled two weeks ago, it is now time to NMU the >> remaining packages where the maintainer didn't gave any update plan >> in the bug report. We need your help for that. > > I've done 16 of them already. that has also fixed 2 RC bugs as a side > effect (uninstallability bugs). > > 7 other person like me, and it's old story ! I noticed the original list didn't include the python-gmenu package. The source package (gnome-menus) produces some regular machine code packages as well as the python module package. Perhaps there are others like this? -- /home/sam/.sig -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian mactel linux support?
Hi I've got hold of an intel mac that I'm interested in getting Debian running. I've seen quite a few folks running Debian on MacBook Pro at Debconf in Mexico, and I'm surprised that there aren't Debian packages. The things I'm planning on doing are follows: Code packages fix gnu-efi (bug: #376000) fix elilo (bug: #376002) ITP rEFIt (bug: #375999) (I've filed bugs to track their progress) Debian-installer: elilo-installer is not built for ia32 (http://lists.debian.org/debian-boot/2006/06/msg00185.html) erfit-installer ? Anyone already working on these stuff? I don't quite grok how I can make erfit be the default bootloader without access to MacOSX command-line to 'bless', I hope I can find out as I delve deeper. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: News from the python policy transition
Le jeu 29 juin 2006 16:37, Sam Morris a écrit : > On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote: > > Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit : > >> So you don't have any excuse to not update your packages any more. > >> About 60% of the Python modules have already been updated, but 109 > >> are left to be done: > >> http://bugs.debian.org/from:[EMAIL PROTECTED] > >> > >> The bugs have been filled two weeks ago, it is now time to NMU the > >> remaining packages where the maintainer didn't gave any update > >> plan in the bug report. We need your help for that. > > > > I've done 16 of them already. that has also fixed 2 RC bugs as a > > side effect (uninstallability bugs). > > > > 7 other person like me, and it's old story ! > > I noticed the original list didn't include the python-gmenu package. > The source package (gnome-menus) produces some regular machine code > packages as well as the python module package. Perhaps there are > others like this? that's possible, you are welcomed to open the right bugs... -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdXAaF2DXa4.pgp Description: PGP signature
Re: Debian mactel linux support?
On Fri, Jun 30, 2006 at 12:57:55AM +0900, Junichi Uekawa wrote: > I don't quite grok how I can make erfit be the default bootloader > without access to MacOSX command-line to 'bless', I hope I can find > out as I delve deeper. Is this the same "blessing" on a hfs filesystem like on ppc based macs? If it's like that you can bless a directory with hattrib from hfsutils. Gaudenz -- Ever tried. Ever failed. No matter. Try again. Fail again. Fail better. ~ Samuel Beckett ~ pgpaOZ7lp9Jzg.pgp Description: PGP signature
Re: Debian mactel linux support?
On Thursday 29 June 2006 17:57, Junichi Uekawa wrote: > Debian-installer: > elilo-installer is not built for ia32 > (http://lists.debian.org/debian-boot/2006/06/msg00185.html) > > Anyone already working on these stuff? There has been some work done on the installer (including uploading elilo installer for i386 to the archive...). There does not seem to be a real drive behind this though. Owners of such machines are welcome to jump in and contact us on the debian-boot list. Cheers, FJP pgpYdoFWtlGS5.pgp Description: PGP signature
Re: Debian mactel linux support?
Junichi Uekawa <[EMAIL PROTECTED]> wrote: > fix gnu-efi (bug: #376000) I'm sure this is a dupe of a bug I filed, but I can't find it right now. > I don't quite grok how I can make erfit be the default bootloader > without access to MacOSX command-line to 'bless', I hope I can find > out as I delve deeper. You can't. Intel Mac blessing is different to traditional HFS stuff - it's not too difficult to do the blessing, but we have no way of generating HFS+ filesystems without resorting to APSLed code and that seems to be the only useful bootable format. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Dropping indirect dependencies from libgnutls-config --libs
Hello, currently "libgnutls-config --libs"' output looks like this, -L/usr/lib -lgnutls -L/usr/lib -ltasn1 -lgcrypt -lgpg-error listing both direct (-lgnutls) and indirect dependencies. - Its output can be used for static linking. I am pondering (and have now been asked by bts) on changing this to only say -lgnutls for Debian, which is enough for dynamic linking. - Static linking would be broken except for a) libtool using packages (.la lists the indirect dependencies) or b) packages using pkg-config --libs --static to get the indirect dependencies[1] This change is probably going to influence most of the autoconf using packages requiring gnutls, as AM_PATH_LIBGNUTLS is using libgnutls-config to find gnutls and the needed linker/compiler flags. I do not expect any resulting breakage (i.e. none or next to none in Debian packages) besides the one noted above, but perhaps I have missed something. I'd welcome to hear about your thoughts on this. thanks, cu andreas [1] Is this actually done somewhere? Letting libtool doing the fiddling sounds saner than constructing different compilerflags depending whether static linking is used. -- The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal vision of the emperor's, and its inclusion in this work does not constitute tacit approval by the author or the publisher for any such projects, howsoever undertaken.(c) Jasper Ffforde -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
These new diffs are great, but...
Is it at all useful/better for apt-get to use the .pdiff files when dealing with a local (file://) debian repo? Thanks, Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new tar behavior and --wildcards (proposed middle ground)
[EMAIL PROTECTED] (Barak A. Pearlmutter) writes: > As a compromise that addresses some of the issues I would suggest the > following: go with upstream, but add some convenience code, to whit: > > (1) Hot-wire tar to check an environment variable TAR_WILDCARD_DEFAULT > and activate the --wildcard option if set. I'm not sure I see the point of this. The warnings/errors generated seem reasonably obvious, and inventing an additional, less-obvious mechanism instead of just assuming people will try --wildcard when tar suggests it seems like a step in the wrong direction. > (2) Hot-wire tar to print a warning message to stderr if it > (a) is defaulting to the --no-wildcard behaviour and, > (b) it notices a filename that, had tar instead been > in --wildcards mode, would have been expanded. Actually, tar already does this. I realize now that you must not have actually seen the warning in question, which helps explain to me why you were suggesting (1) above. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Booting - new idea?
> Software suspend which exists in kernel for several years? And works properly in Debian since what? Weeks? Months? :-) signature.asc Description: Digital signature
Re: Booting - new idea?
On 6/29/06, Christian Perrier <[EMAIL PROTECTED]> wrote: > Software suspend which exists in kernel for several years? And works properly in Debian since what? Weeks? Months?:-) It doesn't really work properly anywhere, does it? :-P regards, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
#195752: Can somebody mark this bug as grave or critical?
I just did an upgrade, and laptop-net caused my network interface to disappear. This is documented here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=195752 laptop-net restarts network interfaces when it is upgraded. This is *nasty*. If you are upgrading over a network, this causes your controlling terminal to disappear, leaving dpkg hung. If other packages are being upgraded at the same time, this can leave the entire system in an unusable state. Furthermore, if the network restart fails for some reason, the entire box is essentially killed: $ ssh [EMAIL PROTECTED] ssh: connect to host fliplid port 22: No route to host I'm *FURIOUS* that this bug has caused me to lose access to my laptop, and incredulous that THIS HAS BEEN A BUG FOR THREE YEARS!!! ... especially because it's configured to just leave the network interface alone when it's working. It's only supposed to drop/raise connections when the cable is unplugged/plugged in. *sigh* Looking at the bug's history it seems like they've tried to fix it a few times and failed. I guess I'm going to purge this package and just do an ifdown/ifup manually when I need to from now on. But yeah, I'm not in an official position to say, but if this isn't considered a "critical" or at least "grave" bug, then I don't know what is. - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dropping indirect dependencies from libgnutls-config --libs
On Thu, Jun 29, 2006 at 07:38:56PM +0200, Andreas Metzler <[EMAIL PROTECTED]> wrote: > Hello, > currently "libgnutls-config --libs"' output looks like this, > -L/usr/lib -lgnutls -L/usr/lib -ltasn1 -lgcrypt -lgpg-error > listing both direct (-lgnutls) and indirect dependencies. - Its output > can be used for static linking. > > I am pondering (and have now been asked by bts) on changing this to > only say -lgnutls for Debian, which is enough for dynamic linking. - > Static linking would be broken except for > a) libtool using packages (.la lists the indirect dependencies) > or > b) packages using pkg-config --libs --static to get the indirect > dependencies[1] I got a similar report on libxml2, which suggested the use of xml2-config --libs to get the direct libs and xml2-config --libs --static to get everything. Same semantics as pkg-config. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
also sprach Tyler MacDonald <[EMAIL PROTECTED]> [2006.06.29.2005 +0200]: > Is it at all useful/better for apt-get to use the .pdiff files > when dealing with a local (file://) debian repo? Not really. pdiff's mainly reduce download size for low bandwidth connections. file:// is pretty high bandwidth, you won't notice the difference. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system only by counting could humans demonstrate their independence of computers. -- douglas adams, "the hitchhiker's guide to the galaxy" signature.asc Description: Digital signature (GPG/PGP)
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote: > Not really. pdiff's mainly reduce download size for low bandwidth > connections. file:// is pretty high bandwidth, you won't notice the > difference. I usually notice the difference -- the other way. "aptitude update" on a machine that hasn't been updated in a while suddenly takes minutes instead of seconds... /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote: > > Not really. pdiff's mainly reduce download size for low bandwidth > > connections. file:// is pretty high bandwidth, you won't notice the > > difference. > > I usually notice the difference -- the other way. "aptitude update" on a > machine that hasn't been updated in a while suddenly takes minutes instead of > seconds... Yes, this is what I'm getting at. :-) Should this be considered a bug in apt-get (file:// urls should never use diffs)? - Tyler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #195752: Can somebody mark this bug as grave or critical?
severity 195752 critical thanks also sprach Tyler MacDonald <[EMAIL PROTECTED]> [2006.06.29.2029 +0200]: > But yeah, I'm not in an official position to say, but if this > isn't considered a "critical" or at least "grave" bug, then > I don't know what is. Agreed. I tried to ping the release team on IRC before, but they were all busy it seemed. So since changing severity isn't a final, irreversible action, I am just doing it. -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP)
Re: new tar behavior and --wildcards (proposed middle ground)
Oops, guess I should have checked if it was already done. My bad. (Given that the warning is working, why were people making such a fuss? Well, never mind.) -- Barak A. Pearlmutter <[EMAIL PROTECTED]> Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland http://www.bcl.hamilton.ie/~barak/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Steinar H. Gunderson wrote: > On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote: >> Not really. pdiff's mainly reduce download size for low bandwidth >> connections. file:// is pretty high bandwidth, you won't notice the >> difference. > > I usually notice the difference -- the other way. "aptitude update" on a > machine that hasn't been updated in a while suddenly takes minutes instead of > seconds... Same here. Very annoying on a box where you only update every few weeks or something. Wouldn't it be possible to make snapshots every week and only pdiff from this snapshot? Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#25837: chance of a lifetime
Hib there lovely, I was seaarching the neta few days ago. I am new to this thing. and bsaw your profile. I decided to emaila you acause aI found youb attractive. I might come down to ybour city in few weeks. Let me know if we can meet each other in person. I am attractive girl. I am sure you won't regret it. Reply to my personal email at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Tyler MacDonald on 2006-06-29 11:43:45 -0700: > Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: > > On Thu, Jun 29, 2006 at 08:35:41PM +0200, martin f krafft wrote: > > > Not really. pdiff's mainly reduce download size for low bandwidth > > > connections. file:// is pretty high bandwidth, you won't notice the > > > difference. > > > > I usually notice the difference -- the other way. "aptitude update" on a > > machine that hasn't been updated in a while suddenly takes minutes instead > > of > > seconds... > > Yes, this is what I'm getting at. :-) Should this be considered a > bug in apt-get (file:// urls should never use diffs)? See bug #372712. To disable pdiffs, use: apt-get update -o Acquire::PDiffs=false signature.asc Description: Digital signature
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 09:15:13PM +0200, Bastian Venthur wrote: > Same here. Very annoying on a box where you only update every few weeks > or something. Wouldn't it be possible to make snapshots every week and > only pdiff from this snapshot? You can turn off pdiffs if you'd like to; the old packages files are still there. The question here is what to do with the default. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Steinar H. Gunderson wrote: > On Thu, Jun 29, 2006 at 09:15:13PM +0200, Bastian Venthur wrote: >> Same here. Very annoying on a box where you only update every few weeks >> or something. Wouldn't it be possible to make snapshots every week and >> only pdiff from this snapshot? > > You can turn off pdiffs if you'd like to; the old packages files are still > there. The question here is what to do with the default. Ah ok, I was not aware of this feature. But since downloading pdiffs of > x days might in fact result in a larger download than downloading the package-files directly, aptitude (or apt-get) should decide automatically when to use pdiffs and when not. Someone could make stats to calculate the average day-count x when the summ of the pdiffs becomes larger that the package-files. Then aptitude (or apt-get) could decide whether the last update is more than x days away and decide what to use. Should not be too hard to implement. We had still the advantage of using pdiffs for the users who update regulary but no drawbacks for all the other ones. Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
also sprach Bastian Venthur <[EMAIL PROTECTED]> [2006.06.29.2135 +0200]: > Someone could make stats to calculate the average day-count x when the > summ of the pdiffs becomes larger that the package-files. Then aptitude > (or apt-get) could decide whether the last update is more than x days > away and decide what to use. Nice idea. I suggest "Someone" == "Bastian Venthur" :) -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system "common sense is the collection of prejudices acquired by age eighteen" -- albert einstein signature.asc Description: Digital signature (GPG/PGP)
Re: These new diffs are great, but...
martin f krafft wrote: > also sprach Bastian Venthur <[EMAIL PROTECTED]> [2006.06.29.2135 +0200]: >> Someone could make stats to calculate the average day-count x when the >> summ of the pdiffs becomes larger that the package-files. Then aptitude >> (or apt-get) could decide whether the last update is more than x days >> away and decide what to use. > > Nice idea. I suggest "Someone" == "Bastian Venthur" :) Sure, I will be on vacation for the next week but when I'm back and nothing changed, I'll have a look at it. Best regards, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: #195752: Can somebody mark this bug as grave or critical?
On Thu, 2006-06-29 at 20:43 +0200, martin f krafft wrote: > severity 195752 critical > thanks > > also sprach Tyler MacDonald <[EMAIL PROTECTED]> [2006.06.29.2029 +0200]: > > But yeah, I'm not in an official position to say, but if this > > isn't considered a "critical" or at least "grave" bug, then > > I don't know what is. > > Agreed. I tried to ping the release team on IRC before, but they > were all busy it seemed. So since changing severity isn't a final, > irreversible action, I am just doing it. I've only recently picked up this package as maintainer. Nonetheless, I agree it's a very nasty bug. As a long-time user, doing updates via the network all the time, I'm surprised I haven't run into it myself My apologies that the bug has stayed open for so long; I'm still sorting through all the bug reports to understand and prioritize them. This one definitely goes to the top of the list of Things To Do and I'll repair it as quickly as I can. -- Ciao, al -- Al Stone Alter Ego: Open Source and Linux R&D Debian Developer Hewlett-Packard Company http://www.debian.org E-mail: [EMAIL PROTECTED][EMAIL PROTECTED] -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 09:35:09PM +0200, Bastian Venthur wrote: > Someone could make stats to calculate the average day-count x when the > summ of the pdiffs becomes larger that the package-files. Then aptitude > (or apt-get) could decide whether the last update is more than x days > away and decide what to use. it might be easier to just generate fewer diffs on the server side, if there is no matching diff available apt will fall back to using the standard method. you will however find out that the size of all diffs together is already less than the size of the regular packages file. disabling diffs for file/cdrom urls makes perfect sense imho... cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 10:53:14PM +0200, Robert Lemmen wrote: > it might be easier to just generate fewer diffs on the server side, if > there is no matching diff available apt will fall back to using the > standard method. you will however find out that the size of all diffs > together is already less than the size of the regular packages file. There is a penalty per-request (both on the client and the server side), and a penalty for piecing the diffs back together on the receiving end, both of which are > ε. /* Steinar */ -- Homepage: http://www.sesse.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Thu, Jun 29, 2006 at 09:35:09PM +0200, Bastian Venthur wrote: > Steinar H. Gunderson wrote: > > On Thu, Jun 29, 2006 at 09:15:13PM +0200, Bastian Venthur wrote: > >> Same here. Very annoying on a box where you only update every few weeks > >> or something. Wouldn't it be possible to make snapshots every week and > >> only pdiff from this snapshot? > > > > You can turn off pdiffs if you'd like to; the old packages files are still > > there. The question here is what to do with the default. > > Ah ok, I was not aware of this feature. But since downloading pdiffs of > > x days might in fact result in a larger download than downloading the > package-files directly, aptitude (or apt-get) should decide > automatically when to use pdiffs and when not. > > Someone could make stats to calculate the average day-count x when the > summ of the pdiffs becomes larger that the package-files. Then aptitude > (or apt-get) could decide whether the last update is more than x days > away and decide what to use. You don't need stats for that, the Packages.diff/Index has the size in it. But what I don't get is that it seems to be downloading every file more than once. It atleast looks to be downloading twice as files as it should, but it more looks like it's downloading the same file 3 times if I look at the sizes. Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Robert Lemmen wrote: > standard method. you will however find out that the size of all diffs > together is already less than the size of the regular packages file. Yeah, looking at the average filesize of a diff compared to a packages file, I guess you'll need to wait like 100-200 days until the sum of the diffs becomes larger than the package file itself. However, downloading a 5meg file takes a few seconds on my boxes while downloading the diffs from 10-20days can take a few minutes, which is not very attractive. This is quite a dilemma since I understand that the bandwith of volunteering archive mirrors is not free. Since the main problem seems to be that downloading many small files can take much longer than downloading one big file, a compromise could be to provide only one diff. The trick: generate x diffs for: today-1day, today-2days .. today-x days so you only have do download one file if your last update is less than x days ago. A good compromise for x could be 50 days or something. The diffs would be reasonable small, fast to download and if your last update is more than x days ago you still could download the package file directly. This solution should keep the bandwidth utilization on the servers small (older diffs are less likely to be downloaded than the most recent ones) while being faster than the current (and even faster than downloading the whole packages) solution. Plus, you don't have to keep all the old diffs (only the last x ones) on the servers. Any ideas? Cheers, Bastian -- Bastian Venthur http://venthur.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376038: ITP: hpodder -- Tool to scan and download podcasts (podcatcher)
Package: wnpp Severity: wishlist Owner: John Goerzen <[EMAIL PROTECTED]> * Package name: hpodder Version : 0.5.0 Upstream Author : John Goerzen <[EMAIL PROTECTED] * URL : http://quux.org/devel/hpodder * License : GPL Programming Lang: Haskell Description : Tool to scan and download podcasts (podcatcher) Podcasting is a method of publishing radio-like programs on the Internet. Through podcasting, almost anyone can produce their own audio program, and publish episodes of it as often or as rarely as they like. . To listen to podcasts, you need a program to download the podcast's episodes from the Internet. Such a program is called a podcatcher (or sometimes a podcast aggregator). hpodder is this program. . hpodder's features include: . Convenient, easy to learn, and fast command-line interface. It's simple to do simple things, and advanced things are possible. . Automatic discovery of feed metadata . Full history database for accurate prevention of duplicate downlaods and tracking of new episodes . Conversion tools to convert your existing feed list and history from other applications to hpodder. Supported applications and formats include: castpodder and ipodder. . Most operations can work fully automatically across your entire podcast database, or they can work manually. . Automatic updating of ID3 (v1 and v2) tags based on metadata in the podcast feed. This important feature is available through iTunes but is often missed by other podcatchers. . hpodder operations can be easily scripted or scheuled using regular operating system tools. . Fully customizable naming scheme for downloaded episodes, including a name collision detection and workaround algorithm. . Automatic support for appending .mp3 extensions to MP3 files that lack them. . Numerous database and history inquiry tools . Small, minimalist footprint . Power users and developers can interact directly with the embedded Sqlite3 database used by hpodder. The database has a simple schema that is developer-friendly. . Support for resuming interrupted downloads of podcasts . hpodder is SAFE and is designed with data integrity in mind from the beginning. It should be exceedingly difficult to lose a podcast episode, even in the event of a power failure. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.15.6 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to execute a data-file's preferred app from the cmd-line?
Török Edvin dijo [Thu, Jun 22, 2006 at 09:23:32AM +0300]: > >kfmclient exec foobar.odt > What if I am using gnome? Should I use gnome-open then? > Ah, and how do I determine if I am running gnome or kde? > (look in the output of `ps x'?) Don't. The machine might be multiuser (i.e. LTSP). Its users will have different sessions. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-0154 / 1451-2244 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Reclaiming automake
* Scott James Remnant ([EMAIL PROTECTED]) wrote: > On Sun, 2006-06-25 at 19:11 -0400, Eric Dorland wrote: > > > Scott James Remnant dropped me an email recently, interested in > > improving the automake situation in Ubuntu and Debian[0]. > > > > [0] Their plan, which mirrors mine, is documented here: > > https://wiki.ubuntu.com/AutomakeTransition > > > If you could have another read through of that spec, now it's > post-draft, and make sure we're still both planning the same thing > that'd be great. I don't see any reason for Ubuntu to go a different > direction to Debian here. > > In particular I had a momentary thought about what packages should > actually depend/build-depend on now -- could you check that. The automaken | automake$VER is probably not wise. A new version of automake may not be fully backwards compatible. If it were, we wouldn't have these problems. Better to depend on a known version that works, or better still don't build depend on it at all and ship the generated files in the diff.gz. > > Now before I can implement this master plan, I need to fix all the > > packages that still build depend on "automake"[1]. To proceed with > > this I'd like to file wishlist bugs (with patches) against these > > packages one week from today. One week after that, with the Release > > Team's blessing, I'd like to start NMUing as much of these packages as > > I can. Once that is complete, I'd like to make the transition and > > raise the severity of any of bugs that remain. > > > We should probably work together to cut the time down to make these > patches. I'm going to get started on Saturday, and I'll be on IRC (#debian-devel) so if you (or anyone) want to join in the fun, we can coordinate there. I've just filed #376047 too, so any bugs filed should be made to block that one. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 signature.asc Description: Digital signature
Re: Debian mactel linux support?
Hi, > > fix gnu-efi (bug: #376000) > > I'm sure this is a dupe of a bug I filed, but I can't find it right now. Your bug is meant to be already fixed (#355252), but I see there are some deviations between Debian and Ubuntu (which you seem to maintain), I'm suspecting there might be problems with Debian code which is only updated about 3 months ago. > > I don't quite grok how I can make erfit be the default bootloader > > without access to MacOSX command-line to 'bless', I hope I can find > > out as I delve deeper. > > You can't. Intel Mac blessing is different to traditional HFS stuff - > it's not too difficult to do the blessing, but we have no way of > generating HFS+ filesystems without resorting to APSLed code and that > seems to be the only useful bootable format. I thought EFI should work with FAT (I was surprised to see blessing can be applied to HFS+ also), which is the first partition on the internal disk. I'm hoping that I can switch default boot through some kind of nvram setting. regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
Hi, > > Debian-installer: > > elilo-installer is not built for ia32 > > (http://lists.debian.org/debian-boot/2006/06/msg00185.html) > > > > Anyone already working on these stuff? > > There has been some work done on the installer (including uploading elilo > installer for i386 to the archive...). > There does not seem to be a real drive behind this though. Owners of such > machines are welcome to jump in and contact us on the debian-boot list. I'm planning on hacking on this part for this weekend's hackathon in Tokyo: 'CodeFestAkihabara' [1] . [1] https://members.fsij.org/trac/codefestakihabara2006/wiki regards, junichi -- [EMAIL PROTECTED],netfort.gr.jp} Debian Project -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
On 6/29/06, Junichi Uekawa <[EMAIL PROTECTED]> wrote: Hi I've got hold of an intel mac that I'm interested in getting Debian running. I've seen quite a few folks running Debian on MacBook Pro at Debconf in Mexico, and I'm surprised that there aren't Debian packages. The things I'm planning on doing are follows: Code packages fix gnu-efi (bug: #376000) fix elilo (bug: #376002) ITP rEFIt (bug: #375999) (I've filed bugs to track their progress) Debian-installer: elilo-installer is not built for ia32 (http://lists.debian.org/debian-boot/2006/06/msg00185.html) erfit-installer ? Anyone already working on these stuff? I don't quite grok how I can make erfit be the default bootloader without access to MacOSX command-line to 'bless', I hope I can find out as I delve deeper. Hi Junichi, Just to put on your radar: http://lists.debian.org/debian-kernel/2006/06/msg00210.html thanks, -- stratus -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Adam Borowski <[EMAIL PROTECTED]> writes: > On Wed, Jun 28, 2006 at 03:17:27AM +0200, Henning Makholm wrote: >> > If package maintainer wants to build it faster on their own machine, I >> > would imagine that checking for an environment variable (DEB_MAKE_OPTS >> > or something, perhaps?) and using that would be the way to go. By >> > default, build with a single processor. > > This would affect every single package, and you can't do that. While > a vast majority of C code will build correctly, not every package is > SMP-safe. [1] > >> If I understand the problem correctly, it is not even necessary to >> modify debian/rules to get this behavior. If the interdependencies >> are properly declared, >> >> $ debian/rules -j42 binary >> >> should do the trick, as GNU make is smart enough to pass the option >> down to sub-makes that it starts. > > Actually, this is a bad idea; debian/rules are specifically the kind > of makefiles that typically rely on the order in which dependencies > are built. This is a bug as it breaks make -k, but as -k hardly ever > makes sense with regard to debian/rules, this is nearly totally > untested. What relies on the order and why should it? Every target in debian/rules should have the correct dependencies listed and force make to build targets in the order required. That means binary* depends on install*, install on build, build on configure or whatever combination of targets are employed. I think it is sane to demand that all debian/rules files are concurency save and it is trivial to do so. The same can't be said for upstream makefiles though. Many sources don't build with -j option. I'm not sure if debian/rules should somehow enforce -j1 in those cases or if only packages that benefit from -jX should add support for some DEB_BUILD_OPTION or CONCURENCY_LEVEL env var. The later would always be the save option. The former would have lots of hidden bugs that prop up suddenly on rebuilds or security fixes. Maybe someone should do a complete archive rebuild with -j1 and -j4 on a smp system and compare the amount of failures to get an overview how bad it would be. > On the other hand, making builds significantly faster is not > something that you can shake a stick at. Typically make -jX is faster > even on uniprocessor, and I don't need to tell you why it's much > faster on SMP. > Too bad, a C++ build where every file takes 1GB memory obviously > should not be parallelized. Also, no one but the maintainer knows > whether a package is SMP-clean or not. You cannot guess this in an > automated way. That would point to using an env varibale > Thus, my counter-proposal: > Let's allow maintainers to use make -jX according to their common > sense, requiring obeying an env variable to opt out. and let the maintainer pass that env variable down a -jX. How about this option: We write a tool "concurency-helper" that gets a set of requirements of the source and outputs a suitable concurency level for current build host. Requirements could include: --package pkg Let the tool know what we build. The tool can have overrides in place for packages in case special rules apply. --max-concurency X || --non-concurent Limit the concurency, possibly to 1, for sources that have problems with it. Although such sources probably just shouldn't support this. --ram-estimate X [Y] Give some indication of ram usage. If the host has too little ram the concurency will be tuned down to prevent swapping. A broad indication +- a factor of 2 is probably sufficient. The [Y] would be to indicate ram usage for 32bit and 64bit archs seperately. Given the pointer size ram usage can vary between them a lot. --more-concurent Indicate that there are lots of small files that greatly benefit from interleaving I/O with cpu time. Try to use more concurency than cpus. The tool would look at those indicators and the hosts resources in both ram and cpus and figure out a suitable concurency level for the package from there. What do you think? > Rationale: > Nearly every buildd and nearly every user building the packages on > his own will benefit from -j2 [2], even on non-SMP. Unless it's a > piece of heavily-templated code, any modern box will have enough > memory to handle it. The maintainer know whether the code is heavily > templated or not. Mips, mipsel, arm and m68k won't benefit. The ram requirement just leads to poor cache performance or even excessive swapping in general. Sources and gcc are growing and growing and the ram of the buildds stays the same. On the other hand any modern system will build the source fast and the buildd will be idle most of the time so -j2 or not hardly matters. Wouldn't that indicate a preference to -j1? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
Adam Borowski <[EMAIL PROTECTED]> writes: > On Wed, Jun 28, 2006 at 07:50:50PM +0300, Lars Wirzenius wrote: >> ke, 2006-06-28 kello 18:43 +0200, Adam Borowski kirjoitti: >> > What do you think about going with Don Armstrong's suggestion >> > ($CONCURRENCY_LEVEL), while handling the default (no env var) my >> > way (decent memory => parallel, little memory => -j 1) instead of >> > Ingo's (-j 1 unless explicitely set)? >> >> I'm in favor of Ingo's approach. I don't think it is a good idea to >> hardcode assumptions of what is sufficient memory size into rules files; >> that's the kind of thing that is best done centrally. > > Still, the buildd admin has no way to estimate how much a sub-process > of a package is going to use, the maintainer has at least a rough > idea. Since the maintainer's action is needed anyway, he can as well > provide this estimate. > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally > disable any parallelism of this kind. One could patch make to use concurency when the ram permits. This would involves checking the current ram usage and forking more builds if there is enough as well as suspending submakes when swapping starts. But i guess that would greatly complicate make itself. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Robert Lemmen <[EMAIL PROTECTED]> writes: > it might be easier to just generate fewer diffs on the server side, if > there is no matching diff available apt will fall back to using the > standard method. you will however find out that the size of all diffs > together is already less than the size of the regular packages file. The problem for me is not the _size_ or the network bandwidth, it's that apt seems to spend a lot more _CPU_ (and disk I/O) time dealing with zillions of diffs -- e.g., it seems to save the updated Packages file to disk about every 10 downloaded pdiff files or so, and on my machine saving the Package file takes a good 20 seconds or so. As I've got a fast network connection, the "pdiff method" ends up being far more painful because of this behavior if it's been a long time since my last update. Of course, I can just disable pdiffs but (1) they're actually nice when I update frequently, and (2) it really ought to do something more optimal by default -- novice users won't know how to configure stuff. -Miles -- It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill. It was yours. [Greenpeace advertisement, New York Times, 25 February 1990] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
Kurt Roeckx <[EMAIL PROTECTED]> writes: > But what I don't get is that it seems to be downloading every > file more than once. It atleast looks to be downloading twice as > files as it should, but it more looks like it's downloading the > same file 3 times if I look at the sizes. Yeah I noticed this too -- some .pdiff files appeared to be downloaded dozens of times! -Miles -- The secret to creativity is knowing how to hide your sources. --Albert Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
"Bastian Venthur" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] Robert Lemmen wrote: standard method. you will however find out that the size of all diffs together is already less than the size of the regular packages file. Yeah, looking at the average filesize of a diff compared to a packages file, I guess you'll need to wait like 100-200 days until the sum of the diffs becomes larger than the package file itself. However, downloading a 5meg file takes a few seconds on my boxes while downloading the diffs from 10-20days can take a few minutes, which is not very attractive. This is quite a dilemma since I understand that the bandwith of volunteering archive mirrors is not free. Since the main problem seems to be that downloading many small files can take much longer than downloading one big file, a compromise could be to provide only one diff. The trick: generate x diffs for: today-1day, today-2days .. today-x days so you only have do download one file if your last update is less than x days ago. A good compromise for x could be 50 days or something. The diffs would be reasonable small, fast to download and if your last update is more than x days ago you still could download the package file directly. This solution should keep the bandwidth utilization on the servers small (older diffs are less likely to be downloaded than the most recent ones) while being faster than the current (and even faster than downloading the whole packages) solution. Plus, you don't have to keep all the old diffs (only the last x ones) on the servers. Any ideas? A very good idea. This is trading a slight increase in file space for bandwidth and speed. There is some additional server-side processing required, but diffing is realatively cheap. If reversible diffs are used then generating today's diffs requires only yesteday's Package file, the most recent (x-1) diffs from yesterday,and todays package file. Scripting a program to update the diffs would not be terribly hard. Once the diffs are updated, everything from yesterday can be discarded. Apt would always download the main package file if it was smaller than the appropriate diff. If it turns out that some of the diffs (the ones around today-x) are pretty large they can be compressed like the main package file. Regardless, diffs should obviously not be used for file:// Sources or cd-rom sources unless the user explicitly says otherwise. This is because it is normally faster to fetch the main file when using those sources. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mactel linux support?
"Junichi Uekawa" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I don't quite grok how I can make erfit be the default bootloader > without access to MacOSX command-line to 'bless', I hope I can find > out as I delve deeper. You can't. Intel Mac blessing is different to traditional HFS stuff - it's not too difficult to do the blessing, but we have no way of generating HFS+ filesystems without resorting to APSLed code and that seems to be the only useful bootable format. I thought EFI should work with FAT (I was surprised to see blessing can be applied to HFS+ also), which is the first partition on the internal disk. I'm hoping that I can switch default boot through some kind of nvram setting. Worst case: You have to abuse the firmware update released to facilitate Boot camp, and have that boot normal lilo. Perhaps not as nice as having EFI boot a bootload, or running a bootloader as an EFI application, but I think that is what most people are currently doing. Disclamer: I have not used a Mac. Ever. I have no experience with EFI. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: These new diffs are great, but...
On Thu, 29 Jun 2006 11:43:45 -0700, Tyler MacDonald <[EMAIL PROTECTED]> wrote: >Steinar H. Gunderson <[EMAIL PROTECTED]> wrote: >> I usually notice the difference -- the other way. "aptitude update" on a >> machine that hasn't been updated in a while suddenly takes minutes instead of >> seconds... > > Yes, this is what I'm getting at. :-) Should this be considered a >bug in apt-get (file:// urls should never use diffs)? file:// URLs are not the only issue here - aptitude update is also much slower than before on a hosted box which has 100 Mbit/s connectivity and could load the Packages.gz in, like, two seconds. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Re: These new diffs are great, but...
Miles Bader wrote: > Yeah I noticed this too -- some .pdiff files appeared to be downloaded > dozens of times! It prints the same pdiff filenames when downloading files with the same basename from different paths. Just to confuse things it does print out each seprate pdiff file 3 times, although my squid logs show it downloads each exactly once. My guess w/o reading the code is that one represents the download, one the extraction, and one the application of the diff. Get:15 2006-06-29-1245.21.pdiff [39.1kB] Get:16 2006-06-29-1245.21.pdiff [39.1kB] Get:17 2006-06-29-1245.21.pdiff [39.1kB] Get:18 2006-06-29-1245.21.pdiff [818B] Get:19 2006-06-29-1245.21.pdiff [818B] Get:20 2006-06-29-1245.21.pdiff [330B] Get:21 2006-06-29-1245.21.pdiff [330B] Get:22 2006-06-29-1245.21.pdiff [11.9kB] Get:23 2006-06-29-1245.21.pdiff [818B] Get:24 2006-06-29-1245.21.pdiff [330B] Get:25 2006-06-29-1245.21.pdiff [249B] Get:26 2006-06-29-1245.21.pdiff [11.9kB] Get:27 2006-06-29-1245.21.pdiff [249B] Get:28 2006-06-29-1245.21.pdiff [11.9kB] Get:29 2006-06-29-1245.21.pdiff [249B] Get:30 2006-06-29-1245.21.pdiff [4801B] Get:31 2006-06-29-1245.21.pdiff [4801B] Get:32 2006-06-29-1245.21.pdiff [4801B] 1151639470.951 4248 192.168.1.7 TCP_REFRESH_MISS/200 12975 GET http://archive.progeny.com/debian/dists/unstable/main/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 text/plain 1151639474.134 3183 192.168.1.7 TCP_REFRESH_MISS/200 12883 GET http://archive.progeny.com/debian/dists/unstable/contrib/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 text/plain 1151639477.004 2871 192.168.1.7 TCP_REFRESH_MISS/200 12884 GET http://archive.progeny.com/debian/dists/unstable/non-free/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 text/plain 1151639479.933 2929 192.168.1.7 TCP_REFRESH_MISS/200 12882 GET http://archive.progeny.com/debian/dists/unstable/main/source/Sources.diff/Index - DIRECT/216.37.55.114 text/plain 1151639480.474541 192.168.1.7 TCP_REFRESH_HIT/304 250 GET http://archive.progeny.com/debian/dists/unstable/contrib/source/Sources.diff/Index - DIRECT/216.37.55.114 - 1151639483.453 2980 192.168.1.7 TCP_REFRESH_MISS/200 12884 GET http://archive.progeny.com/debian/dists/unstable/non-free/source/Sources.diff/Index - DIRECT/216.37.55.114 text/plain 1151639486.507 3053 192.168.1.7 TCP_REFRESH_MISS/200 12884 GET http://archive.progeny.com/debian/dists/experimental/main/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 text/plain 1151639486.886379 192.168.1.7 TCP_REFRESH_HIT/304 249 GET http://archive.progeny.com/debian/dists/experimental/contrib/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 - 1151639487.205319 192.168.1.7 TCP_REFRESH_HIT/304 250 GET http://archive.progeny.com/debian/dists/experimental/non-free/binary-i386/Packages.diff/Index - DIRECT/216.37.55.114 - 1151639500.962 13757 192.168.1.7 TCP_MISS/200 39456 GET http://archive.progeny.com/debian/dists/unstable/main/binary-i386/Packages.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain 1151639501.693731 192.168.1.7 TCP_MISS/200 1214 GET http://archive.progeny.com/debian/dists/unstable/contrib/binary-i386/Packages.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain 1151639502.173480 192.168.1.7 TCP_MISS/200 727 GET http://archive.progeny.com/debian/dists/unstable/non-free/binary-i386/Packages.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain 1151639506.532 4358 192.168.1.7 TCP_MISS/200 12277 GET http://archive.progeny.com/debian/dists/unstable/main/source/Sources.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain 1151639506.973441 192.168.1.7 TCP_MISS/200 645 GET http://archive.progeny.com/debian/dists/unstable/non-free/source/Sources.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain 1151639508.952 1980 192.168.1.7 TCP_MISS/200 5200 GET http://archive.progeny.com/debian/dists/experimental/main/binary-i386/Packages.diff/2006-06-29-1245.21.gz - DIRECT/216.37.55.114 text/plain -- see shy jo signature.asc Description: Digital signature
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 03:22:48AM +0200, Goswin von Brederlow wrote: > The same can't be said for upstream makefiles though. Many sources > don't build with -j option. I'm not sure if debian/rules should > somehow enforce -j1 in those cases or if only packages that benefit > from -jX should add support for some DEB_BUILD_OPTION or > CONCURENCY_LEVEL env var. The later would always be the save > option. The former would have lots of hidden bugs that prop up > suddenly on rebuilds or security fixes. I'm strictly in favour of being on the safe side. If maintainers would start now to add -j4 to their makefiles, we would end in more FTBFS bugs, I guess, which is unnecessary and an extra burden for the porters and buildds. When we want to introduce some sort of concurrency builds, we should do it that way that the impact is as small as possible (opt-in). Start with some packages that are known to build fine with -jX and choose 1-2 buildds on some archs to implement this feature for a small test. > Maybe someone should do a complete archive rebuild with -j1 and -j4 on > a smp system and compare the amount of failures to get an overview how > bad it would be. Are there any m68k SMP machines? No, just joking. ;) I guess, some amd64 machines are fast enough to get some results in a reasonable time. For some more tests it would be nice if Martin M. (tbm) would do a rebuild on his machine park. He already did some archive rebuilds in the past and is experienced with this. This should show some pitfalls across the different archs. If anything goes well, the procedure could be implemented on all buildds. > > On the other hand, making builds significantly faster is not > > something that you can shake a stick at. Typically make -jX is faster > > even on uniprocessor, and I don't need to tell you why it's much > > faster on SMP. > > Too bad, a C++ build where every file takes 1GB memory obviously > > should not be parallelized. Also, no one but the maintainer knows > > whether a package is SMP-clean or not. You cannot guess this in an > > automated way. > That would point to using an env varibale I doubt that a single env variable would do the trick, as the discussion has shown. There are some showstoppers for smaller machines like huge C++ packages - at least when all processes ought to run on the local machine. This is a different matter when such processes would be distributed to other, more powerful machines with crosscompilers. > > Thus, my counter-proposal: > > Let's allow maintainers to use make -jX according to their common > > sense, requiring obeying an env variable to opt out. > and let the maintainer pass that env variable down a -jX. > How about this option: > We write a tool "concurency-helper" that gets a set of requirements of > the source and outputs a suitable concurency level for current build > host. Requirements could include: > --package pkg >Let the tool know what we build. The tool can have overrides in >place for packages in case special rules apply. > --max-concurency X || --non-concurent >Limit the concurency, possibly to 1, for sources that have problems >with it. Although such sources probably just shouldn't support this. > --ram-estimate X [Y] >Give some indication of ram usage. If the host has too little ram >the concurency will be tuned down to prevent swapping. A broad >indication +- a factor of 2 is probably sufficient. The [Y] would >be to indicate ram usage for 32bit and 64bit archs seperately. >Given the pointer size ram usage can vary between them a lot. > --more-concurent >Indicate that there are lots of small files that greatly benefit >from interleaving I/O with cpu time. Try to use more concurency >than cpus. > The tool would look at those indicators and the hosts resources in > both ram and cpus and figure out a suitable concurency level for the > package from there. > What do you think? Of course this is a more complex approach, but I think it's an approach into the right direction. I would like to have settings for distcc to get added (like --use-distcc and --distcc-hosts) > > Rationale: > > Nearly every buildd and nearly every user building the packages on > > his own will benefit from -j2 [2], even on non-SMP. Unless it's a > > piece of heavily-templated code, any modern box will have enough > > memory to handle it. The maintainer know whether the code is heavily > > templated or not. > Mips, mipsel, arm and m68k won't benefit. The ram requirement just > leads to poor cache performance or even excessive swapping in > general. Sources and gcc are growing and growing and the ram of the > buildds stays the same. > On the other hand any modern system will build the source fast and the > buildd will be idle most of the time so -j2 or not hardly matters. > Wouldn't that indicate a preference to -j1? Erm. Most modern systems are not in the need to necessarily speed up the build process because there are fast enou
Work-needing packages report for Jun 30, 2006
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 305 (new: 1) Total number of packages offered up for adoption: 85 (new: 3) Total number of packages requested help for: 22 (new: 0) Please refer to http://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: pythoncard (#375610), orphaned 2 days ago Description: wxPython-based GUI construction framework Reverse Depends: python-pythoncard pythoncard pythoncard-tools Installations reported by Popcon: 72 304 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/orphaned for a complete list. The following packages have been given up for adoption: gamin (#375226), offered 5 days ago Description: File and directory monitoring system Reverse Depends: apachetop gamin gnome-menus gnome-panel gnubiff kdelibs4-dev libgamin-dev libgamin0 libgnome-menu-dev libgnome-menu2 (5 more omitted) Installations reported by Popcon: 3715 gnu-smalltalk (#375649), offered 2 days ago Description: GNU Smalltalk - an implementation of Smalltalk-80 Installations reported by Popcon: 36 libfreezethaw-perl (#376033), offered today Description: legacy FreezeThaw perl module Reverse Depends: checkgmail libcrypt-simple-perl libdbix-dbschema-perl request-tracker3.4 svk Installations reported by Popcon: 699 82 older packages have been omitted from this listing, see http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: aboot (#315592), requested 371 days ago Description: Alpha bootloader: Looking for co-maintainers Reverse Depends: aboot aboot-cross dfsbuild ltsp-server Installations reported by Popcon: 49 apt-build (#365427), requested 61 days ago Description: Need new developer(s) Installations reported by Popcon: 417 athcool (#278442), requested 611 days ago Description: Enable powersaving mode for Athlon/Duron processors Installations reported by Popcon: 220 cvs (#354176), requested 126 days ago Description: Concurrent Versions System Reverse Depends: bonsai cvs-autoreleasedeb cvs-buildpackage cvs2cl cvs2html cvschangelogbuilder cvsconnect cvsd cvsdelta cvsps (16 more omitted) Installations reported by Popcon: 7156 docbook (#358522), requested 99 days ago Description: standard SGML representation system for technical documents Reverse Depends: alcovebook-sgml docbook-dsssl docbook-to-man sgmltools-lite Installations reported by Popcon: 3368 docbook-xml (#358520), requested 99 days ago Description: standard XML documentation system, for software and systems Reverse Depends: dblatex docbook-dsssl docbook-ebnf docbook-html-forms docbook-jrefentry docbook-mathml docbook-simple docbook-slides docbook-website docbook-xsl-stylesheets-ko (6 more omitted) Installations reported by Popcon: 8093 dpkg (#282283), requested 586 days ago Description: dselect: a user tool to manage Debian packages Reverse Depends: alien alsa-source apt-build apt-src backuppc build-essential clamsmtp crosshurd cvs-autoreleasedeb cvs-buildpackage (80 more omitted) Installations reported by Popcon: 13469 grub (#248397), requested 780 days ago Description: GRand Unified Bootloader Reverse Depends: bootsplash dfsbuild grub-splashimages grubconf replicator Installations reported by Popcon: 10213 gtkpod (#319711), requested 340 days ago Description: manage songs and playlists on an Apple iPod Installations reported by Popcon: 357 lirc (#364606), requested 66 days ago Description: Linux Infra-red Remote Control support Reverse Depends: digitaldj fbtv gkrellm-radio gxine irmp3 kradio liblircclient-dev lirc lirc-svga lirc-x (15 more omitted) Installations reported by Popcon: 7493 mwavem (#313369), requested 381 days ago (non-free) Description: Mwave/ACP modem support software Installations reported by Popcon: 7 nas (#354174), requested 126 days ago Description: The Network Audio System Reverse Depends: abakus acm acm4 adept alsaplayer-nas apollon ark arson asc audiooss (237 more omitted) Installations reported by Popcon: 9044 ntp (#373824), requested 14 days ago Description: Network Time Protocol: network utilities Reverse Depends: nagios-plugins-standard ntp-server radioclk Installations reported by Popcon: 8171 openssl (#332498), req
Re: These new diffs are great, but...
* Joey Hess <[EMAIL PROTECTED]> [2006-06-30 02:05]: > Just to confuse things it does print out each seprate pdiff file 3 > times, although my squid logs show it downloads each exactly once. > My guess w/o reading the code is that one represents the download, > one the extraction, and one the application of the diff. Your guess is correct, see #372504. "This is currently a UI problem. It displays the line three times, but it only downloads it in the first. The other two lines are unpack and rred (patch)." -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: make -j in Debian packages
On Fri, Jun 30, 2006 at 03:26:15AM +0200, Goswin von Brederlow wrote: > > Still, the buildd admin has no way to estimate how much a sub-process > > of a package is going to use, the maintainer has at least a rough > > idea. Since the maintainer's action is needed anyway, he can as well > > provide this estimate. > > And then the buildd admin can set CONCURRENCY_LEVEL to 1 to centrally > > disable any parallelism of this kind. > One could patch make to use concurency when the ram permits. This > would involves checking the current ram usage and forking more builds > if there is enough as well as suspending submakes when swapping > starts. But i guess that would greatly complicate make itself. And I doubt that upstream would implement this patch. OTOH, why not use something like weak-no-auto-build or the lists for timeouts in sbuild? That way each buildd admin could setup his own rules for each package. -- Ciao...//Fon: 0381-2744150 Ingo \X/ SIP: [EMAIL PROTECTED] 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]
