Re: of bash and ...sbin/
On Wed, Mar 22, 2000 at 08:24:42PM +0100, Robert Bihlmeyer wrote: > Dylan Paul Thurston <[EMAIL PROTECTED]> writes: > > On Wed, Mar 22, 2000 at 11:52:37AM -0500, Jacob Kuntz wrote: > > > at the risk of reigniting a flame war, how is traceroute in a different > > > catagory that ping? > > traceroute is "deeper" than ping. It exposes things that the casual > user neither sees nor cares about. Ping only measures what everybody > experiences anyway: how responsive is a particular host? Without going in depth as to what traceroute and ping are (a fruitless flame war) suffice it to say that I disagree with your "deeper" comment. > One has to draw a boundary, and on GNU systems it runs between ping > and traceroute. Others do it differnently, AFAIR AIX has both in > sbin. These 'boundaries' are completely arbitrary, since as pointed out earlier, Herbert Xu isn't willing to change traceroute. Perhaps we should ask Dan Quinlan? > > Or mtr, for that matter? > > That should go into sbin. I filed a wishlist item. If it is really to go in sbin, then I shall also take the suid-bit off of it, since obviously only root will be using it anyway. mtr users, relax: none of this will happen, because, first and foremost, *I* use mtr as a user. :) -- Robert Woodcock - [EMAIL PROTECTED] "To the other one percent -- thanks for the passion and color!" -- Jeff Bezos
Intent to package: distmp3
Hi, distmp3 is a tool to allow encoding of mp3's across a network. It consists of a client perl script and a server perl script. http://wlug.westbo.se/medlprog/distmp3-0.1.5.tar.gz Currently it has no license but I've contacted the upstream author and he will be doing another release shortly that places it under the GPL. Because it requires an mp3 encoder to function, it will go in contrib. Once it's there, I can make abcde use it transparently :) -- Robert Woodcock - [EMAIL PROTECTED] "To the other one percent -- thanks for the passion and color!" -- Jeff Bezos
Re: lost packages
Michael Meskes wrote: >I just checked via dselect to see which packages on my slink/potato machine >are not found in the potato archive. I wonder what happened to them. >Here's my list (after removing the obvious ones like libgtk1.1.*): > >conf Oh my goodness! A conf user! I thought those all disappeared with the grea... err waitasec alright this isn't return to zork :> I had conf removed from potato because there was no evidence of anyone using it. No bugs had ever been filed against it (I *know* there's bugs in conf), and no dependancies were ever thrust upon it. That combined with the existance of something better (apt-config), as well as the namespace-pollution factor and general dislike of windows .ini-style files led me to conclude that this was not something anyone would be using, nor anything I would want users to be stuck using on behalf of some utility for all time immortal, something a few hundred times more probable if conf were to ever make it into a stable release. See http://www.debian.org/Bugs/db/36/36611.html If you want to take over the package I can send you everything. -- Robert Woodcock - [EMAIL PROTECTED] "Now don't you think that's better than some quadrupally redundant, electronic, Microsoft software control system?" -- Burt Rutan on the crashworthiness of the Proteus rocket module
Re: VX Chipsets and 2.2.5
Michael Beattie wrote: >I have been told by an aquaintance that linux 2.1.x or greater kernels are >unlikely to boot on a Motherboard that uses a VX Chipset. I have a >VXPro... Well at least your friends know where to get good crack. 2.2.5 runs fine on VX boards, and oh, BTW, the VXPro is absolutely not a VX. It's a clone with a similar feature set. Also, check http://www.debian.org/releases/slink/running-kernel-2.2 for important information about running 2.2 kernels on slink. -- Robert Woodcock - [EMAIL PROTECTED] "Now don't you think that's better than some quadrupally redundant, electronic, Microsoft software control system?" -- Burt Rutan on the crashworthiness of the Proteus rocket module
Re: Package to give away/orphan: GNU acct
On Thu, May 13, 1999 at 09:43:58PM -0400, Dirk Eddelbuettel wrote: > Which kernel-sources, running kernel, libc6, egcc, ... are you using ? I > think on my build machine it is > > [EMAIL PROTECTED]:~> dpkg -l kernel-image-2.2.7 kernel-source-2.2.5 libc6 > egcc|grep ^ii > ii kernel-image-2. edd.1 Linux kernel binary image. > ii kernel-source-2 2.2.5-2Linux kernel source. > ii libc6 2.0.7.19981211 GNU C Library: shared libraries > ii egcc2.91.66-0slink The GNU (egcs) C compiler. aha - you're running glibc 2.0 - sys/acct.h is in the glibc headers, *not* the kernel headers (and furthermore it doesn't reference them). I'm running all the current potato tubulation: frantica:~$ dpkg -l kernel-image-2.2.5 gcc libc6-dev libc6 hi kernel-image-2. 1.00 Linux kernel binary image. ii gcc 2.91.66-1 The GNU (egcs) C compiler. ii libc6-dev 2.1.1-5GNU C Library: Development libraries and hea ii libc6 2.1.1-5GNU C Library: Shared libraries and timezone > Robert> I can take over the package for you or at least make an NMU, > > Well, it might be sufficient if I can bounce a few things off you, and if we > both try a thing or two. > > Robert> but I won't have time to make something that autodetects > Robert> 2.0.x/2.2.x to work with both, at least not anytime soon. > > Well, I wrote something simple in Perl for the last package, but Shaleh says > it fails on his box. What does /usr/sbin/compare_kernel_version say for you? Seems like it could work ok: frantica:~$ compare_kernel_version 2.0 || echo true true frantica:~$ compare_kernel_version 2.2 || echo true true frantica:~$ compare_kernel_version 2.4 || echo true frantica:~$ > Robert> I think that shipping a broken-for-2.0.x acct package in potato > Robert> would be acceptable. > > That was all I was shooting for given my limited time. After all, the acct in > slink is fine-for-2.0-but-broken-for-2.2. I think the tough part will be getting things to build against two different sets of headers. -- Robert Woodcock - [EMAIL PROTECTED] "Now don't you think that's better than some quadrupally redundant, electronic, Microsoft software control system?" -- Burt Rutan on the crashworthiness of the Proteus rocket module
Re: Package to give away/orphan: GNU acct
[sorry for not getting to this message sooner] Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote: >GNU acct is still broken for 2.2 kernels. I thought a recompile would fix it, >but it doesn't. Not true: frantica:~/src/acct-6.3.5$ lastcomm | head root ?? 0.00 secs Wed Dec 31 16:00 9 root ?? 18358884.83 secs Wed Dec 31 16:00 joercw ?? 0.00 secs Sat Jan 29 04:26 741 ?? 1327769.36 secs Fri Jan 2 22:36 root ?? 815267.85 secs Sun Jan 18 20:54 ?u;7 root ?? 176947.85 secs Wed Dec 31 23:25 root ?? 18694425.18 secs Wed Dec 31 16:00 bin ?? 0.00 secs Wed Dec 31 16:00 daemon ?? 655360.00 secs Thu May 13 17:59 57 ?? 9267091.02 secs Wed Dec 31 16:00 Broken pipe frantica:~/src/acct-6.3.5$ ./lastcomm | head headrcw tty8 0.03 secs Thu May 13 18:02 lastcommrcw tty8 0.04 secs Thu May 13 18:02 headrcw tty8 0.00 secs Thu May 13 18:02 lastcommrcw tty8 0.04 secs Thu May 13 18:02 joe rcw tty2 0.04 secs Thu May 13 18:01 cronroot ?? 0.00 secs Thu May 13 18:00 sh root ?? 0.01 secs Thu May 13 18:00 rmmod root ?? 0.00 secs Thu May 13 18:00 headrcw tty8 0.01 secs Thu May 13 17:59 lastcommrcw tty8 0.03 secs Thu May 13 17:59 Broken pipe frantica:~/src/acct-6.3.5$ uname -a Linux frantica 2.2.5 #6 Tue Apr 13 20:43:55 PDT 1999 i686 unknown I can take over the package for you or at least make an NMU, but I won't have time to make something that autodetects 2.0.x/2.2.x to work with both, at least not anytime soon. I think that shipping a broken-for-2.0.x acct package in potato would be acceptable. -- Robert Woodcock - [EMAIL PROTECTED] "Now we'll have to kill you." -- Linus Torvalds
cdgrab on hold? read this (Re: Intent To Package: cd-discid)
On Fri, May 07, 1999 at 09:06:27PM -0700, Robert Woodcock wrote: > Hmmm, now that I've uploaded cd-discid I guess I better write an intent to > package for it :) > > cd-discid has long been bundled in cdgrab, but since cdgrab changes so much > more quickly, and is a simple shell script, the other architectures don't > get updated versions of it as quickly as desired. cd-discid is a package > that won't change as often. > > So, now cd-discid is in its own package, putting cdgrab in binary-all where > it belongs. It has also been rewritten to not use libcdaudio, at the expense > of 44 more lines of code, bloating this copy to an alarming 95 lines. One thing I forgot was dinstall isn't instant for new packages, and cd-discid is still in Incoming. For those of you wanting to try out cdgrab, or for those of you pondering a message like this: The following packages have been kept back cdgrab This is whatcha do: wget http://frantica.lly.org/~rcw/cd-discid/cd-discid_0.2-1_i386.deb wget http://frantica.lly.org/~rcw/cdgrab/cdgrab_0.7-1_all.deb dpkg -i cdgrab_0.7-1_all.deb cd-discid_0.2-1_i386.deb -- Robert Woodcock - [EMAIL PROTECTED] "Now we'll have to kill you." -- Linus Torvalds
Re: Corel Setup Design Proposal
Randolph Chung wrote: >The VESA PnD (plug and display) specs can be downloaded from the VESA web >site (http://www.vesa.org/pnd.pdf). A cursory flip through the specs seem to >indicate that it will indeed provide video timing (as well as other >interesting pieces of) information about your display hardware.=20 Yes. >Is there a different PnP monitor spec that people are talking about? This >(the VESA spec) is what my monitor uses. Yes. pnd.pdf covers the *hardware* interface between the computer and monitor that makes DDC possible. It makes a reference to the DDC specification for software implementations and command sets. Since Debian is making a distribution, not video cards and monitors, this information doesn't really apply to us. If you can find the DDC specification on Vesa's site without paying money, we'd all be very happy. :) -- Robert Woodcock - [EMAIL PROTECTED] "Now we'll have to kill you." -- Linus Torvalds
Re: What hack in ld.so?
Alexandre Oliva wrote: >The point is that you've just been asking for libtool not to use >-rpath at all, Yes, I think this is the correct solution. >but this would only work for people who create .deb or .rpm binary >packages, You fill this house with lies. It works for anyone putting libraries in standard places, "standard" being defined by the admin, who has write access to /etc/ld.so.cache. Users can work around this by, at worst, creating a wrapper script to set LD_LIBRARY_PATH. For example: frantica:~/apt/build/bin$ ./apt-get ./apt-get: error in loading shared libraries libapt-pkg.so.2.0: cannot open shared object file: No such file or directory frantica:~/apt/build/bin$ cat apt-get-wrapper #!/bin/sh LD_LIBRARY_PATH=/home/rcw/apt/build/bin exec /home/rcw/apt/build/bin/apt-get "$@" frantica:~/apt/build/bin$ ls -l apt-get-wrapper -rwxr-xr-x 1 rcw rcw87 Jan 31 02:11 apt-get-wrapper* frantica:~/apt/build/bin$ ./apt-get-wrapper apt 0.3.0 for i386 [...] This is what our ld.so has done for years, this is what our users expect, and this is what has determined Linux's library placement for every other transition it has had to make. It's safe to say that will not change. Hardcoded pathnames to libraries are evil, you can't blame people for trying to get rid of them, especially when they start breaking left and right the minute things move around. -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: XFree86 3.3.2.3a-8pre9v6 at master.debian.org/~branden/xfree86
Branden Robinson wrote: >*) No damn circular symlinks. Check the /etc/X11/xinit and >/etc/X11/xserver directories for them. Some of my postinsts, and dpkg >itself, should scream at upgrade time if this happens, but it never hurts >to be sure. I just upgraded from 3.3.2.3a-8 to 3.3.2.3a-8pre9v6 with apt-get, and they're still there (note - they might have been there in -8 before as well - I didn't check) lrwxrwxrwx 1 root root 24 Nov 29 15:07 xinit/xserverrc -> /etc/X11/xinit/xserverrc lrwxrwxrwx 1 root root 31 Nov 29 15:07 xserver/SecurityPolicy -> /etc/X11/xserver/SecurityPolicy -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: Debian logo & its license
Avery Pennarun wrote: >What if someone gets hold of the Linux kernel and uses it to guide nuclear >missiles? (Well, at least they have to share their changes with us :)) Only if they distribute the control systems :> >Seriously, slander is slander, and it's rude, and people will know it when >they see it. Furthermore, if people want to parody Debian (including the >logo) they'll do so regardless of the logo license, and Debian doesn't have >enough money to sue them about it. Besides, did anyone bother to register a >trademark? Aren't parodies specifically allowed under international copyright law? >A license that says "this logo should only be used when referring >specifically to Debian" is plenty and probably still unenforceable. Yeah, I don't think it should be more than one sentence. Perhaps: "You are licensed to use and distribute modified versions of this logo to refer to or advertise debian." Note that this fails DFSG point #6. I believe this was the original intent. -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: boot disk question/suggestion
Ossama Othman wrote: >The machines both have two Adaptec 7890 and one Adaptec 7860 SCSI chipsets >installed. Each machine also has a gigabyte of memory and four Intel >Pentium II Xeons installed. In order to get RedHat to work we had to fool >the kernel into thinking that it had less than a gig of memory since it >can't seem to handle more then about 1020MB (confirmation anyone?) of >memory. 2.0.x maxes out at 2^30-2^26 = 1006632960 bytes, or 960MB, of RAM. Thus, you'll wanna use "mem=960M". You can also adjust some headers (I forget which) to expand the kernel memory / virtual memory split (it is adjustable, and it defaults to 1GB/3GB). >Second we also had to tell the kernel to prevent the aic7xxx >driver from probing since it causes the system to crash if it does probe. >Here is the boot line: > > boot: linux mem=1000M aic7xxx=no_probe > >The RedHat boot disk does no probing at all since SCSI drivers appear to >be loaded during the installation process, not during the boot process. >OTOH, Debian's kernel loads several SCSI drivers (right?) which appears to >be causing my system to crash. The system crashes right after the IDE >detection boot step. > >Is it possible to shut off all SCSI support at the "boot:" prompt? If >not, can anyone suggest a solution? Since RedHat's boot technique appears >to work well in situations like mine (new hardware, probing causes >crashes), can we or should we do something similar? > >Are there any new boot disks available besides the ones that were released >last on 12/29? I can't make my own boot disks since I currently don't >have access to Debian system and I don't want to use master or va to >create boot disk images. You can switch out the kernel on the rescue disk on any linux system fairly easily: # dd if=resc1440.bin of=/dev/fd0 # mount -t msdos /dev/fd0 /mnt # cd /mnt # rm linux # cp /place/i/have/my/working/kernel linux # ./rdev.sh # cd / # umount /mnt Yes, the rdev.sh script does require that you mount the disk on /mnt. Make sure your rescue disk contains ext2, msdos, ramdisk, initrd, and ELF support. Happy booting. -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: pseudo package for upgrades from hamm
Martin A. Soto wrote: > >Many, *many* people has proposed this idea before. So many, that you >would be tempted to consider it a simple, natural, and straightforward >idea. Nonetheless, it seems that this far, it has been impossible to >make it part of dpkg, or even to start working on the necessary >modifications for that purpose. I don't think anyone's filed that particular idea as a wishlist bug against dpkg yet. I plan to. If you want to start, there's nothing stopping you, except your own inability to figure out other people's code (this is actually a serious problem for most of us mere mortals :) If you're serious, you'll probably want to join the debian-dpkg@lists.debian.org mailing list (hmmm, very hypocritical of me - I'll have to remember to subscribe myself :) >The list of bugs against dpkg grows almost daily Hmmm, we're up to 388. Critical: 1 Grave: 6 Important: 8 Normal: 256 Wishlist: 66 Fixed: 49 Normal done: 1 Fixed done: 1 It seems a few people are actually going through the bug list and closing bugs that have been fixed or shouldn't be there. I've done that to a few of the more superfluous dpkg bugs recently myself. I encourage you to do the same. :) >while the very few people who are blessed to touch the source code >continue to be too buzzy to work on it. >From what I've heard, Klee Dienes has dropped off the face of the earth, and Ian Jackson has had to put dpkg aside this year to concentrate on being leader. I think I remember him saying sometime that he plans to start hacking on dpkg again after his replacement takes office. So, the gist of that is that dpkg has been left for dead (well, NMU hell anyway) for a full year and there hasn't been *that* many complaints. Just no new features. >Opening the development model for dpkg would be a great way to overcome >this sad situation, but it seems that us, poor mortal Debian maintainers, >are not considered good enough for taking care of the central and most >important tool in our project. What tangible changes are you suggesting? Anyone can currently submit dpkg patches to the BTS, and if they want to handle the flames, any developer can do a NMU of dpkg. I think the problem is the lack of people that really *really* understand the dpkg source, and there's no way for Ian to just "fix" that. -- Robert Woodcock - [EMAIL PROTECTED] "It's like a love-hate relationship, but without the love." -- jwz, on linux
Re: Revision 4 of DFSG
Anthony Towns wrote: >* Is the Limitation of Liability really a restriction on use or > distribution? This is just a layout thing, but it'd be nice to > get it right. Neither! The limitation of liability in almost all licenses these days do not grant or deny any rights. The right to sue (i.e., the right to hold the other end liable) is usually dependant on local laws and a statement to the contrary in a license agreement typically would have no effect. Also note that in all fields of endeavour you don't have to be able to sue the author to use the software (although there's a large amount of letter- recycling between the phrases ;) -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: pseudo package for upgrades from hamm
Adam Heath wrote: >I see a problem with all this talk about pseudo packages for upgrades from >hamm. > >These 'pkgs' will have to remain in the system forever. If someone skips >slink, and goes to potato when that is released, the same problem will occur. > >If we ever fix dpkg/dselect/apt to handle a pkg rename, and we can guarantee >that an old dpkg/dselect/apt will install the new dpkg/dselect/apt, then we >will be able to remove the pseudo names. But currently, I don't see how this >is possible. [the following is all just talk - I don't feel comfortable hacking dpkg source yet] We need to add a new field - call it anything you want - I called it "Was-Part-Of:" in an earlier post, but I'm sure there's a better name than that - "Previously:" maybe. Anyway, say slink contains a package 'foobar', version 1.2-3. The maintainer decides to split it into 'foo' and 'bar' for potato. In the control files for the foo and bar packages, the maintainer slips in that aforementioned field: Package: foo Version: 1.2-4 Previously: foobar (<< 1.2-3) ... and does the same thing for the bar package. dselect and apt check that field, check the current version of foobar, and based on that, automagically select the new packages. Chances are, someone has ripped off my idea ;> and submitted it as a wishlist bug against dpkg already, so I'll look through the list later and file a wishlist bug if there isn't one already there. That is, if noone has any better ideas on how to handle this. >ps: When is Jason Gunthorpe going to rewrite dpkg? :) You really want dpkg written in C++? :> -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
cracklib-runtime NMU
Just wanted to let you know that tonight I plan to recreate the cracklib-runtime build scripts (with debhelper) since they seem to be missing a few things and also patch crack_packer so it produces no output on a successful run, then repackage the source so it extracts cleanly with dpkg-source -x. This is to fix the outstanding release-critical bug report against your package. If you were planning to fix this yourself please let me know. (And, if anyone has already done this, please let me know - I don't want to redo someone else's work.) -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: LSB?
Chris Lawrence wrote: >Nice to see the Open Group and X/Open are going to send us chasing our >tails trying to get this stuff together (so we can call our Linux >implementations "Linux" :-p) instead of pursuing Unix branding. Indeed. I thought LSB was going to be an Application Environment specification - so that apps developed on one distribution would run on all the others. If that's still the case, I wanna know WTF they are thinking/smoking, specifying kernel locations, netstat, mount/umount, fdisk, setserial, disktab, adjtime, csh.login (!), fdprm, fstab, gettydefs (!!!), group, passwd, inittab, lilo, mtab, profile, securetty, exports, hosts, hosts.allow, hosts.deny, networks, printcap, protocols, services, rpc, /home, /lib/modules, /opt existing (conflicts with FHS), /root, clock, getty, init, update, mkswap, swapon, swapoff, telinit, shutdown, fsck, mkfs, ifconfig, route, /tmp cleaning, /usr/X386 (?!?), includes, g++, /usr/local/*, process accounting, utmp (ALL programs should use the wrapper), /var/spool/lpd, rwho, /var/tmp persistance, NIS, ALL OF THE DAMN MAJOR/MINOR NUMBERS FOR THE DEVICES, /usr/src, /usr/src/linux, compilers... *NO* well-behaved application should use/twiddle/tinker with ANY of the above. (Well, I could be wrong in a couple spots, but... wow.) P.S.: From where is /bin/domainname standard? I can see it's purpose in an app env standard, so I'm curious... -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: Secure Locate (findutils?)
[Cc'd to debian-devel and the findutils maintainer] In debian-devel, [EMAIL PROTECTED] wrote: >Anyone give any thought to packaging Secure Locate 1.2? Yeah, I posted an intent to package about the same time you posted this. BTW, at least version 1.3 is out now. >Is there any way to >package this without it conflicting with the standard locate provided in >findutils? It has to seamlessly replace both updatedb and locate. Then you can use dpkg's diversion features to properly shove them out of the way. Unfortunately it seamlessly replaces neither yet, and since dpkg isn't yet supposed to be able to properly divert configuration files, I can't touch /etc/updatedb.conf or /etc/cron.daily/find (even to make sure they don't run - who would want two locate databases?). So the only thing left for me to muck with is the updatedb script itself. I have contacted the upstream author and he's working to make slocate compatible with locate, however the updatedb end needs quite a bit of work. (slocate currently uses the same binary for indexing and searching!) updatedb is a good chunk of functionality to replace, considering it's a shell script. >This seems like a much better way to enhance privacy without running >updatedb as nobody and thus making users unable to 'locate' files in their >own private directories. I concur :) >I'd do this myself, but I haven't been accepted as a maintainer yet, >findutils is part of the required base install which I'd rather not be >resposible for breaking, and slocate might require some special permissions >which could decrease security in a ways I haven't fully explored yet. It wants to be setgid slocate so it can read the slocate db. If a user can exploit slocate they get to read the database. The database is actually owned by root, and I'll need to make sure the directory it's in is as well. I made a suggestion to the upstream author about storing the databases in separate files, owned by whoever should be able to read them (yeah, one for each uid), so nothing would have to be set[ug]id. He never commented on it. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Intent to package: slocate
As featured on Bugtraq and recently Freshmeat, slocate is a replacement for locate/updatedb. It keeps track of UID's for files so that people can't see other people's hidden stuff, while still seeing their own. I'll have it create a diversion for /usr/bin/locate and /etc/cron.daily/find, and create a system user for `slocate'. I'm not sure if it's a good idea to divert a config file, if not I'll have to rethink things a little. If by some miracle I can get this done tonight (yeah right), it'll be in slink. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Intent to package: uvscan
This follows up my post on Thursday regarding the 'Suggestion - Antivir for Linux' thread. There was a minor amount of interest for a mcafee installer package so in it goes. new debian package, version 2.0. size 5188 bytes: control archive= 2264 bytes. 672 bytes,19 lines control 295 bytes, 5 lines md5sums 3547 bytes, 141 lines * postinst #!/bin/sh 271 bytes, 6 lines * prerm#!/bin/sh Package: uvscan Version: 3-1 Section: contrib/admin Priority: optional Architecture: i386 Depends: libc5 Recommends: unzip Conflicts: uvscan3-full Provides: uvscan3-full Installed-Size: 23 Maintainer: Robert Woodcock <[EMAIL PROTECTED]> Description: McAfee Virusscan for Linux (installer package) Installs the Network Associates version of McAfee Virusscan (30-day trial or licensed) on your Debian system. . Network associates does not allow redistribution of their software, so Debian is unable to distribute full packages. You will need to download the latest .tar from ftp://ftp.nai.com/pub/antivirus/unix/linux/ and place it in /tmp (or $TMPDIR) before installation. It installs Network Associates Inc's files to /usr/lib/neta and places a simple wrapper in /usr/bin: #!/bin/sh ANTIVIRUS="/usr/lib/neta" exec /usr/lib/neta/uvscan $* It also includes a build-uvscan script which will create full .debs of uvscan and its dats: -rw-r--r-- 1 rcw rcw566646 Aug 9 20:49 uvscan3-dats_3.00.3105_i386.deb -rw-r--r-- 1 rcw rcw140082 Aug 9 20:49 uvscan3_3.1.8-1_i386.deb uvscan3 also contains the build-uvscan script, therefore it is the world's first self-replicating .deb :) (Yes, I'm well aware that 3105 is out of date, however I don't have any virii to scan on my home development machine, so I don't really care :) There currently isn't a script to update the dats. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: suggestion - AntiVir for Linux
On Fri, Oct 09, 1998 at 09:33:49AM -0500, Jeff Noxon wrote: > On Fri, Oct 09, 1998 at 04:48:26AM -0000, Robert Woodcock wrote: > > Just out of curiosity would anyone be interested in a mcafee virusscan > > installer package in slink contrib? I have everything created, the only > > thing I'd have to work on would be upstream upgrades (it currently doesn't > > handle this at all) and then I'd write an intent to package and upload it. > > I looked at this yesterday. It appears to be an a.out executable. I > don't have a.out/libc4 anymore, and I suspect I'm not alone. Are you > aware of a newer version? It would be nice to have a virus scanner on > my Linux machine, since I receive a lot of Windoze e-mail attachments > and have several Samba shares. mercury:~$ ldd /usr/lib/neta/uvscan libc.so.5 => /lib/libc.so.5 (0x4000c000) That's what's in ftp://ftp.nai.com/pub/antivirus/unix/linux/nlxb318e.tar. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: suggestion - AntiVir for Linux
[EMAIL PROTECTED] wrote: >On Thu, 8 Oct 1998, Chris wrote: >> Since when did linux get virus's You'd only get them on a really >> bad system - which debian is not (or if you did EVERYTHING as root). > >On a linux system exporting disk space to Windows machines, it is indeed >practical to have an anti-virus able to report if your shares contains >virii. Just out of curiosity would anyone be interested in a mcafee virusscan installer package in slink contrib? I have everything created, the only thing I'd have to work on would be upstream upgrades (it currently doesn't handle this at all) and then I'd write an intent to package and upload it. I could probably squeeze it in before the freeze. Thing is, Network Associates Inc. is axing the Mcafee engine in favor of Dr Solomon soon. However, it *is* the world's first self-replicating debian package :) (build-uvscan makes full debs of the engine and datfiles, the engine deb includes build-uvscan :) -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: exim really does need to be the standard MTA in slink
On Mon, Oct 05, 1998 at 08:31:24PM -0700, Robert Woodcock wrote: > [...] so if there seems to be a concensus this time around, I'll file bugs > against ftp.debian.org. Filed. It's bug #27642. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: exim really does need to be the standard MTA in slink
On Mon, Oct 05, 1998 at 11:39:36PM -0700, [EMAIL PROTECTED] wrote: > in the message IDed as <[EMAIL PROTECTED]>, Robert Woodcock <[EMAIL > PROTECTED]> wrote this on Mon, 05 Oct 1998 20:31:24 PDT: > > Yeah, I know this makes at least the second reincarnation of this thread in > > the last 6 months, but I really think exim should be the standard MTA in > > slink. > > (I am not a voter here.) > > Fine... but PLEASE don't make decisions that would make any of the other > mailers unusable to any degree (that's for everyone else), -especially- > sendmail (that's for me). Nah, it wouldn't affect existing setups, only new users who never specifically chose an MTA in dselect, i.e. went with the standard system. Just out of curiosity, what's the security track record on smail vs exim for the last two years? The standard MTA should have a chance of being secure from remote attacks for at least a year after release. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
exim really does need to be the standard MTA in slink
Yeah, I know this makes at least the second reincarnation of this thread in the last 6 months, but I really think exim should be the standard MTA in slink. Last time this came up, there were two factions: 1. YES, PLEASE 2. Let's wait for vmailer There wasn't particularly anyone against it from a technical perspective. I'd like to keep this discussion quick and to the point, so: * What's the status of vmailer now? * Is it going to be ready for the release after slink? * How much trouble is it to switch standard MTA's around in releases? (i.e. will this cause such an upgrade nightmare for users that we're better off only changing it once?) There is currently no technical committee (this is why we need one of those!) so if there seems to be a concensus this time around, I'll file bugs against ftp.debian.org. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: what's after slink
On Mon, 5 Oct 1998, Vincent RENARDIAS wrote: >On Mon, 5 Oct 1998, Ben Armstrong wrote: >> On Sat, 3 Oct 1998, Martin Schulze wrote: >> > 2.2 potatoe >> > 2.3 andy >> > 2.4 davis >> > 3.0 sergeant >> > 3.1 hannah >> >> Bo was taken, but how about "Peep"? > >Not a good idea considering what it (phonetically) means in French... >(Or we might as well call it Debian Lewinsky, so everyone could get the >joke... ;) An interesting idea came to me yesterday... Use the nearly endless namespace of non-trademarked addictive painkiller medication. "Debian Morphine" -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel
Re: p2c 1.20-2.4 is now lintian-compliant and in Incoming.
On Fri, Jun 19, 1998 at 11:39:20AM -0300, Igor Grobman wrote: > Some time around Thu, 18 Jun 1998 19:36:17 PDT, Robert Woodcock wrote: > > I did *not* fix the old source format [...] > > If it's the old source format, then is it still in hamm? I think every other > old-source format package is no longer in hamm. I don't see why p2c would be > the exception given that no one wants to maintain it anyway. Unless, of > course > you mean something different by "old source format" than what I am thinking > of > (does it have a .dsc file?) Hmmm, I haven't been a developer long enough to know just what you're talking about, but yes it does have a .dsc file. It seems the debian/rules file predates debstd though. Can someone who *does* know exactly what 'old source format' means look at and possibly close bug #9514? -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
p2c 1.20-2.4 is now lintian-compliant and in Incoming.
It's targetted for 'frozen unstable' - yes, this is for hamm. I did *not* fix the old source format, or edit it to use debhelper, or anything else drastic - it *only* (a). fixes all the lintian errors and (b). gives us a libp2c1 package. I've tested it with the example code that comes with p2c, and the traditional hello world code. Please test it further and let me know of any problems. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Intent to do SOMETHING with: p2c
My personal opinion on this is that p2c in it's current state should be removed from hamm. It's completely broken, as it depends on a non-existant package that was removed from hamm during the freeze because, of all things, a lintian error: * #19382: libp2c1: ldconfig-symlink-missing-for-shlib LI#117 Package: libp2c1; Severity: important; Reported by: [EMAIL PROTECTED]; 98 days old. However, something usable should go in slink. (p2c is still used by the occasional person, I had someone ask me on #debian where libp2c1 was...). Whatever happens, I'm not a good person to maintain p2c. I'm not so sure *anyone* is - are there *any* developers that use it? I plan to do a quick NMU of 1.20-2.4 for unstable that gets us back to using libp2c.a instead of .so. Please comment. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Boot Dependancies - a weird wacky wonderful new idea
Hello, I have an idea (ok, maybe not an original idea, but bear with me :) It involves the sysvinit (/etc/init.d/rcS and a lotta other stuff) and dpkg packages. (update-rc.d) Parallelized booting. What this means is we run multiple bootup scripts simultaneously. It's a *lot* faster on mid-to-higher-end machines, even with just one CPU - it'd be wickedly fast with SMP. "Hey wait a second that won't work!!! What if the netstd_nfs script runs before the netbase script is done processing?" Well, you're right, but I have another (slightly more original) idea that will make it work. Boot-time dependancies. * Instead of relying on those icky priority numbers we just had a flame war or two about, the packages tell us how they *really* feel and state precisely in a file (I'm thinking /etc/init.d/deps/[KS]packagename) what needs to be successfully running (or not running) before or after they can start. Do we need to make this information separate for each runlevel? (i.e. make it /etc/rc?.d/deps/[KS]packagename instead?) * /etc/init.d/rc is modified to call a program that determines the order the scripts should be run in, on the fly. I figure this won't be much of a speed hit. Slrn can thread thousands of messages per second across a localhost news connection on my machine, sorting 30 scripts shouldn't take long either. Actually, we don't even need to thread, we can probably get away with just checking on script exit (any script exit) whether there's something else available to run or not - if there's nothing else available but there's still stuff that wants to be run, we can just run it anyway. * Because a fatal error on bootup is simply not an acceptable option, dependancies are considered 'soft' - if a dependancy can not be met for whatever reason, it is simply ignored. (This is what our existing setup with priority numbers does anyway.) We'd want to keep a debugging flag in the works to reveal such a situation though. * update-rc.d is modified to ignore priority numbers and keep things in the new format. (hmmm, perhaps we can be trickier than this.) Problems looming: * Installing new packages using the new dependancy format on older machines without thread-scripts needs to be handled - perhaps we can keep the NN switch to update-rc.d calls in new packages (at least for a while) * Going back and forth from the old setup to the new one won't be a walk in the park. I'd need to make a conversion utility. * My coding skills ;) I still have yet to create proof-of-concept code for this but the general idea has created such a buzz in #debian that we might just see something :) As for the file formats of /etc/init.d/deps/[KS]packagename, I was thinking something along the lines of: After: Before: I feel this information absolutely positively must be admin-editable, which dictates some type of text file format. Perhaps we could give it the idea of psuedo-packagenames such as 'everything' so we can have 'After: everything' for Srmnologin and Sxdm. i.e. /etc/init.d/deps/Sbind would have: -CUT- After: sysklogd kerneld netstd_init -CUT- If we are ever going to do this it would require at least the agreement of Miquel van Smoorenburg, Klee Dienes, and Ian Jackson (current sysvinit and dpkg maintainers) and a good concensus among the Debian developers, preceeded by a LOT of discussion, so I figured I'd throw it out onto debian-devel and await the replies: "so... what *is* that you're smoking?" :) Please let me know what you think of this. -- Robert Woodcock - [EMAIL PROTECTED] "Unix and C are the ultimate computer viruses" -- Richard Gabriel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Intent to package: uedit
On Wed, 29 Apr 1998, Igor Grobman wrote:
> O my god!! This is true. I downloaded it, and the README is pretty much
> what James has written. I tried starting it, and it managed to kill
> exmh, but not all of X exiting with "Setup Eror: Unable to Initialize
> Program". What a pity, it failed to kill X :).
> Um... I suddenly have a strange desire to destroy someone or something.
Well, after making a user to test this out with:
mercury:/home/rcw/Uedit_0.9c$ strace ./Uedit
execve("./Uedit", ["./Uedit"], [/* 24 vars */]) = 0
brk(0) = 0x19000
ioctl(0, KDSETMODE, 0) = 0
ioctl(0, VT_WAITACTIVE, 0) = -1 ENXIO (Device not configured)
ioctl(0, VT_SETMODE, 0x18ef8) = 0
ioctl(0, VT_RELDISP, 0) = -1 EINVAL (Invalid argument)
sigaction(SIGUSR1, {SIG_IGN}, {SIG_DFL}) = 0
open("/dev/mem", O_RDWR)= -1 EACCES (Permission denied)
fstat(1, {st_mode=S_ISGID|010, st_size=0, ...}) = 0
brk(0x1c000)= 0x1c000
brk(0x1d000)= 0x1d000
ioctl(1, TCGETS, {B38400 opost isig icanon echo ...}) = 0
write(1, "Setup Error: Unable To Initializ"..., 42Setup Error: Unable To
Initialize Program
) = 42
_exit(0)= ?
Yeah, that's right, an editor that opens /dev/mem.
I'm also wondering why, in 1998, this guy is releasing a.out binaries,
without source. It's just like, you know, so... *retro!*
:)
Sick. Disgusting. Wrong.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: A little ircii /dcc tweak I'd like to see the default...
On Sun, 19 Apr 1998 16:23:58 +, Rev. Joseph Carter wrote: >On Sat, Apr 18, 1998 at 07:29:19PM -0700, Robert Woodcock wrote: >> I'd like to see this patch become the default: [...] >> Yes, what that does is check your /dcc commands to see if they have >> /etc or /passwd in them, and if they do, print a message "Send request >> rejected". > > Ick, no. If an admin is not running shadow passwds, that's their fault. > Don't cripple the user needing help with a file in /etc. Hmmm, I guess I didn't make that very clear. I was not advocating putting that code *in* the ircii sources, I was advocating taking it *out*. (As for copying it to /tmp first, yeah, that *will* work, but why should we put users through the pain for no reason at all? In fact, I was able to defeat it by symlinking ~/argh to /etc and /dcc'ing ~/argh/whatever.) -- Robert Woodcock - [EMAIL PROTECTED] All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
A little ircii /dcc tweak I'd like to see the default...
I'd like to see this patch become the default:
--- ircii-4.4/source/dcc.c~ Thu Dec 25 17:36:09 1997
+++ ircii-4.4/source/dcc.c Sat Apr 18 19:22:43 1998
@@ -940,16 +940,6 @@
return;
}
#endif /* S_IFDER */
- if (scanstr(FileBuf, "/etc/"))
- {
- yell("Send request rejected");
- return;
- }
- if ((int) strlen(FileBuf) >= 7 && 0 == strcmp(FileBuf + strlen(FileBuf)
- 7, "/passwd"))
- {
- yell("Send request rejected");
- return;
- }
filesize = stat_buf.st_size;
Client = dcc_searchlist(FileBuf, user, DCC_FILEOFFER, 1, filename);
if ((Client->file = open(Client->description, O_RDONLY | O_BINARY)) ==
-1)
Yes, what that does is check your /dcc commands to see if they have /etc
or /passwd in them, and if they do, print a message "Send request
rejected".
Pretty much the only reason it's there is so clueless users can't be
tricked into sending people /etc/passwd files.
This makes sense on a large system with lotsa newbies on it.
It does *not* make sense when you're just trying to exchange XF86Config's
or what-have-you over IRC to try to help get something to work for
someone.
My thoughts on this are that large systems without shadow passwords with
shell accounts with ircii installed are:
1. very few and far between.
2. probably not running debian.
3. have hundreds of other security holes because of #2, making this one
irrelevant.
4. have admins who usually wouldn't get debianized source anyway, or if
they did, they'd be clueful enough to "fix" it.
I'd love to hear people's opinions on this.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Bug#20445 disagree
On Thursday, April 9, 1998, Brian White <[EMAIL PROTECTED]> > I think that if somebody can get the 2.2 kernel source off of CD, build > the kernel (hopefully as a debian package) and install it, they have the > knowledge and the ability to download packages from the network using > one of the many possibilities of dpkg, dselect, dftp, or another. > > What we lose is including packages that break either during installation or > when run on a stock Hamm system. Since we are shipping a "hamm" CD, I > believe that that CD should be as problem free as possible. If people > start mixing things from different CDs, they have to realize things may > not work "out of the box". I must have missed the part of this conversation that had the facts in it... Exactly what 2.1.x-kernel-ready packages currently in hamm break parts of a 2.0.x system? For example, if modutils 2.1.71 works perfectly fine with 2.0.x kernels, and there are no outstanding bug reports against it related to that (a quick glance says there aren't), then there's no reason to go back to the 2.0.0 version. 2.0.x is our release priority - however I think having hamm ready for 2.2 kernels *without causing problems for 2.0.x users* is a good idea. Debian does have a bit of a reputation for packaging all the latest and greatest stuff. The original bug report mentioned these packages: ax25-utils smbfsx ncpfsx vold pciutils romfs ipportfw bridgex * Juan Cespedes mentioned that romfs works with 2.0.x with the included patches. In any case it does not hinder 2.0.x functionality. *crosses off list* * ax25-utils doesn't hinder 2.0.x functionality, and patches are available. *crosses off list* * pciutils doesn't hinder 2.0.x functionality. *crosses off list* * vold doesn't hinder 2.0.x functionality. *crosses off list* * ipportfw doesn't hinder 2.0.x functionality and has a supplied 2.0.x patch. *crosses off list* * bridgex doesn't hinder 2.0.x functionality and has a supplied 2.0.x patch. *crosses off list* That leaves us with smbfs/smbfsx and ncpfs/ncpfsx. Can someone verify that these packages coexist or that smbfsx/ncpfsx works with 2.0.x? I personally think non-interactively printing a message during installation like "Warning - this package requires a 2.1. or later kernel to function." would be more than adequate. -- Robert Woodcock - [EMAIL PROTECTED] All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
CERT bind alert.
Henry Hollenberg <[EMAIL PROTECTED]> wrote: > Has anyone assesed the impact of the bind exploit announced by CERT > today. > I'm using bind_4.9.6-1.deb, so would be curious as to where I stood, > what the fixes were. > Thanks >Henry Hollenberg [EMAIL PROTECTED] Ya know what sucks? I worked my butt off to get it patched and packaged up, made the .deb's, got them uploaded a few places: ftp://ftp.linpeople.org/pub/Software/Bind/bind_8.1.1-7.1_i386.deb http://www.oz.net/~rcw/bind_8.1.1-7.1_i386.deb And then I was in the middle of composing a message to this list with a big scary subject like "SECURITY FIX:" which forced me to quote the CERT advisory (causing me to *read* it :)... >Date: Wed, 8 Apr 1998 17:45:08 -0400 >From: CERT Advisory >To: cert-advisory@coal.cert.org >Subject: CERT Advisory CA-98.05 - bind_problems >Reply-To: [EMAIL PROTECTED] >Organization: CERT(sm) Coordination Center - +1 412-268-7090 > >-BEGIN PGP SIGNED MESSAGE- > >= >CERT* Advisory CA-98.05 >Original issue date: April 08, 1998 > >Topic: Multiple Vulnerabilities in BIND >1. Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases >2. Denial-of-Service Vulnerabilities in BIND 4.9 and BIND 8 Releases >3. Denial-of-Service Vulnerability in BIND 8 Releases [...] >II. Impact > > Topic 1: A remote intruder can gain root-level access to your name server. > > Topics 2 and 3: A remote intruder is able to disrupt normal operation of > your name server. [...] >* >Topic 1: Inverse Query Buffer Overrun in BIND 4.9 and BIND 8 Releases >* > >1.A. Description > > BIND 4.9 releases prior to BIND 4.9.7 and BIND 8 releases prior to 8.1.2 > do not properly bounds check a memory copy when responding to an inverse > query request. An improperly or maliciously formatted inverse query on a > TCP stream can crash the server or allow an attacker to gain root > privileges. > >1.B. Determining if your system is vulnerable > > The inverse query feature is disabled by default, so only the systems > that have been explicitly configured to allow it are vulnerable. > > BIND 8 >Look at the "options" block in the configuration file (typically >/etc/named.conf). If there is a "fake-iquery yes;" line, then the >server is vulnerable. So, you can't get root on the existing package unless you enabled the fake-iquery option. Well that right there ticked me off enough to make me cancel the message, give up and go to sleep and let Johnie Ingram package up 8.1.2. (which was designated beta last I heard...) -- Robert Woodcock - [EMAIL PROTECTED] All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why isn't /bin/sh managed with alternatives?
On Sun, April 5, Shaleh <[EMAIL PROTECTED]> wrote:
> My assumption is that /bin/sh is VERY important to the system. All
> server scripts use it. A dangling symlink could be hazardous. Also,
> some systems initially mount only certain directories. And /etc is
> sometimes on a different partition entirely. /bin should stand on its
> own.
*NO* dynamically linked binary (this includes /sbin/init and /bin/sh) will
run without /etc/ld.so.cache:
mercury:~$ strace init
execve("/sbin/init", ["init"], [/* 27 vars */]) = 0
brk(0) = 0x804dde8
open("/etc/ld.so.preload", O_RDONLY)= -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=9333, ...}) = 0
mmap(0, 9333, PROT_READ, MAP_PRIVATE, 3, 0) = 0x4000c000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
For the curious, it retrieved that "/lib/libc.so.6" string from
ld.so.cache.
By the way, is ash any faster at sh script processing than bash?
If we made ash the default /bin/sh, would it speed the bootup process any?
Another idea I got on IRC was providing a --background flag to
start-stop-daemon so that daemons could be started in parallel - this
might have quite an effect on SMP systems, and DNS misconfigs would be
more treatable if sendmail started in the background instead of waiting a
few minutes timing out on stuff before anything else could run.
Or we could just use & to do it.
--
Robert Woodcock - [EMAIL PROTECTED]
All I want is a warm bed and a kind word and unlimited power.
-- Ashleigh Brilliant
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: 2 versions of netcat
On Sat, 10 Jan 1998, Joey Hess wrote: > I just noticed that 2 versions of netcat are in incoming. Last night, I > didn't realize this, and assumming that netcat was libc and noboday was > working on it, I decided to fix it, and uploaded version 1.10-4. (I'm not > the maintainer either, but I assummed the package was orphaned, so didn't do > a non-maintainer release.). Oops, you got there first, way back in december! Since [EMAIL PROTECTED] hasn't gotten back to me yet, and the packages I've uploaded have been rejected because I haven't been registered yet, you might as well ignore 1.10-3.1. Michael Shields, the current maintainer, doesn't really have the time to keep it up to date, so if you wanna take it (or if I could get registered, *nudge nudge wink wink* :>) that'd be great. > I see some overlap in the changelogs. Your version has: [...] Heh, maybe I should be more verbose in my changelogs. :) I'm slowly getting the hang of this - I didn't notice that bugs resolved should be mentioned in the changelog. There's actually quite a bit of overlap. [...] > I've now taken it upon myself to resolve this by releasing 1.10-5, which > merges the man pages (mine was longer, but yours was better in places; the > diff of the 2 is amusing :-), and compiles with -DTELNET. Heh, that works. I wrote the man page almost entirely by cutting and pasting stuff from the upstream README. :) Can you send this to me via e-mail? I don't have an account on master yet. Also I've been hearing that there's a namespace conflict between nc (netcat) and nc (nedit-client). Any ideas on this one? I think it'd be easier to rename the latter because it's not a backend tool and thus not likely to be used in scripts. (And of course because it wouldn't affect me. :) -- Robert Woodcock - [EMAIL PROTECTED] All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
netcat update & intentions
After getting in touch with Michael Shields <[EMAIL PROTECTED]>, the current maintainer of netcat, I've decided to make a non-maintainer release of netcat with the version 1.10-3.1. It should let us close all the distribution-specific bug reports for that package: * #5304: missing man page * #6647: netcat has no manpage * #9489: Package is still in old source format. * #9785: netcat: Documentation * #11530: /usr/doc/netcat * #11716: libc6 * #13194: netcat: /usr/doc/netcat is file, not directory It does not fix bug #10486, "nc doesn't understand ports in /etc/services that have a '-' in them". This package was done from scratch with source from ftp.avian.org, instead of updating Michael's package. To make a non-maintainer release I have ripped the description and a few other fields from the control files of the previous package. I've taken the liberty of cutting and pasting a manpage together and compiling with -DTELNET. I also put the examples and scripts in /usr/doc/netcat/ in their own directories. /usr/doc/netcat is now /usr/doc/netcat/README. There's now a changelog and changelog.Debian. It's libc6 now. Since this is my first Debian package, I'd appreciate a little peer review. Install it, try it out, check that it runs on your system, unpack the .tar.gz and patch, then see if it builds, etc... Because I'm not an official debian developer (...gonna have to fix that :) it has been uploaded to chiark. Word is it's sitting in master's incoming directory awaiting further processing, so all you official developers can get it there. If I'm connected, you can also snag it from my machine (on a pitiful 28.8) at ftp://rcw.oz.net/pub/debian/. If you know your way around chiark it should also be in alldone/ temporarily. That should be enough to allow inclusion in hamm. Also, netcat is conflicting with another package, nedit. The nedit client (nedit does client/server apparently) is also called 'nc'. Does anyone have any suggestions on what to do here? -- Robert Woodcock - [EMAIL PROTECTED] All I want is a warm bed and a kind word and unlimited power. -- Ashleigh Brilliant -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
