Re: debian.org e-mail address and SPF/SRS
Hi, Matthew Palmer wrote:
> Uhm, having just read through the supplied URL, I can't agree with the
> sanity of the proposal. It appears to require that headers not be modified
> at all in transit
You can tell it which headers to protect, so that's not a problem.
In theory. Mailing lists do have a problem, but the list forwarder can
always re-sign the message. (It' in the draft.)
I don't like that proposal for a totally different reason: I need
to get the whole message before I can even think about rejecting it.
SPF, on the other hand, I can use as soon as I get the MAIL FROM:.
If I assume the DNS to be not compromised and mailers to be not-open-relay
(as the draft does), DomainKeys gets me precisely nothing, compared to
SPF. However, it'll hurt my bandwidth and my CPU.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
svn.debian.org
It took me a while to get SVN access to some projects at svn.debian.org. It will be nice if someone can update web page contents of svn.debian.org. Osamu - Here is example with pkg-ime. Although svn.debian.org lists for SubVersionN: svn://svn.debian.org/pkg-ime/ most obvious action caused as follows: $ svn co svn://svn.debian.org/pkg-ime/ svn: Can't open file '/svn/pkg-ime/format': Permission denied (This may be related to #debian-devel message "alioth: filesystems at 90+%, wrong perms") Alternative URL guessing from actual absolute path: $ svn co svn://svn.debian.org/svn/pkg-ime/ svn: Can't open file '/svn/svn/pkg-ime/format': Permission denied Then I tried (I have write access, so svn over ssh should work) $ svn co svn+ssh://svn.debian.org/pkg-ime/ svn: No repository found in 'svn+ssh://svn.debian.org/pkg-ime' Of couse, svn+ssh with absolute path /svn/pkg-ime/ worked but this is not so obvious from this svn.debian.org. But short message stating svn+ssh requires prepending of /svn/ or change all the listed URL to be with /svn/ may be more useful. (Assuming permission issues are gone and symlink svn --> . works) Osamu
UNSUBSCRIBE
-- If a listener nods his head when you're explaining your program, wake him up.
Bug#279983: general: scsi emulated cdrom ide unit can't be correctly mounted first time
Package: general Severity: important In my freshly rebooted computer (each time I reboot it): Each of the first times I try to do $ mount /cdrom I get an error answer: mount: /dev/scd0 no es un dispositivo de bloques válido (english: non valid block device) If I do # mount -t iso9660 /dev/hdc /cdrom I get another error, but this one is normal and expectable: mount: tipo de sistema de ficheros incorrecto, opción incorrecta, superbloque incorrecto en /dev/hdc, o número de sistemas de ficheros montados excesivo (could this be the IDE device where you in fact use ide-scsi so that sr0 or sda or so is needed?) (english: incorrect filesystem type, wrong option, incorrect superblock or too many mounted filesystems) After that error, any try to mount the cdrom as usual goes OK, but it is always impossible to mount it before doing that. My box is a completely updated sarge. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED]
Re: Comparing FHS 2.3 and 2.1
On Tue, Oct 26, 2004 at 05:59:18PM -0400, Joey Hess wrote: > Note that new sarge installs should be basically /media compliant, > although I don't know if we have every subdir the FHS may require in > there. And we still have a /cdrom link to /media since some programs > (like apt) have not transitioned. I don't think anyone has mentioned the need for a transition on -deity. It would be trivial to change the default, but it would also break existing systems. It could possibly search a list of likely mount points, or read fstab. We could also transition existing systems to /media. -- - mdz
Re: $HOME/.dotfiles and FHS 2.3 (was: Comparing FHS 2.3 and 2.1)
On Fri, Oct 29, 2004 at 04:53:29PM +0200, Frank Küster wrote: > "Marcelo E. Magallon" <[EMAIL PROTECTED]> wrote: > > * bash reads and writes a number of files in ~/ (.bash_profile, > > .bashrc, .bash_history) > > * there are several directories related to GNOME (at least ~/.gnome2 > > and ~/.gnome2_private) > > * vim has ~/.vimrc, ~/.viminfo (configure IIRC), ~/.vim/ > > They should probably use their own directory in the future. I think this > would really be a good idea. It would have been a good idea when these programs were being written. It doesn't seem at all worthwhile to endure a transition of existing software for the marginal aesthetic benefits. -- - mdz
Need help fixing bug #269534, #269534
Hello, I have two serious bug reports against cursel: #267900: cursel: ftbfs [sparc] syntax error "_Bool" #269534: cursel_0.2.2-3.1(ia64/unstable): FTBFS: bad build-depends However, the problem seems to be with another package, objc-poc: #258993: /usr/bin/objc1 is incompatible with gcc-3.3 and other problems To summarize, there is certain dependencies on gcc-2.95 in objc-poc, which cannot be resolved. I could do the following that may work around the problem: 1. Change build-depends as follows: Build-Depends: debhelper (>= 3.0), byacc, objc-poc, flex, libncurses5-dev, \ gcc-2.95 [!hppa !ia64], gcc-3.0 [hppa], gcc-2.96 [ia64] 2. Change debian/rules to force the c compiler as follows: ... C = gcc-2.95 ifeq ($(DEB_BUILD_ARCH),hppa) CC= gcc-3.0 endif ifeq ($(DEB_BUILD_ARCH),ia64) CC= gcc-2.96 endif ... But, it is insane since I will keep having bug reports. A better solution seems to have objc-poc upgraded to 3.2.6. Should I even be contemplating of MMUing it? Thanks for any suggestions/comments. Bao -- Best Regards. Bao C. Ha Hacom OpenBrick Distributor USA http://www.hacom.net voice: (714) 530-8817 fax: (714) 530-8818 8D66 6672 7A9B 6879 85CD 42E0 9F6C 7908 ED95 6B38
Re: $HOME/.dotfiles and FHS 2.3 (was: Comparing FHS 2.3 and 2.1)
On Nov 07, Matt Zimmerman <[EMAIL PROTECTED]> wrote: > It would have been a good idea when these programs were being written. > It doesn't seem at all worthwhile to endure a transition of existing > software for the marginal aesthetic benefits. Agreed. I see no point in even discussing this, considering that FHS says "should" and not "must". -- ciao, | Marco | [9020 baWEaEGQpMwlw] signature.asc Description: Digital signature
