plan for freebsd-i386
Thought I'd send an update with my plans for the freebsd-i386 port. Short term (this week): * Clean up patches. Fix changelogs, remove obsolete changes, and conditionalize anything that needs it. * Finish fixing some packaging bugs in freebsd packages. Mostly broken symlinks. Medium term (within the next month or so): 1. Get my build machine running native, instead of in a chroot. I'd also put it somewhere without NAT, so that I can run services. 2. Get space in the archive. Based on Anthony Towns' announcement about woody, I think this should be possible now. 3. Merge patches. I would like to try to merge with netbsd and openbsd ports first, to reduce duplication of effort. 4. Setup an autobuilder 5. See how much builds without patching. :) Long term (when it happens): 1. Do something about installation. Probably the hardest part of the port... 2. Possibly switch to -CURRENT. Depends on stability and how long it takes to release sarge. 3. Hopefully release with sarge. ---Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: group id of newly created nodes
On Fri, Apr 26, 2002 at 08:03:35PM +0200, Marcus Brinkmann wrote: > > Then that's a bug in the rules of those packages. It's sloppy, and needs > > to be fixed. > I agree. Luckily, I kept a list of such packages as I found them. There > might be more (actually, I would assume that there are more). Just found a related problem. debootstrap apparently isn't setting groups when creating directories. This caused most of /var to have the wrong group. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: group id of newly created nodes
On Fri, Apr 26, 2002 at 02:56:38PM +0200, Marcus Brinkmann wrote: > Hi, > > (please CC me on replies) > > we have found an interesting problem in Debian package scripts. This is > related to the behaviour of the Hurd and BSD to create new files with the > gid of the parent directory, rather than the process. And sgid flag on > directories is simply ignored. POSIX allows that. It seems this is default on FreeBSD, also. > For example, if you build a package as root which is unpacked as user joe, > the files in the package will have a group of joe. You can imagine that > this is not a good thing to have. It should be the same on the Hurd as on > BSD, but I have no BSD around to check. It looks like it acts the same. > So I thought I would just give you a heads up on this issue, because it > really puzzled me, and maybe you want to check if your builds are all fine. > Candidates are dpkg, base-files, and debianutils because their debian/rules > commands are not careful enough to explicitely set the group to root. Then that's a bug in the rules of those packages. It's sloppy, and needs to be fixed. > I don't know if you have fakeroot for BSD. But it should even show up in a > fakeroot build. I have fakeroot. I haven't checked what it does yet. > If you unpack and build as root, you will also want to know about bug report > #144571. This is perfectly normal behaviour for tar. dpkg-source should either invoke tar with --no-same-owner, or clean up itself. > I hope this is helpful. If you don't have this problem, congratulations and > just ignore this mail :) If you have this problem, you might need to fix > those debian/rules files. For the Hurd, we definitely have this problem but > we might change the default to be like Linux in this regard, so I am not > sure if we will continue to have it. If we do, we need to fix those > rules files, too, and we might coordinate our efforts. Thanks for the heads-up. I believe the scripts should be fixed, regardless. They don't handle that behaviour, and they don't fail either. That's a bug, because this can happen even on Linux. ext2fs has the grpid or bsdgroups option that causes the same behaviour, according to the man page for mount. (I've never used it.) What happens if someone used it? Undefined behaviour? That mount option might be useful for finding this particular packaging problem. Someone could put an autobuilder on a filesystem like that, then run a script that scans packages for the group id the build was run under. Wouldn't be hard, dpkg -c foo.deb | grep sbuild might work. ---Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: symbol versioning ORIG:(forw) Re: Upgrade nightmare
Andreas, I'm not sure I understand what your question really is. I know that gcc 3.x requires a fairly new version of binutils. I've been having the best results with 2.11.93.0.2-1. This version seems to have fixed the problems I had with debugging symbols, and also seems to work correctly with C++. I don't know much about symbol versioning. AFAIK, it is only used by libc and the kernel. I believe most libraries just use version numbers. ---Nathan On Wed, Apr 17, 2002 at 11:27:45PM +0200, Andreas Schuldei wrote: > i would like your advice on this. is symbol versioning required > to be able to have nice upgradeabel libs as needed for debian > packages of libs? > From: Marc Espie <[EMAIL PROTECTED]> > To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > Subject: Re: Upgrade nightmare > Reply-To: [EMAIL PROTECTED] > Mail-Followup-To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> > X-Spam-Status: No, hits=0 required=5 tests= > > On Wed, Apr 17, 2002 at 11:47:53AM +0200, Andreas Schuldei wrote: > > * Marc Espie ([EMAIL PROTECTED]) [020417 01:28]: > > > You are using the assembler from new-binutils, this is wrong. > > > > [...] > > > > > Except for us OpenBSD developers. Because you see, we went > > > through the same nightmare before, when we slowly took the > > > OS from 2.9 to 3.1... and most of the issues you are going > > > > Could you please give a short overview of what happend, where > > we are today and what the goal is? Are we moving to some enhanced > > ELF (OLF) and what can the new binutils do what the old could > > not? I noticed that there are still library versioning problems > > which are solved under linux. (just stumbled onto that...) > > We don't have library versioning problems. We are using a simpler > scheme that just works. Tell me about what problems you think linux > solves, and I tell you how we don't need it :) > > What the new binutils can do that we can't (yet): > - support for new i386 asm instruction. That could probably be patched in. > - elf sections, which means better support for debugging information > (though it's not perfect yet, because the tools need to coalesce info > more). > - dwarf unwind info, for C++ exception support. > - scripting. That can be used to handle ctors/dtors in better ways. > - some obscure bugs in symbol handling in shared libraries (yes, in ld). > - better memory usage for linking huge libraries (though the hack I've > just committed to ld alleviates that problem a great deal). > - in general, tighter cooperation with recent gcc releases. It's just > a question of testing gcc and fixing the various bits that have been > broken by the FSF recent releases, really. > - -zcomb-reloc, though that isn't perfect yet. In general, pre-linking > support is being worked on in very recent binutils. That's useful for > coalescing relocation info better in large shared code-based projects (see > the kde webpage for details) > > We also have issues which are completely separate from binutils proper. > - some ld.so bugs, which probably kill mozilla. > - gdb has troubles with a.out pic information. > - thread support in general, and in particular in the C++ library and qt. > > One large problem is that binutils may work, but the code is a piece of > junk. It is very convoluted, and it is very hard to find the piece of code > that you are looking for. The patterns used to make the code very flexible > are not at all apparent, and the various indirection mechanisms are very > poorly documented (most of the bfd functions are undocumented, the ld > scripting mechanism is poorly documented), and the functionality separation > is poor (you often find operating-system specific stuff in supposedly > arch-only files), plus there are lots of defines that contribute to > obfuscating the code (hard to find out what's compiled in ELF/ECOFF/AOUT > modes). > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Announcement: new Debian GNU/FreeBSD base tar
I finally made a new tarball for Debian GNU/FreeBSD. You can find it at http://people.debian.org/~utsl/freebsd-i386/base-20020415.tar.bz2 This is based on FreeBSD -STABLE, so you will need to have it installed. Apt is working. You'll want to put the following line into your sources.list: deb http://people.debian.org/~utsl/freebsd-i386/debian unstable main Diffs against debian source packages can be found at http://people.debian.org/~utsl/freebsd-i386/patches Source packages specific to Debian *BSD can be found under http://people.debian.org/~utsl/freebsd-i386/native For information about the current status of freebsd-i386, see the status document here: http://people.debian.org/~utsl/freebsd-i386/status.html Notes: * libshadow - There is a working libshadow now. Programs that update /etc/passwd or /etc/shadow must call spsync(), in order to update /etc/pwd.db and /etc/spwd.db. /etc/master.passwd is no longer used except as part of the update process. You can manually force a rebuild of the db files with mkmasterpw. * shadow/pam - shadow and pam are now linked against libshadow, and should work as expected, including password aging. Haven't really tested pam much yet, but shadow definitely is working. * I'm not sure /dev is in working order in the tarball. Some of the device numbers don't look right. I recommend running MAKEDEV all before use. I think cpio is supposed to get the device numbers right, so I may try switching over to that. * The source diff for dpkg isn't there yet. The source tree is a mess. I will make a diff as soon as I figure out which directory I built it from... Hopefully tomorrow morning. * You need ~600M of free space to rebuild the freebsd source package. * I don't have everything in the apt archive yet. This is because I'm trying to sort out all the packages that require patches. Packages that don't require patches will have a dsc file in freebsd-i386/clean. (.dsc is a small file, and helps me track which version worked.) pgpih5WGUrObK.pgp Description: PGP signature
[wnpp@debian.org: Work-needing packages report for Apr 12, 2002]
Anyone interested in picking these up? cvsup depends on it, and if it goes away it would be kind of inconvenient... ---Nathan pm3 (#129594), orphaned 85 days ago Description: Polytechnique Montreal Modula-3 Reverse Depends: pm3 pm3-extra cvsup mentor cvsupd netobjd obliq pm3i386 (#129593), orphaned 85 days ago Description: Polytechnique Montreal Modula-3 Bootstrap -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
shadow library for *BSD
Here is an attempt at a shadow library for *BSD. This library provides getspent, but it reads from /etc/master.passwd. I wrote some code to try to convert the aging fields, but haven't fully test that part yet. The next step is write a utility to read /etc/passwd and /etc/shadow, write a new /etc/master.passwd, and run pwd_mkdb. With that, we should be able to link the shadow package with this library, and then patch to run the as yet unwritten utility. This is alpha code, and the usual disclaimers apply. ---Nathan libshadow.tar.bz2 Description: Binary data pgpSlHPAHSDty.pgp Description: PGP signature
Re: Multiple topics
On Tue, Apr 09, 2002 at 11:26:56AM -0600, Joel Baker wrote: > On Tue, Apr 09, 2002 at 11:47:10AM -0400, [EMAIL PROTECTED] wrote: > > > > What I ran into with 5.0 was that there was a define that you set to > > enable compiling with gcc 3.x, and there were some #ifdef's to make it > > work. However, that define also enabled building gcc 3.x from the > > FreeBSD source tree, and that failed. Looked like the changes for it > > aren't quite finished merging in. That was only a week or two ago, so > > I'd wait a little while yet. > > Fair enough. Waiting is fine, but knowing that it's a target is quite > helpful. My plan is to continue with 4-STABLE for a while, and try building CVS snapshots of 5 every so often. Once I get one that builds ok, I'll have to recompile with the new libc. I made a DBS-like package, so it's not too hard to change over to -CURRENT. I'm not in a real rush with it now, because -CURRENT is getting changed rapidly, and I'm trying to concentrate on making a working Debian system. What I'd like to do is get my system working well with -STABLE, and get the base changes merged into Debian. Then playing around with -CURRENT would make more sense to me. Otherwise, I'm combining an unstable userland with an unstable libc and kernel. That's just a bit too hard to debug. > > These packages are pretty stable. I could upload source and binaries for > > it, if you've got your machine taking uploads. :-) > > > > The main trouble I've got with uploading is going through all the > > packages I've built, and sorting out which ones needed patching, if it's > > still necessary, and cleaning up patches where I can. I'm getting near the > > point where I should just run an autobuilder. > > Autobuilders are good. I almost had one up for NetBSD, until I ran into > problems I couldn't reconcile with system headers (fixed in -current, but > I can't get that to work on my box, so...) I've had a few headaches. Here are the major compatibility issues I've found: 1. getopt_long not in libc. Sometimes alloca, too. Some Linux/Debian specific programs are not checking for libiberty functions in configure. 2. unicode/iconv support not in libc. It seems to be missing multibyte character support. 3. utmp is missing a lot of fields. I solved this by writing a utmpx implementation. 4. shadow passwords. I'm writing a library that will hopefully solve this. > > Hmm, no. I didn't spend much time on it. It was some libc function > > missing, I think. That's usually the problem. The only reason I tried to > > build it was because ash depends on it, but ash built fine with > > FreeBSD's make. I had to have ash for makedev, because it won't work > > with bash. So ash becomes a base package on FreeBSD, at least for 4.x. :( > > > > At this point, I have a package I build from the FreeBSD source tree, > > that contains all the programs I need to build that source. The circular > > dependacy is a bit annoying, but that package solves a lot of headaches. > > (Would you believe it requires the FreeBSD version of find in the > > Makefiles?) > > Differing base packages, while annoying, can be dealt with (albeit with > some effort, and it might be easier to try to convince FreeBSD to make it > /bin/sh friendly, I don't know; Debian stuff is *supposed* to not use any > bashisms, for example, in 'core' areas). makedev is apparently incompatible with bash. ash works, and so does /bin/sh from FreeBSD. I just used ash. In 5.0 that goes away, because of devfs, so I'm not too worried about it. > The problem is that, at least for me, I'm not trying to build - and don't > really want present - the majority of the BSD userspace. It won't cooperate > nicely with the Debian userspace, and it will utterly break a lot of things > on the underside (the inverse of the 'needs FreeBSD find' - LOTS of things > assume that they have the Debian-standard 'ls', 'find', etc - though at > least for find, they need to be declaring a dependancy on the findutils > package). > > Having a make-kpkg equivalent with tools to build a kernel (and, for us, > libc and similar stuff) is not out of whack, but I'd say those need to be > kept fairly separate. The BSD make stuff, on the other hand, is used in a > LOT of stuff outside the kernel. > > Of course, that doesn't mean anything but the kernel makes use of the non- > compatible extensions. Hf. My solution was to make a directory /usr/bsd, and I put programs into /usr/bsd/bin. It looks like this: skaro:/# ls /usr/bsd/bin byacc gcovkas kgdb kranlib make objformat xargs colldef gensetdefs kc++filt kld kreadelf mk_cmds patch yacc compile_et install kcc knm ksize mkdepsh yyfix csh kaddr2line kcpp kobjcopy kstrings mknodtcsh findkar kgasp kobjdump kstripmktemp tsort
Re: Multiple topics
On Mon, Apr 08, 2002 at 10:37:41PM -0600, Joel Baker wrote: > On Mon, Apr 08, 2002 at 10:11:46PM -0400, [EMAIL PROTECTED] wrote: > > On Mon, Apr 08, 2002 at 06:54:29PM -0600, Joel Baker wrote: > > > Two main things: > > > > > > 1) FreeBSD 5.0 pre-release... does anyone know if it's GCC 3.x clean? If > > > so, I might futz with trying to do up a chroot based on that, at some > > > point > > > here... unless someone else desperately wants to do it or something. > > > > Kind of. I had problems building it. Ironically, I have -STABLE patched > > to build with the Debian gcc. (3.0.4) Except the kernel, which I use the > > FreeBSD compiler for. :( > > Interesting. It was largely the kernel I was hoping was GCC 3.x compliant. > Guess it isn't yet. Hrrrf. What I ran into with 5.0 was that there was a define that you set to enable compiling with gcc 3.x, and there were some #ifdef's to make it work. However, that define also enabled building gcc 3.x from the FreeBSD source tree, and that failed. Looked like the changes for it aren't quite finished merging in. That was only a week or two ago, so I'd wait a little while yet. > > If you're really interested in this, I can let you have my packaging > > scripts. > > That could be useful; or I could put them up (with permission) on the > archive... These packages are pretty stable. I could upload source and binaries for it, if you've got your machine taking uploads. :-) The main trouble I've got with uploading is going through all the packages I've built, and sorting out which ones needed patching, if it's still necessary, and cleaning up patches where I can. I'm getting near the point where I should just run an autobuilder. > > > 2) pmake (aka /usr/src/usr.bin/make) - the source tree for this on the > > > various BSD flavors differ significantly, but all appear to share some > > > basic level of functionality. How similar are they? I'm looking at taking > > > over the pmake package, and wondering whether stealing just one would > > > suffice, or whether I need to do pmake-netbsd, pmake-freebsd, > > > pmake-openbsd > > > (heck, maybe pmake-bsd44 for the origional BSD 4.4 version?) and allow > > > folks to use /etc/alternatives to select what 'pmake' actually calls. > > > > I needed a lot of other tools to build FreeBSD, especially the kernel, > > so I just included BSD make into that. Debian's pmake package won't > > build for me. > > Bug filed? Reference? I can probably arrange to ensure this, at least, gets > fixed in the relatively near future, if so. Hmm, no. I didn't spend much time on it. It was some libc function missing, I think. That's usually the problem. The only reason I tried to build it was because ash depends on it, but ash built fine with FreeBSD's make. I had to have ash for makedev, because it won't work with bash. So ash becomes a base package on FreeBSD, at least for 4.x. :( At this point, I have a package I build from the FreeBSD source tree, that contains all the programs I need to build that source. The circular dependacy is a bit annoying, but that package solves a lot of headaches. (Would you believe it requires the FreeBSD version of find in the Makefiles?) ---Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple topics
On Mon, Apr 08, 2002 at 06:54:29PM -0600, Joel Baker wrote: > Two main things: > > 1) FreeBSD 5.0 pre-release... does anyone know if it's GCC 3.x clean? If > so, I might futz with trying to do up a chroot based on that, at some point > here... unless someone else desperately wants to do it or something. Kind of. I had problems building it. Ironically, I have -STABLE patched to build with the Debian gcc. (3.0.4) Except the kernel, which I use the FreeBSD compiler for. :( If you're really interested in this, I can let you have my packaging scripts. > 2) pmake (aka /usr/src/usr.bin/make) - the source tree for this on the > various BSD flavors differ significantly, but all appear to share some > basic level of functionality. How similar are they? I'm looking at taking > over the pmake package, and wondering whether stealing just one would > suffice, or whether I need to do pmake-netbsd, pmake-freebsd, pmake-openbsd > (heck, maybe pmake-bsd44 for the origional BSD 4.4 version?) and allow > folks to use /etc/alternatives to select what 'pmake' actually calls. I needed a lot of other tools to build FreeBSD, especially the kernel, so I just included BSD make into that. Debian's pmake package won't build for me. ---Nathan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian GNU/Hurd and Debian GNU/*BSD
On Wed, Mar 20, 2002 at 02:36:09PM -0700, Joel Baker wrote: > Joel has mostly-working patches for 4.1.x, at this stage; most of the > reason that they're not in a .deb is that I need Branden's advice on some > esoterica about X itself and what it builds. I agree with his priorities, > however - which means that most likely, you'll actually see some official > stuff for 4.2.0 (once he releases the packages for it and I can see how > much is broken in between - but most of the patches for *BSD aren't in > areas that seem likely to change, unlike, say, GCC). I also have a more-or-less working patch for FreeBSD, based on Joel's NetBSD patch. I believe I'll wait on 4.2 also. I mainly wanted xlib6-dev, anyway. I need it to build doxygen, so I can build gcc without breaking g++ docs... There seem to be a bunch of problems with the locale and i18n support in libc, and this breaks several of the X programs I've tried to build. Not just gettext, but UTF and similar things seem to be missing. I've packaged GNU libiconv, and that helps some, but I still have no multi-byte character functions, and I'm not sure what to do about it. > On a side note - work has been insane, and thus, very little packaging work > has gotton done recently. I don't really know if, or when, this will change > (and if I change jobs, I lose my build machine entirely, so...) You have my sympathies. I'm between jobs now, but my last one was very demanding. (If anyone wants to hire a debian developer, let me know... :-) ---Nathan
Re: Booting
On Sun, Mar 17, 2002 at 06:55:26PM +0100, Jeroen Dekkers wrote: > This is certainly true. It's a wishlist item, it would be nice if all > free kernels would use multiboot. I've heard that grub will at least > be partly rewritten to make some new features possible, it might also > be the "extra environmental stuff" but I'm not sure what you mean with > it. It'd be nice, but I think the BSD's are going to be pretty skeptical. FreeBSD, in particular, has a very nice boot loader. I rather like it, it reminds me of OpenBoot. The man page for loader.conf describes some of the environment stuff I mentioned: http://www.freebsd.org/cgi/man.cgi?query=loader.conf&apropos=0&sektion=0&manpath=FreeBSD+4.5-stable&format=html
Re: Booting
On Sun, Mar 17, 2002 at 05:25:12PM +0100, Jeroen Dekkers wrote: > On Sat, Mar 09, 2002 at 06:30:27PM -0700, Joel Baker wrote: > > Honestly? I'd really love to see GRUB achieve it's nominal purpose - GRand > > Unified Bootloader. Making it capable of compiling on, and booting, *BSD > > machines seems like a major step forward for it, and it shouldn't be all > > that hard - it's just one kernel and one primary filesystem (FFS) to make > > sure function, to support the vast majority of BSD-land. > > I think the best way is to make multiboot BSD kernel images. The > multiboot standard is very flexible, it's included in the grub > documentation. That would indeed be nice. It also is not something I'm going to waste my time on. FreeBSD has a bootloader that works just fine. Works a lot like grub, in fact. However, there is a lot of extra environmental stuff that it does, and I'm not sure that grub could support that without a lot of extra code. IMHO, this is a case of fixing something that isn't broken. And at this point in time, it's just not worthwhile. Maybe once the porting is farther along. For now, I'd rather concentrate on fixing the things that are, in fact, broken. See http://people.debian.org/~utsl/freebsd-i386/status.html for more info. ---Nathan
Re: Booting
On Mon, Mar 11, 2002 at 02:24:55AM +, Tony Finch wrote: > FreeBSD has a directory /boot too (in -STABLE it holds the stage 3 loader > and its configuration, and in -CURRENT i believe the kernel(s) and > modules have moved in there too). So it would seem sensible to make > NetBSD follow the others. (Does NetBSD/i386 not use /usr/mdec any more?) I've been using /boot for the boot loader, and /lib/modules for kernel modules. At present, I have the boot loader packaged together with the kernel, but that may change later. AFAICS, on FreeBSD the paths for kernel, boot loader, modules, etc. are customizable, so I see no reason not to use standard Debian locations. They aren't really that different, and are pretty reasonable.
Re: ifupdown
What did you have to do to it? I looked at it, but didn't have much luck figuring it out. That source is a horrible mess. As for the base system: Take a look at debootstrap. It has lists of packages that it wants to install. I'm not sure all of them are base exactly, but if debootstrap wants them, they're probably needed. Do you have dhcp working? On Sun, Mar 03, 2002 at 01:18:53AM +, Matthew Garrett wrote: > I've managed to get this to approximate functionality. What are we still > missing from a base system at this point? > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Regarding possibly porting Debian GNU/BSD to the PowerPC.
On Thu, Feb 28, 2002 at 10:49:17PM +1100, matthew green wrote: > ps: it seems to me that most people so far have not touched the > kernel, but rather have been working on userland issues... i dunno > i just provide a netbsd developer's POV. :-) I packaged the FreeBSD kernel. It wasn't too bad except that I had to use the FreeBSD gcc and binutils, because it wouldn't build with gcc 3.0. So I have a box that boots with everything in a package, including libraries and kernel. I think NetBSD should be easier, since it's more supportive of cross compiling, and probably less sensitive to the gcc version.
Re: PAM
On Mon, Feb 25, 2002 at 11:26:37AM +1100, matthew green wrote: > >I thought sockets weren't affected by read-only filesystem. Just out >of curiousity, why should they be if the node is already there? There'd >be no actual writing to the filesystem. Do fifo's not work either? > > creating a socked or a named pipe is creating a file on the > file system. you need to be able to write to it. this is > simply enforcing the same semantics as elsewhere... I understood that. I just didn't realize you had to delete and re-create them each time. I guess you can't reuse the inode. I thought you could.
Re: PAM
On Sun, Feb 24, 2002 at 10:16:44PM +1100, matthew green wrote: > >On a separate note, msyslogd builds happily but uses /dev/log as its >socket by default. The NetBSD logging functions seem to be expecting >/var/run/log - symlinking the two work, and you can pass an option to >msyslog to make it produce /var/run/log instead. What's the preferable way >to do this? > > > the point of /var/run/syslog is so that / has no files written at > boot time, given that /var is not /. infact, some of us now run > with /var/run as an tiny mfs... > > not writing to / means that one can have a read-only system, with > only /var/run being required, and this can be located not on the > disk filesystem (it's not preserved between reboots.) I thought sockets weren't affected by read-only filesystem. Just out of curiousity, why should they be if the node is already there? There'd be no actual writing to the filesystem. Do fifo's not work either? > msyslogd should probably have an option to look elsewhere... making > it use /dev/log again would remove the above feature. (actually, > probably lots of other things break it but why make it worse? :-) Msyslog has the capability. FYI, I believe it's available in /usr/ports. I know it has a separate module for BSD kernel logs as opposed to Linux ones. Works well. :-) > the prior art for syslogd in this case are the -p and -P flags i > added to netbsd a few years back: > > -pSpecify the pathname of an log socket. Multiple -p options > create multiple log sockets. If no -p arguments are created, > the default socket of /var/run/log is used. > > -PSpecify the pathname of a file containing a list of sockets > to be created. The format of the file is simply one socket > per line. > > > > FYI: it was basically eventless for the move to /var/run/log. it > affected people using chroot jails -- but i helped those people > (the set of which of course includes myself) in even better ways by > adding the -p and -P flags. :-) > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: utmpx
On Sun, Feb 24, 2002 at 10:09:37PM +1100, matthew green wrote: > > > FYI: > > > a basic implementation of utmpx has been commited to netbsd-current, > completely indepedant of any work done here... i don't believe it is > 100% complete yet. When I was looking around on Google, I saw mention of it in a NetBSD mailing list. I wasn't aware it had been committed. From what I read, it sounded like it hadn't been completed, and might not meet my needs, anyway. I needed something sufficiently compatible with what Linux has that I could build sysvinit. It seemed to me that the best way to do that, would be to do a clean implementation of the standard for utmpx.h (in SUSv2) under a BSD license. So that's what I did. You are welcome to suggest improvements, merge with your own implementation, or do whatever else you want to with it. At the moment, what I have meets my needs well. I will look at the NetBSD implementation when I get a chance, and see if it suggests any improvements to my own code, though. ---Nathan
Re: PAM
I'd be interested in looking at that patch for PAM. I started on it, but got sidetracked. I'm not sure what the right thing for msyslogd. I had thought /dev/log was standard on Unix systems, but I see that FreeBSD puts in /var/run, too. The odd thing is that I have it at /dev/log on FreeBSD Debian, and seems to work... Maybe I better test it more. AFAIK, only syslogd, and the syslog function in libc need to use that socket, so it shouldn't really matter where it is, as long as both can find it. On Sun, Feb 24, 2002 at 04:16:25AM +, Matthew Garrett wrote: > I have PAM 0.75 source that builds and appears to work if I use shadow > with it. 6 patches from the NetBSD port seem to be enough to get it to > compile, but I needed to add a check for pwent->pwexpire being 0 (the code > assumes that if the current time is greater than the expiry time then the > password has expired, even if there isn't an expiry time set). With that > done, I can rebuild my patched shadow utils with PAM and login seems to > work. > > On a separate note, msyslogd builds happily but uses /dev/log as its > socket by default. The NetBSD logging functions seem to be expecting > /var/run/log - symlinking the two work, and you can pass an option to > msyslog to make it produce /var/run/log instead. What's the preferable way > to do this? > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: make-bsd, pmake, and /usr/share/mk, oh my
On Tue, Feb 19, 2002 at 08:59:15PM -0700, Joel Baker wrote: > So... pmake claims to be "BSD 4.4 make", and in fact appears to be a not- > unreasonable copy of the NetBSD make sources. Is there any particular > reason that the make-bsd and netbsd-mk packages in the chroot can't be > replaced by the Debian-standard pmake package, if it gets updated (it's > a few revisions behind, it looks like, but that's a wishlist bug for the > author and easy to patch against for us). FWIW, pmake compiles on FreeBSD, but doesn't seem to actually work. It keeps complaining that it doesn't know how to make pmake... I was trying to use it to build ash, but gave up and hacked the rules file to use the FreeBSD make. (I wanted ash for MAKEDEV, which of course, doesn't work with bash...) ---Nathan
Re: sys/socket.h and source defines
On Mon, Feb 18, 2002 at 04:19:56PM -0700, Joel Baker wrote: > As best I can tell, with the native NetBSD sys/socket.h, if a problem in > any way defines (or triggers definition of) _POSIX_SOURCE or _XOPEN_SOURCE, > anything which calls sys/socket.h will break horribly (since it uses values > from types.h - which it also fails to include on it's own - which are only > valid if not using POSIX sources, specifically u_char rather than u_int8_t) > > Can anyone offer solutions to this? It's breaking a number of packages > which, for various reasons, declare one of these two, and then include some > file which, in turn, includes sys/socket.h I'd look at adding #ifdef's into sys/socket.h to switch to u_int8_t if _POSIX_SOURCE is defined.
Re: utmpx implementation
On Fri, Feb 15, 2002 at 12:55:37PM -0500, Jimmy Kaplowitz wrote: > On Thu, Feb 14, 2002 at 11:23:20PM -0500, [EMAIL PROTECTED] wrote: > > I've implemented utmpx for FreeBSD, and placed it under BSD license. This > > should be a standards-compliant (SUSv2) implementation, that is > > approximately > > equivilent to the utmp in glibc or Solaris. The major difference from Linux > > is that it uses /var/run/utmpx, and getutent becomes getutxent. > > Why these different names, then? I would think that it would help > compatibility with Linux programs to use the non-"x" names. Or is there > another standard that specifies the "x"? SUSv2 specifies this, so portable code should work with it, because Solaris and quite a few other systems use it. I think it may have been in SysV, but I'm not sure. Glibc implements this by defining these functions to be the same as the utmp ones. That satisfies the standard, but other systems don't all do it that way, and code that assumes utmp has everything isn't portable. By implementing it this way, I get standards compliance, and I also get the ability to offer this source to the BSD's for inclusion. Just because it supports runlevels doesn't mean you have to use them...
utmpx implementation
I've implemented utmpx for FreeBSD, and placed it under BSD license. This
should be a standards-compliant (SUSv2) implementation, that is approximately
equivilent to the utmp in glibc or Solaris. The major difference from Linux
is that it uses /var/run/utmpx, and getutent becomes getutxent.
I haven't tested this thing very heavily yet, so please look it over closely.
If someone would like to take on writing some code to test it thoroughly, I'd
be very appreciative. I have it working with sysvinit (major reduction in the
size and ugliness of that patch) and shellutils. I'll be better able to tell
how well it's working after I get Matthew Garrett's libshadow ported over.
Enjoy,
---Nathan
/*
* Copyright (c) 2002
* Nathan Hawkins. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*
*/
#ifndef _UTMPX_H_
#define _UTMPX_H_
#include
#include
#define _PATH_UTMPX "/var/run/utmpx"
#define UTMPX_FILE _PATH_UTMPX
/* features in utmpx */
#define _HAVE_UT_PID1
#define _HAVE_UT_ID 1
#define _HAVE_UT_TV 1
#define _HAVE_UT_TYPE 1
#define _HAVE_UT_HOST 1
/* size of character arrays in struct utmpx */
#define UT_LINESIZE 32
#define UT_NAMESIZE 32
#define UT_HOSTSIZE 256
struct exit_status {
short int e_termination;/* Process termination status. */
short int e_exit; /* Process exit status. */
};
struct utmpx
{
pid_t ut_pid;
char ut_id[4];
/* reserve space for IPv6 addresses */
u_int32_t ut_addr6[4];
long int ut_session; /* used by X? */
struct timeval ut_tv;
struct exit_status ut_exit;
short int ut_type;
char ut_line[UT_LINESIZE];
char ut_user[UT_NAMESIZE];
char ut_host[UT_HOSTSIZE];
char _unused[20];
};
/* for compatibility */
#define ut_name ut_user
/* values for ut_type */
#define EMPTY 0 /* Empty struct */
#define RUN_LVL 1 /* SysV runlevel */
#define BOOT_TIME 2 /* System boot */
#define NEW_TIME 3 /* Mark new time at time change */
#define OLD_TIME 4 /* Mark old time at time change */
#define INIT_PROCESS 5 /* Process started by init */
#define LOGIN_PROCESS 6 /* User login */
#define USER_PROCESS 7 /* Normal process. */
#define DEAD_PROCESS 8 /* Terminated process. */
#define ACCOUNTING 9
__BEGIN_DECLS
void endutxent(void);
void setutxent(void);
struct utmpx *getutxent(void);
struct utmpx *getutxid(const struct utmpx *);
struct utmpx *getutxline(const struct utmpx *);
struct utmpx *pututxline(const struct utmpx *);
void utmpxname(const char *);
__END_DECLS
#endif /* !_UTMPX_H_ */
/*
* Copyright (c) 2002
* Nathan Hawkins. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEG
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 06:34:14AM +, Tony Finch wrote: > In article <[EMAIL PROTECTED]> you write: > > > >I need to look into it a bit more, and figure out exactly what FreeBSD does > >and doesn't do with this. > > Everything you need to know is in /usr/src/sys/kern/imgact_elf.c: > > /* We support three types of branding -- (1) the ELF EI_OSABI field >* that SCO added to the ELF spec, (2) FreeBSD 3.x's traditional string >* branding w/in the ELF header, and (3) path of the `interp_path' >* field. We should also look for an ".note.ABI-tag" ELF section now >* in all Linux ELF binaries, FreeBSD 4.1+, and some NetBSD ones. >*/ > > There's a table of the supported ABIs which is scanned when executing an > ELF binary. On the first scan an ABI is found if either the OSABI field > matches (number 1 above) or if the second eight bytes of the ELF header > match (which used to be "FreeBSD" instead of nulls as is usual) (number > 2 above). On the second scan an ABI is found if the file's .interp > section matches (number 3 above). To work correctly with a normal gcc (not hacked like the one in the FreeBSD sources), it needs to do the .note.ABI-tag check. #3 doesn't work for static binaries because they don't have an interpreter, which would be why my test box didn't boot the first time I tried it. I guess I'll have to see about coding support for .note.ABI-tag sometime. Think they'd accept a patch for that?
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 11:07:18AM +0100, David Schmitt wrote: > On Mon, Feb 11, 2002 at 01:25:51AM -0500, [EMAIL PROTECTED] wrote: > > 4. Drop keeping metadata in package filenames. Make them just a unique > >string, assigned when the package is installed into the archive. > >That gets rid of the need to add something to the filename to > >distinguish i386 from sparc packages. Just use the Packages files, > >and the control fields from the packages themselves. I'd be in > >favour of going further: use one Packages file, and determine > >available packages based on the tags your kernel and libc support. > > Which would lead to the problem, that in the pool/ there would be stuff > like: > > pool/main/p/package/: > > package_Version-1_abcde.deb > package_Version-1_lsahd.deb > package_Version-1_iorzq.deb > package_Version-1_mbmnb.deb > package_Version-1_poiuz.deb > package_Version-1_mjuhb.deb > > > Essentially rendering manual download impossible. Actually, I was thinking of going a bit further than that, and drop the package names and versions from the filenames too. Just think of a squid cache. I don't see manual downloads or parital mirroring as a huge problem. It would simply mean that there'd need to be tools to locate the files. For manual downloads, a CGI that returns a URL for the right file could work. Or possibly just a slightly enhanced apt or similar tool. > This is a question to Marcus Brinkmann: > > How can one distinguish > > package_1.0-1.deb (i686,glibc,mmx) and > package_1.0-1.deb (sparc,netbsd4) > > in the pool (i.e. filesystem)? > > I know, in your doc, you don't explicitly specify an 'encoding' for this > dependency information, but people (as simpleminded as I am) would think > about some extra entry in the Depends: field, which wouldn't help much > with filesystemlayout in the mirrors as Philip Charles mentioned in > regard to partial mirrors and things as pointet out above. That's why I'd like to take those parts out of the filename, and put together tools to handle it. It should be a matter of giving a partial mirror program a pattern you want to mirror with, like "sparc and netbsd," and it generates a list of files to mirror. That's fairly painless, and filesystem layout can be just a matter of keeping directories from getting too many files, and filesystems from overfilling. I maintained a program that tracked about 450,000 files, all of which were had information encoded in the filenames. (Ok, it didn't start that large, but it got there fast.) It was a nightmare until I moved the metadata into a database, and renamed every file to a number. I could then do lookups in the database table, and locate the files much more quickly. (I gained an order of magnitude speed increase in my user interface.) I also was able to balance out the directories. I had some directories with 10,000 files, and other with a few hundred. When I was done, I had 4112 directories, with about 100 files in each. I think a similar approach would be helpful for Debian. Database tables can be indexed, and can handle much more complicated queries than filesystems can. Having information in the filename really doesn't help much of anything except manual downloads, and I think that can be managed.
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 12:47:32PM +0100, Marcus Brinkmann wrote: > On Mon, Feb 11, 2002 at 01:25:51AM -0500, [EMAIL PROTECTED] wrote: > > I think you could say that a binary's environment is made up these things: > > Whatever. The exact set of virtual package names that make up the > architecture depends on your needs (I called this the universe). > > Of course you have to specify this if you want to use a flexible > architecture system. But it should not be part of the design of the > architecture system (eg nothing should depend on the selection of such > interface names). Actually, I think you'd want to standardize the naming. I was just trying to establish a concrete example. I didn't follow through well enough, though. > > 1. Drop the Architecture field. > > 2. Add two new multi-value fields. I'll call them Env-Provides, and > >Env-Depends. Probably someone else can think of better names. > > Why do you want to replace one evil with another? The existing Provides: > and Depends: can cope with non-existing package names (called virtual > packages). Those are exactly what you need for the interfaces like the CPU > etc. True, but that makes it difficult to distinguish between between regular dependacies and these architecture-type dependacies in software. > > 3. Make those fields provide and depend on tags which are completely > >separate from package names. This makes it easy to distinguish > >what packages a package depends on from the environment it's been > >built for. > > I don't understand what you mean here. Can you elaborate? > > > It also makes it easier to make an index of packages > >for a particular architecture combination, > > Why? Simple example: you want to be able to quickly find all possible packages that would work on your system. At that point, it'd be very useful to have a file that looks like: Package: telnet Env-Depends: i386, elf, gnu-libc6 Package: wdiff Env-Depends: alpha, elf, gnu-libc6.1 It's called an index, and it's commonly used in databases to speed things. I think we should also consider using a db3 databases rather than flat text files, but that's a different issue... > > and doesn't pollute the > >package namespace with a lot of virtual packages. > > Beauty is in the eye of the beholder. I think having two fields duplicated > without any real technical advantage is adding to ugliness. The advantage is in making it easier to find things. It'd be easier to tell the difference between packages that could be installed, if we had some other package installed, from those that can't be installed because of architectural dependacies. > > 4. Drop keeping metadata in package filenames. Make them just a unique > >string, assigned when the package is installed into the archive. > > I don't understand at all what you are aiming at here. > > >That gets rid of the need to add something to the filename to > >distinguish i386 from sparc packages. > > Can you cite an example? Sure: apt_0.5.4_freebsd-i386.deb vs. apt_0.5.4_i386.deb If you drop the Architecture concept, you have to find another way to name the files. I'm saying why put any information into the filename? You can get at it with dpkg, anyway, and it's in the Packages files, so why does it need to be in the name? I'm thinking of squid caches. Squid doesn't put any information into filenames, it just load balances across directories, and locates files with its database. I don't see why that wouldn't be a good solution here. > >favour of going further: use one Packages file, and determine > >available packages based on the tags your kernel and libc support. > > I think you misunderstand the purpose of the packages file. The packages > file determines what is in the distribution for a specific architecture. So > dinstall (katie, whatever) would decide if a new package in the pool would > enter a packages file or not based on the dependencies in the package. > > I am probably misunderstanding you, but without an idea want you want to > achieve with 4 above I have trouble to see why you would want to change > that. It'd be unnecessary. If you have the dependacies in the Packages file, you can trivially determine which packages are available to your system in dselect or apt. All you have to do is find dependacies that can't be satisfied without replacing your kernel. And if you install a kernel that supports another sort of binary, you can automatically show more available packages. My suggestion about using new fields rather than Depends was aimed at making that faster and easier to determine, but with a real database, rather than text files, it'd probably be unnecessary. Indexes would solve that nicely. Having distributions for particular architectures wouldn't be required. All you need is stable, testing and sid. Makes dinstall's job eas
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 03:37:36AM +0100, Marcus Brinkmann wrote: > On Sun, Feb 10, 2002 at 09:28:35PM -0500, [EMAIL PROTECTED] wrote: > > Like libc.so.4 on FreeBSD, soon to be libc.so.5? Not compatible with libc5 > > on > > Linux. It's confusing, but I don't know any good way around it. > > Well, then you have to include the OS-ABI field into the dependency name for > all library dependencies. As the information is easily available from the > binary with objdump, this can be as automatic as the soname. You have to > make such decisions based on the universe you live in. If you build a > distribution that only ever has binaries from a single ABI tag, you don't > need to include it. But if you have different ABI tags you want to support, > you mangle it into the dependency name. I think you could say that a binary's environment is made up these things: 1. processor type (i386, alpha, sparc, etc.) 2. processor mode (64/32) 3. kernel (linux, hurd, whatever) 4. object format (ELF/a.out) 5. object format subtypes or emulations 6. libc That ought to be sufficient to define a binaries requirements. I'd like to see something flexible enough to deal with that much complexity, but not so unwieldy that it can't be made to work. So I'll make my suggestion: 1. Drop the Architecture field. 2. Add two new multi-value fields. I'll call them Env-Provides, and Env-Depends. Probably someone else can think of better names. 3. Make those fields provide and depend on tags which are completely separate from package names. This makes it easy to distinguish what packages a package depends on from the environment it's been built for. It also makes it easier to make an index of packages for a particular architecture combination, and doesn't pollute the package namespace with a lot of virtual packages. 4. Drop keeping metadata in package filenames. Make them just a unique string, assigned when the package is installed into the archive. That gets rid of the need to add something to the filename to distinguish i386 from sparc packages. Just use the Packages files, and the control fields from the packages themselves. I'd be in favour of going further: use one Packages file, and determine available packages based on the tags your kernel and libc support. It's a little radical, but I think it could work well. > > Bear in mind that quite a few systems already support multiple kinds of > > binaries, > > My text was written with that in mind. > > > Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark > > it's binaries. > > The GNU/Hurd does it as well. > > > Of course, dpkg doesn't know that... > > dpkg doesn't know a lot of things ;) > > > That should be correct. A distribution already is just a Package file with > > references to files in the pool. No real change there. The difference would > > seem to be in the generation of the Packages file. > > Yes, exactly. And you need some differences in the algorithm that decides > when to compile a package from source for a given architecture (the pool > might contain a compatible but inferior binary package). But that's not a problem for the guy who makes the CD's.
Re: thoughts on architectures
On Mon, Feb 11, 2002 at 04:41:07AM +0100, Marcus Brinkmann wrote: > On Mon, Feb 11, 2002 at 02:35:50PM +1100, matthew green wrote: > > > >> Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field > > to mark > >> it's binaries. > > > >The GNU/Hurd does it as well. > > > > > > hmm, last i looked hurd used an ELF note, like NetBSD. > > Yes, sorry, I thought that was he meant (and he did :). I did not even know > about a special OSABI field. > > ulysses:/tmp/x# objdump -s -j .note.ABI-tag /bin/bash > > /bin/bash: file format elf32-i386 > > Contents of section .note.ABI-tag: > 8048108 0400 1000 0100 474e5500 GNU. > 8048118 0200 1e00 > ulysses:/tmp/x# objdump -s -j .note.ABI-tag /gnu/bin/bash > > /gnu/bin/bash: file format elf32-i386 > > Contents of section .note.ABI-tag: > 8048100 0400 1000 0100 474e5500 GNU. > 8048110 0100 There's a field in the ELF header called OS/ABI. Readelf -h finds it, and it looks like this: Normal binaries: OS/ABI:UNIX - System V FreeBSD binaries: OS/ABI:UNIX - FreeBSD I need to look into it a bit more, and figure out exactly what FreeBSD does and doesn't do with this.
Re: thoughts on architectures
On Sun, Feb 10, 2002 at 10:34:36PM +0100, Marcus Brinkmann wrote: > Hi, > > (I am not subscribed. You might CC me on interesting threads/sub-threads) > > From: [EMAIL PROTECTED] > "The major oversight is that he completely fails to mention libc. And for us, > that remains a big issue. Right now, and for immediately forseeable future, > I'm not going to be using glibc." > > There is nothing special about libc. It Depends on some kernel, cpu and > possibly other stuff, and provides a library api (soname). > > Sonames should be handled completely automatic by the build system (in > Debian they aren't) with optional overrides in case of incompatible libs > with the same soname (don't do that, though). Like libc.so.4 on FreeBSD, soon to be libc.so.5? Not compatible with libc5 on Linux. It's confusing, but I don't know any good way around it. > Programs also might depend on an object format, or you might assume the > object format is common for all programs depending on the same interfaces. > EG, if you assume a common object format, all packages depending on > libc.so.6 are ELF by definition. Otherwise the object format has to be > coded into the dependencies. Bear in mind that quite a few systems already support multiple kinds of binaries, and there are more on the way. Sparc, ia64 and x86-64 (not sure if x86-64 is a Debian arch yet) all can do both 64 and 32 bit binaries. I think s390 might too, but I'm not sure. The packaging system needs to know how to deal with the situation. The BSDs can run Linux binaries, and also run on some of the same 64/32 bit platforms. > A program that depends only on i386, libc.so.6 and optionally elf, will run > on all systems that have libc.so.6, understand the elf object format and can > emulate or provide i386 instructions. That's what I was looking for. Essentially, you're setting up dependacies based on CPU and API's needed, rather than using just architecture. That's a good idea, and I'm in favour of it. However, it won't really help me all that much, because just about everything is going to depend on libc6, and it doesn't work on FreeBSD. Also, FreeBSD (and possibly NetBSD as well) uses the ELF OSABI field to mark it's binaries. That's how it knows when to start emulating Linux syscalls. So it's effectively using an altered ELF format on i386, as well as a different libc. But it's capable of supporting libc6 in Linux emulation mode. Of course, dpkg doesn't know that... > Philipp: > "However, we CD image builders are simple folk with an include/exclude > mentality and not much time for subtle distinctions." > > My proposal shall not worry you. A distribution will look similar to the > distributions that exist in Debian right now. There is no need to change > how a distribution will look to a user. For you and others, it will simply > be a list of packages to pick from, out of a pool. That should be correct. A distribution already is just a Package file with references to files in the pool. No real change there. The difference would seem to be in the generation of the Packages file.
Re: Status of various major things
On Sun, Feb 10, 2002 at 11:14:18AM -0700, Joel Baker wrote: > XFree86: Builds cleanly, seems to run. Talking to the maintainer about some > differences in what it builds between the normal and NetBSD versions, and > how to resolve those. That is, however, the only obvious remaining issue > before the packages are public. (Well, technically it still has a build > dependancy on bsdmainutils, which breaks, but it only uses 1 utility, so I > have that installed manually). > > GCC 2.95: Fails many of it's build tests. Also, in practice, appears to > rather impressively break any C++ code on the system, whether compiled with > the old or new GCC version. I have reverted my chroot, and things are much > happier. I'll look into it, but this is a non-trivial problem. I had problems with it, too. Main problem seemed to be with libstdc++. 3.0 fixed that. > GCC 3.0: Doesn't build with the current release in sid, which *looks* like > it's a 3.0-branch CVS from last week (3.0.4 or so). Going to try to dig up > a current development branch so that I can drop it's tarball in place, and > see if that works better. Also build-depends on a newer binutils, which > is reported to break things. Hmm. I'm running gcc 3.0.3ds3, and it seems to work ok. binutils 2.11.92.0.12.3 does break badly. It core dumps linking c++ code, so I backed it out, and am running 2.11.90.0.7. > GCC defaults: Currently compiled to default to 2.95. However, I think that > 3.0 is a much better default for new ports, and would prefer to use this > instead, once we have a working set of 3.0 packages. Folks should give > opinions on this one... > > Misc: The regex routines in libc appear to be the home of, or trigger of, > stack corruption. This is what is causing the segfaults in ed, and I > suspect it is also causing the 'sed' build failures. Compiling and dumping > a new libc into the chroot did not produce any difference, however. It may > be compiler issues (thus the efforts on getting a sane set of GCC packages > which has failed so far). I suspect that ed's doing something that compiles, but doesn't actually work with that implementation of regex. Have you tried linking against a different regex library? > Native packaging: I'm likely to play with trying to package at least some > of the /usr/src/lib stuff later today (such as libc, libarch, etc). On the > topic of libarch: the source should be called libarch. Should the binaries > be called 'libarch' as well, or 'libi386', 'libsparc', etc? Personally, I > vote for 'libarch', because otherwise the dependancies will end up being a > huge mess... and since switching arches includes replacing 90% of all the > *other* packages, as well, this shouldn't be a problem. Thoughts? If you'd like, you could have the debian directory from my FreeBSD source package. It'd be a place to start. ---Nathan
Re: patch to add FreeBSD support
On Sun, Feb 10, 2002 at 11:48:56AM -0600, Adam Heath wrote: > On Sun, 10 Feb 2002, Wichert Akkerman wrote: > > > Please don't use perl there, I want to get rid of all perl in dpkg. > > This is during the build of dpkg. That's a completely different area then the > running of dpkg. Yes, it only affects configure. There's no equivilent patch for dpkg --print-architecture. That still has to have an exact match in the archtable. Changing that would add a dependacy on a regex library. I've configured gcc as i386-unknown-freebsd4, because gcc's configure knows that versions < 4 are a.out. That allows --print-architecture to find the arch by i386-freebsd4 in the archtable. I may have to add freebsd5 for 5.0 later, but that's much easier than dealing with every minor release, or patching every configure and config.guess in Debian. At some point, it may be desirable for config.guess to be able to distinguish Debian FreeBSD from regular FreeBSD. That could solve the problem here nicely. ---Nathan
Re: patch to add FreeBSD support
On Sun, Feb 10, 2002 at 01:44:52AM +0100, Wichert Akkerman wrote:
> Previously [EMAIL PROTECTED] wrote:
> > --- dpkg/utils/start-stop-daemon.c Fri Feb 1 23:28:13 2002
> > +++ dpkg-1.10-freebsd/utils/start-stop-daemon.c Fri Feb 8 04:36:55 2002
> > @@ -707,7 +709,9 @@
> >
> > /* WTA: this needs to be an autoconf check for /proc/pid existance.
> > */
> > -#if defined(OSLinux) || defined (OSsunos)
> > +
> > +/* WART: FreeBSD also has /proc support */
> > +#if defined(OSLinux) || defined (OSsunos) || defined(OSfreebsd)
>
> Removed the WART comment, that was already covered by the statement
> above that.
That was an inheritance from Wartan Hachaturow's patch, some months ago. It's
probably not important...
> > diff -urN dpkg/configure.in dpkg-1.10-freebsd/configure.in
> > --- dpkg/configure.in Sat Feb 2 17:58:58 2002
> > +++ dpkg-1.10-freebsd/configure.in Fri Feb 8 23:35:45 2002
> > @@ -93,7 +93,7 @@
> >
> > dpkg_archset=''
> > AC_MSG_CHECKING(Debian architecture)
> > -dpkg_archset="`awk '$1 == "'$target_cpu-$target_os'" { print $2 }'
> > $srcdir/archtable`"
> > +dpkg_archset="`perl -ane 'if("'$target_cpu-$target_os'"=~m#^$F[0]$#)
> > {print $F[1]; exit(0)}' archtable`"
> > # Finish off
> > if test "x$dpkg_archset" = "x"; then
> > AC_MSG_RESULT([$target_cpu-$target_os, but not found in archtable])
>
> Please don't use perl there, I want to get rid of all perl in dpkg.
Sorry, it was the first implementation that came to mind. I'll see if I can
remember how to use awk well enough to get it to do that. Is the basic concept
acceptable?
Re: patch to add FreeBSD support
On Sat, Feb 09, 2002 at 05:39:16PM +0100, Wichert Akkerman wrote:
> Previously [EMAIL PROTECTED] wrote:
> > Please consider this patch, which adds FreeBSD support to dpkg. It is based
> > on a fresh checkout from CVS, so it should apply easily.
>
> Can you please split the patch in multiple parts:
>
> 1. make functions static
> 2. type changes
> 3. support for wildcards
> 4. adding freebsd to archtables
Ok, I've split it up:
1 & 2: Not sure what you're looking for here. I put the start-stop-daemon
changes into patch #1. The function changes were to make them match
the prototypes at the top of the file. I haven't got this part really
well tested yet, so it might be a good idea to hold off on applying
this patch for a while.
3: Fixed a major problem with this, while I split it off. I had hardcoded my
arch in, instead of the target variables. Oops. It's now possible to use
perl-style regular expressions in archtable. These are only used in
configure, not in dpkg itself, so the arch in the gcc-lib path still has
to be in archtable.
4: Adjust FreeBSD archs in archtable and dpkg-architecture.
5: Fix __va_copy test in configure.in. The one that was there didn't really
make sure it works.
6: Fix dpkg-shlibdeps to work on FreeBSD. The ldd on FreeBSD doesn't work on
shared libraries. ldconfig -r does approximately what ldconfig -p does on
Linux, and sort of provides the same information as ldd would have.
diff -urN dpkg/utils/start-stop-daemon.c
dpkg-1.10-freebsd/utils/start-stop-daemon.c
--- dpkg/utils/start-stop-daemon.c Fri Feb 1 23:28:13 2002
+++ dpkg-1.10-freebsd/utils/start-stop-daemon.c Fri Feb 8 04:36:55 2002
@@ -32,6 +32,8 @@
# define OSOpenBSD
#elif defined(hpux)
# define OShpux
+#elif defined(__FreeBSD__)
+# define OSFreeBSD
#else
# error Unknown architecture - cannot build start-stop-daemon
#endif
@@ -43,7 +45,7 @@
# include
#endif
-#if defined(OSOpenBSD)
+#if defined(OSOpenBSD) || defined(OSFreeBSD)
#include
#include
#include
@@ -675,7 +677,7 @@
{
#if defined(OSLinux) || defined(OShpux)
if (execname && !pid_is_exec(pid, &exec_stat))
-#elif defined(OSHURD)
+#elif defined(OSHURD) || defined(OSFreeBSD)
/* I will try this to see if it works */
if (execname && !pid_is_cmd(pid, execname))
#endif
@@ -707,7 +709,9 @@
/* WTA: this needs to be an autoconf check for /proc/pid existance.
*/
-#if defined(OSLinux) || defined (OSsunos)
+
+/* WART: FreeBSD also has /proc support */
+#if defined(OSLinux) || defined (OSsunos) || defined(OSfreebsd)
static void
do_procinit(void)
{
@@ -768,8 +772,8 @@
#endif /* OSHURD */
-#if defined(OSOpenBSD)
-int
+#if defined(OSOpenBSD) || defined(OSFreeBSD)
+static int
pid_is_cmd(pid_t pid, const char *name)
{
kvm_t *kd;
@@ -810,8 +814,8 @@
return (strcmp(name, start_argv_0_p) == 0) ? 1 : 0;
}
-int
-pid_is_user(pid_t pid, int uid)
+static int
+pid_is_user(pid_t pid, uid_t uid)
{
kvm_t *kd;
int nentries; /* Value not used */
@@ -833,7 +837,7 @@
return (proc_uid == (uid_t)uid);
}
-int
+static int
pid_is_exec(pid_t pid, const char *name)
{
kvm_t *kd;
diff -urN dpkg/configure.in dpkg-1.10-freebsd/configure.in
--- dpkg/configure.in Sat Feb 2 17:58:58 2002
+++ dpkg-1.10-freebsd/configure.in Fri Feb 8 23:35:45 2002
@@ -93,7 +93,7 @@
dpkg_archset=''
AC_MSG_CHECKING(Debian architecture)
-dpkg_archset="`awk '$1 == "'$target_cpu-$target_os'" { print $2 }'
$srcdir/archtable`"
+dpkg_archset="`perl -ane 'if("'$target_cpu-$target_os'"=~m#^$F[0]$#) {print
$F[1]; exit(0)}' archtable`"
# Finish off
if test "x$dpkg_archset" = "x"; then
AC_MSG_RESULT([$target_cpu-$target_os, but not found in archtable])
diff -urN dpkg/archtable dpkg-1.10-freebsd/archtable
--- dpkg/archtable Tue Jan 1 13:16:37 2002
+++ dpkg-1.10-freebsd/archtable Fri Feb 8 01:17:11 2002
@@ -43,6 +43,8 @@
hppa1.1-linux-gnu hppahppa
hppa2.0-linux-gnu hppahppa
hppa64-linux-gnu hppahppa
+i386-freebsd.+ freebsd-i386freebsd-i386
+i386-freebsd4 freebsd-i386freebsd-i386
i386-freebsd freebsd-i386freebsd-i386
s390-linux-gnu s390s390
s390-ibm-linux-gnu s390s390
diff -urN dpkg/scripts/dpkg-architecture.pl
dpkg-1.10-freebsd/scripts/dpkg-architecture.pl
--- dpkg/scripts/dpkg-architecture.pl Tue Jan 1 14:07:49 2002
+++ dpkg-1.10-freebsd/scripts/dpkg-architecture.pl Fri Feb 8 04:45:52 2002
@@ -65,7 +65,7 @@
's390', 's390-linux',
'ia64', 'ia64-linux',
'openbsd-i386', 'i386-openbsd',
- 'freebsd-i386', 'i386-freebsd',
+ 'freebsd-i386', 'i386-freebsd4',
'darwin-powerpc', 'powerpc-darwin',
'darwin-i386', 'i386-darwin');
diff -urN dpkg/configure.in dpkg-1.10-freebsd/configure.in
--- dpkg
patch to add FreeBSD support
Please consider this patch, which adds FreeBSD support to dpkg. It is based
on a fresh checkout from CVS, so it should apply easily.
I added support for wildcards in the archtable to configure, because
config.guess returns i386-unknown-freebsd4.5, and will change regularly. This
seemed like it require excessive maintenance. The NetBSD and OpenBSD ports
will likely benefit from this as well.
diff -urN dpkg/archtable dpkg-1.10-freebsd/archtable
--- dpkg/archtable Tue Jan 1 13:16:37 2002
+++ dpkg-1.10-freebsd/archtable Fri Feb 8 01:17:11 2002
@@ -43,6 +43,8 @@
hppa1.1-linux-gnu hppahppa
hppa2.0-linux-gnu hppahppa
hppa64-linux-gnu hppahppa
+i386-freebsd.+ freebsd-i386freebsd-i386
+i386-freebsd4 freebsd-i386freebsd-i386
i386-freebsd freebsd-i386freebsd-i386
s390-linux-gnu s390s390
s390-ibm-linux-gnu s390s390
diff -urN dpkg/configure.in dpkg-1.10-freebsd/configure.in
--- dpkg/configure.in Sat Feb 2 17:58:58 2002
+++ dpkg-1.10-freebsd/configure.in Fri Feb 8 23:35:45 2002
@@ -93,7 +93,7 @@
dpkg_archset=''
AC_MSG_CHECKING(Debian architecture)
-dpkg_archset="`awk '$1 == "'$target_cpu-$target_os'" { print $2 }'
$srcdir/archtable`"
+dpkg_archset="`perl -ane 'if("'i386-freebsd4.5'"=~m#^$F[0]$#) {print $F[1];
exit(0)}' archtable`"
# Finish off
if test "x$dpkg_archset" = "x"; then
AC_MSG_RESULT([$target_cpu-$target_os, but not found in archtable])
@@ -173,11 +173,20 @@
} inline int foo (int x) {], AC_DEFINE(HAVE_INLINE))
AC_MSG_CHECKING([for __va_copy])
-AC_TRY_COMPILE([
-#include
-],[
-va_list v1,v2;
-__va_copy(v1, v2);
+AC_TRY_RUN([
+#include
+void f (int i, ...) {
+va_list args1, args2;
+va_start (args1, i);
+__va_copy (args2, args1);
+if (va_arg (args2, int) != 42 || va_arg (args1, int) != 42)
+ exit (1);
+va_end (args1); va_end (args2);
+}
+int main() {
+ f (0, 42);
+ return 0;
+}
], [AC_MSG_RESULT(yes)
AC_DEFINE(HAVE_VA_COPY)],[AC_MSG_RESULT(no)
AC_MSG_CHECKING([for va_list assignment copy])
diff -urN dpkg/scripts/dpkg-architecture.pl
dpkg-1.10-freebsd/scripts/dpkg-architecture.pl
--- dpkg/scripts/dpkg-architecture.pl Tue Jan 1 14:07:49 2002
+++ dpkg-1.10-freebsd/scripts/dpkg-architecture.pl Fri Feb 8 04:45:52 2002
@@ -65,7 +65,7 @@
's390', 's390-linux',
'ia64', 'ia64-linux',
'openbsd-i386', 'i386-openbsd',
- 'freebsd-i386', 'i386-freebsd',
+ 'freebsd-i386', 'i386-freebsd4',
'darwin-powerpc', 'powerpc-darwin',
'darwin-i386', 'i386-darwin');
diff -urN dpkg/scripts/dpkg-shlibdeps.pl
dpkg-1.10-freebsd/scripts/dpkg-shlibdeps.pl
--- dpkg/scripts/dpkg-shlibdeps.pl Wed Jun 20 16:30:15 2001
+++ dpkg-1.10-freebsd/scripts/dpkg-shlibdeps.pl Fri Feb 8 23:57:06 2002
@@ -91,12 +91,29 @@
}
}
+$deb_build_arch = `dpkg --print-installation-architecture`;
+if ($?>>8) {
+ &syserr("dpkg --print-installation-architecture failed");
+}
+chomp $deb_build_arch;
+
for ($i=0;$i<=$#exec;$i++) {
if (!isbin ($exec[$i])) { next; }
# First we get an ldd output to see what libs + paths we have at out
# disposal.
my %so2path = ();
+
+if($deb_build_arch eq "freebsd-i386") {
+defined($c= open(P,"-|")) || syserr("cannot fork for ldconfig");
+if (!$c) { exec("ldconfig","-r"); syserr("cannot exec ldconfig"); }
+while () {
+ if (m,^\s+\d+:-l(\w+)(\.\d+)\s+=>\s+(\S+)$,) {
+ $so2path{"lib$1.so$2"} = $3;
+ }
+}
+close(P); $? && subprocerr("ldconfig");
+} else {
defined($c= open(P,"-|")) || syserr("cannot fork for ldd");
if (!$c) { exec("ldd","--",$exec[$i]); syserr("cannot exec ldd"); }
while () {
@@ -105,6 +122,7 @@
}
}
close(P); $? && subprocerr("ldd on \`$exec[$i]'");
+}
# Now we get the direct deps of the program. We then check back with
# the ldd output from above to see what our path is.
diff -urN dpkg/utils/start-stop-daemon.c
dpkg-1.10-freebsd/utils/start-stop-daemon.c
--- dpkg/utils/start-stop-daemon.c Fri Feb 1 23:28:13 2002
+++ dpkg-1.10-freebsd/utils/start-stop-daemon.c Fri Feb 8 04:36:55 2002
@@ -32,6 +32,8 @@
# define OSOpenBSD
#elif defined(hpux)
# define OShpux
+#elif defined(__FreeBSD__)
+# define OSFreeBSD
#else
# error Unknown architecture - cannot build start-stop-daemon
#endif
@@ -43,7 +45,7 @@
# include
#endif
-#if defined(OSOpenBSD)
+#if defined(OSOpenBSD) || defined(OSFreeBSD)
#include
#include
#include
@@ -675,7 +677,7 @@
{
#if defined(OSLinux) || defined(OShpux)
if (execname && !pid_is_exec(pid, &exec_stat))
-#elif defined(OSHURD)
+#elif defined(OSHURD) || defined(OSFreeBSD)
/* I will try this to see if it works */
if (execname && !pid_is_cmd(p
Re: Build machine
That's interesting. I've been having similar problems with it. I just discoverd that it would accept either the sources lines or my binaries line, but not both at the same time. I'm not sure, but I suspect it's trying to match up source packages with binary packages, and running into inconsistancies. See if this is similar to what you get: (gdb) bt #0 0x280f51dd in pkgTagSection::Scan(char const*, unsigned long) () from /usr/lib/libapt-pkg.so.3.2 #1 0x280f4eb8 in pkgTagFile::Step(pkgTagSection&) () from /usr/lib/libapt-pkg.so.3.2 #2 0x28121a87 in debListParser::Step() () from /usr/lib/libapt-pkg.so.3.2 #3 0x28111c84 in pkgCacheGenerator::MergeList(pkgCacheGenerator::ListParser&, pkgCache::VerIterator*) () from /usr/lib/libapt-pkg.so.3.2 #4 0x2812af84 in debPackagesIndex::Merge(pkgCacheGenerator&, OpProgress&) const () from /usr/lib/libapt-pkg.so.3.2 #5 0x28114e51 in pkgCacheGenerator::WriteUniqString(char const*, unsigned) () from /usr/lib/libapt-pkg.so.3.2 #6 0x2811521d in pkgMakeStatusCache(pkgSourceList&, OpProgress&, MMap**, bool) () from /usr/lib/libapt-pkg.so.3.2 #7 0x2810c625 in pkgCacheFile::Open(OpProgress&, bool) () from /usr/lib/libapt-pkg.so.3.2 #8 0x0805957b in DoUpdate(CommandLine&) ([EMAIL PROTECTED]) at apt-get.cc:85 #9 0x280e440a in CommandLine::DispatchArg(CommandLine::Dispatch*, bool) () from /usr/lib/libapt-pkg.so.3.2 #10 0x0805f380 in main (argc=2, argv=0xbfbffc48) at apt-get.cc:2174 #11 0x08052130 in _start () On Thu, Feb 07, 2002 at 03:42:02PM -0700, Joel Baker wrote: > The build machine is out of order until such time as I can get apt-get to > not segfault on things like "any source list, including a completely empty > one". Even working from a brand new chroot install isn't helping. > > Of course, the totally unexplained "well, sometimes it segfaults, and then > sometimes it does" that I've had with it for the past 2 weeks just appears > to have become "it always segfaults". Maybe it will decide it likes me in > a few hours. > -- > *** > Joel Baker System Administrator - lightbearer.com > [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: binutils for GNU/FreeBSD
For FreeBSD, I've been using binutils 2.11.90.0.7-2 with gcc 3.0.3-1. This seems to work well. The newer binutils (2.11.92.0.12.3-6) segfaults when linking c++ code. Breaks apt, lftp and fakeroot. I've been just copying getopt into packages for now. Gets them up and running, so I can get a stable base system to work on. Later, I'm thinking about putting together a libiberty package. Then it'll just require patching configure. That work can probably be shared by all the BSDs. On Thu, Feb 07, 2002 at 03:33:34PM +0100, Robert Millan wrote: > > Hi! > > Looks like the actual version of binutils is not > up-to-date enough for the gcc-3.0 packages to work > (although --force-depends has been working so far) > > Anyone has a clue on building the latest binutils? > > Also, I remember some discussion about getopt.h. > > What is it suposed to be done when getopt.h is > necessary for a build? > > Cheers, > > -- > > Robert Millan Debian/GNU user > zeratul2 wanadoo eshttp://getyouriso.dyndns.org/ > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Self-hosting Debian NetBSD system available
Hmm. How odd. I got it working on FreeBSD well enough to pass its tests. I don't recall running into any problem with libc.so.6. I'm using version 0.4.5. On Thu, Feb 07, 2002 at 03:47:57PM +, Jonathan Amery wrote: > In article <[EMAIL PROTECTED]> you write: > >Blech; it would appear fakeroot does an explicit dlopen of > >/lib/libc.so.6. Since I don't have root in your chroot, and, well, > >fakeroot doesn't work, try changing LIBCPATH at the top of libfakeroot.c > >to /usr/lib/libc.so.12 and recompiling.. > > > Oh, yes - doesn't fakeroot do all sorts of evil LD_PRELOAD style > stuff that may well be libc dependant? > > Jonathan. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
FreeBSD multiuser boot
I just got Debian FreeBSD to boot multiuser. Expect a new tarball very shortly. I have to roll some init script changes back into the packages, and deal with a problem with ELF branding. I may have to recompile every package to fix that one, but it'd be worth it. FYI, this is a packages only installation. I used a much-hacked version of debootstrap to make it. The new tarball should be ~15M. ---Nathan
Re: ed SEGV
On Tue, Feb 05, 2002 at 09:20:25PM -0700, Joel Baker wrote: > On Wed, Feb 06, 2002 at 03:18:49AM +, Matthew Vernon wrote: > > "Joel Baker" <[EMAIL PROTECTED]> writes: > > > > > > > It's apparently being caused by stack corruption... lord knows how THAT > > > is happening. Time to dig out the toolkit. Or rather, try to compile the > > > toolkit... (GDB should be up, now, for the record). > > > > I suspect Crap Code(TM). Or someone relying on a behaviour of glibc > > that isn't standard. > > Except that the source is taken from FreeBSD's /usr/src tree... > > However, GCC 2.95.4 compiled; I'm now going to back up my current tarball, > and do some test compiling with the new GCC to ensure that it works sanely, > then try ed under 2.95.4 to try to weed out compiler issues. Which sources are you using for ed? I used the ed package from Debian, and all I had to do was put libed.a back into the ed target in Makefile.in. make check passes just fine.
Re: ed SEGV
I haven't had the problem you're having with ed, but I have had some problems with binutils. The current version wasn't linking ok, so I backed down to 2.11.90.0.7-2, which has been stable. I need to figure out where to set the ABI binutils brands the binaries with. Right now, everything is getting branded as System V. Anybody happen to know where to change that? On Tue, Feb 05, 2002 at 07:25:23PM -0700, Joel Baker wrote: > It's apparently being caused by stack corruption... lord knows how THAT > is happening. Time to dig out the toolkit. Or rather, try to compile the > toolkit... (GDB should be up, now, for the record). > -- > *** > Joel Baker System Administrator - lightbearer.com > [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: libshadow
On Tue, Feb 05, 2002 at 09:02:23PM +, Matthew Garrett wrote: > On Tue, Feb 05, 2002 at 02:02:15PM -0500, [EMAIL PROTECTED] wrote: > > After hacking on shadow off and on for a few months, I decided to give up, > > and > > just use the native passwd tools. I believe the Hurd has it's own tools for > > this, so there's precedent. > > On the other hand, the modifications are pretty minimal (two functions > need to be modified in commonio.c and the password format string needs > changing) and it probably wouldn't be that hard to extend it to cover the > BSD additions. I'd rather keep the codebase as close to Debian as possible > except where there really is a lot of extra work or stuff is tied to the > kernel (ifconfig, mount and so on), so I'm inclined to modify the debian > one rather than packaging the BSD ones. I'll have to try it out, and see how it works. Do you have adduser working yet?
Re: libshadow
After hacking on shadow off and on for a few months, I decided to give up, and just use the native passwd tools. I believe the Hurd has it's own tools for this, so there's precedent. On Tue, Feb 05, 2002 at 06:18:13PM +, Matthew Garrett wrote: > On closer investigation, the reason none of the group stuff worked with my > patch to libshadow was that groupio.c uses the same calls as for updating > passwords, with the result that it was attempting to write group files in > the same way as passwd files (whereas /etc/group is the same format on > NetBSD as elsewhere). For the moment I've worked around this by shifting > all my changes to a different commonio.c (commoniobsd.c) and adding > unmodified versions of the three modified functions with different names > then hacked groupio.c to use those. No hint is passed regarding whether > the file is a password or a group file, so can anyone suggest a better > mechanism or should I just stick with this for now? (with this fix, the > login and passwd packages seem to basically work so can probably be taken > off the TODO list. We still lose the ability to alter the NetBSD specific > stuff, but that can probably be added in later) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: ed package
I think it'd be best to package libiberty from gcc (arbitrary choice). Then when a package tries to use getopt_long from libc, we patch configure to use our libiberty package. One library that all three can use, and we should be able to share the patches to configure. On Mon, Feb 04, 2002 at 11:29:14PM +0100, Andreas Schuldei wrote: > * [EMAIL PROTECTED] ([EMAIL PROTECTED]) [020204 21:29]: > > I think it would be best if we can agree on a solution that works for all > > three > > BSD's. That could save work, and it would definitely simplify getting > > patches > > merged back into Debian. > > sadly, openbsd has no getopt_long, only getopt. > > of cause there is the gnu subtree in the cvs, where getopt_long > occures. However, even there it is not linked against one lib, > but every (?) program suite brings its own header and c-source > file. I found perhaps a dozent independent pairs. > > I am pretty sure that the netbsd and openbsd libc are quite > different by now. (I did not compare them, correct me if I am > wrong.) So I guess a cross platform patch is not really feasable > for openbsd. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: ed package
I think it would be best if we can agree on a solution that works for all three BSD's. That could save work, and it would definitely simplify getting patches merged back into Debian. Perhaps we should just package libiberty. That takes care of the handful of packages that try use to use obstack and friends, also. On Mon, Feb 04, 2002 at 10:24:45AM -0800, Jeremy C. Reed wrote: > On Mon, 4 Feb 2002, matthew green wrote: > > > please tell me the differences; i can probably get the netbsd one > > changed. it is *supposed* to be compatible. it was written so that > > we would have a getopt_long() that wasn't GPLed. any difference is > > a bug and should be treated as such... > > The NetBSD getopt_long(3) manual page includes a list of the differences > to the GNU (glibc-2.1.3) implementation under "IMPLEMENTATION > DIFFERENCES". > > Jeremy C. Reed > echo '9,J8HD,[EMAIL PROTECTED]:[EMAIL PROTECTED];[EMAIL > PROTECTED]@5GBIELD54DL>@8L?:5GDEJ8LDG1' |\ > sed ss,s50EBsg | tr 0-M 'p.wBt SgiIlxmLhan:o,erDsduv/cyP' > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: ed package
On Mon, Feb 04, 2002 at 01:40:57PM +0100, Andreas Krennmair wrote: > * matthew green <[EMAIL PROTECTED]> [02-02-04 13:36]: > >But behaves differently to GNU getopt_long, as regards its handling of > >the arguments '-' and '--' > > it does? this sounds like a bug. it should be compatible. > getopt_long is a GNUism, anyway. Only getopt is a standard (at least > according to getopt(3)). True enough. However, so many packages in Debian just assume it's in libc that it's easier to put it there for now, and fix configure in all those packages later. ---Nathan
Re: Revised TODO
It's kind of an alternative to nsswitch.conf. I'm not sure why it exists... It looks like this on FreeBSD: skaro:/skaro# cat /etc/host.conf # $FreeBSD: src/etc/host.conf,v 1.6 1999/08/27 23:23:41 peter Exp $ # First try the /etc/hosts file hosts # Now try the nameserver next. bind # If you have YP/NIS configured, uncomment the next line # nis And on Linux: hotrod:~# cat /etc/host.conf order hosts,bind multi on As I said, FreeBSD's resolver really didn't like the Linux version of the file, which is in base-files. On Mon, Feb 04, 2002 at 11:04:19AM +1100, matthew green wrote: > >I plan to just replace ifconfig. The major headache is ifupdown. FYI, > watch out >for /etc/host.conf. The Linux version badly broke FreeBSD's resolver. > > > what is host.conf? don't think netbsd uses it. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Self-hosting Debian NetBSD system available
Hmm. Not sure what's going on with Fakeroot there. It worked ok on FreeBSD. If you get it working, please send me a patch. I'll merge it, and we can try to get support for both archs merged in upstream. On Sun, Feb 03, 2002 at 11:02:22PM +, Matthew Garrett wrote: > I now have a self-hosting Debian NetBSD system. The patch to sysvinit > seems to have worked wonderfully, though several boot scripts are not > entirely happy due to commands having different semantics. Networking > isn't automatically set up yet (the ifupdown source is distributed in some > weird format allowing the documentation and code to be distributed > together, as far as I can tell. This would be fine except the package to > untangle it requires tetex amongst other things. I'll take a look at this > now), and it doesn't launch any gettys, but I do now have ssh running and > can log in remotely. > > Fakeroot is compiled, but fails its test suite > > ../scripts/fakeroot -f /tmp/fakeroot-0.4.5/faked -l > /tmp/fakeroot-0.4.5/.libs/libfakeroot.so.0 -- "touch tmp/foo; install > tmp/foo tmp/bar; ls -al tmp/bar" | grep "root.*root.*tmp/bar" > dlsym(open): Undefined symbol "open" > dlsym(fopen): Undefined symbol "fopen" > dlsym(freopen): Undefined symbol "freopen" > dlsym(freopen): Undefined symbol "freopen" > dlsym(lstat): Undefined symbol "lstat" > dlsym(stat): Undefined symbol "stat" > dlsym(fstat): Undefined symbol "fstat" > dlsym(mknod): Undefined symbol "mknod" > dlsym(chown): Undefined symbol "chown" > dlsym(lchown): Undefined symbol "lchown" > dlsym(fchown): Undefined symbol "fchown" > dlsym(chmod): Undefined symbol "chmod" > dlsym(fchmod): Undefined symbol "fchmod" > dlsym(mkdir): Undefined symbol "mkdir" > dlsym(unlink): Undefined symbol "unlink" > dlsym(rmdir): Undefined symbol "rmdir" > dlsym(remove): Undefined symbol "remove" > dlsym(rename): Undefined symbol "rename" > dlsym(getuid): Undefined symbol "getuid" > dlsym(getgid): Undefined symbol "getgid" > dlsym(geteuid): Undefined symbol "geteuid" > dlsym(getegid): Undefined symbol "getegid" > ../scripts/fakeroot: line 85: 27418 Segmentation fault (core > dumped) FAKEROOTKEY=$FAKEROOTKEY LD_LIBRARY_PATH=$PATHS LD_PRELOAD=$LIB sh > -c "$*" > make: *** [4] Error 1 > make: Leaving directory `/tmp/fakeroot-0.4.5/test' > > and running it gives me a shell but claims that I'm still me. I'll look > into this. > > Although it's less useful without fakeroot running, I can provide access > to this system now for anybody who's interested in developing on it. > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: patches
On Sun, Feb 03, 2002 at 09:39:50PM +, Matthew Garrett wrote: > Two minor changes needed (other than s/freebsd/netbsd) for the sysvinit > patch - NetBSD's reboot() doesn't seem to do poweroff, so I changed that > #define to just halt the system, and reboot() takes two arguments, magic > and a string that can be passed to the firmware under certain > circumstances. Changing reboot() to be defined as reboot(magic,"") sorted > that. > > My chroot was on a separate partition to my native system. Though there > are some problems with the boot scripts (mount and fsck take different > options), and we don't have a getty yet, I now have a system that will > come up with sysvinit and give me a shell. I'm very impressed. Excellent. Mind sending me a diff against my patch, so I can merge it together, and send upstream?
Re: ed package
On Sun, Feb 03, 2002 at 09:02:57PM +, Matthew Vernon wrote: > "Jeremy C. Reed" <[EMAIL PROTECTED]> writes: > > > > > On Sat, 2 Feb 2002 [EMAIL PROTECTED] wrote: > > > > > getopt is in libiberty. It's also in glibc, and people have a bad > > > habit of not checking for that in configure. I'm thinking about > > > packaging libiberty, and > > > > Also a BSD-licensed getopt (and getopt_long) is available in the NetBSD > > libc. > > So the correct solution is to make the gnu ed configure use this on NetBSD. Sounds good. I'm going to see if I can patch that implementation into the FreeBSD libc. That would solve a lot of headaches for me.
patches
Ok, here are patches for sysvinit and fakeroot. Fakeroot I've actually been
able to test, and it appears to work. sysvinit is waiting on me to finish
making my new (cleaner) chroot, and put on another box, so I can try booting.
---Nathan
diff -urN fakeroot-0.4.5/communicate.h fakeroot-0.4.5-freebsd/communicate.h
--- fakeroot-0.4.5/communicate.hTue Sep 7 20:38:14 1999
+++ fakeroot-0.4.5-freebsd/communicate.hMon Jan 28 01:51:02 2002
@@ -14,7 +14,8 @@
As I assume that pre-2.1 libc's will just ignore those _LARGEFILE64_SOURCE
defines, I hope I can get away with this approach:
*/
-
+
+#ifndef __FreeBSD__
/*First, unconditionally define these, so that glibc 2.1 features.h defines
the needed 64 bits defines*/
#ifndef _LARGEFILE64_SOURCE
@@ -59,6 +60,8 @@
# define _LARGEFILE_SOURCE
#endif
#endif
+
+#endif /* __FreeBSD__ */
#include
diff -urN fakeroot-0.4.5/fakerootconfig.h
fakeroot-0.4.5-freebsd/fakerootconfig.h
--- fakeroot-0.4.5/fakerootconfig.h Sat Oct 9 15:31:20 1999
+++ fakeroot-0.4.5-freebsd/fakerootconfig.h Mon Jan 28 01:44:45 2002
@@ -1,14 +1,8 @@
-#define NEXT_STAT(a,b,c) next___xstat(a,b,c)
-#define STAT_ARG(a,b,c) (a,b,c)
-#define NEXT_FSTAT(a,b,c) next___fxstat(a,b,c)
-#define FSTAT_ARG(a,b,c) (a,b,c)
-#define NEXT_LSTAT(a,b,c) next___lxstat(a,b,c)
-#define LSTAT_ARG(a,b,c) (a,b,c)
-#define NEXT_STAT64(a,b,c) next___xstat64(a,b,c)
-#define STAT64_ARG(a,b,c) (a,b,c)
-#define NEXT_FSTAT64(a,b,c) next___fxstat64(a,b,c)
-#define FSTAT64_ARG(a,b,c) (a,b,c)
-#define NEXT_LSTAT64(a,b,c) next___lxstat64(a,b,c)
-#define LSTAT64_ARG(a,b,c) (a,b,c)
-#define NEXT_MKNOD(a,b,c,d) next___xmknod(a,b,c,d)
-#define MKNOD_ARG(a,b,c,d) (a,b,c,d)
+#define NEXT_STAT(a,b,c) next_stat(b,c)
+#define STAT_ARG(a,b,c) (b,c)
+#define NEXT_FSTAT(a,b,c) next_fstat(b,c)
+#define FSTAT_ARG(a,b,c) (b,c)
+#define NEXT_LSTAT(a,b,c) next_lstat(b,c)
+#define LSTAT_ARG(a,b,c) (b,c)
+#define NEXT_MKNOD(a,b,c,d) next_mknod(b,c,d)
+#define MKNOD_ARG(a,b,c,d) (b,c,d)
File fakeroot-0.4.5/test/hda3 is a regular empty file while file
fakeroot-0.4.5-freebsd/test/hda3 is a block special file
diff -urN sysvinit-2.84/debian/control sysvinit-2.84-freebsd/debian/control
--- sysvinit-2.84/debian/controlSun Feb 3 18:25:01 2002
+++ sysvinit-2.84-freebsd/debian/controlSat Jan 26 00:54:18 2002
@@ -6,14 +6,11 @@
Package: sysvinit
Essential: yes
-Architecture: any
+Architecture: freebsd-i386
Pre-depends: ${shlibs:Depends}
-Conflicts: last, file-rc (<= 0.5.7), kbd (<< 0.95-2), mdutils (<< 0.35-9)
-Depends: dpkg (>= 1.4.0.21), mount (>= 2.7i-1), util-linux (>= 2.9t-2),
e2fsprogs (>= 1.15-1)
-Replaces: last, bsdutils (<=2.0-2), dpkg (<< 1.9.17)
+Depends: dpkg (>= 1.4.0.21)
Description: System-V like init.
Init is the first program to run after your system is booted, and
continues to run as process number 1 until your system halts. Init's
job is to start other programs that are essential to the operation of
your system. All processes are descended from init. For more information,
- see the manual page init(8).
diff -urN sysvinit-2.84/debian/rules sysvinit-2.84-freebsd/debian/rules
--- sysvinit-2.84/debian/rules Sun Feb 3 18:25:01 2002
+++ sysvinit-2.84-freebsd/debian/rules Sat Jan 26 00:11:09 2002
@@ -18,7 +18,7 @@
build:
# Builds the binary package.
$(checkdir)
- (cd src; make DEBIAN=cool)
+ (cd src; make DEBIAN=cool FREEBSD=1)
touch build
# Architecture independant files.
@@ -57,7 +57,7 @@
install -d -g root -m 755 -o root $(tmp)/usr/share/man/fr/man8
install -d -g root -m 755 -o root $(tmp)/var/lib/urandom
install -g root -m 755 debian/fsck.nfs $(tmp)/sbin/fsck.nfs
- (cd src; make ROOT=$(tmp) DEBIAN=cool install )
+ (cd src; make ROOT=$(tmp) DEBIAN=cool FREEBSD=1 install )
install -g root -m 644 debian/rc.boot.5 $(tmp)/usr/share/man/man5
install -g root -m 644 debian/rcS.5 $(tmp)/usr/share/man/man5
install -g root -m 644 debian/extra/*.8 \
diff -urN sysvinit-2.84/src/Makefile sysvinit-2.84-freebsd/src/Makefile
--- sysvinit-2.84/src/Makefile Tue Nov 6 11:58:16 2001
+++ sysvinit-2.84-freebsd/src/Makefile Sat Jan 26 00:12:31 2002
@@ -18,7 +18,11 @@
PROGS = init halt shutdown killall5 runlevel sulogin utmpdump \
last mesg wall
else
-PROGS = init halt shutdown killall5 runlevel sulogin last mesg
+ ifeq ($(FREEBSD),)
+PROGS = init halt shutdown killall5 runlevel sulogin last mesg
+ else
+PROGS = init halt shutdown killall5 sulogin
+ endif
endif
BIN_OWNER = root
@@ -34,11 +38,11 @@
all: $(PROGS)
-init: init.o init_utmp.o
- $(CC) $(LDFLAGS) $(STATIC) -o $@ init.o init_utmp.o
+init: init.o init_utmp.o utent.o
+ $(CC) $(LDFLAGS) $(STATIC) -o $@ init.o init_utmp.o utent.o
-halt: halt.o ifdown.o hddown.o utmp.o reboot.h
- $(CC) $(LDFLAGS) -o $@ ha
Re: thoughts on architectures
On Sun, Feb 03, 2002 at 05:59:28PM +0100, Andreas Schuldei wrote: > Markus Brinkmanm (of HURD fame) has written this > http://master.debian.org/~brinkmd/arch-handling.txt > which is mandatory reading for us. You're right, that's a very good document. He's apparently been thinking along similar lines that I have. There are other problems, like sparc64/32, and ia64 or AMD's 64-bit arch supporting i386, that could be helped by this. The major oversight is that he completely fails to mention libc. And for us, that remains a big issue. Right now, and for immediately forseeable future, I'm not going to be using glibc. Another one is branding binaries. Linux emulation could be quite useful on *BSD and maybe hurd, as well. But it would be really helpful if binutils were altered to do branding. That would help make it possible to install i386 binary packages directly onto freebsd-i386, given the appropriate libraries in /compat/linux. There'd be some other headaches, but it could be done. Might help the Hurd developers, too, if they had it available. > they (the hurd people) are very interested in working closely > together with us, simply since we together might have enough > weight to make debian make more architecture aware. they are > both highly cooperativ and competent, so we better are nice to > them. (c: > > please give some feedback on that document. Excellent. I think we're getting to the point where it makes sense to have those conversations. Perhaps we can all agree to strangle the person who wrote the docs for dpkg in SGML... ;-) ---Nathan
Re: Revised TODO
On Sun, Feb 03, 2002 at 10:48:49AM -0700, Joel Baker wrote: > > Anything else need adding/updating? > > Packaging tool for the BSD kernel, kernel-tools, and libc. I'm working on a package to do this for FreeBSD. At the moment, it works great when I build it on FreeBSD, and I'm still trying to get it working in my chroot. You guys can probably adapt it. It's not nearly as advanced as kernel-package, but it's a start.
Re: Revised TODO
On Sun, Feb 03, 2002 at 03:42:31PM +, Matthew Garrett wrote: > This is what we have on the website: > > any of the libs in /lib or /usr/lib that aren't currently packaged need to > be > > (still needs doing) > > base-passwd is desperately unhappy > > (seems happy now) FYI, there is a bug that causes it to dump core. I think it's only when you point it at an empty /etc/master.passwd. It's probably in fgetpwent_r.c. > equivilents of console-tools/data need to be produced > > (still needs doing) > > netbase needs to be rebuilt. This is probably one of the more > awkward ones - we have source for the BSD versions of ifconfig et al, but > the semantics are somewhat different. If we stick with BSD semantics, we > have to deal with any scripts that assume Linux-style semantics. Does HURD > follow Linux-style semantics, and if not how have they dealt with this? > > (still needs doing) I plan to just replace ifconfig. The major headache is ifupdown. FYI, watch out for /etc/host.conf. The Linux version badly broke FreeBSD's resolver. > procps (probably best to just provide the BSD versions) > > (still needs doing) > > shadow (sort of working, but NetBSD has interesting binary files for > dealing with passwords. As a result, stuff like passwd and adduser are not > currently as useful as they could be. Somebody needs to look into this) > > (other than group stuff, seems to be working) I ended up packaging FreeBSD's passwd, su, login, and native libpam. (And a few others.) So far the main victim is adduser... Haven't got round to hacking it yet. > sysklogd > > (still needs doing) Try msyslog. I believe it came from NetBSD originally, so it should work. > sysvinit (BSD init doesn't support runlevels. We can hack it to work > like Debian with a single runlevel without too much trouble) > > (still needs doing) I have it hacked at least enough to compile. I'll get you the patch. > Anything else need adding/updating? fakeroot, if you haven't got it yet. It's going to be essential at some point. I'll get you my patch for it. ---Nathan
Re: apt
Matthew, I had to do the patch to environment.mak also. I believe I used Wartan's patch that was on the list a few months ago. I had problems with ftp-archive also. At different points, with different versions, and different versions of g++, it has segfaulted, failed to compile, and just plain won't work. I disabled it in the Makefile. I haven't tried real hard to fix it, because I felt there were other things that were more urgent. If you figure out what's wrong with it, I'd be quite interested... FWIW, I do have apt basically working on FreeBSD. It segfaulted quite a bit at first, but seems to be working better, now that I recompiled it with gcc 3.0. It might just be that the libstdc++ with 3.0 is better. I don't really know, but it helped a lot. ---Nathan On Sun, Feb 03, 2002 at 04:33:11AM +, Matthew Garrett wrote: > On Sun, Feb 03, 2002 at 04:01:32AM +, Matthew Garrett wrote: > > > Oh, no, got it. Unless a certain set of magic words appears in the host > > architecture, it builds with static libraries. buildlib/environment.mak.in > > probably needs patching to be a touch saner. > > Yup, that does it. Hacking environment.mak.in so that it produces shared > libraries has let me produce a working apt with which I've just retrieved > a source package. apt-ftparchive is still segfaulting, presumably due to > me screwing up somewhere in that patch. Other than that: > > cysteine:/source/stage2/debs# uname -a > NetBSD cysteine 1.5 NetBSD 1.5 (GENERIC) #1: Sun Nov 19 21:42:11 MET 2000 > [EMAIL PROTECTED]:/work/trees/netbsd-1-5/sys/arch/i386/compile/GENERIC i386 > unknown > cysteine:/source/stage2/debs# apt-get moo > (__) > (oo) >/--\/ > / ||| > * /\---/\ > ~~ ~~ > "Have you mooed today?"... > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: ed package
I think an essential base package would make sense. If it's a shared library, it will be required by too many package to make it build-essential. The -dev package would be build-essential. On Sat, Feb 02, 2002 at 11:31:42PM +0100, Jeroen Dekkers wrote: > On Sat, Feb 02, 2002 at 10:09:33PM +, Matthew Garrett wrote: > > > Uhm, yes. Definitely should be packaged. That way we at least have a way > > > to allow folks to declare (build|)dependancies on "GNU libc or libiberty". > > Packages never depend on libc, becuase it's a (build-)essential package. > > > Would it make more sense to include it in the libc package? That way we > > end up with a single package that approximates the functionality of glibc, > > rather than requiring several of them. > > I think libibery should be (build-)essential. Putting libc and > libiberty in one package is wrong because they have a different > upstream. I think the right way is having a libc package which depends > on the libiberty package. > > Jeroen Dekkers > -- > Jabber supporter - http://www.jabber.org Jabber ID: [EMAIL PROTECTED] > Debian GNU supporter - http://www.debian.org http://www.gnu.org > IRC: [EMAIL PROTECTED]
Re: dpkg patch
On Sat, Feb 02, 2002 at 11:58:11AM -0700, Joel Baker wrote: > On Sat, Feb 02, 2002 at 12:15:46PM -0500, [EMAIL PROTECTED] wrote: > > I think it might be a good idea to merge them. However, I need to upgrade > > a bit first. I'm still using 1.9.16. > > > > Any thoughts about using wildcards in archtable? It'd be nice to be able > > to say i386-unknown-freebsd*, and have configure work with that. Much > > nicer than putting each release in there. > > Merging is probably not a bad idea, but largely depends on how much extra > is necessary for OpenBSD; certainly, however, we should make sure that at > the very least, the two can be applied cleanly together. > > I *strongly* favor wildcard matching in the archtable, to address the issue > of not wanting to file bugs against dpkg every time NetBSD upgrades it's > kernel by a minor revision. Yes, I think we all have that problem. I'll write up a patch for configure to support wildcards. I think that's the only place that will actually need them. I've configured gcc to use i386-unknown-freebsd4, so dpkg finds that when it looks for the arch at runtime. (By looking at the path to gcc-lib. Yuck!) I think I can probably live with putting major version number in. They aren't as frequent.
Re: ed package
getopt is in libiberty. It's also in glibc, and people have a bad habit of not checking for that in configure. I'm thinking about packaging libiberty, and making patches to check for getopt there. Might be easier to deal with than fifty separate versions across fifty source packages... On Sat, Feb 02, 2002 at 11:55:29AM -0700, Joel Baker wrote: > On Sat, Feb 02, 2002 at 10:30:51AM +, Matthew Vernon wrote: > > Hi, > > > > ed package (binary) is at > > http://www.pick.ucam.org/~matthew/netbsd/ed_0.2-19_netbsd-i386.deb > > > > md5sum is 0d08768459c589722584903fc658fa0c > > > > The package is of course unsigned, but this mail is signed :) > > FYI - there are two bugs filed against ed which are of interest. The second > one (the option bug) is not exactly critical, but I'd dearly love some help > hunting down more info for the maintainer. I *think* it's happening because > of a difference in GNU libc getopt() vs. the internal replacement that ed > has (and that possibly linking the getopt library would fix it - is this > libiberty? I always forget...) > -- > *** > Joel Baker System Administrator - lightbearer.com > [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Any ETA on a Debian-BSD CD/DVD release?
Sorry, but I think a CD release is a long ways away. I believe we're all still basically bootstrapping, so it'll probably be a while yet before it even boots. On Sat, Feb 02, 2002 at 01:25:26AM -0800, Gary Kline wrote: > >Gents, > >It's been great seeing the solid D-BSD progress in the past few >weeks. When there is a CD/DVD set available--or at least someplace >where people could retrieve binaries or src code--I would like to >cover the DebianBSD distribution in the Answerman column of >Daemonnews.org. > >I'm still dragging my heels in a hardware re-shuffle and the fellow >who helps me with things-hardware is swamped, so it'll be some >months before I have a separate box for the Debian port. > >thanks for any insights, > >gary > > -- >Gary Kline [EMAIL PROTECTED] www.thought.org Public service Unix > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: dpkg patch
I think it might be a good idea to merge them. However, I need to upgrade a bit first. I'm still using 1.9.16. Any thoughts about using wildcards in archtable? It'd be nice to be able to say i386-unknown-freebsd*, and have configure work with that. Much nicer than putting each release in there. I patched start-stop-daemon also, but never really tested it. On Sat, Feb 02, 2002 at 04:05:28PM +0100, Andreas Schuldei wrote: > concerning the dpkg patch, which mail i deleted accidently. > > I have some more changes to the buildsystem which are needed on > openbsd, mainly because it is broken and does not support some > stuff. > > this is for example a configure check for gnu make, ncurses vs > curses, problems with __va_copy and additional detection for > openbsds binary format (not quite elf) in dpkg-shlibdebs. > > Furthermore I am surprised that the start-stop daemon compiled > for you, since in my version I checked out of cvs I found the > #ifdefs messed up for openbsd. > does it work for you guys? > > should we try merging our patches before feeding them to > upstream? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
interesting comments on porting Debian
Here's an interesting message I saw in DWN. This seems to be a realistic assessment of the the process of porting Debian to a new architecture. Actually a bit simpler than what I'm presenting dealing with, though. Anyway here it is: To: Greg Ingram <[EMAIL PROTECTED]> Subject: Re: VAX port? From: Marcus Brinkmann <[EMAIL PROTECTED]> Date: Fri, 18 Jan 2002 17:17:35 +0100 Cc: debian-devel@lists.debian.org In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Sender: Marcus Brinkmann <[EMAIL PROTECTED]> User-Agent: Mutt/1.3.25i On Fri, Jan 18, 2002 at 08:34:25AM -0600, Greg Ingram wrote: > > Are there documents about how one would start building Debian for a new > architecture? I've got Linux running a VAX and would like to see about > building Debian packages. 1. Get rid off your job, your hobbies and all your friends. 2. Start to port dpkg to the VAX. Don't upload. 3. Test it by porting small packages. Don't upload. 4. Bootstrap the complete build-essential system. Don't upload. (Considerably easier for you than it was for me as you have a running system.) 5. Run all checks in the build chain (gcc, glibc). Fix the big bugs. You have not yet uploaded anything. 6. Make a fresh partition with just your Debian packages installed. 7. Go back to 2, and recompile everything using just the standard Debian packages of all tools (except a few which you are going to ignore for now, because they don't affect the result too much. You may take them from the native system if available). Don't upload. 8. Still here? You should now have a couple of dozen packages or so. Announce your progress, file a bug report against ftp.debian.org to make a directory in the archive. 9. Wait. 10. Discuss the usefulness of this project on debian-devel. A common mistake is to do this too early, eg before step 3 has been completed. Don't fall into this trap. 11. Wait some more. Don't upload. 12. Still here? Check if the directory has been created. Maybe you get an acknowledgement, so check your mail frequently. Now, upload! 13. From now on, you might consider running a build daemon. But you can also do it manually until you are fed up with it. Compile whatever can be compiled. Don't upload yet. 14. Install, test. 15. Fix the bugs. 16. Upload. 17. Go back to 13. 18. There is no 18. If you did everything correct, you loop over 13-17 until you leave Debian. But there are some options: 12a. Rally support for your activities. 12b. Get a mailing list created. 12c. Make a web page. 13a. Write articles about your experience. 13b. Visit conferences, talk about your experiences. 13c. Delegate work. 13d. Pick up delegated work that was not completed. Thanks, Marcus -- `Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED] Marcus Brinkmann GNUhttp://www.gnu.org [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.marcus-brinkmann.de
Re: dpkg architecture and official support
On Wed, Jan 30, 2002 at 11:21:21PM +0100, Michael Weber wrote:
> * Joel Baker <[EMAIL PROTECTED]> [2002-01-30T10:55-0700]:
> > Two or three times now, I've run into bugs that were wishlisted or outright
> > closed because we are not considered an Official Architecture (tm) yet; the
> > determining factor in this appears to be "are you listed in dpkg's arch
> > list?"
>
> Well, and that was mainly the reason why jimmy and me started the
> thread about the config.{guess,sub} issue earlier this week, after
> discussing it briefly on IRC.
>
> The problem AIUI is, you can't arbitrarily choose a name and put it
> into the archtable of dpkg. The first column part has to match the
> canonicalized arch name as produced by config.sub (modulo the
> "unknown" part). Here's a list of the *BSDs, currently in the
> unofficial archtable:
> i386-freebsdfreebsd-i386freebsd-i386
> i386-openbsd2.8 openbsd-i386i386
> i386-netbsdelf1.5 netbsd-i386 i386
> i386-netbsdelf1.5 netbsd-i386 i386
> alpha-netbsd-debian netbsd-alphaalpha
>
> We need to reach a consensus here (that won't bite us in the future),
> and make sure the config.* guys like it, too, before we ask the dpkg
> maintainers to incorporate the changes. I mentioned some of the
> things to keep in mind in the "How to check for a GNU userland"
> thread.
I have a similar problem. Basically, I'm using i386-unknown-freebsd4. I patched
config.guess to drop the minor version number. It seemed better than entering
every permutation of i386-unknown-freebsd4.x that I could think of. That's just
asking for problems.
Maybe configure could be modified to support wildcards in the archtable? That
might avoid the need to change either config.* or the archtable regularly. I
can write a patch to do that, if it would be acceptable to the dpkg
maintainers.
A related issue:
I found that some packages (gcc for example) use dpkg-architecture to get the
GNU architecture, and pass it to configure. It seems to work best if I have
dpkg return i386-freebsd4, rather than i386-freebsd or i386-freebsdelf.
> > Therefore, I think it's about time we were. I'm willing to talk to the
> > maintainer about it, but before I start down that road, I need to know
> > what, if any, patches were done to dpkg to get it to work in the tarball...
>
> I started with the patch from
>
> http://debian-bsd.sourceforge.net/dpkg/dpkg-patch
>
> and modified it a bit, so that dpkg now builds smoothly on my machine:
>
> http://people.debian.org/~michaelw/dpkg-bsd.patch
>
> Please note that this is BY NO MEANS a patch that should be submitted
> to the dpkg team! There are some hacks in it, that I didn't come
> around to fix properly.
>
> Also, this version should build ok on a native NetBSD system (modulo
> some minor adjustments to INCLUDE_PATH AND LDFLAGS, and a link from
> curses.h to ncurses.h). If somebody is interested I can probably
> write up a more detailed guide.
Another similar situation... I need to upgrade, and see if the version in CVS
requires less kludging. That python version of dpkg-shlibdeps may solve several
headaches for me.
Re: Able to put website on debian.org
On Wed, Jan 30, 2002 at 04:06:03PM -0500, Jimmy Kaplowitz wrote: > That's a good suggestion, and after I finish getting the site moved > over, we can do that. Also, I'd suggest that some of you go to > http://cvs.debian.org/?cvsroot=webwml for instructions on checking out > the website anonymously, which will enable you to make patches for me to > apply to the cvs tree, with changes such as the above. The site uses WML > rather than pure HTML, which adds various nice features. Mostly you > don't have to worry about this, since HTML is still permissible, but go > to http://www.debian.org/devel/website for information on working on the > website. I believe Josip will be setting me up for access to /ports/freebsd, also. Could you link to that, rather than directly to my FreeBSD chroot, and dexter's FreeBSD 3 archive? (That should really be removed. It's based on FreeBSD 3 and slink!) > We can't forget utsl, the guy trying to do FreeBSD all by himself, > either :-) Of course not. And we'll see who gets something that boots first! ;-)
Re: Debian GNU/NetBSD webspace
Put me down for the FreeBSD port. I am a Debian developer, userid is utsl.
On Mon, Jan 28, 2002 at 04:56:57PM -0500, Jimmy Kaplowitz wrote:
> On Mon, Jan 28, 2002 at 09:53:12PM +0100, Josip Rodin wrote:
> > One day, when the Hurd and BSD ports become more mature, we will definitely
> > move the stuff from ports/ into linux-ports/ (or something like that) and
> > create hurd-ports/ and bsd-ports/. Or perhaps ports/{linux,hurd,bsd}/.
> >
> > Until then, ports/netbsd/ should work. OK?
>
> I have no problem with this; I was mistaken in believing that the Hurd
> pages were at ports/hurd-i386/ rather than ports/hurd/. It is confusing
> having the ports directory be a different name than the architecture
> name, but now that I understand this, ports/netbsd/ is fine with me.
>
> > Basically we need a list of people who will work on those web pages, in
> > order to know whom to give the appropriate permissions to.
>
> Well, for now just give permissions to me (jimmy) and Michael Weber
> (michaelw). I'll take responsibility for copying the existing
> debian-bsd.sf.net site over to www.debian.org, and Michael has agreed to
> put up a little bit of information about his work on netbsd-alpha. Most
> of the active people aren't official Debian developers, but out of those
> that are, SPEAK UP and let Josip and me know that you want to work on
> the website.
>
> > Once we agree on the location of your stuff, you do whatever you like in
> > there, with some general Debian web site standard compliance.
>
> We agree; see above.
>
> > Be sure to read the web pages' web pages (heh) that Alfie pointed you to. We
> > don't expect you to read all of it, but do read the introduction sections
> > and at least skim over the rest. If you have any questions not answered
> > there, don't hesitate to ask.
>
> I have now read (most of) the relevant web pages. I look forward to
> working on copying the debian-bsd.sf.net site tonight, in a few hours.
>
> - Jimmy Kaplowitz
> [EMAIL PROTECTED]
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
patch for base-passwd
I have written a patch for base-passwd that makes it work on FreeBSD. It isn't
exceptionally well tested, but it compiles and seems to work. (i.e. Converted
default FreeBSD master.passwd to a Debian-ized one.) I believe it would
probably also work on NetBSD, if the #ifdef's are changed to add NetBSD.
Someone please add those, test on NetBSD, and send changes back to me. Once
that's done, I'll work on getting it merged upstream.
---Nathan
diff -urN base-passwd-3.2.1/Makefile.in base-passwd-3.2.1-freebsd/Makefile.in
--- base-passwd-3.2.1/Makefile.in Tue Nov 30 09:27:22 1999
+++ base-passwd-3.2.1-freebsd/Makefile.in Sat Jan 26 19:35:26 2002
@@ -16,7 +16,7 @@
mandir = @mandir@
# Files used
-sources= update-passwd.c
+sources= update-passwd.c lckpwdf.c getopt.c getopt1.c
fgetpwent_r.c
objects= $(patsubst %.c, %.o, $(sources))
gen_autoheader = config.h.in
gen_autoconf = configure
diff -urN base-passwd-3.2.1/debian/postinst
base-passwd-3.2.1-freebsd/debian/postinst
--- base-passwd-3.2.1/debian/postinst Sat Apr 21 14:00:07 2001
+++ base-passwd-3.2.1-freebsd/debian/postinst Sat Jan 26 19:50:34 2002
@@ -12,14 +12,15 @@
ln -s ../share/doc/$pkg /usr/doc/$pkg
fi
-if [ ! -e /etc/passwd ] ; then
- cp /usr/share/base-passwd/passwd.master /etc/passwd
-fi
-
if [ ! -e /etc/group ] ; then
cp /usr/share/base-passwd/group.master /etc/group
fi
+if [ ! -e /etc/master.passwd ] ; then
+ awk -F: 'BEGIN {OFS=":"}{print $1,$2,$3,$4,"",0,0,$5,$6,$7}'
/etc/master.passwd
+ pwd_mkdb /etc/master.passwd
+fi
+
tmp=`tempfile`
if ! update-passwd --dry-run > $tmp ; then
cat pw_name=fields[0];
+ resbuf->pw_passwd=fields[1];
+ resbuf->pw_uid=atoi(fields[2]);
+ resbuf->pw_gid=atoi(fields[3]);
+ switch(cfields) {
+ case 10:
+ /* FreeBSD master.passwd file format */
+ resbuf->pw_class=fields[4];
+ resbuf->pw_change=atol(fields[5]);
+ resbuf->pw_expire=atol(fields[6]);
+ resbuf->pw_gecos=fields[7];
+ resbuf->pw_dir=fields[8];
+ resbuf->pw_shell=fields[9];
+ break;
+ case 7:
+ /* Linux passwd file format */
+ resbuf->pw_class=&buf[buflen]; /* pointer to NUL */
+ resbuf->pw_change=0;
+ resbuf->pw_expire=0;
+ resbuf->pw_gecos=fields[4];
+ resbuf->pw_dir=fields[5];
+ resbuf->pw_shell=fields[6];
+ break;
+ default:
+ /* invalid format */
+ return(0);
+ }
+ return(1);
+}
+
+static int gr_parse_line(char *buf,size_t linelen,size_t buflen,struct group
*resbuf);
+
+int fgetpwent_r (FILE *stream,struct passwd *resbuf,char *buffer,size_t
buflen, struct passwd **result)
+{
+ char *p;
+
+ *result=NULL;
+
+ while(*result==NULL) {
+ p=fgets(buffer,buflen,stream);
+
+ if(p==NULL && feof(stream)) {
+ errno=ENOENT;
+ return(ENOENT);
+ }
+ /* skip leading spaces */
+ while(isspace(*p))
+ *p++;
+ /* skip empty and comment lines */
+ if(*p=='\0' || *p=='#')
+ continue;
+ if(pw_parse_line(buffer,strlen(buffer),resbuf))
+ *result=resbuf;
+ }
+ return(0);
+}
+
+int fgetgrent_r (FILE *stream,struct group *resbuf,char *buffer,size_t buflen,
+struct group **result)
+{
+ char *p;
+
+ *result=NULL;
+
+ while(*result==NULL) {
+ p=fgets(buffer,buflen,stream);
+
+ if(p==NULL && feof(stream)) {
+ return(ENOENT);
+ }
+ /* skip leading spaces */
+ while(isspace(*p))
+ *p++;
+ /* skip empty and comment lines */
+ if(*p=='\0' || *p=='#')
+ continue;
+ if(gr_parse_line(buffer,strlen(buffer),buflen,resbuf))
+ *result=resbuf;
+ }
+ return(0);
+}
+
+#ifdef TEST
+int main(void)
+{
+ FILE *f;
+ char buf[8192];
Re: How to check for a GNU userland
I know exactly how you feel. I seem to be working on the FreeBSD port alone, also. Fortunately, some work can be shared back and forth. On Sun, Jan 27, 2002 at 09:11:51PM +0100, Andreas Schuldei wrote: > * Michael Goetze ([EMAIL PROTECTED]) [020127 02:37]: > > Still at it, eh? Mind telling us how far along you are? I haven't heard from > > you for a long time. > > I spare myself and you all the excuses for not beeing as far as > the netbsd port. Not so much happend, but I still work on it if i > have time. I would still enjoy doing this together with someone > else, not alone. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: How to check for a GNU userland
Agreed. It probably was for System V, which different vendors customized. Hardware vendors don't customize Linux, distributors do. However, that raises an interesting question: should uname be changed? On Sat, Jan 26, 2002 at 05:30:29PM -0800, Michael Goetze wrote: > > > config.guess returns CPU-Vendor-OS, not CPU-VENDOR-Kernel. > > I've never quite understood what the "vendor" is supposed to mean, exactly. I > mean, in the case of, say, a SparcStation running Solaris, it's pretty obvious > who the vendor is: > > sparc-sun-solaris, mips-sgi-irix, alpha-dec-tru64 > > However, in the case of PCs, the software and hardware are usually from > different sources. Now, which of these looks more useful to you? > > i386-compaq-linux, i386-dell-netbsd, i386-gateway-hurd > i386-debian-linux, i386-debian-netbsd, i386-debian-hurd > > Yeah, that's what I thought. > Either way, the "unknown" has to go, IMHO. > > - Michael > > = > -BEGIN GEEK CODE BLOCK- > Version: 3.12 > GCS/MU d- s+:+ a--- C++ ULISBH+++ P+++ L++(-) E- > W--(+) N o? K? w--- !O !M V?> PS+++ !PE Y+ PGP- > t+(-) 5 X R+>+++ tv-- b++ DI(+) D G e->+++ h r-- y > --END GEEK CODE BLOCK-- > > __ > Do You Yahoo!? > Great stuff seeking new owners in Yahoo! Auctions! > http://auctions.yahoo.com > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: How to check for a GNU userland
Working on Debian FreeBSD, I have been putting BSD tools into /usr/bsd/bin, and using PATH when I need them to build a package. The BSD kernel and libc want to have the native make, rather than GNU make, so it seemed like an easy solution. IIRC, Solaris has something similar in /usr/ucb/bin. I'm having a larger problem with libraries. That's where most of the headaches come from. Things like libnsl and libdl are in libc, but libintl is separate. And some native Debian packages expect getopt to be in libc, instead of using libiberty. On Sat, Jan 26, 2002 at 10:08:35PM +0100, Andreas Schuldei wrote: > * Jimmy Kaplowitz ([EMAIL PROTECTED]) [020126 21:19]: > > The uname command will not in any > > way reflect GNU or Debian, since we will be using NetBSD's kernel. So, > > what is the best way to check for the GNU userland tools? > > This is also a major pain for debian/OpenBSD, which tries to keep > the OpenBSD userland in takt as much as possible for security > reasons, if not other desired (e.g. by installing wu-ftp). > > I have reached the conclusion that this can only be solved by > individual checks in the configure scripts, for the presence of > the individual features you need (are certain command line > switches accepted? How does this command behave?) Some commands > are especially creepy, because they behave differently, even > without any switches, xargs for example. > > In the openbsd port I wrote wrappers around the tools, which are > looking at an environment variable and call the specified > toolchain's command. This is possible, because in different > phases of a buildprocess of a package ONLY GNU or ONLY BSD tools > are expected. Actually all 'native' debian packages require for > example GNU make and > the whole openbsd source tree the openbsd make. One has to > clean/set the environment variabel to get debian packages build > of bsd sources. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: bsdmainutils
I'd suggest looking through the diff for the package, and see if you can find where it's adding the bits you don't want. That's probably the easiest way. FreeBSD doesn't seem to have any langinfo stuff, or if they do, it's not in /usr/include. I'm not sure what it's supposed to do, anyway. I suspect that what you have is actually forked and heavily patched from FreeBSD. On Fri, Jan 25, 2002 at 02:04:16PM -0700, Joel Baker wrote: > In a display of amazing twistedness... bsdmainutils won't compile on a BSD > kernel/libc. As best I can tell, most of it is caused by various sections > of #ifdef DEBIAN which really should be #ifdef LINUX - but just turning off > the -DDEBIAN flag results in code being added which deals with non-existant > nl_langinfo calls in at least one or two places. > > The program copyrights indicate that almost all of them are from the > FreeBSD usr.bin source tree - but it must be a fairly recent one, possibly > using things that aren't available in NetBSD's tree, or even older FreeBSD > versions (I only have access to Stable -1, not Stable or Current). > > Any volunteers to work on untangling this mess? > -- > *** > Joel Baker System Administrator - lightbearer.com > [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: base-files
I believe it does support it, but it may not ship with it. On Fri, Jan 25, 2002 at 01:24:51PM -0700, Joel Baker wrote: > Having looked into base-files, the only file that seems to be at issue in > any form is nsswitch.conf - so, in quick summary, does NetBSD: > > A) Use this file at all? > > B) Support the 'compat' entries (the only major difference between the >tarball and the distributed file). > > Once this is resolved, base-files should become available. > -- > *** > Joel Baker System Administrator - lightbearer.com > [EMAIL PROTECTED] http://users.lightbearer.com/lucifer/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: APT archive
> Fully agreed. So perhaps the proposal should expand to include the kernel > as well as libc packages. > > Perhaps: > > libc-gnu-6.1 > kernel-source-linux-2.4.17 > kernel-headers-linux-2.4.17 I would prefer something like: freebsd-kernel-4.3 freebsd-source-4.3 freebsd-libc4 linux-kernel-2.4.17 linux-source-2.4.17 That's what I'm doing with the package I'm working on for the FreeBSD libc. (Haven't gotten to the kernel yet...) I think it'd be nicer to use a prefix, since that way the names sort together.
Re: Dependancies on libc
On Thu, Jan 24, 2002 at 06:24:04PM +0100, Jeroen Dekkers wrote: > On Wed, Jan 23, 2002 at 09:00:14PM -0700, Joel Baker wrote: > > Having run into a few packages, now, which have dependancies on specific > > GNU libc versions (or rather, libc versions, when all that the packaging > > system understands is libc == GNU libc), which compiled just fine under > > the NetBSD libc, I come to the following conclusion: > > > > We should request that a provision be made for desginating which libc is > > required, from the developer/policy community. As a starting point, I'll > > toss out one possible resolution: > > > > Rename the libc-* packages to libc-gnu-* (or gnu-libc-*), and use Provides > > headers to "fake" the old names, for a period of time (IE, to allow a grace > > period in which packages which depend on libc can change their dependancy > > listing). Other libc packages would then be libc-netbsd-* or netbsd-libc-* > > in a similar fashion, allowing proper dependancy declarations for any libc > > packages which might end up being part of Debian. > > > > Any thoughts? Comments? Spitwads? > > I don't know about what dependencies you're talking about. If you're > talking about "Build-Depends: libc6 (>= x.x.x)" renaming doesn't help > anything. It should be > "Build-Depends: libc6 (>= x.x.x) | netbsd-libc (>= x.x.x)". I suggest creating a virtual package called "libc" or something similar. Set libc6 to provide it. Then, my freebsd-libc4 package, and the netbsd-libc package can provide it also, and source dependacies are fine. Or what you suggest can be done also, for packages that need specific versions. I think having the virtual package could be convenient for other reasons. > I'm also thinking about porting glibc to *BSD. I think that would > solve very much problems, as a lot of programs just expect to have > glibc installed. A lot of kernel-specific things are already fixed > because we want them to compile on Debian GNU/Hurd. But the Hurd also > uses glibc, I expect really much trouble with that. Most people just > don't know how to write portable or don't care about it. I don't know > if I'm the only one thinking about porting glibc. Feel free. I looked at it, and I think I'd rather spend my time elsewhere. It would be a huge help, though. Even if you're successful, I think we'll need to have the BSD libc available for the kernel specific utilities. As for portable code, I think that's something that needs to change. Portable code tends to be better code. I'd rather see some of the Debian tools like apt become more portable than have a glibc port, because I think making those programs more portable will most likely improve them.
Re: Status of packages
On Thu, Jan 24, 2002 at 10:41:16AM +0100, Fabio Massimo Di Nitto wrote: > Joel Baker wrote: > > >Since we've been going about on this one, I decided that I should post a > >listing of the current packages I know of, and their status. The list is > >in three parts: > > > > That's nice.. what about a common repository for all these pkgs?? > freebsd-i386 has one already mentioned on debian-bsd.sf.net There are two. Dexter's is ancient. It's based on FreeBSD 3.x and slink, I believe. Mine is based on FreeBSD 4.3 and woody from a few months ago. I've been updating a bit, but it's not all in the archive yet. The archive at trantor.utsl.org is the most current there is. Hopefully in the next few weeks/months, I'll be able to get it a bit further.
Re: Dependancies on libc
On Wed, Jan 23, 2002 at 11:23:57PM -0500, Jimmy Kaplowitz wrote: > Please CC me on all replies, even though I am (finally) subscribed. It > works better with my mail sorting setup. > > On Wed, Jan 23, 2002 at 09:00:14PM -0700, Joel Baker wrote: > > Having run into a few packages, now, which have dependancies on specific > > GNU libc versions (or rather, libc versions, when all that the packaging > > system understands is libc == GNU libc), which compiled just fine under > > the NetBSD libc, I come to the following conclusion: > > > > We should request that a provision be made for desginating which libc is > > required, from the developer/policy community. > > This is not true; GNU libc is called libc6 rather than libc. So there is > no conflict. Also, the source packages don't generally have dependencies > on libc6, only the compiled binary ones (as makes sense for dynamically > linked Linux executables). Quite a few of them have build dependacies on libc6-dev. That will need to be changed. I suggest that we propose virtual packages. Actually, I'm thinking both libc and kernel should be handled that way. > By the way, in response to your question, I at least am an official Debian > developer; are there any others on this project? (This is mainly a question > out of curiosity rather than anything else.) I also am a Debian developer. I believe there were a couple others lurking here, and I have also seen posts by comitters for both NetBSD and FreeBSD.
Re: Patch for dpkg-shlibdeps
On Tue, Jan 22, 2002 at 05:23:50PM +0100, Jeroen Dekkers wrote: > On Tue, Jan 22, 2002 at 10:57:26AM -0500, [EMAIL PROTECTED] wrote: > > On Mon, Jan 21, 2002 at 09:31:45PM -0700, Joel Baker wrote: > > > On Mon, Jan 21, 2002 at 11:23:54PM -0500, Sam Hartman wrote: > > > > Is dpkg-shlibdeps broken on NetBSD or just FreeBSD? > > > > > > Well, that patch for using the NetBSD ldd binary. I don't currently have a > > > FreeBSD setup of any sort (nor another spare machine to run one on), so I > > > can't really answer effectively. :/ > > > > It breaks badly on FreeBSD, because ldd doesn't work on shared libraries. It > > sounds like it has a small difficulty with the output format on NetBSD. > > That's > > what the patch addresses. > > Could you try the python version of dpkg-shlibdeps? You can find it at > http://cvs.debian.org/dpkg-dev/scripts/?cvsroot=dpkg. We also use it > for the Hurd port because we have problems with the current > dpkg-shlibdeps. If it works we could put more pressure on the dpkg > maintainers. I'll give it a try sometime after I get python working. However, unless it doesn't use ldd, it probably won't work either.
Re: Patch for dpkg-shlibdeps
On Mon, Jan 21, 2002 at 09:31:45PM -0700, Joel Baker wrote: > On Mon, Jan 21, 2002 at 11:23:54PM -0500, Sam Hartman wrote: > > Is dpkg-shlibdeps broken on NetBSD or just FreeBSD? > > Well, that patch for using the NetBSD ldd binary. I don't currently have a > FreeBSD setup of any sort (nor another spare machine to run one on), so I > can't really answer effectively. :/ It breaks badly on FreeBSD, because ldd doesn't work on shared libraries. It sounds like it has a small difficulty with the output format on NetBSD. That's what the patch addresses. The difference has to do with the ELF implementations, which apparently were done independently. I may try to port the NetBSD ldd sometime, but I have dpkg-shlibdeps working ok with ldconfig. ---Nathan
Re: Proposed patch management/build solution
On Mon, Jan 21, 2002 at 03:36:01PM -0500, Sam Hartman wrote: > >>>>> "utsl" == utsl <[EMAIL PROTECTED]> writes: > > utsl> This is a good idea. I'm interested in it. Why not simply > utsl> import the standard Debian source packages as vendor > utsl> branches, and use the normal CVS facilities to track the > utsl> changes? This seems simpler than keeping patches in separate > utsl> files, as you describe below. > > Two reasons. First is the bandwith requirement. Some people involved > may not be close to the central CVS server. cvsup? They have to download the source packages anyway. Perhaps people could comment on how big an issue it is. > Second is that DBS style packages do not work well with CVS at all. > Checking in tar files sucks. Hmm. I can't think of a good solution to that. Only thing I can say is that I've noted that the vast majority of changes that I've made were to the debian directory, mostly debian/rules. I do recall doing a patch for a DBS package, shadow I think, but I put the patch into the debian directory instead of changing the tar file. > I'll try and put things together and once I have something perhaps I > can get added to the sourceforge project so I can check it in. > > I agree with your analysis of the three kinds of patches. I think I may be able to add you to it. What's your id on sourceforge? ---Nathan
Re: Proposed patch management/build solution
This is a good idea. I'm interested in it. Why not simply import the standard Debian source packages as vendor branches, and use the normal CVS facilities to track the changes? This seems simpler than keeping patches in separate files, as you describe below. Also, it should work with cvsbuildpackage. It's worth noting that there are three common kinds of patches: 1. Patches needed to get the package to build or work, because XYZ isn't there yet. (i.e. Don't build documentation, because there's no SGML tool.) 2. Patches to fix confused makefiles. Some packages don't use configure, (or don't have some of the tests they need) and have to be tweaked to work in the Debian BSD environment. 3. Libc differences. Some packages assume glibc, and fail because of that. These seem to be mostly Debian native packages. The first kind of patch is temporary, and can go away once things are further along. The other two kinds need to be sent upstream. The real difficulty is getting them separated out, and having someone get them merged back into the sources. I know that in my case, I was primarily trying to get a minimal base system working, so that I could get rid of all of the first type of patches (kludges really), and go on and deal with the real issues. On Mon, Jan 21, 2002 at 12:15:46PM -0500, Sam Hartman wrote: > > > As I mentioned Saturday, I'm interested in helping set up some sort of > system for managing patches that we are not comfortable sending back > to Debian packages yet. > > I'm concerned that without such a system: > > * Different people will each set up their own archives of packages > with different mechanisms for marking local changes > > * Some of these archives may not include source packages and thus may > violate the GPL or other licenses > > * It will not be easy or possible for a random person to rebuild the > entire system, which could be critical for debugging > > * We may not easily be able to pull in new versions as Debian >packages evolve, or we may accidentally lose changes we want to >keep > > I have a proposal for how I plan to do things. My design goals are as > followss: > > * Facilitate development by a group of people not just individuals > > * Slightly more centralization than the standard Debian archive; the > standard Debian archive has several conditions that make its > decentralization work that i don't think currently apply to this > project. I can go into detail if people like, but I'd rather do so > off list. > > * Single well defined format for describing NetBSD-specific changes > > * Mandate that people describe their changes and clearly label our > versions as modified > > * Set up version control. What we are doing is clearly active > development; it is easy to show that many problems result from not > having good version control for active development software > projects. > > * Minimize bandwith. Several of the people involved seem to have > limited Internet connections. Requiring them to download large > chunks of source over the net rather than from convenient local > mirrors would decrease their ability to contribute. > > So, here's what I propose to do. I want to set up a CVS repository > with two top level directories. The first directory will be called > packages; it will contain any BSD-native packages we've developed. > It will contain their sources in a format compatible with > cvs-buildpackage. I know at least one such package will exist. > > The second directory will be called patches and will contain > directories corresponding to source packages we've had to patch to get > them to build on BSD. Each source package directory will contain some > or all of the following: > > * A file called version that contains the version of the source > package these patches are for. > > * A file called patch that will be applied after the dpkg-source -x > > * A file called changelog.add that will be prepended to > debian/changelog > > * One or more files called after-foo-patch which will be applied after > running debian/rules foo. The most common example might be > after-setup-patch which should help with DBS patches > > I will also write a small native package that contains a script to > build a source package based on one of these patch directories and a > program to build all patched packages. > > Then we can set up this CVS repository somewhere (presumably initially > sourceforge) and allow people to start committing their patches. I > think this organization will really help me be able to debug things > and make forward progress; will it help others enough to be used? > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: APT archive
On Mon, Jan 21, 2002 at 01:36:51PM +0100, Wessel Dankers wrote: > On 2002-01-20 21:58:11-0700, Joel Baker wrote: > > On a sidenote... I'm a bit worried at the errors I'm seeing out of the > > shared-lib dependancy autogenerator stuff. Is this still broken? (I don't > > mind re-building all of the packages, once it's fixed, if so, but I would > > sort of like to know...) > > At least on FreeBSD, shared objects can't be ldd'd, which happens to be > exactly what debhelper does. Perhaps these .so's don't include information > for ldd to extract? It's really weird, because it's supposed to be ELF. Yes, I had some trouble with that at first. I have it solved, however. I altered dpkg-shlibdeps to use ldconfig -r instead. It turns out that all it really needed was a list of the paths of the shared libraries. It gets the list of libraries dependacies from objdump -p, and really only uses ldd to get paths for them. ldconfig -r provides that, and everything works fine.
Re: Website and library packages
Would you mind posting a patch? I'd like to see if I can get your modifications to work in my FreeBSD chroot. Thanks, ---Nathan On Sun, Jan 20, 2002 at 12:27:23AM +, Matthew Garrett wrote: > On Thu, Jan 17, 2002 at 04:27:33AM +, Matthew Garrett wrote: > > Ok, it turns out that this doesn't look too bad. In shadow-foo/lib we have > > a stack of code that performs the actual manipulation of the files, with > > all the utilities using that. There's code there for manipulation of > > dbm-style passwd files, so it shouldn't be too difficult to hack in code > > to support the NetBSD password databasesand then just call pw_mkdb > > afterwards. What we do lose is any ability to use the extended features > > that are offered over traditional password files, but we keep the ability > > to use PAM. Combining both sets of features into one set of tools looks > > like a little more work :) > > Right, as of today I have a working passwd program. Most of the other > utilities from shadow also work, although I haven't fixed group handling > yet so addgroup (and hence adduser) aren't happy. This is without PAM - > I've modified libshadow in the following ways: > > 1) commonio.c now uses the BSD pw_lock and pw_mkdb functions (I spent some > time trying to figure out why pw_mkdb didn't work in the chroot until I > looked at the libutil source and found that my assumption that the > pwd_mkdb utility called the library function was incorrect - instead, the > library calls the utility. Copied that over into the chroot and everything > became happy) > 2) pwio.c uses getpwnam(), and pw_lock() was renamed to pw_filelock() to > avoid colliding with libutil's pw_lock(). All the utilities had to be > modified to cope with this. > 3) putpwent.c was modified to output stuff in the right format > > There's no support for password aging, expiry or user classes, but those > ought to be relatively easy to add. I'll build a package tomorrow and > upload it. The code isn't pretty at the moment, and I'm sure it's full of > horrible race conditions and suchlike, but it's an improvement over having > no functionality at all :) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: getting apt to work
On Fri, Jan 18, 2002 at 02:47:40PM -0500, Sam Hartman wrote: > > Hi. I'm not sure I see any conclusion to the apt thread. Does anyone > have apt-get working (instead of segfaulting) using the apt in the > distributed chroot? If so, how? If not, does anyone have apt working > using other builds? I never got apt to compile on FreeBSD. I think it had problems with the C++ libraries. I was just looking at debootstrap, though. It looks like it could be very useful to get it working on BSD to setup the chroots, rather than downloading big tarballs. ---Nathan
Re: "Why Debian NetBSD"
On Fri, Jan 18, 2002 at 03:12:30PM -0500, Sam Hartman wrote: > > "Jeremy" == Jeremy C Reed <[EMAIL PROTECTED]> writes: > > Jeremy> It all depends on your (or RMS's) personal definition of > Jeremy> "freedom". Definitely BSD websites promote free software > Jeremy> -- in fact, they encourage the use of their code in > Jeremy> proprietary, closed-source applications and devices. (When > Jeremy> your force freedom on someone are they free?.) > > Fortunately we are Debian and we have a definition of free that those > of us who are part of the project accepted when we joined. Under this > definition both the GPL and the BSD license are free. Can we head off > the flamewar about whether GPL is free, because in the Debian context > it is defined (by name) to be free. Also, Debian does not define a > comparison operator on freedom; asking what license is more free than > another is not worth the bandwith it takes provided they are both > free. That was very well stated. I would like to see the political arguements about licenses taken off-list. There are plenty of other forums for it. --Nathan
Re: Website and library packages
On Fri, Jan 18, 2002 at 05:48:48PM +0100, Jeroen Dekkers wrote: > On Thu, Jan 17, 2002 at 02:46:29AM +, Matthew Garrett wrote: > > > That approach gets rid of a lot of hassles associated with upgrading the > > > sources, and allows people to rebuild their kernel and core system. You > > > just > > > pull the new sources from CVS, and use the scripts to build debs. A lot > > > like > > > kernel-package, except that it has to handle more packages. > > > > I've left the CVS directories in there, so it ought to be possible for > > package maintainers to deal with upgrades. On the other hand, the idea of > > a user being able to upgrade stuff in-situ sounds rather cool :) I'm not > > sure whether the best policy here is to stick with the existing Debian > > mentality of individual packages dealt with by different maintainers or a > > huge package with the user having more choice over updates as you > > suggest. What does everyone else think? > > I think we should do it the way it's currently done in Debian for > now. If we want to use CVS, we should set it up Debian-wide. I like > the idea of using CVS for Debian source packages. What I had in mind was that you'd get an equivilent to kernel-package, which would be able to get it's source either from a kernel-source type package, or with cvsup from the CVS repository for NetBSD or FreeBSD. Not that different from Linux, just the ability to get updated source code through CVS. This is something that makes it easier for users who build their own kernels, and also easier for whoever makes the official ones. Like kernel-package does on Linux. The important question isn't CVS. It's whether to try to break up a very large set of source into separate source packages, which need to be at synchronized versions, or to simply build some scripts to turn it into multiple packages. ---Nathan
Re: GNU GNU GNU
> Mind you, I don't think it's worth having a protracted flame war over. Then let's just kill the thread now. Until it's a lot closer to a release, discussing what the name should be seems a bit pointless.
Re: Website and library packages
On Thu, Jan 17, 2002 at 04:27:33AM +, Matthew Garrett wrote: > On Wed, Jan 16, 2002 at 09:16:10PM -0500, [EMAIL PROTECTED] wrote: > > * On the webpage, you mention problems with shadow: > > I had the exact same problem with FreeBSD, and I see two choices. Either use > > native passwd, adduser, etc. or get the shadow package to build a library (I > > believe it can, but it's disabled), and recompile the Debian passwd and > > friends > > with that. Then it's just a matter of getting PAM working. > > Ok, it turns out that this doesn't look too bad. In shadow-foo/lib we have > a stack of code that performs the actual manipulation of the files, with > all the utilities using that. There's code there for manipulation of > dbm-style passwd files, so it shouldn't be too difficult to hack in code > to support the NetBSD password databasesand then just call pw_mkdb > afterwards. What we do lose is any ability to use the extended features > that are offered over traditional password files, but we keep the ability > to use PAM. Combining both sets of features into one set of tools looks > like a little more work :) Hmm. I was thinking more in terms of a libshadow. I seem to recall that there used to be one, back with libc5, and I think that the shadow source package still can make one. (If I remember right, it was disabled in the build on Debian, because it's in glibc.) If so, you should be able to get passwd and everything from Debian working by just adding -lshadow to the Makefiles. In fact, I suspect you'd find that configure would pick it up automatically for a lot of packages, because Solaris uses libshadow, and configure would know to look for it. That wouldn't be compatible with NetBSD passwd databases, though. But then, rewriting update-passwd didn't seem like fun to me. I couldn't even get it to compile on FreeBSD. ---Nathan
Re: Website and library packages
On Thu, Jan 17, 2002 at 03:38:04PM +1100, matthew green wrote: > >utilities and libraries NEED to be built together with the kernel. It's a >feature in the BSD world. It'd be easer to keep them in sync if they're > built > > > hmm, i wouldn't call it a feature :-) certainly in NetBSD we've done a > lot of work to remove these sorts of issues... and the trend is only > going to continue in the future. cf, ps(1) and most of the *stat utilties > now no longer require the same-vintage kernel. there are still a lot > remaining, and things like "ipfilter" will never be do-able otherwise, > given the current way ipfilter is modified :-) Sorry, that was meant kind of tongue-in-cheek. There was a lively discussion of it when I joined the list. (Someone thought that it was a reason why a Debian BSD was a very bad idea.) I'm glad to hear things are changing for the better. Yeah, I read about the ipfilter license issues with OpenBSD. Have you guys thought about porting over OpenBSD's new replacement? It might be less work to deal with in the long term. ---Nathan
Re: Website and library packages
On Thu, Jan 17, 2002 at 02:46:29AM +, Matthew Garrett wrote:
> On Wed, Jan 16, 2002 at 09:16:10PM -0500, [EMAIL PROTECTED] wrote:
> > * About packaging from /usr/src:
> > I had been planning on writing something similar to kernel-package for
> > FreeBSD.
> > The basic idea was to do a make buildworld against the regular FreeBSD
> > source
> > tree, and then make multiple packages out of it. (i.e. libc package, kernel
> > package, etc.)
>
> That's something which hadn't occured to me :) Yes, that probably makes
> things somewhat easier in some ways, although we end up with a rather huge
> source package. I guess that it would probably be somewhat stripped down
> to only include the stuff that we're concerned about? (That is one thing
> I've found, though - a couple of the source packages I've built include
> stuff from the kernel source, so building them both from the same package
> would reduce duplication)
A large source package isn't necessarily a big deal. Most people are probably
just going to use CVS, so the package that does the build could be separate,
like kernel-package is separate from kernel-source. I believe you can do
something with the supfile to limit which parts of the CVS tree it downloads.
That might help reduce the size somewhat.
It's not just duplication, there's also the fact that many of the userspace
utilities and libraries NEED to be built together with the kernel. It's a
feature in the BSD world. It'd be easer to keep them in sync if they're built
as packages which depend on an exact kernel package version.
> > That approach gets rid of a lot of hassles associated with upgrading the
> > sources, and allows people to rebuild their kernel and core system. You just
> > pull the new sources from CVS, and use the scripts to build debs. A lot like
> > kernel-package, except that it has to handle more packages.
>
> I've left the CVS directories in there, so it ought to be possible for
> package maintainers to deal with upgrades. On the other hand, the idea of
> a user being able to upgrade stuff in-situ sounds rather cool :) I'm not
> sure whether the best policy here is to stick with the existing Debian
> mentality of individual packages dealt with by different maintainers or a
> huge package with the user having more choice over updates as you
> suggest. What does everyone else think?
You could do a big source package in CVS, and have a team maintain it. That
seems oddly appropriate. ;-)
> > On a related note, FreeBSD's Makefiles use "make" sometimes where they
> > should
> > use "${MAKE}", so I put the BSD make into /usr/bsd/bin. Then I mangle $PATH
> > before running make from debian/rules, so that the FreeBSD Makefiles always
> > get BSD make rather than GNU. Sounds like NetBSD has better Makefiles.
>
> Yup, this isn't something I've encountered so far.
>
> > * On the webpage, you mention problems with shadow:
> > I had the exact same problem with FreeBSD, and I see two choices. Either use
> > native passwd, adduser, etc. or get the shadow package to build a library (I
> > believe it can, but it's disabled), and recompile the Debian passwd and
> > friends
> > with that. Then it's just a matter of getting PAM working.
>
> PAM seems to be working (due to the problems with passwd and company I
> haven't been able to check it too effectively yet), but there were some
> issues with applying both the NetBSD patches and the Debian patches. I
> think I got those sorted, but doing this in a clean way that works with
> the existing package isn't going to be a great deal of fun :)
Oh, but it's so educational! I've always found PAM to be a complete PITA to
get right.
> > I'd just use the BSD utilities. Most users probably either use ifup/ifdown,
> > or can figure it out. It should be much easier to modify ifup to know about
> > BSD-style ifconfig than to try to make some replacement that's compatible.
> > Besides, Linux already has both ifconfig/route and "ip", with totally
> > different
> > semantics.
>
> Ah, that's true. Yup, the init scripts all use ifup now, so just having
> our own version of that ought to deal with the problem nicely.
I'd suggest that if it's at all possible, merge into the usual ifup.
---Nathan
Re: "Why Debian NetBSD"
On Thu, Jan 17, 2002 at 02:35:04AM +, Matthew Garrett wrote: > I've added a webpage (http://debian-bsd.sourceforge.net/why.html) with > some reasons why I think this project is worthwhile. Does anyone have any > objection to any of the reasons listed or have any suggestions for extra > ones that can be added? The main reason I'm interested: The development process that Linux 2.4 seems to be going through. The BSDs seem to have much saner release processes. 2.4.9 and 2.4.12 were pretty scary. I'd like to have a more reliably stable alternative for my production systems. I don't see the Hurd filling that role in the immediately forseeable future. > On a related note, I've been wondering about the GNUishness of this. In > contrast to GNU/Linux, we're quite conspicuously not using the GNU C > library, and a few other bits and pieces that would be GNU on a Linux > system are BSD on ours. > > 1) The rest of the fundamental userland is still GNU. Is this enough to > warrant calling it GNU/NetBSD? > 2) Were we to call it GNU/NetBSD, would this be likely to be perceived as > insulting by the NetBSD community? On the one hand it might sound like a > grab by the GPL movement, but on the other hand it does clearly > acknowledge the NetBSD contribution and differentiates it further from > "true" NetBSD > 3) Were we to fail to call it GNU/NetBSD, would we stand any chance > whatsoever of getting it into Debian proper? > > My personal preference would probably be for GNU/NetBSD, but at the same > time I have no desire whatsoever for us to end up alienated from the > NetBSD people who have provided such useful advice so far. Comments? On this one, I think you'll find that you can't make everybody happy. No matter what you do, somebody will have a problem with it. (See the archives for this list if you don't believe me...) Personally, I still think that GNU/Linux is a silly name, but I also don't think it's worth arguing over. The choice is whether you offend RMS, or possibly the NetBSD community. (I'd just about guarrantee that RMS would favour GNU/NetBSD.) It's not exactly a certainty that you'd offend the NetBSD folks, but RMS is consistant, noisy, and never gives up. (Not that those are bad things to be. :-) So I'd suggest that you ask the NetBSD leaders nicely, and see how they feel about the name Debian GNU/NetBSD. Hopefully, they won't really mind... ---Nathan
Re: Website and library packages
On Thu, Jan 17, 2002 at 12:08:00AM +, Matthew Garrett wrote:
> I've now uploaded the web page to http://debian-bsd.sf.net and am
> redirecting people there from the old location. It's also reminded me that
> there's currently several libs in the chroot that are just copied in there
> rather than packaged - packaging them shouldn't be too difficult. What I'm
> doing for the NetBSD-based packages at the moment is mainly just putting
> the relevant part of the /usr/src tree into a directory
> (/usr/src/lib/libc, for instance), making sure that make descends into it
> and using make-bsd in the debian/rules rather than make. make-bsd
> clean; make-bsd; DESTDIR=$(currdir)/debian/tmp make-bsd install seems to
> do the job adequately.
I read you web page, and have a couple comments about that as well as your
email:
* About packaging from /usr/src:
I had been planning on writing something similar to kernel-package for FreeBSD.
The basic idea was to do a make buildworld against the regular FreeBSD source
tree, and then make multiple packages out of it. (i.e. libc package, kernel
package, etc.)
That approach gets rid of a lot of hassles associated with upgrading the
sources, and allows people to rebuild their kernel and core system. You just
pull the new sources from CVS, and use the scripts to build debs. A lot like
kernel-package, except that it has to handle more packages.
On a related note, FreeBSD's Makefiles use "make" sometimes where they should
use "${MAKE}", so I put the BSD make into /usr/bsd/bin. Then I mangle $PATH
before running make from debian/rules, so that the FreeBSD Makefiles always
get BSD make rather than GNU. Sounds like NetBSD has better Makefiles.
* On the webpage, you mention problems with shadow:
I had the exact same problem with FreeBSD, and I see two choices. Either use
native passwd, adduser, etc. or get the shadow package to build a library (I
believe it can, but it's disabled), and recompile the Debian passwd and friends
with that. Then it's just a matter of getting PAM working.
* Also on the webpage, you mention netbase:
I'd just use the BSD utilities. Most users probably either use ifup/ifdown,
or can figure it out. It should be much easier to modify ifup to know about
BSD-style ifconfig than to try to make some replacement that's compatible.
Besides, Linux already has both ifconfig/route and "ip", with totally different
semantics.
---Nathan
Re: Further development
I have just put my FreeBSD box back online. So for anyone who's interested, my Debian/FreeBSD chroot tar and debs are available at ftp://trantor.utsl.org/pub Unfortunately I haven't had time to work on this for a few months. On Tue, Jan 15, 2002 at 03:29:33PM +, Matthew Garrett wrote: > There's now an updated image at > http://www.srcf.ucam.org/~mjg59/debian-netbsd/debian-netbsd.tar.gz and > I've written a brief webpage at > http://www.srcf.ucam.org/~mjg59/debian-netbsd/ - I seem to recall somebody > having access to the debian-bsd site on Sourceforge, so would it be > possible to either copy the webpage across or give me access so that I can > upload it myself? > > (oh, and we're in DWN tomorrow. Smile :) ) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: dpkg: adding a "Kernel:" tag to control files
How about being just a little bit more generic: Use an ABI tag, and let kernel or library packages provide that ABI. Then, when you enable Linux binary emulation on that NetBSD kernel, have it provide both "abi-netbsd" and "abi-linux". At that point, it could allow packages for either to be installed. Same thing also could apply to 32/64 bit environments. Use something like "abi-sparc32" vs. "abi-sparc64", and let 64 bit machines support both. On Fri, Nov 09, 2001 at 09:44:01PM +0100, Robert Millan wrote: > Package: dpkg > Severity: wishlist > > Hello, > > I'd like to suggest adding a "Kernel:" tag to the control file. I think > it'd be very useful to allow combinations of kernels and architechtures > that need to be done manually as now. Moreover, in the future with > the coming of kernel-ports like GNU/Hurd, GNU/*BSD and GNU/W32, this > would become still more useful. > > The most dramatical situation we could find is that, if someday we have a > debian > port for, say, each of the 45 (and more to come) architechture NetBSD is > ported > to, the maintainer of a netbsd-specific package will be forced to type > *all* > the architechtures: > > Architechture: netbsd-i386, netbsd- (up to 45 entries) > > While if we had a Kernel: tag it'd be as simple as this: > > Architechture: any > Kernel: netbsd > > Please implement this feature, for this would add a lot of flexibility to > porters > working on non-linux ports. > > Regards, > > -- > -- > Robert Millan Debian GNU/Hurd user > zeratul2 wanadoo eshttp://getyouriso.dyndns.org/ > -- > GPG ID C8D6942C > 237F 8688 C2E5 BC64 E152 97B4 FB28 D41B C8D6 942C > -- > Some words for my friends Carnivore and Echelon > -- > FBI CIA NSA Assault Bomb Terrorism Jihad > Allah Ossama Bin Laden Saddam Hussein > Handgun Assault Plane Crash Pentagon > World Trade Center Whitehouse President Bush > Putin Twin Towers Air Force One USA America > DeCCS RIAA BSA piracy illegal drugs heroin > Big Brother is watching you defcon nuclear > holocaust world war arabian afghanistan > cryptography PGP GPG crack RSA algorithm > Chechnya OMON Spetsnaz T-72 Merkava M1A1 Abrams > Chieftain Challenger Turret Apache Missiles Skinheads > troopers Kazakhstan Muhhamed Atta > --- > Put this in your signature and join us in confusing the Big Brother > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: installing chroot environment
I just put my chroot into a tar. You'll need a working FreeBSD 4.x system to check it out. I'm using FreeBSD 4.3, so that's most likely to work. Go to ftp://skaro.quic.net/pub. You'll see world.tar.bz2, which is the chroot, and a debs directory. On Wed, Oct 24, 2001 at 07:52:58PM -0700, Santiago Canez wrote: > Hey all, > > After being on this list for a while, I am finally going to start doing > some work myself. So my question is, how would I go about installing one > of the working chroot environements and where can I find some? Do I need a > working Debian system to start or what? > > Thanks for the info > SC > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: state of the different chroot environments
I have gcc and binutils in my FreeBSD chroot. If I get a chance, I'll make a tar of it before I go on vacation, but I probably won't have time. :-( I've attached the dpkg -l from my chroot. These packages mostly work, but there are a few that aren't working yet. I've begun packaging FreeBSD components, starting with the libc. Still trying to figure out how to handle shadow passwords, because the FreeBSD libc and utils are apparently incompatible with Debian's utils. Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name VersionDescription +++-==-==- ii autoconf 2.13-27automatic configure script builder iU base-files 2.2.10 Debian base system miscellaneous files iU bash 2.05-6 The GNU Bourne Again SHell iU bash-builtins 2.05-6 Bash loadable builtins - headers & examples ii bash-doc 2.05-6 Documentation and examples for the The GNU B ii binutils 2.11.90.0.7-2 The GNU assembler, linker and binary utiliti ii binutils-dev 2.11.90.0.7-2 The GNU binary utilities (BFD development fi ii binutils-doc 2.11.90.0.7-2 Documentation for the GNU assembler, linker ii bzip2 1.0.1-12 A high-quality block-sorting file compressor ii chill 2.95.3-7 The GNU Objective-C compiler. ii chill-2.95 2.95.4-0.01042 The GNU Chill compiler. ii cpp2.95.3-7 The GNU C preprocessor. ii cpp-2.95 2.95.4-0.01042 The GNU C preprocessor. ii cpp-2.95-doc 2.95.4-0.01042 Documentation for the GNU C preprocessor (cp ii cpp-3.0-doc3.0-4 Documentation for the GNU C preprocessor (cp iU debhelper 3.0.40 helper programs for debian/rules iU debiandoc-sgml 1.1.49 DebianDoc SGML DTD and formatting tools ii debianutils1.15 Miscellaneous utilities specific to Debian. ii diff 2.7-25 File comparison utilities ii diff-doc 2.7-25 Documentation for GNU diffutils. ii dpkg 1.9.16 Package maintenance system for Debian iU dpkg-dev 1.9.16 Package building tools for Debian ii dpkg-doc 1.9.16 Dpkg Internals Documentation ii ed 0.2-19 The classic unix line editor ii file 3.33-5 Determines file type using "magic" numbers ii fileutils 4.1-2 GNU file management utilities. ii findutils 4.1.7-2utilities for finding files--find, xargs, an ii freebsd-libc4 4.3_STABLE-1 FreeBSD libc4 shared libraries ii g++2.95.3-7 The GNU C++ compiler. ii g++-2.95 2.95.4-0.01042 The GNU C++ compiler. ii g772.95.3-7 The GNU Fortran 77 compiler. ii g77-2.95 2.95.4-0.01042 The GNU Fortran 77 compiler. ii g77-2.95-doc 2.95.4-0.01042 Documentation for the GNU Fortran compiler ( ii gawk 3.1.0-1GNU awk, a pattern scanning and processing l ii gcc2.95.3-7 The GNU C compiler. ii gcc-2.95 2.95.4-0.01042 The GNU C compiler. ii gcc-2.95-doc 2.95.4-0.01042 Documentation for the GNU compilers (gcc, go ii gcc-3.0-base 3.0-4 The GNU compiler collection (base package). iU gcj2.95.3-7 The GNU Java compiler. ii gobjc 2.95.3-7 The GNU Objective-C compiler. ii gobjc-2.95 2.95.4-0.01042 The GNU Objective-C compiler. iU gpc2.95.3-7 The GNU Pascal compiler. ii grep 2.4.2-2GNU grep, egrep and fgrep. ii gzip 1.2.4-33 The GNU compression utility. ii hostname 2.09 A utility to set/show the host name or domai ii html2text 1.2.4-6An advanced HTML to text converter. ii info 4.0-5 Standalone GNU Info documentation browser ii less 358-7 A file pager program, similar to more(1) ii libbz2-1.0 1.0.1-12 A high-quality block-sorting file compressor iU libbz2-dev 1.0.1-12 A high-quality block-sorting file compressor ii libkpathsea-de 1.0.7+20001218 kpathsea.a and include files for teTeX ii libkpathsea3 1.0.7+20001218 shared libkpathsea for teTeX ii libncurses55.2.20010318-2 Shared libraries for terminal handling iU libncurses5-db 5.2.20010318-2 Debugging/profiling libraries for ncurses iU libncurses5-de 5.2.20010318-2 Developer's libraries and docs for ncurses ii libreadline4 4.2-5 GNU readline and history libraries, run-time ii libreadline4-d 4.2-5 GNU readline and history libraries, debuggin iU libreadline4-d 4.2-5 GNU readline and history libraries, developm ii libstdc++2.10 2.95.4-0.01042 The GNU stdc++ library ii libstdc++2.10- 2.95.4-0.01042 The GNU stdc++ library (debugging files) ii libstdc++2.10
Re: update on Debian/FreeBSD
That's what it looked like in CVS. I briefly considered trying to port ldd from NetBSD. They are implemented very differently. On NetBSD ldd does all the work, while on Linux and FreeBSD, it is just a wrapper around ld.so. The difference is that the ld.so on Linux has a workaround for shared libraries, but the FreeBSD one doesn't. I don't feel prepared to hack the FreeBSD ld.so yet. Maybe when I'm more familiar with the system... On Sun, Aug 05, 2001 at 03:13:05AM +1000, matthew green wrote: > > > FWIW, it seems that the NetBSD ELF `ldd' works with shared libraries. > i don't have an a.out system to test with but you can probably ignore > that as most netbsd port have switched or are in the process of > switching to ELF. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: update on Debian/FreeBSD
I'm using dpkg 1.9.16, which I believe was from unstable. I checked CVS, and it looked like 1.9.16 had just been released when I got it. I'm using testing and sid, for the most part. I had to downgrade a few things, like gcc and perl, because I couldn't get the latest versions to compile. So for now I'm using gcc 2.9.4 and perl 5.005. I'm also using FreeBSD-STABLE. dpkg-shlibdeps is using both ldd and objdump. It's using ldd to get the paths for all the shared libs, and matching them up with the list of libs from objdump's NEEDED field. FreeBSD's ldd doesn't work with shared libraries, so FreeBSD, I switched to using ldconfig -r, which seems to provide what it needs, after a little mangling of the output. I think it is probably a FreeBSD- specific problem and solution. On Sat, Aug 04, 2001 at 12:38:12PM +0200, Filip Van Raemdonck wrote: > On Thu, Aug 02, 2001 at 09:49:07PM -0400, [EMAIL PROTECTED] wrote: > > The list has been quiet the last couple days, so I thought I'd post some > > updates from my adventures with FreeBSD: > > > * Figured out how to "fix" dpkg-shlibdeps. It wanted to use ldd on shared > >libs, but I hacked it to get a list of libs from ldconfig -r instead. It > >seems to work now. > > Everyone should start using (at least[1]) unstable for what they are doing. > As an example, dpkg in unstable hasn't been using ldd since november last > year, as ldd for shlibdeps was giving all kinds of problems. It uses objdump > instead now. > > Potato is a static release, no development is being done on it anymore, only > security fixes. If people keep using potato to work with, they may easily > bump into problems that they may not have had with sid. > > Regards, > > Filip > > [1] For dpkg and apt it may be wise even to use cvs, for the time that > Debian/BSD doesn't get officially into the archives. Even the unstable > versions of those two tools tend to "get old" fast when compared to the > sources available from cvs.debian.org > > -- > "When we said that you needed to cut the wires for ultimate security, > we didn't mean that you should go wireless instead." > -- Casper Dik
Re: update on Debian/FreeBSD
That's a good idea. I should subscribe to some of those lists, anyway. But now that I have it working with ldconfig -r, I don't think it'll be necessary to hack ldd. Now if I could just figure out how to handle utmp... :-) On Sat, Aug 04, 2001 at 01:11:04PM -0500, Steve Price wrote: > On Sat, Aug 04, 2001 at 01:51:01PM -0400, [EMAIL PROTECTED] wrote: > > That's what it looked like in CVS. I briefly considered trying to port ldd > > from > > NetBSD. They are implemented very differently. On NetBSD ldd does all the > > work, > > while on Linux and FreeBSD, it is just a wrapper around ld.so. The > > difference > > is that the ld.so on Linux has a workaround for shared libraries, but the > > FreeBSD one doesn't. I don't feel prepared to hack the FreeBSD ld.so yet. > > Maybe > > when I'm more familiar with the system... > > Perhaps you could ask on one of the FreeBSD mailing lists for > assistance? I know John Polstra is usually the one that does > the ELF loader changes but maybe someone on [EMAIL PROTECTED] > can help with a workaround. > > -steve > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
update on Debian/FreeBSD
The list has been quiet the last couple days, so I thought I'd post some updates from my adventures with FreeBSD: Good news: * I built my first package in the chroot. Bash was giving me problems with libreadline, so I decided to try it in the chroot, and it worked. I had to force install it though, because base-passwd isn't working yet. * Figured out how to "fix" dpkg-shlibdeps. It wanted to use ldd on shared libs, but I hacked it to get a list of libs from ldconfig -r instead. It seems to work now. * Just built a package for the FreeBSD libc. That's the first step in my multi-binary package for /usr/src. That was lots of fun... It actually seems to be working! Bad news: * utmp: just about everything that compiles against utmp.h fails. Debian tools are expecting a SysV-ish utmp, and it just isn't there. * libiberty: some of the Debian-specific packages are expecting getopt_long to be in libc. I'm temporarily using freelibiberty from the ports to get things working. Probably will need to fix configure, and possibly include the libiberty stuff into those packages. * shadow.h: FreeBSD doesn't seem to implement the standard shadow password functions in it's libc. (No getspnam and friends.) So far, I've learned that this breaks base-passwd.
Re: Problems with init
I'm in favour of improving things where possible. I'm also in favour of staying reasonably compatible unless there's a compelling reason not to. Personally, I think the ability to use scripts from /etc/init.d after booting is more important than the details of how init runs them. Whether I use the rc-file or rc.d is a lot less important to me. The specific idea of using dependacies in rc/init system is a good one. I've wondered about it myself a few times. However, I'm curious about how it handles state. I'd think it would require more than SysV runlevels. Is this in a released NetBSD, or is it just in CVS? On Sat, Jul 28, 2001 at 09:25:15AM -0500, Steve Price wrote: > On Sat, Jul 28, 2001 at 03:38:14PM +0400, Wartan Hachaturow wrote: > > > > I would like to point out again that we're not trying to change Debian, > > or the way it works. We're trying to get it to use a BSD kernel ;) > > In my mind it should mimic the Debian/Linux way everywhere possible. > > And if somewhere along the way this project finds something that > works even better than the Debian way, will you stick with the > lesser solution just because, ... well just because? While there > is no conclusive evidence (yet) that NetBSD's new rcinit code is > that much better than the current SysV scheme that Debian uses it > does have merits that are worth exploring. Making a better mouse- > trap is a good thing but if you let "policy" be your blinders then > it is less likely to happen. > > All IMHO of course. > > -steve > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: BSD libc or Glibc?
There are changes that would need to go in for utmp. Those affects sysvinit, and the who program in the shellutils. Probably some other packages as well. I had more problems with a handful of packages that were written for Debian, because they assume that all of the libiberty functions are in the libc. And there is the issue with ldd not working on shared libraries. This I found on FreeBSD. I looked at the CVS for NetBSD, and it looks like it works differently, so it's probably not affected. There are three options: 1. Get the needed functionality into the BSD libc. 2. Patch the Debian package to not need it, or workaround. 3. Port glibc. I've been looking at glibc, and at this point, I'm in favour of the first two options. Not because I think one libc or the other is better, but because it's less work. On Thu, Jul 26, 2001 at 11:01:27AM -0400, Perry E. Metzger wrote: > > matthew green <[EMAIL PROTECTED]> writes: > >So, we have to decide whatever we use native libc, or port glibc? > >I have faced some issues during my sysvinit port (it's about > >50% done, so hold on :), that required me changing NetBSD's libc > >header files (for example, utmp.h). > >So, let's decide, what are we going to use? > > > > > > what did you have to change in utmp.h? that seems ... the wrong > > thing to do. note that porting glibc includes all the machines > > that netbsd runs on (currently 44, across 12 CPU architectures). > > i don't think this will be an easy task. i'm sure that _in the > > end_ you'll probably want to do this, but as it stands there are > > probably better things to work on. libc is also highly tied to > > the kernel, due to the implementation of system calls. note that > > to avoid having libc's major number bumped, that many standard > > system calls are "renamed" by header files, and that the real > > (modern) syscall is actually something like __fstat13(). this > > will require significant work, sometimes in MD code. > > Indeed. I'd suggest that you'd be better off making a list of missing > functions and asking Matt and myself to get them integrated into > NetBSD's libc. It should be straightforward to do that. > > Perry > -- > Perry E. Metzger [EMAIL PROTECTED] > -- > NetBSD Development, Support & CDs. http://www.wasabisystems.com/ > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
Re: Soooooooo...
I couldn't get gcc 3.0 to build. As for aims: this isn't exactly going to get released with woody, or very likely with the next one. I'm going with anything that I can get to work for right now. On Mon, Jul 23, 2001 at 04:53:44PM +0100, Matthew Garrett wrote: > On Sat, Jul 21, 2001 at 12:51:17AM +0100, Matthew Garrett wrote: > > > Great. I'll prod this at some point over the weekend and try to get NetBSD > > ones built. Have you done anything about differences between the FreeBSD > > and Debian file layouts? > > I've built binutils packages, and have managed to get gcc to build but > haven't packaged it as yet. Currently no versions of gcc will build on a > netbsdelf system without patching, but patches are available. Should we > aim for gcc 3.0 or stick with 2.95? (the patches are pretty much > applicable to either, it's just a couple of mods to the configure scripts > and some changes to the arch specific include files for the most part) > > -- > Matthew Garrett | [EMAIL PROTECTED] > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] >
