Re: Bug#70269: automatic build fails for potato
Hello. Anand Kumria schrieb: > Not having the helper packages included in the autobuild system appears to > benefit, at most, around ~470 packages. May I ask how they benefit? It's only a (little) burden on the packages that use debhelper, but I can't see any benefits for packages not using it. Nobody will force debhelper on anyone. As soon as you want to build something you will most probably end up installing debhelper anyway, thus it's only wasted space on the mirrors if all these hundreds of packages that use debhelper have to declare this in their Build-Depends:. On the other hand it probably makes counting them easier ... ;) ciao, 2ri -- 0 and 1. Now what could be so hard about that?
Re: Machine-specific optimizations
Hello. Alisdair McDiarmid schrieb: > On Thu, Aug 31, 2000 at 01:49:13PM -0700, Sean 'Shaleh' Perry wrote: > > you always have the option of using 'apt-get source' to recompile a package, > > then place it on hold and we wont touch it. > > I've tried doing this occasionally -- more often to change a > compile-time feature than optimise for CPU -- and it's not very > convenient. I mean, the apt-get source couldn't be easier, but unless > I put the package on hold, apt `upgrades' to the *same* version on > the very next apt-get upgrade. Is there a convenient way to put a package on hold? I couldn't figure anything out form the dpkg and apt-get manpages. If I have to start dselect every time I want to put something on hold this is certainly not how it should be. (Ever used dselect on a 9600 serial console? It's fun ;). ciao, 2ri -- "Siddhartha tut nichts, er wartet, er denkt, er fastet, aber er geht durch die Dinge der Welt hindurch wie der Stein durchs Wasser, ohne etwas zu tun, ohne sich zu rühren; er wird gezogen, er lässt sich fallen. [...] Es ist das, was die Toren Zauber nennen und wovon sie meinen, es werde durch die Dämonen bewirkt." -- Hermann Hesse, "Siddhartha" -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: X and runlevels
Paul Slootman schrieb: > On Mon 04 Sep 2000, Ethan Benson wrote: > Debhelper (and one of the other helper things) does this, if you > don't call dh_installinit with the --no-restart-on-upgrade (or such) > option. I guess the reasoning is that (a) you're upgrading in multiuser > mode because debian lets you :-) (b) in multiuser mode the daemon was > running. Running start-stop-daemon without --oknodo for restart) would probably also solve the problem (you do set -e, do you?). It would yell if it doesn't find the daemon running and exit. > It's unfortunate that there's no easy way to find the current runlevel > (the usual "who -r" from Solaris etc. doesn't work), otherwise this > piece of code could be used: > > RL=`who -r` > if [ -x /etc/rc$RC.d/S??$PKGNAME ]; then > /etc/rc$RC.d/S??$PKGNAME start > fi 14:27:10 [EMAIL PROTECTED]:~$ sudo runlevel N 2 > That's ignoring file-rc, unfortunately. Is there an easy way of > determining whether a certain init.d script should be started in > the current runlevel that works also with file-rc ? Probably we should just make /etc/init.d/foobar restart _not_ start anything if the deamon was not running before. It can be done with little effort there, and works with file-rc. ciao, 2ri -- The light at the end of the tunnel is the headlight of an approaching train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: why apt/dpkg not using bzip2
Hello. Adrian Bunk schrieb: > My suggestion for the Packages file is: > > There's a Packages.bz2 additionally to the Packages.gz . apt downloads by > default the Packages.bz2, but you can tell apt to fetch the Packages.gz > instead if you do have a slow machine. This solution has the advantage > that there are no problems with old versions of apt (the Packages.gz is > still present), and if you don't want the .bz2 you can still get the .gz . I don't understand this hysteria about compressing Packages-files. IMO it would be _much_ better (bandwith and processing-speed wise) to have it uncompressed on the servers and rsync it. How often did you have to download that whole damned 800k Packages.gz of unstable just because one single package was upgraded? apt-move uses rsync to update it's Packages, and it's a real improvement over the sledgehammer method. ciao, 2ri, sitting behind 64k/s ISDN, yawning -- The light at the end of the tunnel is the headlight of an approaching train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: build question
David Starner schrieb: > On Tue, Sep 05, 2000 at 01:29:02AM +0200, Tom Cato Amundsen wrote: > > On Mon, Sep 04, 2000 at 07:19:11PM +, michael d. ivey wrote: > > > my main server is potato. is it "bad" for me to be building packages > > > there if they are destined for woody? should i start building on a > > > woody box? > > > > > If possible, your package should depend on packages in potato only. > > Then users won't be forced to install other unstable packages, > > just to try out your package. > Contrary to Tom, though, if packages are destined for woody, packages > should be built on woody, because that's how the build demons will > build them, that's how people will run them, and that's how they > will eventually be released. It will also help shake out bugs in > unstable libraries. That sounds reasonable. > If you want to build them so that potato users can use them, > do so and store them in a directory on master or a private > machine and tell people how to get them. Or just educate people on how to use dpkg-buildpackage (apt-get -b source). This would be even easier if dpkg-buildpackage would handle Build- itself. I like debian source packages ... ciao, 2ri -- They are really completely different things, so don't mix them up, but they have a close relation to each other. -- http://hurddocs.org/whatis/translator.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: apt-move problem
Peter S Galbraith schrieb: > My current problem with apt-move is that it wants to delete every > single deb file I have For my archive it was to late: 19M /home/pub/debian That was ~250M before ... oops. Time to use http and squid instead ... ciao, 2ri -- Note that there are two possible orientations of the log. If the end with the larger diameter is facing downstream, the log is said to be big-endian; otherwise, it is little-endian. -- Philip Willoughby <[EMAIL PROTECTED]> on Segfault.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Location of -doc documentation?
Joey Hess schrieb: > Karl M. Hegbloom wrote: > > I just noticed that `apache-doc' puts the documentation under > > "http://.../doc/apache";, while `debconf-doc' puts it under > > "http://.../debconf-doc/";. > > Eh? (Debconf-doc is a package, that contains some documentation files. > It doesn't touch the web space at all.) Well, it touches /usr/doc, and /etc/apache/srm.conf has an Alias /doc/ /usr/doc/. HTH ciao, 2ri
Re: What do you wish for in an package manager?
Hi Mark Seaborn schrieb: > I want a system where I can install multiple versions of a library (or > any package really) and say which version I want each program on the > system to use, possibly on a per-user basis. The present system is a > disaster waiting to happen: If I install a package from unstable, it > often wants to replace my version of libc from stable with one from > unstable. [...] You actually can install (hypotetical) libfoo0 (/usr/lib/libfoo.so.0.3.1) and libfoo1 (/usr/lib/libfoo.so.1.0.9) at once, and that's why Debians shared library dependencies work (with packages gradually upgrading to the new library). Unfortunately more and more library packages do no more properly feature the entire soname in the package name, which can cause mayham. And if you want to install packages from unstable on a stable system you ether take the binary package and everything it depends on, or you apt-get -b source it. If all library packages are made properly, you can't get around this with fancy package management. Running programs with another than the standard version of a library can be done with LD_PRELOAD (ld.so(8)). ciao, 2ri
Re: Bug#80343: general: Lack of policy on which files should be owned by which user
Hi Brian May schrieb: > > "Hamish" == Hamish Moffatt <[EMAIL PROTECTED]> writes: > > Hamish> On Tue, Dec 26, 2000 at 11:13:13AM +1100, Brian May wrote: > >> However, the idea of one UID per daemon is (IMHO) a really > >> horrible solution, too, as you end up having more UIDs for > >> daemons then users. > > Hamish> Why is that a problem? There are 65536 available UIDs. > Some potential problems though: > > - easy to hide back-door entry point in /etc/passwd if lots of entries > exist (eg. missing password field). Whether this is by mistake > or done on purpose by an attacker is not important, but the fact it > is harder to detect may be important. Regular /etc/passwd checking is done by a pretty rigid scripts usually. It really does not matter how many entries there are in /etc/passwd. Checking it "by hand" seems pointless to me. > - As the number of entries grows, the chance that one/more entries > will conflict with some NIS, openldap or remote NFS system increases. > Especially since adduser, etc, do not support NIS or openldap. I am > not sure of the details here - can adduser assign a local user a UID > that conflicts with that from some other source? Then we should fix adduser and libc(PAM/NSS). I tried to get the normal 'passwd' to change passwords on nis (well, passwdd; pam_unix seems to be able to do this) but couldn't get it to work (I hadn't that much time for it though). > - harder to administrate /etc/passwd as more users exist. Something that seems improtant to me: providing a way to use less users/groups on some systems should be easy once every daemon can have it's own (adduser creating system accounts with same UID/GID comes to mind). The other way round it's harder. ciao, 2ri
Re: test -d /usr/man && mail submit@bugs
hi Peter Makholm schrieb: > for package in dpkg apt libc gpg bplay etc ; do > sed [...] bug.template | mail ; > done You'd better use [EMAIL PROTECTED], else you need a very good asbestos suit ... ciao, 2ri
Re: What do you wish for in an package manager?
Hi Hamish Moffatt schrieb: > Package X and package Y are not truely unrelated if they share any > dynamic libraries, though, eg libc. > > So do you have any suggestion as to how this could actually be > implemented? Even if it's actually desirable (which I dispute), > implementation seems far from trivial. It is trivial: link everything statically and include everything that might be needed in each package. Welcome to . ciao, 2ri
Re: ITP: ttf-xtt, xfonts-xtt
ISHIKAWA Mutsumi schrieb: > So, I want to separate TrueType fonts and meta datas such that > fonts.scale and fonts.alias included in xfonts-xtt-*. C'mon, it wont do any harm to ppl who are using LaTeX but not X11 if they have fonts.scale and fonts.alias installed but unused. They are not larger than 100k, are they? ciao, 2ri
Re: ITP: ttf-xtt, xfonts-xtt
ISHIKAWA Mutsumi schrieb: > For example, if ttf-xtt-* includes meta datas(fonts.alias, > fonts.scale, tfm and so on) and when only fonts.alias update and > upload. A user would download ttf-xtt-* package (include other files, > they are not updated), if the user use the package only for TeX (not > using for X).This update perhaps would not need the user. How often will the xfonts-* package change without the ttf-* package changing as well? Probably never, at least not the stable packages. The cost of having some bytes more in the Packages.gz that _every_ user has to download (even ppl who don't know japanese) and greater resource usage of apt is much greater than the advantage of not having to download 3.6M once every total eclipse (only for ppl using these packages). ciao, 2ri -- "I didn't know it was impossible when I did it."
Upstream orphans wmfsm, anybody interested? [Re: wmfsm: homepage and source 404]
Hi I don't know C, thus couldn't do more than keep it available. (quick and dirty translation in []) - Forwarded message from Stefan Eilemann <[EMAIL PROTECTED]> - Date: Fri, 5 Jan 2001 10:15:23 +0100 To: Arthur Korn <[EMAIL PROTECTED]> From: Stefan Eilemann <[EMAIL PROTECTED]> Subject: Re: wmfsm: homepage and source 404 On Sun, Dec 31, 2000 at 03:00:27PM +0100, Arthur Korn wrote: > Hallo Stefan. > > http://netpedia.net/hosting/wmfsm/ > > Ist tot. Hallo Arthur, ja, all netpedia seiten sind tot. [ all netpedia pages are gone ] Als erstes muss ich mich bei dir entschuldigen wg. der manpage. Ich komme irgendwie nicht dazu. Ich habe jetzt bei auch festgestellt, dass ich gar kein backup von wmfsm habe :(, da ich meinen Job gewechselt habe. Mein Vorschlag [ he doesn't have backups, not even of wmfsm source (it's in the debian archive though) ] waere (...falls du zustimmst/moechtest), dass du die Website woanders hinpackst und den Code uebernimmst, da ich in zukunft wohl eher nicht dazu komme. [ he suggests that I take over wmfsm since he probably won't have any time for it anyway ] Stefan - End forwarded message - ciao, 2ri -- All constants are variables.
Re: our broken man package
Hi Joey Hess schrieb: > > And, anyway, caching might be done in a cronjob: look at the pagesa in This seems to be cr^Hontrary to the idea of caching. > That's a good idea. Another route to take is to split man into the > rendering/caching bit and the command line man page lookup/processing/pager > executing bit. Only the former part of the program needs to run as user man, A man-daemon? Or a 6755 root.man rendering part? Wouldn't simpy let every user have his own cache be much simpler and not even too much worse, since different users tend to read different manpages? A cronjob could collect these per-user cached pages into a shared cache if this is really needed, and clean up the user caches. ciao, 2ri -- All constants are variables.
Re: local facilities and official packages
Hi Andres Seco Hernandez schrieb: > Are local? facilities reserved in Debian for some purpose? I'm not aware of any "reserved" local facilities, however system log daemons provide the syslog-facility(8) script which may be used by packages to dynamically retrieve and set up a local facility (eg snort does this). > Where can i find more information about syslog policy in Debian? There is none, at least I never saw one. I try to make msyslog behave as much like sysklogd where it makes sense, so does Attila Szalay (syslog-ng) it seems. ciao, 2ri -- Education is what remains after one has forgotten everything he learned in school. -- A. Einstein
Re: NMUers: STOP BEING STUPID
Hi Richard Braakman schrieb: > In that case the right "repository" could be a bugreport to the package > involved. That way the diff submission is guaranteed. I agree with you that _something_ has to be done about catastrophal NMUs, but just stopping to NMU and only submitting diffs, even on packages where it is clear that the maintainer stopped working on them some years ago can't be the solution. [1] I've submitted a handful of diffs and some manpages to packages which where either ignored (without notice) or the maintainer didn't bother to upload at all (for some months that is). I'm glad most Debian developers are more responsive, but such things happen and are most frustrating. [1] check out the changelog of afbackup for example ... ciao, 2ri -- Why is "abbreviation" such a long word?
Re: Packages not making it into testing
Anthony Towns schrieb: > + libvoxel uploaded 357 days ago, out of date by 347 days! > has a year old "doesn't build" bug, 60985 I hacked at it at BSP#3, nothing depends on it, and the bug is _really_ obscure (that's not only me saying this). I asked the maintainer wheter it would be OK to remove it, he said it's fine with him. Do I have to bug ftp.debian.org? > + locale-vi uploaded 202 days ago, out of date by 192 days! > + locale-zh uploaded 190 days ago, out of date by 188 days! > probably should be removed from the archive as of glibc 2.2.x > (conflicts with glibc > 2.1.94, except on alpha) I thought they where obsolete with newer glibc packages. > + sdl-net1.1 uploaded 154 days ago, out of date by 144 days! I uploaded sdl-net1.2 this weekend, packages won't change to 1.2 automatically though (seperate -dev), but there won't be any new releases and there are no bugs on it. Rationale: I won't upload it again. ciao, 2ri -- locate sunny|grep place|xargs cat|paste ~/me sleep 4h
auditd as logrotate replacement?
Hi I got an offer from the friendly people at Core-SDI to make auditd (server part of theyer BSD licenced, in development, log management software) a full (read: better) replacement for logrotate. Will a package in non-US/main have any chance to be accepted as full replacement for logrotate? As I understand being in non-US does not mean that anybody can't use it, just that it can't be distributed from mirrors in certain (braindead) countries. ciao, 2ri -- locate sunny|grep place|xargs cat|paste ~/me sleep 4h
Re: auditd as logrotate replacement?
Sean 'Shaleh' Perry schrieb: > as long as lograte can be installed first, then I can later > install auditd and everything will just work, sure. I can't use logrotate with msyslog, it won't work, logrotate is just too limited. This would mean I have to move msyslog to non-US, since I will make it depend on auditd. So, basically, since auditd does feature encryption, it does not have any chance to be the default for log rotation, even if it was a lot better than logrotate? What giant pile of crap. > Since it is in non-us, at least for now that means it will not > appear on a official debian cd. Did I say I hate it? Shaleh, don't take it personally ... ciao, 2ri -- locate sunny|grep place|xargs cat|paste ~/me sleep 4h
Re: Debian Afbackup
Salut Stephane Stephane Leclerc schrieb: > I've see that you uploaded 13 Apr 2001 a fix version of afbackup. > Do you know the status of this package?. I've sent an email to the official > maintainer and never got an answer. I don't use afbackup myself, and from what I remember of the changelog (/usr/share/doc/afbackup/changelog.Debian.gz) it's regular maintainer hasn't made an upload for some years. It looks like we have to find a new maintainer for afbackup :(. > The .deb is really old, don't works very well and I'll looking for a .deb > version of the up to date version. I currently use it directly from the > tarball but it's a paint to maintain on many boxes. And on Alpha, it's realy > hard to compile. > > Thanks to let me know. > > Stef... > > > .. > . Linux - Debian - php4 - Apache - MySQL - Infogerance . > . email: [EMAIL PROTECTED] - http://www.actionweb.fr . > . Tel: (0)141 906 100-Fax: (0)141 906 101. > .. > ciao, 2ri -- Hardware, n.: The parts of a computer system that can be kicked.
Re: Runlevel for powersaving
Ho [EMAIL PROTECTED] schrieb: > I have a suggestion, Why not define Runlevel 3&5 as > Powersaving mode console/powersaving mode graphics and put > some laptop specific services in those runlevels. I did a very similar thing on my notebook as well, it's really nice, but using apmd "events" for this would be even cuter, since apm knows when AC is plugged in anyway. Looking at apmd(8), it seems "change power" would fit, but unfortunately it doesn't tell you wheter AC was plugged in or out. Maybe something like "change power [ AC | battery ]" would serve better ... ciao, 2ri -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln
Re: rfc1149
Adam Heath schrieb: > Um, "Free as a Bird" is a song, and copyrighted, so they can't go in main. Copyrighting old german proverbs? *shudder* ciao, 2ri -- "Never" is almost always earlier than you think.
Re: dm management of wm listings (kdm/gdm/etc..)
Ivan E. Moore II schrieb:
> I think that this method would probably reduce the amount of possible
> duplication as long as the update-dm script pulled it's wm listing from
> /var/lib/dpkg/alternatives/x-window-manager for example. That way the only
> change any wm would have to do is add a call to update-dm in it's postinst.
> All dm's that would use this feature would then create a custom file and
> install it into /etc/X11/dm (for example) and run update-dm in it's postinst
> as well.
Have a look at update_wdm_wmlist, it get's a list of WMs by
looking at the x-{window,session}-manager alternatives.
Using the menu system's "needs=wm" entries would probably yield
too long titles for WDM.
ciao, 2ri
--
"Never" is almost always earlier than you think.
Re: Bug#95975: mutt: doesn't use charset anymore
Josip Rodin schrieb: > > Changing the LANG to en_US may have some unexpected side effects and > > should not be done without at least some thought for the consequences. > > (E.g., the sort order will be radically different.) > > Hear, hear, the thing with the sort order is so annoying. But I guess we'll > just have to get used to it >:( hmm, what's LC_COLLATE for again? ciao, 2ri, running LANG=de_CH; LC_MESSAGES=C -- The light at the end of the tunnel is the headlight of an approaching train.
Re: Work-needing packages report for May 4, 2001
Carlos Laviola schrieb: > I hope that's a joke, because, based _solely_ on that > comparison table, the reason one should use snarf over wget is > because it has a cool progressbar. snarf is also a lot smaller than wget. (According to the chart) ciao, 2ri -- They are really completely different things, so don't mix them up, but they have a close relation to each other. -- http://hurddocs.org/whatis/translator.html
Re: Finishing the FHS transition
Chris Waters schrieb: > (Plus, as a side issue, by a strict reading of the FHS, we should be > using /usr/share/menu rather than /usr/lib/menu, which means RC bugs > against nearly every package in the system!) :-) /usr/lib/menu is not shareable, since it would be most confusing to have a menu item that just doesn't work, because the package it belongs to is installed on another machine with which /usr/share is shared. ciao, 2ri -- Q: How does a Unix guru have sex? A: gunzip && strip && touch && finger && mount && fsck && \ more && yes && fsck && fsck && fsck && umount && sleep
Re: [FLAME WARNING] Linux Standards Base and Debian
Stephane Bortzmeyer schrieb: > below. RPM is the defacto standard on Linux [sic] and supported either > directly, or indirectly by the widest number of distributions. The statement is perfectly true, Debian supports RPM with aliens help. > The intent is to in the future replace this format with a new > format currently being developed. I'd like it much more if there was a simple "portable package format" (like GNU .tar.gz (ie with autoconf or workalike);) and distributions can build on that if they feel they need to. In short: most is there. > So, LSB is not a specification for Linux-based operating systems but for the > subset of them which uses the RPM format. What part of the quote leads you to this conclusion? ciao, 2ri -- No, I'm not going to explain it. If you can't figure it out, you didn't want to know anyway... :-) -- Larry Wall in <[EMAIL PROTECTED]>
