Re: Signature de cle GPG
On Sun, May 18, 2003 at 03:54:02AM +0200, Eric Heintzmann wrote: Bonjour a tous, Je ne sais pas trop si c est le bon endroit pour poster ce message mais je n en vois pas d autre. Voila je cherche un developpeur Debian pour signer ma cle GPG. Et je cherche cet animal rare dans la region toulousaine de preference. Vous l aurez compris, il s agit pour moi de presenter ma candidature pour devenir developpeur Debian. J ai deja un paquet, un sponsor en la personne de Matthias Klose,j ai lu toutes les doc requises (et plus), il ne me manque plus qu une cle signee. Salut, j'emménage à Toulouse dans 2 semaines. Si ta clé n'est toujours pas signée, tu n'auras qu'à me contacter. Denis
Re: Signature de cle GPG
On Mon, May 19, 2003 at 11:14:33AM +0200, Denis Barbier wrote: Voila je cherche un developpeur Debian pour signer ma cle GPG. Et je cherche cet animal rare dans la region toulousaine de preference. Je suis disponible pour une signature. Tu peux donc me contacter. Salut, j'emménage à Toulouse dans 2 semaines. Si ta clé n'est toujours pas signée, tu n'auras qu'à me contacter. Haa ;) ça fait plaisir à entendre ;) -- Igor Genibel http://www.answare.fr/ [EMAIL PROTECTED] http://www.tuxfamily.org/[EMAIL PROTECTED] http://people.debian.org/~igenibel [EMAIL PROTECTED] GPG: 1024D/9D735B4F: 4F61 8D8F 05AC 8D2C 5F92 9B99 C44B 0266 9D73 5B4F
Re: Signature de cle GPG et SSTIC
[snip] Et je cherche cet animal rare dans la region toulousaine de preference. Je suis disponible pour une signature. Tu peux donc me contacter. Salut, j'emménage à Toulouse dans 2 semaines. Si ta clé n'est toujours pas signée, tu n'auras qu'à me contacter. Si vous organisez une petite signature autour d'un verre, je suis aussi partant... meme si je ne suis pas encore dans la démarche DD... Disons que j'attends de me stabiliser géographiquement... Autre sujet : Y a-t-il des personnes dans le sud-Ouest qui envisagent d'aller au SSTIC (http://www.stic.org) à Rennes ? Peut-être je peux covoiturer avec certains, mais je dois le savoir suffisament à l'avance pour pouvoir m'organiser... Olivier pgpFdFgXychFC.pgp Description: PGP signature
Re: NM, un peu d'aide s'il vous plait
Nicolas Bertolissio wrote: Bonjour, Je suis en train de répondre aux questions de mon responsable de candidature. Et je bloque un peu sur deux questions, similaires donc je n'en exposerai qu'une seule ici: 10. What does version 3.4-2.1 mean? upsteam version is 3.4 maintainer version is 2 NMU version is 1 What Debian control file would you put this in? changelog Please be more specific (hint: you may need to consider a lower level of the package-building process). Juste une idee comme ca. Et si il voulait que tu repondes debian/changelog et non changelog tout court ? Ben ouais, y a souvent des fichiers changelog ailleurs, donc il veut, peut etre, etre sur que tu confondes pas.
L'oeuf et la poule, version Build-Depends
Salut, Je suis en train d'empaqueter DJGPP, qui comme chacun sait est une version de GCC pour DOS. Pour être plus precis, c'est une libc spéciale et une architecture cible du toolchain GNU. J'ai trois paquets source : - (gcc|binutils)-i386-msdosdjgpp : paquets crées avec toolchain-source, qui pondent le cross-gcc kifo. - djgpp, qui compile la libc. Évidemment, pour compiler la libc, j'ai besoin du cross-compilo. Donc je Build-Depends: c-compiler-i386-msdosdjgpp. Seulement, pour compiler gcc, j'ai besoin des headers de la libc, donc je Build-Depends: djgpp. Et hop, une build-dépendence circulaire. Ça pourrait être pire. En fait, mon paquet djgpp est Arch: all. Si je ne m'abuse, quand un DD uploadera la chose, le paquet djgpp n'aura pas besoin de passer par les autobuilders. (confirmation?) Ca me tracasse quand même. Est-ce un problème ? Comment je peux éviter ça, d'après vous ? (et tant qu'on y est, un volontaire pour sponsoriser ?) -- Jeremie Koenig [EMAIL PROTECTED]
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 10:01:31PM -0500, Taral wrote: Looks like the python2.2 stuff migrated into testing without noticing that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) are advised not to upgrade. Huh? What's aptitude got to do with python-apt? Package: aptitude Version: 0.2.11.1-3 Depends: libapt-pkg-libc6.2-3-2-3.2, libc6 (= 2.2.4-4), libncurses5 (= 5.2.20020112a-1), libsigc++0, libstdc++2.10-glibc2.2 (= 1:2.95.4-0.010810) Anyone know how exactly the testing scripts managed to miss this breakage? They didn't, I told them to ignore it, since finally getting python, perl, qt, postgresql, etc up to date in testing is far more important. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Dear Anthony Towns: [...] Congratulations -- you are now certified as a Red Hat Certified Engineer!'' pgpJ6vk7g2fL6.pgp Description: PGP signature
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 10:01:31PM -0500, Taral wrote: Looks like the python2.2 stuff migrated into testing without noticing that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) are advised not to upgrade. Anyone know how exactly the testing scripts managed to miss this breakage? I'm just guessing here (didn't check yet), but isn't it more likely that people just didn't file a bug against python2.2? - Adam
Re: Warning: python-apt in testing broken, ** apt-listchanges ** users DO NOT UPGRADE
Huh? What's aptitude got to do with python-apt? Package: aptitude Version: 0.2.11.1-3 Depends: libapt-pkg-libc6.2-3-2-3.2, libc6 (= 2.2.4-4), libncurses5 (= 5.2.20020112a-1), libsigc++0, libstdc++2.10-glibc2.2 (= 1:2.95.4-0.010810) Okay, I feel like an idiot. It's supposed to be apt-listchanges, not aptitude. -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. Most parents have better things to do with their time than take care of their children. -- Me pgpE5rH4YfQTY.pgp Description: PGP signature
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 11:29:14PM -0500, Adam Majer wrote: On Sun, May 18, 2003 at 10:01:31PM -0500, Taral wrote: Looks like the python2.2 stuff migrated into testing without noticing that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) are advised not to upgrade. Anyone know how exactly the testing scripts managed to miss this breakage? I'm just guessing here (didn't check yet), but isn't it more likely that people just didn't file a bug against python2.2? python-apt has a very clear set of deps: Depends: python (= 2.1), python ( 2.2), ... That's NOT satisfied anymore in the current testing. -- Taral [EMAIL PROTECTED] This message is digitally signed. Please PGP encrypt mail to me. Most parents have better things to do with their time than take care of their children. -- Me pgpabX9jDlwvy.pgp Description: PGP signature
Re: Debian conference in the US?
Ben Collins [EMAIL PROTECTED] writes: What are other developers' feelings on the matter these days? If we're doing let's have a conf where we normally don't how about we have it on the US's east coast aswell. I'd personally argue for the nothern Virginia are myself. Too many conferences are held on the US's West coast, and if conferences do get to the East coast, they are always in New York. That leaves the south eastern US folks out in the cold. Wrong. It doesn't get cold out in the southeastern US. :P -- Looks like excitement by repetition!
Re: Do not touch l10n files (was Re: DDTP issue)
On Sun, 18 May 2003, Denis Barbier wrote: [All Cc's removed] On Sat, May 17, 2003 at 07:54:55AM +0200, Fabio Massimo Di Nitto wrote: [...] I don't believe that there is not an estestic layout that can satisfy all the languages we have in Debian. What is the rationale for having a single layout for all languages? since we are talking about estetic, i believe that it looks nicer keeping the layout coherent across translation. How do developers check how translations are rendered? sorry but i don't understand what you mean. Don't forget that most of the text we use in descriptions (or templates, or whatever) are based on technical language and terms, imho most of them farly new i would say and only recently adopted by common languages. Could you please be more explicit? I do not understand how this sentence is related to the issue discussed here. I will make a couple of example so we can understand each other better but they are just examples that i don't mind to discuss, but out of the mailing list since it will become too much off-topic imho. When you translate old literature, for instance, it is extremely difficult since you have to stick to tons of rules (ancient and new ones) and probably you will have to use some obsolete terms in your language that correspond to the same one in the other. In a case like this you need to apply atleast 3 grammatic rule sets. the old one in the other language, the old one in your language and the new one in your langauge, and if you don't do that in a really pedantic way you will loose everything of the meaning of the original text. Now evaluate computer related terms. They are not older than 20 years, only some of them have been accepted in common languages (read dictionaries), and in most cases we inveted new terms that will probably never flow in laguages other than computer ones. Think to something like: I've debianized X4.3! ;-) (an exagerate example but just to get the idea) in italian i would translate in something like: Ho debianizato X4.3! ;-). The verb to debianize doesn't exist in any dictionary other than the Debian one but somehow we imported it and adapted to out language. Keeping the same meaning and a very close layout. Point is that this is a shorcut to a more long and possibly boring translation that will look like: Io ho creato un pacchetto Debian che contiene i binari di X4.3 (exagerated a bit in the other way but still just to get the idea). Somehow the language evolves and since computer related language is farly new i don't see any problem in adapting it a bit for our targets. Of course you might argue that is not clean but afaik noone has ever really set rules for cases like this one. The point is that using a farly new language gives us a bit more freedom than using a normal language in a strict way. Can you see my point? Fabio -- Our mission: make IPv6 the default IP protocol We are on a mission from God - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: Debian conference in the US?
* Aaron M. Ucko ([EMAIL PROTECTED]) [030519 04:26]: * As mentioned, we have an enthusiastic sponsor lined up, which is a definite plus. What do we get from that sponsor? Conference rooms, network, accomodation, food, flights and tshirts?
Re: Bug#190038: libgtkdatabox_1:0.2.3.0-1(m68k/unstable/thing2): FTBFS on m68k
On Sat, 17 May 2003, Junichi Uekawa wrote:
It's strange, because on my i386 system
objdump -T /usr/lib/libgdk-X11-2.0.so gives
0002e71c gDF .text 0049 Base_gdk_display_x11_get_type
00045ebc gDF .text 014c Base_gdk_windowing_window_init
0005017c gDF .text 0106 BaseXineramaIsActive
00010a20 gDF .init Base_init
0002b8b0 gDF .text 0041 Basegdk_image_type_get_type
00050284 gDF .text 01ba BaseXineramaQueryScreens
DF *UND* 00c3 g_get_charset
00026e3c gDF .text 0097 Base_gdk_screen_close
and that probably means the symbol should be defined within that library.
On crest (m68k) this results in:
D *UND* XineramaIsActive
00016970 gDF .init Base_init
0002ffd4 gDF .text 004c Basegdk_image_type_get_type
D *UND* XineramaQueryScreens
DF *UND* 00c6 g_get_charset
0002b8fa gDF .text 009a Base_gdk_screen_close
DF *UND* 0148 XkbSetDetectableAutoRepeat
Any idea why it seems to be undefined (*UND*) on m68k?
Noone seems to have replied to this mail yet, but
for this kind of thing to happen, a possible cause would be
a XineramaQueryScreens function that is expected to be
defined in a static library (and linked into the
shared library) was once provided as a shared library.
libXinerama.a is only provided as a static library,
but apparently, on m68k, I suspect some symbols were provided
through some shared library, at some time.
Thanks for having a look at problem. I have to admit that I have no idea
what to do to fix the problem.
Kind regards
Andreas.
Re: Where are translated man pages packaged?
On Fri, May 16, 2003 at 10:02:18PM +0200, Fabio Massimo Di Nitto wrote: On Fri, 16 May 2003, Keegan Quinn wrote: On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote: On Fri, 16 May 2003, Keegan Quinn wrote: more than once i had to install small dns servers on boxes with less than 100Mb flash and stuff like that... so basically also the minimal installation has to be tight.. then rm doc and man and after install the minimum sets of pkgs to provide the services. Please do not try to force this methodology upon the standard Debian base system. Administrators of embedded systems have many tools to deal with these problems already, that do not require ever unpacking the full base onto the target. sorry but i can hardly read from the previous post that i am trying to force something to someone. I guess this is just a misunderstanding. Perhaps the word 'force' was a bit harsh, but it's essentially how it works for an end-user. It seemed to me that you were suggesting that the standard installer should be optimized for embedded systems, which does not sound like a very good idea. These systems have many specialized needs which cannot be easily accounted for. No i was not suggesting either. I was just explaining why i would like to avoid to get a bigger base system and giving out one of the reason. it was an example, no more no less. anyway no big deal ;) Ok, so, it wouldn't hurt anyone if all translated man pages were along the original one, or did I miss something again ? Thanks, Mt. -- Dans la france profonde, il y a surtout des spéléologues. -- Le Chat
[RFC] Chapter for the debian reference about l10n
Hello, I repost this because I got no feedback at all. I guess it shows that my email was long enough for not being read :) Thanks, Mt. On Wed, May 14, 2003 at 05:29:00PM +0200, Martin Quinson wrote: In order to help the current discution to find an usefull conclusion, I would like to propose you the following blahblah for inclusion in the debian reference Managing packages chapter, for example after the one on porting and geting ported. This is very far from being perfect, and I would be more than happy to discuss it before the actual inclusion. But, please, do respect the reply-to to debian-i18n, so that we discuss it on the right ML. Friendly, Mt. Internationalizing, translating and being internationalized and translated Debian supports an ever-increasing number of natural language. Even if you are native english speaker and do not speak any other language, it is part of your duty as a maintainer to be aware of issues of internationalization (abbreviated i18n because there is 18 letters between the 'i' and the 'n' in internationalization). Therefore, even if you are ok with english only programs, you should read most of this chapter. According to Introduction to i18n from Tomohiro KUBOTA, (http://www.debian.org/doc/manuals/intro-i18n/), I18N (internationalization) means modification of a software or related technologies so that a software can potentially handle multiple languages, customs, and so on in the world. while L10N (localization) means implementation of a specific language for an already internationalized software. l10n and i18n are tied, but the difficulties related to each of them are very different. It's not really difficult to allow the program to change the language in which texts are displayed based on user settings, but it is very time consuming to actually translate the messages. On the other hand, setting the character encoding is trivial, but adapting the code to use several character encodings is a really hard problem. Letting alone the i18n problems, where no general receipt exist, there is actually no central infrastructure for l10n within Debian which could be compared to the dbuild mecanism for porting. So, most of the work have to be done manually How are handled translations within Debian? === Handling translation of the texts contained in a package is still a manual task, and the process depends on the kind of text you want to see translated. For program messages, the gettext infrastructure is used most of the time. Most of the time, the translation is handled upstream within projects like the Free Translation Project (http://www.iro.umontreal.ca/contrib/po/HTML/), the Gnome translation Project (http://developer.gnome.org/projects/gtp/) or the KDE one (http://i18n.kde.org/). The only centralized resource within Debian is the Central Debian translation statistics (http://www.debian.org/intl/l10n/), where you can find some statistics about the translation files found in the actual package, but no real infrastucture to ease the translation process. An effort to translate the package descriptions started long ago even very few support is offered by the tools to actually use them (ie, only APT can use them, when configured correctly). There is nothing to do for the maintainers, and the translators should use the DDTP (http://ddtp.debian.org/). For debconf templates, maintainer should use the po-debconf package to ease the work of your translators, which should use the DDTP to do their work. Some statistics can be found both on the DDTP site (about what is actually translated), and on the Central Debian translation statistics site (http://www.debian.org/intl/l10n/ -- about what is integrated in the packages). For webpages, each l10n team have access to the relevant CVS, and the statistics are available from the Central Debian translation statistics site. For general documentation about debian, the process is more or less the same than for the webpages (the translators have an access to the CVS), but there is no statistics pages. For package specific documentation (man pages, info document, other formats), almost everything have yet to be done. Most notably, the KDE project handles translation of its documentation in the same way than its program messages. Debian specific man pages begin to be handled within a specific CVS repository (http://cvs.debian.org/manpages/?cvsroot=debian-doc). I18N L10N FAQ for maintainers === This is a list of problems that maintainers may face concerning i18n and l10n. While reading this, keep in mind that there is no real consensus on those points within Debian, and that they are only advices. If you have a better idea for a given problem, or if you disagree on some points, feel free to provide your feedback, so that this document can be enhanced. How to get a given text translated? --- To translate package description
Re: [RFC] Chapter for the debian reference about l10n
On Mon, 19 May 2003, Martin Quinson wrote: I repost this because I got no feedback at all. I guess it shows that my email was long enough for not being read :) Or there is no other comment from my side than: Go for it! It is an important topic! Kind regards Andreas.
Re: Maintaining kernel source in sarge
Hello
On Sun, May 18, 2003 at 04:52:54PM +0200, Martin Schulze wrote:
*SNIP*
Removing one kernel version and including another without rebuilding
all modules packages will break several installations. Not removing
the old packages will make the archive grow through time which will
cause problems with CD build scripts.
Hence, it is important that when a new kernel is added (e.g. for
security reasons) an older package is removed *and* all relevant
modules packages are rebuilt and included as well.
Rebuilding module pacakges is not always trivial. I hope that code
can help some. The reason is that most of them depend on a kernel-tree
that is already compiled. The following code fixes that (at least for my
situations).
I use it to compile modules for custom kernels. If you want me to make a command
line tool, just tell me. :)
Modify it as you wish.
# This file should be sourced by a file that sets the following variables.
#revision=01
#kernver=2.4.19
#arch=686
#append=freeswan+vlan+mppe+ctx+netboot+raid
#clean=no
#prepmods=
# Reasonable defaults
#E=${revision:=01}
# Some other settings.
srcdir=/usr/src
kernbdir=kernel-source-$kernver
curdir=`pwd`
modsrcdir=modules
kernsrcdir=$curdir/$kernbdir
FAKE=
if [ $UID != 0 ] ; then
FAKE=fakeroot
fi
if [ -z $maint ] ; then
I=[^:][^:]*
maint=$(grep ^$USER: /etc/passwd | \
sed s|$I:$I:$I:$I:||;s|[,:].*||;)
fi
if [ -z $email ] ; then
email=$EMAIL
fi
if [ $cleanall = yes -a -d $modsrcdir ] ; then
for d in $(find $modsrcdir -type d -mindepth 1 -maxdepth 1) ; do
rm -Rf $d
done
fi
if [ ! -d $kernbdir ] ; then
echo Unpacking source kernel-source-$kernver.tar.bz2
tar xfj $srcdir/kernel-source-$kernver.tar.bz2
else
echo CD $kernbdir
cd $kernbdir
if [ -d debian ] ; then
$FAKE debian/rules clean EOF
n
n
n
EOF
elif [ -f Makefile ] ; then
$FAKE make clean
fi
echo CD ..
cd ..
fi
if [ -n $prepmods ] ; then
if ! echo $prepmods | grep -q pcmcia-cs ; then
prepmods=$prepmods pcmcia-cs
fi
fi
for p in $prepmods ; do
echo PREPARE $p.
echo CD $curdir
cd $curdir
if [ $clean = yes -a -d $modsrcdir/$p ] ; then
rm -Rf $modsrcdir/$p
fi
if [ ! -d $modsrcdir/$p ] ; then
echo Uncompressing $p module.
if [ -r $p.tar.gz ] ; then
tar xfz $p.tar.gz
elif [ -r $p.tar.bz2 ] ; then
tar xfj $p.tar.bz2
elif [ -r $srcdir/$p.tar.gz ] ; then
tar xfz $srcdir/$p.tar.gz
elif [ -r $srcdir/$p.tar.bz2 ] ; then
tar xfj $srcdir/$p.tar.bz2
else
echo ERROR no source for preparing $p in '$srcdir' or '.'.
exit 1
fi
MODNAME=$(echo $d | sed -e s|.*/||;)
echo CD $modsrcdir/$p
cd $modsrcdir/$p
if [ -r ../$p.patch ] ; then
echo PATCHING $p source using ../$p.patch.
patch --forward -p1 --force ../$p.patch
fi
fi
done
echo CD $curdir
cd $curdir
if [ ! -d $modsrcdir ] ; then
echo A modules source directory is required! A directory for each modules
source.
exit 1
fi
compilemods=$(find $modsrcdir -type d -mindepth 1 -maxdepth 1)
if [ -z $compilemods ] ; then
echo No modules to create in $modsrcdir dir.
exit 1
fi
for arch in $archs ; do
VNAME=$kernver-$append-$arch
KERNSRC=/usr/src/kernel-headers-$VNAME
echo COPY kernel headers to kernel build tree.
cp -a $KERNSRC/* $kernsrcdir
for d in $compilemods ; do
MODNAME=$(echo $d | sed -e s|.*/||;)
echo CD $curdir
cd $curdir
echo CD $modsrcdir
cd $modsrcdir
echo CD $MODNAME
cd $MODNAME
#OPTS=KSRC=$KERNSRC KVERS=$VNAME
#OPTS=KSRC=$KERNSRC KVERS=$VNAME
OPTS=KSRC=$kernsrcdir KVERS=$VNAME
echo CLEAN before build.
$FAKE debian/rules clean $OPTS
echo BUILD
$FAKE debian/rules kdist $OPTS \
#$FAKE debian/rules binary-modules $OPTS \
KMAINT=$maint KEMAIL=$email DEST=../..
#KPATH=$KERNSRC:$kernsrcdir
done
done
Regards
// Ola
I would be glad if somebody could investigate the modules situation
and describe which modules packages require which kernel versions
(and/or depend on which other packages).
I also wonder if there are efforts in progress to unify the kernel
source through more than two architectures? This would require a
group or architecture maintainers (current kernel package mantainers)
to work collaboratively towards this goal.
A policy for kernel, kernel-patcha and kernel-module packages should be
great.
I'll start here:
Kernel package policy:
--
* It should only exist one kernel-source package.
* Every modification to the kernel should be added as a patch package.
* Modifications may be separated to make it easier to administrate and
for other people/packages to use it.
Kernel module
DSA's via rsync
As previously mentioned on this list, where I work, we have a sizeable chunk of infrastructure that can't connect out to a Debian mirror[1] One of my colleages has written a script, which works on the /var/lib/dpkg/status file on a host that may require updating comparing it against the /var/lib/apt/lists/security.debian.org_debian-security_dists_stable_updates_*Packages files and then generating a list along with the appropriate DSAs, of the packages that require updating. This would be made easier if the DSA's were obtainable in a more parseable format. Currently they're being retrieved from http://www.debian.org/security/ via a recursive wget. Would it be possible, and would it be beneficial to anyone else, if they were made available individually via rsync? Andrew [1] http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00468.html
Re: DSA's via rsync
On Mon, May 19, 2003 at 06:28:19PM +1000, Andrew Pollock wrote: This would be made easier if the DSA's were obtainable in a more parseable format. Currently they're being retrieved from http://www.debian.org/security/ via a recursive wget. Perhaps CVS would be easier? :pserver:[EMAIL PROTECTED]/cvs/webwml, module webwml, /english/security. You may need some extra bits to build the WML files. -- Colin Watson [EMAIL PROTECTED]
steambox ripper
Hi, Could you please help me to find the website from where I am able to download steambox ripper. Thanks, Reda.
Re: Bug#190038: libgtkdatabox_1:0.2.3.0-1(m68k/unstable/thing2): FTBFS on m68k
On Mon, May 19, 2003 at 09:30:52AM +0200, Andreas Tille wrote:
On Sat, 17 May 2003, Junichi Uekawa wrote:
It's strange, because on my i386 system
objdump -T /usr/lib/libgdk-X11-2.0.so gives
0002e71c gDF .text 0049 Base_gdk_display_x11_get_type
00045ebc gDF .text 014c Base_gdk_windowing_window_init
0005017c gDF .text 0106 BaseXineramaIsActive
00010a20 gDF .init Base_init
0002b8b0 gDF .text 0041 Basegdk_image_type_get_type
00050284 gDF .text 01ba BaseXineramaQueryScreens
DF *UND* 00c3 g_get_charset
00026e3c gDF .text 0097 Base_gdk_screen_close
and that probably means the symbol should be defined within that
library.
On crest (m68k) this results in:
D *UND* XineramaIsActive
00016970 gDF .init Base_init
0002ffd4 gDF .text 004c Basegdk_image_type_get_type
D *UND* XineramaQueryScreens
DF *UND* 00c6 g_get_charset
0002b8fa gDF .text 009a Base_gdk_screen_close
DF *UND* 0148 XkbSetDetectableAutoRepeat
Any idea why it seems to be undefined (*UND*) on m68k?
Noone seems to have replied to this mail yet, but
for this kind of thing to happen, a possible cause would be
a XineramaQueryScreens function that is expected to be
defined in a static library (and linked into the
shared library) was once provided as a shared library.
libXinerama.a is only provided as a static library,
but apparently, on m68k, I suspect some symbols were provided
through some shared library, at some time.
Thanks for having a look at problem. I have to admit that I have no idea
what to do to fix the problem.
Sorry, should've replied to this thread a bit earlier.
The exact problem you're quoting (the Xinerama thing), being a bug in
libgtk2.0 on m68k only, was of course known to us m68k porters. It
turned out to be a problem with logtool, which has now been fixed. The
new libgtk2.0 package is linked correctly again.
However, that's not why the bug was filed. There are a lot of undefined
references to other functions in the bugreport, that have nothing to do
with the (now fixed) Xinerama-problem. You may want to check them out.
--
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts.
-- National Geographic Channel, in a documentary about large African beasts.
pgpydMs56iBgB.pgp
Description: PGP signature
Re: Debian conference in the US?
* Aaron M. Ucko ([EMAIL PROTECTED]) wrote: What are other developers' feelings on the matter these days? I'm all for it, and GWU would be most excellent in my view. Of course, I live just outside DC... ;) Stephen pgpSnD1TuI4Jx.pgp Description: PGP signature
Re: DSA's via rsync
On Mon, 19 May 2003 18:28:19 +1000 AP == Andrew Pollock [EMAIL PROTECTED] wrote: AP AP AP This would be made easier if the DSA's were obtainable in a more parseable AP format. DSA'a are available in RDF. There exists a link on the bottom of www.debian.org/security to it. -- Alexander Kotelnikov Saint-Petersburg, Russia
Evolution 1.2.4. mailto: attachments
Hello Debian-devel, hello Takuo,
I patched Evolution 1.2.4 to be able to send attachments with a mailto:;
URL. Simply use
evolution 'mailto:[EMAIL PROTECTED]
subject=attachmentbody=Hello%20listattach=/path/to/file'
Please note that this functionality is enclosed in Evolution 1.3 beta, but
not in 1.2.4, the current stable version (AFAIK).
Patching is simple:
--- e-msg-composer.cSat Dec 7 07:09:39 2002
+++
/mnt/images/evolutionchroot/tmp/evolution-1.2.4/build-tree/evolution/composer/e-msg-composer.c
Fri May 16 15:35:27 2003
@@ -3719,7 +3719,9 @@
} else if (!g_strncasecmp (header, body, len)) {
g_free (body);
body = g_strdup (content);
- } else {
+ } else if (!strncasecmp (header, attach, len)) {
+e_msg_composer_attachment_bar_attach
(E_MSG_COMPOSER_ATTACHMENT_BAR (composer-attachment_bar), content);
+} else {
/* add an arbitrary header */
e_msg_composer_add_header (composer, header,
content);
}
That's all. Recompile and off you go. You will need additional patches in
debian/control: the libnss3, libnss-dev and libnspr4 dependencies are all
=2:1.2 here.
.deb-files are to be found at
http://olivier.sessink.nl/~valentyn/evolution-1.2.4/
Use at own risk!
Best regards,
Valentijn
--
http://www.openoffice.nl/ Open Office - Linux Office Solutions
Valentijn Sessink [EMAIL PROTECTED]
Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
From: Agustin Martin Domingo [EMAIL PROTECTED]
Subject: Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
Date: Fri, 16 May 2003 13:50:39 +0200
I am cc'ing this message to the debian-tetex-maint list. I think they
would also like to know about this and will have a much better knowledge
than I have about how possible it is and the incompatibilities that
might arise.
Even in the latest teTeX 2.0.2, there are settings in texmf.cnf
as follows;
TEXINPUTS.latex = .;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.latex209 = .;$TEXMF/tex/{latex209,generic,latex,}//
that is, there is basically no problem to provide latex209
macros under $TEXMF/tex/latex209 if the command was called
latex209.
Thanks, 2003-5-19(Mon)
--
Debian Developer Debian JP Developer - much more I18N of Debian
Atsuhito Kohda [EMAIL PROTECTED]
Department of Math., Tokushima Univ.
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 10:01:31PM -0500, Taral [EMAIL PROTECTED] was heard to say: Looks like the python2.2 stuff migrated into testing without noticing that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) are advised not to upgrade. aptitude has nothing to do with python-apt. You may be thinking of apt-listchanges. Daniel -- / Daniel Burrows [EMAIL PROTECTED] ---\ | It is hard to think of anything | | less sentient than a pumpkin. | | -- Terry Pratchett, _Witches Abroad_| \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Re: Do not touch l10n files
On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote: Highly technical packages like zebra, netfilter-related stuff and linux-atm are most likely to be used by people who know English. Not speaking English will make running routers and/or internet security systems almost impossible anyway. I've done most of the work to internationalize e2fsprogs (at least as far as gettext is concerned; I haven't done the framework to internationalize man pages yet), and while it was done mostly for my own edification, to learn about gettext, I have had some concerns about whether or not Internationalization is actually a *good* thing. The main problem here is support. If uses e2fsck with NLS support enabled, and with a non-US locale, the messages will come out in their native language. Which is all very well-and-good until they run into problems and they start asking me for help. If it's in some language I don't speak, such as Swahili, I'm going to be very hard pressed to actually help them. E2fsprogs may be a special case in that why I get these cries for help (which mainly are of the form, help me, I'm a loser, I didn't make backups, can you help me recover my 10 years of thesis research), time is of the essence. So waiting for a translation team to translate output back into English is not an option. Furthermore, when you're dealing with a filesystem which may have been modified by e2fsck during its initial run, the possibility of resetting the locale back to C to defeat the translation may not help, as the second e2fsck run may not have same messages as the first e2fsck run. I suppose that I could try to look at the Swahili's .po file, and try to match the output and turn it back into English, but that will be very, very tedious, and so I won't be able to help as many people when they give me their sad stories of years of research being lost. There are a couple of possible solutions: 1) Someone could write a program which takes output, and a .po file, and tries to undo the translation. This is a lot harder than it might first appear, since the strings may have printf expansions (i.e., %d, %x, and %s, with the last being particularly hard to deal with). 2) Use VMS or VM style message prefixes to make it easier for someone who doesn't under-stand the internationalization to figure out what's going on. (i.e., SYS-EXT2-YOURFUCKED-14326: Stupid summer intern who shouldn't have been given root access ran mke2fs on half of a MD device, where SYS-EXT2-YOURFUCKED-14326 is the same regardless of the translation, so it can be easily looked up). 3) Tell users to either not use the NLS support at all for e2fsprogs, or resign themselves to a second-class citizen level of support, simply because the developer can't provide free support in a language he (unfortunately) doesn't understand. Right now the default answer is #3, but that's not very satisfying. Among other things, it calls into question whether or not the internationalization of e2fsprogs was actually a good idea or not, or just a complete waste of time. As for the other possible solutions, I don't have time to write #1, but if someone is looking for a good summer project, I think it would be very useful. - Ted
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote: I'll start here: Kernel package policy: kernel image to avoid confusion between kernel source, kernel headers, kernel modules, etc. -- * It should only exist one kernel-source package. * Every modification to the kernel should be added as a patch package. * Modifications may be separated to make it easier to administrate and for other people/packages to use it. Kernel image packages must include a list of patches which have been applied, and the packages from which they came. Kernel module policy: - * Kernel modules must be provided as a binary source package. * Module source packages should provide a debian/rules file. * The debian/rules file must compile the module if KSRC=kernelsourcedir and KVERS=versionname is priovided. * The debian/rules file may fail if an unsupported version of the kernel is provided by the environment. * The debian/rules file may fail if no kernel-headers is in that location. * The debian/rules file should handke KMAINT and KEMAIL env variables. It would be a significant gain if kernel modules could always be built against kernel-headers, without requiring full kernel-source. Is there any situation where this is not feasible, or could it be made a requirement? -- - mdz
Re: Do not touch l10n files
On Mon, May 19, 2003 at 10:38:47AM -0400, Theodore Ts'o wrote: The main problem here is support. If uses e2fsck with NLS support enabled, and with a non-US locale, the messages will come out in their native language. Which is all very well-and-good until they run into problems and they start asking me for help. If it's in some language I don't speak, such as Swahili, I'm going to be very hard pressed to actually help them. E2fsprogs may be a special case in that why I get these cries for help (which mainly are of the form, help me, I'm a loser, I didn't make backups, can you help me recover my 10 years of thesis research), time is of the essence. So waiting for a translation team to translate output back into English is not an option. It seems to me this would be mitigated by two factors: 1) if they know enough to realize they should be emailing you in English, they probably realize they need to send the error messages in English too (by running e2fsprogs in English if possible, or providing an impromptu translation if not); 2) in single user mode, where I would expect most of the time-critical support requests to originate, it requires a significant amount of dedication to get a locale other than the C locale. In practice, are you running into support requests where there is a language barrier because of l10n of the e2fsprogs? The VMS-style error codes occurred to me as well. Though if one goes that route, I wonder if gettext any longer has advantages over msgcat. :) -- Steve Langasek postmodern programmer pgpE88IRdiNPh.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote: Kernel module policy: - * Kernel modules must be provided as a binary source package. * Module source packages should provide a debian/rules file. * The debian/rules file must compile the module if KSRC=kernelsourcedir and KVERS=versionname is priovided. * The debian/rules file may fail if an unsupported version of the kernel is provided by the environment. * The debian/rules file may fail if no kernel-headers is in that location. * The debian/rules file should handke KMAINT and KEMAIL env variables. It would be a significant gain if kernel modules could always be built against kernel-headers, without requiring full kernel-source. Is there any situation where this is not feasible, or could it be made a requirement? I think it's safe to say that if a kernel module package requires something not present in the kernel-headers package for building, there's a bug somewhere. Which is not to say there aren't bugs, of course. -- Steve Langasek postmodern programmer pgpwDosniEoMl.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
Ola Lundqvist [EMAIL PROTECTED] writes: Kernel module policy: - * Kernel modules must be provided as a binary source package. * Module source packages should provide a debian/rules file. * The debian/rules file must compile the module if KSRC=kernelsourcedir and KVERS=versionname is priovided. I'd be slightly happier if the targets kernel-package used were supported here, 'debian/rules kdist-image' and such. (This is to accomodate binary source packages that have a single debian/rules file that's copied verbatim from the source package to the binary package; both lm-sensors and i2c work this way, don't know about other packages.) * The debian/rules file may fail if an unsupported version of the kernel is provided by the environment. * The debian/rules file may fail if no kernel-headers is in that location. * The debian/rules file should handke KMAINT and KEMAIL env variables. ...in fact, this looks a lot like what kernel-package currently documents. Is a separate policy from the kernel-package documentation needed? (FWIW, i2c and lm-sensors both successfully build against only the kernel headers, via the kernel-build-* packages.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: Maintaining kernel source in sarge
Hello On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote: On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote: I'll start here: Kernel package policy: kernel image to avoid confusion between kernel source, kernel headers, Agreed. kernel modules, etc. -- * It should only exist one kernel-source package. * Every modification to the kernel should be added as a patch package. * Modifications may be separated to make it easier to administrate and for other people/packages to use it. Kernel image packages must include a list of patches which have been applied, and the packages from which they came. Agreed. Kernel module policy: - * Kernel modules must be provided as a binary source package. * Module source packages should provide a debian/rules file. * The debian/rules file must compile the module if KSRC=kernelsourcedir and KVERS=versionname is priovided. * The debian/rules file may fail if an unsupported version of the kernel is provided by the environment. * The debian/rules file may fail if no kernel-headers is in that location. * The debian/rules file should handke KMAINT and KEMAIL env variables. It would be a significant gain if kernel modules could always be built against kernel-headers, without requiring full kernel-source. Is there any situation where this is not feasible, or could it be made a requirement? At least the pcmcia and freeswan needs some parts of kernel source to build. At least last time I tried. I have been bitten by this a lot of times. But yes that would be really great if they just have to depend on the kernel source. Regards, // Ola PS. I accidentily deleted two other mails in this thread. Was they just for me or has they not yet been delivered to the mailinglist? DS. -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: steambox ripper
On Mon, May 19, 2003 at 09:06:20PM +1000, RedaComputer wrote: Could you please help me to find the website from where I am able to download steambox ripper. No, sorry - I'm afraid we'll first have to complete our search for the sheets of dueling banjos before we can work on your request. Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: steambox ripper
On Mon, May 19, 2003 at 04:19:31PM +0200, Richard Atterer wrote: No, sorry - I'm afraid we'll first have to complete our search for the sheets of ...that which shall not be named... before we can work on your request. Do you realize that every time this is mentioned in the list archives, it gets worse? -- - mdz
Re: Bug#193838: libgcc1: installation of libgcc1:3.3-2 causes failure of massive number of programs
[CC to debian-devel, did anybody see this behaviour on an update?] Luke Kenneth Casson Leighton writes: On Mon, May 19, 2003 at 04:52:51PM +0200, Matthias Klose wrote: Never seen this upgrade behaviour. Was libgcc1 installed before libstdc++5? If not, please could you explictely install libgcc1 and then libstdc++5? i have tried that. it says already at latest version. then i tried installing gcc 3.3. that failed to fix the problem. when i manually installed the OLD version of libstdc++: 514 dpkg -i /var/cache/apt/archives/libgcc1_1%3a3.2.3-0pre6_i386.deb 515 dpkg -i /var/cache/apt/archives/libstdc++5_1%3a3.2.3-0pre6_i386.deb then it fixed the problem ** BUT ** i now cannot install gcc 3.3 or anything else that depends on gcc 3.3 including groff, kernel-package, dselect, dpkg and a WHOLE boat load of critical packages. the only way that i can recover my system back to a useable state is: - remove unstable from sources.list - deinstall gcc () - deinstall python2.2 (!!!) and all of its dependent modules, python-mysql, htmltmpl, crypto, python-postgres just to name a few - reinstall python2.2 - re-add unstable back into sources.list - reinstall all of my python modules including python2.2-dev if i do NOT follow this procedure i end up with being either unable to reinstall or unable to run python. trust me when i say that this is a SERIOUS problem with the present debian unstable and i guarantee that you will see more people get into difficulties if they have python2.2 or any of the other programs that depend on libstdc++5 compiled with gcc3.2, and gcc3.3 on their system. l. Adding a pre-dpends on libgcc1 in libstdc++5 may help here, but this would not catch binaries depending on new symbols in libgcc1, and not depending on libstdc++5. there are a LOT of broken programs that have exactly this dependency problem. python2.2, update-menus were only two that i noticed and started to freak out over. Luke Kenneth Casson Leighton writes: Package: libgcc1 Version: 1:3.2.3-0pre6 Severity: critical actions taken: apt-get remove jade this required, at this time, the installation / upgrade of libgcc1 and the installation / upgrade of tetex. gcc 3.3 and cpp 3.3 was NOT required as part of that installation / upgrade. once actioned, python2.2, update-menus, and scores of other programs, failed to operate, with the following error: /usr/lib/libgcc_s.so.1: version 'GCC_3.3' not found (required by /usr/lib/libstdc++.so.5). -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Josip Rodin wrote: Well, yeah, sure, but the highway analogy doesn't apply. There isn't a single technical reason why I as a random person need to ever be in any sort of contact with a spammer to keep the system running. There was no mention of spammers in the thread! While they are prone to sending HTML emails its a general comment on people usage of the Internet. If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. Matt.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Emile van Bergen wrote I also don't understand the phrase today's Internet world. You mean with the hordes running Outlook and shopping on the clickable amazing discoveries / quantum shopping / tell sell channel that's the WWW? Yes. If you have to interact with them to any great extent then its hard to cut yourself off from those that don't follow the 'rules'. How does that make sane email communication standards less relevant? It doesn't, but then those hordes may not agree with your view of which standard to follow if they don't know of the RFC (in this case) and just go with the MUA default settings. Again, I ask: what's the alternative you are proposing? What do you want? I'm putting forward the viewpoint that the 'rules' are archaic and quoting them may not get the response you want/expect. If you can then drop email to NULL: for those people then thats fine but others may not be so lucky. I find it hard to get worked up with any of the anti-social behaviour that goes on (yes, even spam) because its more useful to have access to the Internet with all its warts than to avoid some of the interaction that acompanies it. It seems you just want to send HTML mail, and not feel sorry for it. Never said I wanted to and the thread was wider scoped than just HTML email. Matt.
stunnel
Hello, I saw stunnel has not been uploaded since december 2001, so unstable version of stunnel is very old. I use stunnel on all my computers, and I would like to take over the package. Is there any objection ? ( I sent a mail to current maintainer Paolo Molaro [EMAIL PROTECTED] three weeks ago without answer). Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Hi, On Mon, May 19, 2003 at 07:14:07PM +0100, Matt Ryan wrote: Josip Rodin wrote: Well, yeah, sure, but the highway analogy doesn't apply. There isn't a single technical reason why I as a random person need to ever be in any sort of contact with a spammer to keep the system running. There was no mention of spammers in the thread! While they are prone to sending HTML emails its a general comment on people usage of the Internet. If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. Few people are advocating to send every non-netiquette compliant mail to the bitbucket. However, I fail to understand why you want people to refrain from bringing the netiquette under the attention of the people they are receiving email from. It's not that receivers of email have a /right/ or that they can enforce compliance, but that was never the case anyway, in case you didn't notice. You can't demand anything, but of course you can filter whatever you like. It's your loss, nobody elses. IOW, if everybody just tries to accomodate some reasonable wishes as stated by the other party as far as is possible without effort (and including a text/plain part is no effort, not forwarding virus hoaxes is no effort, but proving to a robot that you are not *is*), there is no need to drop any netiquette rules. In short, I still fail to see your point. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
Re: Maintaining kernel source in sarge
Hello On Mon, May 19, 2003 at 12:43:02PM -0400, David Z Maze wrote: Ola Lundqvist [EMAIL PROTECTED] writes: Kernel module policy: - * Kernel modules must be provided as a binary source package. * Module source packages should provide a debian/rules file. * The debian/rules file must compile the module if KSRC=kernelsourcedir and KVERS=versionname is priovided. I'd be slightly happier if the targets kernel-package used were supported here, 'debian/rules kdist-image' and such. (This is to accomodate binary source packages that have a single debian/rules file that's copied verbatim from the source package to the binary package; both lm-sensors and i2c work this way, don't know about other packages.) Hmm, that was what I wanted too. It was just too long time ago I fiddled with the real options. I use my scripts too much I think. * The debian/rules file may fail if an unsupported version of the kernel is provided by the environment. * The debian/rules file may fail if no kernel-headers is in that location. * The debian/rules file should handke KMAINT and KEMAIL env variables. ...in fact, this looks a lot like what kernel-package currently documents. Is a separate policy from the kernel-package documentation needed? Well the kernel-package documentation is what I want to be highlighted. But they are not at mandatory (or similar) and some packages do not follow them. They are also not complete (in my opinion at least). (FWIW, i2c and lm-sensors both successfully build against only the kernel headers, via the kernel-build-* packages.) The kernel build-packages is a good step. Regards, // Ola -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Bug#193888: ITP: openoffice.org-thesaurus-de -- German Thesaurus for OpenOffice.org
Package: wnpp Version: unavailable; reported 2003-05-19 Severity: wishlist * Package name: openoffice.org-thesaurus-de Version : 20030512 Upstream Author : Daniel Naber [EMAIL PROTECTED] * URL : http://thesaurus.kdenews.org/lang.php?lang=en * License : GPL Description : German Thesaurus for OpenOffice.org This package contains a German Thesaurus for the OpenOffice.org office suite. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frodo 2.4.20-apm-rene #1 Sat May 10 00:47:56 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] pgpGtULPsRBPZ.pgp Description: PGP signature
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Mon, May 19, 2003 at 07:14:07PM +0100, Matt Ryan wrote: Well, yeah, sure, but the highway analogy doesn't apply. There isn't a single technical reason why I as a random person need to ever be in any sort of contact with a spammer to keep the system running. There was no mention of spammers in the thread! While they are prone to sending HTML emails its a general comment on people usage of the Internet. Spammers are only the bottom-most layer, but it's the same pile. (I'd quote a proverb about how small things lead to big things, but I can't currently think of any of those in English. :) If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. You started the subthread by saying the rules are archaic and irrelevant; whether the law-abiding people get used to other people breaking the laws or not is not the real issue -- that's a reality. But in principle, rejecting these laws based on the number of offenders, discarding the other realities such as the fact there's no official legislation enforcing them, doesn't strike me as particularly logical. -- 2. That which causes joy or happiness.
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
On Mon, May 19, 2003 at 10:17:40PM +0200, Josip Rodin wrote: (I'd quote a proverb about how small things lead to big things, but I can't currently think of any of those in English. :) Look after the pennies and the pounds will take care of themselves. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Accepted pointless 0.3-3 (i386 source)
reopen 193287 reopen 193286 thanks Marco Presi (Zufus) [EMAIL PROTECTED] writes: Format: 1.7 Date: Wed, 14 May 2003 20:30:39 +0200 Source: pointless Binary: pointless Architecture: source i386 Version: 0.3-3 Distribution: unstable Urgency: low Maintainer: Marco Presi (Zufus) [EMAIL PROTECTED] Changed-By: Marco Presi (Zufus) [EMAIL PROTECTED] Description: pointless - A presentation tool based on OpenGL Closes: 193286 193287 Changes: pointless (0.3-3) unstable; urgency=low . * Closes: #193287 * Closes: #193286 Uhhh, nope, sorry. Close them correctly or don't close them at all. -- Looks like excitement by repetition! pgpLbZW6s3csx.pgp Description: PGP signature
RE: Debian conference in the US?
-Original Message- From: Brian Nelson [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2003 1:05 AM To: debian-devel@lists.debian.org Ben Collins [EMAIL PROTECTED] writes: What are other developers' feelings on the matter these days? If we're doing let's have a conf where we normally don't how about we have it on the US's east coast aswell. I'd personally argue for the nothern Virginia are myself. Too many conferences are held on the US's West coast, and if conferences do get to the East coast, they are always in New York. That leaves the south eastern US folks out in the cold. Wrong. It doesn't get cold out in the southeastern US. :P Wrong. It DOES get cold. Just not AS cold as the northern US. :P Mike
Re: Bug#193838: libgcc1: installation of libgcc1:3.3-2 causes failure of massive number of programs
p.s. the version of python 2.2 is back at 2.2.1 compiled with gcc 2.95.4 (stable version) the version that got into trouble was the python 2.2 that was compiled with gcc 3.2 (unstable latest version?) On Mon, May 19, 2003 at 07:40:06PM +0200, Matthias Klose wrote: [CC to debian-devel, did anybody see this behaviour on an update?] Luke Kenneth Casson Leighton writes: On Mon, May 19, 2003 at 04:52:51PM +0200, Matthias Klose wrote: Never seen this upgrade behaviour. Was libgcc1 installed before libstdc++5? If not, please could you explictely install libgcc1 and then libstdc++5? i have tried that. it says already at latest version. then i tried installing gcc 3.3. that failed to fix the problem. when i manually installed the OLD version of libstdc++: 514 dpkg -i /var/cache/apt/archives/libgcc1_1%3a3.2.3-0pre6_i386.deb 515 dpkg -i /var/cache/apt/archives/libstdc++5_1%3a3.2.3-0pre6_i386.deb then it fixed the problem -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about...
Re: Do not touch l10n files
On 19-May-03, 11:03 (CDT), Steve Langasek [EMAIL PROTECTED] wrote: The VMS-style error codes occurred to me as well. Though if one goes that route, I wonder if gettext any longer has advantages over msgcat. :) I realize you're being (at least somewhat) facetious, but if you start with a message like fprint(stderr, SYS-YOURFSCKED-1334 Stupid summer intern error); used it consistently, and added Please don't attempt to translate anything that looks like SYS-BLAHBLAH-CODE to the docs, you might get much of what Ted wants and still get the advantages of gettext(). Of course, you don't get the full advantages of VMS system then, but you won't anyway on a Unix system. Steve If -- Steve Langasek postmodern programmer -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Daft Internet Stuff [Re: Returning from vacation. (MIA?)]
Matt Ryan [EMAIL PROTECTED] writes: sending HTML emails its a general comment on people usage of the Internet. If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. Is html-only email really all that widespread? I keep very close track of whether mail is in html form or not, for spam killing reasons, and I don't think I've _ever_ gotten an email from someone that didn't at least have a text/plain version of the contents along with the text/html. Of course most of my email is from technical people, but I certainly get a reasonable amount from non-technical people as well. On the other hand, spammers invariably -- so far! -- seem to send _pure_ html (no non-blank text/plain parts). [The big exception is nigerian 419-scammers, who for the most part don't even seem to have discovered lower-case...] -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down.
Re: DSA's via rsync
On Mon, May 19, 2003 at 04:25:20PM +0400, Alexander Kotelnikov wrote: On Mon, 19 May 2003 18:28:19 +1000 AP == Andrew Pollock [EMAIL PROTECTED] wrote: AP AP AP This would be made easier if the DSA's were obtainable in a more parseable AP format. DSA'a are available in RDF. There exists a link on the bottom of www.debian.org/security to it. Doh. I wish the person who'd asked me had looked harder :-( Andrew
Re: [fwd] Debian.cl
Gunnar Wolf dijo: A ver... Prefiero traer esto acá, entre cuates, antes de pasarlo al foro grandote. ¿Se lo enviamos a debian-legal? ¿Hay algo que se pueda hacer al respecto? ¿Algún chileno a la mano, ocnocen la política de resolución de disputas en .cl? Yo después de lo de hispalinux.com tengo el umbral de tolerancia bastante alto ;-) -- I would rather starve than lose your acceptance .''`.My eyes will always show my empty soul : :' :- Boy Sets Fire `. `' Proudly running Debian GNU/Linux (Sid 2.4.20 Ext3) `- www.amayita.com www.malapecora.com www.chicasduras.com
Re: [fwd] Debian.cl
Amaya dijo [Mon, May 19, 2003 at 03:55:32PM +0200]: A ver... Prefiero traer esto acá, entre cuates, antes de pasarlo al foro grandote. ¿Se lo enviamos a debian-legal? ¿Hay algo que se pueda hacer al respecto? ¿Algún chileno a la mano, ocnocen la política de resolución de disputas en .cl? Yo después de lo de hispalinux.com tengo el umbral de tolerancia bastante alto ;-) ...UGH. Nuevo para mí :-/ -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Re: [fwd] Debian.cl
Gunnar Wolf dijo: A ver... Prefiero traer esto acá, entre cuates, antes de pasarlo al foro grandote. ¿Se lo enviamos a debian-legal? ¿Hay algo que se pueda hacer al respecto? ¿Algún chileno a la mano, ocnocen la política de resolución de disputas en .cl? La reglamentacion de NIC Chile esta en http://www.nic.cl/reglamentacion.html bajo el titulo De las Revocaciones de Dominios aparecen las condiciones segun las cuales se puede pedir la revocacion de un dominio, y las causas son: a. Que el nombre de dominio sea identico o enganosamente similar a una marca de producto o de servicio sobre la que tiene derechos el reclamante, o a un nombre por el cual el reclamante es reconocido. b. Que el asignatario del nombre de dominio no tenga derechos o intereses legitimos con respecto del nombre de dominio, y c. Que el nombre de dominio haya sido inscrito y se utilice de mala fe. Y dentro de las evidencias de mala fe aparece: d. Que usando el nombre de dominio, el asignatario de este, haya intentado atraer con fines de lucro a usuarios de Internet a su sitio web o a cualquier otro lugar en linea, creando confusion con la marca del reclamante. Segun esto creo que se puede pedir la revocacion del dominio, pero no se cuales serian los pasos a seguir, probablemente sea necesaria la asesoria de un abogado local y seguramente debe ser debian com institucion quien pida la revocacion. Xavier
Re: [fwd] Debian.cl (from: ek3k0@vtr.net)
On Sun, May 18, 2003 at 07:53:05PM -0500, Gunnar Wolf wrote: A ver... Prefiero traer esto acá, entre cuates, antes de pasarlo al foro grandote. ¿Se lo enviamos a debian-legal? ¿Hay algo que se pueda hacer al respecto? ¿Algún chileno a la mano, ocnocen la política de resolución de disputas en .cl? Si hay alguien que ha de resolver esto es SPI a petición de Debian, en caso de que estén interesados. Dado que la empresa se dedica entre otras cosas a la administración de sistemas Debian, quizá sería bueno preguntarles a ellos primero tb. Un saludo -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] pgp0l9emd4LUC.pgp Description: PGP signature
