Release Plans (19990513)
(Please send followups to this mail to debian-devel, not debian-devel-announce) This is what I learned from the responses to the previous announcement. Boot disks: Creating disk sets with the much larger 2.2 kernels is proving difficult. This is likely to delay the freeze unless the boot-floppies team gets some help. CD Images: The tools that create the CD images could use some fixing. Join the debian-cd list if you wish to help. Architectures: PowerPC will also release with potato. That makes the full list: i386 m68k alpha sparc powerpc PAM: Ben Collins sponsored full pamification as a release goal. The main packages that need work are the shadow suite, and xdm. Perl 5.005: Two people volunteered as coordinator for this, and promptly got into an argument :-) I'll pick wait and see on this one. Richard Braakman
Re: doc-base and obnoxious unknown format warnings
Adam == Adam Di Carlo [EMAIL PROTECTED] writes: Adam Geeze -- ok, I'll fix it tonight. Thanks! I didn't mean to sound concilatory, but it seems a lot of packages have a lot of doc-base warnings these days.. -- Brought to you by the letters N and P and the number 19. You should be glad you don't have diaper rash. Mah Jongg. Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/ I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: doc-base and obnoxious unknown format warnings
Joey == Joey Hess [EMAIL PROTECTED] writes:
Joey warning: ignoring unknown format `$$format_data{'format'}'
Joey if $ENV{DOC_BASE_GRIPE}; }
This is a nice solution.
--
Brought to you by the letters G and B and the number 7.
When you had it, you didn't want it. Now you ain't got it, you want it back.
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
ITP: squirm
Squirm is a URL redirector for squid. It provides a fast means for squid to modify URLs according to a set rule that the administrator applies. It is useful for things like a) redirecting requests for common files to internal cached copies b) restricting access to URLS and redirecting them to some other place (a warning message for instance) c) (and this is what I mostly use it for) redirecting things like banners and ads to some other place. daniel
Re: ITP: squirm
On Thu, May 13, 1999 at 09:10:54AM +1000, Daniel James Patterson wrote: Squirm is a URL redirector for squid. It provides a fast means for squid to modify URLs according to a set rule that the administrator applies. Oh, I forgot to mention that it's under the GPL and you can look at it at: http://www.senet.com.au/squirm/ daniel
Re: Release Plans (1999-05-10)
Wichert Akkerman [EMAIL PROTECTED] writes: [1 text/plain; us-ascii (quoted-printable)] Previously Martin Bialasinski wrote: Do I have access to the net within that environment? I just have some pre-release slink CDs, so I have to upgrade to the current point release by ftp (by an ISDN line - it is accessed like a NIC). Sure. You are just using the same system, only the root of the filesystem is changed for processes running in the chroot-environment. Do I have access to $DISPLAY somehow and can I use startx, so I can test X packages directly? If you use localhost:0.0 you can use the same display (note that :0.0 doesn't work since the X-socket is in a location the chroot-environment cannot access). If you want to do startx you have to use a different display since X is already running. You also have to mount a seperate copy of proc in the chrooted environment. Be careful of pre/post install scripts they may stop daemons and restart them in the chrooted environment. (I usually run all the inetd stuff in one environment and ssh in the other, so normal users can easily access it.) Steve [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
Ian Lynagh wrote: In article [EMAIL PROTECTED], Richard Braakman [EMAIL PROTECTED] writes These are installed now. I assume the delay with libgtop1 was that it was a new package? If so, please remove libgtop0. Yes... I'll get around to that later :-) Richard Braakman
Re: Release Plans (1999-05-10)
[Please restrict your line length to around 70-72 characters, as otherwise it overruns 80 chars when quoted.] It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. Yes, and these patches live in the unstable distribution. How do you know that a patch won't (a) cause some other part of the program to fall over, or (b) cause some other program to fall over (due to some unforeseen interaction)? That's why patches and updates only go into the unstable distribution. (The sole exception to this is security updates or other critical bugs which are allowed into stable because of the serious damage the problem might otherwise cause.) This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. Who's everyone? I'm quite happy with 3.3.2.3a-11 here. But if you *must* have 3.3.3, then you can either compile it yourself or move to unstable. But with XFree86 being the huge beast which it is, how do you know whether 3.3.3 might interact in bad ways with other pieces of software? That's the purpose of unstable. Also, for potato, since it WILL be glibc 2.1 based, I suspect a large number of people would want versions of XFree, gnome, and other packages without having to upgrade their systems. By setting up an Should we provide libc5 versions as well for those who are still running Debian versions pre-2.0? (My department have machines running 1.2 and 1.3 and are now planning to upgrade to Red Hat 5.2 :-( . And they wanted XFree86 3.3.3, so they downloaded it and compiled it themselves.) I think that it is quite enough work for the developers to ensure that two versions work as well as possible (stable and unstable, and even sometimes frozen), without expecting them to work on a random mix of packages from different versions. GNOME has been discussed in other mails, but for the other stuff, it seems quite reasonable to expect those people who are desperate to download the binaries directly from XFree86's site, for example. extension to our current directory structure for updates, we make it VERY simple for people to add these in. I THINK it might also make it easier to release maintenance releases in this manner. Simply have all the updated packages in the updates section. If apt and dselect do their jobs, it should grab the proper NEWer version of the package. Yes, it would make it much easier to have interim releases, but the stability is guaranteed to suffer. And as the stated purpose of stable is to be just that: stable, it is not reasonable to put routine upgrades of individual packages in stable. There is a new release of Debian approximately every six months: those people who cannot wait that long are welcome to live on the unstable distribution. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Package to give away/orphan: GNU acct
GNU acct is still broken for 2.2 kernels. I thought a recompile would fix it, but it doesn't. The upstream author, with whom I generally had very good (albeit sporadic) contact is MIA. AFAICT the other dists don't distribute acct. The package needs a kernel hacker type who can debug and hopefully fix it. Unless someone steps forward to adopt it, I will ask that acct be removed prior to the release of potato A bug has also been reported on the installation, but I cannot replicate it here on a 2.2 machine. -- According to the latest figures, 43% of all statistics are totally worthless.
Re: Upload queue software?
On Wed, 12 May 1999, Roman Hodek wrote: Does anyone know where I can find the software to run a debian upload queue? I thought it was packaged but I can't seem to find it using the obvois searches.. It's in project/misc/debianqueued-0.8.tar.gz. It's no proper Debian package because it runs on other Unixes, too (mine runs under Solaris). Hmm, why does that prevent you from packaging it? : Jason
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 02:06:24PM -0700, David Bristel wrote: It seems to me that since there will always be patches and updates to packages between releases, and since we have the proposed updates, perhaps we could add an updates area, in addition to the non-free, contrib, and main sections. This would work VERY nicely for users who want to grab the latest patches. A good example of why this would be good is the XFree 3.3.2 being released in slink, and everyone wanting 3.3.3. I am perfectly willing to package a version of XFree86 3.3.3.1 for slink (and thus built against glibc 2.0), if I can get assurance that these will be accepted. Except for the Unix98 pty problem which just popped up with xterm, and some kind of strangeness with detecting a particular IBM RAMDAC chip in the I128 X server, reports appear to be that the potato 3.3.3.1 packages are better than the 3.3.2.3 ones in slink in every respect. Namely, there are several packaging-level bugs that I have fixed in the potato version of X. None of these are security matters, however, and that is typically the sole criterion upon which packages for stable-updates are judged. I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. -- G. Branden Robinson |Yesterday upon the stair, Debian GNU/Linux |I met a man who wasn't there. [EMAIL PROTECTED] |He wasn't there again today, cartoon.ecn.purdue.edu/~branden/ |I think he's from the CIA. pgpasgYQtHADR.pgp Description: PGP signature
GPG as a PGP replacement
Hi all, I have been doing some reasearch here and I have been able to determine that right now GPG represents (with the non-free RSA and IDEA modules) a functional replacement for PGP 2.x for both checking signatures and creating signatures. It is remarkably easy to do, I am surprised that someone else has not mentioned it.. Put this in your .gnupg/options file: load-extension rsa load-extension idea keyring /usr/share/keyrings/debian-keyring.pgp keyring /usr/share/keyrings/debian-keyring.gpg keyring /home/jgg/.pgp/pubring.pgp secret-keyring /home/jgg/.pgp/secring.pgp (for instance) GPG will directly read your existing PGP 2 key rings, the distributed RSA ring and the DSS ring. It also able to directly parse the encrypted secret key ring. PGP 2.x compatible signatures can be generated using this command: gpg --rfc-1991 -a --clearsign foo.txt Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig. Werner says it enters a different mode when you use a pipe.. Sigs can be checked using cat foo.asc | gpgm Much like PGP.. (gpgm is a version that does not need root privlage to lock memory) You can also generate a DSS key and have both your RSA and DSS key available to GPG for signing, the -u option can select between them. I am hoping that information like this will help us to adopt gpg and free algorithms more quickly. With any luck we should be able to eliminate the use of PGP in the archive checking scripts using instead GPG (which would finally allow DSS keys to be used for uploads) As a final note, I have not yet found out the fate of RSA in a years time, I would hope that it will be moved into the main GPG distribution and become a fully free algorithm. IDEA won't be, but IDEA is unnecessary for signatures and GPG can use other ciphers with RSA keys for encryption. Jason
Re: Release Plans (1999-05-10)
On Wed, May 12, 1999 at 11:29:10PM -0400, Branden Robinson wrote: I've been told that this is pretty much Christian Hudon's decision. Perhaps an exception could be made for X, given that it is so huge and onerous to download, and requires gargantuan amounts of space and time to build. But my feelings won't be hurt if he decides against it. In the meantime, Johnie Ingram has been making glibc 2.0 versions of my potato XFree86 packages available at http://www.netgod.net/x/. Which work quite well, by the way ;P. I was forced to get them for my laptop. -- ..Aaron Van Couwenberghe... [EMAIL PROTECTED] [EMAIL PROTECTED] Berlin: http://www.berlin-consortium.org Debian GNU/Linux: http://www.debian.org ...Nothing astonishes men so much as common sense and plain dealing... -- Ralph Waldo Emerson
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Joel Klecker wrote: At 15:14 +0200 1999-05-12, Sven LUTHER wrote: I think the issue is the different way that different ppc systems uses to boot from the CD. I am not entirely sure how amigaos does this, but i bet it is different from macos ... Sure, we could choose not to be cd-bootable, best would be to d othis the same way it is done for linux/m68k cds .. For power macs, we don't need to worry about bootable CDs, most of them have Open Firmware that is too broken to even be capable of booting from either a cdrom drive or a iso9660 filesystem. The few macs that have reasonable OF should be able to boot from an arbitrary executable residing anywhere on the filesystem. The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. -- Matt Porter [EMAIL PROTECTED] This is Linux Country. On a quiet night, you can hear Windows reboot.
Re: Release Plans (1999-05-10)
On Wed, 12 May 1999, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. that reminds me, now that i have my home email working again. (yeah, i'm baack. head for the hills while you can.;) does anybody actually have a list of non-MCG/non-IBM/non-Apple PowerPC CHRP/PReP boards? I'm trying to hunt those little buggers down. Me, being the crazy little bastard I am, plan to get those suckers booting somehow. (Don't ask how; I really dunno yet. Probably hack up lilo or something.:) Also, for those of you who aren't subscribed to debian-powerpc, and have RS/6000's - I am working on bootable kernel images, both UP and SMP, for every RS/6000 that I currently have *REASONABLY* stable. The problem is that I *have* to use 2.2.x kernels, due to the fact that, well, 2.0.x kernels are just quite unsuitable for use on RS/6000's. Too many various issues that I've run into. I'm having some.. ISSUES *grumble*.. with kpkg still, but I'll be sure and let everyone know when they're done. I bugged up gcc again, so it'll be a few days probably. -Phillip R. Jaenke, Head Unix Guru, Unicent Telecom 216-344-2603 / 9a-~5p Eastern - Pester me!
Re: Release Plans (1999-05-10)
On May 12, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. IMHO there's no point in making the APUS installer boot from CD... people will need to select video cards, etc. Besides which, most Amigas can't boot from CD anyway... Guess that narrows it to PReP ;-) Chris -- = | Chris Lawrence | Visit my home page! | |[EMAIL PROTECTED] | http://www.lordsutch.com/chris/ | | | | | Amiga A4000 604e/233Mhz | Visit the Amiga Web Directory | | with Linux/APUS 2.2.3 | http://www.cucug.org/amiga.html | =
alternative man page reader?
has anybody thought about packaging an alternative to the man-db/groff combination for reading man pages? 4mb is a lot for small systems, and reading man pages is pretty much a neccessity. -Brad -Brad
Re: Adding a global UID/GID?
Mitch == Mitch Blevins [EMAIL PROTECTED] writes: Mitch GENERAL QUESTION: What is the procedure for getting a UID in Mitch the 0-99 range added to Debian? Add a wishlist bug to 'base-passwd' I believe. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: doc-base and obnoxious unknown format warnings
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Joey == Joey Hess [EMAIL PROTECTED] writes:
Joey warning: ignoring unknown format `$$format_data{'format'}' if
Joey $ENV{DOC_BASE_GRIPE}; }
Ben This is a nice solution.
Well, actually, in tonight's upload, I only enabled this warning if
the -v or --verbose switch it used. Much cleaner. I hate env vars
anyway.
--
.Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
Re: Release Plans (1999-05-10)
Hi, everyone. I've successfully built most of Gnome on a stock Slink system. Three cheers for the Gnome project and the packaging team! On 12 May 1999 15:41:04 +0200, Martin Bialasinski wrote : BTW: compiling gnome is a pain. We _need_ source dependencies Hear, hear. Just for flavour, the gotchas I've found include: - Need to upgrade autoconf, automake, libtool and debhelper - Make sure libjpeg62-dev and not libjpeg6a-dev is installed, or Imlib builds linked against both, and weird stuff happens. - There are a number of minor build breaks or hassles which I don't have time to reproduce and document. An autobuilder would have a lot of trouble just right now. Eg. bug #37226 and more. I think Debian should have high quality Slink gnome binaries, because not everyone can afford to run unstable and building from source is quite a lot of work. Also, Redhat have this shipped :-) Good luck, Gordon Musing Building Gnome is pretty mind-blowing: tens of megabytes of code and data wrapped in two-million, five hundred thousand tonnes of spinning build-script... PS: Can debian-gtk-gnome be web-archived? -- We knew we were in trouble when we needed the seventh power-board for the coffee machines. // Gordon Deane // Engineering/Maths // Aust. Nat. Uni //
Re: doc-base and obnoxious unknown format warnings
Adam == Adam Di Carlo [EMAIL PROTECTED] writes:
Ben == Ben Gertzfield [EMAIL PROTECTED] writes:
Joey == Joey Hess [EMAIL PROTECTED] writes:
Joey warning: ignoring unknown format `$$format_data{'format'}'
Joey if $ENV{DOC_BASE_GRIPE}; }
Ben This is a nice solution.
Adam Well, actually, in tonight's upload, I only enabled this
Adam warning if the -v or --verbose switch it used. Much
Adam cleaner. I hate env vars anyway.
Fine by me! :)
--
Brought to you by the letters E and L and the number 0.
What's green and sits in the corner? ... A naughty frog!
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.
Re: Splitting debian-devel-changes to separate lists
On Wed, May 12, 1999 at 07:36:27PM +0100, Edward Betts wrote: On Wed, 12 May, 1999, Bart Warmerdam wrote: Hi, The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. seconded Also seconded, but I think this should be on -policy as (IIRC) the lists are mentioned in policy.. Zephaniah E. Hull.. -- I consume, therefore I am -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgp6Ts5MVmVKo.pgp Description: PGP signature
Retraction of Intend to Package: root framework
-BEGIN PGP SIGNED MESSAGE- Dear wnpp maintainers, Dear fellow developers, when I recently had a look at the wnpp list, I saw that I once intended to package the root framework ( http://root.cern.ch/ ). Unfortunatly I am currently working on my diploma (on my master) and as some of you might have noticed, I am even not paying the needed attention to my existing packages (kbackup e.g.). In addition, the license accompanying the root framework prohibits distribution of patches without the permission of the authors. Because of this I want to retract my Intent to package. But I would like to point out, that root extensively uses a C/C++ interpreter with licensing terms, which are more free (cint). Maybe some of you would like to have cint packaged and have enough time to split it from the root. Greetings, Jens P.S.: Please vote against Spam! At http://www.politik-digital.de/spam/ (Sorry Europeans only) - --- [EMAIL PROTECTED] [EMAIL PROTECTED] Key ID: 2048/E451C639 Jens Ritter Key fingerprint: 5F 3D 43 1E 24 1E CC 48 1E 05 93 3A A7 10 73 37 -BEGIN PGP SIGNATURE- Version: 2.6.3ia Charset: noconv iQEVAwUBNzqCubIME9PkUcY5AQGuRQgAsYhrFSpg8f3yH5n+/g4Lk7BuGEZKgUoV boQbciqAaeVYVj5KFSzdiW7/Dg4qoJHr56nA/+oVXvfoJcuJJYtoBqEGADUv9v7L 3CvOyt0DGKc1YuPeZRt4TvH2K1HFziOAC+r222k/w7cct7379kgMW/wjF9cHvQ1/ vxscSptB68tJWEfD+FlyKkU320+LRDf0ahqN7W2ctKUJCUxA8krj/CHUh9RLyjwW njbflU/u1YkYSBrW3Tux1wut2fjuLWRyd/FWQamfWyouNRxHIlVpPBFdKSdTeXih 9eFn8Yx0GaDmBYtIxAA/HzdMU/spRPvetecYw5YqVVS/Kbh7o7803w== =V53m -END PGP SIGNATURE-
Re: Release Plans (1999-05-10)
The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? Thnx, Hartmut
Re: Splitting debian-devel-changes to separate lists
On Wed, 12 May, 1999, Bart Warmerdam wrote: Hi, The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. This isn't really something to vote on. The situation is this: dinstall (the program on master which installs packages into the archive) has been modified to make announcements automatically when the .changes file has format version 1.6. This is produced by an experimental version of dpkg(-dev). Once these changes are added to the standard dpkg(-dev) and all of the maintainers have upgraded to it (say, after the next release), it will be a trivial matter to modify dinstall to announce to the appropriate list (and I believe that Guy intends to do this). Until then, we will continue the way it is. Julian =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED] Debian GNU/Linux Developer. [EMAIL PROTECTED] -*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
[Cc'ing to -devel]
Package: tetex-base
Version: 0.9.990406-1
Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644.
Therefore all font generation operations get an error:
/usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable.
Changing it to mode 666 works around the problem, but the right thing
would be to make mktexupd setgid to some group (daemon?) and make
/var/spool/texmf/ls-R writable by that group. Possibly the same thing
should be done to the subdirectories of /var/spool/texmf, mode 1777
can be problematic.
You are correct. A fully working solution which closes the security
holes is not straightforward, though. I am currently working on a
project to solve this problem. In the meantime though, note that the
font _is_ generated and stored, will be found by kpathsea on the next
occasion that it is needed, and will be written into the ls-R file the
next time the tetex cron job runs.
My current state of progress is:
- Working Perl Kpathsea interface and Kpathsea module (although they
are labelled as alpha, there are some minor bugs apparently and
the Makefiles need cleaning up). You can download it from
http://www.debian.org/~jdg.
- I have rewritten all of the mktex scripts in Perl except for
mktex{mf,tfm,pk}. (You might say, Huh? But that's all of them!
But this means that I have dealt with mktex.opt, mktexnam,
mktexnam.opt, mktexdir, mktexdir.opt, mktexupd and mktexlsr. Just
the three last ones to go.) Unfortunately, these are currently on
paper only; you can have a photocopy of them if you really desire ;)
Still to go:
- At present, I am working on making the Perl scripts behave
identically (modulo bugs) to the shell script counterparts. When
this is working, I fully intend to introduce variant behaviour if
the script is running setuid. We need the scripts to be setuid
tex if they are to be secure, as otherwise, the owner of the
process will still own any font files created, which is Not Good.
Then the writeable font trees would be owned by tex, mode 755, and
ls-R would be owned by tex with mode 644.
- The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them, which is unnecessary. Any
extra privileges they require will be gained when they are called
from other setuid processes. The mktex{mf,tfm,pk} scripts should
do the following if they are running setuid (and do the same as
present if not):
. In a child process, drop any privileges and check the
locations of the files which would need to be created (by
calling mktexnam). Report back to the parent process.
. In the parent process, compare the results against the value of
SYSTEXMF obtained from the system texmf.cnf files, having
cleared (but saved) any environment variables. If the location
which would be used is not within the SYSTEXMF trees, then drop
privileges, reinstate the old environment and create the font.
Since the process is now running as the user with no
privileges, any nasty settings in their personal texmf.cnf or
environment will be ignored.
. Otherwise, we continue with privileges and a sanitised
environment to figure out where *we* would like to place the
created fonts by calling mktexnam again. If it is not in one
of the recognised places (SYSTEXMF, VARFONTS), give up.
Otherwise, go ahead and create the font.
- Issues which need to be addressed for this to work:
. mktexnam currently makes assumptions about the location of a
font based on the writeability of a directory. We must ensure
that these assumptions are correct in this scheme.
. We must be very careful to fork a child process to do the font
creation *before* invoking any of the Kpathsea routines, as the
texmf.cnf files cannot be reinitialised easily. A better
solution may well be to have mktex{mf,tfm,pk} be setuid C
wrappers which call the non-setuid mktex{mf,tfm,pk}.pl scripts;
then they can simply exec another copy of themselves and load
the Kpathsea library afresh. (This also avoids people needing
to have suidperl around if they don't want it.) Doing this
properly is probably a bit painful (will probably use parts of
Kpathsea's proginit.c to get the right location of the mktex
scripts).
. This sound like a lot of computational work, and that it will
be a lot slower than the present system, but since the ls-R
databases will need loading only a handful of times, this
should turn out to be much faster.
Comments appreciated!
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*-
Re: Release Plans (1999-05-10)
Josip Rodin wrote: On Mon, May 10, 1999 at 08:55:44PM +0200, Hartmut Koptein wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. Richard Braakman
Re: Release Plans (1999-05-10)
Hartmut Koptein wrote: Hi, BTW, I think it's good to set an *optimistic* freeze date, so people aren't shocked. I would set it at July 1, or maybe Bastille day (Debian pomme de terre?). We have a long history of overly optimistic freeze dates :-) I'd like to try something else this time. I note, though, that if we do manage to freeze on July 1, we'll be able to have a release in time for the Linuxworld Expo in August. That would be cool. For slink update or for potato? For potato we new min. two months and only if we start now working very hard (all maintainers, not only 10 people or so) on bad packages boot-floppies cd-images. Two months means fixing 2 release-critical bugs per day, starting now. I may have to re-evaluate a few... In any case, my next step will be to mark the packages that I plan to remove from frozen if they aren't fixed at freeze time. This way, their maintainers have advance warning, and the bughunters can concentrate on bugs that will actually delay the freeze. The QA-team must then also have the power to do massive NMU's. How many open bugs have we, more then 7000? This must be down to ~1000. Wow, you're more ambitious than I am :-) I'll be happy enough if we can get the release-critical bugs under control. The rest are, well, not critical to the release, and I'll let someone else worry about them. That said, though, I would like to encourage maintainers to fix up existing packages, rather than packaging more and more new ones. I don't think we can ever reduce the number of bugs unless the ratio of maintainers to packages goes up. Richard Braakman
Re: Release Plans (1999-05-10)
Joel Klecker wrote: At 19:06 +0200 1999-05-10, Richard Braakman wrote: * glibc 2.1 upgrade As far as I know, this project is largely complete. There are one or two bugs left in the backward compatibility code, and there's the question of what to do with /dev/pts. No there isn't, /dev/pts is taken care of. Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. * glibc 2.1 source compatibility A larger task is to ensure that all packages still compile on a glibc 2.1 development system. The sparc people may have a list of problem packages. Most problems in this area have been fixed by the combined effort of the sparc, arm, and powerpc porters. However, many of the patches are sitting in the BTS and have yet to be applied. That is what I meant, actually. We should get those patches into the packages. The issue was delayed during the slink release, I don't think we can in good conscience delay it again. Debian packages should compile from source! Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. powerpc wishes to try for potato. Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? : * Don't try to keep track of everything. Find a sponsor for each : release goal, who keeps track of progress, makes sure it happens, and : gives advance warning of any problems. That way the release manager : only has to stay in touch with the sponsor. Richard Braakman
Re: PROPOSAL: preparation for freezes, release coordination
Adam Di Carlo wrote: * Release Critical Bugs With respect to fixing release critical bugs, I think there are two components to lowering this as a big problem. The first, as pointed out, is to *not* try to cram heavily broken things into unstable just prior to freeze, and it just requires a little self-discipline from developers. I hope to fix this in the long run by having more frequent releases, so that maintainers are less anxious to get their packages in the upcoming release. In the short term... let's just hope :-) The second solution for fixing release-critical bugs is a revived and healthy Debian QA group. I believe Joey is trying to revive this, and I wish him the best of luck. I'm following this development with interest, too. We could use an active Bug-Hunting team. (Nobody expects the Bug Inquisition!) I don't know if the QA team wants to be that, though. If not, could we create a separate team for chasing release-critical bugs? * Release Coordination I propose that we create a new list (argh, yet another list!), 'debian-release'. Next, we ask that representatives from all interested teams (including boot-floppies, cd, archive mgmt, porters, the QA team, testers, security team) be subscribed to the list. This would be a low-volume list for the increased communication between these teams. The consensus reached on this list must be implemented in an prompt fashion, i.e., moving packages into the archive. I support this idea. Among other things, it would be an excellent forum for constructing a step-by-step plan for the release, so that no details are missed and everything happens in the right order. Richard Braakman
Please adopt: prc-tools
Hi, prc-tools is a gcc, gdb, and binutils cross-development package that generates and works with binaries for use on the Palm Pilot/PalmIII/IIIX/V line of products. I tried giving it away last December, but apparently the person that took it didn't have time to upload it, so I'm trying again. The reason I'm giving it away is that it is i386-only and I do not have an i386 system on which to maintain it. Thanks, John
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), but since then they (the mozilla.org guys) released the fourth and fifth milestone (that's their way of calling the big public releases), and everybody expects us (Debian) to package them. Unfortunately, M4 instantly coredumps on every fscking computer we've tried it on, and I can't even build M5 :( I'm trying to build some newer versions right now, actually. What more can I say - we'll just keep trying. If we don't manage to do it before freeze, then I'll file a bug against ftp.debian.org, asking for mozilla package to be removed. -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:53:11PM +0200, Josip Rodin wrote: On Thu, May 13, 1999 at 01:13:10PM +0200, Richard Braakman wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? I was using Mozilla 19981008 for a while with some happiness, but eventually got annoyed by some of its bugs and that it wasn't getting updated. :-/ It'd be nice to have a free, frames java such -capable browser to install, without having to wrestle with the big green dragon... Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpPKmHspPVJQ.pgp Description: PGP signature
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
On Thu, 13 May 1999 11:25:10 +0100 (BST), Julian Gilbey wrote: [Cc'ing to -devel] Package: tetex-base Version: 0.9.990406-1 Out of the box, /var/spool/texmf/ls-R is owned by root and mode 644. Therefore all font generation operations get an error: /usr/share/texmf/web2c/mktexupd: /var/spool/texmf/ls-R unwritable. Changing it to mode 666 works around the problem, but the right thing would be to make mktexupd setgid to some group (daemon?) and make /var/spool/texmf/ls-R writable by that group. Possibly the same thing should be done to the subdirectories of /var/spool/texmf, mode 1777 can be problematic. You are correct. A fully working solution which closes the security holes is not straightforward, though. I am currently working on a project to solve this problem. In the meantime though, note that the font _is_ generated and stored, will be found by kpathsea on the next occasion that it is needed, and will be written into the ls-R file the next time the tetex cron job runs. Glad to hear all of this. I just have one comment: - The mktexlsr, mktexdir and mktexupd scripts must not be setuid. If they are, anyone could run them, which is unnecessary. Any extra privileges they require will be gained when they are called from other setuid processes. It seems to me that *only* these three should be setuid, since only these three need elevated privileges. mktextfm, etc. should be changed to write the output into a scratch directory, and have mktexupd move it into place. Yes, this does mean anyone can invoke them, but if properly designed no damage can be done, and this restricts the scope of the changes and the scope of the specially privileged code much better. zw
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 10:12:46PM +1000, Anthony Towns wrote: mozilla should work for potato Maybe it will ;) We'll try. If it doesn't, I guess the current mozilla should be removed? It's sort of old now, and it doesn't work with glibc 2.1. I was kidding - newer mozilla *does* work, just not the versions people expect from us. We had it working just fine in versions 19990323 and 19990402 (ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? Maybe. Question is - do we want another five thousand wishlist bug reports from users screaming for something 'better'? ;( I think you should look in http://va.debian.org/~bfulgham/ and download the version of mozilla that is (hopefully) still there. If it works, and if more people agree with it, I'll put it in potato. I was using Mozilla 19981008 for a while with some happiness, but eventually got annoyed by some of its bugs and that it wasn't getting updated. :-/ It'd be nice to have a free, frames java such -capable browser to install, without having to wrestle with the big green dragon... I'm all for it, but it ain't so easy :) BTW is there a fast potato i386 machine somewhere on the net for us developers to use? I'm sick of mailing debian-admin to install one-thousand-and-one little library from potato for building mozilla... -- enJoy -*/\*- http://jagor.srce.hr/~jrodin/
Re: Adding a global UID/GID?
On Thu, May 13, 1999 at 03:13:39AM -0400, Adam Di Carlo wrote: Mitch == Mitch Blevins [EMAIL PROTECTED] writes: Mitch GENERAL QUESTION: What is the procedure for getting a UID in Mitch the 0-99 range added to Debian? Add a wishlist bug to 'base-passwd' I believe. And pray. :-) (http://bugs.debian.org/28158)
Re: Release Plans (19990513)
On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote: PAM: Ben Collins sponsored full pamification as a release goal. The main packages that need work are the shadow suite, and xdm. /me blinks... has nis (the package) been PAMified? I positively hate PAM because it's an all or nothing solution. After helping some people set nis up on a couple of RH boxes, we all agreed RH sucks big time. They PAMified what they considered important, and their nis package wasn't on that list. End result: you have lots of PAMified stuff, but you can't use most of PAM's features. Marcelo
Re: Release Plans (1999-05-10)
Sorry it took me so long to reply, life decided to give me my yearly supply of 'fun' in a small amount of time, and I had deleted the message I was replying to.. I'm also sorry about how I jumped, I over reacted a bit, as I said, this has been a very interesting week... On Tue, May 11, 1999 at 07:51:31AM +0200, Raphael Hertzog wrote: Le Mon, May 10, 1999 at 07:12:55PM -0400, Zephaniah E. Hull écrivait: I highly question your ability to fill this role as it is quite clear that you have not been following the perl5.005 stuff, specificly the debian-perl list and the massages on -devel before -perl existed about how to attack it.. I've read everything, I'm subscribed to -perl. I know that Darren is working hard on the perl package. What do you have against me ? I'm ready for helping and you criticize me. If you want to do the job, it's ok for me. The current plan cleanly addresses the case of things ending up broken, and the perl maintainer is a bit busy but spending his time working on it instead of jumping up every thread where incorrect info is mentioned. What was wrong in the message you're replying to ? Specificly the path issues and the mention of the bug reports.. (From the message I replied to in the first place) Many of them were only paths problems (that may not appear with the official perl5.005 package). And I've already filled some bugs against netbase and netstd so that the packages do not break when perl5.005 is uploaded. This gives the impression that you are quite unaware that perl5.005 should have little to no effect on ANY packages which are currently in use, as perl5.004 will continue to be used by things.. (There are a few minor issues which still need to be worked out, for instance perl-base and deciding which perl will become essential, however the basic upgrade path is that NOTHING breaks as perl5.004 continues to be used by things) As far as the coordinator position, I don't think I'm up to keeping track of everything, but I would definitely like to stay just a little off to the side of the middle... Once again, sorry for snapping at you, hopefully I'll still be living here tomorrow, and be in a state to do anything. (Don't ask, unless you really want a nice long rant about things) Zephaniah E. Hull.. Cheers, -- Raphaël Hertzog 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/ -- PGP EA5198D1-Zephaniah E. Hull [EMAIL PROTECTED]-GPG E65A7801 Keys available at http://whitestar.soark.net/~warp/public_keys. CCs of replies from mailing lists are encouraged. pgp065hyL6CwB.pgp Description: PGP signature
Package to give away/orphan: GNU acct
GNU acct is still broken for 2.2 kernels. I thought a recompile would fix it, but it doesn't. The upstream author, with whom I generally had very good (albeit sporadic) contact is MIA. AFAICT the other dists don't distribute acct. The package needs a kernel hacker type who can debug and hopefully fix it. Unless someone steps forward to adopt it, I will ask that acct be removed prior to the release of potato In looking at the gnucash site I got the impression that work on gnu acct was being phased out in favor of gnucash. Has anyone tried to complile gnucash, I think they have made the move from motif/lesstif to gtk. As soon as I get the time to install gnome on my slink system, trying out gnucash is on my todo list (if I can get a replacement for quicken and turbotax I can get my wife off windows and on to linux. I already have a replacement for wordperfect, wordperfect!) === Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
Re: Release Plans (1999-05-10)
Hi Richard, On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote: Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? : * Don't try to keep track of everything. Find a sponsor for each : release goal, who keeps track of progress, makes sure it happens, and : gives advance warning of any problems. That way the release manager : only has to stay in touch with the sponsor. Could you please add IPv6 Support as a Release Goal? I'm willing to act as a sponsor for this (especially since it looks like everyone else is more than happy to do the actual work :). We're aiming, more or less, to get the base system IPv6 capable for potato, and, I guess, most of the networky programs of priority Standard or higher for woody [0]. We're currently at the point where: In potato: * bind supports records (and has for ages) * netbase supports IPv6 interfaces, has a working ping6, and traceroute6 In progress: [1] * telnet/telnetd (support for both IPv6 and IPv4 in one binary) * inetd, tcp-wrappers * apache * zmailer * radvd Under consideration: (working packages aren't available yet) * Exim Mark Baker [EMAIL PROTECTED] (the exim.deb maintainer) * GNU Zebra Matthew Schlegel [EMAIL PROTECTED] (tentative intent to package) Craig Sanders [EMAIL PROTECTED]) (from the WNPP) * apt Remco van de Meent [EMAIL PROTECTED] (currently just trying things out) Still to do for potato: * ftp, ftpd * finger, fingerd * identd * tcpdump * lynx * ssh We're also working on getting a 6-bone subnet (or something similar) to help testing all this. Cheers, aj [0] ...or whatever. [1] Packages have been made, and are available for testing from either of: deb http://www.debian.org/~ajt/ipv6 ipv6 unstable deb ftp://ftp.ipv6.nl/pub debian/ The sites are more or less synced; they're also i386 only at the moment. All packages in the staging area *need* testing, btw: if you try one and it does/doesn't work, please send a mail to the -ipv6 list so we know when things are ready to be mashed into potato. -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. PGP encrypted mail preferred. ``There's nothing worse than people with a clue. They're always disagreeing with you.'' -- Andrew Over pgpL91bHvu2CW.pgp Description: PGP signature
Re: Release Plans (1999-05-10)
At 13:02 +0200 1999-05-13, Richard Braakman wrote: Joel Klecker wrote: At 19:06 +0200 1999-05-10, Richard Braakman wrote: * glibc 2.1 upgrade As far as I know, this project is largely complete. There are one or two bugs left in the backward compatibility code, and there's the question of what to do with /dev/pts. No there isn't, /dev/pts is taken care of. Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. Most programs do not use UNIX98 ptys, is that what you meant about what to do with it? Potato Architectures: As far as I know it will be the same set as in slink, i.e. i386, m68k, sparc, and alpha. If any other architectures want to make a release they will have to decide soon. powerpc wishes to try for potato. Excellent. Would someone like to be a sponsor for that, in the sense that I described last March? I am willing to be the sponsor for the powerpc release. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
At 10:25 +0200 1999-05-13, Hartmut Koptein wrote: The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Linus' tree is fine on pmac, from what I hear. The only patches pmac would need is stuff for the iMac and Blue G3, hopefully OHCI will start to work in the in-kernel USB driver soon, then I will have just the Blue G3 stuff to deal with. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Re: Release Plans (1999-05-10)
At 22:10 -0700 1999-05-12, Matt Porter wrote: The non-mac CHRP boards (LongTrails etc.) also use OF I believe. Are their OF's so broken that they don't work properly as well? Perhaps APUS and PReP (and I'm talking PPCBUG firmware not OF systems) are the only ones we need to worry about. Interestingly enough, Motorola dropped OF because it was so damn buggy. No, CHRP boards tend to have good OF. Most of the Macs had such broken OF because Apple did not rely on it for booting Mac OS (it only had to be enough to boot up and hand control to the Mac ROM). In the new world architecture introduced with the iMac, Apple finally began relying on OF to boot Mac OS, thus it has to be stable. -- Joel Klecker (aka Espy)Debian GNU/Linux Developer URL:mailto:[EMAIL PROTECTED] URL:mailto:[EMAIL PROTECTED] URL:http://web.espy.org/ URL:http://www.debian.org/
Intent to upload vflib2, watanabe-vfont and asiya24-vfont
I'll upload debian packaged version of vflib2 and two vfonts. VFlib: VFlib is a library for converting vector fonts (also known as outline fonts) to bit map data. Its functions include rotation, shrinking, and changing the slant of characters. VFlib is used by localized software for Japanese document processing that requires Kanji fonts, for example xdvi, dvi2ps, ghostscript. asiya24-vfont: Vector fonts made from Abe's asiya24 font. watanabe-vfont: Vector fonts made from labosystem123 32dots font. -- Keita Maehara [EMAIL PROTECTED]
Re: Package to give away/orphan: GNU acct
thwap acct is user login/use accounting, NOT money matters.
Re: Release Plans (1999-05-10)
On Thu, May 13, 1999 at 01:02:10PM +0200, Richard Braakman wrote: Hmm... then why isn't it used on my system? devpts is mounted, I have /dev/ptmx, but /dev/pts is empty. Perhaps you aren't using anything that uses unix98 ptys? Not everything uses them by default, you know. Sometimes patches are required. Try ssh'ing to localhost, or install Eterm, or grab some of the packages from ftp.espy.org/pub/debian (I think that's the correct path). In there is patched packages for screen, telnet, etc to use Unix98 ptys. Brian
Re: Bug#37606: /var/spool/texmf/ls-R unwritable
Glad to hear all of this. I just have one comment:
- The mktexlsr, mktexdir and mktexupd scripts must not be setuid.
If they are, anyone could run them, which is unnecessary. Any
extra privileges they require will be gained when they are called
from other setuid processes.
It seems to me that *only* these three should be setuid, since only
these three need elevated privileges. mktextfm, etc. should be
changed to write the output into a scratch directory, and have
mktexupd move it into place.
Yes, this does mean anyone can invoke them, but if properly designed
no damage can be done, and this restricts the scope of the changes and
the scope of the specially privileged code much better.
No, absolutely not. If mktexupd is setuid, then anyone can make it do
anything to the ls-R file, I would guess. And having mktex{mf,tfm,pk}
writing to a scratch directory defeats the purpose of making the fonts
directory read only, as anyone could then create a corrupt font file
in the scratch directory and run mktexupd. The mktexupd program is
essentially only used in two situations: (1) when called from
mktex{mf,tfm,pk} and (2) when called from texconfig or a postinst. In
the latter situations, it will be running as root if it is doing
anything useful, and all that must be done in that case is to ensure
that the ownership of the ls-R files is unchanged. This is not too
difficult to arrange if you are running as root!
Julian
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, QMW, Univ. of London. [EMAIL PROTECTED]
Debian GNU/Linux Developer. [EMAIL PROTECTED]
-*- Finger [EMAIL PROTECTED] for my PGP public key. -*-
Re: Adding a global UID/GID?
In foo.debian-devel, Brian wrote: On Thu, May 13, 1999 at 03:13:39AM -0400, Adam Di Carlo wrote: Mitch == Mitch Blevins [EMAIL PROTECTED] writes: Mitch GENERAL QUESTION: What is the procedure for getting a UID in Mitch the 0-99 range added to Debian? Add a wishlist bug to 'base-passwd' I believe. And pray. :-) (http://bugs.debian.org/28158) hmmm. Maybe this is better suited for a dynamic system ID (101-1000)? It doesn't look like we have much room to expand in the 0-100 range. -Mitch (minorly annoyed that a non-free package like qmail uses up 5% of our global UID space)
Re: Release Plans (19990513)
Marcelo E. Magallon [EMAIL PROTECTED] writes: On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote: PAM: Ben Collins sponsored full pamification as a release goal. The main packages that need work are the shadow suite, and xdm. /me blinks... has nis (the package) been PAMified? I positively hate PAM because it's an all or nothing solution. After helping some people set nis up on a couple of RH boxes, we all agreed RH sucks big time. They PAMified what they considered important, and their nis package wasn't on that list. End result: you have lots of PAMified stuff, but you can't use most of PAM's features. I'm not entirely sure what you're talking about here. I use NIS and PAM all the time on RedHat (and Debian - although half of our stuff is not yet pamified). What exactly has to be pamified in the nis package? (In RH 6.0, setting up an NIS client is as easy as typing the domain name into a text widget during the install.) In fact, on Debian I use my own pamified versions of rsh because the non-pam versions _don't_ work with NIS. (They don't grok netgroups in hosts.equiv.) Steve [EMAIL PROTECTED]
Old Library dependencies Re: Release Plans (19990513)
Richard Braakman [EMAIL PROTECTED] writes: (Please send followups to this mail to debian-devel, not debian-devel-announce) This is what I learned from the responses to the previous announcement. Boot disks: CD Images: Architectures: PAM: Perl 5.005: Library dependencies: Remove as many dependencies on old libraries as possible, this includes: libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6, libwraster1, libpng0g and various older gtk/gnome libraries. Problematic packages can be found using apt-cache showpkg libjpegg6a (replace libjpegg6a with the outdated library). A whole list of packages can be done with a script like: (LIBS=libpng0g newt0.25 ncurses3.4 libpgsql libjpegg6a tcl7.6 libwraster1 for pkg in $LIBS; do apt-cache showpkg $pkg|sed -e '/^Reverse D/,/^[^ ]/p;d'|grep -v Depend done)| sort -u (We should filter out an exceptions list too - these lists will have to be seperately generated for each architecture.) It might also be a good idea to add a filter to dinstall to keep new packages that depend on one of these libraries from being uploaded (with a suitable exceptions list). A raw list of bad packages is at the end of this message. Steve [EMAIL PROTECTED] abiword,libpng0g angband,ncurses3.4 boot-floppies,newt0.25 cqcam,libjpegg6a cti-ifhp,ncurses3.4 dbf2pg,libpgsql fbtv,libjpegg6a ftape-util,tk4.2 gettyps,ncurses3.4 gicon,libjpegg6a gnotes,libjpegg6a gtksql,libpgsql gzilla,libjpegg6a hdlant,ncurses3.4 hfsutils-tcltk,libjpegg6a imagemagick,libjpegg6a imaptool,libjpegg6a ircii,ncurses3.4 itcl3.0,ncurses3.4 jpeginfo,libjpegg6a kerberos4kth-clients,ncurses3.4 kerberos4kth-services,ncurses3.4 kerberos4kth-user,ncurses3.4 knews,libjpegg6a libch,libpgsql libhdf4g,libjpegg6a libjpeg6a,libjpegg6a libjpegg-dev,libjpegg6a libmagick4g,libjpegg6a libmagick4g-lzw,libjpegg6a libpgsql2,libpgsql libterm-readline-gnu-perl,ncurses3.4 libtiff3,libjpegg6a malaga-bin,tk4.2 mgt,ncurses3.4 mosaic,libjpegg6a mosaic,libpng0g mush,ncurses3.4 netris,ncurses3.4 netstd,ncurses3.4 nn,ncurses3.4 oneliner,ncurses3.4 perlmagick,libjpegg6a pfe,ncurses3.4 prc-tools,ncurses3.4 rat,ncurses3.4 rscheme,ncurses3.4 scilab,ncurses3.4 scottfree,ncurses3.4 sniffit,ncurses3.4 socks4-clients,ncurses3.4 speak-freely,ncurses3.4 streamer,libjpegg6a tcd,ncurses3.4 tcl7.6-dev,tcl7.6 tcl76,tcl7.6 tela,ncurses3.4 telnet98,ncurses3.4 telnetd98,ncurses3.4 tf,ncurses3.4 tk4.2,tcl7.6 tk4.2-dev,tk4.2 tk42,tk4.2 tkdesk,tcl7.6 tkdesk,tk4.2 tkgofer,ncurses3.4 tkgofer,tcl7.6 tkgofer,tk4.2 tkstep4.2,tcl7.6 trn,ncurses3.4 ultra-utils,ncurses3.4 uudeview,tcl7.6 uudeview,tk4.2 vice,ncurses3.4 webcam,libjpegg6a wmss,libwraster1 worklog,ncurses3.4 www-pgsql,libpgsql x11iraf,ncurses3.4 xacc,libjpegg6a xawtv,libjpegg6a xfig,libjpegg6a xlife,ncurses3.4 xloadimage,libjpegg6a xpaint,libjpegg6a xpcd,libjpegg6a yagirc,libjpegg6a
Re: Old Library dependencies Re: Release Plans (19990513)
Steve Dunham [EMAIL PROTECTED] writes: Remove as many dependencies on old libraries as possible, this includes: libjpegg6a, libncurses3.4, newt0.25, libpgsql, tk4.2, tcl7.6, libwraster1, libpng0g and various older gtk/gnome libraries. Looking at some of these, it occurs to me that one thing that may cause this to happen accidentally is when a -dev package includes a soname---because developers have to take an additional explicit step to be sure to compile with the new version---as an example, the existence of libpng0g-dev (rather than libpng-dev) would make it easy for people to miss the new -dev library. Should we try and remove sonames from -dev package names? Mike.
RE: Release Plans (1999-05-10)
(ask Brent Fulgham, maybe there were more), Would it be possible to at least have one of those in potato? Maybe. Question is - do we want another five thousand wishlist bug reports from users screaming for something 'better'? ;( I think you should look in http://va.debian.org/~bfulgham/ and download the version of mozilla that is (hopefully) still there. If it works, and if more people agree with it, I'll put it in potato. The only problem I had with the versions in my home directory is that they were somewhat slow. They were not built using optimization, so they suffer some performance hits. Everything seems to build fine according to Tinderbox. Let's try another build Josip and see how it works out. If we can't get it to build cleanly, I will pull CVS over my phone line at home and try building on my Potato system there... -Brent
Re: Release Plans (19990513)
I'm not entirely sure what you're talking about here. I use NIS and PAM all the time on RedHat (and Debian - although half of our stuff is not yet pamified). What exactly has to be pamified in the nis package? (In RH 6.0, setting up an NIS client is as easy as typing the domain name into a text widget during the install.) IIRC, the nis server was running Debian and the nis client was running RH 5.2; until I switched everything to unix_auth, the client wouldn't verify passwords using the NIS server. On a different setup, both the system and the server were running RH 5.2, and NIS wouldn't work until unix_auth was used in /etc/pam.d/login; what's the point of using PAM if you end up using unix_auth? Marcelo
PAM notes... [was Re: Release Plans (19990513)]
On Thu, May 13, 1999 at 10:13:59AM -0600, Marcelo E. Magallon wrote:
I'm not entirely sure what you're talking about here.
I use NIS and PAM all the time on RedHat (and Debian - although half
of our stuff is not yet pamified). What exactly has to be pamified in
the nis package? (In RH 6.0, setting up an NIS client is as easy as
typing the domain name into a text widget during the install.)
IIRC, the nis server was running Debian and the nis client was running RH
5.2; until I switched everything to unix_auth, the client wouldn't verify
passwords using the NIS server. On a different setup, both the system and
the server were running RH 5.2, and NIS wouldn't work until unix_auth was
used in /etc/pam.d/login; what's the point of using PAM if you end up using
unix_auth?
The unix modules do not imply using /etc/{shadow,passwd}, they mean you
will be using the native libc calls which in turn use /etc/nsswitch.conf.
NIS should work fine with PAM without _any_ changes as long as you have
nis listed in nsswitch.conf for the proper listings (just the same as you
would have to do without PAM).
IOW, PAM does not have anything to do with NIS support. Please NOTE!!! Do
not use pwdb as defaults in the pam.d for packages which support PAM, we
ran into this problem with ssh/PAM, it does initially break NIS support
unless you also modify /etc/pwdb.conf, and this has been looked down on,
and should _not_ be used as default for our packages.
Re: Release Plans (19990513)
On Thu, May 13, 1999 at 07:03:37AM -0600, Marcelo E. Magallon wrote: On Thu, May 13, 1999 at 02:28:16PM +0200, Richard Braakman wrote: PAM: Ben Collins sponsored full pamification as a release goal. The main packages that need work are the shadow suite, and xdm. /me blinks... has nis (the package) been PAMified? I positively hate PAM because it's an all or nothing solution. After helping some people set nis up on a couple of RH boxes, we all agreed RH sucks big time. They PAMified what they considered important, and their nis package wasn't on that list. End result: you have lots of PAMified stuff, but you can't use most of PAM's features. The reason for this is because RH uses libpwdb with their PAM apps and pam_pwdb as a module. This means you have to setup /etc/nsswitch.conf _and_ /etc/pwdb.conf to use NIS. We don't use libpwdb in our pam, and pam_pwdb.so is not to be used as a default module for PAM applications. Instead pam_unix_*.so is used and works fine with NIS.
Re: Release Plans (1999-05-10)
Le Thu, May 13, 1999 at 09:16:11AM -0400, Zephaniah E. Hull écrivait: Specificly the path issues and the mention of the bug reports.. About the bugs, here they are : http://www.debian.org/Bugs/db/35/35236.html http://www.debian.org/Bugs/db/35/35446.html And there are path problems IF perl5.005 is used and IF perl5.005 is compiled without /usr/lib/perl5 in @INC. But with the solutions proposed in those bug reports, there won't be any problems at all (with perl5.004 or perl5.005 and any further version). This gives the impression that you are quite unaware that perl5.005 should have little to no effect on ANY packages which are currently in use, as perl5.004 will continue to be used by things.. This is true if perl5.004 will still be used, but as you know, perl5.005 has some binary incompatiblity for binary modules. And actual binary modules will be replaced by newly compiled ones and will depend on perl5.005. So if you have one binary module on your system and if people upgrade it, perl5.005 will be automatically installed. And /usr/bin/perl will be changed. And then the problems may arise. And last I talked with Darren, he said that he will need to add /usr/lib/perl5 to @INC at least for potato (woody's perl may get rid of it) in order not to have to conflict with specific version of netstd and/or netbase. Because actually there are postinst script that do NOT run if you use perl5.005 without /usr/lib/perl5 in @INC. Look at netstd's and netbase's postints. BTW, I think there's a similar problem for the PDL package. (There are a few minor issues which still need to be worked out, for instance perl-base and deciding which perl will become essential, however the basic upgrade path is that NOTHING breaks as perl5.004 continues to be used by things) That's ok, as long as you do not upgrade binary perl modules. Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Re: GPG as a PGP replacement
Hi Ship's Log, Lt. Jason Gunthorpe, Stardate 120599.2134: Hi all, I have been doing some reasearch here and I have been able to determine that right now GPG represents (with the non-free RSA and IDEA modules) a functional replacement for PGP 2.x for both checking signatures and creating signatures. It is remarkably easy to do, I am surprised that someone else has not mentioned it.. Put this in your .gnupg/options file: load-extension rsa load-extension idea keyring /usr/share/keyrings/debian-keyring.pgp keyring /usr/share/keyrings/debian-keyring.gpg keyring /home/jgg/.pgp/pubring.pgp secret-keyring /home/jgg/.pgp/secring.pgp oops .. have you looked at the debian gpg? It is actually a script callin gpg.gnupg (the binary) with exactly these options (except the debian-keyring) Greetings -- Alexander N. Benner [EMAIL PROTECTED] #Ixthys #Darmstadt #LinuxGer The grit in your eye soon enters your heartAnne Clark And all that was strength is just falling apart We're jumping from one bed and into anotherSELF DESTRUCT Searching for something that we'll never discover Joined Up Writing
Re: Release Plans (1999-05-10)
[ I'm responding to myself in order to precise things, there was some informations missing in the previous message ] [ Followup on debian-perl, please ] Le Thu, May 13, 1999 at 06:32:00PM +0200, Raphael Hertzog écrivait: This is true if perl5.004 will still be used, but as you know, perl5.005 has some binary incompatiblity for binary modules. And actual binary modules will be replaced by newly compiled ones and will depend on perl5.005. So if you have one binary module on your system and if people upgrade it, perl5.005 will be automatically installed. And /usr/bin/perl will be changed. And then the problems may arise. In fact, we must agree to use the latest perl. Because there's the same problem with non-binary perl modules. If they are built with the latest perl, they'll be installed in a versionned directory and therefore they will have to depend on perl5.005 Zephaniah, you must understand that the fact we decided to have multiple perls do not ONLY have to do to the fact that we want a smooth upgrade but also that we do want to make multiple perl available so that we can use #!/usr/lib/perl5.004 in script that do specifically need such a perl. And we CAN have a smooth upgrade even with perl5.005 as the default perl. The important point is that all modules in Debian must have been built with the same perl version and that perl keeps /usr/lib/perl5 in @INC (only for potato release, after that we'll get rid of it because the scripts that would break will already be corrected). And I do not want to minimize the importance of the perl5.005 upgrade, there are many little issues affecting MANY packages : - of course perl modules must be rebuilt - postint scripts of some packages must be corrected - all package depending on perl will have to depend on perl5. If they need a specific version of perl, they'll have to set a dependency to perl5.XXX. This is not mandatory, but should be done for consistency, because the perl package will only be a fake package (like xbase was) depending on perl5.004. BTW, I think that perl should depend on perl5.004 | perl5.005 ... otherwise with perl5.005 installed, a package depending on perl would have dependencies problems. :-) Cheers, -- Hertzog Raphaël 0C4CABF1 http://prope.insa-lyon.fr/~rhertzog/
Intent to create: nfs-client
In order for the kernel nfs daemon to function properly wrt file locking,
clients must be running rpc.statd. I will therefore, as part of moving
knfs to unstable, create a nfs-client package containing rpc.statd.
I plan to include showmount in it as well (with an approproate replaces for
nfs-server), since it is a handy tool on clients as well.
/Anders
--
-- Of course I'm crazy, but that doesn't mean I'm wrong.
Anders Hammarquist | [EMAIL PROTECTED],iko.pp}.se
Physics Student, root, Debian Maintainer| Tel: +46.31.47 69 27
Jag ska b|rja plugga i l{svecka 1...| Cel: +46.707.27 86 87
Re: Package to give away/orphan: GNU acct
acct is user login/use accounting, NOT money matters. oops. Yeah that was Xacct or something like that. Oh well never mind. === Amateur Radio, when all else fails! http://www.qsl.net/wa2mze Debian Gnu Linux, Live Free or . _ Do You Yahoo!? Free instant messaging and more at http://messenger.yahoo.com
debbugs not on Freshmeat?
Hi, I noticed that debbugs isn't listed in Freshmeat's bug tracking software site: http://freshmeat.net/appindex/development/bug-tracking.html Is there any reason why it isn't listed? -Ossama -- Ossama Othman [EMAIL PROTECTED] Center for Distributed Object Computing, Washington University, St. Louis 58 60 1A E8 7A 66 F4 44 74 9F 3C D4 EF BF 35 88 1024/8A04D15D 1998/08/26
Re: GPG as a PGP replacement
On May 13, Jason Gunthorpe [EMAIL PROTECTED] wrote: PGP 2.x compatible signatures can be generated using this command: gpg --rfc-1991 -a --clearsign foo.txt AFAIK this is not needed. The only compatibility options I have in my ~/.gnupg/options file are: compress-algo 1 force-v3-sigs no-comment Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig. I do that for it.* CFVs and I'm quite sure the signatures can be verified with PGP 2.x. If anyone cares I can provide my generic GPG.pm module for signing and verifying. -- ciao, Marco
Re: Haskell in Debian
Hi. On Wed, May 12, 1999 at 06:21:19PM +0200, Rui Zhu wrote: On Wed, May 12, 1999 at 07:00:31PM +0300, Antti-Juhani Kaijanaho wrote: In related note, according to unofficial information from Simon Peyton Jones (the primary author of GHC), the Glasgow Haskell Compiler (GHC) will become free RSN. Currently GHC has no license. I've tried to bootstrap it but it is so big a beast that I'll probably let it pass. I hope someone else packages it when it becomes free. It is good news though it is only unofficial one. I've tried to build 4.02, it took me 4 hours on my K6-233 box and costed more than 100MB disk. I'd like to apply to become a Debian maintainer and package it, if no one want to take it. Well, for about the fifth time over the years, I'm having a go at compiling ghc (I finally have plenty of disk and a decent amount of RAM). I've hit two problems so far: a) happy is unhappy [1] I have mailed Simon M? regarding this. Binary is distributed for use with libc5, source is distributed with a libc5-dependent bootstrap. I couldn't compile from the source due to ghc being unhappy with the options happy wanted (-fhaskell-1.3) and various hard-codings of the ghc path and the ghc version. I would happy to take on happy, once it's happy. This may just be a case of the GHC people making their latest CVS snapshot available. Oh, and there is the small question of the lack of a licence (I also queried this). b) ghc runs out of heap compiling its parser The file ParseIface.hs (in ghc/compiler) needs more than 64M but no more than 128M of heap to compile. With 64M of RAM and not too much else (X and ntpd) running you are looking at 1500+ garbage collections for about 1.5G of allocation. This file took 10-20 minutes on my machine. If you have 64M of RAM you should probably be the maintainer. I'm thinking of upgrading in the next month of so, funds permitting. In any case, given the quantity of stuff that makes up ghc (the compiler, the profiling tools, the parallel simulation package, etc.), some division of labour might be sensible. If that turns out to be a bad idea... well, I have an alpha on which I could _try_ to get ghc up and running, presupposing a diff.gz and a working bootstrap compiler. I would need to find some more memory for the poor thing though. Lastly, the ghc-users list seems to be rather quiet, but I've only just subscribed. Giuliano. [1] note for the bemused: happy is a yacc for Haskell
Re: debian-upload-queue in Japan (Re: Homapages in list of maintainers)
Thank you for your quick action :) In article [EMAIL PROTECTED] Fumitoshi UKAI [EMAIL PROTECTED] writes: I've already set up debian upload queue daemon on master.debian.or.jp. It seems to work fine, Susumu Osawa has uploaded aumix package as powerpc binary NMU via this upload queue yesterday:) Then we should inform [EMAIL PROTECTED] about this to make update the /etc/dupload.conf file, as Josip Rodin told here and me (Thank you Josip :). Now, I'm wondering what nickname is used for this upload queue. Since master-jp is already used for nickname to dupload for JP archives (in Debian JP Project), different name is better to distinguish, I think. Any idea? Even if the master-jp was not used, I think it is not suitable, because it resembles master. I don't like master-?? coming all over the world ;) How is the other nicname chiark, elrangen, and giano named ? Are they named after the name of the location ? I personally prefer sakura, a Cherry blossom, kind of flower. It is famous in Japan, as a gift from Japan to be planted along the Potomac(?) river in the Washington D.C. But another member of JP project said that name is used for another host which is used to build the sparc binary... Then, how about tokyo ? It is the name of a famous city that can be recognisable globally, I suppose. Or fuji ? the name of the highest mountain in Japan. -- Taketoshi Sano: [EMAIL PROTECTED]
Re: GPG as a PGP replacement
On Thu, 13 May 1999, Marco d'Itri wrote: PGP 2.x compatible signatures can be generated using this command: gpg --rfc-1991 -a --clearsign foo.txt AFAIK this is not needed. The only compatibility options I have in my ~/.gnupg/options file are: I was unable to make it work without the --rfc-1991 argument shrug Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig. I do that for it.* CFVs and I'm quite sure the signatures can be verified with PGP 2.x. If anyone cares I can provide my generic GPG.pm module for signing and verifying. Well, I tried many many times and went so far as to ask on the mailing list (was told it wouldn't work), never once was I able to make gpg create a signature that pgp 2.6 would accept using a pipe. You might want to double check that your sigs do work.. Jason
Re: Haskell in Debian
On Thu, May 13, 1999 at 09:10:48PM +0100, Giuliano P Procida wrote: I've hit two problems so far: a) happy is unhappy [1] b) ghc runs out of heap compiling its parser Well, I spoke to soon. I have a compile failure with no error message: ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelBase -H10m -c PrelBase.lhs -o PrelBase.o -osuf o make[3]: *** [PrelBase.o] Error 1 and that is as far as I get (make -k doesn't get much more done). Giuliano.
libmysqlclient in potato not work with php3-mysql-3.0.7-2
After I upgrade to mysql 3.22.20a-3 in potato, my php3 scripts connecting to mysql database stoped working. It complains with Fatal error: Call to unsupported or undefined function mysql_connect() After some investigation, I found out the php3-mysql module (mysql.so) is looking for libmysqlclient.so.4, while we have libmysqlclient.so.6 in the package now. Can someone update the package php3 and the modules please? Thanks. -- --- Yifang Dai Fax: (847)628-0255
Re: Splitting debian-devel-changes to separate lists
Previously Bart Warmerdam wrote: The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. I've been told that if we used listar for that list we can let subscribers simply toggle flags for what they want to receive. That sounded like a perfect solution to me... in the meantime I'm using this procmail-recipe to filter out binary-only uploads: :0 * ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\) /dev/null Wichert. -- == This combination of bytes forms a message written to you by Wichert Akkerman. E-Mail: [EMAIL PROTECTED] WWW: http://www.wi.leidenuniv.nl/~wichert/ pgpCZCQA0eGDh.pgp Description: PGP signature
Re: Splitting debian-devel-changes to separate lists
Wichert == Wichert Akkerman [EMAIL PROTECTED] writes: Wichert Previously Bart Warmerdam wrote: The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. Wichert I've been told that if we used listar for that list we Wichert can let subscribers simply toggle flags for what they Wichert want to receive. That sounded like a perfect solution to Wichert me... in the meantime I'm using this procmail-recipe to Wichert filter out binary-only uploads: And just if someone are using gnus, here's my split's... - s n i p - (setq gnus-auto-expirable-newsgroups mail.sent.*\\|debian.changes nnmail-split-methods 'nnmail-split-fancy ;; Aliases for the splitting... nnmail-split-abbrev-alist '((any . [Ff]rom\\|[Tt]o\\|[Cc]c\\|sender\\|resent-to\\|resent-from\\|apparently-to\\|Delivered-To) (from . From\\|from) (ToCc . to\\|To\\|cc\\|Cc) (ToCcReSentTo . [Tt]o\\|[Cc]c\\|resent-to\\|Delivered-To) (mail . mailer-daemon\\|postmaster\\|MAILER-DAEMON) (subj . Subject) (ml . Mailing-List\\|X-From-Line\\|X-Mailing-List)) ;; The actual splitting... nnmail-split-fancy '(| ;; Debian stuff (any [EMAIL PROTECTED] (| ;; Messages from the debian-private list... (ml debian-private.* (| (subj Recently.*accepted.*maintainer.* debian.new-maints) debian.private)) ;; Messages from the debian-changes OR debian-devel-changes mailinglist... (ml debian-devel-changes.*\\|debian-changes (| (subj New Debian.* debian.changes-new) (subj RETRACTING.* debian.changes-retract) (subj Installed.* debian.changes-installed) ;; (subj Uploaded.*i386.*\\|Uploaded.*all.* ;; Package uploads that we are specially intrested of... (| (subj \\(.*util-linux.*\\|.*leafnode.*\\|.*roxen.*\\|.*gnudip.*\\|.*pike.*\\|.*chooser.*\\|.*vpnd.*\\) debian.changes-watch) (subj \\(.*mrouted.*\\|.*xipmsg.*\\|.*minfo.*\\|.*ipac.*\\|.*barcode.*\\|.*licq.*\\|.*dhis.*\\) debian.changes-watch) (subj .*dhcp.* debian.dhcp))) ;; (subj .*hurd-i386.*debian.changes-hurd) (subj .*m68k.* debian.changes-m68k) (subj .*i386.* debian.changes-i386) (subj .*sparc.* debian.changes-sparc) (subj .*arm.* debian.changes-arm) (subj .*alpha.* debian.changes-alpha) (subj .*powerpc.* debian.changes-powerpc) (subj lintian debian.lintian) debian.changes)) ;; Messages from the debian-boot mailinglist... (ml debian-boot (| (subj Debian Boot Floppies CVS:.* debian.boot-cvs) debian.boot)) ;; Messages from the other debian lists... (ml debian-mentors debian.mentors) (ml debian-email debian.email) (ml debian-admintool debian.admintool) (ml debian-devel debian.devel) (ml debian-maintainer debian.maintainer) (ml debian-alpha debian.alpha) (ml debian-devel-announce debian.announce) (ml debian-announce debian.announce) (ml debian-testing debian.testing) (ml debian-68k debian.m68k) (ml debian-arm debian.arm) (ml debian-java debian.java) (ml netwinder debian.netwinder) (ml deity debian.deity) (ml beowulf debian.beowulf) ;; Messages from the debian administrators etc... (from maor-installer debian.installed) (ml maor-installer debian.installed) (from owner debian.bugs) (ToCc submit debian.bugs) (ToCc security debian.bugs) - s n i p - -- We are GNU. You will be GPL'ed. Resistance is futile. / \ / \ / \ / \ / \ / \ Turbo Fredriksson [EMAIL PROTECTED] ( D | e | b | i | a | n ) Debian Certified Linux Developer \_/ \_/ \_/ \_/ \_/ \_/ Gothenburg/Sweden Please always Cc to me when replying to me on the lists. -- smuggle Ft. Bragg kibo South Africa
Re: GPG as a PGP replacement
On Thu, May 13, 1999 at 02:33:49PM -0600, Jason Gunthorpe wrote: On Thu, 13 May 1999, Marco d'Itri wrote: AFAIK this is not needed. The only compatibility options I have in my ~/.gnupg/options file are: I was unable to make it work without the --rfc-1991 argument shrug afaicr, you need --rfc-1991 to make encryption work, but not signatures. Note: You cannot pipe input to gpg and get a PGP 2.x compatible sig. I do that for it.* CFVs and I'm quite sure the signatures can be verified with PGP 2.x. If anyone cares I can provide my generic GPG.pm module for signing and verifying. Well, I tried many many times and went so far as to ask on the mailing list (was told it wouldn't work), never once was I able to make gpg create a signature that pgp 2.6 would accept using a pipe. You might want to double check that your sigs do work.. gpg --clearsign works, gpg --sign doesn't, seemingly. (ERROR: Nested data has unexpected format. CTB=0xCB) (I did gpg --no-options --load-extension rsa --load-extension idea \ --clearsign -u 0x6494661D --secret-keyring ~/.pgp/secring.pgp \ testfile testfile.out) SRH -- Steve Haslam Debian GNU/Linux [EMAIL PROTECTED] gnome-libs, gnome-core, gnome-control-center, gdm, p3nfs.what, me worry? pgpgbrybw4b7B.pgp Description: PGP signature
Re: Splitting debian-devel-changes to separate lists
On Thu, May 13, 1999 at 12:59:12PM +0200, Wichert Akkerman wrote: The topic to split debian-devel-changes in a -$ARCH and -sources list was proposed a while ago. What happened to it and what are the sentiments on splitting it?? I think it's quite high volume because most lists aren't intresting to me, but some are. I've been told that if we used listar for that list we can let subscribers simply toggle flags for what they want to receive. That sounded like a perfect solution to me... in the meantime I'm using this procmail-recipe to filter out binary-only uploads: :0 * ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\) /dev/null A slight mod: :0 * ^Subject:.*\((alpha|arm|powerpc|m68k|sparc)\) * !^Subject:.*source /dev/null -- Joseph Carter [EMAIL PROTECTED]Debian GNU/Linux developer PGP: E8D68481E3A8BB77 8EE22996C9445FBEThe Source Comes First! - * Simunye is so happy she has her mothers gene's Dellaran you better give them back before she misses them! pgpqJ42467fxf.pgp Description: PGP signature
Re: PROPOSAL: preparation for freezes, release coordination
In linux.debian.devel, you wrote: I hope to fix this in the long run by having more frequent releases, so that maintainers are less anxious to get their packages in the upcoming release. In the short term... let's just hope :-) How about creating woody at the freeze announcement instead of at the actual freeze? Then you could rail at new-package uploaders and they'd have no excuses, plus we could compete to be the first uploader.. It would also give the archive maintainers a chance to spread out their workload: freeze would be independent of creating the new distribution area. -Drake
Re: Release Plans (1999-05-10)
On Thu, 13 May 1999, Hartmut Koptein wrote: The OF of my LongTrail works perfectly but i don't know how to set it up for autobooting. Booting from floppy is not (yet) possible (for initrd) because the kernel cannot read the floppy. So net or cd booting are the only choices. assuming it's similar to openboot, set boot-device disk setenv autoboot true are you getting any specific errors reading from floppy? Currently i wait for manoj's update for his kernel-package with my changes. After that, compiling will be easier. But then i need kernel-diffs for apus, pmac, prep and also mbx for the 2.2.x tree. Which class is rs/6000, chrp or prep? no offense intended, but you'd probably be best holding off till i get my images/source done for the rs/6000 against 2.2.6 or 2.2.8. 2.2.8 after looking at the code, will *not* boot on any rs64 (i had 2.2.6 booting on single rs64 in 32bit mode). the problem is in cort's code; it's simply not rs64 ready. and barely 604e rs/6k ready. i will HOPEFULLY have this done by the end of tomorrow. i broke gcc early last week, and finally got it fixed today, so soon. very soon. as to chrp/prep, most are neither. s70's are chrp, but s70 advanced servers don't appear to be. h70's are chrp as well. f50's i still haven't figured out. *some* f40's are chrp. (only single cpu f40's from what i can tell so far.) what i really need is *physical* access to rs/6000's to tell. gotta get into the openfirmware via aix to figure out what platform it is. and then from there, it's generally very easy. btw, i am working on smp support.. i have dual on f40 non-chrp, but single on everything else still. give me a few months on that. ;) -Phillip R. Jaenke, Head Unix Guru, Unicent Telecom 216-344-2603 / 9a-~5p Eastern - PESTER ME!
Re: Release Plans (1999-05-10)
Richard Braakman [EMAIL PROTECTED] writes: We have a long history of overly optimistic freeze dates :-) I'd like to try something else this time. I note, though, that if we do manage to freeze on July 1, we'll be able to have a release in time for the Linuxworld Expo in August. That would be cool. I'd like to point out that expecting freeze to be shorter than 10 weeks is lunacy. We have 5 architectures now Consider that archive changes at any point in freeze imply changes in boot floppies (well, for anything in base) and in the CD system. -- .Adam Di [EMAIL PROTECTED]URL:http://www.onShore.com/
