freefonts package already taken?
Hi, I just wanted to know if the freefont package as already been taken over. I am writing (finally) the Debian Type Manager (!?) and I need a package of fonts to test it. I will give more infos about the font manager in a week or so, just the time to put the preliminary package in experimental. (And the new freefonts that uses dtm, if I get it.) Ciao. * Federico Di Gregorio | / *-=$ ;-) TeX Wizard?* * Debian developer! | / -1pgp: finger [EMAIL PROTECTED] * * friend of penguins |/try http://www.debian.org* **DE 9E B2 75 B4 F6 CC 5B C3 D5 71 51 04 AB F3 B2** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dhelp 0.2 - a online help system
On 1 Gen, Jim Pick wrote: [EMAIL PROTECTED] writes: I like it but... I like it too. 1) How about dwww? (Yes, I know dwww needs a web server...) I think I'll add support for .dhelp files to dwww too. Oh, great! 2) I really dont like to have 2/3/... methods of building indexes of documentation installed in the debian system. What about integrating all that stuff? (menu, dwww, dhelp, etc...) I agree - we should eventually have only have one index. I've been working on yet another way of building an index, but I'm been very slow working on it. 3) The policy says the preferred doc format is HTML (fine) but it says nothing about how to access it. Any ideas before we poor developer have to write a dozen of different conf files to support all that new help systems? (menu entries, .dwww-index, .dhelp, etc...) I'd consider all documentation menu systems experimental at this point, so I wouldn't worry about it yet. Just support a particular menu style if you feel like playing with it. FWIW, the menu system I'm working on was going to be SGML/DSSSL based, so Marco's .dhelp menu format is perfect for that. I'll be able to use the .dhelp format as input. Short term (in the next few days), I'm also going to enhance the dwww menu-package based menus. I'll see if I can write a .dhelp to menu converter. That way, package authors can write a single .dhelp file, and support all the menu-building packages (dhelp, menu, and dwww-next-generation). The next dwww should be ready by Sunday, at least. I'll surely try it, and i'll give a try at dhelp. My only concern was about incompatibilities; as now not much packages support the dwww or menu systems and I thought that a new system will stop developers to add documentation entries. I can't wait for the new SGML based system... ciao. * Federico Di Gregorio | / *-=$ ;-) TeX Wizard?* * Debian developer! | / -1pgp: finger [EMAIL PROTECTED] * * friend of penguins |/try http://www.debian.org* **DE 9E B2 75 B4 F6 CC 5B C3 D5 71 51 04 AB F3 B2** -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
On Sun, 4 Jan 1998, Hamish Moffatt wrote: There is absolutely no necessity to have a kernel-source or kernel-headers package on your system (that I'm aware of). You can certainly dump your own copy of the Linux source tree into /usr/src/linux, compile it (with or without kernel-package/make-kpkg) and install it. dpkg/dselect won't care. I never use the source packages because I don't like the way they're already patched with some non-standard things in some cases. The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Lindsay Allen [EMAIL PROTECTED] Perth, Western Australia voice +61 8 9316 248632.0125S 115.8445Evk6lj Debian Unix =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's going on with gpc?
This is an apology for not having packaged a new release of gpc yet. I was planning to work on it during our final exam period, which is always a quiet time for me, then our new head of faculty decided he wanted the student grades anaylsed and reported in 20,000 different ways (well not actually that many, but a lot). So instead of being able to work on gpc, have been up to my neck modifying some very old Cobol programs (I didn't know anyting about Cobol 2 weeks ago), sql programming and so gpc has been neglected. Things should slow down next week when we start the inter-semester break, so hopefully I will have something finished by the end of January. Apologises to anyone waiting, Richard At 09:40 PM 1/3/98 +0200, Kai Henningsen wrote: [EMAIL PROTECTED] (Richard Davies) wrote on 07.12.97 in [EMAIL PROTECTED]: This is a request for some feedback from current and potential users of GPC. I have GPC 2.0 compiled for hamm, built using GCC 2.7.2.3. The next version of GPC (currently 971001) is in beta, but is already more stable than GPC 2.0. There seems to be a few possibilities available. I could package GPC 2.0, GPC 971001 beta, both versions, or wait until GPC 971001 beta is released as GPC 2.1. Let me know your preferences, if any, within the next few of days and I will then decide which course of action to take. The archive has 2.0-3 in both bo and project/orphaned (well, the latter is source-only), from 1996, from Christoph Lameter. And WNPP claims that Christoph orphaned them, and Paul J. Thompson took it. Is anybody working on it? MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy.
Manoj Srivastava [EMAIL PROTECTED] writes: Hold on right there!! This is something indistinguishable from magic!! kernel-headers installs files in /usr/src/kernel-headers-X.X.XX. It never installs into /usr/src/linux-* or usr/src/my-kernel-version. The postinst may create the link, but the files are already installed. My apologies, you're right. I wasn't paying close enough attention. In any case, I've already started moving all my stuff to /usr/local/src (which I probably should have done originally). -- Rob Browning [EMAIL PROTECTED] PGP fingerprint = E8 0E 0D 04 F5 21 A0 94 53 2B 97 F5 D6 4E 39 30 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
FTP Archive cleanup
I had written a script which checks the archive for missing and extra source and binaries some time ago. I've finally acted on its output. I've orphaned any old source packages. Some are obviously obsolete (such as tcl74, tcl75, tk40, tk41). Others are useful but have no active maintainer. I've removed any binary packages which weren't being generated by a source package. This cleaned up a lot of cruft and unfortunately (or not) all the a.out packages. hamm currently has no a.out support, runtime or development. Apparently there are some commercial packages which are only available in a.out format, so we ought to at least provide libc4. I don't think it's necessary to support development. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: Looking for a reason to not orphan my howto
Do you mean bo or hamm? I do not have a problem with libc5 on my hamm machine. And I don't know what's the problem with libc5-dev especially why it should be in hamm. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Martin Schulze [SMTP:[EMAIL PROTECTED] Sent: Friday, January 02, 1998 12:41 AM To: Meskes, Michael Subject: Re: Looking for a reason to not orphan my howto Importance: High On Thu, Jan 01, 1998 at 08:23:04PM +0100, Meskes, Michael wrote: libc5-dev for hamm??? And what's wrong with libc5 in hamm? IMO it's a waste of time to upgrade the bo version now that we're close to completing hamm. No it's not. If we don't have a working libc5 for hamm people can't upgrade. This would break the whole debian philosopy. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / File: ATT00075.ATT -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: FTP Archive cleanup
On 5 Jan 1998, Guy Maor wrote: Apparently there are some commercial packages which are only available in a.out format, so we ought to at least provide libc4. I don't think it's necessary to support development. I agree. I think xcompat should also be provided, for the same reason. Remco -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: FTP Archive cleanup
Are you sure nothing depends on the older tcl an tk versions? I think axe still depends tcl74 for instance. Joost, will you update axe? Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Guy Maor [SMTP:[EMAIL PROTECTED] Sent: Monday, January 05, 1998 9:39 AM To: debian-devel@lists.debian.org Subject: FTP Archive cleanup I had written a script which checks the archive for missing and extra source and binaries some time ago. I've finally acted on its output. I've orphaned any old source packages. Some are obviously obsolete (such as tcl74, tcl75, tk40, tk41). Others are useful but have no active maintainer. I've removed any binary packages which weren't being generated by a source package. This cleaned up a lot of cruft and unfortunately (or not) all the a.out packages. hamm currently has no a.out support, runtime or development. Apparently there are some commercial packages which are only available in a.out format, so we ought to at least provide libc4. I don't think it's necessary to support development. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
cron jobs more often than daily
I'm working on a package of ipac, some scripts to set up
and summarise IP accounting info from the kernel. The author
suggests running part of it every 15 minutes. The advantage
to this is that there is less data lost in case of a system crash
(the author's point), and it also lets you get summaries
between a particular times, so obviously we get more resolution
if we run it more often.
However, policy indicates that you can only get your job
to run daily, weekly, or monthly, by putting entries in
/etc/cron.{daily,weekly,monthly}. Anything that runs more often
has a user assigned to it who gets the cronjob (eg smail
runs runq from mail's crontab, inewsinn installs crontabs for
news).
However, there's no suitable user for this and it needs
to run as root anyway to reset the accounting stats.
Am I stuck with daily?
Hamish
--
Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Work I want to do for hamradio section
Hi, I am working on a few debian packages here. They are for hamradio: tpp-convers-1.14 pileup-1.1 sccw-1.0 unixcw-1.0 Cheers, Joop -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote:
I'm working on a package of ipac, some scripts to set up
and summarise IP accounting info from the kernel. The author
suggests running part of it every 15 minutes. The advantage
to this is that there is less data lost in case of a system crash
(the author's point), and it also lets you get summaries
between a particular times, so obviously we get more resolution
if we run it more often.
However, policy indicates that you can only get your job
to run daily, weekly, or monthly, by putting entries in
/etc/cron.{daily,weekly,monthly}. Anything that runs more often
has a user assigned to it who gets the cronjob (eg smail
runs runq from mail's crontab, inewsinn installs crontabs for
news).
However, there's no suitable user for this and it needs
to run as root anyway to reset the accounting stats.
Am I stuck with daily?
Why not add a job like:
*/15 * * * * root/usr/sbin/ipac-cron
to /etc/crontab? The predecessor of at has done this, too.
Regards
Joey
--
/ Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg /
/Erfahrung ist eine nützliche Sache /
/ Leider macht man sie immer erst kurz nachdem man sie brauchte /
pgpmaorVfVWMH.pgp
Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: However, there's no suitable user for this and it needs to run as root anyway to reset the accounting stats. Am I stuck with daily? Why not add a job like: */15 ** * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says 3.5. Cron jobs -- Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? thanks, Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpVKIqkKADfH.pgp Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 11:31:09PM +1100, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: However, there's no suitable user for this and it needs to run as root anyway to reset the accounting stats. Am I stuck with daily? Why not add a job like: */15 * * * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says 3.5. Cron jobs -- Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? Oups. Well, rules exist for breaking them... An old idiom... Then your only chance is to write an ipacd that forks, lets the daughter call the ipcac-cron script , waits 15 mins and forks again. Started via /etc/init.d/ipac. Well, I know which version I would prefer but maybe the second one is better as you can control that you start your script only if the most recent child has terminated. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / pgps4zx7Nvu5a.pgp Description: PGP signature
Re: uploaded dhelp (i386 source)
Marco Budde [EMAIL PROTECTED] writes: Description: dhelp - online help system Changes: dhelp (0.2.1) unstable; urgency=low * cgiparse binary (from CERN httpd) isn't it better to use the correct Recommends/Depends flag instead of doubling the binaries. * dbugreport (report Debian bugs) where's the difference to the bug program (located in the package bug)? Btw.: Shouldn't we switch the priority for bug to a higher one, i.e. standard or essential!? It's a small but very useful program that should be found on *every* Debian system. Bye Christian -- Christian Leutloff, Aachen, Germany [EMAIL PROTECTED] http://www.oche.de/~leutloff/ Debian GNU/Linux 1.3.1! Mehr unter http://www.de.debian.org/ pgp2pwcTRhN8E.pgp Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 01:35:08PM +0100, Martin Schulze wrote: On Mon, Jan 05, 1998 at 11:31:09PM +1100, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: Why not add a job like: */15 ** * * root/usr/sbin/ipac-cron to /etc/crontab? The predecessor of at has done this, too. Policy 2.3.0.1 says Packages may not touch the configuration file `/etc/crontab', nor may they modify the files in `/var/spool/cron/crontabs'. Doesn't this rule this out? Oups. Well, rules exist for breaking them... An old idiom... Then your only chance is to write an ipacd that forks, lets the daughter call the ipcac-cron script , waits 15 mins and forks again. Started via /etc/init.d/ipac. Urgh, I hate it already. Can somebody post a rationale for the section of policy quoted above? I notice that mgetty has added faxrunq to my /etc/crontab on my bo system. Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgpGLKBPLdOEM.pgp Description: PGP signature
Re: cron jobs more often than daily
On Mon, Jan 05, 1998 at 11:58:12PM +1100, Hamish Moffatt wrote: Urgh, I hate it already. Can somebody post a rationale for the section of policy quoted above? I notice that mgetty has added faxrunq to my /etc/crontab on my bo system. In fact, mgetty-fax's postinst said the modification of /etc/crontab was done automatically by debstd! Perhaps my mistake was using debhelper; if I use debstd, I can reassign any bugs filed against my package for modifying /etc/crontab to debstd :-) Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org pgp0eXYAhtjy3.pgp Description: PGP signature
Anyone using dhelp with netscape?
It seems communicator 4.0 doesn't like it at all. As soon as I click on the debian link netscape gets a bus error. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Question/request concerning master
Firstly, there is this: blp:/raid/home/blp$ ftp master Connected to master.debian.org. 220-This system is for internal use by the Debian developers. It is not 220-open to anonymous FTP. Please use ftp.debian.org or one of its many 220-mirrors. 220- 220 debian FTP server (Version wu-2.4(14) Wed Jan 8 21:17:19 MET 1997) ready. Name (master:blp): pfaffben 530- 530-Sorry, there are too many anonymous users using the system at this 530-time. Please try again later. There is currently a limit of 10 530-anonymous users for your domain group. 530- 530 User pfaffben access denied Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp quit 221 Goodbye. blp:/raid/home/blp$ Why am I considered an anonymous user?! Secondly, could the lftp program be installed on master? It's nicer than ftp, and it's freer than ncftp. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Tue, 6 Jan 1998, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 11:58:12PM +1100, Hamish Moffatt wrote: Urgh, I hate it already. Can somebody post a rationale for the section of policy quoted above? I notice that mgetty has added faxrunq to my /etc/crontab on my bo system. The idea behind the policy is explained in `3.3.7 Configuration files'. As /etc/crontab is a configuration file of the cron package, no other package may touch it. That's because in the past, we had packages that messed around with other packages configuration files. The solution presented in 3.3.7 is that the owner of the conffile (cron in that case) provides a utility (like install-info, for example) through which other packages can register and remove cron jobs. I suggest you file a wish-list bug report against cron. You can refer to me, if you want. In fact, mgetty-fax's postinst said the modification of /etc/crontab was done automatically by debstd! Yeah, this is one of the biggest lies: debstd. Please let me say this very loud again: debstd does _NOT_ stand for DEBIAN STANDARD, it stands for CL's interpretation of the DEBIAN STANDARD, which often differs from the policy Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Perhaps my mistake was using debhelper; if I use debstd, I can reassign any bugs filed against my package for modifying /etc/crontab to debstd :-) Yes, please file bug reports against debstd. Note, that I don't know if debhelper is any better regarding the cron policy--I hope so. Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Hamish Moffatt wrote: [modifying /etc/crontab] Urgh, I hate it already. Can somebody post a rationale for the section of policy quoted above? I notice that mgetty has added faxrunq to my /etc/crontab on my bo system. One rationale can be found in policy section 3.3.7: A package may not modify a configuration file of another package. /etc/crontab is a conffile of package cron. Perhaps this could be solved by having cron provide an update-crontab command, just like update-inetd, et cetera. (And it does look like we need a generic framework for things like this, like Guy Maor described.) Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
apsfilter or magicfilter
Couldn't anyone please tell me if one's superior? Currently I use magicfilter (and btw couldn't find apsfilter in hamm). Thanks Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
driver for Epson Stylus 300
Does anyone know if there is a ghostscript driver for this new printer available? Yes, I can use the other Stylus drivers, but that means the printer tries to print black by mixing the other three colors, not by using the black ink. Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On Mon, 5 Jan 1998, Hamish Moffatt wrote: : On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: : On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: : However, there's no suitable user for this and it needs : to run as root anyway to reset the accounting stats. : Am I stuck with daily? : : Why not add a job like: : : */15 * * * * root/usr/sbin/ipac-cron : : to /etc/crontab? The predecessor of at has done this, too. : : Policy 2.3.0.1 says : : 3.5. Cron jobs : -- : : Packages may not touch the configuration file `/etc/crontab', nor may : they modify the files in `/var/spool/cron/crontabs'. : : Doesn't this rule this out? The mrtg package in hamm adds an entry to /etc/crontab; it also places comments around the entry to aid future removal, I suppose. This may violate policy (I don't know), but it does show that other packages are doing this. : : thanks, : Hamish : -- : Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] : Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 : CCs of replies from mailing lists are welcome. http://hamish.home.ml.org : -- Nathan Norman MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104 phone: (605) 334-4454 fax: (605) 335-1173 mailto://[EMAIL PROTECTED] http://www.midco.net PGP Key ID: 0xA33B86E9 - Public key available at keyservers PGP Key fingerprint: CE03 10AF 3281 1858 9D32 C2AB 936D C472 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: cron jobs more often than daily
Yes, it does. Worse than that are the packages that update /etc/services like transproxy. Everytime Peter adds a service I have to manually change the /etc/services file. Argh! Couldn't we find a common way for packages to adjust other packages conffiles? I don't like the idea of and update-crontab, update-services etc. in my filesystem. Eventually we need a special update-bin directory. :-) Michael -- Dr. Michael Meskes, Project-Manager| topsystem Systemhaus GmbH [EMAIL PROTECTED]| Europark A2, Adenauerstr. 20 [EMAIL PROTECTED] | 52146 Wuerselen Go SF49ers! Go Rhein Fire! | Tel: (+49) 2405/4670-44 Use Debian GNU/Linux! | Fax: (+49) 2405/4670-10 -Original Message- From: Nathan E Norman [SMTP:[EMAIL PROTECTED] Sent: Monday, January 05, 1998 4:12 PM To: Debian Developers List Subject: Re: cron jobs more often than daily On Mon, 5 Jan 1998, Hamish Moffatt wrote: : On Mon, Jan 05, 1998 at 01:26:56PM +0100, Martin Schulze wrote: : On Mon, Jan 05, 1998 at 09:48:42PM +1100, Hamish Moffatt wrote: : However, there's no suitable user for this and it needs : to run as root anyway to reset the accounting stats. : Am I stuck with daily? : : Why not add a job like: : : */15 ** * * root/usr/sbin/ipac-cron : : to /etc/crontab? The predecessor of at has done this, too. : : Policy 2.3.0.1 says : : 3.5. Cron jobs : -- : : Packages may not touch the configuration file `/etc/crontab', nor may : they modify the files in `/var/spool/cron/crontabs'. : : Doesn't this rule this out? The mrtg package in hamm adds an entry to /etc/crontab; it also places comments around the entry to aid future removal, I suppose. This may violate policy (I don't know), but it does show that other packages are doing this. : : thanks, : Hamish : -- : Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] : Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 : CCs of replies from mailing lists are welcome. http://hamish.home.ml.org : -- Nathan Norman MidcoNet - 410 South Phillips Avenue - Sioux Falls, SD 57104 phone: (605) 334-4454 fax: (605) 335-1173 mailto://[EMAIL PROTECTED] http://www.midco.net PGP Key ID: 0xA33B86E9 - Public key available at keyservers PGP Key fingerprint: CE03 10AF 3281 1858 9D32 C2AB 936D C472 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: apsfilter or magicfilter
Michael Meskes wrote: Couldn't anyone please tell me if one's superior? Currently I use magicfilter (and btw couldn't find apsfilter in hamm). apsfilter was removed in favour of magicfilter, partly because it had some grave packaging bugs and no-one was maintaining it. (As far as I know, there's no upstream maintainer for it either.) It's currently in project/orphaned. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
New Maintainer for libc5/libc6
I have been speaking with David Engel about the current problems with libc5 and libc6. I have agreed to take over these packages (with a boost up the learning curve from David) and become their maintainer. While I am not as informed as I would like to be, as to the inner workings of these libraries, it is time for me to learn what I can about their construction and installation. While this makes me an inferior candidate in some ways, I have been the only one to respond to David's frustrations finding help with these packages. If anyone else has a more pressing need to maintain these packages, now is the time to step forward. If I hear no objections, I will work toward applying David's patch and getting a new release of libc5 out ASAP (hopefully before the end of the week). My goal is to get a libc5 that can be installed on a bo system and allow a clean upgrade path to libc6. Any and all help will be appreciated, so don't hesitate to comment if you think it will help. Waiting is, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: dhelp 0.2 - a online help system
Marco == Marco Budde [EMAIL PROTECTED] writes: Marco We could write a converter :)? I'd rather see a unified interface for that sort of thing than a kludgey converter converter scheme. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Christian Schwarz [EMAIL PROTECTED] writes: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. Looks good to me. Mike. -- Michael Alan Dorman | E-Mail: [EMAIL PROTECTED] Network Administrator | Phone: (305) 284-2463 University of Miami School of Law | Fax: (305) 284-3753 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: driver for Epson Stylus 300
Does anyone know if there is a ghostscript driver for this new printer available? Yes, I can use the other Stylus drivers, but that means the printer tries to print black by mixing the other three colors, not by using the black ink. There may be another way, but you can by installing gs-aladin. In 5.0.3 there is a new driver (called uniprint) which works great. I'm using it with my Stylus Color 600. - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
On Mon, Jan 05, 1998 at 12:30:09PM -0500, Dale Scheetz wrote: If anyone else has a more pressing need to maintain these packages, now is the time to step forward. If I hear no objections, I will work toward applying David's patch and getting a new release of libc5 out ASAP You did notice the updated versions of this patch posted in the need libc5 non-maintainer upgrade thread, didn't you? Ray -- PATRIOTISM A great British writer once said that if he had to choose between betraying his country and betraying a friend he hoped he would have the decency to betray his country. - The Hipcrime Vocab by Chad C. Mulligan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
This section is in my /etc/crontab... I see no problem with it. Perhaps there ought to be a thing like the script that updates inetd.conf for the crontab. I would also like an /etc/cron.scripts directory. #-- postgresql begin 0 4 * * * postgres/usr/lib/postgresql/bin/do.maintenance #-- postgresql end -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Question/request concerning master
On Mon, 5 Jan 1998, Ben Pfaff wrote: Firstly, there is this: blp:/raid/home/blp$ ftp master Connected to master.debian.org. 220-This system is for internal use by the Debian developers. It is not 220-open to anonymous FTP. Please use ftp.debian.org or one of its many 220-mirrors. 220- 220 debian FTP server (Version wu-2.4(14) Wed Jan 8 21:17:19 MET 1997) ready. Name (master:blp): pfaffben 530- 530-Sorry, there are too many anonymous users using the system at this 530-time. Please try again later. There is currently a limit of 10 530-anonymous users for your domain group. 530- 530 User pfaffben access denied Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp quit 221 Goodbye. blp:/raid/home/blp$ Why am I considered an anonymous user?! I suspect the error message of being a fall through. I just tried the same route and was rejected. In the past this has been because someone has disabled ftp on master, and it usually clears up soon. You should still be able to telnet into master and then ftp from your site to master. Secondly, could the lftp program be installed on master? It's nicer than ftp, and it's freer than ncftp. Can't speak to this one ;-) Waiting is, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian The solution presented in 3.3.7 is that the owner of Christian the conffile (cron in that case) provides a utility Christian (like install-info, for example) through which other Christian packages can register and remove cron jobs. Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Is there a maintainer for the install doc?
Is anyone maintaining the Debian installation manual? I know that Sven is no longer doing it. If not, we will need a volunteer. - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 03:02:38PM +0100, Christian Schwarz wrote: On Tue, 6 Jan 1998, Hamish Moffatt wrote: Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Isn't automake the GNU program for using with autoconf ? automake creates Makefile.in's out of Makefile.am's. The Makefile.in's will be processed by configure (which itself is created by autoconf out of configure.in) to Makefiles. Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? Thank you, Marcus -- Rhubarb is no Egyptian god. Debian GNU/Linux Marcus Brinkmann http://www.debian.org [EMAIL PROTECTED] http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Is there a maintainer for the install doc?
James A.Treacy [EMAIL PROTECTED] writes: Is anyone maintaining the Debian installation manual? I know that Sven is no longer doing it. That's mainly true, however this manual is part of the boot-floppies package and has to be changed quickly when the boot disks are changed. So the person working on this manual needs to cooperate with the people workinh on boot-floppies. Sven -- Sven Rudolph [EMAIL PROTECTED] http://www.sax.de/~sr1/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
On Mon, 5 Jan 1998 [EMAIL PROTECTED] wrote: On Mon, Jan 05, 1998 at 12:30:09PM -0500, Dale Scheetz wrote: If anyone else has a more pressing need to maintain these packages, now is the time to step forward. If I hear no objections, I will work toward applying David's patch and getting a new release of libc5 out ASAP You did notice the updated versions of this patch posted in the need libc5 non-maintainer upgrade thread, didn't you? The patch I intend to use comes directly from David. Any changes to that patch need to be discussed before I will add them to the package. Waiting is, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Question/request concerning master
On Mon, Jan 05, 1998 at 08:05:59AM -0500, Ben Pfaff wrote: blp:/raid/home/blp$ ftp master Connected to master.debian.org. 220-This system is for internal use by the Debian developers. It is not 220-open to anonymous FTP. Please use ftp.debian.org or one of its many 220-mirrors. 220- 220 debian FTP server (Version wu-2.4(14) Wed Jan 8 21:17:19 MET 1997) ready. Name (master:blp): pfaffben 530- 530-Sorry, there are too many anonymous users using the system at this 530-time. Please try again later. There is currently a limit of 10 530-anonymous users for your domain group. 530- 530 User pfaffben access denied Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp quit 221 Goodbye. blp:/raid/home/blp$ Why am I considered an anonymous user?! You are not. Only the msg.toomany contains the word 'anonymous'. I've changed it to 'ftp'. There's a limit of 10 ftp users at the moment. Anonymous users are limited to 0 - say: it's turned off. Secondly, could the lftp program be installed on master? It's nicer than ftp, and it's freer than ncftp. It's installed now. If va would answer it'll be installed there, too. Expect this to be happened in approx 30mins. Regards Joey -- / Martin Schulze * [EMAIL PROTECTED] * 26129 Oldenburg / /Erfahrung ist eine nützliche Sache / / Leider macht man sie immer erst kurz nachdem man sie brauchte / pgpxwblqoMLTY.pgp Description: PGP signature
Re: What warrants a non-maintainer release number?
On 5 Jan 1998, Michael Alan Dorman wrote: Christian Schwarz [EMAIL PROTECTED] writes: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. Looks good to me. I'm a bit confused by the context of these comments. What is being solved here? It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. All debian changes are reflected in the diff file produced by dpkg-buildpackage. Any changes to the debianized source (even a simple change in the dependencies) should create a new and unique version of the .deb .changes .dsc and .diff files, none of which requires either changing or uploading source files. What am I missing here? Waiting is, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
I think that /usr/src should the be domain of the local admin.
I don't think kernel-{header,source}-x.xx.deb should exist, really,
because I don't think source code should be distributed as .deb files
anyway. So I'm not unhappy about making a policy decision that leaves
kernel-{header,source} with nowhere good to go.
Why does libc6 depend on kernel-header ?
Manoj writes:
Current [ractices, as far as debian is concerned, is that
debian owns /usr/src. This has been the case since April 1996 (that's
1.75 years now!)
This may be the case if you look at all packages, but I have never
installed any packages that did this, and if I had I would have
reported it as a bug.
What's new is that packages wanted even by people who think they own
/usr/src might actually install there.
Ian.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Christian Schwarz wrote: Note, that I don't know if debhelper is any better regarding the cron policy--I hope so. Debhelper doesn't have any provision for modifying /etc/crontab, since that is prohibited by policy. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
In message [EMAIL PROTECTED] you write: | a 64 bit variable, it's good for another 4000 years. | |Uhhh -- no. If it went from 32 bits to *33* bits, that would get us Actually, the current limit of 68 years (1970 + 68 = 2038) is posed by the used of SIGNED int (31 bits) instead of unsigned bits: |butch| bc -l bc 1.04 Copyright (C) 1991, 1992, 1993, 1994, 1997 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2^31 2147483648 2^31/(60*60*24*365) 68.09625976661593099949 Just moving to unsigned int will give you 68 more years, up to year 2106: 2^32 4294967296 2^32/(60*60*24*365) 136.19251953323186199898 1970+136 2106 So it's even simpler in regards of type size, but moving to an unsigned int may cause serious troubles in comparing dates (unless you use some functions which hide thedetails). |4000 years. This gets us more like 16 billion billion years (american |billions - 16 x 10^18 is what I mean, but it's off the top of my head...) Where did you get this 4000 years figure anyway? 33 bits would just double the duration from 136 years to 272 (bringing us to year 2242). Cheers, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Topi Miettinen wrote:
We have cron.{month,week,dai}ly, why not add directories hourly, bihourly
(every 30min), and quarterly (every 15min). That would give enough
resolution for most daemons.
Mrtg needs to run every 5 minutes.
--
see shy jo
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
Ian Jackson [EMAIL PROTECTED] writes:
I think that /usr/src should the be domain of the local admin.
I agree.
I don't think kernel-{header,source}-x.xx.deb should exist, really,
because I don't think source code should be distributed as .deb files
anyway. So I'm not unhappy about making a policy decision that leaves
kernel-{header,source} with nowhere good to go.
We do need kernel headers in some kind of package, for compiling programs.
It wouldn't look good to release 2.0 with the requirement that you must
obtain kernel source and/or install it separately to have a working
development environment.
Why does libc6 depend on kernel-header ?
It's libc6-dev that has that dependency.
Perhaps weakening the dependency to Suggests might be the best solution.
What's new is that packages wanted even by people who think they own
/usr/src might actually install there.
Yes, I think the policy needs to be updated to explicitly cover this point.
Martin.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? I don't know why all those patches are already applied. I have stopped using the kernel-source packages because they can't be patched up to the next kernel version easily (because of the already applied patches). You should be able to install kernel-headers to satisfy it and then dump the standard Linux source tree in for building kernels. Does anyone know why there is a dependency on kernel-headers? I was under the impression that glibc didn't use the kernel headers. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Steve Dunham [EMAIL PROTECTED] writes: SD Hamish Moffatt [EMAIL PROTECTED] writes: HM On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: LA The kernel-source-2.0.32 deb has a 130K diff file against the LA standard source. Just where do these patches come from and why LA are they necessary? Is the fact that I _have_ to have 2.0.32 LA source or headers going to stop me from going to 2.0.33? HM HM I don't know why all those patches are already applied. I have HM stopped using the kernel-source packages because they can't be HM patched up to the next kernel version easily (because of the HM already applied patches). You should be able to install HM kernel-headers to satisfy it and then dump the standard Linux HM source tree in for building kernels. SD SD Does anyone know why there is a dependency on kernel-headers? I SD was under the impression that glibc didn't use the kernel headers. ...or why it depends on kernel-headers-2.0.32 instead of just kernel-headers, which is provided by the kernel-source-* and kernel-headers-* packages? -- _ / \ The cat's been in the box for over | David Maze | 20 years. Nobody's feeding it. The | [EMAIL PROTECTED] |cat is dead. | http://donut.mit.edu/dmaze/ | -- Grant, on Schroedinger's Cat \_/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLEmFyqK7IlOjMLFAQGk1QQAkunssgl4fkpPCLl6uv5uoRFYsmsdK7PZ 48i9g9K71+jiyYkxbjPh/uwak4CBjjbObfZcWryBalQ85omrOvktPcpdssxUdMnu 4V0HoiAmFxSaYczaZZauCzgR8mGDgFtdh4EuUELKyr8xKRCfEDWpAk0DolYEU98k 7WdpgUD8XUQ= =Qxo2 -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
On 5 Jan 1998, Steve Dunham wrote: Hamish Moffatt [EMAIL PROTECTED] writes: On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: The kernel-source-2.0.32 deb has a 130K diff file against the standard source. Just where do these patches come from and why are they necessary? Is the fact that I _have_ to have 2.0.32 source or headers going to stop me from going to 2.0.33? I don't know why all those patches are already applied. I have stopped using the kernel-source packages because they can't be patched up to the next kernel version easily (because of the already applied patches). You should be able to install kernel-headers to satisfy it and then dump the standard Linux source tree in for building kernels. Does anyone know why there is a dependency on kernel-headers? I was under the impression that glibc didn't use the kernel headers. The libc6-dev package used to include its own copy of the linux and asm directories from the kernel source. The libc6 maintainer decided that it was rather pointless to make a hude diff that was essentially just the kernel-headers package, so the dependancy was added again. It is for a version-specific package for the reasons given in /usr/doc/libc6/FAQ.Debian.gz -- Scott K. Ellis [EMAIL PROTECTED] http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
please upgrade your packages to current standards
Hi folks! Yesterday, I wrote a script that scans our whole archive for .dsc files (Debian source package description files) and outputs some statistics regarding the `Standards-Version' fields, that is, which policy version the packages claim to comply with (according to the maintainer). Here are the results (mirror timestamp Thu Jan 1 22:00:01 UTC 1998) splitted into the different sections: (Note, the numbers or source packages, not binary packages.) Standards-Version hamm contrib non-free non-us TOTAL 0 1 1 0.0 1 1 0.1 1 12 0.2.1.1 14 14 0.2.2.0 2 2 1.4.0.19 2 2 2.0.0.0 91 1 2 13 2.0.1.0 12 2 14 2.0.1.5 1 1 2.1.0.0 562 4 1 63 2.1.1.0 176621 2 205 2.1.1.2 19 5 24 2.1.1.6 1 1 2.1.2.2 302 2148 4 375 2.1.221 1 2.1.3.0 252 2 29 2.1.3.1 21 3 2.1.3.2 18 8 26 2.1.3.3 5 27 2.2.0.0 41116 1 59 2.2.0.1 1 1 2.2.2.0 1 1 2.3.0.0 162833 1 204 2.3.0.1 150 1016 2 178 TOTAL 1003 52 159 13 1227 With this, we have 44 packages that specify an invalid (i.e., non-existant) policy version and 728 packages (out of 1227, that's nearly 60% !) claim to apply to a policy older than one year!!! Unless someone objects, I'll report bugs against the 44 packages. Since I don't think (at least I hope :-) that our packages are that bad and _do_ actually comply with current policy in most cases, it looks like the maintainers simply don't upgrade this field very often. Therefore, I suggest that you check your packages against current policy and upgrade the field with the next upload you make. (The last digit of the policy version number represents the patch-level, so I don't really care if you specify 2.3.0.0 or 2.3.0.1, but it does matter if you set this to 0.0 :-) To simplify the policy-upgrade process, I created a checklist which is attached below. You can use this list to get a quick overview about the major changes between the policy versions. If you need more details (or if you are upgrading from a very old version), please check out the Policy Manual. (The checklist will show up on the policy home page shortly.) Thanks, Chris -cut-here--- Policy checklist for upgrading your packages About the checklist The checklist below has been created to simplify the upgrading process of old packages. Note, that this list is not `official.' If you have doubts about a certain topic, if you need more details, or if you think some other package does not comply with policy, please refer to the Policy Manual. Here is how the check list works: Check out which policy version your packages complies with currently. Than move upwards until the top and check which of the items on the list might concern your package. If the item does not give you enough details, please check out the Policy Manual. The checklist 2.3.0.1, 2.3.0.0Sep 97 * new section `4.2 Daemons' including rules for /etc/services, /etc/protocols, /etc/rpc, and /etc/inetd.conf * updated section about `Configuration files': packages may not touch other packages' configuration files * MUAs and MTAs have to use liblockfile 2.2.0.0 Jul 97 * added section 4.1 `Architecture specification strings': use arch-linux where arch is one of the following: i386, alpha, arm, m68k, powerpc, sparc. * detailed rules for /usr/local * user ID's * editor/pager policy * cron jobs * device files * don't install shared libraries as executable * app-defaults files may not be conffiles 2.1.3.2, 2.1.3.1, 2.1.3.0 Mar 97 * two programs with different functionality must not have the same name * Webstandard 3.0 * Standard for Console Messages * Libraries should be compiled with `-D_REENTRANT' * Libraries should be stripped with strip --strip-unneeded 2.1.2.2, 2.1.2.1, 2.1.2.0 Nov 96
Re: Re^2: dhelp 0.2 - a online help system
On 5 Jan 1998, Karl M. Hegbloom wrote: Marco == Marco Budde [EMAIL PROTECTED] writes: Marco We could write a converter :)? I'd rather see a unified interface for that sort of thing than a kludgey converter converter scheme. Once written, doc-base will be the interface for all online documentations. (Not only registering the manuals to menus, but also converting between different documentation formats, compressing documentation, etc.) Though we definitely need some time discussing the new documentation policy we could perhaps start working on the menu registry with doc-base to get some experience in this area. If someone wants to do this with me, just drop me a note. I'm just waiting for volunteers... Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Intent to package amiwm; DFSG ramblings
I'm planning on packaging the amiwm window manager. It's an AmigaOS lookalike WM, with multiple workspaces and a customizable tools menu (but it doesn't support submenus as yet, so menu package support will have to wait for this upgrade). Anyway, it looks like it's going to have to be in non-free. I contacted the author on the copyright, and this is what he said: ---Marcus Comstedt [EMAIL PROTECTED] wrote: I'm aware that the copyright statement is very fuzzy and I'll try to supply a better one in future distributions (if any). Anyway, the license for amiwm does _not_ contain a generic license to produce derived works using my source code. I'll probably grant licenses to specific derived works should someone ask me, but no such license is given implicitly with the software. I'll allow distribution of patches in the form of diffs though. My filosofy here is that I don't want people to confuse bugs written by other people with the bugs written by me. ;) Since there's no implicit derived works license, my understanding is that this contravenes DFSG section #4, which requires an explicit license (and it would have to be a non-exclusive one). Anyway, perhaps we need to look at providing a section between contrib and non-free that allows for software that is redistributable without restrictions but is not DFSG-free (i.e. stuff that people can stick on CD-ROMs without wandering through every copyright file in non-free), or at least a convention for tagging non-free packages as CD-ROMable. This would be consistent with our goal of making it easy for people to produce CD-ROMs of our system without violating any licenses, import/export restrictions, or any other laws (per Policy) and would not compromise the ideological purity of the DFSG. Chris == Chris Lawrence Email: [EMAIL PROTECTED] Senior Political Science Major University of Memphis Contract Programmer Memphis, Tennessee, USA FedEx - Operations Research _ DO YOU YAHOO!? Get your free @yahoo.com address at http://mail.yahoo.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, 5 Jan 1998, Marcus Brinkmann wrote: On Mon, Jan 05, 1998 at 03:02:38PM +0100, Christian Schwarz wrote: On Tue, 6 Jan 1998, Hamish Moffatt wrote: Thus, the use of debstd is depreciated. Note, that I've removed debstd from all of my packages lately and would like to see others doing the same thing. As soon as we have the macro-utility (was it called automake?) set up, we should consider removing debstd. Isn't automake the GNU program for using with autoconf ? automake creates Makefile.in's out of Makefile.am's. The Makefile.in's will be processed by configure (which itself is created by autoconf out of configure.in) to Makefiles. Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? (BTW, the discussion about this was in mid Oct 97.) The idea is to create the debian/rules file by a macro processor. (Since automake is used to create Makefiles and debian/rules is a Makefile, someone suggested to use it. However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) This would have the advantage that every action would be included explicitely in the debian/rules file instead of hidden into some utilities. Furthermore, since debian/rules would be generated by the maintainer only, everyone else can recompile the package and get the same results. (With debstd this is one problem. You need exactly the same debstd version than the maintainer had to get the same package.) It would be nice if we could find one (or more) volunteers to do some experiments on that issue. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
On 5 Jan 1998, Karl M. Hegbloom wrote: Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian The solution presented in 3.3.7 is that the owner of Christian the conffile (cron in that case) provides a utility Christian (like install-info, for example) through which other Christian packages can register and remove cron jobs. Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? Since /etc/crontab is actually a conffile (no matter if you tag it as such or not) this would be a dirty hack around our policy. Fact is, that the cron package, the local sysadmin, and possibly other packages modify the /etc/crontab file. However, dpkg only controls modification between the sysadmin and _one_ package (cron here). I really think the cron package should provide a script where other packages can register cron jobs. I'll file a bug report. Thanks, Chris -- Christian Schwarz Do you know [EMAIL PROTECTED], [EMAIL PROTECTED], Debian GNU/Linux?[EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
source packages and extensible apps
I'm working on packaging the Berkeley NS (network simulator) code. This is an extensible app, in the sense that users modify and add to the source code to add their own features. Two questions: - How should such a program be packaged? As a source package only or as both a source and a binary package (the program is usable w/o any modification). - Where should the source code go? Thanks, Mike PS: How long should one wait for an account on the debian master? I asked for one about 3 weeks ago... -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: [snip] BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. I think removing entries from the changelog is usually a bad thing, even for dot releases. Sometimes, the changelog is very useful to get some background info about the version one has installed. Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED], Don't know Perl? [EMAIL PROTECTED], [EMAIL PROTECTED] Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA http://www.perl.com http://fatman.mathematik.tu-muenchen.de/~schwarz/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On Mon, 5 Jan 1998, Ian Jackson wrote: I think that /usr/src should the be domain of the local admin. Why? Could you please give a few arguments for that? According to FSSTND and FHS: ``/usr/src: [...] Any non-local source code should be placed in this subdirectory.'' [snip] Manoj writes: Current [ractices, as far as debian is concerned, is that debian owns /usr/src. This has been the case since April 1996 (that's 1.75 years now!) This may be the case if you look at all packages, but I have never installed any packages that did this, and if I had I would have reported it as a bug. A few packages currently install into /usr/src: awe-drv, debian-cd, etc. I really fail to see what's wrong with that. IMHO, the local sysadmin has enough space for sources in /usr/local/src. Why should we treat sources different from libs, binaries, documentations, etc.? Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. If there is a reason to upload a new .deb package then that alone is sufficient to require an incremented version number. Every new release of a package should come with a new version. Only if an md5 sum of the new package is identical to that of the old would the version remain the same. In that instance there is no reason to upload the new file. Luck, Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Intent to package amiwm; DFSG ramblings
On Mon, 5 Jan 1998, Chris Lawrence wrote: [snip] Anyway, perhaps we need to look at providing a section between contrib and non-free that allows for software that is redistributable without restrictions but is not DFSG-free (i.e. stuff that people can stick on CD-ROMs without wandering through every copyright file in non-free), or at least a convention for tagging non-free packages as CD-ROMable. This would be consistent with our goal of making it easy for people to produce CD-ROMs of our system without violating any licenses, import/export restrictions, or any other laws (per Policy) and would not compromise the ideological purity of the DFSG. This has been discussed some time ago when we decided to make contrib packages also DFSG free. We didn't choose this option (to split non-free into non-free-but-freely-dist and really-non-free-stuff) since (a) we don't want to give guidelines for non-DFSG software (this would be against our project goals) and (b) what's `freely-dist' differs very much from vendor to vendor (depending on how much they charge, what else is on the CD, etc.). Sorry, but I think the amiwm package has to go into non-free for now. Thanks, Chris -- _,, Christian Schwarz / o \__ [EMAIL PROTECTED], [EMAIL PROTECTED], ! ___; [EMAIL PROTECTED], [EMAIL PROTECTED] \ / \\\__/ !PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA \ / http://fatman.mathematik.tu-muenchen.de/~schwarz/ -.-.,---,-,-..---,-,-.,.-.- DIE ENTE BLEIBT DRAUSSEN! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
Martin Mitchell [EMAIL PROTECTED] writes:
Ian Jackson [EMAIL PROTECTED] writes:
Why does libc6 depend on kernel-header ?
It's libc6-dev that has that dependency.
Perhaps weakening the dependency to Suggests might be the best solution.
No, you can't. Their are multiple header files that will be flat *broken*
without a /usr/include/{linux,asm}.
--
Stephen
---
Normality is a statistical illusion. -- me
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Christian Schwarz wrote: On Mon, 5 Jan 1998, Santiago Vila wrote: [snip] BTW: After the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package. I would add: You may want to use a point version number x.1 or x.5 and make it to disappear from the changelog as if it were never existed, as long as it is not released for stable. I think removing entries from the changelog is usually a bad thing, even for dot releases. Sometimes, the changelog is very useful to get some background info about the version one has installed. We want to release hamm as soon as possible. Therefore everybody should use the latest release of each package. If you release x, recompile it and call it x.1, and later release x+1, I don't see why x.1 should be kept in the changelog, being it just a recompile. I still think that changelog is *mainly* the history of *source* changes. If we increment it just for a recompile is because dpkg needs it to see that a package is newer. -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLE7uSqK7IlOjMLFAQEsrQP7Bp1Q+ih4hUNY687sAIxBYv5ye7DBx777 nnKkccy77eyj7Riwt82y7xThp2wP0UK1iHyilaUjgIH5woDNePpPaSjAULAxsINm eTAfASKNiTRlXIk5nE2YWDQC2xFX7+DA4pvkqFHlv8aiZG56BBzDb5BEAJxMVeo1 aiKesL9rQtE= =F9jz -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
-BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: On Mon, 5 Jan 1998, Santiago Vila wrote: On Mon, 5 Jan 1998, Dale Scheetz wrote: It was my understanding that the only time it is necessary to upload a new source package was when the upstream source changed. Here, source means Debian source, i.e. orig source + diff. In fact, you upload a new Debian source each time you upload a new diff. We are trying to clarify what happens when you just recompile a package. Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. Maybe, but the official maintainer should also be able to do a recompile of his own package :-) Why do you think we are still discussing non-maintainer uploads? -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: latin1 iQCVAgUBNLE89yqK7IlOjMLFAQFDUgP/aQX5mNcI06vbVewU9PSY07/yRuKN3sMT 0BFawG1KmHCLYR0pq8aFn8pXSo6+8H+8uNQDhs4hDQwFJJFhotwxRIroTPp04ROd 8oIHz2NzrebL0RdrA0XSZQcnHxB5BA7MtLTIlfpJ2/5XrmIj9/DTXMuVMohe55I1 OJD8ErmfGV4= =QRsk -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Re^2: dhelp 0.2 - a online help system
Christian == Christian Schwarz [EMAIL PROTECTED] writes: Christian If someone wants to do this with me, just drop me a Christian note. I'm just waiting for volunteers... I would like to help, but I don't think I've got the skills it would require right now. I'll try and take the time to look over what you people do with it, and learn from your example. Right now, I really need to just read books and code, more than anything. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
Dale Scheetz wrote: The patch I intend to use comes directly from David. Any changes to that patch need to be discussed before I will add them to the package. Can you post the patch to debian-devel? As far as I know it has not yet been made clear exactly which patch we're talking about. Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 05, 1998 at 08:08:51PM +0100, Christian Schwarz wrote:
On Mon, 5 Jan 1998, Marcus Brinkmann wrote:
Automake does support the GNU standard, a less restrict one, and (perhaps)
the gnits standard (the new GNU standard). Will there be automake support
for Debian packages ?
(BTW, the discussion about this was in mid Oct 97.)
(Ok, perhaps I will look in the archive. I certainly wasn't ready for this
technical topic at that time ;)
The idea is to create the debian/rules file by a macro processor. (Since
automake is used to create Makefiles and debian/rules is a Makefile,
someone suggested to use it. However, doubts have been presented that it
does not fit exactly to our purposes. Someone would have to do some
experiments on this. If it doesn't fit, we can use or write another macro
generator.)
Although I'm not able to judge auto{conf,make}'s capabilities, I had the
impression that they are strong tools. It would be nice to have some
general approach like this become standard for debian packages (I imagine
that auto compiling and porting would be easier then).
[...]
Furthermore, since debian/rules would be generated by the maintainer only,
everyone else can recompile the package and get the same results. (With
debstd this is one problem. You need exactly the same debstd version than
the maintainer had to get the same package.)
I see.
It would be nice if we could find one (or more) volunteers to do some
experiments on that issue.
Yes, I think it would be a Good Thing.
Thank you,
Marcus
--
Rhubarb is no Egyptian god. Debian GNU/Linux
Marcus Brinkmann http://www.debian.org
[EMAIL PROTECTED]
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Non-interactive installs [Re: need libc5 non-maintainer upgrade]
On Sat, Jan 3 1998 17:38 +0100 Richard Braakman writes: Christian Schwarz wrote: [Immediate-Configure: Yes field] [...] An Immediate-Configure field will help with 2, but I think there is a better solution. If there is a way to specify that a package's postinst is _not interactive_, then dpkg can attempt to configure those packages right away; there is no reason not to try. (If dependencies are not satisfied, it can try again after all packages have been unpacked.) [This discussion belongs probably to debian-policy] As Roberto already pointed out on debian-policy, a clever solution would be to make the postinst non-interactive _in general_. If then a program wouldn't have a postconfigure file it could be configured right away. David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
Hi all!
This is my first message on this mailing list, I am sorry if I am not
allowed to talk.
On Mon, 5 Jan 1998, Topi Miettinen wrote:
Hamish Moffatt writes:
Maybe because if the admin changes the /etc/crontab, it might be difficult
to merge in the modifications.
We have cron.{month,week,dai}ly, why not add directories hourly, bihourly
(every 30min), and quarterly (every 15min). That would give enough
resolution for most daemons.
I'd rather use cron for timing than daemon's built-in functionality:
- less swapped-out daemons
- more flexible configuration
-Topi
What about a kind of tag-oriented style of appending to /etc/crontab after
asking the admin:
ipac-install suggest to append an entry to /etc/crontab, which starts ipac
every 15 minutes:
[line to be inserted]
The lines will be enclosed by # -*- install: ipac -*-.
This way a remove script will be able to remove the lines which were
inserted by install.
cu
Torsten
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Non-interactive installs [Re: need libc5 non-maintainer upgrade]
I think there should be a set-params script in all packages that require interaction. This script should get params from the user, store them in COAS repository, and then the pre-inst and post-inst should use those parameters, getting them from COAS. The set-params script should not require that the package be installed to run. See http://www.caldera.com/coas . Thanks Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On Mon, 5 Jan 1998, Santiago Vila wrote: -BEGIN PGP SIGNED MESSAGE- On Mon, 5 Jan 1998, Dale Scheetz wrote: Then we are still discussing non-maintainer uploads/version numbering. In that case I find the paragraph to be ambiguous, confusing, and not to the point. Maybe, but the official maintainer should also be able to do a recompile of his own package :-) Why do you think we are still discussing non-maintainer uploads? I don't know ;-) that's why I got into the discussion. I had thought that we decided to add point numbers to the debian release increment, so a non-maintainer upload of ae_962-17 would be numbered ae-962-17.1 allowing the maintainer to do a -18 upload without confusion. This is, however, a different issue from, when do I change the version number, isn't it? Any binary package upload that differs by a single bit from the previous version should be provided with a new version number. At the very least, a change in the packages used to build said new package should result in new information in the change log, asside from the resultant changes to the binary. These are each sufficient to create a new version. What have I missed? Dwarf -- _-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_- aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308 _-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
Well, there is a problem with the Gregorian calendar that has to be dealt with in 2000 years or so (having to do with leap-millenia), but I figure if it's more than 100 years it's no problem. Bruce -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
Amos Shapira wrote: In message [EMAIL PROTECTED] you write: | a 64 bit variable, it's good for another 4000 years. | |Uhhh -- no. If it went from 32 bits to *33* bits, that would get us Actually, the current limit of 68 years (1970 + 68 = 2038) is posed by the used of SIGNED int (31 bits) instead of unsigned bits: ... Just moving to unsigned int will give you 68 more years, up to year 2106: but would make it impossible to represent dates from 1902 to 1969, which we can do now. So it's even simpler in regards of type size, but moving to an unsigned int may cause serious troubles in comparing dates (unless you use some functions which hide thedetails). You would break anything that used dates earlier than 1970. Why does glibc2 not use long long (64 bits) for dates, insead of long int (32 bits)? Surely we ought to change this now along with all the other libc6 changes? -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key ID 32B8FAA1 Unsolicited email advertisements are not welcome; any person sending such will be invoiced for telephone time used in downloading together with a £25 administration charge. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
On Mon, 5 Jan 1998, Richard Braakman wrote:
Dale Scheetz wrote:
The patch I intend to use comes directly from David. Any changes to that
patch need to be discussed before I will add them to the package.
Can you post the patch to debian-devel? As far as I know it has not
yet been made clear exactly which patch we're talking about.
I only did a cursory look at the patch you sent, but it looks similar to
the one I will be using.
Here is what David sent me...
diff -urN libc-5.4.38.orig/debian/changelog libc-5.4.38/debian/changelog
--- libc-5.4.38.orig/debian/changelog Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/changelogMon Dec 29 17:05:58 1997
@@ -1,3 +1,9 @@
+libc (5.4.38-0.2) unstable; urgency=low
+
+ * Build -dev and -dbg packages to make Scott Ellis happy.
+
+ -- David Engel [EMAIL PROTECTED] Mon, 29 Dec 1997 17:05:58 -0600
+
libc (5.4.38-0.1) unstable; urgency=high
* new upstream version (fixes #15340)
diff -urN libc-5.4.38.orig/debian/config.i386 libc-5.4.38/debian/config.i386
--- libc-5.4.38.orig/debian/config.i386 Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/config.i386 Mon Dec 29 17:14:31 1997
@@ -1,8 +1,8 @@
STATIC_SHARED=
MAKE=make
SPEED=fast
-HOST_ROOTDIR=/usr/i486-linuxlibc1
-HOST_BINDIR=/usr/i486-linuxlibc1/bin
+HOST_ROOTDIR=/usr
+HOST_BINDIR=/usr/bin
TARGET_ROOTDIR=/
TARGET_MACHINE=i486-linuxlibc1
TARGET_OS=linux
diff -urN libc-5.4.38.orig/debian/control libc-5.4.38/debian/control
--- libc-5.4.38.orig/debian/control Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/control Mon Dec 29 17:47:18 1997
@@ -12,8 +12,6 @@
These libraries are modified to make them work better in a libc6
environment.
PRE-DEPENDS: ldso (=1.7.14-2)
-DEPENDS: libc6 (=2.0.4-1)
-CONFLICTS: libc5-dev, wg15-locale, locales (2.0.4-1)
ARCHITECTURE: any
PACKAGE: libc5-altdev
@@ -24,7 +22,6 @@
libraries. This package can be used to build libc5-base binaries
even when the libc6-dev package is installed.
DEPENDS: libc5 (=${Source-Version})
-CONFLICTS: libc5-dev
ARCHITECTURE: any
PACKAGE: libc5-altdbg
@@ -35,5 +32,13 @@
This package can be used to debug libc5 even when the libc6-dev package
is installed.
DEPENDS: libc5-altdev (=${Source-Version})
-CONFLICTS: libc5-dev
+ARCHITECTURE: any
+
+PACKAGE: libc5-dev
+SECTION: oldlibs
+PRIORITY: standard
+DESCRIPTION: The Linux C library version 5 (dev files).
+ Includes libc headers, kernel headers (v2.0.29) and static
+ libraries.
+DEPENDS: libc5 (=${Source-Version})
ARCHITECTURE: any
diff -urN libc-5.4.38.orig/debian/control.hamm libc-5.4.38/debian/control.hamm
--- libc-5.4.38.orig/debian/control.hammMon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/control.hamm Mon Dec 29 20:22:07 1997
@@ -12,8 +12,6 @@
These libraries are modified to make them work better in a libc6
environment.
PRE-DEPENDS: ldso (=1.7.14-2)
-DEPENDS: libc6 (=2.0.4-1)
-CONFLICTS: libc5-dev, wg15-locale, locales (2.0.4-1)
ARCHITECTURE: any
PACKAGE: libc5-altdev
@@ -24,7 +22,6 @@
libraries. This package can be used to build libc5-base binaries
even when the libc6-dev package is installed.
DEPENDS: libc5 (=${Source-Version})
-CONFLICTS: libc5-dev
ARCHITECTURE: any
PACKAGE: libc5-altdbg
@@ -35,5 +32,13 @@
This package can be used to debug libc5 even when the libc6-dev package
is installed.
DEPENDS: libc5-altdev (=${Source-Version})
-CONFLICTS: libc5-dev
+ARCHITECTURE: any
+
+PACKAGE: libc5-dev
+SECTION: oldlibs
+PRIORITY: standard
+DESCRIPTION: The Linux C library version 5 (dev files).
+ Includes libc headers, kernel headers (v2.0.29) and static
+ libraries.
+DEPENDS: libc5 (=${Source-Version})
ARCHITECTURE: any
diff -urN libc-5.4.38.orig/debian/rules libc-5.4.38/debian/rules
--- libc-5.4.38.orig/debian/rules Mon Dec 29 20:23:05 1997
+++ libc-5.4.38/debian/rulesMon Dec 29 17:05:12 1997
@@ -103,8 +103,8 @@
mv dev-tmp/usr/lib/libg.a dev-tmp/usr/lib/libc_p.a dbg-tmp/usr/lib
install -d alt-tmp/usr/$(aa)-linuxlibc1
install -d altdbg-tmp/usr/$(aa)-linuxlibc1
- mv dev-tmp/usr/* alt-tmp/usr/$(aa)-linuxlibc1
- mv dbg-tmp/usr/* altdbg-tmp/usr/$(aa)-linuxlibc1
+ cp -a dev-tmp/usr/* alt-tmp/usr/$(aa)-linuxlibc1
+ cp -a dbg-tmp/usr/* altdbg-tmp/usr/$(aa)-linuxlibc1
#
install -d run-tmp/usr/doc/$(p)
ifeq ($(dist),bo)
@@ -188,7 +188,7 @@
dpkg-name -o -s .. locale-tmp.deb
touch binary-locale
-binary-hamm: build debian/utmp-conv binary-arch binary-alt
+binary-hamm: build debian/utmp-conv binary-arch binary-alt binary-dev
binary-bo: binary-arch binary-locale binary-pic binary-dev
Later,
Dwarf
--
_-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE
Re: Question/request concerning master
Dale Scheetz [EMAIL PROTECTED] wrote: |I suspect the error message of being a fall through. I just tried the |same route and was rejected. In the past this has been because someone has |disabled ftp on master, and it usually clears up soon. You should still be |able to telnet into master and then ftp from your site to master. I might be missing something here, but after being beaten by crackers who simply put a password sniffer on one of my Debian machines, I'd strongly recommand the Debian leaders to reconsider the policy of plain ftp and telnet. In the least you should consider using SSLtelnet and SSLftp, if you insist on an alternative for ssh. I'd also like to recommand that all passwords on master shall be replaced if and when you disable plain ftp and telnet. With plain passwords allowed to fly in the direction of master, ssh is useless, as one can simply find the password from other sources and use it to login. Thanks, --Amos --Amos Shapira| Of course Australia was marked for 133 Shlomo Ben-Yosef st. | glory, for its people had been chosen Jerusalem 93 805 | by the finest judges in England. ISRAEL[EMAIL PROTECTED] | -- Anonymous -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
boot-floppies progress
We made a lot of progress on the boot floppies over the weekend, but they still don't work. I expect to have them working in a few more days. Thanks Bruce -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
On Mon, 5 Jan 1998, Ian Jackson wrote:
I think that /usr/src should the be domain of the local admin.
I don't think kernel-{header,source}-x.xx.deb should exist, really,
because I don't think source code should be distributed as .deb files
anyway. So I'm not unhappy about making a policy decision that leaves
kernel-{header,source} with nowhere good to go.
I never understood why the kernel source was made into a .deb package. It
doesn't make sense to me. I also don't see any point in managing a
binary package of the kernel either. The system doesn't gain anything by
having dpkg know which kernel binaries are installed either. The binary
thus installed still needs to be configured for lilo or loadlin or grub,
so what's the point?
The short form...I agree with Ian here. We need to rethink how this should
work. For instance, I keep my kernel sources in /usr/local/src/linux and
never install the kernel packages unless required by circumstance.
Why does libc6 depend on kernel-header ?
I don't know either, but it is on the top of my list of things I need to
understand as the new maintainer. It was my understanding that the way we
deal with kernel headers was supposed to free the c library from the
headers. I don't know that anything has changed in that reguard. I'll let
you know what I find asap.
Waiting is,
Dwarf
--
_-_-_-_-_-_- Author of The Debian User's Guide_-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769
Flexible Software 11000 McCrackin Road
e-mail: [EMAIL PROTECTED] Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: New Maintainer for libc5/libc6
Okay. The version I sent you contains two fixes (aside from the extra changelog entries). Ray Dassen added an entry for libc5-dbg to the control file (both debian/control and debian/control.hamm). This is necessary because the debian/rules file tries to build libc5-dbg, and fails if it doesn't find a control entry for it. I added three lines to the control entry for libc5-dev: CONFLICTS: libc (4.6.27-11), libc-dev PROVIDES: libc-dev REPLACES: ppp (2.2.0f-22) I took them from the libc5-dev in bo. The conflict/provide of libc-dev is needed to make it conflict with libc6-dev (it installs mostly the same files, so it has to). I don't know why it conflicts with old libc versions. It replaces old ppp versions because it replaces some files. (I remember an old bug report about that). Richard Braakman -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, Jan 5 1998 20:08 +0100 Christian Schwarz writes: Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? [...] However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) I played over the christmas holidays with autoconf and automake (for use in my rpncalc package). My conclusions: - the generated Makefiles and configure.in's are too strict: e.g. a) they require that the COPYING (GPL) file is present, b) they test whether the cc is gcc (which we already know it is), c) they test whether the libc-headers are ANSI-compliant (which we already know they are) d) they test whether the signal returning type is void (which it is and should be) etc. ad nausaum. Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Screen-refresh in vi
I have a problem with the vi editor and screen-refresh (and possibly ncurses). Before filing an bug report, I'd like to ask whether somebody noticed this already or whether it is my local configuration problem. Moreover, I'm not able to isolate the offending package. Here it is: You're editing something and want to insert the current date. No, problem, you type: ':r!date' And the problem appears. The screen doesn't get refreshed, until you add something before the line where the output was written to. Neither ^R, nor ^L refresh the whole screen. I have this problem only on my hamm system, the bo system works like a charm. Any ideas/is this already known? ([EMAIL PROTECTED]) /var/tmp$dpkg -s nvi ncurses-base Package: nvi Status: install ok installed Priority: important Section: editors Installed-Size: 385 Maintainer: Steve Greenland [EMAIL PROTECTED] Version: 1.79-1 Depends: libc6, ncurses3.4 Conffiles: /etc/rc.boot/nvi 4785743d1b733c9f254d29a28cb299f2 Description: 4.4BSD re-implementation of vi. Vi is the original screen based text editor for Unix systems. It is considered the standard text editor, and is available on almost all Unix systems. . Nvi is intended as a bug-for-bug compatible clone of the original BSD vi editor. As such, it doesn't have a lot of snazzy features as do some of the other vi clones such as elvis and vim. However, if all you want is vi, this is the one to get. Package: ncurses-base Essential: yes Status: install ok installed Priority: required Section: base Installed-Size: 47 Maintainer: Galen Hazelwood [EMAIL PROTECTED] Source: ncurses Version: 1.9.9g-3 Replaces: ncurses-term Provides: ncurses-runtime Conflicts: ncurses, ncurses-runtime Description: Video terminal manipulation - Minimum terminal emulations This package contains what should be a reasonable subset of terminal definitions, including: ansi, dumb, linux, sun, vt100, vt102, vt220, vt52, xterm and xterm-color. David -- David Frey (51F35923114FC864 7D05FF173C61EFDE) Those who do not understand Unix are condemned to reinvent it, poorly. -- Henry Spencer -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Custom library for emacs 19.34 ?
The most recent python-mode for emacs needs a recent version of Per Abrahams' Custom library (http://www.dina.kvl.dk/~abraham/custom/). The version supplied with xemacs19/20 and Emacs 20 is fine, but the version supplied with emacs-19.34 won't work. I have tried to package custom (look at http://www.mathi.uni-heidelberg.de/~flight/debian-private/custom/) so that it can be dropped in for emacs-19.34 and that works for python-mode.el 3.28. Still I've heard rumours that custom-1.9961 breaks GNUS. Perhaps interested parties could try this package. If it does no big damage, I'd like to suggest to include this in hamm somehow (either as separate package, or as addition to emacs). Gregor --- |Gregor Hoffleit Mathematisches Institut, Uni HD| | [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 | | We will make windows invisible | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian? (was: Re: cron jobs more often than daily)
On Mon, 5 Jan 1998, David Frey wrote: On Mon, Jan 5 1998 20:08 +0100 Christian Schwarz writes: Automake does support the GNU standard, a less restrict one, and (perhaps) the gnits standard (the new GNU standard). Will there be automake support for Debian packages ? [...] However, doubts have been presented that it does not fit exactly to our purposes. Someone would have to do some experiments on this. If it doesn't fit, we can use or write another macro generator.) I played over the christmas holidays with autoconf and automake (for use in my rpncalc package). My conclusions: - the generated Makefiles and configure.in's are too strict: e.g. a) they require that the COPYING (GPL) file is present, b) they test whether the cc is gcc (which we already know it is), c) they test whether the libc-headers are ANSI-compliant (which we already know they are) d) they test whether the signal returning type is void (which it is and should be) etc. ad nausaum. Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... Automake is much less strict if invoked with the --foreign option. As for all the various autoconf tests, so what if it tests for stuff we know is true? It is what makes everything more portable to whatever you want it to compile on. -- Scott K. Ellis [EMAIL PROTECTED] http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
[EMAIL PROTECTED] (Amos Shapira) wrote on 05.01.98 in [EMAIL PROTECTED]: In message [EMAIL PROTECTED] you write: | a 64 bit variable, it's good for another 4000 years. | |Uhhh -- no. If it went from 32 bits to *33* bits, that would get us Actually, the current limit of 68 years (1970 + 68 = 2038) is posed by the used of SIGNED int (31 bits) instead of unsigned bits: True, but please don't change that. You'd break the doc-rfc package - there are RFCs from 1969 in it :-) |4000 years. This gets us more like 16 billion billion years (american |billions - 16 x 10^18 is what I mean, but it's off the top of my head...) Where did you get this 4000 years figure anyway? 33 bits would just double the duration from 136 years to 272 (bringing us to year 2242). True. And 64 bits gives us +/- 68*4*10^9 years, or over 250*10^9 years. 10^9 = 1 milliard (where applicable) or 1 billion (elsewhere). Nothing like billions of billions there. Hmm. I think that goes farther back than the beginning of the universe, so it's probably barely enough :-) MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
[EMAIL PROTECTED] (Christian Schwarz) wrote on 05.01.98 in [EMAIL PROTECTED]: On Tue, 6 Jan 1998, Hamish Moffatt wrote: On Mon, Jan 05, 1998 at 11:58:12PM +1100, Hamish Moffatt wrote: Urgh, I hate it already. Can somebody post a rationale for the section of policy quoted above? I notice that mgetty has added faxrunq to my /etc/crontab on my bo system. The idea behind the policy is explained in `3.3.7 Configuration files'. As /etc/crontab is a configuration file of the cron package, no other package may touch it. That's because in the past, we had packages that messed around with other packages configuration files. The solution presented in 3.3.7 is that the owner of the conffile (cron in that case) provides a utility (like install-info, for example) through which other packages can register and remove cron jobs. Umm. There's a good reason for not automatically modifying conffiles, ever: ... was modified by you or by a script ... The general rule, AFAIR, is for a file to _either_ be a conffile, or _completely_ handled by scripts, and never the twain shall meet. And yes, we still have a number of (sometimes important) packages getting this wrong. In this case, it's probably best if /etc/crontab goes the script only route, with a section clearly reserved for the sysadmin, and other sections handled automatically. The update-crontab script would have to handle ancient /etc/crontab files that were done by conffile+sysadmin+scripts before; probably impossible without manual intervention. Also, make sure that old *rm scripts won't junk the new, improved crontab! This is not going to be fun. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Snapshots of python 1.5 packages
I've put a snapshot of my python 1.5 non-maintainer packages at http://www.mathi.uni-heidelberg.de/~flight/debian-private/python/. There are still some unresolved problems regarding the removal of the old python-1.4 packages (their postrm scripts are due to fail), but the upgrade seems to work somehow now (at least when using dselect or one straight dpkg run), while it still leaves some old files in place. Gregor --- |Gregor Hoffleit Mathematisches Institut, Uni HD| | [EMAIL PROTECTED] INF 288, 69120 Heidelberg, Germany | | (NeXTmail, MIME) (49)6221 54-5771fax 54-8312 | | We will make windows invisible | -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What's Debian's /usr/src policy
Dale Scheetz wrote: I never understood why the kernel source was made into a .deb package. It doesn't make sense to me. I agree with this, I see nothing wrong with just having it available as a source package, perhaps with kernel-package merged into it as the debian/ directory. I also don't see any point in managing a binary package of the kernel either. The system doesn't gain anything by having dpkg know which kernel binaries are installed either. I was a skeptic about this too, 6 months ago. Now I've been using kernel-package for a while and I see many advantages. You can compile a kernel once and install the resulting .deb on multiple machines. You can keep old versions of the kernel in .deb's so you can downgrade if problems arise. You can use it to manage multiple installed kernels as well. You get a consitent kernel install, even if make-kpkg is run by a newbie, so it makes debugging other's problems easier as well. Using a debian package for the kernel also enables packages to depend on a certian version of the kernel, etc. We get all the benefits you'd see when making a .deb of any other program. The binary thus installed still needs to be configured for lilo or loadlin or grub, so what's the point? The kernel package postinst can handle lilo configuration already, it wouldn't be too hard to add grub support too. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
[EMAIL PROTECTED] (Dale Scheetz) wrote on 05.01.98 in [EMAIL PROTECTED]: If there is a reason to upload a new .deb package then that alone is sufficient to require an incremented version number. Every new release of a package should come with a new version. Only if an md5 sum of the new package is identical to that of the old would the version remain the same. In that instance there is no reason to upload the new file. Very much me too here. Version numbers are not for the convenience of maintainers. Version numbers are for the convenience of users. As such, they need to change whenever the .deb changes. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: autmake debian?
[EMAIL PROTECTED] (Christian Schwarz) wrote on 05.01.98 in [EMAIL PROTECTED]:
The idea is to create the debian/rules file by a macro processor. (Since
automake is used to create Makefiles and debian/rules is a Makefile,
someone suggested to use it. However, doubts have been presented that it
does not fit exactly to our purposes. Someone would have to do some
experiments on this. If it doesn't fit, we can use or write another macro
generator.)
I thought there was already consensus that automake was a very bad match
for this.
I'm currently experimenting with writing an autodeb tool; very early stage
yet, absolutely no promises at all of any kind. Any- and everyone is
encouraged to write a different one. (Didn't Ian himself want to do it?
He's surely better suited to that than I am :-))
My game plan:
analyse debmake and similar packages for what to do
do an autodeb-scan that creates debian/auto.proto
which is a proposed debian/auto
do an autodeb that creates debian/rules (and maybe other stuff) from
debian/auto, possibly via some .new prefix so people can verify it
does what they want first
do everything in perl, debian/auto uses Data::Dumper format to store
settings
After working some hours on it today, I've come as far as producing stuff
like this:
# generated by ./autodeb-scan
$auto1 = {
USERNAME = Kai Henningsen,
POLICY = 2.3.0.1,
CONFIGURE = ,
CLEAN = make clean,
DEBIAN = ,
VERSION = 0.0,
INSTALL = make install DESTDIR=`pwd`/debian/tmp,
EMAIL = [EMAIL PROTECTED],
DOCS = [],
PACKAGE = autodeb,
DATE = Mon, 5 Jan 1998 19:22:44 +0100,
PACKAGES = [
i:autodeb,
o:autodeb-doc
]
};
No rules generation yet.
This is obviously all highly subject to change. It's not as if I didn't
have lots of ideas how to change it :-)
This would have the advantage that every action would be included
explicitely in the debian/rules file instead of hidden into some
utilities.
Well, some could still be in well-defined utilities, if there's stuff
that's hard to do in a makefile. (I don't know yet if there will be
something like that.)
It would be nice if we could find one (or more) volunteers to do some
experiments on that issue.
Here where the hand is waving :-)
MfG Kai
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: cron jobs more often than daily
[EMAIL PROTECTED] (Christian Schwarz) wrote on 05.01.98 in [EMAIL PROTECTED]: On 5 Jan 1998, Karl M. Hegbloom wrote: Perhaps the /etc/crontab shouldn't be a conffile; but created by the installation scripts? Since /etc/crontab is actually a conffile (no matter if you tag it as such or not) this would be a dirty hack around our policy. Nope, that would be the correct solution. Conffiles modified by scripts are the dirty hacks, because dpkg's conffile mechanism isn't set up to cope with them. The packages those files and scripts belong to don't have anything to do with it. If the policy manual says otherwise, that's a bug. Fact is, that the cron package, the local sysadmin, and possibly other packages modify the /etc/crontab file. However, dpkg only controls modification between the sysadmin and _one_ package (cron here). I Wrong. Dpkg only controls modification between sysadmin and package maintainer; _no_ additional script changes work right. really think the cron package should provide a script where other packages can register cron jobs. _And_ not keep the file as a conffile, _and_ not keep it in the .deb. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Debian and the millenium bug
Quoting Oliver Elphick (olly@lfix.co.uk): Why does glibc2 not use long long (64 bits) for dates, insead of long int (32 bits)? Surely we ought to change this now along with all the other libc6 changes? IIRC, POSIX stipulates that time_t has to be a standard arithmetic type whereas long long is a non-standard extension. (Although I also seem to recall some talk of ANSI standardizing long long, so that might not be true anymore.) -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, [EMAIL PROTECTED]finger, or email with Subject: get pgp key -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
On 5 Jan, Christian Schwarz wrote: How about this: ``Whenever the source package is changed WRT to the last uploaded version, its version number has to be incremented. In addition, if the source package is not changed but the binary package changed (because it has been recompiled in another environment), the version number has to be incremented too (this is, the source package has to be changed and uploaded again) to make sure dpkg/dselect recognizes the changed package.'' Any comments are welcome. What about: The version number of a previously uploaded package must be incremented on every change in one of the md5sums listed in the .changes file, even in absence of other modifications to the package's contents. or: After a package has been uploaded (even if not installed), you must always increment the debian version number before uploading it again if any of the md5sums in the .changes file has changed. Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E pgp1HNuAtTOhF.pgp Description: PGP signature
Re: autmake debian? (was: Re: cron jobs more often than daily)
David Frey [EMAIL PROTECTED] writes: Shortly put, most of the test are appropriate for SunOS 4 but not for Debian (GNU libc2, gcc, POSIX.1 and nearly X/OPEN compliant) and are a waste of time. Of course, some m4 guru could put together an Debianized set of autoconf macros... If I get some free time tonight or tomorrow night, I will (got to be some benefits to hotel rooms :/). -- Stephen --- Normality is a statistical illusion. -- me -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Work-Needing and Prospective Packages for Debian GNU/Linux
Work-Needing and Prospective Packages for Debian GNU/Linux [EMAIL PROTECTED] $Id: packages.sgml,v 1.65 1998/01/05 23:38:10 johnie Exp $ 1. General Questions 1.1. Before reading this document You should have read the Debian GNU/Linux FAQ http://www.debian.org/doc/FAQ/. 1.2. Purpose of this document This document is intended to identify areas that need your contributions. It provides information that hopefully changes quite often, so it supplements the Debian GNU/Linux FAQ. 1.3. Getting newer versions of this document Newer versions of this document will be available via FTP and HTTP: o http://www.debian.org/doc/prospective-packages.html o ftp://ftp.debian.org/debian/doc/package-developer/prospective- packages.txt o ftp://ftp.debian.org/debian/doc/package-developer/prospective- packages.html 1.4. Feedback Please send additions, corrections, suggestions and wishes to the WNPP maintainer [EMAIL PROTECTED] Please mention to which version of this document your comments refer. Try to change the subject of your mail to reflect the packages you're talking about, it makes it easier for to sort out all Re: Work- Needing and Prospective Packages emails. A suggested subject line reads WNPP: removing foopackage or WNPP: working on barpackage. Thanks. 2. Recent Changes 2.1. Since version 1.64 1997/12/29 o Craig Sanders mailto:[EMAIL PROTECTED] has adopted procps. o Richard Braakman mailto:[EMAIL PROTECTED] has adopted ftplib. o Kai Henningsen mailto:[EMAIL PROTECTED] has adopted adbbs. o Gergely Madarasz mailto:[EMAIL PROTECTED] has adopted htdig. o Douglas Bates mailto:[EMAIL PROTECTED] has adopted xspread. o Adrian Bridgett mailto:[EMAIL PROTECTED] has adopted tkdiff and uploaded pppload. o Stuart Lamble mailto:[EMAIL PROTECTED] is working on modula-3. o Karl M. Hegbloom mailto:[EMAIL PROTECTED] has adopted suidmanager. o The pgcc compiler is obsolete and no longer listed as orphaned. 3. Orphaned packages (An orphaned package is a package that has no current maintainer.) Please inform [EMAIL PROTECTED] via e-mail: o when you find that you need to orphan a package o when you believe that the following list is incomplete o when you would like to maintain one of these packages. Emilio Lopes [EMAIL PROTECTED] : o ratfor77 (old source format) o ftnchek Tom Lees [EMAIL PROTECTED] : o majordomo Andreas Jellinghaus [EMAIL PROTECTED] : o kde o giflib Dominik Kubla o vgrind Rob Browning [EMAIL PROTECTED] : o blt Helmut Geyer [EMAIL PROTECTED] : o auctex o ghostview o lacheck (libc5) o libc5 o libc5-altdbg o libc5-altdev o libc6.1 o libc6.1-dbg o libc6.1-dev o libc6.1-pic o libproc-dev o xproc o xxgdb Orn E. Hansen : o xega o xmailtool Yves Arrouye [EMAIL PROTECTED] : o compress-package o ppd-adobe-common, ppd-adobe-extra, ppd-adobe-misc, ppd-gs o psptools Dominik Kubla [EMAIL PROTECTED] : o arpd o csh Brian C. White [EMAIL PROTECTED] : o zyxel Raul D. Miller [EMAIL PROTECTED] : o j1 (in old source format) o sam Michael Nonweiler [EMAIL PROTECTED] : Jim Robinson [EMAIL PROTECTED] : o mh-papers o term Doug Geiger [EMAIL PROTECTED] : o apsfilter Erick Branderhorst [EMAIL PROTECTED] : o mathpad o mfbasfnt o wenglish Christian Linhart [EMAIL PROTECTED] : o xarchie o bibindex Stuart Lamble [EMAIL PROTECTED] : o fsp Guy R. Thomas [EMAIL PROTECTED] : o dld (do we still need this ?) Patrick J Edwards [EMAIL PROTECTED] : o mailpgp Robert Leslie [EMAIL PROTECTED] : o motifnls Tom Lees [EMAIL PROTECTED] : o file-rc David Engel [EMAIL PROTECTED] : o tcl74 o tcl75 o tk40 o tk41 Philippe Troin [EMAIL PROTECTED] : o tclx74 o tclx75 o tix40 Michael Fletcher [EMAIL PROTECTED] : o javalex o java-cup o rsynth Karl Sackett [EMAIL PROTECTED] : o courtney o freelip o groupkit o imgstar o lee o objpak o pgapack o premail o saoimage o snns o tcs o wily o xbattle o xephem-smotif Christian Schwarz [EMAIL PROTECTED] : o hyperlatex o latex2rtf Herbert Xu [EMAIL PROTECTED] : o gettyps Others: o rc o xcompat (should we drop it ?) o libc4 (a.out compatibility) 4. Packages needing a new maintainer Please inform [EMAIL PROTECTED] via e-mail: o when you find that you'd like to discontinue maintaining a package Please inform [EMAIL PROTECTED] and the mainatiner of the package: o when you would like to maintain one of the packages. Sven Rudolph [EMAIL PROTECTED] : o seyon o lpr Martin Schulze [EMAIL PROTECTED] : Christoph Lameter [EMAIL PROTECTED] : o adpkg o autofs o berolist o bonnie o bridge/bridgex (Bridging Tools for Kernel 2.0.X/2.1.X) o chris-cust o debsums o defrag o dhcpd o
Re: Debian and the millenium bug
Bruce, You are causing me all sorts of trouble. The post used the word 'effected' when 'affected' is what you wanted. Some of the letters I'm getting are quite detailed in their explanation of why effected is incorrect. Want me to send them to you? ;) The best part is that none of these anal retentive people noticed that you misspelled millennium. - Jay -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: What warrants a non-maintainer release number?
Why do you think we are still discussing non-maintainer uploads? I don't know ;-) that's why I got into the discussion. The discussion started when someone (I forgot who :) did a non-maintainer upload for another architecture _twice_, the second time with different depedencies (resulted from simply recompiling) but with the same version number. However, the `non-maintainer' part of this discussion is totally unimportant. What matters is the question `in which cases has the version number to be incremented and in which cases can it be left'? I think we all agree now that the version number has to be incremented whenever the binary package is changed on master (even in Incoming/). (The only situation where one can upload a binary package twice without changing the version number would be when the first upload wasn't successful--i.e., the fules got truncated.) Thanks, Chris -- Christian Schwarz [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED], [EMAIL PROTECTED] PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA CS Software goes online! Visit our new home page at http://www.schwarz-online.com -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
