Re: Using CVS for package development
> Communication should be done via a package-specific mailing list. The > maintainer of the package decides who has commit privileges for this > package and who gets on this package's developers' mailing-list. > > This mailing list could be used as target for the bug reports against > this package. > > Regarding stability: We will need at least two branches: for stable > and for unstable. When some people cooperate on porting to a specific > architecture and this port does not work yet, they could create an > extra branch. (Usually this won't be necessary.) This discussion is making me feel guilty. I hinted a while back that I would Debianize aegis, and have not got round to it. To quote an earlier mail from me: There is a CASE tool called Aegis that would seem to fit into this scheme quite well. ftp://ftp.agso.gov.au/pub/Aegis/aegis.2.3.README As I understand it, this would sit happily on top of CVS (or perhaps do what CVS does), and also take care of asking for the test team(s) approval of each change, and automatically building the system and running automated regression tests against the built system. The aim of Aegis is to maintain a baseline source tree that always passes it's own tests, and so can be expected to work. It does this by seeking approval of each change from a tester, and attempting to satisfy itself of the validity of the change by building the system with the change applied and ensuring that it passes any tests that exist. If we could actually put up with the (not very large) overhead involved, I think it would end up giving us a massive improvement in reliability. If some of the CVS gurus could have a look at the Aegis docs and see how they think it measures up --- I'll debianize it if it looks worthwhile. -- One reason I didn't rush to do anything about this was that I couldn't see a worthwhile way of doing it without setting up a CVS server, and I don't have the bandwidth. Now that it looks like you are trying for at least a partial CVS and ``make world'' system, Aegis might be more viable. If we could implement an Aegis based system, even if only for the base packages, then a fair amount of automated testing would become a possibility. An alternative use might be to unpack _all_ the source for packages that go into a release, and put it into CVS or aegis, and allow bug fixes to stable only via that source. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Vincent Renardias wrote: > > On Thu, 29 May 1997, Christian Schwarz wrote: > > > Is it correct, that we are currently working on ports to the following > > platforms (the abbrevs should be the ones that dpkg is using in the file > > names): > > i386 > > alpha > > arm > > m68k > > powerpc > > sparc > > Are these correct (i.e. not ppc) and is this list complete? > > Correct for powerpc. > Didn't know someone was working on ARM(who?) We are going to have debian/ARM? :> I know there is a Linux port of some form for some of the ARM chips, Esp the StrongARM... Anyone know how well they run linux? Jason Mmm, 50$ 200Mips RISC processor.. I want 6! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
packages.debian.org & qmail (was Re: Using CVS for package development)
[EMAIL PROTECTED] said: > I had problems making it work because darned qmail won't parse a full > RFC822 address on the command line What were you trying to achieve ? --- it might be simpler than you think. I just discovered that most of my alias handling under qmail was drivel, and could be dome much more simply. > If someone wants to spend some time on a simple mailer hack, you can > make this work. If you want mail to, for instance: [EMAIL PROTECTED] to get sent to: [EMAIL PROTECTED] Assuming that packages.debian.org is just an alternative name for master, then you just need to generate a couple of lines in /var/qmail/users/assign for each package, like this: =rsync:philh:952:800:/home/Debian/philh::: +rsync-:philh:952:800:/home/Debian/philh:-:: Having to put the UID GID numbers in the file is a pain, but that can be avoided, with one extra ~alias file. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On May 29, Bruce Perens wrote > There actually is a packages.debian.org domain aliased on "master", I > had problems making it work because darned qmail won't parse a full > RFC822 address on the command line (it wants you to remove the > comments). If someone wants to spend some time on a simple mailer hack, > you can make this work. Sure. Just tell me what you want qmail to do for you and point me at the sh/whatever scripts you started working on. Christian pgpABQJv8JU5X.pgp Description: PGP signature
Re: Using CVS for package development
Hi, I have had a very quick look at the aegis README. It has a baseline (main trunk in CVS; no mention of multiple independent branches and back merging that I could see). It implements a per change test rquirement (thought: what tests? that the package build? could be done with a commitinfo script in CVS). For the most part it fits in the same niche as CVS. I just wonder how easy is it to come up with regression tests for changes that are made, and whether they will be valid at the next change. Seems more, umm, restrictive than CVS, but I should really download the source to see. I can see why management will prefer this system over CVS (any manager would love to put the accumulated regression tests on a report). I'm leaving for the weekend, but I'll take a closer look when I get back next week. manoj -- What do you call it when someone rubs a Volkswagen van on your head? A Fahrvergnoogie. Manoj Srivastava mailto:[EMAIL PROTECTED]> Mobile, Alabama USAhttp://www.datasync.com/%7Esrivasta/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
I must admit to not understanding what that qmail alias file is for. I do _all_ of my aliases with .qmail-* files . What I was trying to achieve was to have qmail forward a message without messing around with the headers any more than necessary. Thus, I wanted to have a .qmail-packages-default file to handle the packages.debian.org domain, and that would look up the package name and map it to the maintainer address, and remail messages to the maintainer. This is not a terribly complicated hack, but I got busy. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
From: "Christian Hudon" <[EMAIL PROTECTED]> > Just tell me what you want qmail to do for you and point me at the > sh/whatever scripts you started working on. I think we already have Joey (Martin Schulze) working on this today. Please check with him. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
Aegis looks interesting. I'd like to see how it works on top of a physically-distributed development using CVS. Do please package it when you have time, Phil. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
qmail for debian - when will it be released?
Hi, You keep talking about using Qmail - when will it be released for Debian? Is the experimentation over? How stable is it? The file in project/experimental is dated Apr 24th so it's been over a month of testting. 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] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
> What I was trying to achieve was to have qmail forward a message without > messing around with the headers any more than necessary. Thus, I wanted > to have a .qmail-packages-default file to handle the packages.debian.org > domain, and that would look up the package name and map it to the maintainer > address, and remail messages to the maintainer. This is not a terribly > complicated hack, but I got busy. That seems simple enough. I think your best bet is this: 1) make sure control/locals does not contain packages.debian.org add this line to control/virtualdomains: packages.debian.org:alias-packages create ~alias/.qmail-packages-default, containing: |forward "`/usr/local/bin/pkg2maint $EXT2`" write /usr/local/bin/pkg2maint, which is a program that takes a package name, and puts the maintainers e-mail address on its STDOUT. The only extra thing to have pkg2maint do is output an address that will cause the mail to bounce if the maintainer cannot be found ([EMAIL PROTECTED] might work) Anyone already have the pkg2maint code already written ? Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: long list of give away or orphaned packages
In article <[EMAIL PROTECTED]>, Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > Hi! I subscribed a few days ago, (and have been somewhat overwhelmed > by the quantity of mail on this list; is there a digestified version?) > and would like to propose that I package up Inform, Frotz, and some of > the associated games. I've already made an inform package. It will get uploaded as soon as I get an account on master. There is one interpreter already packaged, I can't remember which but it's not a terribly good one. My favourite is jzip which I might package up some time.
Re: Upcoming Debian Releases
[EMAIL PROTECTED] (Tom Lees) wrote on 27.05.97 in <[EMAIL PROTECTED]>: > There are ways to avoid this. For example, modify dpkg not to include any > line with "config=yes" in it in the md5sum of certain files. This is a troll, right? Or maybe you have forgotten how conffiles are actually handled: (old=original install, new=this install, current=possibly edited version) If old md5 = new md5, ignore new file (package unchanged) If old md5 = current md5, install new file (conffile was not edited) otherwise, prompt (both changed) Your change would mean that in case 2, dpkg would have to figure out how to put the variables from the old script into the new one. MfG Kai -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Possible bug in dpkg-source? Possible fix?
I'm using dpkg-dev 1.4.0.17. The problem is that not just with
source packages I create. It is with all source packages I'm
downloading, e.g., hello.
The type of error I'm getting is as follows:
dpkg-source: failure: remove patch backup file
hello-1.3/debian/substvars.dpkg-orig: No such file or directory
I've checked, and true to the error patch does not create a file
called "substvars.dpkg-orig"; however, it is creating a file called
"substvars.orig".
What's curious is that I don't have any problems extracting the
source when I use the method outlined in the Debian Packaging Manual
for extracting by hand. The patch command I use when doing a manual
extraction is just "patch -p0 -s", and all works like it should.
I'm no expert on the various uses of patch, and I don't know perl,
but I did have a look at dpkg-source. I found the following line:
exec('patch','-s','-t','-F','0','-N','-p1','-u',
'-V','never','-b','.dpkg-orig');
I figured this must be equivalent to typing at the command prompt the
following line:
patch -s -t -F 0 -N -p1 u -V never -b ".dpkg-orig"
Sure enough, when I do this, I do not end up with files that only
have .orig as a suffix instead of the intended .dpkg-orig.
Now, I have looked through the man page for patch and it seems that
the option "-b" should be replaced with "-z". When I make the
substitution, all works well.
Am I behind the times, or is this a bug?
Thanks
Paul Serice
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: packages.debian.org & qmail (was Re: Using CVS for package development)
Philip Hands <[EMAIL PROTECTED]> writes: [snip] > That seems simple enough. > > I think your best bet is this: > > 1) make sure control/locals does not contain packages.debian.org But make sure it's in control/rcpthosts, of course. > add this line to control/virtualdomains: > packages.debian.org:alias-packages > > create ~alias/.qmail-packages-default, containing: > |forward "`/usr/local/bin/pkg2maint $EXT2`" I would prefer |forward "`/usr/local/bin/pkg2maint "$EXT2"`" for security. > write /usr/local/bin/pkg2maint, which is a program that takes a > package name, and puts the maintainers e-mail address on its STDOUT. > > The only extra thing to have pkg2maint do is output an address that > will cause the mail to bounce if the maintainer cannot be found > ([EMAIL PROTECTED] might work) A better way to bounce when a maintainer is not found would be to do something like |/usr/local/bin/pkgforward "$EXT2" where pkgforward execs qmail's forward if a maintainer is found, or prints "unknown package" or "maintainer not found" as appropriate and returns 100. If you've got 1000 or so spare inodes, you could just make a ~alias/.qmail-package-packagename for each package, containing "&[EMAIL PROTECTED]" or whatever. If packages.debian.org is really master.debian.org, you could use users/assign to map "packages-packagename" to "maintername". If you don't want to worry about unescaping the various formats of email addresses, add the appropriate Resent-... and Delivered-To: (from DTLINE) headers, set some env. vars and pipe the resulting message into qmail-inject, telling it to get its recipients from the message headers. I could probably be persuaded to write this... :-) -- Carey Evans <*> [EMAIL PROTECTED] "Lies, damn lies, and computer documentation." -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Problems with inittab
Short question inbetween: Why is the Debian /etc/inittab different from one use on Watchtower? Mrvn -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Apache server-side includes questions
In article <[EMAIL PROTECTED]> you write: > >What's the Right Way(tm) to include the output of a perl script into a web >page? Why not just use Works for me... -- Steve McIntyre, CURS Secretary, Cambridge, UK. [EMAIL PROTECTED] Use Debian GNU/Linux - upgrade your Windoze box today! http://www.debian.org/ "Can't keep my eyes from the circling sky, +-- "Tongue-tied & twisted, Just an earth-bound misfit, I..." |Finger for PGP key Mail for me sent to cam.ac.uk addresses will start bouncing soon. Please use [EMAIL PROTECTED] or [EMAIL PROTECTED] instead. Thanks. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
> I have had a very quick look at the aegis README. It has a > baseline (main trunk in CVS; no mention of multiple independent > branches and back merging that I could see). It relies on RCS or CVS for its version control, so you get access to most if not all the features of those (or at least I think you do --- been a long time since I used it) It does allow multiple people to work on the same thing, but only one baseline exists. You can only get stuff into the baseline if it doesn't break anything, its like the unstable vs. stable split, but with automated checks. > It implements a per > change test rquirement (thought: what tests? that the package build? > could be done with a commitinfo script in CVS). This can be waived, but many tests would be fairly simple to write, and should really be done. The basic idea is that you write a script that fails with the old version, and succeeds with the new, so that the script tests for the bug-fix or feature that has just been introduced. Since the tests get run for every change, it should elliminate repeat occurences of the same bug. The other thing that it does, that people were talking about is administer the peer review thing, by mailing a tester, and requiring an approval before letting the change into the baseline. I can't see it working for ongoing unstable development because it would be too severe a bottleneck, but it might be useful for keeping stable stable, and the accumulated tests should be useful when we next do a freeze. > For the most part it fits in the same niche as CVS. I just > wonder how easy is it to come up with regression tests for changes > that are made, and whether they will be valid at the next change. > > Seems more, umm, restrictive than CVS, but I should really > download the source to see. I think so --- even if you don't use it, the ideas should be applicable. Cheers, Phil. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
gdbm and libc6
Hi developpers, I'm planning to package htdig, a www search engine (http://htdig.sdsu.edu/). I have two questions : - is someone already working on this package ? - what is the status of lib gdbm and libc6 ? . Htdig uses gdbm but libc6 provides db and sometime ago I'seen a post of Ulrich Drepper (glibc maintener), he said that he was unable to find a maintainer for ligdbm. So is gdbm offcialy dropped for hamm ? should I port htdig to use db instead ? Thanks for any info. Yann Doussot <[EMAIL PROTECTED]> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Where is the mysql package?
On Mon, 26 May 1997 [EMAIL PROTECTED] wrote: > > > Yep. How about a verbose mode that tells you when you connect, or if it > > > cant, says so, and then when its done, prints xxx bytes downloaded in yyy > > > seconds, at foo kb/s. > > > > > > something like: > > > $ snarf -v http://linuxos.org/index.html > > > connected to linuxos.org:80 > > > getting file... > > > got 63K in 45 seconds at 1.4K/s > > > $ > > So how about it, huh? =) Snarf is one cool proggie. wget can do this. It sounds like snarf is similar to this. Sample output:- debian:~$ wget -v http://localhost/debian.html --11:59:33-- http://localhost:80/debian.html => `debian.html' Connecting to localhost:80... connected! HTTP request sent, fetching headers... done. Length: 2,778 [text/html] 0K -> .. 11:59:34 (452.15 KB/s) - `debian.html' saved [2778/2778] -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: kernel header files : problems (yes, again)
On Wed, 28 May 1997, Andreas Jellinghaus wrote: > also get this directory. but only linux/ and asm/ shoud override > /usr/include, not net/ (because : net/ is buggy !). what shall i do ? > ok, i know how to fix this, but with the next libc or kernel header > update i will have to fix it again... any good solution ? Put something like this in debian/rules:- mkdir kinclude ln -s /usr/src/linux/include/linux kinclude/linux ln -s /usr/src/linux/include/asm kinclude/asm Then compile with -Ikinclude -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible bug in dpkg-source? Possible fix?
Paul Serice <[EMAIL PROTECTED]> writes: > Now, I have looked through the man page for patch and it seems that > the option "-b" should be replaced with "-z". When I make the > substitution, all works well. > > Am I behind the times, or is this a bug? This *is* a bug. The `patch' command recently changed its command-line specification in a non-backward-compatible manner. In my opinion this is just stupid lossage. It broke some of my custom patching tools as well. This ought to be fixed ASAP, IMHO. (Note that I believe you need -b as well as -z; -z by itself is not sufficient as far as I know.) -- Ben Pfaff <[EMAIL PROTECTED]> 12167 Airport Rd, DeWitt MI 48820, USA *Note*: New PGP key available at http://www.msu.edu/user/pfaffben/pgp.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: RFC: Policy for arch specs
On Thu, 29 May 1997, Christian Schwarz wrote: > Hi folks! > > As I'm working on a new Policy I'm handling the request to include a > policy for "correct architecture spec strings". However, I've discovered > _several_ threads here on debian-devel without any (obvious) results. > > Is it correct, that we are currently working on ports to the following > platforms (the abbrevs should be the ones that dpkg is using in the file > names): > i386 > alpha > arm > m68k > powerpc > sparc > Are these correct (i.e. not ppc) and is this list complete? > > Next step: GNU's "configure" utility. I thought that we had agreed on > using > i386-unknown-linux > (and similar for the other architectures), but then I had just discovered > that GCC uses > /usr/lib/gcc-lib/i486-linux/2.7.2.1/ > ^^ > > (first it says "i486" instead of "i386", second it ommits the "unknown"). No, i486-linux is the alias we should use. Latest configure tools will convert this to i486-pc-linux-gnu! But, all programs should install using the alias, not the full name. Dpkg calls it "i386", but the autoconf string should be i486. In general, the alias given to configure should be xxx-linux. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Taking over e2fsprogs ?
On Wed, 28 May 1997, Yann Dirson wrote: > > Has anybody postulated to take over maintainance of the package ? If > not, I'm a volunteer... Please let me know. If you do take it, please try to get the e2compr patches into it. I have requested that I take it to do this work on it. However, e2compr-ised patches are only available against 1.06 - they will need some converting. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On Mon, 26 May 1997, David Frey wrote:
> Hello everybody,
>
> On Sat, May 24 1997 11:40 +0200 Andreas Jellinghaus writes:
> > there are three tools : cfgtool (lars wirzenius), nod (winfried
> > truemper), dcfgtool (mine). and someone is working on a _real_ tool (all
> > three have flaws, and if this way we will get a tool with all good
> > features).
>
> With somebody, you meant eventually me, since I asked at the Linux-Kongress
> in Wuerzbuerg whether I may upload a dcfgtool clone.
> But whether it's a ``real'' tool, is not so sure... . Don't hold your breath.
>
> > as you can see, it's a small text database. so it has nothing, absolutly
> > nothing to do with deity - that's a GUI.
> agreed.
We are planning on expanding the scope of deity to include a few more
features than "just a GUI" after the initial release though. Including
getting a decent library set together for other developers to use. Making
the config-tool part of this would seem pretty logical.
> > then we should :
> > a) choose _one_ cfgtool (the current one have big flaws. the new one
> > will not have them).
> > b) change policy to _not_ allow config information in /etc scripts
I really don't like this, and I think several others don't either.
> > c) change policy to _not_ allow additional debian uniq config files to
> > fix b). only the textdb should be used.
Definitely. But we have to remain backwards-compatible, so we must be able
to *read*, e.g. /etc/mailname, to be able to convert to the db.
> > d) think about getting rid of some config files only used by shell
> > scripts, and use the textdb instead.
> yes.
>
> Lars Wirzenius <[EMAIL PROTECTED]> said:
> > Assuming the syntax is simple, and there's no need for complexity, a
> > hand-written parser can be lightning fast, and all the time is spent
> > in starting the program, and reading the file.
> Mine is currently a lex parser and a yacc scanner.
Do you do any hashing? I usually use gperf to generate a hashing function
for the main keywords. This really does give some nice speed improvements.
However, if the format is even simpler than this (no keywords, just
"variable assignments", and comments), it would be faster to use a yacc
parser, and write your own (simpler) lexer. The regular-expression
capability of lex does hit the performance slightly unless you really need
it. GNU flex doesn't suffer from this problem nearly as much as the
original lex did, though - it was severely slow.
> Tom Lees <[EMAIL PROTECTED]> said:
> > I know all this. But when will it be finished? What about beta
> > versions? Is there a mailing list (other than debian-admintool)?
>
> Finished in about a week (beta version).
Great! Are you planning on uploading it to experimental or unstable? I
would suggest you upload it to experimental, as it has the possibility to
severely corrupt people's systems. OTOH, you could also put it in your
home on master, as a pre-beta to check if everyone likes it.
> Mailing list other than debian-admintool: no
Maybe we should start *using* debian-admintool then :)
> Tom Lees <[EMAIL PROTECTED]> said:
> > It would be really cool if we upgraded the packaging system to handle
> > configuration integrally (so we can do configuration _BEFORE_ an
> > installation, etc.).
> Yes. But the tricky part is how to rewrite all the /etc/hosts, /etc/networks,
> /etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
> I don't have an idea.
How about we do it like apache does its modules? (This might get tricky,
as I'm not sure all developers can program). So the config tool loads all
the modules (using libdl), and then it can use special functions in these
modules to handle these file-formats. OTOH, there aren't that many files
with non-generic syntax... maybe we could simply include separate parsers
for each of these.
> > Deity definitely _IS_ the right place for this -
> > a GUI to do the configuration with, at the same time as packaging
> > control!
> I'd prefer a back-end and deity would be the frontend.
The way I envisaged it was that Deity would get all the configuration
info, and then pass it on to the back-end after it had all the info.
I think the cfgtool should probably be available as a shared lib so that
deity can also read stuff etc., without too much of a slowdown from
execing another prog.
> Jason Gunthorpe <[EMAIL PROTECTED]> said:
> > To allow a GUI to present a usefull view of the config file
> > information about each field would have to be known. A short
> > description, it's content type, possible range information, etc.
>
> You can store a comment (a la dcfgtool), but the other things are not here.
> dtxtdb knows about booleans, ints, floats and strings. That's it.
I suggest another two types (although they are really special cases) - IP
address, and FQDN. The regular expressions to handle these really are too
long for something that will be in common use.
My one (in perl) can handle perl expressions to valid
Re: Problems with inittab
In article <[EMAIL PROTECTED]>, Goswin Brederlow <[EMAIL PROTECTED]> writes: > > Short question inbetween: > > Why is the Debian /etc/inittab different from one use on Watchtower? Why should it be the same? I don't know what the Watchtower one was like (I've never had the misfortune to run Watchtower), but there's no reason why it should be the same. It depends on what gettys etc you want to start (you can also get inittab to start your X server for you, although the debian inittab doesn't do this by default) and what kind of boot scripts should be run. Look in inittab(5) for more information.
Re: gdbm and libc6
In article <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> writes: > - what is the status of lib gdbm and libc6 ? . Htdig uses gdbm but > libc6 provides db and sometime ago I'seen a post of Ulrich Drepper (glibc > maintener), he said that he was unable to find a maintainer for ligdbm. So > is gdbm offcialy dropped for hamm ? should I port htdig to use db instead? It's not officially dropped, it's just not currently maintained; I don't think there's any plan to drop it totally. I believe db has a dbm compatibility mode, and porting htdig to use that should be fairly easy; getting it to use db's native mode is a little more effort but may be worthwhile.
Re: Unresolved Critical Bugs
On 27 May 1997, Sven Rudolph wrote: > Christian Schwarz <[EMAIL PROTECTED]> writes: > > > Anyways, e2fsprogs seams to have a lot of open bugs. Is this package > > actively maintained? > > Probably not. Last maintainer is Michael Nonweiler <[EMAIL PROTECTED]>, > but he is looking for a new maintainer for e2fsprogs. Seeing as I am maintaining e2compr, I'll take it, and merge the packages as appropriate. -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Clean Debian installed, but a few problems left.
I got Debian installed on a clean disk now using the base1.2tgz and the instfiles.tar, but I run across some problems: The /etc/inittab from instfiles.tar gave errors and failed to execute some program (like dselect). Also the inittab it restored after it was run was taken from watchtower by the script and didn't work because the format is different (why?). After correcting this I was able to boot from hd and runn dselect manually without problems. After hours of installing I was left with two problems, probably related to the failures of the inittab on the first boot: /dev/mouse not found. nslookup faild (-> couldn't configure smail, ...) I will try to fix the nslookup problem, but for the mouse I could need some hint. Last two little anoying bugs: 1. When suplying a base path for dselect (first question under acess/mounted) it complains about not being able to find stable/binary-i386. Is that a bug in the source or just a broken configfile? I was able to work around the problem by answering none at the first prompt and then supplying the correct path at the next. Doing that worked fine. 2. dselect doesn't give any message / warning when you try to install a package you don't have. As a result all packages that depend on a missing package will fail without the missing package failing. (Which left me confused for some time.) -[ Hello to all fans in domestic surveillance ] security NORAD plutonium DES radar Semtex Clinton Uzi NSA domestic disruption smuggle kibo nuclear fissionable Legion of Doom SDI cryptographic SEAL Team 6 -[ Hello to all fans in domestic surveillance ] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Problems with inittab
On Fri, 30 May 1997, Mark Baker wrote: > Date: Fri, 30 May 1997 13:58:00 +0100 > From: Mark Baker <[EMAIL PROTECTED]> > To: Goswin Brederlow <[EMAIL PROTECTED]>, > debian-devel@lists.debian.org > Subject: Re: Problems with inittab > > > In article <[EMAIL PROTECTED]>, > Goswin Brederlow <[EMAIL PROTECTED]> writes: > > > > Short question inbetween: > > > > Why is the Debian /etc/inittab different from one use on Watchtower? > > Why should it be the same? > I don't mean 100% equal, just the syntax should be the same, so a inittab working with watchtower should also work with debian. Unfortunally they differ in syntax, so even a basic thing as starting the getty for login fails, although the same kernel is used. > > I don't know what the Watchtower one was like (I've never had the misfortune > to run Watchtower), but there's no reason why it should be the same. It > depends on what gettys etc you want to start (you can also get inittab to > start your X server for you, although the debian inittab doesn't do this by > default) and what kind of boot scripts should be run. > > Look in inittab(5) for more information. > . > -[ Hello to all fans in domestic surveillance ] security NORAD plutonium DES radar Semtex Clinton Uzi NSA domestic disruption smuggle kibo nuclear fissionable Legion of Doom SDI cryptographic SEAL Team 6 -[ Hello to all fans in domestic surveillance ] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ncurses back on hold...
Well. Anyone want to venture any opinions? Mike. --- Begin Message --- Jesse Thilo writes: > On Thu, May 29, 1997 at 09:18:48PM -0400, T.E.Dickey wrote: > > > To the terminfo.src maintainer, > > c'est moi > > Since when? (Seriously) Mr. Dickey appears to have decided that hijacking one project and screwing over Zeyd and myself wasn't enough for him. Now he's asserting control of the terminfo database I maintain, as well. This is only the latest instance of a pattern of arrogance and treachery. While Thomas Dickey's technical work on ncurses has undoubted merit, his behavior towards the two copyright holders and senior maintainers (Zeyd and myself) has been not only grossly unethical but, under U.S. copyright law and the Berne Convention, actually unlawful. I've had enough of this. Repeated attempts by myself and others to get Thomas Dickey to account for his behavior have failed. He won't answer my mail. He has repeatedly ignored Zeyd benHalim's protests about the unauthorized 4.0 and 4.1 releases. He has altered credits on the ncurses distribution without authority to do so and without the consent of the persons affected. As one of the copyright owners of ncurses, I have the legal right to forbid Thomas Dickey from distributing or modifying the ncurses sources. I have refrained from exercising it because I felt I had more important things to do than get in a pissing match with a skunk. I'm afraid I have allowed disgust at this prospect, and the well-meaning but misguided advice of others, to paralyze me for six months. My tolerance, and my paralysis, is ended. Since neither attempts at negotiation nor the customary norms of cooperative behavior in the hacker community seem to mean anything to Mr. Dickey, it's time for force majeure. Exercising my legal rights, I have just deleted the unauthorized 4.1 release from prep.ai.mit.edu. I now forbid Thomas Dickey from redistributing, modifying, or otherwise using the ncurses sources without the explicit permission of Zeyd BenHalim and myself, the copyright holders. He is enjoined to desist immediately under penalty of law. I am copying this note to the administrators of clark.net and to the ncurses lists. All parties should consider themselves notified that Mr. Dickey and clark.net no longer have the copyright holders' permission to carry ncurses sources and are required to delete them from clark.net's FTP areas and all other file areas of clark.net, under penalty of law. (Permission for clark.net to carry these sources will be granted once I am satisfied that Mr. Dickey is no longer in a position to use clark.net to violate Mr. benHalim's and my rights.) I ask all members of the ncurses lists to shun Thomas Dickey, beginning immediately and continuing unless and until he makes a public agreement to respect the rights and project seniority of Zeyd BenHalim and myself. Under no circumstances will he be permitted to control future distributions. I'll see to that if I have to have him sued or thrown in jail to ensure it. The ncurses sources were written as free software and will so remain; my exercise of rights is a specific response to Thomas Dickey's repeated unethical behaviors and his usurpation of the software, and I have no intention to prevent others from using the sources in all customary ways. I will open a 4.2 archive hosted at snark by next Wednesday (it would be sooner but I'm traveling this weekend). In the interest of neutralizing any possible feeling that I merely wish to selfishly control the project, I will also accept (and am confident Zeyd benHalim as senior maintainer will support) self-nomination by any third parties of good reputation on the ncurses list to take on the roles of principal maintainers. After a suitable probationary period, the present copyright holders will assign rights to those maintainers. If no suitable persons come forward, I will maintain the source tree myself until such time as I can hand off the job to a competent and ethical maintainer. -- http://www.ccil.org/~esr";>Eric S. Raymond --- End Message ---
Re: time stops on latest kernels
On 27 May 1997, Rob Browning wrote: > Is anyone else running the latest unstable kernels on a uniprocessor? > I have noticed that with many of the recent kernels (including > 2.1.40), time appears to be stopped. With these kernels, on my > machine clock never returns anything but zero, and things like > procmeter never register anything for cpu usage. > > I know that 2.1.26 doesn't have this problem, but I'm not sure where > it was introduced. I have a suspicion that it's related to the new > multiprocessor code... I'm running:- Linux debian 2.1.36 #56 Sat Apr 26 15:44:22 BST 1997 i486 unknown And everything is working... -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
confusion regarding kernel-source and ibcs source
Recently, I grabbed the newest ibcs source (ibcs_970513-2) and compiled it sucessfully on my machine (running hamm and kernel 2.0.29). I then proceeded to try the same thing on two other debian machines (running 1.3) using the same source for ibcs. It choked because /usr/src/linux/include/linux/modversions.h was missing. I realized that I did not install the kernel source on these machines and did so and tried again. Still choked due to that missing file. So I decided to look at if modversion.h was included in the kernel source. It isn't. Doing a search using dpkg --search, I found out that file only exists in modutils: /usr/doc/modules/examples/Stacking/modversions.h So my question is, does kernel-package put that file into the source tree? Or, more generally, how did it get into my source tree? Also, should there be some documentation in the ibcs package warning of this? Cheers. -- Colin R. Telmer, Institute of Intergovernmental Relations School of Policy Studies, Queen's University Kingston, Ontario, Canada, K7L-3N6 (613)545-6000x4219 [EMAIL PROTECTED] PGP Fingerprint = 09 E9 DA 66 9C EE 33 DC B8 3B 97 0E 01 BC EC 0B PGP Public Key at http://terrapin.econ.queensu.ca> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Man-Db and Man both in Frozen???
On May 30, Fabrizio Polacco wrote: > Where is it? > I've just looked both in ftp.debian.org and in master, but man_ is only > in rexx . > > Or maybe it has been just removed? Hmm, either that or we are looking at a bug in dselect herebecause it certainly was in the package list when I upgraded a few days ago. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
RE: confusion regarding kernel-source and ibcs source
>From [EMAIL PROTECTED] Fri May 30 09:49:58 1997 >Date: Fri, 30 May 1997 09:42:11 -0400 (EDT) >From: Colin Telmer <[EMAIL PROTECTED]> >To: Debian Development >Subject: confusion regarding kernel-source and ibcs source > >Recently, I grabbed the newest ibcs source (ibcs_970513-2) and compiled it >sucessfully on my machine (running hamm and kernel 2.0.29). I then >proceeded to try the same thing on two other debian machines (running 1.3) >using the same source for ibcs. It choked because >/usr/src/linux/include/linux/modversions.h was missing. I realized that I >did not install the kernel source on these machines and did so and tried >again. Still choked due to that missing file. So I decided to look at if >modversion.h was included in the kernel source. It isn't. Doing a search > >[Michael Meskes] You're right. A while ago we decided to use a versioned >kernel and versioned modules (at least I think so, since I did not maintain a >module back then) because that makes it easier to use one module for >different kernel releases. But it seems the kernel package does not create a >versioned kernel. It seems we're not on the same page right now. Ot course we >should be :-( > >using dpkg --search, I found out that file only exists in > >modutils: /usr/doc/modules/examples/Stacking/modversions.h > >So my question is, does kernel-package put that file into the source tree? >Or, more generally, how did it get into my source tree? Also, should there >be some documentation in the ibcs package warning of this? Cheers. > >[Michael Meskes] Right now you can only create the files (you also need the >modules subdir) by recompiling the kernel with MODULE_VERSION defined. > -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Rick's Cheesy MIDI Plug-In Package
I've got packaged a program which provides a midi plugin for Netscape. The name of the program is Rick's Cheesy Midi Plug-In. Does anyone mind? Thanks Paul Serice -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dcfgtool and clones
On May 30, Tom Lees wrote
> We are planning on expanding the scope of deity to include a few more
> features than "just a GUI" after the initial release though. Including
> getting a decent library set together for other developers to use. Making
> the config-tool part of this would seem pretty logical.
and where is that configtool ? we don't have one, and nobody is working
on one (IIRC). all we have are those text databases (configtooll, nod,
dcfgtool, dtxtdb). it's like dpkg and dselect : one is the base tool,
and the other one the gui.
the dtxtdb will be universal enough, to fit any gui you will write. but
there is no reason now to care for a might be coming sometime gui.
and even if someone writes a gui to configure debian : there are much
worse problems than dtxtdb. look at the structure of config files like
uucp sys config file : if you can manage this, you can manage nearly
everything (including dtxtdb).
cfgtool is a bad name, and it was it all the time. but even if we keep
to the name cfgtool, what you are talking aboout is the admintool - a
gui and inteligent program to configure debian.
> > > b) change policy to _not_ allow config information in /etc scripts
>
> I really don't like this, and I think several others don't either.
code is code and data is data. many scripts have both in them, causing
many problems when updating. and a lot of debian developers start to
move data out of their scripts, but everyone uses his own way.
> > > c) change policy to _not_ allow additional debian uniq config files to
> > > fix b). only the textdb should be used.
>
> Definitely. But we have to remain backwards-compatible, so we must be able
> to *read*, e.g. /etc/mailname, to be able to convert to the db.
that's ok, because many programs use it. i was thinking about files like
/etc/gpm.conf, only used by /etc/init.d/gpm, and others. so, what about :
c) change policy to _not_ allow additional debian uniq config files, if
they are only used by scripts.
> > > d) think about getting rid of some config files only used by shell
> > > scripts, and use the textdb instead.
> > yes.
> Do you do any hashing? I usually use gperf to generate a hashing function
> for the main keywords. This really does give some nice speed improvements.
it don't why anyone considers speed. if we only store data we currently
store in scripts, we will have less then 30k data. divide that in
several files, and you will have files < 5k. and you will need to read
these files 100 times at bootup, and nearly never during runtime.
and all these values are worst case, based on current /etc i will get
only 8k total (that's 2k per file or so). if the whole program is
written in c, it's very fast. no need to make thoughts about speed. we
can do that, if the program is going to be slow, but everything points
to be a very fast program.
> > Finished in about a week (beta version).
>
> Great! Are you planning on uploading it to experimental or unstable? I
> would suggest you upload it to experimental, as it has the possibility to
> severely corrupt people's systems. OTOH, you could also put it in your
> home on master, as a pre-beta to check if everyone likes it.
it can not corrupt any system, because there are no packages that will
take use of it, as long as package maintainers don't modify their
scripts to use it.
> > Mailing list other than debian-admintool: no
>
> Maybe we should start *using* debian-admintool then :)
if we had something other to discuss than to worry about speed and gui
details ...
> > Tom Lees <[EMAIL PROTECTED]> said:
> > > It would be really cool if we upgraded the packaging system to handle
> > > configuration integrally (so we can do configuration _BEFORE_ an
> > > installation, etc.).
> > Yes. But the tricky part is how to rewrite all the /etc/hosts,
> > /etc/networks,
> > /etc/uucp/{sys,dial,port,config}, /etc/fstab, /etc/slip.dip etc. files.
> > I don't have an idea.
no, don't do that ! it's not your job. that's the job of an admintool,
not the job of the dtxtdb. also /etc/fstab and /etc/slip.dip are real
config files, we may not touch them.
all we should do for now, is provide an utility as replacement for one
config file, where currently is none, or where we have a propietary
config file for one script (that's pointless).
if someone want's to write an admintool - he would have well known uucp
cpnfig files to work with. he would have well known smail config files
to work with. the only things he has no config file, are these damned
scripts with only one variable, changing from version to version. he
shouldn't bother with them ans have a real config file. but we don't
want one big config file to configure everything (like german suse
distribution), and we will provide an interface to dtxtdb as
replacement.
everything dtxtdb should do is provide a replacement for a config file,
where there is no, but tens of scripts and propietary files with only
one or two values.
> How about we do it l
xdm-shadow (was Re: 1.3 installation report.)
Hi, Mark Eichin: > 2) the xdm shadow support doesn't fall back in any sane way, > and it's more than just dropping a check -- a bunch of code needs > rearrangement. (If you run xdm-shadow on a non-shadow system, you *lose*...) Well, I just did that with xbase-3.2-6: # mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm I can switch back and forth between shadow and non-shadow passwords, and can login via xdm just fine. Nothing bad happened, my machine hasn't exploded yet, etc. :-) There was indeed a problem with XFree86-3.1.2 (xdm-shadow didn't work with non-shadow passwords), but not with 3.2 and higher. With 3.2 and 3.2A, the only thing that remains to be fixed is the Imakefile that still generates two separate xdm binaries. I reported this to the XFree86 upstream maintainers, and got a reply from David Dawes: "We've dealt with this finally, and it will be fixed in 3.3." So, I would appreciate if it could be fixed in the next Debian 1.3 xbase release. Just move that single binary... > I've never understood why the debian shadow code was so primitive. Not just Debian, and not just Linux - getspnam() is also used on several other systems, Solaris being one of them. Like many other UN*X things, it is not perfect, maybe it is even primitive, but it works and is standard. Most reasonably current, portable sources, already know about getspnam(). > Any reason why the classic "getpw* give you a password field if you've > got root" implementation isn't used? I can think of a few reasons > (avoiding coredumps in programs not actually needing passwords) but Another reason is that in the past some setuid root programs (chfn, chsh) used to get the passwd entry using getpwnam(), modify it, and write it back to /etc/passwd. Congratulations, you just unshadowed your system... Sure, they can (and should) be fixed, but I prefer to play it safe. Besides, there is more information in /etc/shadow than just the encrypted passwords, and that information (password aging) would be lost. The people at AT&T who added getspnam() to SVR4 a few years back could probably give a better answer to this question than I did. Of course this is a matter of personal opinion, but I for one consider getspnam() to be the "classic" shadow password implementation. (Some systems actually do the getpw* thing, but I think it is a little unsafe.) > they're kind of weak [and could be handled better by simply providing > a shadow_need_passwords() call to enable the feature...] Non-standard - there are already so many different shadow password implementations... Regards, Marek -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Possible bug in dpkg-source? Possible fix?
> I'm using dpkg-dev 1.4.0.17. The problem is that not just with > source packages I create. It is with all source packages I'm > downloading, e.g., hello. > > The type of error I'm getting is as follows: > > dpkg-source: failure: remove patch backup file > hello-1.3/debian/substvars.dpkg-orig: No such file or directory [ Excellent and absolutely correct analysis snipped ] This has been fixed already in 1.4.0.18 (in Incoming) which has been there for a few days. I got burned by that one too. Cheers, -Jim pgpHX6kgJ8c2Y.pgp Description: PGP signature
Re: xdm-shadow (was Re: 1.3 installation report.)
> # mv /usr/X11R6/bin/xdm-shadow /usr/X11R6/bin/xdm
> I can switch back and forth between shadow and non-shadow passwords,
> and can login via xdm just fine. Nothing bad happened, my machine
> hasn't exploded yet, etc. :-)
Ah, I see, it just logs an error, but doesn't actually fail. (The
code only changed a *small* amount, but I guess it was sufficient.)
sp = getspnam(greet->name);
if (sp == NULL) {
Debug ("getspnam() failed, errno=%d. Are you root?\n", errno);
} else {
So I'll change that text a bit, and have the next release install both
xdm and xdm-shadow but make them the same executable (safest path, I
think, since I can't count on everything else being updated to know
about the change.)
HOWEVER, it doesn't make any sense to do a new release just for this,
since it's just an annoyance, not a bug (the shadow convert scripts
currently do the right thing if you run them with X already
installed.) There is a better reason though -- someone sent me
patches for what they claim are all of the Xt buffer overruns. If
there's a 1.3.1 planned, and someone lets me know the deadline and/or
schedule at least a week (preferably two) in advance, I'll get both of
these in.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Man-Db and Man both in Frozen???
John Goerzen <[EMAIL PROTECTED]> writes: >On May 30, Fabrizio Polacco wrote: > > > Where is it? > > I've just looked both in ftp.debian.org and in master, but man_ is only > > in rexx . > > > > Or maybe it has been just removed? > > Hmm, either that or we are looking at a bug in dselect herebecause it > certainly was in the package list when I upgraded a few days ago. This is probably bug #6210, which has since been reported several times. Just apply the tiny patch, or run dpkg --clear-avail before doing an Update. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Using CVS for package development
On Thu, 29 May 1997, Paul Bame wrote: > = > Should this CVS repository be mandatory, i.e. does every Debian > = > package have to be there? > > A brief word of warning... (I tried CVS on dpkg a while back) > > The natural CVS model is to name the directory for the package, > for example .../dpkg/ and relegate the version numbers to tags. > At least one package (dpkg) uses its directory name in such a way > that when the directory is .../dpkg/ the build fails, while it > works when the directory is a versioned one, .../dpkg-1.2.3/. This has been fixed now, since 1.4.0.9 (it was in my original automakizing patch, it now using the debian changelog to determine version). -- Tom Lees <[EMAIL PROTECTED]>http://www.lpsg.demon.co.uk/ PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E B8 A2 17 9D 4F 9B 89 D6 finger [EMAIL PROTECTED] for full public key (also available on keyservers) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ncurses back on hold...
Any new work I do will use slang rather than ncurses. Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ncurses back on hold...
[EMAIL PROTECTED] (Bruce Perens) writes: > Any new work I do will use slang rather than ncurses. Can't say as I'd blame you. RMS has stepped in. I can't quite decide if that's likely to foster resolution or small-arms usage. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ncurses back on hold...
Michael Alan Dorman wrote: > > RMS has stepped in. I can't quite decide if that's likely to foster > resolution or small-arms usage. > Stepped in on whose side? --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: gdbm and libc6
> It's not officially dropped, it's just not currently maintained; I don't > think there's any plan to drop it totally. Umm, it's not maintained *upstream*; I maintain the debian package. It is worth porting the code to use db, even using the dbm-style interfaces, but since there's no data-level compatibility I need to package up a libc6 gdbm anyhow... probably this weekend... but don't wait for it, start on converting [which should be trivial, since you're presumably using all the dbm_* interfaces anyway...] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
ncurses package orphaned...
Debian developers:
ESR has, IMHO, decided to start a pissing match about ncurses
development. I have no desire to participate or watch.
My frank recommendation is that we ditch ncurses entirely, go back to
BSD curses and termcap and encourage authors of free packages to use
slang.
I enclose my latest set of diffs against 4.1, in case someone here's
sucker enough to take up the torch. If so, have fun. I've got no
more time to waste on the smouldering brushfire that is ncurses
development, and I'm sick of trying to find some middle ground between
people's need/desire for an updated, bug-fixed library and the various
personality disputes that exist between the ncurses developers.
There's still a small glitch in there somewhere, but it produces the
packages, and shouldn't need more than a small bit of tuning.
--- ncurses-4.1.orig/man/man_db.renames
+++ ncurses-4.1/man/man_db.renames
@@ -43,6 +43,7 @@
curs_touch.3x touch.3ncurses
curs_util.3x util.3ncurses
curs_window.3x window.3ncurses
+dft_fgbg.3xuse_default_colors.3ncurses
form.3xform.3form
form_cursor.3x cursor.3form
form_data.3x data.3form
--- ncurses-4.1.orig/debian/README.debian
+++ ncurses-4.1/debian/README.debian
@@ -0,0 +1,11 @@
+NOTE: The ncurses package is split into six parts: ncurses-base (a minimal
+set of terminal entries), ncurses4 (the shared libraries), ncurses4-dev
+(header files, static libraries and man pages), ncurses-term (the remaining
+terminal entries), ncurses-bin (programs for manipulating terminfo entries)
+and ncurses4-pic (a library for building minimal shared libraries). All
+systems should have ncurses-base and ncurses4 installed. Users interested
+in manipulating entries should have ncurses-bin installed. Only development
+systems should have ncurses4-dev installed, and only systems needing
+relatively exotic terminals need ncurses-term installed. ncurses4-pic is
+really only used for creating installation disks.
+
--- ncurses-4.1.orig/debian/changelog
+++ ncurses-4.1/debian/changelog
@@ -0,0 +1,45 @@
+ncurses (4.1-1) unstable; urgency=low
+
+ * New upstream version. Removed deb-files.
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Wed, 7 May 1997 16:39:28 -0400
+
+ncurses (4.0-1) unstable; urgency=high
+
+ * Upgrade to 4.0, which syncronizes the ABI and version numbers (and
+goes to a major-only ABI number, which is more like other packages).
+ * Ditched use of dpkg-shlibdeps for the moment---I feel more confident
+of my ability to maintain the dependencies by hand.
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Fri, 27 Dec 1996 09:24:47 -0500
+
+ncurses (1.9.9g-3) unstable; urgency=low
+
+ * Upgrade to 1.9.9g final release
+ * Remove xterm-color from -base, since default xterm is now color
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Mon, 16 Dec 1996 14:06:49 -0500
+
+ncurses (1.9.9g-2) unstable; urgency=low
+
+ * Upgraded to latest (11/20) snapshot
+ * New soname, so new lib names
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Mon, 16 Dec 1996 13:28:51 -0500
+
+ncurses (1.9.9g-1) unstable; urgency=low
+
+ * Upgraded to latest upstream snapshot
+ * New soname, so new lib names.
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Sun, 22 Sep 1996 14:32:56 -0400
+
+ncurses (1.9.9e-3) unstable; urgency=low
+
+ * Moved to new source packaging format.
+
+ -- Michael Alan Dorman <[EMAIL PROTECTED]> Thu, 12 Sep 1996 15:19:35 -0400
+
+Local variables:
+mode: debian-changelog
+End:
--- ncurses-4.1.orig/debian/control
+++ ncurses-4.1/debian/control
@@ -0,0 +1,64 @@
+Source: ncurses
+Maintainer: Michael Alan Dorman <[EMAIL PROTECTED]>
+Standards-Version: 2.1.2.2
+
+Package: ncurses-base
+Architecture: all
+Conflicts: ncurses, ncurses-runtime
+Provides: ncurses-runtime
+Replaces: ncurses-term
+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.
+
+Package: ncurses-term
+Architecture: all
+Depends: ncurses-base
+Description: Video terminal manipulation - additional terminal files
+ This package contains all of the terminal definitions not found in
+ the ncurses-base package. There are far too many to list here.
+
+Package: ncurses4
+Architecture: any
+Depends: ${shlibs:Depends}
+Conflicts: ncurses
+Description: Video terminal manipulation - shared libraries
+ This package contains the shared libraries necessary to run programs
+ compiled with the ncurses libraries.
+
+Package: ncurses4-dev
+Architecture: any
+Depends: ncurses4, libc6-dev
+Conflicts: ncurses, ncurses-developer, ncurses21-dev, ncurses-dev
+Provides: ncurses-dev, ncurses-developer
+Replaces: ncurses-developer
+Description: Video terminal manipulation - Developer's libraries and docs.
+ This package contains the
Re: ncurses back on hold...
Galen Hazelwood <[EMAIL PROTECTED]> writes: > Michael Alan Dorman wrote: > > RMS has stepped in. I can't quite decide if that's likely to foster > > resolution or small-arms usage. > Stepped in on whose side? No ones in particular, though I suspect ESR could see it as being on Tom Dickey's side, since RMS stated that he wouldn't remove 4.1 from prep until he'd heard both sides of the story, and that from a legal standpoint, the proposition of ESR retroactively revoking the license on ncurses in order to forbid Tom from doing anything seemed pretty dubious. Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: runlevels [was Re: Upcoming Debian Releases]
Yann Dirson writes: > * that's not complete either. As already mentionned, the manpage tells > about undocumented runlevels 7-9. It also poorly tells about those > AaBbCc I never really understood. I just tried those runlevels 7-9, with sysvinit_2.71-2. It just need few modifications to have them work: * add rc[7-9].d, and 'cp -d rc2.d/* rcX.d' to get packages setup * add in inittab: runlevel (l7,l8,l9) entries, 7-9-awareness into getty and ctrl-alt-del entries (entries 1-6 and ca) There would surely be other things to update if they are to be used in debian (eg. update-rc.d). That just go fine, until you try to use 'halt' or 'reboot': as specified in the manpage (yes :), these only call shutdown when in runlevel 1-5. Quite strange IMHO. *BE CAREFUL* trying to reproduce it, it (probably among other unclean things) doesn't unmount cleanly filesystems. I don't know the reason why RLs 7-9 are handled just like 0 and 6. I think it should at least be possible to choose which behaviour they have in this case, if the current behaviour is meaningful (IMHO, it is only meaningful for halt/reboot-like actions). Should this be considered as a bug ? -- Yann Dirson e-mail: [EMAIL PROTECTED] http://monge.univ-mlv.fr/~dirson -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
The enlightenment window manager
Hi all: I just downloaded the enlightenment window manager (see http://www.cse.unsw.EDU.AU/~s2154962/enlightenment/). It is somewhat slow and requieres a lot of memory and disk, but is very funny to see, anyway. I didn't resist the temptation and packaged it for Debian (together with its companion image manipulation library, imlib). If nobody minds, I'll be uploading it to unstable sometime during the next week (there's a little copyright issue I still have to solve with the author). Regards, M. S. Martin A. Soto J. Profesor Departamento de Ingenieria de Sistemas y Computacion Universidad de los Andes [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: ncurses package orphaned...
Michael Alan Dorman wrote: > > Debian developers: > > ESR has, IMHO, decided to start a pissing match about ncurses > development. I have no desire to participate or watch. > > My frank recommendation is that we ditch ncurses entirely, go back to > BSD curses and termcap and encourage authors of free packages to use > slang. Tempting though this may be, I'm not sure it's an option. I believe that slang uses the terminfo database, so we need to keep terminfo regardless of what happens to curses. We may want to separate our terminfo database into an entirely new set of packages, unrelated to any library. As for BSD curses, I had terrible times with that when trying to port the Frotz interpreter. Ncurses was so much better that I simply pointed to it in the README file in the source, for those with BSD-derived curses libraries. I'm prejudiced against it; I'd rather not see it come back. > I enclose my latest set of diffs against 4.1, in case someone here's > sucker enough to take up the torch. If so, have fun. I've got no > more time to waste on the smouldering brushfire that is ncurses > development, and I'm sick of trying to find some middle ground between > people's need/desire for an updated, bug-fixed library and the various > personality disputes that exist between the ncurses developers. I don't blame you one bit. I'm really glad this crackup happened now, when hamm is still a long way from seeing release. Can you imagine the chaos that would have hit if this had happened 3 weeks before 2.0 was to come out, with all our packages dependent on 4.1? This is a really miserable situation. My personal hope is that some kind of resolution happens before too much longer; either one side wins, or they agree to separate. Curses is too important to a lot of software to let our best implementation of it die. In the meantime, I'll look into separating out the terminfo database...and keep an ear open. Thanks a lot for your efforts on our behalf, Michael. --Galen -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Problem with either xbase or ssh.
When the machine I have that's tracking unstable is rebooted, the xdm login screen will not appear until I use ssh to remotely connect to the machine. Until then the screen is blank. I don't know what's causing this, or I'd file a bug with the responsible package, but removing ssh makes the problem go away. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
