Re: RFC: packages that can be installed by the user but not used as build dependencies
Hello, Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a ecrit: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Qt > installation on each package depending on it... This is a _huge_ waste > of resources and buildd time (or is it not??) It is, but also on maintainer systems when testing in bare chroots etc. So I don't think maintainers would use it that much in practice. (similarly to no package currently build-depending on texlive-full) Samuel
Implicition declarations of functions and bugs
Hi,
In buildd logs, I could find several
test.c:3: warning: implicit declaration of function 'f'
warnings
This can be very problematic on 64bits architectures such as AMD64:
test.c:
#include
int main(void) {
printf("%p\n",f(-1));
return 0;
}
test2.c:
#include
void *f(long a) {
char c;
printf("%ld %p\n",a,&c);
return &c;
}
result:
4294967295 0x7ffc725f
0xfffc725f
instead of
-1 0x7ffc725f
0x7ffc725f
, which can of course entail a lot of bugs...
Maybe the debian policy should require
-Werror-implicit-function-declaration in CFLAGS so as to avoid such
issue?
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Implicition declarations of functions and bugs
Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit : > Maybe the debian policy should require > -Werror-implicit-function-declaration in CFLAGS so as to avoid such > issue? Or buildds could check for "implicit declaration of function" warnings. Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Implicition declarations of functions and bugs
Kurt Roeckx, le Fri 20 Jan 2006 23:56:22 +0100, a écrit : > On Fri, Jan 20, 2006 at 11:19:58PM +0100, Samuel Thibault wrote: > > Samuel Thibault, le Fri 20 Jan 2006 23:15:11 +0100, a écrit : > > > Maybe the debian policy should require > > > -Werror-implicit-function-declaration in CFLAGS so as to avoid such > > > issue? > > > > Or buildds could check for "implicit declaration of function" warnings. > > We could also check for lots of other things in buildd logs. One > that happens alot more is "cast to pointer from integer of > different size" and "cast from pointer to integer of different > size". Indeed, though it can be perfectly valid (int casted to void* for pthread_create(), then casted back to int in the thread, for instance). > But this really is the maintainer of the package that should look > at this. I don't think it's up to the buildd's maintainers to > go and look for this type of bugs. Ok, but maintainers don't seem to care so far. Something is needed to get their attention on this issue. Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
Hi, Ah, good. But your script misses some warnings: oss.c:83: warning: incompatible implicit declaration of built-in function 'strdu because of "incompatible" and "built-in". Please fix ;) Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
dann frazier, le Fri 10 Mar 2006 15:46:58 -0700, a écrit : > On Fri, 2006-03-10 at 00:30 +0100, [EMAIL PROTECTED] wrote: > > Hi, > > > > Ah, good. But your script misses some warnings: > > > > oss.c:83: warning: incompatible implicit declaration of built-in function > > 'strdu > > > > because of "incompatible" and "built-in". Please fix ;) > > Thanks Samuel, > Can you point us to the log file this is from? David & I aren't > subscribed, so please CC. This is from the speech-dispatch package: http://buildd.debian.org/fetch.php?&pkg=speech-dispatcher&ver=0.6-1&arch=ia64&stamp=1141941237&file=log&as=raw Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
David Mosberger-Tang, le Fri 10 Mar 2006 17:06:22 -0700, a écrit :
> I'm inclined to treat this as a gcc-4 bug.
It is not.
> $ cat t.c
> char *
> foo (char *str)
> {
> return strdup(str);
> }
> $ gcc-3.3 -c -g -O -Wall t.c
> t.c: In function `foo':
> t.c:4: warning: implicit declaration of function `strdup'
> t.c:4: warning: return makes pointer from integer without a cast
Because strdup() here gets an implicit
int strdup(int str)
declaration, hence the warnings.
> gcc-4.0 -c -g -O -Wall t.c
> t.c: In function 'foo':
> t.c:4: warning: implicit declaration of function 'strdup'
> t.c:4: warning: incompatible implicit declaration of built-in function
> 'strdup'
Same story, except that gcc has additionnal knowledge of which prototype
the strdup function should have: char *strdup(const char *str); . And
char * and int are not compatible types.
> The gcc-3.3 warnings makes perfect sense. The gcc-4.0 warnings are
> useless.
gcc-4.0 warnings are actually just more precise: not only there is a
missing declaration, but gcc has strong conviction that the implicit
prototype is really wrong (strdup() should really take char * and return
char *, not int).
> There is no hint on how the "implicit declaration of built-in function
> `strdup'" is incompatible.
Implicit declarations are in the form
int foo(int bar, int baz, etc.)
and the built-in strdup function has
char *strdup(const char *str)
as prototype. This is incompatible. gcc could even say "int is
incompatible with char*", but I guess gcc people consider this as too
verbose.
This is a warning and not an error, because using one's own strdup()
function (that would take ints) is perfectly legal. gcc-4.0 emits the
warning to let the programmer know that he should disambiguate this by
either #including the usual C header, or by giving the prototype of his
own strdup() function.
Anyway, such warnings deserve grepping, since they are evidence of a
potential binary break.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
Samuel Thibault, le Sat 11 Mar 2006 01:43:34 +0100, a écrit :
> > $ gcc-3.3 -c -g -O -Wall t.c
> > t.c: In function `foo':
> > t.c:4: warning: implicit declaration of function `strdup'
> > t.c:4: warning: return makes pointer from integer without a cast
>
> Because strdup() here gets an implicit
> int strdup(int str)
> declaration, hence the warnings.
>
> > gcc-4.0 -c -g -O -Wall t.c
> > t.c: In function 'foo':
> > t.c:4: warning: implicit declaration of function 'strdup'
> > t.c:4: warning: incompatible implicit declaration of built-in function
> > 'strdup'
>
> Same story, except that gcc has additionnal knowledge of which prototype
> the strdup function should have: char *strdup(const char *str); . And
> char * and int are not compatible types.
Another example:
int main(void) {
return abs(-1);
}
$ gcc-3.3 test.c -o test -Wall
test.c: In function `main':
test.c:3: warning: implicit declaration of function `abs'
$ gcc-4.0 test.c -o test -Wall
test.c: In function 'main':
test.c:3: warning: implicit declaration of function 'abs'
Here gcc 4.0 doesn't complain so much, because even if the abs()
function was not declared, the implicit prototypes matches the actual
prototype of the built-in abs() function, hence no potential binary
break if the programmer is really using the libc's abs() function.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
Hi,
David Mosberger-Tang, le Fri 10 Mar 2006 19:47:10 -0700, a écrit :
> Its purposes is not to "grep for warnings" but instead to
> look for pairs of warnings that are *guaranteed* to cause crashes on
> 64-bit machines.
I did understand that. And my abs() example shows that gcc-4.0 doesn't
complain is such case.
> enum e_t { a, b };
>
> enum e_t
> bar (char *str)
> {
> return strlen (str);
> }
> $ gcc-3.3 -c -g -O -Wall t.c
> t.c: In function `bar':
> t.c:12: warning: implicit declaration of function `strlen'
> $ gcc-4.0 -c -g -O -Wall t.c
> t.c: In function 'bar':
> t.c:12: warning: implicit declaration of function 'strlen'
> t.c:12: warning: incompatible implicit declaration of built-in function
> 'strlen'
That one may cause crashes too because of the str argument. It happens
that with pointers, on amd64, the compiler seems to correctly fill up
registers. But I don't know how this is and will always be true on all
64bits backends (it is not true for longs on amd64).
Well, submit the bug, and gcc people will tell us.
Regards,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Re: Implicition declarations of functions and bugs
Matthew R. Dempsky, le Sun 12 Mar 2006 14:09:54 -0600, a écrit : > On Sun, Mar 12, 2006 at 11:21:40AM +0100, Bastian Blank wrote: > > On Sat, Mar 11, 2006 at 01:43:34AM +0100, Samuel Thibault wrote: > > > This is a warning and not an error, because using one's own strdup() > > > function (that would take ints) is perfectly legal. > > > > No, it is not. At least not with a compiler in hosted mode. In this > > mode, the compiler is allowed to have any knowledge about the standard > > library builtin. gcc 4.0 uses this to replace memcpy with its own > > version. > > gcc has the -fno-builtin and -fno-builtin-FUNCTION options. Or better, -fno-hosted and -fhosted... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384693: Debian traduction team should work on Xt applications localization too
Package: general Severity: wishlist Tags: l10n Hi, Xt applications (like xfig, gv, xterm, ...) are currently not localized, while software support is already there, the traduction team just needs to work on translating labels in /etc/X11/app-defaults. For instance, the attached files are the ones that the xterm package should put in /etc/X11/[EMAIL PROTECTED]/app-defaults/ for French localization (some UTF-8 versions should also be put into /etc/X11/fr_FR.UTF-8/app-defaults/) Regards, Samuel -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (900, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) *mainMenu.Label: Options principales *mainMenu*toolbar*Label: Barre d'outils *mainMenu*securekbd*Label: Clavier sécurisé *mainMenu*allowsends*Label: Autoriser SendEvents *mainMenu*redraw*Label: Rafraîchir la fenêtre *mainMenu*logging*Label: Loguer vers un fichier *mainMenu*print*Label: Imprimer la fenêtre *mainMenu*print-redirect*Label: Rediriger vers l'imprimante *mainMenu*8-bit control*Label: Contrôles 8-bits *mainMenu*backarrow key*Label: Touche retour arrière (BS/DEL) *mainMenu*num-lock*Label: Modificateurs Alt/NumLock *mainMenu*alt-esc*Label: Alt envoie ESC *mainMenu*meta-esc*Label: Meta envoie ESC *mainMenu*delete-is-del*Label: Suppr envoie DEL *mainMenu*oldFunctionKeys*Label: Anciennes touches de fonction *mainMenu*sunFunctionKeys*Label: Touches de fonction Sun *mainMenu*sunKeyboard*Label: Clavier VT220 *mainMenu*hpFunctionKeys*Label: Touches de fonction HP *mainMenu*scoFunctionKeys*Label: Touches de fonction SCO *mainMenu*suspend*Label: Envoyer un signal STOP *mainMenu*continue*Label: Envoyer un signal CONT *mainMenu*interrupt*Label: Envoyer un signal INT *mainMenu*hangup*Label: Envoyer un signal HUP *mainMenu*terminate*Label: Envoyer un signal TERM *mainMenu*kill*Label: Envoyer un signal KILL *mainMenu*quit*Label: Quitter *vtMenu.Label: Options du terminal *vtMenu*scrollbar*Label: Activer la barre de défilement *vtMenu*jumpscroll*Label: Activer le défilement rapide *vtMenu*reversevideo*Label: Activer l'inversement vidéo *vtMenu*autowrap*Label: Activer le retour chariot auto *vtMenu*reversewrap*Label: Activer le retour chariot auto inverse *vtMenu*autolinefeed*Label: Activer le changement de ligne auto *vtMenu*appcursor*Label: Activer les touches de directions applicatives *vtMenu*appkeypad*Label: Activer le pavé numérique applicatif *vtMenu*scrollkey*Label: Retourner en bas sur pression de touche *vtMenu*scrollttyoutput*Label: Retourner en bas sur sortie Tty *vtMenu*allow132*Label: Autoriser le basculement 80/132 colonnes *vtMenu*selectToClipboard*Label: Sélectionner vers le presse-papier *vtMenu*cursesemul*Label: Activer l'émulation curses *vtMenu*visualbell*Label: Activer l'alerte lumineuse *vtMenu*poponbell*Label: Activer l'avant-plan sur alerte *vtMenu*marginbell*Label: Activer l'alerte de marge *vtMenu*cursorblink*Label: Activer le clignotement du curseur *vtMenu*titeInhibit*Label: Activer le basculement sur l'écran alternatif *vtMenu*activeicon*Label: Activer l'icône active *vtMenu*softreset*Label: Effectuer une remise à zéro légère *vtMenu*hardreset*Label: Effectuer une remise à zéro complète *vtMenu*clearsavedlines*Label: Remettre à zéro et effacer l'historique *vtMenu*tekshow*Label: Montrer la fenêtre Tek *vtMenu*tekmode*Label: Basculer vers le mode Tek *vtMenu*vthide*Label: Cacher la fenêtre de terminal *vtMenu*altscreen*Label: Montrer l'écran alternatif *fontMenu.Label: Police du terminal *fontMenu*fontdefault*Label:Défaut *fontMenu*font1*Label: Illisible *fontMenu*font2*Label: Minuscule *fontMenu*font3*Label: Petit *fontMenu*font4*Label: Moyen *fontMenu*font5*Label: Grand *fontMenu*font6*Label: Gigantesque *fontMenu*fontescape*Label: Séquence d'échappement *fontMenu*fontsel*Label:Sélection *fontMenu*font-linedrawing*Label: Caractères de tracé de trait *fontMenu*font-doublesize*Label: Caractères de taille double *fontMenu*font-loadable*Label: Police VT220 logicielle *fontMenu*render-font*Label:Police TrueType *fontMenu*utf8-mode*Label: UTF-8 *fontMenu*utf8-title*Label: Titres UTF-8 *tekMenu.Label: Options Tek *tekMenu*tektextlarge*Label: Caractères larges *tekMenu*tektext2*Label: Caractères taille N°2 *tekMenu*tektext3*Label: Caractères taille N°3 *tekMenu*tektextsmall*Label: Petits caractères *tekMenu*tekpage*Label: PAGE *tekMenu*tekreset*Label: REMISE À ZÉRO *tekMenu*tekcopy*Label: COPIER *tekMenu*vtshow*Label: Montrer la fenêtre de terminal *tekMenu*vtmode*Label: Basculer vers le mode terminal *tekMenu*tekhide*Label: Cacher la fenêtre Tek #include "../../app-defaults/XTerm" #include "XTerm.msg" #include "../../app-defaults/XTerm-color" #include "XTerm.msg" #include "../../app-defaults/UXTerm"
Re: Help needed: People willing to help co-maintain debian accessibility packages
Hi, It's been a long time since you asked for help, and apparently not many people showed up. Although I don't have any hardware synthesizer, I might help for packaging speakup and the debian installer. BTW, The current status of kernel-image-speakup-i386 is not good: it isn't in etch because of security fixes that are missing. Apparently, a mere rebuild with Build-Depends: debhelper (>= 2), modutils, kernel-tree-2.4.27-11, kernel-package (>= 8.105), gcc-3.3, kernel-patch-speakup (>= 20040506-1), transfig in debian/control works fine. Regards, Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#534989: ITP: console-braille -- Fonts and keymaps for reading/typing unicode braille
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: console-braille Version : 1.0 Upstream Author : Samuel Thibault * URL : http://brl.thefreecat.org/ * License : GPL Programming Lang: C Description : Fonts and keymaps for reading/typing unicode braille This includes . - fonts of a lot of sizes to render braille on the linux console - keymaps to type braille as unicode characters on the linux console. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#535615: ITP: libtopology -- Hierarchical view of the machine
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: libtopology Version : 0.9 Upstream Author : libtopology team * URL : http://libtopology.gforge.inria.fr/ * License : CeCILL-B Programming Lang: C Description : Hierarchical view of the machine libtopology provides a portable abstraction (across OS, versions, architectures, ...) of the hierarchical topology of modern architectures. It primarily aims at helping high-performance computing applications with gathering information about the hardware so as to exploit it accordingly and efficiently. libtopology provides a hierarchical view of the machine, NUMA memory nodes, sockets, shared caches, cores and simultaneous multithreading. It also gathers various attributes such as cache and memory information. libtopology supports old kernels not having sysfs topology information, with knowledge of cpusets, offline cpus, and Kerrighed support -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
remastering ISOs to append boot options
Hello, Some a11y people asked how to very easily remaster ISOs so as to append parameters to the kernel command line, to e.g. setup the braille configuration once for good before burning a CD. I've prepared a small crude script to do that on http://people.debian.org/~sthibault/remaster-append.sh it depends on the bsdtar and genisoimage packages, sample use is remaster-append.sh "brltty=eu,ttyS-1,fr_FR" debian-testing-i386-businesscard.iso myimage.iso I'm wondering how that could be provided in debian, or whether it already exists somewhere and I just wasn't able to find it :) I believe it could be more generally useful, for people preseeding stuff & such. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: #518696 ITP: parallel -- build and execute command lines from standard input in parallel]
I just noticed moreutils version 0.36 now contains a parallel command too. I haven't tested it yet. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
Vincent Danjean, le Mon 06 Jul 2009 11:55:08 +0200, a écrit : > Being able to change the lilo/grub/syslinux... configuration file would > also be interesting. Well, I'm not sure such modifications would be easy to automate. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
Vincent Danjean, le Mon 06 Jul 2009 11:55:08 +0200, a écrit : > I needed it to boot on a PC with no screen. It had only a terminal (an > old french Minitel 1B) on its serial line. > I did it by using the USB key boot methods and changing the correct files > (I do not remember exactly what I did). But I remember having been surprised > that booting on a serial line was not well documented in the Debian > documentation. I'm not sure how d-i is supposed to handle such case. debian-boot, opinions? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
Klaus Knopper, le Mon 06 Jul 2009 19:52:20 +0200, a écrit : > [Start of] discussion: > Changes to isolinux.cfg inside a .iso image must not exceed or even > change the space allocated by the file inside the image. Yes, and that makes things quite ugly. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
Marco d'Itri, le Mon 06 Jul 2009 18:01:31 +0200, a écrit : > On Jul 06, Samuel Thibault wrote: > > Some a11y people asked how to very easily remaster ISOs so as to append > > parameters to the kernel command line, to e.g. setup the braille > > configuration once for good before burning a CD. I've prepared a small > > crude script to do that on > This begs for a simple way to binary-patch the syslinux configuration > right in the image... That's another approach yes. As said by Klaus, that would have a size limitation, however. Maybe the linux kernel has one already actually :) Ideally images for all archs should have the same hook so that patching could be done the same way on all of them. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
MaTa, le Sat 11 Jul 2009 15:39:06 +0200, a écrit : > I'm sorry if I'm not an expert, but you can try with "DEBIAN_FRONTEND=text" > boot parameter, to install using the serial port. The question is: how do you type this with a PC that has no screen or keyboard, just a USB plug? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
MaTa, le Sat 11 Jul 2009 18:21:16 +0200, a écrit : > The PC have a RJ-45 connector? Can be that a "net plu"g is a serial console > too. It could not have. My question is about rs-232 console. > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 connector > "serial console") through hyperterminal with the standard Debian installation > CD > > A possible alternate way can be a preseed installation (a preconfigured file) Ok, but how do you proceed? Don't you need to either pass options to the kernel or prepare a particular image with the preseed config file? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
MaTa, le Wed 15 Jul 2009 22:40:28 +0200, a écrit : > 2009/7/15 Samuel Thibault > > > I have installed Debian in SunFire V120 (Sparc maquine with RJ-45 > > connector > > > "serial console") through hyperterminal with the standard Debian > > installation > > > CD > > > > > > A possible alternate way can be a preseed installation (a preconfigured > > file) > > > > Ok, but how do you proceed? Don't you need to either pass options to > > the kernel or prepare a particular image with the preseed config file? > > The preseed file it's "only" a text file with options that you can choose in > installer predefined in a file. To install a system using it needs to > "remaster" de CD with a little modification in boot options and include the > preseed file. It's no very complicated That's precisely my point. You are saying it's not very complicated, but it's not very trivial either (no need to give me info, it's already in the wiki etc), while I think it could be trivialized with a few helper tools, I'm just wondering where such tools could be maintained and advertized. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: remastering ISOs to append boot options
MaTa, le Thu 16 Jul 2009 08:13:24 +0200, a écrit : > • live-magic > • debian-cd > • simple-cdd > • live-helper I don't want to rebuild a whole CD from scratch, I want to just patch an existing debian installer image that I have downloaded (our bought and ripped), doing exactly what you mentioned earlier, but through the use of just one command. I guess you missed the start of the discussion on debian-devel: http://lists.debian.org/debian-devel/2009/07/msg00162.html Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introduction to multiarch: What maintainers must do
Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit : > the only requirement is that any files shipped there are identical > between packages of the same version for multiple architectures. That's however not true for .mo files, for endianness, typically. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introduction to multiarch: What maintainers must do
Goswin von Brederlow, le Wed 29 Jul 2009 19:09:59 +0200, a écrit : > sthiba...@debian.org writes: > > >> My first thought was "Err. Won't moving all the shared libs into a > >> different location kinda screw things up?" And then I looked, and found > >> > >> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <== > > > > Yes, but however pkg-config won't yet find things in > > /usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files > > in /usr/lib/pkgconfig. > > Where do they actualy belong. I would have said the -dev package > (which are to be left alone in round 1). Yes. However, passing --libdir to ./configure makes everything go to /usr/lib/x86_64-linux-gnu/, including pkgconfig files, that's why we should take care of that. > libsdl-gfx1.2-4: /usr/lib/pkgconfig/SDL_gfx.pc > > The second seems to be in clear violation of Policy 8.2. Yes. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introduction to multiarch: What maintainers must do
Peter Samuelson, le Wed 29 Jul 2009 13:41:20 -0500, a écrit : > > > Steve Langasek, le Wed 29 Jul 2009 19:01:57 +0200, a écrit : > > > the only requirement is that any files shipped there are identical > > > between packages of the same version for multiple architectures. > > [Samuel Thibault] > > That's however not true for .mo files, for endianness, typically. Mmm, on second though, maybe not, as I can find quite a few arch:all packages containing them. I now remember some thread about that on debian-devel. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Introduction to multiarch: What maintainers must do
Charles Plessy, le Thu 30 Jul 2009 13:13:59 +0900, a écrit : > 1) What is the advantage of adding a new field over simply using something > like >‘Arch: multi’? Err, I believe it makes sense to mark an i386/amd64-only library as multiarch-capable. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Re: Introduction to multiarch: What maintainers must do
Hendrik Sattler, le Thu 30 Jul 2009 10:35:38 +0200, a écrit : > Zitat von sthiba...@debian.org: > > >>My first thought was "Err. Won't moving all the shared libs into a > >>different location kinda screw things up?" And then I looked, and found > >> > >> | ==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <== > > > >Yes, but however pkg-config won't yet find things in > >/usr/lib/x86_64-linux-gnu/pkgconfig, so take care of putting .pc files > >in /usr/lib/pkgconfig. > > Please don't as those files can be different on different > architectures. Yes, but for now multi-arch support for -dev packages won't be done so it's not a problem. > Change PKG_CONFIG_PATH or PKG_CONFIG_LIBDIR instead. Don't ask the user to do it ;) > pkg-config has a win32-only feature to derive the prefix variable from > the location of the .pc file. Removing the ifdef would also enable > this on Linux and make pkg-config multiarch-usable. Yes, to get -dev packages multi-arch support such kind of thing will be needed. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bits from the release team and request for discussion
Cyril Brulebois, le Thu 30 Jul 2009 19:41:42 +0200, a écrit : > > Architectures > > = > > > > As some of you might have noticed, we added the architectures > > kfreebsd-i386 and kfreebsd-amd64 to testing. This is not a promise > > that they will be part of Squeeze, but we consider it realistic. > > Adding them early to testing makes it easier for us to get testing > > into shape. As of now, these architectures don't have any effect on > > the testing migration. Bugs specific to these architectures are not > > release critical. > > We try to direct user questions/bugreporting to our mailinglist[0], but > you might receive a GNU/kFreeBSD-specific bug report anyway. Feel free > to contact us, we'll look into those issues as time permits. > > 0. debian-...@lists.debian.org Also, please remember that such issues are often not only for GNU/kFreeBSD, but also for GNU/Hurd, GNU/OpenSolaris, GNU/whatever, so please rather think "non-linux issue" than "BSD issue". Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Harald Braumann, le Tue 11 Aug 2009 01:33:58 +0200, a écrit : > Or do you mean the user pays the price, because if the encoding is set > to UTF-8 then performance would suffer? In that case, I'd love to see > some real life numbers. I doubt the difference would be noticeable. Google utf-8 grep performance loss. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit : > while length(str) in any language up to the 1990s was a mere > substraction, now we must go through the string checking each byte to > see if it is a Unicode marker and substract the appropriate number of > bytes. Not necessarily. Any sane implementation should just use wchar_t and substraction gets back. The width of the text is another matter, but it's a problem for truetype rendering anyway. What is still costly is then the conversion, which in principle only happens while talking with other programs (files/socket/etc.) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Bernd Eckenfels, le Tue 11 Aug 2009 21:40:35 +0200, a écrit : > In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote: > > Not necessarily. Any sane implementation should just use wchar_t > > Which could be UTF16 and therefore still has complicatd length semantics. ?? wchar_t may be 32 or 16bit (in which case it can't express unicode after U+), but it's still meant to have the simple length semantics. > And even with UTF32 there are combining characters. Which account for one character. Then there is a problem of rendering width of course, but as I said it's there anyway as soon as you have a font with varying letter widths, string manipulation don't pose any problem anyway. > But the length could be defined in code units - its just a question > how usefull it is. Of course. It's rarely useful to take into account character width yourself, unless you are rendering on a tty, but then speed usually doesn't matter and you can afford calling wcswidth() on your string as late as possible. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Giacomo A. Catenazzi, le Wed 12 Aug 2009 07:54:33 +0200, a écrit : > Samuel Thibault wrote: > > Gunnar Wolf, le Tue 11 Aug 2009 13:28:08 -0500, a écrit : > >> while length(str) in any language up to the 1990s was a mere > >> substraction, now we must go through the string checking each byte to > >> see if it is a Unicode marker and substract the appropriate number of > >> bytes. > > > > Not necessarily. Any sane implementation should just use wchar_t and > > substraction gets back. > > An implementation that use wchar_t is usually not sane, but usually > it is (also) buggy. Why? It's just about using wide functions instead of usual functions. > PS: note that the binary encoding depend on compiler environment (but > such info is not exported). See my other mail. A lot of things can be made to depend on the compiler environment. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Giacomo A. Catenazzi, le Wed 12 Aug 2009 08:03:30 +0200, a écrit : > Bastian Blank wrote: > > On Tue, Aug 11, 2009 at 09:40:35PM +0200, Bernd Eckenfels wrote: > >> In article <20090811183800.ge5...@const.famille.thibault.fr> you wrote: > >>> Not necessarily. Any sane implementation should just use wchar_t > >> Which could be UTF16 and therefore still has complicatd length semantics. > > > > No, wchar_t is UCS-4 (or UCS-2 in esoteric implementations like > > Windows). > > No wchar_t is locale dependent (per POSIX). What do you mean? The compiler can't know the locale in advance for the width and endianness. The value might depend on the locale, yes, but that's not a problem as long as you convert into UTF-8 before communicating with other applications. One same systems (Debian systems are), it's just always UCS-4. > BTW on gcc: > > -fwide-exec-charset=charset > Set the wide execution character set, used for wide string and > character constants. It hurts when I shoot myself in the foot. > The default is UTF-32 or UTF-16, whichever corresponds to the width of > wchar_t. This documentation is bogus BTW. It should read "UCS-4 or UCS-2". > Note that default encoding is UTF-8, thus giving a UTF-32 wchar_t > in most developer machines. I don't understand this sentence. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: default character encoding for everything in debian
Roger Leigh, le Wed 12 Aug 2009 11:30:50 +0100, a écrit : > > > The default is UTF-32 or UTF-16, whichever corresponds to the width of > > > wchar_t. > > > > This documentation is bogus BTW. It should read "UCS-4 or UCS-2". > > It's "strictly" correct according to the standard. > http://en.wikipedia.org/wiki/UTF-32/UCS-4 for an overview. « except that the UTF-32 standard has additional Unicode semantics. » In UTF-32 mode, gcc introduces a BOM, and in UTF-16 it allows without warnings characters after U+. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544546: ITP: libfop-java -- Print formatter driven by formatting objects (XSL-FO)
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: libfop-java Version : 0.95 Upstream Author : The Apache Software Foundation. * URL : http://xmlgraphics.apache.org/fop/ * License : ASL 2.0 Programming Lang: Java Description : Print formatter driven by formatting objects (XSL-FO) libfop-java reads a formatting object (FO) tree and renders the resulting pages to a specified output. Output formats currently supported include PDF, PS, PCL, AFP, XML (area tree representation), Print, AWT and PNG, and to a lesser extent, RTF and TXT. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544547: ITP: libjing-java -- RELAX NG validator
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: libjing-java Version : 20081028 Upstream Author : James Clark * URL : http://xml.apache.org/xalan-j/index.html * License : BSD Programming Lang: Java Description : RELAX NG validator libjing-java implements a command-line user interface for - RELAX NG 1.0 Specification, - RELAX NG Compact Syntax, and - parts of RELAX NG DTD Compatibility, specifically checking of ID/IDREF/ IDREFS. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544551: ITP: jodconverter -- Office formats converter
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: jodconverter Version : 2.2.2 Upstream Author : Mirko Nasato * URL : http://www.artofsolving.com/opensource/jodconverter * License : LGPL Programming Lang: Java Description : Office formats converter JODConverter, the Java OpenDocument Converter, converts documents between different office formats. It leverages OpenOffice.org, which provides import/export filters for various office formats including OpenDocument and Microsoft Office. It can be used - as a java library, - as a command line tool, - as a simple web application, - as a web service. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544556: ITP: libisorelax-java -- Public interface for applications to support RELAX Core
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: libisorelax-java Version : 2004 Upstream Author : ASAMI Tomoharu, Daisuke Okajima, Kohsuke Kawaguchi, and MURATA Makoto * URL : http://iso-relax.sourceforge.net/ * License : MIT Programming Lang: Java Description : Public interface for applications to support RELAX Core The ISO RELAX project hosts the public interfaces useful for applications to support RELAX Core. More details about RELAX NG can be found on http://relaxng.sourceforge.net/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544612: ITP: jodconverter-cli -- Office formats converter - Command line interface
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: jodconverter-cli Version : 2.2.2 Upstream Author : Mirko Nasato * URL : http://www.artofsolving.com/opensource/jodconverter * License : LGPL Programming Lang: Java Description : Office formats converter - Command line interface JODConverter, the Java OpenDocument Converter, converts documents between different office formats. It leverages OpenOffice.org, which provides import/export filters for various office formats including OpenDocument and Microsoft Office. This is the command line tool part -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544637: ITP: joptsimple -- Command line parsing java library
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: joptsimple Version : 3.1 Upstream Author : Paul R. Holser * URL : http://jopt-simple.sourceforge.net/ * License : MIT Programming Lang: Java Description : Command line parsing java library JOpt Simple is a Java library for parsing command line options, such as those you might pass to an invocation of javac. In the interest of striving for simplicity, as closely as possible JOpt Simple attempts to honor the command line option syntaxes of POSIX getopt() and GNU getopt_long() . It also aims to make option parser configuration and retrieval of options and their arguments simple and expressive, without being overly clever. It is known to be simpler of use and cleaner than all other alternatives. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#544640: ITP: jaxe -- JAva Xml Editor
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: jaxe Version : 3.2 Upstream Author : Observatoire de Paris-Meudon, dami...@users.sourceforge.net * URL : http://jaxe.sourceforge.net/ * License : GPL Programming Lang: Java Description : JAva Xml Editor Jaxe is an XML editor adaptable to XML languages. It uses an XML schema and a configuration file for the graphical user interface. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
Russ Allbery, le Thu 03 Sep 2009 13:32:46 -0700, a écrit : > In specific, our information security office (rightfully) considers > the relationship between system and list of installed packages to > be confidential data because of the potential use of such data in > determining which systems to attack following a publicly announced > vulnerability. Could perhaps an almost empty popcon report be considered as valid at least just for the number of installed systems? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: State of developers-reference
Lucas Nussbaum, le Mon 07 Sep 2009 18:28:11 +0200, a écrit : > We could simply decide that it's deprecated, and use a set of wiki > pages to document our procedures. I would like to raise the fact that Internet is not available everywhere, so at least an easy way to get an offline copy of these would be useful. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Explicitely Cc bug reporters
Hello, I'd like to remind maintainers that in order to reach bug reporters to ask for tests etc. you _need_ to explicitely Cc the bug reporter, else he won't receive the mail and of course not do the tests etc. It's now quite a few times that I have received a "you didn't answer" mail... Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Explicitely Cc bug reporters
Leo costela Antunes, le Thu 10 Sep 2009 16:52:43 +0200, a écrit : > Why not include a pseudo-header to subscribe to bugreports on submit? I thought about that too, but that doesn't solve the original problem: clueless reporters won't enable it and absent-minded maintainers will forget to Cc them. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Build logs from local builds
Wesley W. Terpstra, le Wed 21 Oct 2009 13:02:37 +0200, a écrit : > What do other people think? Should this be possible? Should this be required? I confirm that usually not having the i386 or amd64 log is often a problem. One idea that was floating around was to have buildd always recompile the package, even on archs the uploader has provided a binary version for, to make sure packages are clean. That would somehow answer you need (i.e. provide a build log for _all_ archs). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit : > On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote: > > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote: > > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu > > > uses[2]. > > > > How do they work? Do they also change the free-standing compiler or only > > the hosted one? There is a lot of software, which (I would say) missuse > > the hosted compiler to build non-userspace-code, including the Linux > > kernel. > > The stack protector is conditional on being linked with libc, so, if you > build with -nostdlib (as the kernel does), it is implicitly disabled. -nostdlib is a linker option, not a compiler option. The compiler would still emit references to __stack_chk_fail. What you probably mean is -ffreestanding, but it doesn't prevent references to __stack_chk_fail either, and it even produces TLS references, see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838 Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Can linux-any arch and friends be used?
Felipe Sateler, le Thu 29 Oct 2009 12:12:33 -0300, a écrit : > I need to build-depend on a version of libc. Since they have different > names in different architectures, I used linux-any kfreebsd-any and > hurd-any to avoid spelling the entire list. That won't work for ia64 and alpha which have libc6.1-dev, not libc6. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: ReBuild-Depends?
Dmitry E. Oboukhov, le Thu 29 Oct 2009 18:33:12 +0300, a écrit : > I have a package which contains a code like following: > > > > This code works fine by libc wouldn't be rebuilt (new versions, or new > gcc - this moment is ambiguous to me). > Then this code begins segfaulting into this place. > If we try to rebuild our package, it will begin to work fine again. Looks like a bug, not a feature. It's probably worth looking further (at least trying with va_start :) ). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switch on compiler hardening defaults
Ben Hutchings, le Sun 01 Nov 2009 19:06:59 +, a écrit : > On Sun, 2009-11-01 at 19:53 +0100, Matthias Klose wrote: > > On 25.10.2009 19:55, Kees Cook wrote: > [...] > > > - makes more work for dealing with warnings. > > > Rebuttal: those warnings are there for a reason -- they can > > >be real security issues, and should be fixed. > > > > there are some functions in glibc which are questionably declared with the > > "warn > > about unused result" attribute (fwrite*). This seems to force a > > programming > > style which not everybody agrees with (having to check the return value > > after > > each operation instead of checking errno later). > [...] > > In general you cannot rely on checking errno because it is not defined > whether a successful operation clears it. But you can clear it by hand before calling them. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: RFC: RelaxNG and XML schema schemes packaged for Debian
Helloo, Daniel Leidert, le Wed 11 Nov 2009 17:36:05 +0100, a écrit : > A question: I'm currently working with relaxNG and found, that we > (Debian) AFAIK don't have the schemes for RNG [1] or XSD [2] packaged. I don't know very much about relaxNG, but I guess you could be interested in the isorelax and jing packages. Don't hesitate to help maintaining them :) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
Josselin Mouette, le Sat 14 Nov 2009 15:45:11 +0100, a écrit : > * I don’t think we need more than 2 of these. They are still > useful for servers or when some disaster happens in the GUI, but > who opens 6 console sessions nowadays? Blind people and crazy people who always run startx by hand, and also on servers. Actually I even sometimes need to open another one. No, even in that case I don't necessarily want to run X. Yes, in that case gdm doesn't get started so it shouldn't be so hard to find a solution. > * For desktop machines, the display manager starts on tty7, which > means there is a tty switch to display it. This causes a small > latency and can also create some bugs when you’re using a > graphical boot splash. The graphical boot splash could go to tty7. > * Does upstart make things like dynamic allocation of VTs > possible? > * Otherwise, shouldn’t we replace the getty processes started by > init by a small daemon that can allocate them as we see fit? > In all cases, as long as some consoles are managed by /etc/inittab we > are kind of doomed. I guess you mean as long as there is no negociation between gdm and whatever decides where gettys go? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian means 'closer to Windows'?
Marek Artur Penther, le Sun 15 Nov 2009 16:53:45 +, a écrit : > I want to use Debian, because I love this OS, but developers cutting this > love > by abadoning i386 arch. Do you mean the i386 processor? It's been abandonned by most OSes since quite some time already. Do you really still use an i386? Does it have enough RAM to run nowadays' Debian tools anyway? If you mean the i386 series (i.e. also pentium etc.) I don't see where you see Debian abandoning its i386 arch. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
Josselin Mouette, le Mon 16 Nov 2009 11:07:52 +0100, a écrit : > * Opens all /dev/tty1 to tty6 and display a d-i-like “press enter > to activate this console” in them. > * Provide a very simple interface to reserve a VT, that can be > queried by the display manager. And that reservation would kill the Open above? (else you still have a conflict) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: GDM, getty and VTs
I believe it would be useful to be able to configure preallocated VTs. I know a few people whose first action at boot is starting something like a monitoring application on VT6, dynamic allocation would break this habit. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#560088: ITP: python-portio -- low level port I/O for Linux
Ron Johnson, le Wed 09 Dec 2009 01:28:26 -0600, a écrit : > On 2009-12-08 17:42, Dmitrijs Ledkovs wrote: > >2009/12/8 Ben Hutchings : > >I'm working on a parallel LCD interface with my custom PCB and I > >wanted interactive way to use parallel port. Found this decided to > >package it for myself and anyone else. Why using that when you have all ioctls to do the same portably in ? Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [Pkg-xen-devel] Xen status in lenny?
Gunnar Wolf, le Wed 16 Jul 2008 07:42:37 -0500, a écrit : > > I could live with the I/O slowdown but nothing will make hardware > > magically appear. > > Please explain further on this. Do you mean that xen can run > paravirtualized hosts without the hardware features (i.e. the lesser > CPUs sold nowadays) while kvm does require VMX/SVM? Precisely. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tools/ and dftp on mirrors
Michelle Konzack, le Mon 11 Aug 2008 20:09:23 +0200, a écrit : > Hmmm, this mean, "loadlin.exe" would be removed too? loadlin is used for the win9x support too. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Upcoming changes to supported architectures
Michael Casadevall wrote > kfreebsd-* is pretty close to releasable; they've got the archive > built in the high 80s, and are keeping up). BTW, it may be worth noting that a bunch of packages still include headers: in the Failed part of hurd-i386, 178 packages out of 1320 fail at least because of inclusion of #include (there could be others hidden by other compilation problems). That's 2.29% of the 7748 packages in our wanna-build database!... And we still have 1952 packages in the dep-wait state, a lot of them probably include too... Some of these packages could probably be fixed into automatically disabling some linuxish features, or use more standard headers (like sys/types.h...), but still a bunch of tools use for a very good reason. The 95% figure may have to be revised unless we ask non-linux ports to implement linuxish interfaces... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: html2text with utf8 support: please test
Eugene V. Lyubimkin wrote: > Utility html2text, version 1.3.2a-6, with "utf8" patch was just > uploaded to experimental. The patch allows to process UTF-8 files > when '-utf8' option supplied. Input should be in UTF-8 and output will > be in UTF-8 too. > > Please test this functionality - I believe that UTF-8 support is a > good feature, especially for processing non-English documents. Mmm, the way it is done looks wrong to me: there is no reason why the input and output charsets should be related at all. For the input, html2text should recognize the meta http-equiv tag, that should work for a lot of pages, else an input-charset option can be provided. For the output, the current locale's charset should be used (as returned by nl_langinfo(CODESET) after calling setlocale(LC_CTYPE,"")), that should work in almost all cases, else an output-charset option can be provided. Yes, that means conversions. But without that you can not put a sticker "utf-8 support", only "limited utf-8 support". Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496771: Deb AMD64 eats huge amounts of memory (and babies?) because of badly built libs
Gustaf Räntilä, le Wed 27 Aug 2008 12:50:45 +0200, a écrit : > I haven't seen many discussions about this in debian, and just 1 about ubuntu > [1]. It could be that I have gotten things completely the wrong way (then > please tell me so), but it could also be that this has been overseen for too > long, and now needs serious attention. Do not mistake virtual memory for resident memory. Aligning stuff in the address space is not a problem, it does _not_ consume any memory (even less if the library is not even used). > 31095 gustaf20 0 1314m 700m 35m R 30 17.8 252:06.36 firefox-bin > 32197 gustaf20 0 1006m 439m 39m S 12 11.2 167:03.50 epiphany-browse Here are the suckers, not pidgin. Do not have a look at virtual numbers, as the name says these are virtual. Have a look at the %MEM or RES columns instead. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /proc and build environments
Florian Weimer, le Sat 13 Sep 2008 10:43:40 +0200, a écrit : > This is probably a FAQ, and I guess I knew the answer at one point. > What are the requirements for /proc and buildds? >From a Debian GNU/Hurd point of view, it is well known that /proc is needed for quite a few packages (and that used to pose FTBFS for hurd-i386). Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: List of RC-buggy source packages by maintainer/uploader
> win32-loader Waiting for loadlin, waiting for yasm, for which a patch just got commited upstream. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Terminal emulators and command line arguments (again!)
Sune Vuorela, le Mon 13 Oct 2008 05:34:25 +, a écrit : > On 2008-10-12, Steve McIntyre <[EMAIL PROTECTED]> wrote: > > Sune wrote: > >>I dont think supporting title and stuff should be required for providing > >>x-terminal-emulator. I think we could require to handle -e properly, but > >>not much more than that. > > > > Out of curiosity, why not support setting of title etc.? That's the > > main thing I'm considering here, in fact... > > I don't know if I see the need for setting the title at all? When you have a bunch of windows, it's quite useful to be able to find out the one you want in just a window list. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tools removed from mirrors
Joerg Jaspert, le Mon 17 Nov 2008 23:53:33 +0100, a écrit : > And noone complained when I asked about it in August this year, so now > its gone. Uh, I wasn't yet subscribed to debian-devel at the time and thus wasn't aware of that goal. It sure is still useful for blind people booting from a DOS bootdisk with a screen reader (still so far the only accessible "bootloader") > Loadlin-packager: CCed you, as you want to stop building the byhand > component. Well loadlin should at least be kept on the installation CDs. And to my knowledge the CD image build system fetches it from ftp mirrors... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /tools removed from mirrors
Joerg Jaspert, le Tue 18 Nov 2008 08:47:43 +0100, a écrit : > >> And noone complained when I asked about it in August this year, so now > >> its gone. > > Uh, I wasn't yet subscribed to debian-devel at the time and thus > > wasn't aware of that goal. It sure is still useful for blind people > > booting from a DOS bootdisk with a screen reader (still so far the only > > accessible "bootloader") > > If we really need it for some support I'm happy to put those neccessary > files back. The best way for this would be an upload of a package > (or multiple) including a byhand component for the part to be put into > tools/. Like, for the unzip stuff one of unzip, the gzip part via gzip, > etc. as had been done with loadlin in the past. Do you believe that the unzip stuff will really get into Lenny? I'm asking because the loadlin package used to upload a complete .zip, but that is useless for the user if he doesn't have unzip to unpack it. And that being said, I have always been wondering whether we shouldn't just put loadlin.exe and its manual as loadlin.txt which is a lot easier to use than having to unpack it first... Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Can I become a Debian package maintainer, how?
schoappied, le Sat 20 Dec 2008 23:48:32 +0100, a écrit : > Ok... What to do mean by 'fix bugs'? I think I'm able to build packages, > but I'm not a software developer... A lot of bugs are packaging issues. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#509517: ITP: mbrola -- multilingual software speech synthesizer
Package: wnpp Version: N/A; reported 2008-12-21 Severity: wishlist * Package name: mbrola Version : 3.01h Upstream Author : Dr Thierry Dutoit * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the voice and language databases made available by the author. Description : multilingual software speech synthesizer Mbrola is Thierry Dutoit's phonemizer for multilingual speech synthesis. The various diphone databases are distributed on separate packages, but they must be used with and only with Mbrola because of license matters. Read the copyright for details. . Mbrola itself doesn't provide full TTS. It is a speech synthesizer based on the concatenation of diphones. It takes a list of phonemes as input, together with prosodic information (duration of phonemes and a piecewise linear description of pitch), and produces speech samples on 16 bits (linear), at the sampling frequency of the diphone database. . Use Mbrola along with Freephone, cicero or espeak to have a complete text-to-speech in English. I'm actually taking oralux' packaging of mbrola to Debian. Yes, that would basically be a fully binary package (i386, amd64, ppc, arm, alpha, and sparc), no source, no way to modify it (even the voices), and I had to get permission from the author to distribute it. However, the quality of the voices is very good compared to what we currently have in the main section. The idea would be to have the mbrola package containing the binary, and then separately package voices as mbrola-xyn, containing voice xyn (i.e. mbrola-fr1, mbrola-fr2, mbrola-en1, mbrola-en2 etc.) Since voices are a few MB, that is not really a waste to have separate packages, and permits lighter updates. I intend to also package freephone, cicero etc. but won't do so if mbrola itself can not enter even non-free. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file
John Goerzen, le Thu 25 Dec 2008 12:04:43 -0600, a écrit : > Julian Andres Klode wrote: > > Hardlink is a tool which detects multiple copies of the same file and > > replaces > > them with hardlinks. > > . > > The idea has been taken from http://code.google.com/p/hardlinkpy/, but the > > code has been written from scratch and licensed under the MIT license. > > Do we really need another tool like this? > > We already have these packages: > > perforate Nothing to do with this. > fdupes That one would be an argument for "hardlink is a duplicate" _if_ #284274 was fixed. Else, hardlink is really useful. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#509685: ITP: hardlink -- Hardlink multiple copies of the same file
John Goerzen, le Fri 26 Dec 2008 08:54:53 -0600, a écrit : > Samuel Thibault wrote: > > John Goerzen, le Thu 25 Dec 2008 12:04:43 -0600, a écrit : > >> Julian Andres Klode wrote: > >>> Hardlink is a tool which detects multiple copies of the same file and > >>> replaces > >>> them with hardlinks. > >>> . > >>> The idea has been taken from http://code.google.com/p/hardlinkpy/, but > >>> the > >>> code has been written from scratch and licensed under the MIT license. > >> Do we really need another tool like this? > >> > >> We already have these packages: > >> > >> perforate > > > > Nothing to do with this. > > Eh? It can do exactly what #284274 requests in fdupes below. How is > that not relevant? Oh, sorry, I hadn't seen the « Also there are some scripts that help cleaning up the hard disk » I don't see why that belongs to the perforate package. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#510133: ITP: mbrola-en1 -- British English male voice for Mbrola
Package: wnpp Version: N/A; reported 2008-12-29 Severity: wishlist * Package name: mbrola-en1 Version : 19980910 Upstream Author : Faculte Polytechnique de Mons - mbrola team * URL : http://tcts.fpms.ac.be/synthesis * License : see the file readme.txt in the source zip: non-free as in without source code, and for non-commercial, non-military purposes, with and only with the mbrola package made available by the author. Description : British English male voice for Mbrola This package contains an English diphone database provided in the context of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/ . It provides a British English male voice (known as "Roger's voice") to be used with the Mbrola program. It has been built from the original Roger diphones made available by CSTR, University of Edinburgh, as part of their generic text-to-speech system Festival. . http://www.cstr.ed.ac.uk/projects/festival.html . Input files use the SAMPA phonetic notation, as adopted in other Mbrola databases. This package also provides the correspondence with the MRPA phonetic notation used in the original distribution of Roger's voice in the Festival TTS system. This is the first of a series of voices for the non-free mbrola speech synthesis and serves as a first example for discussion. It would provide the following virtual packages: mbrola-voice-en-uk, mbrola-voice-en, mbrola-voice -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510624: ITP: pigz -- Parallel Implementation of GZip
Josselin Mouette, le Sun 04 Jan 2009 16:07:25 +0100, a écrit : > Le dimanche 04 janvier 2009 à 15:49 +0100, Eduard Bloch a écrit : > > Sounds like a plan, but I don't feel very comfortable to do that in the > > Debian package. Let me explain why: > > > > - sched_setaffinity method seems to be Linux specific > > How is that a problem? You only need to use it in Linux builds. And revert to using sysconf() in the cases when you're not on Linux. > > - it's hard to imagine environments with big difference between > >count(cores) and count(available cores) > > It’s already the case in HPC environments, and CPU pinning is certainly > going to be used more widely as the number of cores increases. And that's a shame. Linux shouldn't be so happy to move tasks between CPUs... Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510624: ITP: pigz -- Parallel Implementation of GZip
Josselin Mouette, le Mon 05 Jan 2009 00:20:42 +0100, a écrit : > Samuel Thibault, le Sun 04 Jan 2009 23:45:22 +0100, a écrit : > > > It’s already the case in HPC environments, and CPU pinning is certainly > > > going to be used more widely as the number of cores increases. > > > > And that's a shame. Linux shouldn't be so happy to move tasks between > > CPUs... > > Actually it doesn’t. Since CPU affinity was included (IIRC in 2.6.16) it > is much less prone to move tasks, and the performance impact of not > using CPU pinning is small. Things have improved, yes. > Still, it is better to use CPU pinning since you often want finer > control than that, and that’s especially true in multi-user environments > where resources can be sub-host. Sure, but that should be only a user-explicitely-wanting thing. I would really not like to see pigz systematically bind threads. What if I e.g. want to run several pigz processes at the same time because I have a lot of cores and a lot of files (I guess pigz doesn't scale so much)? Ideally, we should just let Linux manage everything, i.e. put related threads together on the same dies, balancing the load according to the observed behavior, which can vary a lot depending on the latency of reading files, the time to compress, etc. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510624: ITP: pigz -- Parallel Implementation of GZip
Ron Johnson, le Sun 04 Jan 2009 17:40:08 -0600, a écrit : > On 01/04/09 17:20, Josselin Mouette wrote: > >Still, it is better to use CPU pinning since you often want finer > >control than that, and that’s especially true in multi-user environments > >where resources can be sub-host. > > Wouldn't it be better to bind a process to a "chip", rather than a > "core", so that you don't run into cases where, after many processes > terminate, you are left with most of the busy processes pinned to a > single busy core while the others are mostly unused? That's precisely the kind of thing that makes it better to just leave it up to Linux. The case of HPC is quite particular in that you usually really precisely control your computation. In the case of general-purpose tools, I would really not recommend it. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#510624: ITP: pigz -- Parallel Implementation of GZip
Josselin Mouette, le Mon 05 Jan 2009 00:47:02 +0100, a écrit : > There is probably a missing piece here. If you start several pigz > processes, the kernel only sees processes starting a lot of threads, and > processes only see a given number of cores. There is no interface that > allows a process to specify how to start more threads, giving the kernel > the opportunity to start them as it sees fit given the available number > of cores. You mean Scheduler Activations? There's a patch against linux 2.4 ;) We're definitely diving into OS research :) More seriously, I wouldn't see the kernel being able to "start" threads, that's painful to maintain (that's why the LinuxActivations patch hasn't been maintained). I'd rather see a way for the process to dynamically know how many processors it can currently expect (something like a /proc, /sys, /dev or whatever fd with notification), and arrange things according to that (starting/stopping worker threads for instance). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#511522: general: Man pages should say what package a program belongs to
Jack Grahl, le Sun 11 Jan 2009 19:56:52 +, a écrit : > If some program belongs to a package which does not have the same name > as the program, the man page for that command should say which package > the program is part of. Mmm, usually I just run dpkg -S bin/command, or better, dlocate bin/command Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
ITP: mbrola-{de6,es1,fr4,us1,us2} -- various voices for Mbrola
Hello,
Here is a list of ITPs for various mbrola voices.
Samuel
Bug#511973 ITP: mbrola-de6 -- German male voice for Mbrola
Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist
* Package name: mbrola-de6
Version : 0.0.20021125-1
Upstream Author : Faculte Polytechnique de Mons - mbrola team
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
Description : German male voice for Mbrola
This package contains a Germal diphone database provided in the context
of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
.
DE6 is a male German diphone voice created in the context of the EU project
NECA (IST-2000-28580), with the aim of being particularly suitable for the
flexible synthesis of expressive speech.
.
The main feature of DE6 is therefore that it contains a complete diphone
set for three different voice qualities defined by their vocal effort, low
effort ("soft voice"), medium effort ("normal or modal voice"), and high
effort ("loud voice").
.
This diphone database was recorded jointly by the Institute of Phonetics at
Saarland University and by the Language Technology Department at DFKI,
Saarbrücken.
Bug#511974: ITP: mbrola-es1 -- Spanish male voice for Mbrola
Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist
* Package name: mbrola-es1
Version : 0.0.19980610-1
Upstream Author : Faculte Polytechnique de Mons - mbrola team
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
Description : Spanish male voice for Mbrola
This package contains a Spanish diphone database provided in the context
of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
.
It provides a Spanish male voice to be used with the MBROLA program.
.
Input files use the SAMPA (SAM Phonetic Alphabet) notation as
recommended by the EEC-SAM Project, but with some minor changes.
Bug#511975: ITP: mbrola-fr4 -- French female voice for Mbrola
Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist
* Package name: mbrola-fr4
Version : 0.0.19990521-1
Upstream Author : Faculte Polytechnique de Mons - mbrola team
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
Description : French female voice for Mbrola
This package contains a French diphone database provided in the context
of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
.
It provides a French female voice to be used with the MBROLA program.
.
Input files use the SAMPA (SAM Phonetic Alphabet) notation as
recommended by the EEC-SAM Project.
Bug#511976: ITP: mbrola-us1 -- American English female voice for Mbrola
Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist
* Package name: mbrola-us1
Version : 0.3-1
Upstream Author : Faculte Polytechnique de Mons - mbrola team
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
Description : American English female voice for Mbrola
This package contains an English diphone database provided in the context
of the MBROLA project see: http://tcts.fpms.ac.be/synthesis/
.
It provides an American English female voice to be used with the MBROLA
program.
Bug#511977: ITP: mbrola-us2 -- American English male voice for Mbrola
Package: wnpp
Version: N/A; reported 2008-01-15
Severity: wishlist
* Package name: mbrola-us2
Version : 0.1-1
Upstream Author : Faculte Polytechnique de Mons - mbrola team
* URL : http://tcts.fpms.ac.be/synthesis
* License : see the file readme.txt in the source zip: non-free as in
without source code, and for non-commercial, non-military
purposes, with and only with the mbrola package made
available by the author.
Description : American English male voice for Mbrola
This package contains an English diphone database provided in t
Re: Bug#512136: Acknowledgement (ITP: nox -- nox -- Meta package)
Daniel Moerner, le Sun 18 Jan 2009 10:21:15 -0800, a écrit : > Something I don't quite understand is the target audience: most people > who run a command line install will know exactly what they want > installed, and won't need a metapackage to do it or to bring in > extraneous stuff. Actually I've bounced the ITP to debian-accessibility, as such meta-package could be useful to blind people starting to use a debian system from the console. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
Sjors Gielen, le Tue 20 Jan 2009 00:49:29 +0100, a écrit : > I'm working on a project porting the Debian tools to Cygwin. Ususally ports are hosted by debian-ports.org. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Hosting the Debian/kCygwin port?
Hello,
Just a comment about the debian-win32 project: I can read from the list
archive that the main issue was that the VFS doesn't allow to remove or
to overwrite through mv a file in use. IIRC that issue got fixed not so
many months ago in cygwin, and I can confirm that it now seems to work:
$ cat test.c
#include
int main(void) {
int fd = open("blip", O_RDONLY);
pause();
}
$ gcc test.c -o test
$ touch blip
$ ./test &
$ rm blip
$ touch blip
$ ./test &
$ touch blop
$ mv blop blip
So maybe debian-win32 could just be awaken since the barring issue seems gone?
Samuel
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Call for testing of RC2 images
Otavio Salvador, le Thu 29 Jan 2009 11:19:17 -0200, a écrit : > The Debian-CD Team has built the images based on RC2 installer and > I'd like to ask for some tests before we finally announce the release. > > The images are available at http://cdimage.debian.org/cdimage/.lenny_bibble/ Eergl, since loadlin's 1.6c.really1.6c.nobin-2 BYHAND, which was supposed to put back loadlin.exe into ftp://ftp.debian.org/debian/tools/, didn't get processed before that, RC2 doesn't even have a tools/ directory... Could please somebody please handle loadlin's BYHAND please? Thanks, Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#513632: ITP: liblouis -- Braille translation library
Package: wnpp Severity: wishlist Owner: Samuel Thibault * Package name: liblouis Version : 1.5.2 Upstream Author : John J. Boyer * URL : http://code.google.com/p/liblouis/ * License : LGPL Programming Lang: C, Python Description : Braille translation library Liblouis is a braille translator and back-translator. It features support for computer and literary braille, supports contracted and uncontracted translation for many languages and has support for hyphenation. New languages can easily be added through tables that support a rule- or dictionary based approach. Included are also tools for testing and debugging tables. Liblouis also supports math braille (Nemeth and Marburg). Samuel -- System Information: Debian Release: 5.0 APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
man-db's cron warns about dangling symlink
Hi, Short story: # apt-get install mpich-bin # dpkg -P mpich-bin # symlinks /usr/share/man/man1/ | grep dangling dangling: /usr/share/man/man1/clog2alog.1.gz -> /etc/alternatives/clog2alog.1.gz dangling: /usr/share/man/man1/upshot.1.gz -> /etc/alternatives/upshot.1.gz dangling: /usr/share/man/man1/clog_print.1.gz -> /etc/alternatives/clog_print.1.gz dangling: /usr/share/man/man1/mpirun.1.gz -> /etc/alternatives/mpirun.1.gz etc. And the result is that when man-db gets run from cron, it sends the following mail: /etc/cron.daily/man-db: mandb: warning: /usr/share/man/man1/clog2alog.1.gz is a dangling symlink mandb: warning: /usr/share/man/man1/upshot.1.gz is a dangling symlink mandb: warning: /usr/share/man/man1/clog_print.1.gz is a dangling symlink mandb: warning: /usr/share/man/man1/mpirun.1.gz is a dangling symlink etc. The bug is that although the mpich-bin package uses update-alternatives --install on postinst for all these files, it uses update-alternatives --remove only on /usr/lib/mpich/bin/mpirun, leaving a bunch of dangling symlinks... The reason why I'm mailing debian-devel is that I've seen this behavior quite often in the past, in various packages. I hence guess there should be some automatic way to check that a package correctly removes the alternatives it provides. Samuel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Xen support on Squeeze
Brian May, le Sun 03 Jan 2010 16:48:06 +1100, a écrit : > On Sun, Jan 03, 2010 at 12:47:54PM +0800, Paul Wise wrote: > > On Sun, Jan 3, 2010 at 9:01 AM, Brian May wrote: > > > > > 1) I believe Xen, with paravirtualization (that is without QEMU) is more > > > secure > > > then KVM (or Xen) with QEMU. > > > > I haven't heard this claim before, do you have any references to support > > this? > > http://blog.orebokech.com/2007/05/xen-security-or-lack-thereof.html links to > http://taviso.decsystem.org/virtsec.pdf. BTW, nowadays Xen is able to start qemu in stubdomains to sandbox it. That is however not yet packaged in Debian. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: hurd and SA_SIGINFO
Camm Maguire, le Thu 07 Jan 2010 12:00:11 -0500, a écrit : > 1) What is the release candidate status of hurd-i386? It's not ready yet, surely not for Squeeze anyway. > Can I ignore FTBFS errors there for now? Yes, but when it's easy to fix them, please do. > 2) The sigaction flags are not found anywhere on the porterbox, though > they are mentioned in the sigaction man page. Yes, actually GNU/Hurd provides its own signal information structure (which was coined before sigaction, apparently). I started adding the sigaction interface but hasn't finished yet. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : > * Package name: pthsem Mmm, could this perhaps rather be just a patch added to the existing pth package? Else you'll have to share the Debian patches. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler, le Tue 19 Jan 2010 09:27:07 +0100, a écrit : > Samuel Thibault wrote: > > Marc Leeman, le Sun 17 Jan 2010 22:16:17 +0100, a écrit : > > > * Package name: pthsem > > > > Mmm, could this perhaps rather be just a patch added to the existing pth > > package? Else you'll have to share the Debian patches. > > The situation with GNU pth is: I guessed so, but still. The problem is that people know pth, but they don't know pthsem (yet). It will be a long time before people discover that there is a new interesting pthsem package that basically does the same as pth with quite a few extra features, is not dead etc. Why not just replacing the existing pth package with pthsem to avoid that delay? Were I Martin Kögler, I'd even just request GNU to become the new maintainer of pth. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [gmail] Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Julien Cristau, le Wed 20 Jan 2010 22:06:21 +0100, a écrit : > I'm not sure we care if its homepage is at GNU or elsewhere. Agreed, thanks free software :) Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#565675: ITP: pthsem -- pth replacement with semaphore support
Martin Koegler, le Wed 20 Jan 2010 23:04:07 +0100, a écrit : > On Wed, Jan 20, 2010 at 10:06:21PM +0100, Julien Cristau wrote: > > On Wed, Jan 20, 2010 at 21:04:30 +0100, Marc Leeman wrote: > > > > > > I need pthsem, so I only want a working version with all features I > > > > need. > > > > > > All I care about is that there is an agreement between the Debian > > > community and the upstream developer. Martin is very active in > > > supporting his environment and in that respect I am to inclined to > > > support his decision. > > > > > > Can we conclude that pthsem is a valid branch, worth a seperate package? > > > > > > An alternative for Martin is probably to include/hide pthsem in bcusdk; > > > but that would not be as clean IMHO (ffmpeg anyone?) > > > > > If pthsem is pth + improvements, and pth is unmaintained both upstream > > and in Debian, what's the advantage of changing the library/package > > name? I'm not sure we care if its homepage is at GNU or elsewhere. > > I have no problem with renaming pthsem into pth, if this is wanted by > the "community". I don't want to do a hostile takeover of pth. That's why you should discuss with GNU. As said in another post, you can just ask them to say on their website that they do not maintain it any more, and point to your page. > But this needs coordination with the other distributions shipping pth. With the link mentioned above, that's no problem. > If one of the big distributions says no and still ships GNU pth, it > will only cause confusion. Agreed. > I will not call the result "GNU pth", only pth. Calling it GNU will > probably only add restrictions/requirements, without any benefit. Right. People often know "pth" short anyway. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Xen, Squeeze, and Beyond
Marco d'Itri, le Fri 26 Feb 2010 02:38:33 +0100, a écrit : > On Feb 25, John Goerzen wrote: > > 3a) What about Linux virtualization on servers that lack hardware > > virtualization support, which Xen supports but KVM doesn't? > Tough luck. > > > 6) Are we communicating this to Debian users in some way? What can I do > > to help with this point? > Remind people that Xen is dying and KVM is the present and the future. No FUD, thanks. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100226100657.ga3...@const.homenet.telecomitalia.it
Re: Bug#571754: strftime("%c") crashes in (some) locations
Klaus Ethgen, le Sun 28 Feb 2010 14:41:27 +0100, a écrit : > Am So den 28. Feb 2010 um 14:24 schrieb Aurelien Jarno: > > Yes, and I explained you why your code is wrong. > > A part, which was not related to the bug itself. The bug was not explained at all except the output of a buggy program :) Never forget, in a bug report, to tell what you get, and what you expect to get. None of the two are always obvious (especially when it comes to i18n). Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100228134744.gj11...@const.famille.thibault.fr
Re: sensible-mailer
Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : > I'd like to propose a `sensible-mailer' command. Well, there is /etc/alternatives/mailx Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305141026.gj14...@const.bordeaux.inria.fr
Re: sensible-mailer
Harald Braumann, le Fri 05 Mar 2010 15:47:02 +0100, a écrit : > On Fri, Mar 05, 2010 at 03:10:26PM +0100, Samuel Thibault wrote: > > Harald Braumann, le Fri 05 Mar 2010 15:06:28 +0100, a écrit : > > > I'd like to propose a `sensible-mailer' command. > > > > Well, there is /etc/alternatives/mailx > > You can't set, e.g., mutt as an alternative. That could be fixed. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100305145229.gn14...@const.bordeaux.inria.fr
Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8
Petter Reinholdtsen, le Tue 23 Mar 2010 15:33:22 +0100, a écrit : > > [Nicolas François] > > As I have no clue about TTY setup, let see if I can get some other > > opinions on debian-devel. > > > > The question raised on http://bugs.debian.org/547079 is who shall be > > responsible for setting up the user's tty (e.g. regarding UTF-8 handling). > > This sound related to http://bugs.debian.org/547073 >, fixed in > sysvinit. in version 2.87dsf-7. Init now leave it to the kernel to > set the utf-8 flag. Perhaps login should do the same? See my concern in the bug report: “My concern is that getty used to not keep any flag at all. Keeping _some_ flags contrary to none is not just a "fix", it's a change of behavior. Think for instance about a situation where a user clears the tty's iutf8. The next user to log in will have a bogus terminal since getty would leave it cleared and nothing else will set it. This is the same for all the flags, getty could just keep the kernel's current state, but it doesn't. [...] Letting a user break another user's environment is wrong” Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100323161842.ga5...@const.bordeaux.inria.fr
Re: Xen, Squeeze, and Beyond
John Goerzen, le Wed 24 Mar 2010 09:19:24 -0500, a écrit : > I've just noticed that HVM guests (such as Windows) are broken in Xen in > squeeze due to the lack of qemu-dm (see #562703). Any word on plans for > that? Finding somebody that has the time to mentor an upload for Thomas Goirand, see http://ftparchive.gplhost.com/debian/pool/lenny/main/x/xen-qemu-dm-3.4/xen-qemu-dm-3.4_3.4.2-1.dsc Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100324161605.gr4...@const.bordeaux.inria.fr
Re: Bug#547079: login: Should set the iutf8 tty c_iflag if the locale is utf8
Nicolas François, le Tue 23 Mar 2010 23:59:29 +0100, a écrit : > Is it an issue to set the utf8 flag too often? > (does it break something?, It has the converse effect as forgetting it, cf the original bug report: “ATM, if one runs cat from a VT with a UTF-8 locale, type a non-ascii character, backspace, enter, the first byte of the utf-8 encoding non-ascii will remain in the stream.” The converse would be “with utf8 spuriously set, if one runs cat from a VT with a non-UTF-8 locale, type a character, then a non-ascii character, backspace, enter, the first character is dropped from the stream”. That's not so much a big deal (that is why nobody bothered to fix the reported bug up to now), but it's still bogus (the other way round). > does it affect performances?) The performance hit is very tiny: just a couple of additional tests in the kernel. > Also, can you elaborate on your solution. Who would configure what and how? I don't know enough the pam stack to know whether my solution is even feasible. My point is that it there are at least two cases that need to be considered: - getty/login on a VT. - getty/login on a serial port. Both could be independently using utf-8 or not. In the first case, getty could use ioctl(KDGKBMODE) to know whether the VT keyboard is configured in UTF-8 mode or not, and set the IUTF8 flag appropriately. That brings Linux-specific code to getty which for now was quite OS-independent, but well. In the second case, however, getty can not use ioctl(KDGKBMODE), since only the other end of the serial cable knows whether it's using utf-8 or not. The locale setting, however, has very probably been properly set up by the user or the administrator and could be used as the source of information for setting UTF-8 mode or not. That is why I thought about setting it at the login/pam level, where I believed the locale information is available, which captures both cases. I had asked util-li...@packages.debian.org for what they think about it, and never got an answer. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100325132251.gg5...@const.bordeaux.inria.fr
Re: Bits from the Release Team: Scheduling, transitions, how to help
Adam D. Barratt, le Thu 01 Apr 2010 09:57:12 +0200, a écrit : > * GNU/kFreeBSD-* > The release of these two new architectures looks promising, but they > are still far away from full archive coverage. It seems that much > could be gained by fixing some key packages. What is the target BTW? Just remind a remark I made some time ago (august 2008): “in the Failed part of hurd-i386, 178 packages out of 1320 fail at least because of inclusion of #include (there could be other [packages of this type] hidden by other compilation problems). That's 2.29% of the 7748 packages in our wanna-build database!... And we still have 1952 packages in the dep-wait state, a lot of them probably include too...” Some updated figures: now this is 220 packages out of 1404 failed, out of total 8560, which thus makes 2.33%. On top of that, 31 (0.31%) can be added that use . So in a word it could be estimated that at least 5% of the packages do some #include already. Of course there are a lot more other kinds of issues. That's why I'm afraid just fixing some key packages won't be enough, all maintainers should get involved. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100401101751.gf4...@const.bordeaux.inria.fr
Re: Default value of net.ipv6.bindv6only should revert to 0
Hendrik Sattler, le Thu 08 Apr 2010 12:38:36 +0200, a écrit : > Zitat von Salvo Tomaselli : > >>I also don't really see the issues with bindv6only=0. If you listen on > >>all interfaces, it makes is easier. If you only listen on specific > >>interfaces, it's not in the way. > >The problem is that freebsd has bindv6only=1 by default, but i personally > >think it is a bug in the kernel. > > We are discussing this for linux, not freebsd, don't we? We are discussing this for Debian first, which hopefully will ship with the possibility to use a FreeBSD kernel. Samuel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100408110052.gw5...@const.bordeaux.inria.fr
