Apology for MIA, Retiring, RFA: x-symbol, xmix, oneko
I haven't had time for Debian in a long while - I've held on for a while because I've enjoyed working for Debian, but I don't think I'll find time again. Now I'm renovating a house and have switched to OSX, so it's time I move on. I'm truly sorry that I have neglected my packages for so long. I'd like to offer these three packages for adoption: x-symbol, xmix, and oneko. x-symbol is probably the most used of these and needs someone who knows emacsen and a little TeX. The others could probably disappear without anyone noticing. Steve Dunham [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Apology for MIA, Retiring, RFA: x-symbol, xmix, oneko
On Jan 15, 2006, at 8:58 AM, Steve McIntyre wrote: Steve Dunham wrote: I haven't had time for Debian in a long while - I've held on for a while because I've enjoyed working for Debian, but I don't think I'll find time again. Now I'm renovating a house and have switched to OSX, so it's time I move on. I'm truly sorry that I have neglected my packages for so long. I'd like to offer these three packages for adoption: x-symbol, xmix, and oneko. I'll happily take xmix, as I use it myself... It's yours. I've already filed a wnpp bug (#348196) to orphan it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal to package propsel
Charles Briscoe-Smith <[EMAIL PROTECTED]> writes: > I just saw this on c.o.l.a. and want to package it: > Title: propsel > Version:27-Nov-1997 > Entered-date: 27-Nov-1997 > Description:propsel is for people who work with more than a single > X11 display on their desk. It allows one to paste into a > xterm on one display the contents of the selection of > another display. > Keywords: selection, X11, multi > Author: [EMAIL PROTECTED] (Amit Margalit) > Maintained-by: [EMAIL PROTECTED] (Amit Margalit) > Primary-site: ftp://hishome.net/pub/propsel/ > Alternate-site: N/A > Original-site: N/A > Platforms: gcc, X11R5. > Copying-policy: GPL > Any objections? You might want to take a look at x2x also. It passes selections and allows you to use one mouse and keyboard with both displays. I have a copy of the latest version at: http://www.cps.msu.edu/~dunham/out/x2x-1.26.tar.gz I originally got it from: ftp://gatekeeper.dec.com/pub/DEC/SRC/x2x/x2x-1.26.tar.gz Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
dpkg help wanted
I'm preparing the new version of amaya. (I believe it's ready except for this one final detail.) The version I'm releasing is amaya_1.1c-1, it is going into the "web" section of hamm (main distribution). I want it to be an upgrade path for the following: amaya-static_0.95-1 amaya_0.95-1 thot-common_2.0b-1 Which are in non-free. I need the following to happen: 1. If a user has "amaya-static" or "amaya", dselect should replace it with "amaya" 2. If the above is true, thot-common is installed; I want dselect to remove it (and not allow it at the same time as the new amaya). 3. The ftp site puts the new package in the correct location. What exactly do I need to do to make this happen. I'm thinking something along the lines of: Conflicts: thot-common Replaces: amaya-static in the amaya part of the control file, and Section: web at the top of the control file. Will this do the trick? Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Paranoia, "pristine sources", turnkeys, compiling, configuration
David Welton <[EMAIL PROTECTED]> writes: > You might have a look at how Free and Open BSD do things with their > ports system. It doesnt seem that attractive as a package management > system (try installing Xemacs over a 28.8 on a 486;-), but it is done > quite well, and with standard unix tools. It has provisions for > dependencies and the like as well. I would like to look at their > binary package tool as well, but it dumps core on my 2.2-RELEASE > Fbsd... Ahh, but judging from recent posts to USENET, "ports" seems to be more of a system for "source package" management than package management. And our source packaging could use some revamping anyways. (I'd like multiple .tar.gz files and multiple diff files, for example.) (As far as I can tell from USENET, their binary packages are similar to Slakware.) If anyone decides to work on a better source packaging system for Debian, they probably should look at "ports" for some ideas. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Deselect problems.
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Mon, Jan 05, 1998 at 08:59:50AM +0800, Lindsay Allen wrote: > > The kernel-source-2.0.32 deb has a 130K diff file against the standard > > source. Just where do these patches come from and why are they necessary? > > > > Is the fact that I _have_ to have 2.0.32 source or headers going to stop > > me from going to 2.0.33? > I don't know why all those patches are already applied. I have stopped > using the kernel-source packages because they can't be patched > up to the next kernel version easily (because of the already applied > patches). You should be able to install kernel-headers to satisfy it > and then dump the standard Linux source tree in for building kernels. Does anyone know why there is a dependency on kernel-headers? I was under the impression that glibc didn't use the kernel headers. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
xtar, xtar-smotif, xtar-dmotif orphaned
The source package "xtar" and resultant binary packages "xtar-smotif" and "xtar-dmotif" are now orphaned. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: interactive sound configuration utility
Hamish Moffatt <[EMAIL PROTECTED]> writes: > I understand that the modularized sound drivers are now standard > on Linux 2.0.32 and above. Given that, I think it would be good > if we had a setup utility for sound, like the one provided > with OSS/Linux. Hmm, I didn't know this was in 2.0.32. I'll have to look again. I don't seen it in 2.0.33. It is in the later 2.1.7x series, but they break dhcpcd. I'd like to get my sound chip working properly (I have a hack that makes it work), but I'm waiting for modular sound drivers. > Redhat have a sndconfig to go with the modularization patches > (which they sponsored according to their web site). The latest > sources were only in RPM format, the tar.gz was old, but I managed > to battle with rpm long enough to extract them. (Conspiracy > theories anyone?) It's not that hard. You "install" the source package with "rpm", and pick up the pieces in /usr/src/redhat. > Anyway it seems that sndconfig just probes for PnP cards with > isapnptools' pnpdump and configures them, and only supports SB > cards anyway. It'd be nice to have (I may work on a package(*)) > but it isn't exactly what I want. Does anyone know of anything > like this somebody is working on, or are there people interested > in working on it? I'm interested in working on getting the YM715 chip working well. It is the one that comes on the Intel AL440LX "Atlanta" motherboard. It needs better driver support because of IRQ sharing and weird names for mixer device, and it needs isapnp (or a kernel-space equivalent) to configure it. > (*) Their manual page says that sndconfig configures sound on > the Red Hat Linux system. Is it ok to change this if the software > is GPL? Otherwise it would look strange. If it's GPL. And Red Hat says any software they write themselves will be GPL'd. Aside from this, we should try to keep ours as close to theirs as possible so we can pass improvements back to them. Steve [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: dpkg memory usage
John Goerzen <[EMAIL PROTECTED]> writes: > I was upgrading packages on my 64 meg system today ant noticed: > PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND > 24785 root 18 0 12680 12M 568 S 0 0.1 20.0 5:36 dpkg > Yes, that's almost 13 megs used by dpkg, and 20% of my RAM. > That also is 4 megs more than the TOTAL amount of RAM in some computers I > work with. > So...why must dpkg use almost as much memory as XFree86 itself, and MORE > than Netscape does at times? > Not only that, but it is hideously slow even on current computers. My > suggestion: store the databases in a DBM format of some sort instead of > plain text. IMHO, dpkg should be using a DBM database for file -> package lookups and perhaps for the "status" and "available" caches too. (I believe apt does something like this for "available".) (I presume that dpkg actually does use hash tables internally, but it recalculates that 12MB of data everytime it starts up, which, IMHO, is not very efficient.) The startup time and memory usage is just not worth any benefits gained from using a few thousand text files. And the text version is still prone to severe corruption. Mine was scrambled the other day when I upgraded the modutils package running a 2.1.x kernel - the machine locked up, and when I rebooted and tried to install more packages, dpkg mixed up a bunch of scripts and .list files. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Anyone want to make a Debian XDM login screen?
"Marcelo E. Magallon" <[EMAIL PROTECTED]> writes: > On Mon, 13 Apr 1998, Frederic Peters wrote: > > > background where you type your login/password have to be in > > only one color, no pixmap. Except that fact, I think a login > > screen with only xdm (+xloadimage) can be really cool. I am ok > > to make a great login screen. For graphics, I am not the man. > > Why not call for graphics from the web site like when we were > > looking for a logo ? That's all. > you may want to take a look at login.app, that just uploaded. login.app is not an xdm replacement. xdm handles remote sessions too. I would really be disappointed to see Debian using Login.app instead of xdm. Some choices here are: 1) A modified version of xdm-external+gtkgreet (from the web site mentioned earlier in this thread. 2) Some (tasteful) X banner stuff in the background of a normal xdm screen. They both would be easy, but with the first option I would be concerned by the rapidly changing state of the gtk libraries. (Red Hat is basing some gui apps on gtk, so users are unable to install newer versions of the gtk libraries without breaking these apps.) If the second option is chosen, the designer should make sure that the it works on 640x480 screens. (Some people still use 640x480 laptop computers - this causes problems with some software, including the electronic eyes "About" box.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhcpcd
Joey Hess <[EMAIL PROTECTED]> writes: > A long time ago, you wrote: > > Is dhcpcd still up for grabs? If so I'd like to take over the package > I asked you once before if you still intended to make a new upload, you said > yes, soon, but I'm still listed as the maintainer. Dhcpcd has some bugs that > need looking at - are you still planning to maintain it? dhcpcd_0.70-3 has been sitting in Incoming for about a month (well, since march 28, and I touched the changes file about 5 days ago, hoping it would help...) 0.70-3 has the patches from the Bug system applied, has been made lintian-clean, and has me listed as the maintainer. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg memory usage
Ian Jackson <[EMAIL PROTECTED]> writes:
> It's mainly because the access method you're using is (I surmise)
> reinvoking dpkg each time. That involves loading the more robust data
> structures in /var/lib/dpkg/info into a fast-to-access in-core format.
It's mostly when I invoke it on the command line that I notice this.
(When I ocassionally do a "dpkg -i", "dpkg -e" or "dpkg -S".) I use
rpm on some of my systems, and it always surprises me how quickly the
commands return because I'm used to dpkg.
> I also intend to change the format of the /var/lib/dpkg/info/*.list
> database to make it faster to load, and I may change
> /var/lib/dpkg/status too. (The resulting structures will still be
> editable with emacs.)
>From an academic standpoint, I'm interested in knowing what you have
in mind here. I think a single text file would be noticably faster
than a bunch of *.list files, but I don't know how much time is spent
on I/O and how much is spent on building data structures in memory.
(It would save the time of scanning the directory, opening and closing
all the files.)
> Using a dbm file or something is fine if you just want read-only
> access. However, they're no good for updating, because such systems
> do not have sensible behaviour on filesystem failures like disk full -
> they can't be updated atomically. You end up having to read
> everything in and rewrite the whole database after every update.
Ok, I'll concede this on the atomic and error handling points. I
didn't know that dpkg was designed that robustly.
I guess a libdpkg would fix the startup time issues and if I want
"dpkg -S" to work faster, I can always write a perl script that does
it, caching the information in a DBM hash that it rebuilds on demand.
> Steve Dunham writes ("Re: dpkg memory usage"):
> > And the text version is still prone to severe corruption. Mine was
> > scrambled the other day when I upgraded the modutils package running a
> > 2.1.x kernel - the machine locked up, and when I rebooted and tried to
> > install more packages, dpkg mixed up a bunch of scripts and .list
> > files.
> I think this was probably a simple kernel bug. dpkg cannot defend
> against your kernel scrambling its filesystem data structures. It
> does ask the kernel to confirm that changes have been committed to
> disk before it continues.
The crash was a kernel bug. After the system came back up there were
files left in /var/lib/dpkg/updates. When I tried to run dpkg after
that, it complained about two of those files being corrupt, so I
deleted those two and left the rest.
My guess was that the corruption was related to those files being left
in the updates directory, does this make sense? What would happen to
dpkg if stuff was left in there? (The filenames were just numbers,
from 1 to 12 I believe, I deleted 10 and 11.) That's why I suggested
that dpkg mixed them up, although it could be a matter of the
directory not being correct.
Anyways, I did a "ls -lart" of the info directory, renamed some stuff
and reinstalled the effected packages, and it seems to be recovered.
(If I had a local copy of the Debian archive, I could have rebuilt all
of the info directory using the status file.)
Don't take any of this the wrong way. dpkg is a great program; you
did a damn fine job with it. The startup speed issue is only a minor
one. The only real issue I have with Debian packages is interactivity
and this isn't the fault of dpkg.
Steve
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gnome debs?
Herbert Xu <[EMAIL PROTECTED]> writes: > In article <[EMAIL PROTECTED]> you wrote: > > I checked, Debian and Red Hat were not compatible. (e.g. libpng and > > libjpeg have different sonames.) > How did this happen? Shouldn't we try to rectify this ASAP so that there is > binary compatibility? One small correction: the libpng issue wasn't a soname problem, RedHat's libpng.so wasn't explicitly linked against libz.so, so Debian programs _might_ not run on RedHat (without an LD_PRELOAD), but RedHat programs run fine on Debian. The soname issues are with libjpeg, libgdbm, libncurses. DebianRedhat == libjpeg.so.6a libjpeg.so.6 libgdbm.so.1 libgdbm.so.2 libncurses.so.3.4 libncurses.so.3.0 One other problem is that libcompface is static on Red Hat and dynamic on Debian, but this library is rarely used. (All of these were discovered when I tried to move a "stow" tree of XEmacs Beta 20.5 from a Debian system to a Red Hat system.) For now, most of these issues can be resolved by using symlinks. But sonames should be synchronized with Red Hat in the future. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Synchronised sonames (was: Gnome debs?)
Shaleh <[EMAIL PROTECTED]> writes: > Only if we are wrong. We should endeavor to do what the upstream > maintainer does unless it is flat wrong. We are not RH, maybe they > should make their sonames match ours. No, we should both do what is > right. I definitely advocate following the upstream maintainer (although there are a few borderline cases, e.g. Imlib, which changed data structures between 1.2 and 1.3, but kept the soname the same.) My libgdbm.so.2.0.0 seems to be left over from some earlier version of the package - it's dated 1996 - I suspect it's a libc5 file that I manually installed during the fiasco with perl and bash moving to libc6. I don't know about the jpeg issue. Does the upstream maintainer advocate a soname of libjpeg.so.6a rather than libjpeg.so.6? What about ncurses? Does upstream use soname 3.0? I suspect that Red Hat kept the 3.0 soname for the latest libncurses because it is binary compatible with version 3.0. It would be difficult for either Red Hat or Debian to fix it at this stage in the game (both Debian and Red Hat could add symlinks to help with the problem, though), but an effort should be made in the future to prevent this from happening. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: on forming a new Linux Distribution
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On Wed, 29 Apr 1998, Bruce Perens wrote: > As I see it there are two major problems that preclude using APT with RPM > as it stands, > 1 - They don't actually have package dependencies. They have > dependencies on files - big difference. > 2 - They seem to lack a well formed index file, I couldn't find any > rpm index on their ftp site. They have _both_ package dependencies and file dependencies. In fact, earlier versions of RPM only had the package dependencies (e.g. Red Hat 4.2). I know, I've recently made .rpms of "texk" which had package dependencies. (I wanted pdftex.) The file dependencies are automatically generated, and they are used for shared libraries and binaries needed by install scripts. > I took a -VERY- quick look some time ago, at first glance everything else > seemed about on par with dpkg. But if they are true, those are two very > major problems. The only real problems that I see are: 1. no alternatives or diversions mechanism 2. some problems with default configuration file handling I believe I know how #2 can be handled with a small patch to RPM (changing one constant), and for other problems the developers are very active and open to suggestions. > It might be smart to fork rpm (call it something else) and re-do the > header fields to be more sensible, then use APT to provide understanding This would be bad. Especially since RPM is a cross platform standard: people are using rpm to install packages on Solaris machines and many other commercial Unix platforms. > of the fields and use librpm for the actuall installing. Then you get all > the benifits of Debian's dependency system and the benifits of APT's > ordering sequencer, dependency engine, multi-source handing, (and > someday it's GUI too). > If #1 is really true there is zero point in making APT understand RPM, > 90% of it's functionality would have to be disabled. It's not true. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: on forming a new Linux Distribution
Raul Miller <[EMAIL PROTECTED]> writes: > > 2 - They seem to lack a well formed index file, I couldn't find any > > rpm index on their ftp site. > Presumably, this could also be addressed by work. [Since it's not > specific to the rpm format, but the rpm site.] There is an index file in the installation tree (RedHat/base/hdlist), and a program to generate it. The file format is concatenated headers, which is very easy to load into librpm for dependency processing, etc. This format could also easily be used for contrib trees, etc. And it is much cheaper to generate than the Debian "Packages" files currently are. (Last I checked, this required a md5sum of every package.) But this should be discussed on rpm-list, not debian-devel. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Gnome debs?
David Welton <[EMAIL PROTECTED]> writes: > On Mon, Apr 20, 1998 at 03:13:24PM -0400, [EMAIL PROTECTED] wrote: > > GNOME is currently not very stable and things are changing very > > rapidly. Jim Pick is the GNOME guy for Debian. Give it a few more > > weeks and I think you will see more. > The thing I was wondering about is getting support in their build > scripts for debs. Every morning they get some rpm's generated > automatically. I was wondering if it might be feasible to do this to > make some debs too, or if it would be just a waste of time:-/ CVS the relevent gnome packages to your system. Add a /debian tree to each package. Write a script that does a cvs update of each dir, a debian/rules build in each dir, and puts the packages up for ftp. Put the script in a cron job and you have it. There doesn't need to be support in their build scripts for DEBs, AFAIK the rpms are built by a third party, I don't even see any .spec files in the CVS tree. Either way, the people who build the RPMs can't build DEB files. Last I checked, Debian and Red Hat were not compatible. (e.g. libpng and libjpeg have different sonames.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Time to say goodbye...
Christian Schwarz <[EMAIL PROTECTED]> writes: > PS: The Linux community will not lose me! I'm planning to join Bruce' > effort to set up a new base distribution. If Debian should decide to > support the new base distribution, too, perhaps I could act as person > of contact for Debian. You should also keep your eye on the Red Hat Contrib Net (RHCN): ftp://ftp.redhat.com/pub/rhcn/charter which shows some promise. Red Hat is trying to set up a contrib system with signed packages, quality control, designated developers, etc. If it takes off, it would be promising source of non-base packages for both Bruce's project and Red Hat Linux. Most of their policy hasn't been set yet to the detail that Debian's is, other than a statement that maintainers have to be responsible for bugs and are responsible for arranging that their packages are available on as many platforms as possible. I've encouraged them to look at Ian's bug tracking system, which I feel would be well suited for a project like that. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Non-interactive install proposal
Andreas Degert <[EMAIL PROTECTED]> writes: > Manoj Srivastava <[EMAIL PROTECTED]> writes: > > Drake> On Tue, Jun 02, 1998 at 09:48:46PM -0500, Manoj Srivastava wrote: > > >> > > >> What is the benefit of keeping packages in an unconfigured > > >> state? > > Drake>It's a reminder to me that I need to configure this package > > still. > > I prefer the approach to ask questions first, and configure as > > it installs. If we are spending time to do this, we should do this > > right. > In general, you can't ask all questions first; you can ask some > questions, then unpack and debian-configure the packages, but then you > still have to do a lot of configuration (using an editor or some > configuration programs that "ask questions"). Why not? If we provide a way for a package to say: I need this information to configure myself, a program could then take the list of needed information from all the packages (what dictionary language do you prefer, what is the timezone, what keymap, do you want a color xfig, etc.), compare it to an optional database of the information, and ask the user for the missing information before the install. More complicated packages that need very interactive configuration, like X, sendmail, etc. should: * Allow the user to provide the configuration file (sendmail.cf, XF86Config) ahead of time. and * If the file doesn't exist, schedule, via some yet to be determined mechanism, for the interactive configuration program to be run after the install. (So the "package" xbase would be "configured", allowing dependent packages to be installed, but "config_xserver" would be in the queue of pending interactive configuration programs.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Differences of Debian vs. the Other Guys
Tyson Dowd <[EMAIL PROTECTED]> writes: > On 03-Jun-1998, Joel Klecker <[EMAIL PROTECTED]> wrote: > > At 23:38 -0700 1998-06-02, Tyson Dowd wrote: > > >Manoj addressed most of the big differences in his mail. One that he > > >missed (or glossed over) is the difference in generation of packages. > > Another one is that he didn't explain what dpkg-shlibdeps does. > > >dpkg encourages (practically enforces) building a package in a working > > >directory, installing files to a temporary directory, and packaging > > >from that directory. > > > e.g.configure --prefix ./debian/tmp > > > make > > > make install > > > package up ./debian/tmp > > >is what the debian/rules file says. > > That isn't the right way to do it, the executables may end up depending on > > being run from the same directory as the one they were built with (in > > practice, it doesn't seem that too many packages are like that, but it's > > good to keep it in mind). > Oops, sorry, you are of course correct. FYI, most RPM packages do this now too. (Except that the temporary install directory, called a BuildRoot, is usually stored somewhere under /tmp and it's location can be specified at build-time.) When I build RPM files, I usually end up specifying: %attr(-,root,root) /usr as my files list. (The extra magic at the beginning allows me to build as an ordinary user.) I agree that the old RPM way was hideously broken. (And this rather moot here, since we don't use RPM, and if we ever did, we would most likely rewrite the build process.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Building apps for a pilot
Dermot John Bradley <[EMAIL PROTECTED]> writes: > I'm a newbie to the Pilot (haven't actually bought one - waiting for the > Palm III to arrive in the shops). > I see there is now a binutils for the pilot and I've seen mention of using > GCC to cross compile for the 68000. Surely to build apps for the Pilot > would require libraries supporting the PalmOS's windowing environment > (i.e. display image, open window, etc). Are these available for Linux? They will compile on Linux, but are not packaged for Debian yet. Look for the prc-tools package: ryeham.ee.ryerson.ca:/pub/PalmOS/prc-tools.0.5.0.tar.gz I have a binutils package for Debian that is ready except for the /usr/doc stuff (Readme, copyright, etc.) But I haven't done a gcc one yet. I'm been rather busy lately. :( The windowing environment uses something similar to Linux syscalls, which are handled in include files. Steve [EMAIL PROTECTED] -- E-mail the word "unsubscribe" to [EMAIL PROTECTED] TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to [EMAIL PROTECTED]
Re: reliable streams over UDP
Shyamal Prasad wrote: Russell> Surely someone must have written something similar to TCP Russell> but implemented on top of UDP. Too many people have tried this ;-) Try SCTP, a recent attempt to deal with the "reliable UDP" solution: The 2.5.50 kernel has a SCTP implementation. Dunno how well/if it works, but the option is there. Steve [EMAIL PROTECTED]
Re: racoon ISAKMP implementation for IPsec
Noah L. Meyerhans wrote:
I just downloaded the latest upstream source for the iputils packages
and noticed that they it now contains quite a bit of IPsec code. In
particular, this includes libipsec and racoon. Racoon is the KAME
ISAKMP (IPsec key exchange protocol) implementation. I haven't
investigated further, but considering the upstream author's involvement
in Linux kernel network development, I'd take this as a sign that racoon
will be the "official" ISAKMP implementation for the recently merged
kernel IPsec code.
I haven't seen any mention of racoon on this list, nor in wnpp. The
iputils release notes indicate that racoon will eventually be moved to a
separate source package that should be packaged separately from the
iptuils Debian packages. I will maintain the racoon and libipsec
packages, since I haven't seen any sign of other people offering to do
so.
If I missed an ITP, please let me know.
No ITP, but I did manage to get this to compile against the 2.5.50
kernel source tree. It seems to work, but the other side of my
tunnel is down at the moment (he upgraded his kernel but didn't
rebuild freeswan).
You'll also need the setkey program from iputils to do IPSEC. Both
of these (and the library) need headers from a recent kernel source
tree.
I've attached my changes to get racoon to compile, in case you're
interested. Mostly tweaks because our glibc has functions that
the source doesn't think __linux__ has.
Steve Dunham
[EMAIL PROTECTED]
--- iputils.orig/racoon/grabmyaddr.c2002-11-08 18:20:56.0 -0800
+++ iputils/racoon/grabmyaddr.c 2002-11-30 22:26:43.0 -0800
@@ -37,8 +37,8 @@
#include
#if defined(__FreeBSD__) && __FreeBSD__ >= 3
#include
-#endif
#include
+#endif
#include
#include
@@ -79,6 +79,12 @@
#endif
#ifdef __linux__
+#include
+__u32 nl_pid;
+int nl_rescan;
+#endif
+
+#if 0
/* We could do this _much_ better. kame racoon in its current form
* will esentially die at frequent changes of address configuration.
@@ -93,10 +99,8 @@
struct sockaddr_storage ifa_addrbuf;
};
-#include
-__u32 nl_pid;
-int nl_rescan;
+
static int parse_rtattr(struct rtattr *tb[], int max, struct rtattr *rta, int
len)
{
--- iputils.orig/racoon/pfkey.c 2002-11-08 15:25:14.0 -0800
+++ iputils/racoon/pfkey.c 2002-11-30 22:17:59.0 -0800
@@ -36,7 +36,7 @@
#include
#include
-#include
+/*#include */
#include
#include
Re: Need other languafes then english, german and french
Michelle Konzack wrote: Hello, Normaly I am using in my~/.baschrc 'export [EMAIL PROTECTED]' and it works quiet well. Same is for the french users. The tr_TR is half readable. Now I like to use setings for 'fs_ IR', 'ar_SY' und 'ar_MA'. I get a very funny screen... ;-)) Where are the console fonts ??? I have found something for X but nothing for the console... The most important thing is mc... There appear to be some console fonts in the "console-data" package. Take a look at: /usr/share/doc/console-data/fonts/README and the other files in that directory. You will have to switch fonts depending on what locale you are using. The command: locale -ck code_set_name charmap can tell you what charset you need to use. Viel Glück, Steve Dunham -- [EMAIL PROTECTED] http://www.cse.msu.edu/~dunham
Re: project: vitual partial mirror with CGI/dpkg-repack
Wouter Verhelst wrote: On Sun, Dec 08, 2002 at 05:30:13PM +0100, Bill Allombert wrote: I will not do it myself since I know nothing about CGI programming, CGI programming is easy to learn ;-) CGI scripts or programs get whatever the client sends on his URL, starting after the '?' as a parameter, receive on their stdin whatever a client sends using an HTTP PUT statement, and send the HTML and, if necessary, extra HTTP headers to their stdout. That's it. The rebuilt package is likely to have the wrong md5sum. I believe apt will reject it after download. -- Steve [EMAIL PROTECTED] http://www.cse.msu.edu/~dunham
Corel Network Computer Port
Does anyone have any definite information on the Corel Network computers? Is anyone else interested in doing a Debian port? The pictures of these machines look really sexy, and I've heard that rumors that they have decent performance and near $1k prices (with video input and two ethernet ports). If I could get something for around $1k that I could port Debian to, I'd be very tempted... Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corel Network Computer Port
Jim Pick <[EMAIL PROTECTED]> writes: > Joel Klecker <[EMAIL PROTECTED]> writes: > > At 21:20 -0700 1998-06-05, Steve Dunham wrote: > > >Does anyone have any definite information on the Corel Network > > >computers? Is anyone else interested in doing a Debian port? > > Vincent Renardias is apparently working on an arm port of Debian (In bug > > #21327 against ftp.debian.org, he asks for a binary-arm section). This is > > the processor that the Corel NCs are based on, right? > Yep. > The source is available at www.netwinder.org > I bet we could brow-beat Corel into donating a few boxes. I heard > they go as cheap as $300 US for a diskless configuration. It's all just rumors, I've heard nothing back from them. We might have to brow-beat them into selling boxes. > I'd love to get one to play with. :-) Me too. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corel Network Computer Port
Jim Pick <[EMAIL PROTECTED]> writes: > Behan Webster <[EMAIL PROTECTED]> writes: > > They are only giving discounts to OCLUG members, but since I'm in OCLUG, > > I could probably approach the appropriate people to do some enquiries. > > I wouldn't hold your breath though. OCLUG is very RedHat based. > I've talked to some of the Corel guys on the phone before, and they > seemed very reasonable and open-minded. > Basically, nobody has sold Corel on the potential of OEM vendors using > Debian. They've just been listening to Red Hat and their convincing > story of how they are making megabucks, and the sales channel that is > already in place there. I'd like to see the Corel Computers used as generic cheap Linux Computers. They are reported to be fairly cheap, perform reasonably well and have lots of neat I/O features. (NTSC in/out, 2 ethernet ports.) When/if they are ready and Corel doesn't want to sell them directly, someone like varesearch or linuxmall could be convinced to become resellers. (Or even Red Hat would be interesting...) > > How many developpers are we talking here? Last I heard they were > > looking for a few good hackers, especially kernel hackers. They still > > have kernel features that they would like to see implemented too. Maybe > > I'm opening a pandora's box here, but which Debian Developpers are > > interested in getting access to or buying a netwinder, etc? (Last I > > heard Corel is thinking of $1000 (CDN I think) per netwinder). > Sign me up - I can come up with $1000 CDN no problem. I'm interested in buying one too. Are they actually selling them yet? Behan's message contains the seemingly contradictory statements that Corel has gotten them out the door and that they haven't even set a price yet. If software is the only remaining issue (i.e. hardware is finalized), I'd be happy with something that runs and can be bootstrapped off of the net, with a promise of the completed software on CD when it becomes available. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: VI reasons (was Re: Base Set: Suggested additions & removals.)
Jason Gunthorpe <[EMAIL PROTECTED]> writes: > On Thu, 11 Jun 1998, Hamish Moffatt wrote: > > > > Tried booting from a floppy created with dd? > > > > Same problem, if memory serves correctly. Will check it out asap. > Upon reflection it occures to me that there are two other possibilities > 1) The bios calls to access high memory make it so that the kernel routine >to do (page table setup?) reboots the machine > 2) It does not get properly copied to the 1 meg location and reboots >because it executes random memory during decompression. I'm told problem is related to turning on the "A12 Gate" and the cache. It was never explained to me in detail, but it has something to do with the cache having the wrong contents (or rather the wrong tags on the contents) after the A12 line was set. It was never clear to me why they couldn't just clear the cache after turning on the A12 gate. You could ask on the kernel list. LILO, ldlinux.sys, and the built in boot block (dd) exibit the problem. Grub can boot them just fine. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: APT 0.0.16
Paul Seelig <[EMAIL PROTECTED]> writes: > [EMAIL PROTECTED] (Jason Gunthorpe) writes: > > > APT 0.0.16 is available for both bo and hamm. Please let me know if there > > are any bugs that got missed, I'm getting very few bug reports these days. > It is running pretty fine, but there is one thing i personally find > very disturbing about it. When using apt to retrieve newer .deb > packages from a Debian site it simply deletes the downloaded files > after having installed them and doesn't bother asking first. :-( That's just the "dselect" interface. I'd suggest, after selecting packages, that you go back to the command line and type: apt-get dselect-upgrade (You might need a "-f" if you have dependency problems.) I use the "apt-get" for everything but mass package selection. (When I want to add a single package I just do apt-get install package_names_here it fetches the package and all dependencies from the appropriate servers and installs them. > Whenever i download a .deb file i usually prefer to keep them around > for possible future use, but apt is not very cooperative in this > regard. Sure, i could recreate the .deb files using dpkg-repack but i > don't feel really comfortable with this option since it can't really > recreate the original. As I pointed out above this is actually a problem with the apt "method" for dselect. You should file a bug report against apt saying that they should prompt before running "apt-get clean" in the apt method of deselect and use the command line version until then. I do have a feature request for apt: I would like to see a command line interface to query the apt available cache. At the very least it should have something like "dpkg -l", listing all of the available packages, with the one-line description and have another option like "dpkg -s" that lists the detailed information for one package. BTW, for people who are interested, if you carefully (with -p) untar base2_0.tgz, chroot into it, install: apt, perl, libio-stringy-perl, libwww-perl, libmd5-perl, mailtools, and libmime-base64-perl. (Note that it is libmime-base64-perl, not libmime-perl.) Exit the chroot environment, tar it back up and you have an "apt-enhanced" base set. (You might also want to remove qftp, or install libg++272 to resolve a broken dependency.) The resulting file is 10688349 bytes long. (Verses 6866910 bytes for the original tar file.) There is some unncessary stuff from the perl package, but this is good enough for NFS, hard drive, and CDROM installs of the base. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Dale Scheetz <[EMAIL PROTECTED]> writes:
> On Thu, 11 Jun 1998, Enrique Zanardi wrote:
> > On Thu, Jun 11, 1998 at 09:41:03AM -0400, Dale Scheetz wrote:
> > > The problem is that the Debian installation kernel tries to be all things
> > > to all people. As there are machines that boot from SCSI drives, it was
> > > necessary to have all the scsi controlers "built in" to the kernel, hense
> > > its large size.
> > > We should recommend that everyone, once they have a standard system and
> > > can build a kernel, should build a custom kernel for their machine as
> > > early as possible.
> > > Another solution is the one that slackware provides. They build a "bunch"
> > > of kernels, each one for a specific hardware configuration (broad enought
> > > to cover a range of hardware, and chosen to keep incopatibly drivers out
> > > of the picture {like the wd9000 driver that plonks ethernet cards})
> > I'm working on a better solution that involves using initrd to
> > load the required controllers (built as loadable modules). I've tested
> > using initrd for lowmem installations and it works flawlessly (just have
> > a look at lowmem boot disk in boot-floppies_2.0.7 when I upload it next
> > weekend).
> I have wondered why we didn't try this once the kernel supported initrd.
> To be honest I haven't figured out yet how to do the device selection,
> other than going through a list of drivers, trying to insmod each one
> until you are successful.
Red Hat does this, we might want to look at their code. (Even after
the install you end up with both a kernel and an initrd image
containing the exact drivers you need in /boot - they mainly use this
for SCSI drivers - they might also do PCMCIA SCSI there, but I'm not
sure.)
They have a script to rebuild the initrd for newly compiled kernels,
but I usually just compile the drivers in.
> I would love to see your solution for this, even in whatever the current
> state is.
IIRC, they do some of the device selection via /proc/pci. I believe
they do this for ethernet and Video Cards too (to select the right
server) - if it's unsuccessful, you are presented with a list.
I know UltraPenguin probes the PROM tree for the video cards (again to
select a server), because I sent in a patch for the cgfourteen.
IMHO, the Debian install should detect as much as possible from
/proc/pci (and proc/openprom on the Sparc), and do automatic
configuration from this wherever possible.
> > Using initrd, our default kernel may be reduced to half its current size,
> > as all those different controllers may be built as modules and only the
> > required ones will be loaded at boot time. That will save our users a few
> > hundred KBs of RAM, and will make building a custom kernel a not so
> > needed step.
> Yes, this would be a great improvement over the current situation, making
> the installation kernel appropriate for a system kernel with no
> rebuilding.
It would also make new kernel packages available to a wider audience.
(At least some of those who compile their own may be less likely to.)
Steve
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bootint big kernels
Enrique Zanardi <[EMAIL PROTECTED]> writes: > On Thu, Jun 11, 1998 at 11:45:56AM -0500, Martin Alonso Soto Jacome wrote: > > Dale Scheetz <[EMAIL PROTECTED]> wrote: > > > I have wondered why we didn't try this once the kernel supported initrd. > > > To be honest I haven't figured out yet how to do the device selection, > > > other than going through a list of drivers, trying to insmod each one > > > until you are successful. > > > > Wouldn't PCI and ISA PnP support help here? Standard 2.0.x kernels support > > /proc/pci since a long time, so it should be possible to check the device > > names on /proc/pci against a table in order to load the apropriate modules. > > > > That's what Red Hat does, and what I plan to implement for slink. It > doesn't work for ISA cards though, therefore I plan to implement a method > for manually selecting modules at install time as well (probably a > modified "modconf"). You should boot the FreeBSD install disk once for ideas too. > > It should also be possible to deal with PnP just the same way, > Yes, but we will have to create the "device -> module" table from > scratch, as I don't know of anyone that maintains such a table. The only isapnp devices I know of are audio. Are there any SCSI or enet devices? (If so a table would be necessary as they are discovered.) Digging through INF files in windows 95 would be a start. This is something that should be closely coordinated with the ISApnp utilities. > > although I > don't know what the status of the PnP support in the > kernel is right now. > None AFAIK. PnP devices are configured with user-space tools (pnpdump and > isapnp). There is a kernel patch to initialize them, and I have a patch to GRUB to pass the right magic to the kernel patch, but I don't use it right now. (Not necessary, since my only ISApnp device is not critical to booting.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Volunteer(s) wanted to help with owner@bugs.debian.org
"James R. Van Zandt" <[EMAIL PROTECTED]> writes: > I'd sure like a mechanism, with either email or a browser, to get a > list of the bugs registered against a particular package. It would > help cut down duplicate bug reports. Now, I'm forced to download a > list of *all* the bugs. What about http://www.debian.org/Bugs/db/ix/packages.html? Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: just Dumb
Ray Kinsella <[EMAIL PROTECTED]> writes: > Er, > > Hey all, I have a a few small problems, > > I was messing about today on irc.debian.org doling out tech support while > playing around with apackage called Dumb it is a free Doom Graphics > engine. Anyway I got it to compile after some light source hacking and it > works well under X. > So I hear you say wonderful, send it on to us, we will have a look > Now unfortunately, its not that simple, I can't can't maintain the package > becos' my access to an Alpha Linux Box will shortly be coming to an end > and also unfortunately ( even though I use debian at home ) I am restriced > to RH5.0 on the box here so making a .deb could present a problem. If you have 1GB or so free and you have root access, you can install Debian in a chrooted environment. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: GIMP 1 IN FORZEN
Brian White <[EMAIL PROTECTED]> writes: > > Debian 2 ships with Gimp 1 take that redhat :-) > That's assuming that we can get Hamm ready and ship it before RedHat's _next_ > release. They already have 72MB of fixes for 5.1. :) (10MB of fixes to the libjpeg problem I mentioned earlier, 31MB for X fixes, and miscellaneous security fixes including programs that were accidentally setuid...) As always, they have us beat out on ease of configuration and other ease-of-use issues. (linuxconf provides them with graphical-, text-, and web-based configuration. Their network configuration is modularized into seperate files for each interface.) They also beat us on the fact that they have actually released something. We have them beat out on shear size, quality, integration of packages, and ease of updating. (A coworker toasted his RPM database trying to upgrade to 5.1, and now the upgrade program segfaults.) Plus we have apt-get, which is just awesome. What's the story on non-intel versions of hamm? Are they going to exist? The Sparc trees, both hamm and slink, are completely screwed up because about 200 packages in the tree depend on the glibc that has been sitting in Incoming since May 4. If we're not having a "sparc" version of "hamm", should the tree even exist in hamm? (The glibc in question is destined for both unstable and frozen.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any Swim 2.1 users?
Alexander Kushnirenko <[EMAIL PROTECTED]> writes: > I posted this question in debian-user and got no reply :( May be some of > experts could help me out. > Our university kindly bought us Motif for Linux (SWim 2.1) from Linux System > Labs (http://www.lsl.com). On the CD they send there is an installation for > redhat, but nothing for debian. Generally they recommend to copy a big > directory tree to /usr. But it's quite big and contains all sorts of things > (window managers, utilties etc...) which I do not really need, and I also do > not want to accidently mess things up. Err, that's mainly because I'm a lazy bum. (I was supposed to package it for them.) I stopped working on it when I discovered some problems with locale, you might need to use libBrokenLocale.so to get it to work correctly. > Any recommendations how to set it up right for Debian 2.0? In other words > what files do I need to install to take advantage of dynamic libraries? You can use what I have so far, it should work. The missing details were adding some readme's and a script to automate everything. get: http://www.cps.msu.edu/~dunham/out/swim-2.1.tar.gz and untar it. It will make a directory called swim-2.1. "cd" into this directory, and copy the .tgz files from the SWiM CDROM into this directory. I don't have the CD mounted right now, but you need the ones for Red Hat 5.0. At this stage you will have a tree that looks like: swim-2.1/ --+-- debian/ a bunch of control files | \--- a bunch of *.tgz files After they are copied, you can type: fakeroot debian/rules binary and the packages will be built and will show up in the parent directory. (You will need the "debhelper" and "fakeroot" packages installed for this to work. If you are root, you can leave out the fakeroot part.) IIRC, the version of SWiM 2.1 that I was working from didn't have RPM packages, so YMMV. The packages are broken down into: swim, libxm2g, libxm2g-dev, libxm2g-slib, swim-mwm, swim-man, and swim-examples. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: libungif?
Will Lowe <[EMAIL PROTECTED]> writes: > I've just installed Jim Pick's Gnome .20 .debs and they're all complaining > that libungif.so.3 can't be found. Where would it be? There's no > libungif package, according to www.debian.org/packages.html. They are in slink. The depends in gnome is screwed up. It says that it depends on (libgif3g | libungif3g), but panel is linked against libungif.3.so, which is not contained in the libgif3g package. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: LyX: just about the only word processor in debian
[EMAIL PROTECTED] writes: > I am just, out of my inherent curiosity, curious whether LyX still exists > in the hamm distribution. > This was the only available word processor that came with Debian. > I know that it is technically a "pain in the ", > and that anyone who can type > 50WPM can benefit greatly by learning the > markup (so as to type LaTEX docs by hand), yet I believe it's important. > My package database lists LyX in the "obsolete" category - IMO > this is a shame. If it has disappeared from debian, I believe something > *needs* to come up soon to replace it. lyx is in contrib/text, you probably forgot it include contrib in your list of package sources. The two biggest problems with Lyx are that the widget set is non-free and that the widget set is ugly. (And, more specifically, the menus don't behave right.) I have the patches to get AUIS 8.0 to compile with egcs. (Patches from USENET plus a couple of my own to fill in the blanks.) I can also package the default Thot editor. (Thot could be used to build an editor for a specific SGML DTD, but that would be a bit of work.) I currently have Amaya packaged, a HTML editor/browser based on the Thot toolkit. IMHO, it is more usable than the Netscape (you actually can control the structure of your document). Both of these are BSD style licenses, although Thot is a little flaky with Lesstif. (Lesstif text widgets need work.) Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packaging PAM modules? anyone?
[EMAIL PROTECTED] (Gregory S. Stark) writes: > I asked once earlier, but no one responded: > Does anyone know how PAM modules should be packaged? You can look at Red Hat for examples. > Where should they be installed? Is there some way to register them, or some > script to run to offer the sysadmin the option of making the new module the > global default? Personally I think PAM modules are one of the big missing > links for Unix system and no distribution would be complete without a solid > architecture for dealing with them. We have ppp-pam and pam packages, but how > does packaging further modules work? > Kerberos won't be properly supported until there's a PAM module for it > packaged. There are a couple around, but I have no idea how to package them. > I don't even know how PAM is configured and I don't use it here at all. PAM modules go in /lib/security. Programs are configured to use these modules by editing configuration files in /etc/pam.d/. There is one file for each client program. These files should be included with the respective client programs. (On Solaris, all programs are controlled from one file: /etc/pam.conf.) A package for a kerberos module would contain the module in /lib/security, whatever configuration files the module needs in /etc (like server name, etc), and perhaps a script in /usr/sbin that adds kerberos to the existing /etc/pam.d/* files. A longer term goal would be a gtk or newt based program that lets the user configure security without editting /etc/pam.d/* files directly. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PAM and slink (was Re: packaging PAM modules? anyone?)
[EMAIL PROTECTED] (Adam P. Harris) writes: > [EMAIL PROTECTED] (Gregory S. Stark) writes: > > I asked once earlier, but no one responded: > > Does anyone know how PAM modules should be packaged? > Gregory, I'm sorry I cannot provide good technical information. I do > know that we had backed out PAM-ifying hamm sometime last year. I > think we should re-PAM-ify everything (i.e., pam version of login, > passwd, etc etc). I think PAM is stable now and should be embraced > for slink. > But I could certainly be wrong. I'd like to see PAM in slink. Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: PAM and slink (was Re: packaging PAM modules? anyone?)
[EMAIL PROTECTED] (Adam P. Harris) writes: > Norbert Veber <[EMAIL PROTECTED]> writes: > > What sorts of things can pam do? I only know that for example a > > long program that uses PAM works regardless of weather the > > password file is shadowed or not, but can it do more advanced > > authentication, ie. could it be used to replace radius? There currently is support to log to a RADIUS server, I think authentication is still being worked on. The main point of PAM is to allow the sysadmin to configure his choice of all of the various authentication methods via text files, without recompiling anything. It gives the sysadmin the flexibility (choice) that many people claim Debian strives to provide. > PAM, as I understand it, provides the hooks that enable you to plug in > different authentication/authorization (NIS, NIS+, shadow, passwd, > kerberos, radius, etc). That way, you have a pam'ified /bin/login, > rather than having a kerbified login, a shadow login, etc etc. > It's used by RedHat and Solaris. Basically, it lets you specify in a file the rules that programs use for determining whether someone can log in. Below are some examples of pam configuration files, but first a bit about what you can do with it: * Locally, we are writing a module to stack on top of the password modules, so that "passwd" will set both NIS passwords and store a samba password. (This is necessary to use encrypted samba passwords.) * There are modules to implement: securetty, anonymous access, group access, access at particular times of day, "wheel" group access, print last login time print a file "chroot" (automatically chroot a user) S/Key (so you could, by editing text files, restrict xdm, ppp, ftp, rsh, to a certain group, to certain times of day, etc.) * There's a toy "filter" module, along with an example filter that transposes upper and lowercase characters (This could be used to implement an annoying cybersitter-like functionality.) * There is a module to authenticate against an NT server. * I believe there is a module for secureid cards. * Future directions include authentication against a LDAP server. If you don't like /etc/securettys, you can just edit a file to take it out. If you don't like .rhost files, you can just as easily disable that. If you only want people in the "manager" group to be able to use rsh, you edit a file, etc. If you want wheel on su, just edit a text file. Some examples of configuration files. Here is "/etc/pam.d/rsh" auth required /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_nologin.so accountrequired /lib/security/pam_pwdb.so sessionrequired /lib/security/pam_pwdb.so Says that the "pam_rhosts_auth.so" library has to be satisified, that "pam_nologin.so" has to be satisfied (checks /etc/nologin). That "pam_pdwb.so" has to find an account and that "pam_pdwb.so" is used to set up the session. Compare to the "rlogin" file: auth required /lib/security/pam_securetty.so auth sufficient /lib/security/pam_rhosts_auth.so auth required /lib/security/pam_pwdb.so shadow nullok auth required /lib/security/pam_nologin.so accountrequired /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow nullok use_authtok sessionrequired /lib/security/pam_pwdb.so The first module checks /etc/securetty (the library fails if the person is trying to login as root and the tty is not listed there - if you don't like securetty, you just delete the line). The second says that an rhost file entry is sufficient. Otherwise pam_pwdb.so is consulted (null passwords are allowed because of the option, and the shadow file is consulted). The account and session info is gotten from pam_pwdb.so. I don't the the password stack is actually used here (it is in the file for the passwd program). Steve [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: An X version of dselect for slink
Tom Lees <[EMAIL PROTECTED]> writes: > On Fri, Oct 02, 1998 at 03:18:13PM +0200, Hanno 'Rince' Wagner wrote: > > Hi, > > Enrique Zanardi schrieb am 02. Oktober 1998: > > > Moving X to the base disks (Auch!) and configuring X just after the first > > > reboot (hard task for a newbie). I'm not excited about that. > > Hmm - why not using the minimal X used for XF86Setup? It > > may me bad because it's the minimum - but it's X... > Sounds good. When KGI is working nicely, we will have One True X Server > (well, the choice between XF86_KGI and XF68_FBdev, but...). But until then, > this will probably work. As long as we have the choice to _not_ use the KGI X server. (I don't like it - last I checked, they translated keycodes->Unicode->keycodes before handing them to the X server.) For initial install on Intel, we could always use XF86_VGA16. That should work on all systems. Steve [EMAIL PROTECTED]
Re: Imlib NMU
Paul Slootman <[EMAIL PROTECTED]> writes: > On Sun 04 Oct 1998, Brian Almeida wrote: > > > I just talked to Shaleh, the previous Imlib maintainer. It was > > intentional to use libjpegg6a for imlib. 6a and 6b do not play > > well together. Your NMU > Is it necessary that they play _together_ ? > > breaks every Imlib-using GNOME package out there. Therefore I am > > overriding it. Please go through the correct channels next time, > > instead of going out and doing NMUs of other peoples packages > > without a so much as a by-your-leave. That is the whole point of > > the Bug tracking system. I check my mail regularly, as does > > Shaleh. Let us know before you go out doing stuff that affects > > other people's packages. Going to libjpegg6b is fine. But all > > the other packages have to make it there as well. Please people, don't upload NMUs without at least trying to discuss it with the developer. If I wanted to deal with "anyone can upload a new version anytime he/she feels like it", I would be making RPMS. I recently had somebody completely break my dhcpcd package by uploading a completely different dhcpcd daemon with much larger version number. They didn't even ask me. If they had asked me, or looked at the bugs filed against the package, they would have found out where to get an experimental package of the thing they uploaded, packaged correctly. (I had to introduce epochs to override the NMU.) > Do you really mean _all_ other packages? AFAIK you can have libjpegg6a > and libjpeg6b installed together (I didn't find a libjpegg6b package). > Additionally, isn't it that so that those packages that use imlib and > depend on libjpegg6a, depend on libjpegg6a only because imlib does? libjpeg6b is broken and shouldn't be used by any new packages. It doesn't respect the upstream maintainers choice of soname, namely libjpeg.so.62, and hence makes Debian incompatible with Red Hat. (RedHat does use the the upstream soname.) Until somebody gets around to releasing a "libjpeg62" package, we should stick with libjpeg6a. Last I knew it was an unwritten Debian policy to respect upstream sonames whenever possible. (It takes an effort to get libjpeg-6b to compile with anything other than the upstream soname, so I suspect the maintainer just blindly applied the 6a diff file without noting that they added shared library support in 6b.) Steve [EMAIL PROTECTED]
Re: Imlib NMU
Jim Pick <[EMAIL PROTECTED]> writes: > Brian Almeida <[EMAIL PROTECTED]> writes: > > > > libjpeg6b is broken and shouldn't be used by any new packages. It > > > doesn't respect the upstream maintainers choice of soname, namely > > > libjpeg.so.62, and hence makes Debian incompatible with Red Hat. > > > (RedHat does use the the upstream soname.) Until somebody gets around > > > to releasing a "libjpeg62" package, we should stick with libjpeg6a. > > > Oooh. Interesting snag. So. We need to make a joint decision. I talked > > to Jim Pick last night about putting 6b in slink, and get it in before the > > freeze. However this makes me edgy. Jim, Chris? Your opinions? Maybe we > > should just leave it at 6a...even Chris admits that 6b has not been tested. > > I don't want to break every Imlib dependent package totally a week and half > > before the freeze. Unfortunately, libjpeg6a wasn't compatible with Red Hat either (at that point in time the upstream maintainers didn't support shared libraries, hence no standard soname). > Let's do something compatible with Red Hat (unless there are good > reasons not to). Synchronizing SONAMEs is one of the goals of the > LSB. If we are going to switch to libjpeg62 - let's do so before the > freeze. The new libjpeg uses libtool, so it's a matter of taking out the patch to the makefile and doing something like "./configure --enable-shared --enable-static && make" to build it. (You also should do "make LIBTOOL=`which libtool`".) One other thing: there no longer is any need for a seperate libjpeg-gif package, the jpeg distribution no longer contains code for real .gif encoding. (It only contains code for the less optimal LZ with reset encoding instead of LZW.) Mike, are you going to upload a new libjpeg with the correct soname? I have some packages that I make from scratch using dh_make. (I copied your "copyright" file and descriptions.) They generate libjpeg62_6b-1.1, libjpeg-dev_6b-1.1 and libjpeg-progs_6b-1.1. If you want, you can use them: http://www.cse.msu.edu/~dunham/debian/libjpeg Or you can just change your package to use the right soname. If you'd rather not do the work right now and don't mind me uploading my version, please let me know. Steve [EMAIL PROTECTED]
Re: Imlib NMU
Brian Almeida <[EMAIL PROTECTED]> writes: > On Mon, Oct 05, 1998 at 10:57:25AM -0700, Jim Pick wrote: > > Let's do something compatible with Red Hat (unless there are good > > reasons not to). Synchronizing SONAMEs is one of the goals of the > > LSB. If we are going to switch to libjpeg62 - let's do so before the > > freeze. > Alright. Who wants to do the upload of the fixed libjpeg62? The maintainer, > or someone else? If the maintainer doesn't want it, I have one in ~dunham/libjpeg on master. I'm waiting for a response from the maintainer first. Steve [EMAIL PROTECTED]
Re: Imlib NMU
Shaleh <[EMAIL PROTECTED]> writes: > I 100% agree w/ you. Now make it work (-: I have compiled Imlib on > my own box and I can link w/ only -lImlib. However every other > person I know of, linux or otherwise needs to use the -l libs. > Imlib is merely a common interface to the gfx libs. It hides the > jpeg, png, etc. The problem here is whether Imlib is compiled with the stock version of libtool or the Debian version. The Debian version of libtool correctly specifies the interlibrary dependencies, so you see: # ldd /usr/lib/libImlib.so.1 libjpeg.so.6a => /usr/lib/libjpeg.so.6a (0x4002b000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40049000) libungif.so.3 => /usr/lib/libungif.so.3 (0x4007f000) libpng.so.2 => /usr/lib/libpng.so.2 (0x40086000) libz.so.1 => /usr/lib/libz.so.1 (0x400b1000) libm.so.6 => /lib/libm.so.6 (0x400c3000) libc.so.6 => /lib/libc.so.6 (0x400db000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4017c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x2000) # The RPM packages use the stock version of libtool, which doesn't note interlibrary dependencies, so their shared libraries are broken. This probably won't be fixed until either somebody finds time to "correctly" fix the upstream libtool or Gnome stops using libtool. Steve [EMAIL PROTECTED]
Re: Live file system
Keita Maehara <[EMAIL PROTECTED]> writes: > > I've been working on a CD specific install that basically delivers a > > "standard" system with "cp -a" that could be used to also construct a > > "live" file system. I'll let you know how it works out, if I can ever get > > back to working on it. > I've tried to make a live CD called Livian (Live Debian :-)) a few > weeks ago (It is quite useless and I don't have enough time to improve > it now though). > I've untarred base2_0.tgz into a new directory and used dpkg's > "--admindir" and "--root" options to create a filesystem without > affecting the real filesystem. Instead of "cp -a", we can have a > generic method that the live CD creators can make a image as they want > (just like a new installation). Actually, it is easiest to untar base2_0.tgz. Cd into the directory and do: "chroot . bin/bash" Will give you a bash shell in an environment that thinks the current directory is the root directory, then you can do: mount /proc /proc -t proc and configure and install packages. (I often use this technique to test glibc 2.1, or install Debian on a different partition. At one time I had a machine that was running Red Hat and Debian at the same time - if you telneted in, you got Debian and if you used ssh to connect you got Red Hat.) Steve [EMAIL PROTECTED]
Re: dpkg config files in /etc ?
"Thomas Gebhardt" <[EMAIL PROTECTED]> writes: > Hi, > > the configuration files of all debian packages are located in /etc. > That's really fine. > But the package manager stores its configuration (access method, > list of selected packages, ...) somewhere in /var/lib/dpkg. Why? Configuration goes in /etc, state goes in /var. Steve [EMAIL PROTECTED]
Re: another problem maybe relate to lesstiffg
Michael Meskes <[EMAIL PROTECTED]> writes: > I just saw that nedit's layout changed. Between menu and text there is a hug > gray area that hasn't been there before. Since I also experienced missing > buttons in mpsql I wonder if both are related to lesstifg. Guess I try to > reget the old version. Yup, I just noticed that my package, amaya, no longer works. Layout problems: the widget holding the page doesn't show up. I think we might need a newer (or older) version of lesstif in slink. Steve [EMAIL PROTECTED]
Re: gdselect alpha 2 (BUG Report)
"Shaya Potter" <[EMAIL PROTECTED]> writes:
> -Original Message-
> From: Tom Lees <[EMAIL PROTECTED]>
>
>
> >alpha 2 is released at http://www.lpsg.demon.co.uk/gdselect/
> I was trying to compile it, had a little problem with some includes on glib,
> which I overcame, but it seg faulted (or something like that, said glib
> caught it) in the initial run and setup, this is on a system that has latest
> gtk and glib, but is 100MB behind in other regards (been away from this
> machine for a month, running apt tonite on it).
This is due to a hard coded buffer size, see the end of this message:
Program received signal SIGSEGV, Segmentation fault.
0x4021a390 in ()
(gdb) bt
#0 0x4021a390 in ()
#1 0x8052460 in dpkgtag_mergetags (first=0x84919a0, t=0x83b2d08, flags=4,
proc=0x804b210 ) at pkg.c:375
#2 0x804b466 in DoProcess (a=1, s=1) at main.c:111
#3 0x804b869 in ReadAvailStatus () at main.c:189
#4 0x804bba3 in main (argc=1, argv=0xbd54) at main.c:237
(gdb) up
#1 0x8052460 in dpkgtag_mergetags (first=0x84919a0, t=0x83b2d08, flags=4,
proc=0x804b210 ) at pkg.c:375
375 if (!strcasecmp (p->name, p_name) &&
(gdb) p *p
$1 = {first_tags = 0x84a6778, name = 0x0, ver = 0x0,
descr_line1 = 0x84a68b8 "Guile-Gtk scheme interpreter (part of Gnome)",
descr = 0x84a6788 "Gnome is the \"GNU Network Object Model Environment\"\nIt
is a project to build a complete, user-friendly desktop based entirely on free
software.\nThis package contains the guile-gtk and gnomeg scheme in"...,
pri = dpkgpri_required, section = 0x0, source = 0x0, next = 0x84a68f0,
pkg_av = 0x0, pkg_stat = 0x0, deps = 0x0, dependents = 0x0, flags = 2,
data = 0x0, status = dpkgst_avail, selected = dpkgsel_unknown,
error = dpkgfl_ok}
(gdb) p p_name
$2 = 0x83b2d30 "libgdk-imlib1"
This happens when it's part of the way through processing the Status
file. I checked both status and available and the "gnome-guile"
entry has a "Package: gnome-guile" line in both files.
I downloaded the cvs snapshot and checked out alpha_1, and it crashes
at the same spot (p_name="libgdk-imlib1", p->name=0, package in p is
gnome-guile).
Just checked the entry for gnome-guile package. Noticed one
pecularity: the "Depends" line is 330 characters long.
I increased LINE_BUFSZ to 512 in tags.c, and the problem goes away.
A correct solution would be to fix tagfile_read_tags(). If there is
no "\n" terminating the string, then there is more to read. (Unless
EOF.)
Steve
[EMAIL PROTECTED]
Re: gdselect alpha 3
Ben Gertzfield <[EMAIL PROTECTED]> writes: > > "Martin" == Martin Schulze <[EMAIL PROTECTED]> writes: > > Martin> Fixed by moving "#include " five lines up. I > Martin> fixed it but forget about it, since it was *that* easy. > Martin> Not even worth mentioning. > > Er, in which file? The file that errored out was deps.c and it doesn't > even #include .. Adding a #include to it makes it > compile. Quoting your original message: : In file included from deps.c:10: : /home/che/src/gdselect/gdselect-a3/include/dpkg-db.h:164: parse error before `FILE' ^^ Steve [EMAIL PROTECTED]
Re: Debian v2.1 ("Slink") Deep Freeze
Brian White <[EMAIL PROTECTED]> writes: > pilot-link31806 pilot-link: Can't build from source This bug was filed against the 0.9.0 package and the 0.8.11 package is installed in slink. Steve [EMAIL PROTECTED]
Re: how rpm does it (Re: Dpkg Update Proposal)
Joey Hess <[EMAIL PROTECTED]> writes: > As I said before, rpm does have the capability to install 2 different > versions of a package simulantaneously. Here's how it works, to the best of > my knowledge. > User interface: > Rpm differentiates between installing a package and upgrading a package. > Installing a package (rpm -i) simply unpacks the rpm file, registers it in > the database of installed packages, etc. If an old version of the package is > present, it will not be removed. > Upgrading a package (rpm -u) means that the old version of the package that > was installed (if any) is removed at the same time the new one is installed. That's "rpm -U". > So rpm's method of upgrading is the same as dpkg -i, whereas dpkg has nothing > equivilant to rpm's method of just installing a package. > Oh and by the way, this user interface tends to confuse new users (at least > it did me) who accidentially install many versions of the same package > because they arn't aware they should be upgrading it instead. Buried in the Maximum RPM book is a suggestion that you always use -U (which also installs new packages. > I forget how rpm allows removing of one version of a package while leaving > another version of it installed. You can specify packagename or packagename-version to query and remove operations. If you just specify "packagename" to a query op, it will list all versions. Dunno about the delete operation. > Back end: > I don't know much about this. I can intuit some things. > Rpm can keep track of multiple versions of the same package that are all > installed. Presumably, this means its package database indexes the installed > packages by both package name and version, instead of just by package name > as dpkg does. > What happens if you try to install version bar of a package while version > foo of that same package, which contains files of the same name, is > installed? Rpm will happily overwrite version foo's files. rpm will complain if files conflict with another package, and won't let you install the new one unless you force it with --force. > What happens if you then remove version foo? I'm not sure, it's been a while > ;-). I can say that rpm doesn't deal with this very well. It either has to > leave version bar's files around, or delete them, either action leaves the > installed version foo in an inconsitent state. What does dpkg do if you turn on --force-overwrite? > Given the above, it's clear that rpm's method of doing this is really only > useful for library packages, in which 2 different versions contain files > with entirely different names. (You might ask, what about /usr/doc, wouldn't > it be the same in both versions of a library package. The answer is that rpm > packages use /usr/doc/package-version/ as the doc directory.) But it does > work tolerably well for those library packages. Of course, if redhat had > anything like update-alternatives, it could be more useful for other > packages too. I've suggested to Red Hat in the past that they adopt our package naming scheme. There are a few packages that use the seperate packagename for seperate version scheme. (If you look at the "gnome" directory, you'll find glib10 and gtk10 packages containing older versions of glib and gtk.) > Applying this to dpkg: > User interface: > If we wanted to make dpkg have this capability, we could add a new command > line flag, say "--keep-old-version" that makes "dpkg --keep-old-version -i" > behave like rpm -i does. > We would have to come up with some method to allow dpkg to remove one > version of a package while leaving another version of that package installed. I like our current method of naming the packages after the soname of the library. We should make it explicit policy for packages that contain shared libraries used by other packages. > Back end: > Dpkg would have to change how it parses the status file, and presumably how > it stores the information about installed packages in memory, so it in > effect considers different versions of a package as different packages, if > --keep-old-version were passed to it. > Dpkg already doesn't allow 2 packages to be installed that contain the same > files (unless --force-overwrite is on), so it doesn't run into the problem > rpm runs into with installing multiple versions of a package that contain > the same files. (Or does it? The same issues seem to apply with > --force-overwrite. But I guess dpkg does the Right Thing, whatever that is. > ;-) RPM also requires you use --force. (This forces everything but dependencies.) > Applying this to deb packages: > For library packages, which contain different files from version to version, > we really need do nothing special. > For packages like ncftp and ncftp2, update-alternatives can be used (as it > is now) to ensure that the 2 packages contain only differnet files. > However, both these cases do leave us with the problem of > /usr/doc/. We would have to either change that
Re: getting kernel 2.2 into slink
Ben Collins <[EMAIL PROTECTED]> writes: > On Thu, Jan 21, 1999 at 10:02:52PM -0500, Brian White wrote: > > No. We had enough problems upgrading from 2.0.35 to 2.0.36. This would > > be a major change and have corresponding reprocussions. I'm sure it's > > very stable, but it will have incompatibilities. > I'm using nothing but packages from slink/sparc and I see no > incompatibilities. Then again the box isn't running X, any of the other > sparc devs out there have any input on which kernel provides the > 'safest' X for sparc? I haven't touched 2.0.x kernels for the last year on the Sparc platform. I don't trust them. Additionally, the 2.0.35 Debian kernel wouldn't even boot on my Sparc20 (haven't tried 2.0.36), but I've only been running Debian on that machine for about a month (I installed by hand with the 2.1.x kernel I was using for UltraPenguin). X works fine on my Sparc20 and Ultra5, but I can't speak for other systems. The Ultra 5 has run a variety of CVS kernels from about 2.1.125 to 2.2.0-pre4, and the 20 has run an even wider range of 2.1.x kernels with UP, but mostly 2.1.12x kernels with Debian. Steve [EMAIL PROTECTED]
Re: Reality check!
"M.C. Vernon" <[EMAIL PROTECTED]> writes: > I would see this as a RH-style - so a rather bloated kernel which includes > lots of stuff as standard, and asks them the pertinent questions all at > once at the beginning, and then gets on with it. Excuse me, but RedHat actually boots on my laptop because the kernel is _less_ bloated than Debian's kernel. Debian's install disk doesn't boot. Red Hat uses a zImage kernel, Debian uses bzImage because it's too big for zImage. (How do they do it? For the install floppy they load the drivers after booting, and for subsequent boots they use initrd.) Steve [EMAIL PROTECTED]
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Note to Def Branden Robinson <[EMAIL PROTECTED]> writes: > This is what I hope to be the final test build of XFree86 3.3.2.3a-9; if > there are no significant problems it will be released with that version > number. This test build addresses all four release-critical bugs currently > outstanding against XFree86. > There are exactly 5 things I want to do for -10, and then I will declare > slink X done (barring any nasty bugs that crop up). > * have XF86Setup mung /etc/X11/Xserver (and call correct X server during > test) > * deal with new font and static library packages in the upgrade department > * XKB and locale fixes for our non-American friends > (bugs.debian.org/xlib6g) > * merge alpha patches > * merge sparc patches My sparc patches or the older ones that Anders sent you? > Alpha and sparc patches need to be i386-safe. I don't know that they > aren't; I haven't checked closely yet. My next test build will likely > incorporate the alpha patches and I will want to see if it works okay on > i386. Almost all of the Alpha patches have to do with 64-bit alignment > issues, and should not affect the i386. But there's always the chance of > something lurking... > If some sparc folks could confirm that their patches are similarly safe for > i386 consumption I'll subsequently add those. I imagine the Alpha patches > will make life easier for the sparc64/UltraLinux port (do we have one > yet?). The patches that I sent you should be completely safe. But the resulting packages have only been tested by me. (As I said, I took out the -pedantic flag on the altdev stuff - the other changes don't touch x86 at all.) BTW, There are two kinds of sparc64 support: usermode and kernel mode. Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc stuff on a 64-bit kernel. So Alpha patches don't help much there. The biggest issue on the 32-bit sparc is unaligned memory accesses. I don't really want to step on any feet here, but it would be nice if we could get the X source for Sparc into slink - and get the UltraSparc support in there. (Eric plans on making the install work, so X support would be an added bonus.) Nontheless, the current sparc binaries are a built by Anders from a seperate tree. (Anders - my tree was made by merging the latest UltraPenguin patches - a superset of the Red Hat patches - into Branden's tree.) I would want some other sparc people to double check my packages, before we actually include binary packages from my code into slink. If Anders has a tree that matches Branden's recent trees, I'll defer to him (but ask that either he or I merge in the Mach64 and Creator patches), otherwise, I'd like to the goahead from Anders et al to use my stuff in slink (after appropriate testing). It shouldn't matter too much (as long as the binaries work), since I believe Anders is planning on starting from scratch on the 3.3.3.x releases. What do the other Debian Sparc people think? Should we update the X binaries in slink so that we are shipping source code and have UltraSparc support? (I'm 99% sure the binaries work, the only issues would be install script &c, and they are mostly copied from the current binary packages. Also, I have to add a hard-coded XF86Config to the Sparc Mach64 package - because XF86Setup doesn't work yet on the sparc machines.) Steve [EMAIL PROTECTED]
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Anders Hammarquist <[EMAIL PROTECTED]> writes: > > The patches that I sent you should be completely safe. But the > > resulting packages have only been tested by me. (As I said, I took > > out the -pedantic flag on the altdev stuff - the other changes don't > > touch x86 at all.) > Right, at least my sparc patches really only deal with the Xsun server. I > guess yours are similar. And the stuff in the debian dir. I also found that I had to use a hack to remove the -pedantic line from the configuration files to get the altdev stuff to compile: diff -ruN xfree86-3.3.2.3a-8pre9v1/debian/rules xfree86-3.3.2.3a/debian/rules --- xfree86-3.3.2.3a-8pre9v1/debian/rules Tue Dec 29 15:35:58 1998 +++ xfree86-3.3.2.3a/debian/rules Mon Dec 28 22:09:18 1998 @@ -8,7 +8,7 @@ DEBTREEDIR5:=$(shell pwd)/debian/xtree-libc5 # if your arch needs glibc1 compat support build, add it to this list -COMPAT_ARCHS=i486 m68k +COMPAT_ARCHS=i486 m68k sparc A:=$(shell dpkg --print-gnu-build-architecture) ifneq (,$(findstring $(A), $(COMPAT_ARCHS))) @@ -43,6 +43,7 @@ build-old: $(checkdir) mkdir $(L5) && cp -a include config lib Makefile $(L5)/ + perl -pi -e 's/-pedantic//' $(L5)/config/cf/xfree86.cf cp -a debian/Imakefile.l5 $(L5)/Imakefile sed s/@ARCH@/$(A)/ < debian/site.def.l5.in > $(L5)/config/cf/site.def mkdir -p $(L5)/programs/Xserver If it doesn't compile for you, add this hack. I doesn't hurt anything. (The pedantic compiler doesn't like the sparc altdev header files.) > > BTW, There are two kinds of sparc64 support: usermode and kernel mode. > > Usermode stuff is a _long_ way off, currently Debian runs 32-bit sparc > > stuff on a 64-bit kernel. So Alpha patches don't help much there. > > The biggest issue on the 32-bit sparc is unaligned memory accesses. > Hmm, the alpha patches clean up many unaligned accesses, and since > the alignment requirements for the alpha are the same as for sparc > (save 64bit alignment on 32bit sparcs) the alpha patches should fix > this too. I've been planning to merge the patch sets (I do the alpha > X packages too), just haven't gotten to it yet (and I was sort of > waiting to see if the central CVS archive that was suggested was > going to happen). Maybe this is a good time... I would assume that these patches will conflict then (because Alpha would do #ifdef __alpha__ and sparc would do #ifdef __sparc__), but they should be easy to fix. > Can you send me your patches? I suspect that a lot of them are the > same (and they aren't really mine, Mike Shuey did most of the > original work on them), since they too are based on Red Hat's. That > way I can merge them (or I could send you mine and let you do the > merging, either is fine by me). Mainly what I want to achieve is > that we don't change the way Xsun work (i.e. where it finds screens > and such. It has been changing a bit, and I think I have a good > method now). A lot of them are the same. My latest patches against Branden's source are at: ftp://www.cse.msu.edu/pub/debian/X/xfree86.sparc.diff.gz There is also a "split.pl" which splits the patch into many files (one per target file). I don't know how helpful it would be, but it's there if you want it. (You can use "cat" and shell globbing to put the pieces back together. In particular, you might want to seperate out the patches to the debian directory.) These patches are against the xfree86-3.3.2.3a-8pre9v1 tree with Brandens patches already applied. > > If Anders has a tree that matches Branden's recent trees, I'll defer > > to him (but ask that either he or I merge in the Mach64 and Creator > > patches), otherwise, I'd like to the goahead from Anders et al to use > > my stuff in slink (after appropriate testing). > My sparc tree is currently too out-of-date to really be considered > matching Branden's tree. My only concern with switching entirely is > that we may loose fixes that are in my tree but not in yours, thus > I'd rather try and merge our patches. Ok, the only big issue is that you'll probably have to update your stuff in the Debian directory. Also, to handle my stuff, you will need to add the XF86_Mach64 server to the list of packages generated for the sparc. (There is a XF86_VGA16 server too, but it doesn't seem to work, so I'm not packaging it.) Also, make sure the patch at cfb8line.c:898 gets applied, it's not in RedHat's stuff (my own patch) and fixes a bus error in 16bit mode which is triggered by WindowMaker. > > It shouldn't matter too much (as long as the binaries work), since > > I believe Anders is planning on starting from scratch on the > > 3.3.3.x releases. > That's the idea, yes, since much of the code should be in 3.3.3.x already. AFAIK, the sparc stuff hasn't been merged in yet, but it will eventually be merged in. > > (I'm 99% sure the binaries work, the only issues would be install > > script &c, and they are mostly copied from the current binary > > packages. A
Re: gnuserv/gnuclient problem
Amos Shapira <[EMAIL PROTECTED]> writes: > On Fri, January 29 1999, Ionutz Borcoman <[EMAIL PROTECTED]> wro > te: > |Hi, > | > |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions > |from potato I am no more able to start a gnuclient :-( Is anybody else > |experiencing this ? > I've reported this bug with slink months ago with no response. I > still can't use gnuclient with xemacs under slink. There is definitely something wrong with it. I'm not sure where the exact problem lies, but it is trying to run: /usr/lib/xemacs-20.4/sparc-debian-linux, Mule/gnuserv rather than: /usr/lib/xemacs-20.4/sparc-debian-linux/gnuserv I _think_ the problem lies in the elisp files, but I'm not sure.. Steve [EMAIL PROTECTED]
Re: -rpath with libtool and Debian Linux
Hamish Moffatt <[EMAIL PROTECTED]> writes: > On Fri, Jan 29, 1999 at 07:27:28AM -0200, Alexandre Oliva wrote: > > Does it? You mean, that hack in ld.so that adds /usr/lib/libc5 to the > > library search path in certain circumstances? The hack is incomplete, > > you just have to fix it. > Have you checked our ld.so source? The only mentioned of "libc5-compat" > is documentation. It's a magic hack. Somehow (according to Alexandre) it magically adds /usr/lib/libc5 to the path, even though "libc5" occurs nowhere in the binary. (go figure.) Maybe we should just agree that libtool is broken, that it won't be fixed upstream, and just fix the Debian version? This would mean that we would have to rerun autoconf &co when we build packages - but it beats arguing with this guy till the end of time. Steve [EMAIL PROTECTED]
Re: gnuserv/gnuclient problem
Jim Pick <[EMAIL PROTECTED]> writes: > Amos Shapira <[EMAIL PROTECTED]> writes: > > > On Fri, January 29 1999, Ionutz Borcoman <[EMAIL PROTECTED]> wro > > te: > > |Hi, > > | > > |Is the gnuclient/gnuserv broken in XEmacs ? Using the latest versions > > |from potato I am no more able to start a gnuclient :-( Is anybody else > > |experiencing this ? > > > > I've reported this bug with slink months ago with no response. I > > still can't use gnuclient with xemacs under slink. > > It seems to work for me here (gnuclient.xemac20) > > ii xemacs20-bin20.4-13Editor and kitchen sink -- support binaries > ii xemacs20-nomule 20.4-13Editor and kitchen sink -- Non-mule binary ^ The problem only shows up with the mule versions of xemacs. Steve [EMAIL PROTECTED]
Re: gnuserv/gnuclient problem
Chris Waters <[EMAIL PROTECTED]> writes: > Steve Dunham wrote: > > > ii xemacs20-bin20.4-13Editor and kitchen sink > > > ii xemacs20-nomule 20.4-13Editor and kitchen sink > > ^ > > The problem only shows up with the mule versions of xemacs. > Nope, because I only have the nomule version installed, and I have the > same problem. Gnuclient causes xemacs to generate an error, and then > exits immediately. Running slink. Ok, I'm talking about a different problem (which seems to have mysteriously gone away on my system). Steve [EMAIL PROTECTED]
Re: WARNING: Re: debhelper & /usr/bin/passwd
Wichert Akkerman <[EMAIL PROTECTED]> writes: > [1 ] > Previously Remco Blaakmeer wrote: > > Is there any way of changing that default behaviour (e.g. some config > > file) apart from recompiling dpkg? I'd like to leave it disabled at all > > times no matter what the default is in the current dpkg package. > No. Are there other things that would be useful in a dpkg configuration > file? I can't think of anything at the moment. I'd like to be able to turn it off too. (At least RPM only does "--force-overwrites" during the initial install process.) Steve [EMAIL PROTECTED]
Re: List of bugs that *must* be fixed before releasing Slink
[EMAIL PROTECTED] (Dale E. Martin) writes: > Oscar Levi <[EMAIL PROTECTED]> writes: > > In my opinion, this problem is not sufficient to warrant an upload at > > this time since, contrary to the bug reporters claim, it does not > > prevent the packing from functioning. It is annoying, yes. > Interesting that it works for you. It really doesn't for me: > ~> java > Warning: can't find /usr/lib/jdk1.1/bin/../bin/checkVersions, hope that's ok > java was not found in /usr/lib/jdk1.1/bin/../bin/i686/green_threads/java > The binary is somehow actually missing, and I've not done anything weird as > far as I know. The other folks who are saying is doesn't work have the > same problem. I _know_ the checkversions thing is another problem. I have the same problem. The file does show up in "dpkg -L": /usr/lib/jdk1.1/bin/i686/green_threads/java But on the filesystem, the i686 directory is a symlink to the i586 directory, and i586/green_threads is empty. Perhaps this is a bug in dpkg? (I suspect that if you remove the jdk1.1 package and reinstall it, it will fix the problem.) Judging from the bugs database, dpkg has a bunch of problems with symlinks. Steve [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
Samuel Tardieu <[EMAIL PROTECTED]> writes: > On 10/05, 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. > Not largely complete on Sparc (we still have problems with Sun4m), but > Ben Collins is actively working on fixing this :) I believe the problem is known and we have a fix. I'm just waiting for a stock Linus kernel to show up with the appropriate patches in it, so we can add it to potato. Same thing with X 3.3.3.1. We need a late kernel for Creator and Mach64 systems (and, perhaps, LEO systems). Steve [EMAIL PROTECTED]
Re: Release Plans (1999-05-10)
Wichert Akkerman <[EMAIL PROTECTED]> writes: > [1 ] > 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 (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: Time to rewrite dpkg
Enrique Zanardi <[EMAIL PROTECTED]> writes: > On Wed, May 19, 1999 at 05:24:08AM -0700, Aaron Van Couwenberghe wrote: > [...] > > Notably, I'm going to be writing it in C++. This will add > > about 270k to the boot disks' root image, but as the floppy > > install methods are for the most part phasing out under the shadow > > of easier methods, I'm not going to lose any sleep over > > this. libstdc++ can be minimized for static linkage anyway. > dpkg is not on the boot disks' root image (thanks god). It's on the base > system, with dselect, apt and, of course, libstdc++. You won't have to add > it. (Let's call that luck). :-) > OTOH, your opinion that adding 200k to the boot disks' root image, thus > breaking the "rescue" floppy, doesn't matter because the floppy install > methods are phasing out is just plainly wrong. Currently we have three > ways of booting the installation system: bootable CDs (requires a modern > BIOS), floppy disk and bootp (requires a netword card with the proper > ROM, and a bootp+tftp server on the same network). Our bootable CDs use a > floppy image for booting, the same "resc1440.bin" floppy image that's > used on a floppy based installation. That means two of our three methods > (and I dare to say the third one is used on <5% of Debian installations) > use the same "rescue" floppy disk. I won't say that's "pashing out". ;-) Why would this add 200k to the root disk? We don't have dpkg on the root disk, it's in the base image. Steve [EMAIL PROTECTED]
Re: debian O'Reilly book cover is up
Joey Hess <[EMAIL PROTECTED]> writes: > http://www.ora.com/catalog/debian/ > I just noticed this page has a book cover for forthcoming "Learning Debian > GNU/Linux" book from O'Reilly. > What do people think about the art? Looks like that guy has climed onto a > bucking bull -- or is it a GNU? -- and is about to ditch his hat. All good > things. :-) OTOH, I'm not sure it has the classic O'Reilly animal feel -- > but little of their Linux books do. All of their Linux books use a rodeo/cowboy theme rather than the traditional animal theme. I have no idea why. I kinda prefer the animals, but maybe they were running out? Steve [EMAIL PROTECTED]
Re: history (Was Re: Corel/Debian Linux Installer)
Jonathan Walther <[EMAIL PROTECTED]> writes: > With Debian distributions, and small disks, I have found this to always be > sufficient: > > / 32M > /var 96M > swap 32M or more. > /usr all the rest > /home is a symlink to /usr/home > /tmp is a symlink to /var/tmp So what happens to the stuff in /var/tmp on reboot? /var/tmp is supposed to be preserved across reboots and /tmp isn't. Some programs (e.g. vi) rely on this behaviour? BTW, your /var might not be big enough to handle an upgrade from slink to potato. (Depending on whether the source of the packages is net or CD, I think.) Steve [EMAIL PROTECTED]
