Re: Package distribution, a concept for a modern package distribution
> On Fri, Jun 24, 2005 at 06:14:46PM +0200, Otto Wyss wrote: > > The concept is based on an LDAP server (or simiar) as a replacement for > > the Packages file and on a P2P network for package distribution (see > > http://wyodesktop.sourceforge.net/index.php?page=pkgdist.html). IMO it > > would make a lot sense if this concept is discussed at the Debconf5. > > i actually wrote something that exported a local mirror/server's Packages.gz > file into an LDAP directory[1], as well as wrote the beginnings of an > add-on method to apt to query this server. as far as speed/transfer > efficiency goes, we're an order or two of magnitude at the very least. > however, there hasn't seemed to be much interest from others in my > continuing it, so i've been focusing on other things lately. > I've seen some messages about an LDAP implementation around last october but I couldn't find them. I'm quite sure an LDAP solution is much better than the current solution. But before implementing it, it has to be evaluated against other way so it's truely the best. > also, there's a limitation in apt that it expects the list of > packages to be retrieved through the same method as the packages > themselves, which would get a little hairy with LDAP (you don't want to > be holding the packages themselves, in LDAP of course). there could > be a quick-hack workaround for this by having ldap-ftp/ldap-http methods > that wrap around the ftp/http for the actual fetching, but a real fix > would be to patch apt to allow for this. such a patch would also make > it easier to distribute the packages list via other methodst too. > I wouldn't base any work on apt but start a complete new way of package distribution. The advantage is the stabe apt will keep on working while the new solution won't be hampered by any current limitation. IMO a P2P network would be a much better solution but yet again it has to be checked if it this is really true or if there are better alternatives. > anyway if there are more people interested in working on this, i'd be > willing to put my code in cvs/svn and start up an alioth project. > The best way to start a new package distribution is to name a place where it can be discussed off Debian-devel. Since this concept probably has many more implications, like what about Debian installer etc, I think it would make a lot of sense to first collect any pros and cons and discuss them at Debconf5 and possibly on a list. Since I can't attend Debconf5 myself I'd appreciate if someone could keep track of the discussion there and forward it to the list. So the first action should be to set up or name this package distribution list and start collecting arguments there. Besides, until a better place is found I'll keep "http://wyodesktop.sourceforge.net/index.php?page=pkgdist.html"; updated, so you may send any input to the wyodesktop-users list or directly to me (list would be better because less spam prone). O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wyoguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Package distribution, a concept for a modern package distribution
Since around last October, I've considered to make my concept for a modern package distribution public but I wanted to wait until Debian/sarge was released which is now the case. And since the Debconf5 in Helsinki is just around the corner it's about the right time. The concept is based on an LDAP server (or simiar) as a replacement for the Packages file and on a P2P network for package distribution (see http://wyodesktop.sourceforge.net/index.php?page=pkgdist.html). IMO it would make a lot sense if this concept is discussed at the Debconf5. I'm not actively work on this concept and its implementation since I've _no_ time, sorry. If someone else is interested just say so. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wyoguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Restoring lost keymap
Sorry if I ask here but nobody in debia-users seems to know an answer. During installation of console-tools a few weeks ago I lost the keymap of my swiss-german keyboard in the console. As typical console-tools doesn't have a man page and it's documentation is useless. Does anybody know how to restore (load) the correct keymap? The locales seems to be correct "DE_ch". O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Otto Wyss <[EMAIL PROTECTED]> writes: > > reply (that is what I get roughly) to the server would waste 75 hours > on waiting for the initial three-way handshake for a connect. And > another 50 hours for the round-robin sending the name of a file and > getting the data. > Did you messure this figures on a real Debian mirror or is it just what you think? > can use simple http/1.1. It's a win-win situation. > Perfect go ahead. Even if DpartialMirror isn't developed further I use it almost daily and are quite happy with it. And I guess this won't change in the future. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Goswin von Brederlow wrote: > > > Why there isn't there already a rsync method for apt is probably a > > mystery nobody ever will solve. > > It is not wanted due to rsync causing excessive server load. > That is simply not true. This statement is repeated all the time but nobody ever was able to show hard figures. Where rsync produces much load is during the phase when it collects all the files for synchronisation and not during MD5 computation but this is is only due to not well designed scripts. DpartialMirror doesn't impose this phase since it only require single-file transfers and does the file collecting phase on the client. > New versions. The size of the Packages files is comparatively tiny > compared to all the debs. Even the 1% saving for rsyncing debs is > hardly worth it due to the extra traffic for the checksums and the > server load it causes. > Sorry rsync reports the overall use, incl. checksums etc. Of course 1% saving doesn't make much sense so that's the main reason I don't develop DpartialMirror further. Anyway the next time a distribution concept is designed it will be based on a p2p solution. > zsync has the option of looking into gziped files and rsync them as if > they would be ungziped (while still just downloading chunks of the > gziped file). Its a bit more complex algorithm but works even better > than rsyncable files and rsync. > As long as zsync allows multi-file transfers it won't be better that rsync. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] (Otto Wyss) writes: > > > Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > >> > Sure? Anyway DpartialMirror "http://dpartialmirror.sourceforge.net/"; > >> > can. > >> > > > I guess mirrorer doesn't care for bandwith saving as DpartialMirror, > > correct me if I'm wrong. > > Currently it will always redownload the Packages/Sources files as gzip > on every update to fix a bug in the apt methods. But I already > suggested only updating those that don't match the Release file. And, > unless you have an rsync method for apt, it won't rsync files. > Why there isn't there already a rsync method for apt is probably a mystery nobody ever will solve. > While rsyncing the Packages files sounds like a good idea to save > traffic it actualy is a bit insignificant compared to the daily > traffic of new sources and debs. > Do you mean there are up to 100 new packages each day? I get between 50 - 150 packages updated each day for just i386. Or do you mean there are 100 new versions? DpartialMirror handles new versions of packages (sources and deps) in a way it save about 1% even when the packages are normal gzip'ed. It would save around 10% - 50% with rsyncable. Is there any plan to add this feature to mirrored? O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > Sure? Anyway DpartialMirror "http://dpartialmirror.sourceforge.net/"; > > can. > > > A note of caution: > > | 2004-04-03 (wyo) Since Debian does not change its policy to add > | adequate support for rsync'ing package mirrors, I don't actively > | develop DpartialMirror further. > :-( Sad, isn't it? > Any user of dpartialmirror should check out mirrorer from alioth. I > only glanced at the webpage and haven't used dpartialmirror but now > that mirrorer has filtering support it looks like mirrorer could > replace dpartialmirror completly and I'm also thinking about retireing > debmirror in favour of a wrapper to mirrorer. > I guess mirrorer doesn't care for bandwith saving as DpartialMirror, correct me if I'm wrong. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > Debmirror is purely a mirror tool. It will download the Meta files > just like any other file. > > You can easily switch between mirror of equal contents but not create > Packages files reflecting what is locally available. > Sure? Anyway DpartialMirror "http://dpartialmirror.sourceforge.net/"; can. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian mirror scripts
> Tried to work around this with a simple script that merges my > packages into the local mirror and regenerates everything as > needed. But sadly this doesn't seem to be perfect :-( The installer > just doesn't want to get some of these packages, even if the md5's > are correct. Switching from http to ftp gets some more of them and > stucks some packages later. Grrr. > Look at DpartialMirror "http://dpartialmirror.sourceforge.net/";. I use it regularly to build a second mirror. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
/sbin/halt always changes its access rights
I've set the s attrtibute of halt since on my desktop any user may stop the system. But about each second month or so it's set back to it's original rights probably by a package upgrade. Is there a way to keep the access rights or any better way to handle these kind of problems. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: New stable version after Sarge
Tim Cutts <[EMAIL PROTECTED]> wrote: > > Seriously. There's just no way you're going to change the way Debian > > makes releases, or rather, doesn't. It's too big, and there are just > > too damn many people involved, many of whom simply don't care about > > releases. As long as we maintain our current release criteria (which I > > don't necessarily think we should change) we will get slower and slower > > as we get bigger and bigger. > Which is a rather clear sign that the way Debian makes releases has outgrown its usefulness. > Which could be seen as a problem by some; but in some ways it's > probably the way to go. As far as my own use of Debian goes, almost > every machine I install runs testing, and has done for years. There's > a level of protection in there thanks to the rules that are in place, > and I rather like the incremental improvement approach as opposed to > release-based. > Me too, but it might be completely different if you do it for business critical systems. > With the trend as it is at the moment, the endpoint is that Debian will > eventually stop releasing altogether (some end users probably think > this has already happened!) and will essentially become an upstream, > developer-oriented, steadily evolving distribution from which the likes > of Ubuntu take regular snapshots for the masses to use. > Stopping releasing might be a good idea but there should be a better way. IMO the problem is the stable release isn't updated on a regulare basis. It might be a better idea to divide Debian into subsystems which could be released much faster when needed. O. Wyss -- Development of frame buffer drivers: http://linux-fbdev.sf.net Sample code snippets for wxWidgets: http://wxcode.sf.net How to build well-designed applications: http://wxguide.sf.net Desktop with a consistent look and feel: http://wyodesktop.sf.net
Re: Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)
> > > IIRC the problem is that rsync is quite CPU-heavy on the servers, so while > > > the mirrors have the (network) resources to feed downloads to 100s of > > > users, they don't have the (CPU) resources for a few dozen rsyncs. > > > > Why do you keep on saying this without providing _any_ figures! > > Who is "you" here? Please pay attention to attribution on mailing list > postings - especially if you're starting a new thread with your mail. I > posted this statement about cpu load of rsync, and did that exactly once, > so I don't "keep saying it". Also, I put in an IIRC, so you have clear > indication that I'm not too sure - somebody asked about the reason, I > answered with that I heard was the reason when the last person asked. > I don't meant you personally but this statement about the CPU load, mostly accompanied with some vage numbers is repeated all the time and whenever I ask for exact figures only excuses or even not an aswer is provided. Your statement about "feed downloads to 100s ...(CPU) resources for a few dozen rsyncs" implied you have actually seen such CPU loads. Now you say you just repeated from hear say. How much value did your message have to the OP? Does it have any value? Well the main problem is not your message but that nobody is able or willing to set up a reasonable test case and provide accurate figures. Maybe this is a non issue because Debian has more than enough systems and don't has to care about. O. Wyss -- See a huge pile of work at "http://wyodesktop.sourceforge.net/";
Synching mirrors and clients (was: Re: apt-proxy v2 and rsync)
> > Can anyone explain why rsync is no longer considered an appropriate
> > method for fetching Packages files?
>
> IIRC the problem is that rsync is quite CPU-heavy on the servers, so while
> the mirrors have the (network) resources to feed downloads to 100s of
> users, they don't have the (CPU) resources for a few dozen rsyncs.
>
Why do you keep on saying this without providing _any_ figures!
Why always synching the full mirror when only about 1% of the files
changes daily? Just change to single file synching and most of your CPU
load is gone. Single file rsync doesn't need any CPU power to discover
the changed files. Single file rsync touches only the changed files,
only about 1%, so at least disk access is much less while probably also
lowers the CPU load.
If gzip --rsyncable would be used the CPU load would dramatically be
lowered, much lower than with _any_ other synching. As a side effect the
use bandwidth would be equally well be lowered. IMO rsync is very useful
if don't right.
Prove of concept
To finally produce some figures and prove this concept two servers are
needed, the first one an ordinary source mirror, the second a secondary
mirror with different mirror directories for each of the test cases. On
the first server the CPU load is measured, on the second the different
sync scripts are run:
- Ordniary full mirroring rsynch as today in use
- DpartialMirror sync script ("http://dpartialmirror.sourceforge.net/";)
- Deb-mirror sync script
- ???
- Sync with wget, etc.
IMO this will show which is the best solution for full mirrors.
Now limit the secondary mirror to support only one architecture and do
the test above again. This will show the best solution for the commonly
used mirrors.
In a third step limit the packages to what an ordinary user has, just
use popularity-contest or I could provide my dpkg --getselections. This
will show the best solution for servers from clients impact.
Now if you feel advantous, repack as many package on the source mirror
with gzip --rsyncable and notice the difference.
O. Wyss
--
See a huge pile of work at "http://wyodesktop.sourceforge.net/";
DpartialMirror (was Re: [ANNOUNCE] debian-multimirror)
> On Wed, 29 Sep 2004, Pedro Larroy wrote: > > As a long standing debmirror user and with the knowledge that there is a > debpartial-mirror project which is very actively developed I just wonder > if people have to much spare time to invent one wheel after an other. > Sorry for the late reply but in case you mean with deppartial-mirror project my "DpartialMirror" project, I've to say that I set its state to mature. While I still use it daily I don't actively develop it further since as long as Debian doesn't use gzip --rsyncable, it doesn't make much sense. Without it the gain just a few percents. See "http://dpartialmirror.sourceforge.net/";. O. Wyss -- See a huge pile of work at "http://wyodesktop.sourceforge.net/";
Re: Howto reconfigure alsa-modules-2.4.22-1-k6
> > depmod: *** Unresolved symbols in > > /lib/modules/2.4.22-1-k6/alsa/snd-pdaudiocf.o > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.22-1-k6/alsa/snd-vx-cs.o > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.22-1-k6/alsa/snd-vxp440.o > > depmod: *** Unresolved symbols in > > /lib/modules/2.4.22-1-k6/alsa/snd-vxpocket.o > > At this point I would just remove those files. They are not needed by > your machine. Unless those are the devices you are running. But > seriously just remove them and re-run update-modules. There are some > funky things I have always (nearly always) seen with those modules. Even > in the OSS setup they are difficult to get properly compiled. > I've found out, it can be fixed by installing kernel-pcmcia package, see "http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=213887";. Installation is now okay but I get the following error ../../alsa-kernel/pci/ice1712/ice1724.c:1614: invalid EEPROM (size=120) I guess I have to ask about this in another newsgroup but where? O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Re: Howto reconfigure alsa-modules-2.4.22-1-k6
> Otto Wyss dijo: > > dpkg-reconfigure alsa-modules-2.4.22-1-k6 > > > > but this doesn't show the driver list again! Okay getting dselect out, > > purge the package and install it again. But now the list isn't shown > > either. How do I get the driver list from this package? > > > dpkg-reconfigure alsa-base > > Anyway, this message would have fitted better in debian-user > First it was an oversight, sorry. But now I think the alsa packages are more broken. After successfully using dpkg-reconfigure alsa-base I got the following error messages: depmod: *** Unresolved symbols in /lib/modules/2.4.22-1-k6/alsa/snd-pdaudiocf.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-1-k6/alsa/snd-vx-cs.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-1-k6/alsa/snd-vxp440.o depmod: *** Unresolved symbols in /lib/modules/2.4.22-1-k6/alsa/snd-vxpocket.o I get the same messages when using update-modules. My alsa configuration looks good: ### DEBCONF MAGIC # This file was automatically generated by alsa-base's debconf stuff alias char-major-116 snd alias char-major-14 soundcore options snd major=116 cards_limit=4 alias sound-service-0-0 snd-mixer-oss alias sound-service-0-1 snd-seq-oss alias sound-service-0-3 snd-pcm-oss alias sound-service-0-8 snd-seq-oss alias sound-service-0-12 snd-pcm-oss alias snd-card-0 snd-ice1724 alias snd-slot-0 snd-card-0 alias sound-slot-0 snd-slot-0 and lspci shows 00:0b.0 Multimedia audio controller: IC Ensemble Inc ICE1724 [Envy24HT] (rev 01) So what's wrong now? O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Howto reconfigure alsa-modules-2.4.22-1-k6
I've installed alsa-modules-2.4.22-1-k6 but made a mistake when selecting the driver. So I tried dpkg-reconfigure alsa-modules-2.4.22-1-k6 but this doesn't show the driver list again! Okay getting dselect out, purge the package and install it again. But now the list isn't shown either. How do I get the driver list from this package? O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Installing kernel-image-2.4.22
I tried to upgrade the 2.2 kernel from Woody to 2.4.22 and installed kernel-image-2.4.22. During installation a large text but barely interpretable text about initrd.img is shown. Why can't the install make a fully correct lilo.conf by itself? Besides the text is wrong instead of "initrd=initrd.img" it should be "initrd=/initrd.img". So far so good but after installation I don't have network access anymore, probably because 2.4.22 has the network driver as a module. Instead of this sermone about initrd, it'd be better if this fact were mentioned in the installation. A hint to use modconf after installation would be very helpful. The question remains why kernel-image packages don't require the modconf packages. It seems to me obvious that modconf has to be run after a kernel upgrade. How do I install modconf without a network connect? Okay just boot into the old kernel with network support. Well the kernel-image package adds the second entry to lilo.conf but forgets to uncomment the prompt and timeout parameteres. I don't know what would happened if the new kernel wouldn't run. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app
Re: window manager recomendation
> Hello, > > Hoping this won't turn into a flame war, I am looking for > recommendations for a window manager. I tried quiet a few but none seem > to fit the bill yet. > I don't know if XFCE fits all your requirements but since it's not only a window manager but a light weight desktop I like it. The application menu is a little bit chaotic but usable. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Sarge-i386-1.iso via jigdo-lite
Currently there seems to be a problem with the Sarge-i386-1.jigdo file. I tried to build/download a new CD but it complains 57 files where missing. Even getting the .jigdo/.template files again or choosing another mirror didn't help. The script can only be stopped so I don't know how to proceed further. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Library packages and their use
The discussion about the libc6-dev package and its headers let me to the impression that the Debian package structure isn't optimal for libraries. If anyone wants to build his own version of a package (i.e. libwxgtk2.4) he has to get all the dependent underlying dev packages as well. This is a long line of dependencies which mostly aren't wished and shouldn't be necessary. The problem arises because the 2 usual package lines (normal and dev packages) don't fit well with the needs of the users. There are 3 kinds of dissimilar user groups of a package: 1. Users just using a library linked to other packages 2. Developers building packages which depends on a library package 3. Developers building his own version of this library package Currently group 1 just uses the "normal" packages while group 2 + 3 have both to use the "dev" packages. Especially for group 2 this isn't a good solution leading to a long line of unnecessary dependencies. Solution 1: Splitting the 2 packages into 3. Not very attractive, it will more confuse than improve the situation. Maybe the dbg packages could take over the role of the 3. group. Solution 2: Packages are changed that group 1 + 2 can use the normal packages and only group 3 uses the dev. That means the normal library packages contain enough so that other packages depending on this can be build. Solution 3: Normal packages are for group 1, dev packages are for group 2 and group 3 has to get anything needed by other means (i.e. CVS). Usually group 3 is rather small and they tend to get anything by CVS anyway. I'm not sure if any of the above solutions will improve the situation but we should all try to remove dependencies wherever possible. And I'm not sure if any library package can be split this way but it should be tried. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Re: rename linux-kernel-headers to system-headers
> On Fri, Nov 07, 2003 at 10:45:32AM +, Jonathan Dowland wrote: > > On Thu, Nov 06, 2003 at 07:55:03PM +0100, Eduard Bloch wrote: > > > > > What not rename linux-kernel-headers to simple system-headers-linux? > > > This will prevent confused users (or: lazy to read the description users) > > > from asking this again and again. > > > > system-headers-linux is a bit vague and without knowing could be > > associated with the kernel just as strongly as with libc. > > > > How about libc-linux-headers? > > I second that, or perhaps libc6-linux-headers. If the package would have been named "libc6-linux-headers" to show its strong relationship with libc6 I had never started this thread. I'm not a fan of renaming but in this case IMO it seems to be appropriate. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Re: Package libc6-dev depends on linux-kernel-headers
Sorry this message go to the poster instead of the list. > > > There have always been some kernel headers in libc6-dev, they've just > > > been split out into a separate package now. Several of these headers > > > are referenced by headers provided by glibc which would break those > > > headers if linux-kernel-headers is not installed. > > > > I'd prefer the old way. > > And can you give a substantive reason? Without one your message makes > no sense. I didn't give a reason because it wouldn't change anything. I always download the kernel sources myself and build my kernel from scratch. I therefore don't want do download and install the header packages as well. Besides which version of headers does libc6 use/need? You may ask why I don't use any Debian kernel. Mostly because I need the framebuffer early on and also use an USB keyboard on my desktop. Most of the rest are just modules. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Building kernel with framebuffer support (was: Re: GCC for kernel compilation)
I know I'm getting off topic but I don't know a better place to ask and this subject might be interesting of other developers as well. > On Fri, 8 Aug 2003 04:14, Otto Wyss wrote: > > I just upgraded to the current Sarge and also got GCC 3.3. It seems this > > version can't compile all the drivers in kernel 2.4.21. Which version > > Which drivers and what errors do you get? If you tell us the errors then we > can get them fixed. I get lots of warning (i.e. variable fb isn't used in aty182 driver). I don't get these warnings when I use CC=gcc-2.95. It's a little bit difficult to trace warnings and errors during a kernel compilation. I'd be good if warnings and error where duplicated into a log file. I'm trying to build a kernel with framebuffer support for the Matrox G400 card but I always get "open /dev/fb0: No such device" when I use fbset. A week ago I added a new 123GB harddisk to my system, installed a new Debian 3.0r1 and upgraded to the current Sarge. But since then I can't use framebuffer anymore while with the old system I used it for about 2 years. For building I use the same settings (make menuconfig) as before, so it should work unless there are any hidden settings in 2.4.21. The command: ls -la /dev/fb0 crw--w 1 root video 29,0 Mar 14 2002 /dev/fb0 seems to be correct as much as I know. I've tried to config each setting new, I also installed the kernel-image-2.4.21-3-k6 but nothing helps. What can I do to fix this situation? O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
GCC for kernel compilation
I just upgraded to the current Sarge and also got GCC 3.3. It seems this version can't compile all the drivers in kernel 2.4.21. Which version should I use? And how do I set this version (Environment variable?) without deinstalling GCC 3.3? O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Re: A success story with apt and rsync
> From time to time the question arises on different forums whether it is > possible to efficiently use rsync with apt-get. Recently there has been a > thread here on debian-devel and it was also mentioned in Debian Weekly News > June 24th, 2003. However, I only saw different small parts of a huge and > complex problem set discussed at different places, I haven't find an > overview of the whole situation anywhere. > Sorry that I write so late but I'm not reading debian-devel regularly. I've started a solution to distribute Debian mirrors by rsync about 2 years ago. The only "impact" (if impact is the right word) of my soultion on Debian is the use of the rsync patch for gzip. Everything else is solve by my perl script so you might find ideas for your apt solution there. See "http://dpartialmirror.sourceforge.net/";. O. Wyss -- See "http://wxguide.sourceforge.net/"; for ideas how to design your app.
Re: Porting Xconfigurator to Debian!
> Install discover, read-edid and mdetect before you install X, and you're > set. > mdetect hopefully doesn't choke on an USB-mouse anymore! O. Wyss
Packages still in Potato
IMO each package should at least once per release upload a status report. Also there was ample time for the transition of each package to the pool. These are the reason behind the mailing to each maintainer of packages still in Potato. While most of the answers I got were positive, there were some few I simply don't want to get a second time. Therefore I've lost interest into this matter. I'll append the list of maintainers/packages I haven't gotten any answers so others may finish what I started. Just keep in mind there might be wrong or missing entries since I have no desire to do any checks. For me this matter is now solved, with my script I'll simply apply option --transform=pool. O. Wyss --- [EMAIL PROTECTED] tkxanim [EMAIL PROTECTED] rtlinux-doc [EMAIL PROTECTED] theme-converters [EMAIL PROTECTED] termcap-compat [EMAIL PROTECTED] mdate [EMAIL PROTECTED] festvox-don festvox-rablpc16k festvox-rablpc8k festival-doc festlex-cmu festlex-poslex festvox-kallpc16k festvox-kallpc8k festvox-kdlpc16k [EMAIL PROTECTED] ibm-jdk1.1-installer [EMAIL PROTECTED] hbf-cns40-1 hbf-cns40-2 hbf-cns40-3 hbf-cns40-4 hbf-cns40-5 hbf-cns40-6 hbf-cns40-7 hbf-cns40-b5 xcin2.3 [EMAIL PROTECTED] libstdc++2.9-glibc2.1 [EMAIL PROTECTED] libgd-gif-tools libgd-gif1 [EMAIL PROTECTED] perlmenu [EMAIL PROTECTED] fda hpscanpbm iroffer makepasswd [EMAIL PROTECTED] gilt [EMAIL PROTECTED] adbbs [EMAIL PROTECTED] gwm gwm-doc [EMAIL PROTECTED] enscript xdigger [EMAIL PROTECTED] flexml [EMAIL PROTECTED] gnuhtml2latex [EMAIL PROTECTED] workbone [EMAIL PROTECTED] floppybackup [EMAIL PROTECTED] rcs ??? [EMAIL PROTECTED] gnosamba linleech [EMAIL PROTECTED] lclint-doc [EMAIL PROTECTED] scansort [EMAIL PROTECTED] nsmon [EMAIL PROTECTED] ttysnoop [EMAIL PROTECTED] debian-test [EMAIL PROTECTED] fortunes-it [EMAIL PROTECTED] knl [EMAIL PROTECTED] cern-httpd jargon [EMAIL PROTECTED] xmake [EMAIL PROTECTED] cvs-pcl elib [EMAIL PROTECTED] sendmail-wide [EMAIL PROTECTED] chos nstreams [EMAIL PROTECTED] cedicttools ttfprint lpkg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
> > http://rsync.samba.org/rsync-and-debian/
> >
> > I'd appreciate comments.
>
This is certainly a very informative page. I'd appreciate if the CPU
load problem could be solved somehow.
IMO the versioning patch from Paul Russell is not the right approach
since this is Debian specific and has nothing to do with rsync. This
should be done by a wrapper script. Maybe someone writes a debianrproxy
but then what's the difference to my script?
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Rsync and single file transfer
Most of the scripts/methods I've seen which downloads Debian packages
with rsync do only single file transfer. IMO this must be much more
server friendly than a multi file transfer (no filelist).
Is it possible run a rsync server with anonymous login but restricted to
single file transfer next to an rsync server with restricted login and
multi file transfer? This would allow access for secondary Debian
mirrors besides endusers. It also would allow to separate and measure
the impact endusers have on rsync servers.
Note: IMO a script like mine is also useful for secondary mirrors at
least if not all architectures are mirrored. Could any mirror
administrator make a test an publish any results?
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync and debian -- summary of issues
> > 3.1 Compressed files cannot be differenced
>
> I recall seeing some work done to determine how much savings you could
> expect if you used xdeltas of the uncompressed data. This would be the
> best result you could expect from gzip --rsyncable. I recall the numbers
> were disapointing, it was << 50% on average or somesuch. It would be nice
> if someone could find that email or repeat the experiments.
>
With the help of an admin from an rsync server I tested the download of
a with "gzip --rsyncable" compressed Packages.gz versus an uncompressed
Packages. The results are under
"http://lists.debian.org/debian-devel/2001/debian-devel-200106/msg01859.
html"
It just shows 2 days but the test went on for about a week with similar
results. While uncompressed is still the best for rsync download, it
shows a significant reduction (more than 50%) against a normal
compressed Packages.gz. Similar savings are possible if this is applied
to Debian packages.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian's problems, Debian's future
> http://lists.debian.org/debian-devel/2001/debian-devel-200111/msg00757.html
Thanks for this pointer.
My debiansynch script never runs into problem "1. rsync -r" since it
always does single file transfers. And for problem "2. rsync of near
identical files" it's not astonishing using a high cpu load for a short
period, an ftp transfer simply distributes its cpu load over a longer
period.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Description to man pages
> On Sat, Apr 06, 2002 at 10:01:16AM +0200, Otto Wyss wrote:
> > The best would be if "man would bring up a list of man pages
> > with a choose facility when more than one page exists. Maybe this change
> > in behavior could be set through an environment variable.
>
> No need. Try 'man -a '.
>
> Also, when more than one page exists man will ask you if you want to
> display the next one it's found after displaying the first one. Try it.
I'd rather like it if the menu is shown before not after the first man
page. If I knew another page is following I might jump directly there.
Also I'd rather like this to be the default if multiple pages where
available.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rsyncable GZIP (was Re: Package metadata server)
> A large mirror in Australia does provide an rsync server to access debian
> packages. When redhat 7.0 came out so many people tried to rsync it at the
> same time, the machine promptly fell over.
>
What amazes me is that nobody is able or willing to provide any figures.
So I guess no provider of an rsync server is interested in this subject
and therefore it can't be a big problem.
I'm asking any provider of an ftp/rsync Debian server if any comparable
figures could be extracted from the server log. Or if anyone could
measure how much CPU load the download of the Packages/Packages.gz files
really reads.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Rsyncable GZIP (was Re: Package metadata server)
> > Some questions that need to be asked:
> > Howmany of our mirrors are rsyncable?
> How much load can the servers handle?
> How much more load does rsync do than a fast http server like tux?
>
Please show use any figures first before you assert this.
I know rsync imposes some load for the computing of the md5sum but
sendind only the difference outweighs it repeatedly.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Description to man pages
> On Thu, Apr 04, 2002 at 11:03:53PM +0200, Otto Wyss wrote:
> > I've now choosen "7dsc" since packages aren't commands.
>
> How about something more descriptive than "dsc"? Say, "package",
> "pkg", or "deb" (in my order of preference)?
>
I'm also not very happy with "dsc" but I neither are with the others.
What do anybody else think?
If there isn't another man page "man " will show the package
description. You could get a list of all man pages for a keyword with
"man -f ".
The best would be if "man would bring up a list of man pages
with a choose facility when more than one page exists. Maybe this change
in behavior could be set through an environment variable.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Description to man pages
> Is it better than `apt-cache show foo` ?
>
No if you are a power user, otherwise yes. Beside not everbody has
apt-cache installed.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Description to man pages
> > To minimize possible conflicts with other names it creates man pages in
> > section 6 (games!). Of course this can be configured in the config file.
> > I'd rather like to know which is a better place for it.
>
> Use a subsection. For instance, somepackage(1dsc) goes in
> $(mandir)/man1/somepackage.1dsc.gz. This should avoid clashes, and you
> can pass man the '-e dsc' option to look at those pages exclusively. It
> might also be a good idea to write to /usr/local/man by default rather
> than /usr/share/man.
>
I didn't know that man has subsection, the man howto which I found on
the web didn't tell it.
I've now choosen "7dsc" since packages aren't commands.
> Would it be possible to make it easier to use for those who don't use
> debiansynch? I couldn't figure out how to get it to work at all -
> whatever I tried just ended up with "0 processed of 0". I don't have a
> local mirror, so I'd like it just to use the available file.
Actually dsc2man search for Packages files inside the basedir if no
distribution list is specified (empty parameter distsfile" in
"dsc2man.conf" or if the file isn't found). I've changed the behavior so
that searching is the default. Of course the Packages files have to be
located anywhere locally inside the searched basedir (regardless of
structure).
There was also a bug which prevented the search under certain
circumstances, but now it should work.
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Description to man pages
> dpkg -s
>
This doesn't show the package description!
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Description to man pages
Since I hated to start dselect again and again just to read a package
description I wrote a script "dsc2man" which creates appropriate man
pages for each package.
To minimize possible conflicts with other names it creates man pages in
section 6 (games!). Of course this can be configured in the config file.
I'd rather like to know which is a better place for it.
The script does only create pages if none exists. But for upgrading the
force switch has to be used, which means any existing page will be
overwritten.
The script can be down loaded from
"http://dpartialmirror.sourceforge.net/dsc2man.html";
O. Wyss
--
Author of "Debian partial mirror synch script"
("http://dpartialmirror.sourceforge.net/";)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian non-free mirror? Where are they?
I considered to include Debian non-free into my synchronisation scripts (see "http://dpartialmirror.sourceforge.net/";) but I couldn't find any mirror nor any information about. Where is non-free located? O. Wyss
Re: Referring what kernel-images to build to the technical committee?
>In fact, most of the options could be auto-detected from >/proc/cpuinfo. > >It could also be useful as a hardware tester at install time: >"Would you like to test your hardware (and get a kernel custom >build for your hardware at the same time)? This process will >potentially take a long time." (Yes, I realize this idea is >a bit crazier than average.) > Even if your idea sounds a little bit crazy, this is probably the best way at the moment to get a well suited kernel. But I'd rather see a kernel where all options were compiled into separate modules so simply choosing the right modules constructs the optimal kernel. This could be done during an install or setup process. Sound crazy? Maybe now but how about in the future? O. Wyss -- Please CC.
Re: Solving the compression dilema when rsync-ing Debian versions
>>> > gzip --compress-like=old-foo foo > >gzip creates a dictionary (that gets realy large) of strings that are >used and encodes references to them. At the start the dictionary is >empty, so the first char is pretty much unencoded and inserted into >the dictionary. The next char is encoded using the first one and so >on. That way longer and longer strings enter the dictionary. > ... > >So, as you see, that method is not possible. > Okay lets asume gzip knows anyhow the table of the previous compression. It starts compressing as usual, getting the first value to encode. Now instead of just putting it at the first position it looks in the old table and finds it at position 3. Gzip puts it at position 3 leaving the first 2 unused. Now everthing goes fine until a value isn't found. This time gzip appends it to the end of the table. Of course at a certain point these to table diverge to much so gzip starts using a new table. I don't know the outcome of such a compression but I think it will much better correspond to the sources. Besides this algorithmus could be used as gzip --compress=i386.gz where i386 does contain a optimal table for i386 binaries. It will give a better start compression rate while retaining an adaptable compression and it allows to specify th optimal compression for any case. I don't think mine is the best solution and I don't know if its working, it just gives an idea how the problem could be solved. The principle is to use the old compression scheme and adapt it as less as possible but as much as necessary. >But there is a little optimisation that can be used (and is used by >the --rsyncable patch): > This is of course a very good solution, I only wouldn't call it --rsyncable. I wouldn't make it an option at all. Anyhow it's not the NonPlusUltra solution, there are cases where it will fail. > > Maybe it's time to design a compression alogrithmus which has > > this functionality (same difference rate as the source) from > > the ground up. > >There are such algorithms, but they eigther allys use the same >dictionary or table (like some i386.exe runtime compressors that are >specialiesed to the patterns used in opcodes) or they waste space by >adding the dictionary/table to the compressed file. Thats a huge waste >with all the small diff files we have. > These all have fixed compression, as far as I know there isn't any which combines a fixed with an adaptable compression. O. Wyss
Re: Solving the compression dilema when rsync-ing Debian versions
> > gzip --compress-like=old-foo foo > > AFAIK thats NOT possible with gzip. Same with bzip2. > Why not. > I wish it where that simple. > I'm not saying it's simple, I'm saying it's possible. I'm not a compression speciallist but from the theory there is nothing which prevents this except from the actual implementation. Maybe it's time to design a compression alogrithmus which has this functionality (same difference rate as the source) from the ground up. O. Wyss
Re: Solving the compression dilema when rsync-ing Debian versions
> > gzip --compress-like=old-foo foo > > > > where foo will be compressed as old-foo was or as aquivalent as > > possible. Gzip does not need to know anything about foo except how it > > was compressed. The switch "--compress-like" could be added to any > > compression algorithmus (bzip?) as long as it's easy to retrieve the > > No, this won't work with very many compression algorithms. Most > algorithms update their dictionaries/probability tables dynamically based > on input. There isn't just one static table that could be used for > another file, since the table is automatically updated after every (or > near every) transmitted or decoded symbol. Further, the algorithms start > with blank tables on both ends (compression and decompression), the > algorithm doesn't transmit the tables (which can be quite large for higher > order statistical models). > Well the table is perfectly static when the compression ends. Even if the table isn't transmitted itself, its information is contained in the compressed file, otherwise the file couldn't be decompressed either. O. Wyss
Re: Solving the compression dilema when rsync-ing Debian versions
>> So why not solve the compression problem at the root? Why not try to >> change the compression in a way so it does produce a compressed result >> with the same (or similar) difference rate as the source? > >Are you going to hack at *every* different kind of file format that you >might ever want to rsync, to make it rsync friendly? > No, I want rsync not even to be mentioned. All I want is something similar to gzip --compress-like=old-foo foo where foo will be compressed as old-foo was or as aquivalent as possible. Gzip does not need to know anything about foo except how it was compressed. The switch "--compress-like" could be added to any compression algorithmus (bzip?) as long as it's easy to retrieve the compression scheme. Besides the following is completly legal but probably not very sensible gzip --compress-like=foo bar where bar will be compressed as foo even if they might be totally unrelated. Rsync-ing Debian packages will certainly take advantage of this solution but the solution itself is 100% pure compression specific. Anything which needs identical compression could profit from this switch. It's up to profiting application to provide the necessary wrapper around. >gzip --rsyncable, aloready implemented, ask Rusty Russell. The --rsyncable switch might yield the same result (I haven't checked it sofar) but will need some internal knowledge how to determine the old compression. As I read my mail again the syntax for "compressing like" could be gzip --compress=foo bar where bar is compressed as foo was. Foo is of course a compressed file (how else could the compression be retrieved) while bar is not. O. Wyss
Solving the compression dilema when rsync-ing Debian versions
It's commonly agreed that compression does prevent rsync from profit of older versions of packages when synchronizing Debian mirrors. All the discussion about fixing rsync to solve this, even trough a deb-plugin is IMHO not the right way. Rsync's task is to synchronize files without knowing what's inside. So why not solve the compression problem at the root? Why not try to change the compression in a way so it does produce a compressed result with the same (or similar) difference rate as the source? As my understanding of compression goes, all have a kind of lookup table at the beginning where all compression codes where declared. Each time this table is created new, each time slightly different than the previous one depending on the source. So to get similar results when compressing means using the same or at least an aquivalent lookup table. If it would be possible to feed the lookup table of the previous compressed file to the new compression process, an equal or at least similar compression could be achieved. Of course using allways the same lookup table means a deceasing of the compression rate. If there is an algorithmus which compares the old rate with an optimal rate, even this could be solved. This means a completly different compression from time to time. All depends how easy an aquivalent lookup table could be created without loosing to much of the compression rate. O. Wyss
RFC: Changing the Packages files
With the introduction of the packages pool, I'm going to propose the following change to the Packages files: 1. The filename tells what the Packages files contains: Packages files should be independent of the their location, therefor the name has to reflect their contents, i.e. "Packages-$DIST-$ARCH" or simply "$TYPE-$DIST-$ARCH" where $TYPE="Main"|"Contrib"|"NonUS"|"Nonfree" 2. The location of the Packages file does define the base of the packages mirror structur: This means the "Filename:" attribut starts from the location of the Packages file, allowing for a much flexibler naming of the structur. These two changes means the Packages files for all distributions could be moved inside the pool as well. Also it is possible to have different kind of mirror structurs (i.e alphabetical versus functional) since the Packages files could be anywhere. And symlinks from binary-$ARCH to binary-all weren't nessecary. O. Wyss
