Re: Paquet d'un binaire contenant une librairie
Le 24/07/03 à 11:57 Frédéric Bothamy ([EMAIL PROTECTED]) écrivait : several binary packages.. Il faudrait donc séparer le paquet en 2 : un paquet k3b et un paquet libk3bcore provenant du même paquet source et avec des dépendances adaptées. Oui, mais la lib ne sera utilisé que pour k3b et rien d'autre. C'est pour ça je pense que le paquet kdebase-bin inclus des lib. -- Jean-Michel Kelbert
Re: Paquet d'un binaire contenant une librairie
Le jeu 24/07/2003 à 12:15, Jean-Michel Kelbert a écrit : Le 24/07/03 à 11:57 Frédéric Bothamy ([EMAIL PROTECTED]) écrivait : several binary packages.. Il faudrait donc séparer le paquet en 2 : un paquet k3b et un paquet libk3bcore provenant du même paquet source et avec des dépendances adaptées. Oui, mais la lib ne sera utilisé que pour k3b et rien d'autre. C'est pour ça je pense que le paquet kdebase-bin inclus des lib. Ce n'est pas parce que d'autres font mal les choses qu'il faut les imiter :) Je pense qu'il faut éviter de se poser des questions, et faire un paquet par lib partagée. Il faut absolument éviter que les désastres de mozilla et de libvorbis se reproduisent ailleurs. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: Paquet d'un binaire contenant une librairie
Christian Perrier (2003-07-24 13:32:28 +0200) : Quoting Jean-Michel Kelbert ([EMAIL PROTECTED]): version comporte désormais une librairie : libk3bcore : une bibliothèque, tu veux dire, non ? :-) -- Do not feed the trolls Pourquoi ? Tu n'as plus faim ? (Et bim ! :-) Roland. -- Roland Mas Shyumiribirikku ga susunde imashyou ka ? -- Le Schmilblick en japonais
Re: Future releases of Debian
On Wed, Jul 23, 2003 at 06:17:25PM -0400, Matt Zimmerman wrote: On Thu, Jul 24, 2003 at 04:50:06AM +1000, Anthony Towns wrote: For example, I tend to buy cheap hardware wherever possible, especially for running desktop Linux since they're generally much faster than I need anyway; but this means I tend to get built-in graphics, networking and so forth. Most of which tend to be supported on Linux, but only by the latest versions of X and the kernel. Where I come from, cheap hardware is old hardware, and old hardware has much better support in Linux (and Debian) than new hardware. Where I come from, old hardware is unreliable hardware. It's great that Debian works fine for you, but that doesn't mean everyone else can just do the exact same things you do and be as satisfied. Different circumstances, and different goals, and all that. Is there any chance we can accept that Debian does have a vast range of problems (like unpredictable release schedules, a lack of security updates for testing, and a lack of currency in unstable for a fair number of packages including X), and work on fixing them rather than having to continually argue about why they're necessary to fix and why we shouldn't just sweep them under the rug and hope no one notices? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpoJdjIOZXhG.pgp Description: PGP signature
Re: May packages rm -rf subdirectories of /etc/ ?
Herbert == Herbert Xu [EMAIL PROTECTED] writes: Herbert Unfortunately dpkg does not handle the case where a Herbert conffile ceases to exist in a later version of a package. Herbert The conffile will be left on the system even after Herbert purging. That's why packages have maintainers and postrm scripts. -- Stephen So if she weighs the same as a duck, she's made of wood And therefore?... A witch!
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 11:26:58 +0200, Tollef Fog Heen wrote: * Christoph Hellwig | On Wed, Jul 23, 2003 at 02:09:28PM +1000, Martin Pool wrote: | There is already a PAM modules, libpam-tmpdir which automatically sets | this up on login by creating a per-user directory under /tmp and | pointing TMPDIR at it. Despite the scary low version number of 0.04 | it seems to work reliably and presumably any bugs could be fixed. | | Nice idea, wrong implementation. Let login fork the login shell with | CLONE_NEWNS and do a VFS-binding from ~/tmp to /tmp. Presumably you'd want to add this through a PAM module rather than hacking it right into login, otherwise gdm, ssh etc wouldn't be consistent. Having decided to do it through PAM, is it really necessary to change the VFS rather than setting $TMPDIR? Making it impossible to get to the real /tmp makes it a bit more intrusive and potentially confusing than really seems necessary. Given that there is a TMPDIR variable which is obeyed in most cases, using it seems to be easier than remapping /tmp. Fixing programs which are hardcoded to /tmp to use TMPDIR is pretty trivial. Making sure that operations in a world-writable directory are secure can be very hard. A PAM module which does VFS setup would be pretty cool, but I don't think that's the one Debian should use by default. CLONE_NEWNS is 2.4.19 and higher only. Also, ~ might be on NFS or similar where you don't want to put temporary files. (And about the version number of libpam-tmpdir: it could just as easy have been 0.4, in which case nobody would have thought it was «scaringly low». Yes, I'm upstream for it.) Thanks for writing it. I couldn't find any web pages about libpam-tmpdir other than the Debian package. It might be nice to put up just a small one so that it's easier for other systems to find. If we were to put it in as default, I'd like to clean up the code a bit.. it should be safe, but it could use a little tidying up. There are small issues I'll discuss offline. I'm not sure if this is featurism, but you might add a parameter to allow people to set the path. /tmp/users/$uid/ is a good default but people might possibly want it in /home or elsewhere for disk space or other reasons. -- Martin
Re: proposal: per-user temporary directories on by default?
On Wed, 23 Jul 2003 17:14:09 -0400, Joey Hess wrote: Martin Pool wrote: At the least I would like to see Debian prompt for this at installation much as it does for shadow passwords. Ideally it would be on by default. I'm all for this idea. Thanks. What needs to be done to have it adopted? Since I use static per-user in home tmp directories I have not looked at libpam-tmpdir though. I suppose that enabling it currently requires making some modifications to many of the pam.d files? Yes, it does. This is a slight problem: it would be nice if there were a way to say this session module should apply to all services, but I don't think there's any way to do that in PAM. It could be done in either libpam or a Debian script that generates the files, but it's not strictly needed. For the time being I suppose it could just be applied to the services for which it is most relevant: login, ssh, gdm, kdm, xdm, etc. -- Martin
,! 14:1:16:
:[EMAIL PROTECTED] OCRWORD A4 A4A4;20/ 100; : A3 A3A3;80/ 300; 0755-2608861326088616 * [EMAIL PROTECTED] -- 86-755-26088616 [EMAIL PROTECTED] --
Re: coreutils with selinux support
On Wed, 2003-07-23 at 17:58, Brian May wrote: On Wed, Jul 23, 2003 at 11:58:33AM -0400, Michael Stone wrote: On Wed, Jul 23, 2003 at 09:43:17AM -0400, Clint Adams wrote: How about selinux support? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=193328 SE-Linux support would be good. There is also the question of which patch to apply; there are two very different ones for 2.4 SELinux and 2.5 SELinux. For this reason at least it's probably worth just waiting until 2.6 comes out and is more widely used, and we can just drop support for 2.4 from unstable.
Re: Excessive wait for DAM - something needs to be done
On Sun, Jul 13, 2003 at 01:09:47PM -0600, Jamin W. Collins wrote: 2001-01-24 - Dwayne Litzenberger [EMAIL PROTECTED] http://nm.debian.org/nmstatus.php?email=dlitz%40dlitz.net For the record, I'm still interested in becoming a DD. Nice to see this finally being addressed! Thanks! -- Dwayne C. Litzenberger [EMAIL PROTECTED] The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpX247j9tNP8.pgp Description: PGP signature
Cosing ITA bugs when you've changed your mind.
reopen 180993 ! thanks Luca - De Whiskey's - De Vitis wrote: I've never agreed to leave phpgroupware to any maintainer, and i'm now back and actively working on my package, so I'm closing this report. You have RFA'd phpgroupware and I've ITA'd it. Waiting until the ugly work (i.e. the security update to stable) is getting done by others and then popping back out of your hole to say April fools is not acceptable. Your maintainance of phpGroupWare has been limited to yelling at people wanting to finally do something about the embarrassingly poor state of Debian packages, and it's time to let that go. [0] (In private mail, one of the upstream developers who uses Debian told me that he would not use those debs, even if someone paid [him], I've been getting private mails form other users with the same bad experience with phpgroupware.) Maybe you are one of the examples on why the NM process isn't thorough (slow) enough at present. If you cannot incorporate a simple patch in BTS fixing RC bugs into your packages [1], how will you collaborate using alioth? Ever wondered why your appeals for cooperation have no response? Look at #164354. Have I ever received a response to my offer to help (along with patch) in #183896? No. Cheers T. 0. See http://bugs.debian.org/164354 http://bugs.debian.org/phpgroupware (esp. #183896) http://lists.debian.org/debian-mentors/2003/debian-mentors-200306/msg00049.html 1. http://bugs.debian.org/183896 pgpnaYhg62CMw.pgp Description: PGP signature
Re: May packages rm -rf subdirectories of /etc/ ?
Stephen Zander [EMAIL PROTECTED] wrote: Herbert == Herbert Xu [EMAIL PROTECTED] writes: Unfortunately dpkg does not handle the case where a conffile ceases to exist in a later version of a package. The conffile will be left on the system even after purging. That's why packages have maintainers and postrm scripts. It really sucks to handle this if you want/need to get rid of it (if it is unmodified) not only on purge but on upgrades. - You'll need if [ $1 = configure ] \ dpkg --compare-versions $2 le-nl 1.2.3 \ [ -e /etc/foo ] \ [ `md5sum /etc/foo | cut -d\ -f1` = 6bea09fbb18e4676012105fa5fc726c6 ] then echo Removing orphaned unmodified configfile /etc/foo 12 rm /etc/foo fi And not only one of these, but one for every version of /etc/foo you ever shipped (you want to provide smooth upgrades from 1.2.3, 4.5.6 _and_ 4.5.7. dpkg OTOH does know the md5sum of the last (un)installed version and does not need a hard-coded lists in postinst. cu andreas
Re: Cosing ITA bugs when you've changed your mind.
On Thu, Jul 24, 2003 at 08:27:06AM +0200, Thomas Viehmann wrote: You have RFA'd phpgroupware and I've ITA'd it. Waiting until the ugly work (i.e. the security update to stable) is getting done by others and then popping back out of your hole to say April fools is not acceptable. Your maintainance of phpGroupWare has been limited to yelling at people wanting to finally do something about the embarrassingly poor state of Debian packages, and it's time to let that go. [0] (In private mail, one of the upstream developers who uses Debian told me that he would not use those debs, even if someone paid [him], I've been getting private mails form other users with the same bad experience with phpgroupware.) Maybe you are one of the examples on why the NM process isn't thorough (slow) enough at present. Your ideas of hindering people contributing is a non-sense i've already told you. There is no benefit in this for anyone. We have never discussed about your adoption of phpgroupware, so i don't see why you felt free to adopt it. I've already told you, and i'm writing it publically, that an infrastructure to cooperate is up in place and i've already told you i would have let you contribute beside your almost intent to hijack. I wrote it publically in _many_ ways i wanted people to help me, but the only answares i got was to take over the packges (and many fake intent to contribute). This really make me sick. If you cannot incorporate a simple patch in BTS fixing RC bugs into your packages [1], how will you collaborate using alioth? I would let people apply their patch to the cvs directly being able to catch diffs and reviewing work and seeing people really contribute. Ever wondered why your appeals for cooperation have no response? Look at #164354. Have I ever received a response to my offer to help (along with patch) in #183896? No. You still do not understand what is being busy might mean (apart the fact that you patch didn't provide a real solution to the bug). I don't know how to demonstrate any more that your opinon about me are faulty. I supposed my self to be the last person who would not let people work with me. I'm still here saying that i'll be happy to cooperate and let you in, but i'm wandering if i'm doing the right thing. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpSwDLH1yhE5.pgp Description: PGP signature
Re: Cosing ITA bugs when you've changed your mind.
Luca - De Whiskey's - De Vitis wrote: On Thu, Jul 24, 2003 at 08:27:06AM +0200, Thomas Viehmann wrote: You have RFA'd phpgroupware and I've ITA'd it. Waiting until the ugly work (i.e. the security update to stable) is getting done by others and then popping back out of your hole to say April fools is not acceptable. Your maintainance of phpGroupWare has been limited to yelling at people wanting to finally do something about the embarrassingly poor state of Debian packages, and it's time to let that go. [0] (In private mail, one of the upstream developers who uses Debian told me that he would not use those debs, even if someone paid [him], I've been getting private mails form other users with the same bad experience with phpgroupware.) Maybe you are one of the examples on why the NM process isn't thorough (slow) enough at present. Your ideas of hindering people contributing is a non-sense i've already told you. There is no benefit in this for anyone. We have never discussed about your adoption of phpgroupware, so i don't see why you felt free to adopt it. I've already told you, and i'm writing it publically, that an infrastructure to cooperate is up in place and i've already told you i would have let you contribute beside your almost intent to hijack. I wrote it publically in _many_ ways i wanted people to help me, but the only answares i got was to take over the packges (and many fake intent to contribute). This really make me sick. Maybe he was confused and thought that you wanted someone to adopt phpgroupware because you'd filed a Request For Adoption on it? -- Keith
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 08:47, Andreas Metzler wrote: It really sucks to handle this if you want/need to get rid of it (if it is unmodified) not only on purge but on upgrades. - You'll need if [ $1 = configure ] \ dpkg --compare-versions $2 le-nl 1.2.3 \ [ -e /etc/foo ] \ [ `md5sum /etc/foo | cut -d\ -f1` = 6bea09fbb18e4676012105fa5fc726c6 ] then echo Removing orphaned unmodified configfile /etc/foo 12 rm /etc/foo fi In a discussion that followed from this thread off-list, some people agreed that the administrator should be asked what he or she wants to do with an obsolete conffile. The conffile should not be deleted silently because other packages may be using the file. Here is how I see it. On install of the new version of foo which lacks the former foo conffile /etc/foo.conf, * dpkg informs the user that /etc/foo.conf is no longer a conffile of foo; * dpkg says whether or not /etc/foo.conf was changed from the original; * dpkg offers to display the file, to start a shell so that the user can check things out, or to do one of three things to the file: * leave the file as it is (= the current behavior), * delete the file (= the default if the file has not been changed), or, * rename the file to /etc/foo.conf.dpkg-old (= the default if the file has been changed) -- Thomas
Re: Future releases of Debian
Martin Pitt (2003-07-23 17:57:10 +0200) : [...] Besides, what's so bad with the current boot-floppies that they could not be used for another release? They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) Roland. -- Roland Mas ar c t e l l ièu ai ia mi. -- Signatures à collectionner, série n°1, partie 2/3.
Re: mplayer 0.90, was Re: why mplayer not in Debian
Hi, Sam Hocevar wrote:
(statically linked for performance reasons, rotfl)
Well, when the glibc people had this discussion (the switch to ELF), the
performance penalty was found to be on the order of 5%.
I don't know whether modern CPUs' register aliasing hardware changes that
number.
Whether you consider that legitimate, or a fib, is up to you, but I'd say
that the class of machines where this would be right on the line between
real-time performance or not certainly isn't empty.
I don't know whether modern CPUs' register aliasing hardware changes that
number.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
One of the most striking defferences between a cat and a lie is that a cat has
only nine lives.
Re: mplayer 0.90, was Re: why mplayer not in Debian
On Thu, Jul 24, 2003 at 10:18:22AM +0200, Matthias Urlichs wrote: Hi, Sam Hocevar wrote: (statically linked for performance reasons, rotfl) Well, when the glibc people had this discussion (the switch to ELF), the performance penalty was found to be on the order of 5%. I don't know whether modern CPUs' register aliasing hardware changes that number. On anything more recent than a 486, the answer is not a percentage, it's a research paper. Just to _describe_ the performance implications. And it's a different paper for each processor. On something like ia64, I don't think anybody even knows. At least, I've never seen a study of it. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpN2Ns3W4u8l.pgp Description: PGP signature
Re: mplayer 0.90, was Re: why mplayer not in Debian
Hi, Andrew Suffield wrote:
On Thu, Jul 24, 2003 at 10:18:22AM +0200, Matthias Urlichs wrote:
Well, when the glibc people had this discussion (the switch to ELF),
the performance penalty was found to be on the order of 5%.
... by testing with somewhat typical programs.
I don't know whether modern CPUs' register aliasing hardware changes
that number.
On anything more recent than a 486, the answer is not a percentage,
It is -- if you do the same tests, and compare.
it's a research paper. Just to _describe_ the performance implications.
... assuming you want to translate the results to a different set of
tests.
... or, for that matter, if you want to interpret the variance you'll get
in the test results, assuming it's significant, which it probably will be.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Television has brought back murder into the home -- where it belongs.
-- Alfred Hitchcock
Re: Bug#201023: dosemu: purging doesmu wipes out all user data
Hi, Roger Leigh wrote:
For several reasons, it's not possible to know in advance how many files
will be created, or what their names will be, so rm -rf is
appropriate.
For packages like dosemu, this is not (currently) appropriate. There is
no technially valid reason for doing this, since the conffiles and
symlinks that might exist are known by name.
Does that make sense, from a user's point of view? We should have a
concise set of rules WRT what may or may not be deleted, without regard to
whether packages are natively able to keep track of whatever files they
generate.
If the action taken for a specific location isn't what the user would
want, then the files are simply misplaced.
On the technical side, you could as well argue that the actual list of
PPDs isn't known, but the _possible_ names are known, and you could filter
your removal action against that list. And even in cases where this isn't
so, tracking the names of generated files in a special log file won't be
too much of a burden.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
You clever dog!
Re: Future releases of Debian
#include hallo.h * Roland Mas [Thu, Jul 24 2003, 10:11:18AM]: Besides, what's so bad with the current boot-floppies that they could not be used for another release? They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) And here a decission has to be made: releasing with not-sympatic-for-so-called-new-users BFs in 2003 or with stable D-I one year later. In my humble opinion, BFs and D-I share essential problems, lack of motivated developers on non-x86 hardware is one of them. MfG, Eduard.
Re: Using reportbug with Gnus
Peter S Galbraith [EMAIL PROTECTED] wrote: Marcus Frings [EMAIL PROTECTED] wrote: * [EMAIL PROTECTED] (Aaron M. Ucko) wrote: Incidentally, you might also be interested in debbugs-el, which provides a nice report-debian-bug command. Thanks for the hint. I'll give it a try! That would be `M-x debian-bug'. :-) You might also like `M-x debian-bts-control' to send control messages to the BTS. That's in the `dpkg-dev-el' package. I use both with Mew and they are very good ;) Very good job! ;) -- Arnaud Vandyck http://alioth.debian.org/users/arnaud-guest/
Re: Future releases of Debian
Hi! Am 2003-07-24 12:03 +0200 schrieb Eduard Bloch: Besides, what's so bad with the current boot-floppies that they could not be used for another release? They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) And here a decission has to be made: releasing with not-sympatic-for-so-called-new-users BFs in 2003 or with stable D-I one year later. The former would satisfy the users who have already installed Debian (where it is a matter of a mere apt-get dist-upgrade ) and may not appeal to potential new users. Whereas the latter alternative (waiting for a mature D-I) would not be of any help to _both_ groups. IMHO we should try _not_ to deceive as many users as possible. Have a nice day! Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: po-debconf patches and woody backportability (was: Re: [VAC] 25 july - 26 august)
On Thu, Jul 24, 2003 at 10:46:02AM +0200, Christian Perrier wrote:
(this may be quoted outside -private..possible followups belong to
-develI never remember the correct method for moving a thread out
of -private)
Moved to -devel, then, and copied to -i18n because people there are
probably often involved in patching for po-debconf.
Quoting Colin Watson ([EMAIL PROTECTED]):
Would it be possible for such patches to be routinely produced in a way
that preserves the ability to build easily on woody, particularly for
packages in base? The openssh package has a technique for doing this
which you could probably reuse practically verbatim.
You're right?: this may be an argument which prevents maintainers to
adopt the currently sent please switch to gettext-based debconf
templates patch.
Most maintainers, usually motivated and active maintainers (?:-)) try
to keep their packages easy to backport.
.../...
I'm looking at openssh's method?: it basically uses po2debconf on a
master file prior to dh_installdebconf. That's probably the
simpliest thing to doexcept that po-debconf doesn't exist on
woody.how is this solved for woody backports of openssh??
The idea behind the openssh scheme is that the maintainer (or whoever's
building the package for upload to unstable) has to build on a machine
with po-debconf installed, but nobody else does.
When building with po-debconf, a format 1 (no encoding specifications,
woody-compatible) debian/templates file is generated in the clean target
and shipped in the source package, but a format 2 (UTF8-encoded,
woody-incompatible) debian/templates file is generated in binary-arch
for the binary package only.
When building without po-debconf, the binary package simply reuses the
woody-compatible debian/templates file that was produced by the clean
target of the maintainer's build.
This requires the following code:
ifeq (,$(wildcard /usr/bin/po2debconf))
PO2DEBCONF := no
MINDEBCONFVER := 0.5
else
PO2DEBCONF := yes
MINDEBCONFVER := 1.2.0
endif
clean:
[...]
ifeq ($(PO2DEBCONF),yes)
# Hack for woody compatibility. This makes sure that the
# debian/templates file shipped in the source package doesn't
# specify encodings, which woody's debconf can't handle. If building
# on a system with po-debconf installed (conveniently debhelper (=
# 4.1.16) depends on it), the binary-arch target will generate a
# better version for sarge.
echo 1 debian/po/output
po2debconf debian/templates.master debian/templates
rm -f debian/po/output
endif
[...]
binary-arch:
[...]
ifeq ($(PO2DEBCONF),yes)
po2debconf -e utf8 debian/templates.master debian/templates
endif
[...]
dh_gencontrol -- -V'debconf-depends=debconf (= $(MINDEBCONFVER))'
[...]
debian/control has ${debconf-depends} in the appropriate Depends: line.
This approach is a little more complicated, but it seems very robust in
practice, and makes backports perfectly smooth. I recommend it for
people converting packages to po-debconf before the release of sarge.
Cheers,
--
Colin Watson [EMAIL PROTECTED]
Re: Future releases of Debian
Eduard Bloch (2003-07-24 12:03:24 +0200) : [...] And here a decission has to be made: releasing with not-sympatic-for-so-called-new-users BFs in 2003 or with stable D-I one year later. This sounds exactly like the decision that was taken two years ago, resulting in having to fix the boot-floppies system (and in taking one more year to release). Don't let's repeat the past mistakes. Besides, sticking with b-f means we're on our own. Switching to d-i for real means we can get help from Skolelinux and Linex and probably many other custom Debian projects. Roland. -- Roland Mas La tradition orale, c'est comme un vieux fromage [...] -- Le Blaire -- Signatures à collectionner, série n°2, partie 1/3.
Re: Future releases of Debian
On Jul 23, Anthony Towns aj@azure.humbug.org.au wrote: (On the other hand, if you really want a shorter release cycle, there's always testing, which releases every day. All it really needs for us to be able to recommend people use it is security updates...) Did you actually try to use current testing? The status of gnome is very sad, it's a mix of gnome 1 and 2 package which do not work well together, I had to upgrade to unstable to have a working desktop. -- ciao, | Marco | [977 maScO0V5EP2nc] pgpVEC8EZgWBn.pgp Description: PGP signature
Re: Future releases of Debian
On Jul 24, Eduard Bloch [EMAIL PROTECTED] wrote: In my humble opinion, BFs and D-I share essential problems, lack of motivated developers on non-x86 hardware is one of them. Then the solutions should be not releasing these architectures if nobody is interested to work on them, not slowing down everything for all. It's very disappointing working on a package and then having it stuck in unstable because of problems with some useless architecture like arm or m68k. -- ciao, | Marco | [978 poHe4gf80pmAM]
Re: po-debconf patches and woody backportability (was: Re: [VAC] 25 july - 26 august)
Quoting Colin Watson ([EMAIL PROTECTED]): This approach is a little more complicated, but it seems very robust in practice, and makes backports perfectly smooth. I recommend it for people converting packages to po-debconf before the release of sarge. This is a very interesting approach. I will certainly adopt it for my own package which uses (po-)debconf (geneweb). On the other hand, I'm quite skeptic for adding these changes to the po-debconf switch bugs. This would make these patches quite intimidating for the average DD (no offense herethis is based on the input I often receive after sending those bugs)and would probably delay (or even prevent) the adoption of the patch... This would also slow down a lot the systematic work we're doing : we produce patches which need to be adapted to each package...this is a *manual* work...and we try to do correct work. The first goal of the BR we send (this includes myself, but also Michel Grentzinger, Andre Luis Lopes and probably others) is having as many DD as possible, who currently use debconf, go towards po-debconf in order to speed up the translation process. 100% use of gettext'ed templates for user input is The Targetbecause this is one of the keys for 100% translated user input. We currently do not have statistics about the delay between the BR and the po-debconf adoption by the maintainer. I keep a record of the debian-l10n-french team in this particular field...but as soon as a package has switched, I drop the corresponding entry We only have a subjective feeling : -translation only bugs are mostly quickly closed (this concerns packages already using po-debconf, for which we just send a translated file) -po-debconf switch bugs take significantly longer to be closed. Of course, they are more invasive bugs, so that's perfectly understandable... This is why I think than even more invasive bugs would probably frighten some DD's :-) (not counting all people with sophisticated methods for repetitive templates generation, or people who do not want to use debhelper because hand-crafted unreadable scripts are better and so on.. :-)) I'm considering adding a mention to the standard text we currently use. This mention woudl then be compething like this : Please note that the suggested modifications will make your package a little bit harder to backport to earlier Debian releases. If this is a concern to you, you may try to adopt the method used by the openssh package and detailed by Colin Watson in http://lists.debian.org/debian-i18n/2003/debian-i18n-200307/msg00026.html;
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
* Thomas Hood ([EMAIL PROTECTED]) wrote: In a discussion that followed from this thread off-list, some people agreed that the administrator should be asked what he or she wants to do with an obsolete conffile. The conffile should not be deleted silently because other packages may be using the file. I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this, if it's not, ditto. If it's not shared then it should be removed and the user doesn't really need to be asked unless removing it would affect their configuration (not likely if it hasn't been modified and has now been obsoleted). I have exactly this situation with slapd and plan to be adding things to deal with it. Basically if the file (/etc/ldap/schema/krb5kdc.schema iirc) hasn't been modified and isn't referenced from slapd.conf I'll nuke it. If it's been modified or is referenced in slapd.conf I think I'll probably leave it alone but inform the user about it being obsolete. Stephen pgpUyxmKa1Mga.pgp Description: PGP signature
Re: [devel] proposal: per-user temporary directories on by default?
Re: Re: [devel] proposal: per-user temporary directories on by default? [Martin Pool [EMAIL PROTECTED], Thu, Jul 24, 2003 at 03:10:57PM +1000, [EMAIL PROTECTED]] Having decided to do it through PAM, is it really necessary to change the VFS rather than setting $TMPDIR? Making it impossible to get to the real /tmp makes it a bit more intrusive and potentially confusing than really seems necessary. Given that there is a TMPDIR variable which is obeyed in most cases, using it seems to be easier than remapping /tmp. Remapping /tmp would confuse more than it would do good. Besides PAM, users can still set $TMPDIR in their startup files. BTW: Some programs use $TEMP or $TMP, should we file bugs to make them use $TMPDIR instead? Christoph -- Christoph Berg [EMAIL PROTECTED], http://www.df7cb.de Wohnheim D, 2405, Universität des Saarlandes, 0681/9657944 pgpES5HvPJchT.pgp Description: PGP signature
New wnpp tag: Request For (Co-Maintainer|Help|Whatever)
I was wandering about that kind of bug. It should mean that a maintainer (or a group of) is looking for more volunteer fo a kind of packge. It's not really a RFA, and it should probably have its own place on w.d.o/devel/wnpp page. RFC does not sounds good, but RFCM or RFH might. Any comment? ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: New wnpp tag: Request For (Co-Maintainer|Help|Whatever)
On Thu, Jul 24, 2003 at 07:31:02AM -0500, Luca - De Whiskey's - De Vitis wrote: [...] Ops... I made a wrong alias on my mutt. Please follow-up on -qa. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language.
Re: Future releases of Debian
Quoting Roland Mas [EMAIL PROTECTED]: Martin Pitt (2003-07-23 17:57:10 +0200) : [...] Besides, what's so bad with the current boot-floppies that they could not be used for another release? They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) From the user point of view, the new debian-installer looks almost like boot-floppies (plus some bits of hardware autodetection). So, quite no step has been done on the user friendliness side. From the developer point of view, debian-installer is much more maintainable that boot-floppies. So, it is going be easier to make it ready quickly for next Debian releases (boot-floppies have been the bottleneck of past releases). -- Jérôme Marant
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 01:31:05AM +0200, Eduard Bloch wrote: * Josselin Mouette [Wed, Jul 23 2003, 06:06:18PM]: Le mer 23/07/2003 ? 17:57, Martin Pitt a ?crit : Besides, what's so bad with the current boot-floppies that they could not be used for another release? Most people will do a mere dist-upgrade anyway, and b-f are thoroughly tested. But this certainly is another issue... Are you willing to maintain them ? Nobody else is. WTF did you do for debian-boot to make this statement look competent in any way? I don't know what the problem should be - we need just few more motivated people with non-i386 hardware to make them ready for Sarge. Yeah, splitting up resources just at the point when Debian-Installer finally seems to come along nicely. It took ages to find porters for d-i, I hope they don't turn back to boot-floppies now. Nothing against improved/bug-fixed versions for woody point-releases, but I don't agree with doing this let's get back to boot-floppies stunt for a second major release in a row. Of course, I haven't contributed to boot-floppies in any way, so this is just my opinion/advice. Feel free to ignore it. Michael
Re: Future releases of Debian
Hi, Marco d'Itri wrote:
some useless architecture like arm or m68k
Happy flaming.
NOT. Please.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
Only Irish coffee provides in a single glass all four essential food groups --
alcohol, caffeine, sugar, and fat.
-- Alex Levine
Re: Bug#201234: ITP: esmtp -- User configurable relay-only MTA
Andreas, On Tue, Jul 22, 2003 at 02:30:04PM +0200, Andreas Metzler wrote: In article [EMAIL PROTECTED] (local.debian-devel) you wrote: [...] I've done the necessary changes and uploaded everything to the same place http://jrfonseca.dyndns.org/debian/. I also added the detection of the default MDA to the config script. Unless there are any further corrections I'll be ready to have this package uploaded. Hello, I might be able to find the time to test and upload it tomorrow but I would rather have you ask on debian-mentors for another sponsor: * I don't intend to use your package, as I need to test my exim4 instead. * I'll probably go offline for two weeks or so in near future, which would be a bad time just after an upload. I'm also on vacations now but when I find time I'll do as suggested and ask for a sponsor on mentors. Thanks for your feedback. José Fonseca
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, 2003-07-24 at 14:53, Stephen Frost wrote: * Thomas Hood ([EMAIL PROTECTED]) wrote: Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. The maintainer should really know. The maintainer is more likely to know than the user in many cases. I think it would be worthwhile for policy to be modified to require notification when a sharing of this kind happens. I know that I'd expect someone to tell me if they're using a conffile from my package. If this were required in policy, then there ought to be an easy way to comply. We could allow packages to list Conffiles that are not shipped with the package; these would have to be included in some package upon which the dependent package Depends. That would give dpkg the information it needs to decide whether it is OK to delete the conffile when foo abandons it. If bar listed foo.conf as a conffile, then bar could inherit the file when foo abandoned it. Perhaps that could be made to work, but it would be complex, and dpkg is already beyond the capacity of Debian to maintain properly. -- Thomas
Re: May packages rm -rf subdirectories of /etc/ ?
On Thu, Jul 24, 2003 at 02:07:35PM +0200, Thomas Hood wrote: On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. That's a red herring. It doesn't know that there isn't some other package that uses one of its binaries either. What should it do when one of them becomes obsolete -- leave it hanging around just in case? If package B depends on something that is no longer present in package A, package B is buggy, and needs to be updated (even if only with a versioned depends on an older A). Cheers, Nick -- Nick Phillips -- [EMAIL PROTECTED] Beware of a tall blond man with one black shoe.
Re: May packages rm -rf subdirectories of /etc/ ?
* Thomas Hood ([EMAIL PROTECTED]) wrote: On Thu, 2003-07-24 at 13:46, Stephen Frost wrote: I see this as totally bogus. Either the conffile is shared or it isn't. If it's shared then the packages involved know this Package foo which eliminates /etc/foo.conf doesn't know that there is not some other package, bar, which Depends on foo and uses /etc/foo.conf . That's the problem. See #108587 for additional discussion. The maintainer should really know. The maintainer is more likely to know than the user in many cases. I think it would be worthwhile for policy to be modified to require notification when a sharing of this kind happens. I know that I'd expect someone to tell me if they're using a conffile from my package. Stephen pgpF5Ii6qsNzG.pgp Description: PGP signature
Re: Future releases of Debian
Moin Matthias! Matthias Urlichs schrieb am Thursday, den 24. July 2003: Hi, Marco d'Itri wrote: some useless architecture like arm or m68k Happy flaming. NOT. Please. Why NOT?! If nobody volunteeers to make the crap ready, why should others *without hardware and any other motivation* care about? MfG, Eduard. -- hightower scheisse hightower ich hab mich beim Rasieren geschnitten hightower jetzt weiß ich woher die roten Flecken auf der Tastatur kommen
Re: coreutils with selinux support
On Wed, 23 Jul 2003 17:58, Brian May wrote: In answer to your question in the bug report, currently SE-Linux users install a patched coreutils (as well as shadow (login), cron, ssh, devfsd, logrotate, fcron, stat, procps, and psmisc) from Russell's devfsd is not modified. The conflicts for devfsd is because the sample configuration files for the old version of devfsd messed up SE Linux permissions on terminal devices. The other packages listed above are all modified by necessity. archive (unstable) or my archive (stable). A modified version of dpkg is also required, it runs a script after dpkg installs a package that updates the file labels for the new files in the package. Eventually dpkg will have enough functionality that the standard dpkg will do all that I require. It may be some time though. Also I don't think SE-Linux will compile under *all* architectures yet which is also a big problem. The current version of SE Linux compiles under UML, i386, and ARM. It could be easily ported to M68k and any other architecture that does not support multiple word sizes (SPARC and PPC are problemmatic for this). The next version (which is going to be in 2.6.0) will not have any special system calls and will use /proc for such things. Therefore it should compile on all platforms without effort. At that time we can work more seriously on getting SE Linux into main. The next version may be back-ported to 2.4.x. Hopefully that will happen and then I can get all of this (apart from the modified dpkg) into main before the next release. For those of you at OLS, Stephen Smalley's BOF will cover these issues (on the kernel side - I will give a little talk about the Debian issues if there is interest). -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
What's the character encoding of manpages?
Hi, what are man pages, or more generally, groff documents, supposed to be encoded in? I didn't find any reference to that in groff(7). Is it ASCII? The problem arises because I have to transform a Docbook XML document into a manpage; there, all spaces (ASCII 0x20) inside a literallayout are translated into 0xA0 in the output. I don't know what an A0 is supposed to be, but man ignores it when generating output, thus effectively removing the spaces from the output. If a groff document should be ASCII, then this is a bug in docbook-xsl. Otherwise, I don't know. You can reproduce the problem compiling the sitemap package from sid. [Side note: there's also another problem unrelated to this; see http://sourceforge.net/tracker/?func=detailaid=763861group_id=21935atid=516914 for more information] Aaron Isotton [ http://www.isotton.com ] -- BOFH excuse #190: Proprietary Information. pgpvyHHojbHtX.pgp Description: PGP signature
Re: gnupg - old bugs
On Wednesday 23 July 2003 22:44, Branden Robinson wrote: On Wed, Jul 23, 2003 at 01:23:45PM +0200, Adrian 'Dagurashibanipal' von Bidder wrote: I went through some of the older bug reports of gnupg - I'd like some input whether I should act as suggested, or rather not. All of those bugs are more than 1 year old. Please send these individual pieces of commentary/feedback to the bugs themselves as well. I'll do it in those cases where my commentary is not just a summary of the information already present in the bug - in some cases 'this doesn't happen anymore, can we close it' was already added and the bug is still open and not tagged woody - I don't see what adding this comment again serves... cheers -- vbi -- pub 1024D/92082481 2002-02-22 Adrian von Bidder [EMAIL PROTECTED] Key fingerprint = EFE3 96F4 18F5 8D65 8494 28FC 1438 5168 9208 2481 pgpi9JgdejEIW.pgp Description: signature
Bug#202702: ITP: libsql-abstract-perl -- Generate SQL from Perl data structures
Package: wnpp Version: unavailable; reported 2003-07-24 Severity: wishlist * Package name: libsql-abstract-perl Version : 1.13 Upstream Author : Nathan Wiger [EMAIL PROTECTED] * URL : http://search.cpan.org/CPAN/authors/id/N/NW/NWIGER/SQL-Abstract-1.13.tar.gz * License : GPL or Perl artistic Description : Generate SQL from Perl data structures This module was inspired by the DBIx::Abstract. The intention of this module is to provide abstract SQL generation methods. With this module you can generate SQL, but still retain complete control over the statement handles and use the DBI interface if you wish. . While based on the concepts used by DBIx::Abstract, there are several important differences, especially when it comes to WHERE clauses. Some of the concepts used have been modified to make the SQL easier to generate from Perl data structures and hopefully more intuitive. The underlying idea is for this module to do what you mean, based on the data structures you provide it. The big advantage is that you don't have to modify your code every time your data changes, as this module figures it out. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux wompom 2.4.20-3-686 #1 Sat Jun 7 22:34:55 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C
How to gracefully rename a package?
Moi!
The new version of the OpenDX toolkit now provides sane libraries, so I
wanted to restructure the packages a bit. In particular, there is a new
package libdx4, so I wanted to rename what used to be dx-dev package as
libdx4-dev. This turned out to be harder than I thought.
The -dev package will usually be used for compiling local modules, so
nothing within Debian depends on it. dx-dev's dependency on the main dx
package is versioned with (= ${Source-Version}), so when trying to
upgrade, apt wants to remove it without even considering to replace it
with the new libdx4-dev (which conflicts, provides, and replaces
dx-dev). So I created a dummy dx-dev package that simply depends on
libdx4-dev. Works fine. But I also wanted to be nice to the user and
automatically remove the dummy dx-dev once it's no longer needed.
Therefore, libdx4-dev replaces anything in dx-dev, and dpkg removes the
package. Works fine as well. Now the final problem is libdx4-dev and
dx-dev are getting upgraded at the same time, and dpkg tries to setup
dx-dev when it already has been removed:
Preparing to replace dx-dev 1:4.2.0-8 (using dx-dev_4.3.0-1_all.deb) ...
Unpacking replacement dx-dev ...
Selecting previously deselected package libdx4-dev.
Unpacking libdx4-dev (from libdx4-dev_4.3.0-1_i386.deb) ...
Replacing files in old package dx-dev ...
(Noting disappearance of dx-dev, which has been completely replaced.)
dpkg: error processing dx-dev (--install):
no package named `dx-dev' is installed, cannot configure
Setting up libdx4-dev (4.3.0-1) ...
Errors were encountered while processing:
dx-dev
The error can simply be ignored, but it's ugly, and I'd like to avoid
it. So am I trying to do something stupid? Is there a better way to do
it? Or should I simply go file a bug on dpkg?
Any hints welcome,
Daniel.
Re: What's the character encoding of manpages?
Am 24.07.03 um 15:55:43 schrieb Aaron Isotton: what are man pages, or more generally, groff documents, supposed to be encoded in? I didn't find any reference to that in groff(7). Is it ASCII? Preferably ASCII, yes. I seem to remember having once read that the input actually is in Latin-1. There, 0xA0 is a non-breaking space. I wouldn't rely on this, though. Many manpages are in Latin-2, since man used to not do any conversion at all, assuming input would be in the same encoding as output. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: What's the character encoding of manpages?
On Thu, Jul 24, 2003 at 03:55:43PM +0200, Aaron Isotton wrote: what are man pages, or more generally, groff documents, supposed to be encoded in? I didn't find any reference to that in groff(7). Is it ASCII? See groff_char(7). Technically it's Latin-1, but this is planned to change to UTF-8 for groff 2.0 (no schedule yet); groff_char(7) advises sticking to ASCII, and I agree. You can get everything in Latin-1 using named characters anyway without having to worry about encoding. The problem arises because I have to transform a Docbook XML document into a manpage; there, all spaces (ASCII 0x20) inside a literallayout are translated into 0xA0 in the output. I don't know what an A0 is supposed to be, but man ignores it when generating output, thus effectively removing the spaces from the output. 0xA0 is the Latin-1 non-breaking space. Bug #199422 notes that this doesn't work in current groff. I'm not sure whether this is actually a groff bug or not, and need to check with upstream. I suggest using '\ ' instead anyway, though. [Side note: there's also another problem unrelated to this; see http://sourceforge.net/tracker/?func=detailaid=763861group_id=21935atid=516914 for more information] Using .nf and .fi would probably be more sensible than large numbers of .br requests. (Feel free to pass on this comment.) Cheers, -- Colin Watson, groff maintainer[EMAIL PROTECTED]
Re: How to gracefully rename a package?
Am 24.07.03 um 16:19:15 schrieb Daniel Kobras: [...] But I also wanted to be nice to the user and automatically remove the dummy dx-dev once it's no longer needed. Therefore, libdx4-dev replaces anything in dx-dev, and dpkg removes the package. [...] Cool strategy, but in general too complicated.[1] It happens from time to time that a rename has to take place. Perhaps the maintainer made a mistake in the past, perhaps upstream decided to change the name of the program (Phoenix - Firebird). Currently, you make a new package, with Replaces: and Conflicts: and stuff, but it will not be installed. So you make a transitional package with the description can be removed, but that's ugly. (All this is exactly what Daniel said already, just a little more general.) What I would like to see is some means to make this process easy. Such as the following algorithm: If package A disappears from the distribution, but there is a package B that replaces it, install that automatically.[2] I'm not sure whether this might have any unwanted side effects... Alternatively, there could be a new control field, say Supersedes:, which would result in the above behaviour. Of course, there'd have to be a change in policy... In any case, package frontends would have to implement it first, so it could be used only after the next release. Bye, Mike [1] The new package perhaps has a slightly different set of files. [2] Well, perhaps not in pure apt-get, but in dselect. -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
debian-devel@lists.debian.org
Title: [X] . http://www.jeffxee.comEmail:[EMAIL PROTECTED]0755 25093574 13823376067
Re: Future releases of Debian
Hi, Eduard Bloch wrote:
Why NOT?! If nobody volunteeers to make the crap ready, why should
others *without hardware and any other motivation* care about?
I was talking about flames, not about reasonable discussion. The borders
between these two are unfortunately somewhat fuzzy, sometimes.
If nobody volunteeers to make the crap ready,
Umm, using that word puts your mail firmly into the flame category,
especially for readers who actually care about Debian supporting these
architectures.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
--
When it's time to stop living, I will certainly make Death my number one
choice!
-- Terry Pratchett (The Last Continent)
Re: How to gracefully rename a package?
On Thu, Jul 24, 2003 at 04:37:55PM +0200, Michael Piefel wrote: Alternatively, there could be a new control field, say Supersedes:, which would result in the above behaviour. Of course, there'd have to be a change in policy... This has already been proposed as Previously: (#33344), and Successor-of: (#77325), but is probably nothing that dpkg itself can take care of (cf. #33344). Regards, Daniel.
Re: What's the character encoding of manpages?
On Thu, Jul 24, 2003 at 04:24:51PM +0200, Michael Piefel wrote:
Am 24.07.03 um 15:55:43 schrieb Aaron Isotton:
what are man pages, or more generally, groff documents, supposed to be
encoded in? I didn't find any reference to that in groff(7). Is it
ASCII?
Preferably ASCII, yes. I seem to remember having once read that the
input actually is in Latin-1. There, 0xA0 is a non-breaking space.
I wouldn't rely on this, though. Many manpages are in Latin-2, since man
used to not do any conversion at all, assuming input would be in the
same encoding as output.
Heh. Well, that's kind of still true under some circumstances. The
following is from src/encodings.c in man-db CVS, and is my attempt to
hit as many of the encoding problems with current groff as I can with a
very large hammer. Feel free to vomit after reading it.
/* Due to historical limitations in groff (which may be removed in the
* future), there is no mechanism for a man page to specify its own
* encoding. This means that each national language directory needs to carry
* with it information about its encoding, and each groff device needs to
* have a default encoding associated with it. Out of the box, groff
* formally allows only ISO-8859-1 on input; however, patches originating
* with Debian and imported by many other GNU/Linux distributions change
* this somewhat.
*
* Eventually, groff will support proper Unicode input, and much of this
* horror can go away.
*
* Do *not* confuse source encoding with groff encoding. The encoding
* specified in this table is the encoding in which the source man pages in
* each language directory are expected to be written. The groff encoding is
* determined by the selected groff device and sometimes also by the user's
* locale.
*
* This table is expected to change over time, particularly as man pages
* begin to move towards UTF-8. Feel free to patch this for your
* distribution; send me updates for languages I've missed.
*
* Explicit encodings in the directory name (e.g. de_DE.UTF-8) override this
* table. TODO: Implement this.
*/
static struct {
const char *lang_dir;
const char *source_encoding;
} directory_table[] = {
{ C, ISO-8859-1}, /* English */
{ POSIX, ISO-8859-1}, /* English */
{ da, ISO-8859-1}, /* Danish */
{ de, ISO-8859-1}, /* German */
{ en, ISO-8859-1}, /* English */
{ es, ISO-8859-1}, /* Spanish */
{ fi, ISO-8859-1}, /* Finnish */
{ fr, ISO-8859-1}, /* French */
{ ga, ISO-8859-1}, /* Irish */
{ is, ISO-8859-1}, /* Icelandic */
{ it, ISO-8859-1}, /* Italian */
{ nl, ISO-8859-1}, /* Dutch */
{ no, ISO-8859-1}, /* Norwegian */
{ pt, ISO-8859-1}, /* Portuguese */
{ sv, ISO-8859-1}, /* Swedish */
#ifdef MULTIBYTE_GROFF
/* These languages require a patched version of groff with the
* ascii8 and nippon devices.
*/
{ cs, ISO-8859-2}, /* Czech */
{ hu, ISO-8859-2}, /* Hungarian */
{ ja, EUC-JP}, /* Japanese */
{ ko, EUC-KR}, /* Korean */
{ pl, ISO-8859-2}, /* Polish */
{ ru, KOI8-R}, /* Russian */
#endif /* MULTIBYTE_GROFF */
{ NULL, NULL} };
/* The default groff terminal output device to be used is determined based
* on nl_langinfo(CODESET), which returns the character set used by the
* current locale.
*/
static struct {
const char *locale_charset;
const char *default_device;
} charset_table[] = {
{ ANSI_X3.4-1968, ascii },
{ ISO-8859-1, latin1},
{ UTF-8, utf8 },
#ifdef MULTIBYTE_GROFF
{ EUC-JP, nippon},
#endif /* MULTIBYTE_GROFF */
{ NULL, NULL} };
static const char *fallback_locale_charset = ANSI_X3.4-1968;
static const char *fallback_default_device =
#ifdef MULTIBYTE_GROFF
ascii8
#else /* !MULTIBYTE_GROFF */
ascii
#endif /* MULTIBYTE_GROFF */
;
/* The encoding used for the text passed to groff is a function of the
* selected groff device. Traditional devices expect ISO-8859-1 on input
* (yes, even the utf8 device); devices added in the Debian multibyte patch
* expect other encodings. The ascii8 device passes top-bit-set characters
* straight through so is (probably ...) encoding-agnostic. If this encoding
* does not match the source encoding, an iconv pipe is used (if available)
* to perform recoding.
*
* Setting less_charset to latin1 tells the less pager that characters
* between 0xA0 and 0xFF are displayable, not that its input is encoded in
* ISO-8859-1. TODO: Perhaps using
Re: Future releases of Debian
Hi again! Am 2003-07-24 10:11 +0200 schrieb Roland Mas: They're the single most unpopular point of Debian. The installation process is universally known to be non-user-friendly. (Note I'm not saying it doesn't work.) IMHO the problem (that journal testers complain of) is not the base installation, but the complete lack of hardware autodetection and -configuration for X, sound cards, cd burners, usb devices and so on. But these issues do not have much to to with b-f, more with a common hw detection infrastructure in Debian itself. HW detection must work also when apt-getting an X server, hotplug or cdrecord, not just when installing a fresh Debian. I definitively do _not_ want to reinstall my much-cared-of system just because I've bought a new graphics card or a wheel mouse. I like b-f very much, you can install a base system with a fast, clean menu based interface (partitioning, network installation etc.) Could someone tell me what is actually wrong with them (apart from not having a more colorful interface, SCNR)? If it is totally screwed up under the hood, then a clean redesign is good. If its only a cosmetic issue, I do not see the point. This is really a genuine question, no flaming intended. Thanks, Martin -- Martin Pitt home: www.piware.de eMail: [EMAIL PROTECTED]
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 01:01:42PM +0200, Marco d'Itri wrote: On Jul 23, Anthony Towns aj@azure.humbug.org.au wrote: (On the other hand, if you really want a shorter release cycle, there's always testing, which releases every day. All it really needs for us to be able to recommend people use it is security updates...) Did you actually try to use current testing? Sure, I've run it since before it was in the archive. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpc2Ae1IsjHt.pgp Description: PGP signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 12:03:24PM +0200, Eduard Bloch wrote: And here a decission has to be made: releasing with not-sympatic-for-so-called-new-users BFs in 2003 or with stable D-I one year later. Eduard, we've had this discussion before a few times now. If you can get boot-floppies working adequately for sarge, on all architectures, I'll be happy to consider it for the release. I don't believe you'll be able to do it more quickly than the d-i guys can, and I don't believe the time spent on it will be in the long term interests of Debian. You're welcome to prove me wrong. What you're not welcome to do, is to keep bleating about it. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpggTv5Qoja5.pgp Description: PGP signature
Re: How to gracefully rename a package?
Am 24.07.03 um 16:51:11 schrieb Daniel Kobras: This has already been proposed as Previously: (#33344), and Successor-of: (#77325), but is probably nothing that dpkg itself can take care of (cf. #33344). Cool, so many names... I'm aware that it's not dpkg's responsibility. It's not necessary, dpkg is really low level. Things like this have to be implemented in frontends anyway. (Didn't I say that in my last mail?) And that's OK, people shouldn't use backends or be aware of the problems that they might be getting. Many people use apt-get as their frontend, although it's supposed to be a backend. I believe that's wrong. But anyway it could be integrated into apt-get as well, even if Jason disagrees. root (~) # apt-get install fileutils Reading Package Lists... Done Building Dependency Tree... Done E: Couldn't find package fileutils root (~) # apt-get install coreutils Reading Package Lists... Done Building Dependency Tree... Done The following packages will be REMOVED: fileutils shellutils textutils 0 packages upgraded, 1 newly installed, 3 to remove and 0 not upgraded. Do you want to continue? [Y/n] Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: proposal: per-user temporary directories on by default?
Martin Pool wrote: Thanks. What needs to be done to have it adopted? I think that getting the package to make the necessary modifications of the pam files would be a good first step. Possibly with a debconf question first. Then we could see about integrating it into base-config. -- see shy jo pgp4ejOvHIXFH.pgp Description: PGP signature
Re: Future releases of Debian
On Thursday 24 July 2003 17:09, Martin Pitt wrote: Could someone tell me what is actually wrong with them (apart from not having a more colorful interface, SCNR)? If it is totally screwed up under the hood, then a clean redesign is good. If its only a cosmetic issue, I do not see the point. This is really a genuine question, no flaming intended. Do you hate me when I point you to the list archivees? I believe this discussion is now really, really, really, really old and was repeated several times already -- vbi -- Packages should build-depend on what they should build-depend. -- Santiago Vila on debian-devel pgpmCEh4LqMvp.pgp Description: signature
Re: mplayer 0.90, was Re: why mplayer not in Debian
On Thu, Jul 24, 2003 at 11:50:00AM +0200, Matthias Urlichs wrote: Hi, Andrew Suffield wrote: On Thu, Jul 24, 2003 at 10:18:22AM +0200, Matthias Urlichs wrote: Well, when the glibc people had this discussion (the switch to ELF), the performance penalty was found to be on the order of 5%. ... by testing with somewhat typical programs. I don't know whether modern CPUs' register aliasing hardware changes that number. On anything more recent than a 486, the answer is not a percentage, It is -- if you do the same tests, and compare. Well, you can get an *answer* that way, it's just not very accurate or useful :P it's a research paper. Just to _describe_ the performance implications. ... assuming you want to translate the results to a different set of tests. ... or, for that matter, if you want to interpret the variance you'll get in the test results, assuming it's significant, which it probably will be. You generally get a significant variance when you modify the input data. Although that doesn't always hold. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpwx0JRfPYzZ.pgp Description: PGP signature
Re: Future releases of Debian
* Jérôme Marant [EMAIL PROTECTED] [030724 15:08]: From the user point of view, the new debian-installer looks almost like boot-floppies (plus some bits of hardware autodetection). So, quite no step has been done on the user friendliness side. First of all there might be some deficits in the old installer, but it's look is definitly not user-unfriendly. Only thing it's missing is the autodetection and expanded possibilities to make a less fitting system for the impatient. If the user is ready to read the documentation while installing, the old ugly thing is still one of the best installers around, if he knew what hardware he had. Debian-installer makes it also easier to get graphical frontends. But I consider this more an evidence of good modularity than a direct criteria for quality. (But perhaps I'm old-fashioned. I'm placing a newbie before a computer and look under what circumstances he is able to get something done, if I want to get an indicator for usefulnes. And not showing screen- shots to windows-users and looking if they sheer.) Hochachtungsvoll, Bernhard R. Link -- Sendmail is like emacs: A nice operating system, but missing an editor and a MTA.
Re: Future releases of Debian
some useless architecture like arm or m68k Are we in dilemma on should we support arch that are not used widely? or We should support all architectures what i prefer is the second one.
Re: Future releases of Debian
On Jul 24, Matthias Urlichs [EMAIL PROTECTED] wrote: If nobody volunteeers to make the crap ready, Umm, using that word puts your mail firmly into the flame category, especially for readers who actually care about Debian supporting these architectures. So what? You keep using this flame excuse to conveniently ignore the real question: why should reasonably working packages (or even the whole distribution!) be penalized because nobody has enough time or interest to fix toy architectures? -- ciao, | Marco | [987 sp7FmbP1wiu6Q]
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 08:39:11PM +0300, Halil Demirezen wrote: Are we in dilemma on should we support arch that are not used widely? or We should support all architectures what i prefer is the second one. me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! cu robert pgpgsFwbEpqfT.pgp Description: PGP signature
Re: Future releases of Debian
Halil Demirezen [EMAIL PROTECTED] writes: some useless architecture like arm or m68k Are we in dilemma on should we support arch that are not used widely? or We should support all architectures No, this has nothing to do with usage. The question is why support an arch if nobody is interested in doing the work? -- Poems... always a sign of pretentious inner turmoil. pgpslHHXrApxA.pgp Description: PGP signature
Re: Future releases of Debian
Robert Lemmen writes: any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! Even when it fails to build due to compiler errors or buggy libraries? -- John Hasler [EMAIL PROTECTED] Dancing Horse Hill Elmwood, Wisconsin
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: On Thu, Jul 24, 2003 at 08:39:11PM +0300, Halil Demirezen wrote: Are we in dilemma on should we support arch that are not used widely? or We should support all architectures what i prefer is the second one. me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: May packages rm -rf subdirectories of /etc/ ?
Permitted or not, lots of packages do it. 32 on my system. Just try doing this on your own system: grep 'rm -rf' /var/lib/dpkg/info/* | grep /etc A lot of packages put configuration files into directories that belong to other packages. Maintainers of such packages should make sure that the host package's postrm doesn't wipe out their configuration files on purge. -- Thomas
Re: Future releases of Debian
an arch if nobody is interested in doing the work? do you mean someone who is interested in the maintanence of these architectures? Did I get wrong? I so, Lets think that We quit support for those architectures. Debian will be unaware of them. Portability? sincerely pgp0UNNYoRrSG.pgp Description: PGP signature
Re: Future releases of Debian
So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. do you mean you do not have any archs to test them out? All over the world someone probably have access to them. Quitting support is not the aim of Debian. However, If you talk about Commodorre 63, I say ok. sincerely. pgpnMP12wnZi8.pgp Description: PGP signature
Re: Using reportbug with Gnus
Peter S Galbraith [EMAIL PROTECTED] writes: That would be `M-x debian-bug'. :-) Oops, so it would; I crossed it with report-emacs-bug. -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) Finger [EMAIL PROTECTED] (NOT a valid e-mail address) for more info.
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 10:12:11PM +0300, Halil Demirezen wrote: So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. do you mean you do not have any archs to test them out? All over the world someone probably have access to them. Quitting support is not the aim of Debian. However, If you talk about Commodorre 63, I say ok. Yes, I do not have access to them for testing or debugging. I have access to only x86 machines currently. Thus, I can not adequately resolve problems with my packages on arm or other architectures. This is currently a bug report for Jabber concerning a segfault on the arm architecture, I can not replicate the problem and thus can not resolve it. -- Jamin W. Collins Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
Re: Future releases of Debian
On 21-Jul-03, 16:10 (CDT), Mathieu Roy [EMAIL PROTECTED] wrote: Don't you agree that game industry is not a minor industry related to computers? All I meant to ask was for a clarification of card Foo is unsupported. My *personal* experience is that I've gotten a wide variety of cards to work acceptably in 2D mode, and that often people say card Foo is unsupported when what they mean is a I can't run Quake (or whatever) on card Foo. These are related to the people who say the stable release is hopelessly outdated and useless when in fact quite a few people (myself included) have a variety of servers and desktops running the Debian stable release, and amazingly enough, continue to get work done with them. I didn't mean to slam games, but to point out that lack of hardware 3d is not the same as useless. Thanks to the others for clarifying, and while I can be quite happy (well, accepting) with the performance of 2D VESA modes (admittedly with the eye-candy turned down), I'll happily conceed that it's not the best of all possible worlds. Well, sit in front of your computer for about 15 minutes and you'll see the big picture (if you have xscreensaver installed, indeed). Eyecandy. Nice eyecandy for sure, but hardly worth making *the* basis of hardware and software choice. I have no problem with the packages included in woody but defending them by telling that nobody cares about using its hardware at his full capacity (in fact, at least at 50% of it's capacity) seems just wrong. I didn't say that nobody cared, what I said (or at least meant to imply) was that a great many of us *don't* care about such things, and making absolute statements (either way) is not useful in determining how Debian does things. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: proposal: per-user temporary directories on by default?
On 24-Jul-03, 11:11 (CDT), Joey Hess [EMAIL PROTECTED] wrote: I think that getting the package to make the necessary modifications of the pam files would be a good first step. yes. Possibly with a debconf question first. Then we could see about integrating it into base-config. Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? If not, just do it, don't bother people with unnecesary questions. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Future releases of Debian
Jamin W. Collins [EMAIL PROTECTED] writes: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say look on http://db.debian.org/machines.cgi;, except that's down; I can at least point you at section 4.4 of the Developer's Reference, though that doesn't say a whole lot beyond this. I admit that this doesn't necessarily help for testing installers, but for your own packages it should be straightforward for you to do testing and bugfixing even on architectures you don't personally own a machine for. -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ Theoretical politics is interesting. Politicking should be illegal. -- Abra Mitchell
Re: Future releases of Debian
On Thu, 2003-07-24 at 21:52, David Z Maze wrote: Jamin W. Collins [EMAIL PROTECTED] writes: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say look on http://db.debian.org/machines.cgi;, except that's down; I can at least point you at section 4.4 of the Developer's Reference, though that doesn't say a whole lot beyond this. I admit that this doesn't necessarily help for testing installers, but for your own packages it should be straightforward for you to do testing and bugfixing even on architectures you don't personally own a machine for. You walked right into that one... :-) His point throughout this thread is that people waiting for DAM approval do NOT have access to those machines and are thus hampered in their abilities to maintain packages. Cheers, Jens PS: Thanks to all the developers. No matter what, Debian is a great thing.
Re: Cosing ITA bugs when you've changed your mind.
Luca - De Whiskey's - De Vitis wrote: On Thu, Jul 24, 2003 at 08:27:06AM +0200, Thomas Viehmann wrote: Hmm. I guess I've somewhat misunderstood the RFA and your comments on it. Cheers T. pgpMzr4ymt2hX.pgp Description: PGP signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 03:52:38PM -0400, David Z Maze wrote: Jamin W. Collins [EMAIL PROTECTED] writes: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say look on http://db.debian.org/machines.cgi;, except that's down; I can at least point you at section 4.4 of the Developer's Reference, though that doesn't say a whole lot beyond this. I admit that this doesn't necessarily help for testing installers, but for your own packages it should be straightforward for you to do testing and bugfixing even on architectures you don't personally own a machine for. Now you're assuming that I have access to the Debian machines. TMK, these machines are *not* public access machines, but instead are accessible to full DDs only. This excludes all new maintainer applicants, myself included. -- Jamin W. Collins This is the typical unix way of doing things: you string together lots of very specific tools to accomplish larger tasks. -- Vineet Kumar
Re: Future releases of Debian
Quoting Bernhard R. Link [EMAIL PROTECTED]: * Jérôme Marant [EMAIL PROTECTED] [030724 15:08]: From the user point of view, the new debian-installer looks almost like boot-floppies (plus some bits of hardware autodetection). So, quite no step has been done on the user friendliness side. First of all there might be some deficits in the old installer, but it's look is definitly not user-unfriendly. ... Debian-installer makes it also easier to get graphical frontends. But I consider this more an evidence of good modularity than a direct criteria for quality. (But perhaps I'm old-fashioned. I'm placing a newbie before a computer and look under what circumstances he is able to get something done, if I want to get an indicator for usefulnes. And not showing screen- shots to windows-users and looking if they sheer.) Sure. Many Debian people/users don't care for having a userfriendly installer: they want to install the base system and upgrade ever and ever. I've been pretty happy with boot-floppies so far. The priority in the installer revamping effort was to create something more maintainble that you can easily/quickly adapt to new debian releases. But my point was the new debian-installed is not going to look like the current Mandrake 9.1 nor RedHat 9.0 (I've recently installed), at least for sarge. -- Jérôme Marant
Re: Future releases of Debian
David Z Maze [EMAIL PROTECTED] wrote: Jamin W. Collins [EMAIL PROTECTED] writes: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say look on http://db.debian.org/machines.cgi;;, except that's down; I can at least point you at section 4.4 of the Developer's Reference, though that doesn't say a whole lot beyond this. I admit that this doesn't necessarily help for testing installers, but for your own packages it should be straightforward for you to do testing and bugfixing even on architectures you don't personally own a machine for. You forget, perhaps, that Jamin is stuck in the NM queue waiting for DAM approval. Since he's not an official DD yet, he does not have access to those machines... -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 10:35:01PM +0200, J?r?me Marant wrote: Quoting Bernhard R. Link [EMAIL PROTECTED]: But my point was the new debian-installed is not going to look like the current Mandrake 9.1 nor RedHat 9.0 (I've recently installed), at least for sarge. Perhaps for now, but that doesn't mean it has to stay that way. The modularity of the system will definitely allow for different frontends, and the fact that people are going to be more willing to work on d-i means that it will more than likely accumulate improvements over time. You can't say that about boot-floppies. I, for one, hope that the aim is to eventually have a very friendly installer. Even the most knowledgable people will appreciate hardware detection. - David Nusinow
Re: Future releases of Debian
#include hallo.h * David Z Maze [Thu, Jul 24 2003, 03:52:38PM]: On Thu, Jul 24, 2003 at 08:25:16PM +0200, Robert Lemmen wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? But Debian has ~public machines for pretty much every architecture. I'd say look on http://db.debian.org/machines.cgi;, except that's Yeah, let's get auric wired with another box for serial console and reboot it to test D-I! Seriously, for such tasks you need a such box close to your location and for exclusive use only. So the installer implementation can only be done by people with such hardware at home. MfG, Eduard. -- Fette-Sau und warum ist der nicht so schön bunt wie bei Suse?
unicode
Hi Is Debian aims to be unicode compatible system? If yes, then should I mail a bug report against packages which are not able to handle unicode? If yes, should it be Minor, Normal or Important? For example, grep is not able to search unicode strings. Important is a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. So, should I file a bug with important severity for grep? -- Best regards, Sergey Spiridonov
Re: unicode
On Wed, 30 Oct 2002, Sergey V. Spiridonov wrote: For example, grep is not able to search unicode strings. It can't search for UTF-8? Why not? T -- thomas thurman - marnanel at marnanel dot org - http://marnanel.org You are in a long, narrow corridor stretching out of sight to the west.
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 01:08:40PM -0600, Jamin W. Collins wrote: On Thu, Jul 24, 2003 at 10:12:11PM +0300, Halil Demirezen wrote: So, are you volunteering to help those of us without access to either of the above architectures with bugs found in our packages? I'm not saying that all architectures shouldn't be supported equally. I just don't have access to either of the above architectures to correct problems found in my packages. do you mean you do not have any archs to test them out? All over the world someone probably have access to them. Quitting support is not the aim of Debian. However, If you talk about Commodorre 63, I say ok. Yes, I do not have access to them for testing or debugging. I have access to only x86 machines currently. Thus, I can not adequately resolve problems with my packages on arm or other architectures. This is currently a bug report for Jabber concerning a segfault on the arm architecture, I can not replicate the problem and thus can not resolve it. This does not excuse broken, ugly x86isms in packages. The vast majority of portability problems are NOT confined to a single oddball architecture; they may manifest in different ways, but the bugs are usually there on multiple architectures at once. If you don't directly have the hardware or experience to debug a particular problem, there are several mailing lists (debian-mentors, debian-devel, or upstream) where it might be appropriate to ask. The jabber bug in question doesn't even have a 'help' tag -- nor does it have a severity appropriate for a bug that renders a package completely inoperable on a given architecture. It is an explicit duty of every maintainer to not only care for his packages to the best of his ability, but also to recognize when he is unable to care for a package and ask for the help of the larger Debian community -- whether that means orphaning a package when he no longer has the time or interest to maintain it, or asking for help on a particularly confusing bug. -- Steve Langasek postmodern programmer pgpyZBjWBMebX.pgp Description: PGP signature
Re: unicode
On Wed, Oct 30, 2002 at 02:11:46PM +0100, Sergey V. Spiridonov wrote: Is Debian aims to be unicode compatible system? Not officially, although I think that this is a worthwhile goal and there are various efforts that try to bring Debian a little bit closer to ubiquitous Unicode support. If yes, then should I mail a bug report against packages which are not able to handle unicode? If yes, should it be Minor, Normal or Important? wishlist For example, grep is not able to search unicode strings. Is it not? [EMAIL PROTECTED]:~$ cat foo This is a test with Umlauts: äöü [EMAIL PROTECTED]:~$ grep ä foo with Umlauts: äöü [EMAIL PROTECTED]:~$ locale LANG=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 LC_NUMERIC=de_DE.UTF-8 LC_TIME=de_DE.UTF-8 LC_COLLATE=de_DE.UTF-8 LC_MONETARY=de_DE.UTF-8 LC_MESSAGES=de_DE.UTF-8 LC_PAPER=de_DE.UTF-8 LC_NAME=de_DE.UTF-8 LC_ADDRESS=de_DE.UTF-8 LC_TELEPHONE=de_DE.UTF-8 LC_MEASUREMENT=de_DE.UTF-8 LC_IDENTIFICATION=de_DE.UTF-8 LC_ALL= [EMAIL PROTECTED]:~$ - Sebastian
Re: unicode
On Wed, Oct 30, 2002, Sergey V. Spiridonov wrote: For example, grep is not able to search unicode strings. Yes it is. Are you sure you are using a unicode locale? See for instance: $ export LC_ALL=fr_FR $ echo skål | iconv -f iso8859-1 -t utf8 | grep -q sk.l echo OK $ export LC_ALL=fr_FR.UTF8 $ echo skål | iconv -f iso8859-1 -t utf8 | grep -q sk.l echo OK OK $ So, should I file a bug with important severity for grep? No. -- Sam.
Re: po-debconf patches and woody backportability (was: Re: [VAC] 25 july - 26 august)
On Thu, Jul 24, 2003 at 11:29:13AM +0100, Colin Watson wrote: [...] When building with po-debconf, a format 1 (no encoding specifications, woody-compatible) debian/templates file is generated in the clean target and shipped in the source package, but a format 2 (UTF8-encoded, woody-incompatible) debian/templates file is generated in binary-arch for the binary package only. [...] One minor correction, the difference between formats 1 and 2 is that with the latter encoding is part of field name. IIRC original plan for sarge was to use format 2 with legacy encodings (i.e. the same encoding as with format 1), and let translators choose their preferred encoding after sarge. Denis
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 03:13:40PM +1000, Martin Pool wrote: Martin Pool wrote: At the least I would like to see Debian prompt for this at installation much as it does for shadow passwords. Ideally it would be on by default. I'm all for this idea. Thanks. What needs to be done to have it adopted? Since I use static per-user in home tmp directories I have not looked at libpam-tmpdir though. I suppose that enabling it currently requires making some modifications to many of the pam.d files? Yes, it does. This is a slight problem: it would be nice if there were a way to say this session module should apply to all services, but I don't think there's any way to do that in PAM. It could be done in either libpam or a Debian script that generates the files, but it's not strictly needed. This should soon be possible, by making the relevant changes to /etc/pam.d/other and /etc/pam.d/common-session (not yet present in the Debian packages). The support for this layout in the PAM packages is well underway, but I don't think anyone's begun work yet on an update-pam interface for managing these two config files. -- Steve Langasek postmodern programmer pgpl8TEi4XIwe.pgp Description: PGP signature
Re: Future releases of Debian
On Thu, Jul 24, 2003 at 04:23:29PM -0500, Steve Langasek wrote: On Thu, Jul 24, 2003 at 01:08:40PM -0600, Jamin W. Collins wrote: Yes, I do not have access to them for testing or debugging. I have access to only x86 machines currently. Thus, I can not adequately resolve problems with my packages on arm or other architectures. This is currently a bug report for Jabber concerning a segfault on the arm architecture, I can not replicate the problem and thus can not resolve it. This does not excuse broken, ugly x86isms in packages. Did I say it excused them? No! Please refrain from trying to put words in my mouth. The vast majority of portability problems are NOT confined to a single oddball architecture; they may manifest in different ways, but the bugs are usually there on multiple architectures at once. If you don't directly have the hardware or experience to debug a particular problem, there are several mailing lists (debian-mentors, debian-devel, or upstream) where it might be appropriate to ask. The jabber bug in question doesn't even have a 'help' tag -- nor does it have a severity appropriate for a bug that renders a package completely inoperable on a given architecture. It doesn't have a help tag, but it does have both unreproducible, and moreinfo. The definition of unreproducible is: unreproducible This bug can't be reproduced on the maintainer's system. Assistance from third parties is needed in diagnosing the cause of the problem. So, it would seem that the bug was appropriately tagged, and a request for help was made. Tagging the bug with help would have fulfilled the help request, but whould not have been as accurrate a tag. help The maintainer is requesting help with dealing with this bug. I tagged it for assistance as of: 13 Apr 2003 -- Jamin W. Collins To be nobody but yourself when the whole world is trying it's best night and day to make you everybody else is to fight the hardest battle any human being will fight. -- E.E. Cummings
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: On 24-Jul-03, 11:11 (CDT), Joey Hess [EMAIL PROTECTED] wrote: I think that getting the package to make the necessary modifications of the pam files would be a good first step. yes. Possibly with a debconf question first. Then we could see about integrating it into base-config. Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? If not, just do it, don't bother people with unnecesary questions. Does the PAM module *create* /tmp/username if it's not there? -- Steve Langasek postmodern programmer pgp29Ix07bpxu.pgp Description: PGP signature
Re: Future releases of Debian
On Jul 24, Robert Lemmen [EMAIL PROTECTED] wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! Really? Then please tell me what is broken in libberkeleydb-perl: http://buildd.debian.org/fetch.php?pkg=libberkeleydb-perlver=0.23-2arch=armstamp=1058302695file=logas=raw And in the past months some packages (among them mutt, which even fixed a security bug) were kept out of testing because something was broken in m68k groff. -- ciao, | Marco | [989 trQz92q0zHAZw] pgpYFvw6evmzB.pgp Description: PGP signature
Re: Future releases of Debian
And in the past months some packages (among them mutt, which even fixed a For example, I came accross a segfault with micq. However, I could not find the reason for this bug. Why i pointed out this is that there may be a probable bug there. sincerely.
Re: proposal: per-user temporary directories on by default?
On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? Systems with large numbers of users (and normally use, for example /home/u/username), and filesystem which doesn't like large numbers of entries quickly might have performance problems. And then there's the issue of making *really sure* that /tmp/username always exists and has the correct permissions, otherwise this would be worse, because once we do this, people will probably stop caring about creating temporary files securely. -- Dwayne C. Litzenberger [EMAIL PROTECTED] The attachment is an OpenPGP (PGP/MIME) signature, which can be used to verify the authenticity of this message. See the message headers for more information. pgpkyxeE8MZ73.pgp Description: PGP signature
Re: Future releases of Debian
On Fri, Jul 25, 2003 at 12:13:44AM +0200, Marco d'Itri wrote: On Jul 24, Robert Lemmen [EMAIL PROTECTED] wrote: me too! any package that doesn't build on m68k or arm is broken and needs to be fixed, even if it works on x86 by chance! Really? Then please tell me what is broken in libberkeleydb-perl: http://buildd.debian.org/fetch.php?pkg=libberkeleydb-perlver=0.23-2arch=armstamp=1058302695file=logas=raw And in the past months some packages (among them mutt, which even fixed a security bug) were kept out of testing because something was broken in m68k groff. Eh, nobody told me (as the groff maintainer) that that was holding up other packages. I couldn't reproduce the problem on crest, only on fabbione's machine, and there it looked like a hardware problem. -- Colin Watson [EMAIL PROTECTED]
Re: po-debconf patches and woody backportability (was: Re: [VAC] 25 july - 26 august)
On Thu, Jul 24, 2003 at 11:29:35PM +0200, Denis Barbier wrote: On Thu, Jul 24, 2003 at 11:29:13AM +0100, Colin Watson wrote: When building with po-debconf, a format 1 (no encoding specifications, woody-compatible) debian/templates file is generated in the clean target and shipped in the source package, but a format 2 (UTF8-encoded, woody-incompatible) debian/templates file is generated in binary-arch for the binary package only. One minor correction, the difference between formats 1 and 2 is that with the latter encoding is part of field name. Indeed, sorry, I was simplifying format 2 a bit. In my particular case I use '-e utf8' throughout. -- Colin Watson [EMAIL PROTECTED]
Re: unicode
Sebastian Rittau wrote: Is Debian aims to be unicode compatible system? [snip] For example, grep is not able to search unicode strings. Is it not? Sorry, it was bad example. I made wrong test. -- Best regards, Sergey Spiridonov
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:58:33 -0500, Steve Langasek wrote: Does the PAM module *create* /tmp/username if it's not there? Actually it is /tmp/users/uid at the moment, and yes, it creates both levels securely. -- Martin
Re: proposal: per-user temporary directories on by default?
On Thu, 24 Jul 2003 16:56:50 -0600, Dwayne C. Litzenberger wrote: On Thu, Jul 24, 2003 at 02:50:05PM -0500, Steve Greenland wrote: Please don't. Is there *any* reason why defaulting TMPDIR=/tmp/username is inferior to TMPDIR=/tmp? Systems with large numbers of users (and normally use, for example /home/u/username), and filesystem which doesn't like large numbers of entries quickly might have performance problems. The issue is having a number of directories under /tmp/users/uid, each with a moderate number of files, vs having a large number of files directly under /tmp. It will depend on the particular case but I don't think the first will be be worse than the second. Indeed the two-level case with /tmp/users/uid is closer to the setup you mention. The tmpdir for an active user is likely to be in the dcache much of the time, which means that accessing files in it may well be faster than looking through an enormous /tmp/ shared by all users. If people are running a tmpreaper, then it will reap the directories of any users who have not used them for n days. On machines with many users who are intermittently active the case is quite different to /home, where all the directories have to exist all the time. Administrators for whom this is a concern can always override it from a profile script. Anyhow, I don't think a highly speculative possible performance issue justifies neglecting a concrete security improvement that would have effectively protected users from a number of existing problems. And then there's the issue of making *really sure* that /tmp/username always exists and has the correct permissions, I think doing this once and properly in libpam-tmpdir is more likely to be secure than various administrators or programs trying to get it right. I have already done a quick audit of the source and filed some (fairly minor) bugs; other people are welcome to do do too. I am not saying that libpam-tmpdir is eternal and perfect in its current state. There are some issues that could be improved. But I would like Debian to move towards per-user tmp as a general idea. otherwise this would be worse, because once we do this, people will probably stop caring about creating temporary files securely. Well, those people would be pretty damn foolish, because the issue will still exist on almost all other Unix systems or on systems that reset TMPDIR. -- Martin
Accepted gksu 0.9.13 (i386 source)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Thu, 24 Jul 2003 00:53:00 -0300 Source: gksu Binary: gksu Architecture: source i386 Version: 0.9.13 Distribution: unstable Urgency: low Maintainer: Gustavo Noronha Silva [EMAIL PROTECTED] Changed-By: Gustavo Noronha Silva [EMAIL PROTECTED] Description: gksu - Gtk+ Frontend to su Closes: 202532 Changes: gksu (0.9.13) unstable; urgency=low . * New release (not yet released) - minor cosmetic enhancements on the dialog - new option (--ssh-fwd) was added to work-around problem with ssh X11 forwarding (Closes: #202532) Files: 0e297d3e4d831ca802be870c1cc17d75 545 admin optional gksu_0.9.13.dsc cf9134871021f4068e1e303eebfcb762 369612 admin optional gksu_0.9.13.tar.gz b3c07b84843a56fbbd6e1645986648f9 41988 admin optional gksu_0.9.13_i386.deb -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/H3bEt1anjIgqbEsRAiZPAKCIBRiYAWYvZO4TPk39NIvY5rAqnQCgle40 cgcpVZAtmBbZbSriRFKJyG4= =QCaW -END PGP SIGNATURE- Accepted: gksu_0.9.13.dsc to pool/main/g/gksu/gksu_0.9.13.dsc gksu_0.9.13.tar.gz to pool/main/g/gksu/gksu_0.9.13.tar.gz gksu_0.9.13_i386.deb to pool/main/g/gksu/gksu_0.9.13_i386.deb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
