(a small correction) Re: Bug#80544: [rename] can't rename dir with valid permissions
Eray Ozkural (exa) wrote: Try to reproduce what I do there. The permissions on parent are irrelevant. That's a vfat filesystem. Permissions are same everywhere anyway if you wonder. Sorry sorry sorry sorry. Permissions on parent of course do matter as you express. However, in this case the permissions are uniform so the problem is not that. Anyway, I can rename in bash but not in gmc. Thanks, -- Eray (exa) Ozkural Comp. Sci. Dept., Bilkent University, Ankara e-mail: [EMAIL PROTECTED] www: http://www.cs.bilkent.edu.tr/~erayo
Intent to Orphan: fakebo
For reasons ranging from (lack of) time to obsolescence, I'm hereby orphaning fakebo. If anyone likes it well enough to take it over, speak up now. If no one steps forward in the near future, I'm going to officially request it's removal, as it has a security bug filed against it (#76314). It does drop privileges (running as nobody by default), and I don't think it's dangerous beyond a DOS, but still... On the more mundane side, it doesn't know how to deal with BO2K, and upstream development appears to be halted (no mailing-list or CVS updates updates in a year). pgpM3Tl8ADdOh.pgp Description: PGP signature
Re: booting Linux 2.2.18 NFS-Root
Branden == Branden Robinson [EMAIL PROTECTED] writes: Branden On Wed, Dec 27, 2000 at 03:58:47PM +1100, Brian May Branden wrote: I seem to have problems booting Linux 2.2.18 via NFS root image. **2.2.17 works fine**, but 2.2.18 says No NFS servers available, giving up. Branden [...] Any ideas what is going on? Branden This may not have anything to do with it, but IIRC, Alan Branden Cox merged the NFS v3 code into the 2.2.18 series. I fixed the problem. I am not sure if this was my fault grin or a change in the kernel, but now I have to use the -i rom option when creating the wrapper using mknbi-linux. It looks like the options the wrapper passes to the kernel disables it from doing the lookup automatically (I think this has changed in the kernel, not sure when). Somewhere now, something has broken the NFS-Root shutdown procedure. It complains that /etc and /dev are in use, and can't be unmounted. This use to work fine with 2.2.17, not sure what has changed. Then again, I don't understand how it did work... Oh, another thing, I keep getting warnings like this: Dec 27 21:15:34 pluto kernel: nfs warning: mount version older than kernel Is it OK to ignore these? As for NFSv3, I enabled it everywhere (I doubt my user-space daemon supports it though... Probably should use the kernel daemon.) --- what is the difference? -- Brian May [EMAIL PROTECTED]
Re: List of packages that could be dropped
On Wed, Dec 27, 2000 at 04:26:57PM -0700, John Galt wrote: 195 days is a lot of time to have an important package orphaned. At 6 or so months of orphaned-ness, if a maintainer is not found, one should and IMHO must look at the very real at that point possibility of going on without it. If this necessitates further changes as in removal of an entire architecture, then I'd say that it's time to shit or get off the pot, to use the vernacular. It can't be too damned important if nobody steps up and adopts it for ~6.5 months... ATM, though, it's not a real issue, but I think that in addition to the bug horizons, there needs to be a wnpp check on a freeze: orphaned packages die during a freeze unless adoped post haste (I can't remember if this means that silo would've died during the potato freeze...). silo (0.9.9-1) unstable; urgency=low * New upstream * Took over silo's packaging -- Erick Kinnee [EMAIL PROTECTED] Mon, 4 Sep 2000 10:54:23 -0500 No one knew it was on wnpp you idiot. As for your adopt or die, bullshit. Packages are not removed unless they present too many bugs to stay in. Silo had no bugs above normal, only 6 bugs in all, 5 of them were closable as is (already fixed), and the last was wishlist. Put up or shut up (to use your unique vernacular), because if you haven't got anything useful to say, you are just pissing people off. -- ---===-=-==-=---==-=-- / Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=--===-=-=-=-===-==---=--=---'
libapache-mod-perl does not activate the module
Hello, depending on libapache-mod-perl is not enough for my new package slash to be runable on a Debian box, sinde libapache-mod-perl does not reconfigure/activate the mod_perl Module in postinst. Am I allowed to check for the comemnted mod_perl line in apache's config and offer the option to activate it in my postist script (or call the apacheconfig script, but i am not sure if that will help), or should i file a wishlist bug agaianst libapache-mod-perl, requiring it to automatically add it to the list of loaded modules (like some others, like php are doing). Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Re: Rambling apt-get ideas
On Wed, Dec 27, 2000 at 02:03:14PM -0600, Vince Mulhollon wrote: How about an apt-getd debian daemon. Use a apt-get client to remotely mess with another workstations packages. Messing with only one workstation at a time is boring. How about multicast to configure a hundred workstations instead, all at once? And then have a proxying apt-getd server multicast out the .deb files to all the machines at the same time? You can do this already with apt-get and squid. -- - mdz
Re: libapache-mod-perl does not activate the module
On Thu, Dec 28, 2000 at 04:02:16AM +0100, Bernd Eckenfels wrote: Hello, depending on libapache-mod-perl is not enough for my new package slash to be runable on a Debian box, sinde libapache-mod-perl does not reconfigure/activate the mod_perl Module in postinst. Am I allowed to check for the comemnted mod_perl line in apache's config and offer the option to activate it in my postist script (or call the apacheconfig script, but i am not sure if that will help), or should i file a wishlist bug agaianst libapache-mod-perl, requiring it to automatically add it to the list of loaded modules (like some others, like php are doing). I'd rather you file bugs on the other packages which call apacheconfig interactively in postinst - I'm thinking of adding a 'just add this module, commented out, changing nothing else' option to apacheconfig. Either that or giving in and applying debconf to such a silly little problem. I really strongly disapprove of running apacheconfig; it can have startling changes on the behavior of an already configured server. See http://bugs.debian.org/79460 for more of my thoughts on this subject. Dan /\ /\ | Daniel Jacobowitz|__|SCS Class of 2002 | | Debian GNU/Linux Developer__Carnegie Mellon University | | [EMAIL PROTECTED] | | [EMAIL PROTECTED] | \/ \/
Openwall kernel patches
Has anyone looked into packaging the Openwall patches for the kernel? Their licensing is kosher. If nobody else steps up, I'll probably do it. -- - mdz
ITP: fuzz
Package: wnpp Severity: wishlist (already submitted to the BTS, is #80263) homepage URL: http://sourceforge.net/projects/fuzz/ d/l URL: http://download.sourceforge.net/fuzz/fuzz-0.6.tar.gz author: Ben Woodard (ben at valinux dot com) Fuzz is a debugging utility that checks for buffer overflows and other bugs (notably crashes and hangs because of lack of sanity checks, errors that are checked for but not correctly dealt with, and the like) by feeding a program random input through STDIN and argv. Distributed under the GNU General Public License. I will need a sponsor in order to upload this (currently waiting for an AM). My current try at packaging it is available at http://finbar.dyndns.org/~tgs/debapp/fuzz/ thanks and have a nice day -- Thomas Smith [EMAIL PROTECTED] http://finbar.dyndns.org/ gpg key id 0xACABA81E, fingerprint: 3A47 CFA5 0E5D CF4A 5B22 12D3 FF1B 84FE ACAB A81E pgpABs9J4nFWM.pgp Description: PGP signature
ITP: ttyrec -- a tty recorder
Package: wnpp Severity: wishlist URL:http://www.namazu.org/~satoru/ttyrec/ Description: A tty recorder ttyrec is a tty recorder. A recorded data can be playback with the included ttyplay command. ttyrec is just a derivative of script command for recording timing information with microsecond accuracy as well. It can record emacs -nw, vi, lynx, or any programs running on tty. License is BSD style. Regards.
Re: Another Grub question/problem
Hamish == Hamish Moffatt [EMAIL PROTECTED] writes: Hamish On Wed, Dec 27, 2000 at 03:23:52PM +1100, Brian May wrote: still haven't tried 2.2.18. The video= options seems to be completely ignored, and Linux boots up as if it wasn't there. Hamish Did you check /proc/cmdline to see if grub actually passed Hamish it to the kernel? cat /proc/cmdline mem=131008K root=/dev/hda1 video=0x319 I am having similar problems on this diskless NFS-Root system, too,\ where I have tried all the suggested combinations. Right now: cat /proc/cmdline auto rw root=/dev/nfs video=788 nfsaddrs=192.168.87.130:192.168.87.129:192.168.87.129:255.255.255.0: -- Brian May [EMAIL PROTECTED]
Re: Bug#80544: [rename] can't rename dir with valid permissions
On Thu, Dec 28, 2000 at 03:05:50AM +0200, Eray Ozkural (exa) wrote: Martin. Yes. I tried. Do you think I'm a newbie or something? Why do you think the file is owned by root? It's on windows partition... Hold on ... this is an msdos partition mounted? If so, check out man 8 mount; specifically the uid and gid options. -- Nathan Norman - Staff Engineer | A good plan today is better Micromuse Inc. | than a perfect plan tomorrow. mailto:[EMAIL PROTECTED] | -- Patton pgpvBSVvhDxPf.pgp Description: PGP signature
