Re: Firebird 0.6
Eric Dorland <[EMAIL PROTECTED]> writes: > I've uploaded mozilla-firebird_0.6-1 to my personal apt > repository at http://people.debian.org/~eric/debian/. Looks good, but why the long binary name? Wouldn't just `firebird' be nicer? Thanks, -Miles -- Come now, if we were really planning to harm you, would we be waiting here, beside the path, in the very darkest part of the forest?
Firebird 0.6
Hi Everyone, From the amount of mail I've gotten I guess people will be interested. I've uploaded mozilla-firebird_0.6-1 to my personal apt repository at http://people.debian.org/~eric/debian/. Just add: deb http://people.debian.org/~eric/debian/$(ARCH) ./ to your /etc/apt/sources.list and apt-get install mozilla-firebird. Note that This package does NOT Conflict/Provide/Replace my older phoenix package since they were unofficial, and this package doesn't actually conflict with the phoenix package (because of the name change). I'll probably upload this to unstable after a few more tweaks, if there's no objections. PS Many people have sent bug reports over the last few months and I tried to fix as many as I could remember, but I didn't actually look through my mail archive. So if I said I would fix your issue and I didn't, please drop me another note. -- Eric Dorland <[EMAIL PROTECTED]> ICQ: #61138586, Jabber: [EMAIL PROTECTED] 1024D/16D970C6 097C 4861 9934 27A0 8E1C 2B0A 61E9 8ECF 16D9 70C6 -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s++: a-- C+++ UL+++ P++ L++ E++ W++ N+ o K- w+ O? M++ V-- PS+ PE Y+ PGP++ t++ 5++ X+ R tv++ b+++ DI+ D+ G e h! r- y+ --END GEEK CODE BLOCK-- pgpXWyccMqgB6.pgp Description: PGP signature
Re: DSA's via rsync
On Mon, May 19, 2003 at 04:25:20PM +0400, Alexander Kotelnikov wrote: > > On Mon, 19 May 2003 18:28:19 +1000 > > "AP" == Andrew Pollock <[EMAIL PROTECTED]> wrote: > AP> > AP> > AP> This would be made easier if the DSA's were obtainable in a more > parseable > AP> format. > > DSA'a are available in RDF. There exists a link on the bottom of > www.debian.org/security to it. Doh. I wish the person who'd asked me had looked harder :-( Andrew
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
"Matt Ryan" <[EMAIL PROTECTED]> writes: > sending HTML emails its a general comment on people usage of the Internet. > If you can limit yourself to contacts who are technical enough to understand > the arguments why you don't like it then you can maintain the pretence that > it doesn't exist. Those who have to communicate on a wider basis (perhaps > for work?) cannot afford to drop mail to /dev/null and so will have to get > used to it I think. Is html-only email really all that widespread? I keep very close track of whether mail is in html form or not, for spam killing reasons, and I don't think I've _ever_ gotten an email from someone that didn't at least have a text/plain version of the contents along with the text/html. Of course most of my email is from technical people, but I certainly get a reasonable amount from non-technical people as well. On the other hand, spammers invariably -- so far! -- seem to send _pure_ html (no non-blank text/plain parts). [The big exception is nigerian 419-scammers, who for the most part don't even seem to have discovered lower-case...] -Miles -- Yo mama's so fat when she gets on an elevator it HAS to go down.
Re: Do not touch l10n files
On 19-May-03, 11:03 (CDT), Steve Langasek <[EMAIL PROTECTED]> wrote: > The VMS-style error codes occurred to me as well. Though if one goes > that route, I wonder if gettext any longer has advantages over msgcat. > :) I realize you're being (at least somewhat) facetious, but if you start with a message like fprint(stderr, "SYS-YOURFSCKED-1334 Stupid summer intern error"); used it consistently, and added "Please don't attempt to translate anything that looks like SYS-BLAHBLAH-CODE" to the docs, you might get much of what Ted wants and still get the advantages of gettext(). Of course, you don't get the full advantages of VMS system then, but you won't anyway on a Unix system. Steve If > -- > Steve Langasek > postmodern programmer -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net
Re: Bug#193838: libgcc1: installation of libgcc1:3.3-2 causes failure of massive number of programs
p.s. the version of python 2.2 is back at 2.2.1 compiled with gcc 2.95.4 (stable version) the version that got into trouble was the python 2.2 that was compiled with gcc 3.2 (unstable latest version?) On Mon, May 19, 2003 at 07:40:06PM +0200, Matthias Klose wrote: > [CC to debian-devel, did anybody see this behaviour on an update?] > > Luke Kenneth Casson Leighton writes: > > On Mon, May 19, 2003 at 04:52:51PM +0200, Matthias Klose wrote: > > > Never seen this upgrade behaviour. Was libgcc1 installed before > > > libstdc++5? If not, please could you explictely install libgcc1 and > > > then libstdc++5? > > > > i have tried that. > > > > it says "already at latest version". > > > > then i tried installing gcc 3.3. > > > > that failed to fix the problem. > > > > when i manually installed the OLD version of libstdc++: > > > > 514 dpkg -i /var/cache/apt/archives/libgcc1_1%3a3.2.3-0pre6_i386.deb > > 515 dpkg -i /var/cache/apt/archives/libstdc++5_1%3a3.2.3-0pre6_i386.deb > > > > then it fixed the problem > > -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about...
RE: Debian conference in the US?
-Original Message- From: Brian Nelson [mailto:[EMAIL PROTECTED] Sent: Monday, May 19, 2003 1:05 AM To: debian-devel@lists.debian.org Ben Collins <[EMAIL PROTECTED]> writes: >>> What are other developers' feelings on the matter these days? >> >> If we're doing "let's have a conf where we normally don't" how about we >> have it on the US's east coast aswell. I'd personally argue for the >> nothern Virginia are myself. >> >> Too many conferences are held on the US's West coast, and if conferences >> do get to the East coast, they are always in New York. That leaves the >> south eastern US folks out in the cold. > Wrong. It doesn't get cold out in the southeastern US. :P Wrong. It DOES get cold. Just not AS cold as the northern US. :P Mike
Re: Accepted pointless 0.3-3 (i386 source)
reopen 193287 reopen 193286 thanks Marco Presi (Zufus) <[EMAIL PROTECTED]> writes: > Format: 1.7 > Date: Wed, 14 May 2003 20:30:39 +0200 > Source: pointless > Binary: pointless > Architecture: source i386 > Version: 0.3-3 > Distribution: unstable > Urgency: low > Maintainer: Marco Presi (Zufus) <[EMAIL PROTECTED]> > Changed-By: Marco Presi (Zufus) <[EMAIL PROTECTED]> > Description: > pointless - A presentation tool based on OpenGL > Closes: 193286 193287 > Changes: > pointless (0.3-3) unstable; urgency=low > . >* Closes: #193287 >* Closes: #193286 Uhhh, nope, sorry. Close them correctly or don't close them at all. -- Looks like excitement by repetition! pgpLbZW6s3csx.pgp Description: PGP signature
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
On Mon, May 19, 2003 at 10:17:40PM +0200, Josip Rodin wrote: > (I'd quote a proverb about how small things lead to big things, but I > can't currently think of any of those in English. :) "Look after the pennies and the pounds will take care of themselves." Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
On Mon, May 19, 2003 at 07:14:07PM +0100, Matt Ryan wrote: > > Well, yeah, sure, but the highway analogy doesn't apply. There isn't a > > single technical reason why I as a random person need to ever be in any > > sort of contact with a spammer to keep the system running. > > There was no mention of spammers in the thread! While they are prone to > sending HTML emails its a general comment on people usage of the Internet. Spammers are only the bottom-most layer, but it's the same pile. (I'd quote a proverb about how small things lead to big things, but I can't currently think of any of those in English. :) > If you can limit yourself to contacts who are technical enough to > understand the arguments why you don't like it then you can maintain the > pretence that it doesn't exist. Those who have to communicate on a wider > basis (perhaps for work?) cannot afford to drop mail to /dev/null and so > will have to get used to it I think. You started the subthread by saying the rules are archaic and irrelevant; whether the "law-abiding" people get used to other people breaking the "laws" or not is not the real issue -- that's a reality. But in principle, rejecting these laws based on the number of offenders, discarding the other realities such as the fact there's no official legislation enforcing them, doesn't strike me as particularly logical. -- 2. That which causes joy or happiness.
Bug#193888: ITP: openoffice.org-thesaurus-de -- German Thesaurus for OpenOffice.org
Package: wnpp Version: unavailable; reported 2003-05-19 Severity: wishlist * Package name: openoffice.org-thesaurus-de Version : 20030512 Upstream Author : Daniel Naber <[EMAIL PROTECTED]> * URL : http://thesaurus.kdenews.org/lang.php?lang=en * License : GPL Description : German Thesaurus for OpenOffice.org This package contains a German Thesaurus for the OpenOffice.org office suite. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux frodo 2.4.20-apm-rene #1 Sat May 10 00:47:56 CEST 2003 i686 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] pgpGtULPsRBPZ.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
Hello On Mon, May 19, 2003 at 12:43:02PM -0400, David Z Maze wrote: > Ola Lundqvist <[EMAIL PROTECTED]> writes: > > > Kernel module policy: > > - > > > > * Kernel modules must be provided as a "binary source" package. > > * Module source packages should provide a debian/rules file. > > * The debian/rules file must compile the module if KSRC=kernelsourcedir > > and KVERS=versionname is priovided. > > I'd be slightly happier if the targets kernel-package used were > supported here, 'debian/rules kdist-image' and such. (This is to > accomodate "binary source" packages that have a single debian/rules > file that's copied verbatim from the source package to the binary > package; both lm-sensors and i2c work this way, don't know about other > packages.) Hmm, that was what I wanted too. It was just too long time ago I fiddled with the real options. I use my scripts too much I think. > > * The debian/rules file may fail if an unsupported version of the kernel is > > provided by the environment. > > * The debian/rules file may fail if no kernel-headers is in that location. > > * The debian/rules file should handke KMAINT and KEMAIL env variables. > > ...in fact, this looks a lot like what kernel-package currently > documents. Is a separate policy from the kernel-package documentation > needed? Well the kernel-package documentation is what I want to be highlighted. But they are not at mandatory (or similar) and some packages do not follow them. They are also not complete (in my opinion at least). > (FWIW, i2c and lm-sensors both successfully build against only the > kernel headers, via the kernel-build-* packages.) The kernel build-packages is a good step. Regards, // Ola > -- > David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ > "Theoretical politics is interesting. Politicking should be illegal." > -- Abra Mitchell > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
Hi, On Mon, May 19, 2003 at 07:14:07PM +0100, Matt Ryan wrote: > Josip Rodin wrote: > > Well, yeah, sure, but the highway analogy doesn't apply. There isn't a > > single technical reason why I as a random person need to ever be in any > > sort of contact with a spammer to keep the system running. > > There was no mention of spammers in the thread! While they are prone to > sending HTML emails its a general comment on people usage of the Internet. > If you can limit yourself to contacts who are technical enough to understand > the arguments why you don't like it then you can maintain the pretence that > it doesn't exist. Those who have to communicate on a wider basis (perhaps > for work?) cannot afford to drop mail to /dev/null and so will have to get > used to it I think. Few people are advocating to send every non-netiquette compliant mail to the bitbucket. However, I fail to understand why you want people to refrain from bringing the netiquette under the attention of the people they are receiving email from. It's not that receivers of email have a /right/ or that they can enforce compliance, but that was never the case anyway, in case you didn't notice. You can't demand anything, but of course you can filter whatever you like. It's your loss, nobody elses. IOW, if everybody just tries to accomodate some reasonable wishes as stated by the other party as far as is possible without effort (and including a text/plain part is no effort, not forwarding virus hoaxes is no effort, but proving to a robot that you are not *is*), there is no need to drop any netiquette rules. In short, I still fail to see your point. Cheers, Emile. -- E-Advies - Emile van Bergen [EMAIL PROTECTED] tel. +31 (0)70 3906153 http://www.e-advies.nl
stunnel
Hello, I saw stunnel has not been uploaded since december 2001, so unstable version of stunnel is very old. I use stunnel on all my computers, and I would like to take over the package. Is there any objection ? ( I sent a mail to current maintainer Paolo Molaro <[EMAIL PROTECTED]> three weeks ago without answer). Best Regards. -- Julien LEMOINE / SpeedBlue
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
Emile van Bergen wrote >I also don't understand the phrase "today's Internet world". You mean >with the hordes running Outlook and shopping on the clickable amazing >discoveries / quantum shopping / tell sell channel that's the WWW? Yes. If you have to interact with them to any great extent then its hard to cut yourself off from those that don't follow the 'rules'. >How does that make sane email communication standards less relevant? It doesn't, but then those hordes may not agree with your view of which standard to follow if they don't know of the RFC (in this case) and just go with the MUA default settings. >Again, I ask: what's the alternative you are proposing? What do you >want? I'm putting forward the viewpoint that the 'rules' are archaic and quoting them may not get the response you want/expect. If you can then drop email to NULL: for those people then thats fine but others may not be so lucky. I find it hard to get worked up with any of the "anti-social" behaviour that goes on (yes, even spam) because its more useful to have access to the Internet with all its warts than to avoid some of the interaction that acompanies it. >It seems you just want to send HTML mail, and not feel sorry for it. Never said I wanted to and the thread was wider scoped than just HTML email. Matt.
Re: Daft Internet Stuff [Re: Returning from "vacation". (MIA?)]
Josip Rodin wrote: > Well, yeah, sure, but the highway analogy doesn't apply. There isn't a > single technical reason why I as a random person need to ever be in any > sort of contact with a spammer to keep the system running. There was no mention of spammers in the thread! While they are prone to sending HTML emails its a general comment on people usage of the Internet. If you can limit yourself to contacts who are technical enough to understand the arguments why you don't like it then you can maintain the pretence that it doesn't exist. Those who have to communicate on a wider basis (perhaps for work?) cannot afford to drop mail to /dev/null and so will have to get used to it I think. Matt.
Re: Bug#193838: libgcc1: installation of libgcc1:3.3-2 causes failure of massive number of programs
[CC to debian-devel, did anybody see this behaviour on an update?] Luke Kenneth Casson Leighton writes: > On Mon, May 19, 2003 at 04:52:51PM +0200, Matthias Klose wrote: > > Never seen this upgrade behaviour. Was libgcc1 installed before > > libstdc++5? If not, please could you explictely install libgcc1 and > > then libstdc++5? > > i have tried that. > > it says "already at latest version". > > then i tried installing gcc 3.3. > > that failed to fix the problem. > > when i manually installed the OLD version of libstdc++: > > 514 dpkg -i /var/cache/apt/archives/libgcc1_1%3a3.2.3-0pre6_i386.deb > 515 dpkg -i /var/cache/apt/archives/libstdc++5_1%3a3.2.3-0pre6_i386.deb > > then it fixed the problem > > ** BUT ** > > i now cannot install gcc 3.3 or anything else that depends on gcc 3.3 > including groff, kernel-package, dselect, dpkg and a WHOLE boat load > of critical packages. > > the only way that i can recover my system back to a useable state is: > > - remove unstable from sources.list > > - deinstall gcc () > > - deinstall python2.2 (!!!) and all of its dependent modules, >python-mysql, htmltmpl, crypto, python-postgres just >to name a few > > - reinstall python2.2 > > - re-add unstable back into sources.list > > - reinstall all of my python modules including python2.2-dev > > > if i do NOT follow this procedure i end up with being either > unable to reinstall or unable to run python. > > > trust me when i say that this is a SERIOUS problem with the > present debian unstable and i guarantee that you will see > more people get into difficulties if they have python2.2 or > any of the other programs that depend on libstdc++5 compiled > with gcc3.2, and gcc3.3 on their system. > > l. > > > > Adding a pre-dpends on libgcc1 in libstdc++5 may help here, but this > > would not catch binaries depending on new symbols in libgcc1, and not > > depending on libstdc++5. > > there are a LOT of broken programs that have exactly this dependency > problem. > > python2.2, update-menus were only two that i noticed and started to > freak out over. > > > Luke Kenneth Casson Leighton writes: > > > Package: libgcc1 > > > Version: 1:3.2.3-0pre6 > > > Severity: critical > > > > > > > > > actions taken: > > > apt-get remove jade > > > > > > this required, at this time, the installation / upgrade of libgcc1 > > > and the installation / upgrade of tetex. > > > > > > gcc 3.3 and cpp 3.3 was NOT required as part of that installation / > > > upgrade. > > > > > > once actioned, python2.2, update-menus, and scores of other programs, > > > failed to operate, with the following error: > > > > > > /usr/lib/libgcc_s.so.1: version 'GCC_3.3' not found (required by > > > /usr/lib/libstdc++.so.5). > > -- > -- > expecting email to be received and understood is a bit like > picking up the telephone and immediately dialing without > checking for a dial-tone; speaking immediately without listening > for either an answer or ring-tone; hanging up immediately and > then expecting someone to call you (and to be able to call you). > -- > every day, people send out email expecting it to be received > without being tampered with, read by other people, delayed or > simply - without prejudice but lots of incompetence - destroyed. > -- > please therefore treat email more like you would a CB radio > to communicate across the world (via relaying stations): > ask and expect people to confirm receipt; send nothing that > you don't mind everyone in the world knowing about... > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: steambox ripper
On Mon, May 19, 2003 at 04:19:31PM +0200, Richard Atterer wrote: > No, sorry - I'm afraid we'll first have to complete our search for the > sheets of ".." before we can work on > your request. Do you realize that every time this is mentioned in the list archives, it gets worse? -- - mdz
Re: steambox ripper
On Mon, May 19, 2003 at 09:06:20PM +1000, RedaComputer wrote: > Could you please help me to find the website from where I am able to > download steambox ripper. No, sorry - I'm afraid we'll first have to complete our search for the sheets of "dueling banjos" before we can work on your request. Richard -- __ _ |_) /| Richard Atterer | CS student at the Technische | GnuPG key: | \/¯| http://atterer.net | Universität München, Germany | 0x888354F7 ¯ '` ¯
Re: Maintaining kernel source in sarge
Hello On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote: > On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote: > > > I'll start here: > > > > Kernel package policy: > "kernel image" to avoid confusion between kernel source, kernel headers, Agreed. > kernel modules, etc. > > -- > > > > * It should only exist one kernel-source package. > > * Every modification to the kernel should be added as a patch package. > > * Modifications may be separated to make it easier to administrate and > > for other people/packages to use it. > > Kernel image packages must include a list of patches which have been > applied, and the packages from which they came. Agreed. > > Kernel module policy: > > - > > > > * Kernel modules must be provided as a "binary source" package. > > * Module source packages should provide a debian/rules file. > > * The debian/rules file must compile the module if KSRC=kernelsourcedir > > and KVERS=versionname is priovided. > > * The debian/rules file may fail if an unsupported version of the kernel is > > provided by the environment. > > * The debian/rules file may fail if no kernel-headers is in that location. > > * The debian/rules file should handke KMAINT and KEMAIL env variables. > > It would be a significant gain if kernel modules could always be built > against kernel-headers, without requiring full kernel-source. Is there any > situation where this is not feasible, or could it be made a requirement? At least the pcmcia and freeswan needs some parts of kernel source to build. At least last time I tried. I have been bitten by this a lot of times. But yes that would be really great if they just have to depend on the kernel source. Regards, // Ola PS. I accidentily deleted two other mails in this thread. Was they just for me or has they not yet been delivered to the mailinglist? DS. > -- > - mdz > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- - Ola Lundqvist --- / [EMAIL PROTECTED] Annebergsslingan 37 \ | [EMAIL PROTECTED] 654 65 KARLSTAD | | +46 (0)54-10 14 30 +46 (0)70-332 1551 | | http://www.opal.dhs.org UIN/icq: 4912500 | \ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 / ---
Re: Maintaining kernel source in sarge
Ola Lundqvist <[EMAIL PROTECTED]> writes: > Kernel module policy: > - > > * Kernel modules must be provided as a "binary source" package. > * Module source packages should provide a debian/rules file. > * The debian/rules file must compile the module if KSRC=kernelsourcedir > and KVERS=versionname is priovided. I'd be slightly happier if the targets kernel-package used were supported here, 'debian/rules kdist-image' and such. (This is to accomodate "binary source" packages that have a single debian/rules file that's copied verbatim from the source package to the binary package; both lm-sensors and i2c work this way, don't know about other packages.) > * The debian/rules file may fail if an unsupported version of the kernel is > provided by the environment. > * The debian/rules file may fail if no kernel-headers is in that location. > * The debian/rules file should handke KMAINT and KEMAIL env variables. ...in fact, this looks a lot like what kernel-package currently documents. Is a separate policy from the kernel-package documentation needed? (FWIW, i2c and lm-sensors both successfully build against only the kernel headers, via the kernel-build-* packages.) -- David Maze [EMAIL PROTECTED] http://people.debian.org/~dmaze/ "Theoretical politics is interesting. Politicking should be illegal." -- Abra Mitchell
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 11:06:16AM -0400, Matt Zimmerman wrote: > > Kernel module policy: > > - > > * Kernel modules must be provided as a "binary source" package. > > * Module source packages should provide a debian/rules file. > > * The debian/rules file must compile the module if KSRC=kernelsourcedir > > and KVERS=versionname is priovided. > > * The debian/rules file may fail if an unsupported version of the kernel is > > provided by the environment. > > * The debian/rules file may fail if no kernel-headers is in that location. > > * The debian/rules file should handke KMAINT and KEMAIL env variables. > It would be a significant gain if kernel modules could always be built > against kernel-headers, without requiring full kernel-source. Is there any > situation where this is not feasible, or could it be made a requirement? I think it's safe to say that if a kernel module package requires something not present in the kernel-headers package for building, there's a bug somewhere. Which is not to say there aren't bugs, of course. -- Steve Langasek postmodern programmer pgpwDosniEoMl.pgp Description: PGP signature
Re: Do not touch l10n files
On Mon, May 19, 2003 at 10:38:47AM -0400, Theodore Ts'o wrote: > The main problem here is support. If uses e2fsck with NLS support > enabled, and with a non-US locale, the messages will come out in their > native language. Which is all very well-and-good until they run into > problems and they start asking me for help. If it's in some language > I don't speak, such as Swahili, I'm going to be very hard pressed to > actually help them. > E2fsprogs may be a special case in that why I get these cries for help > (which mainly are of the form, "help me, I'm a loser, I didn't make > backups, can you help me recover my 10 years of thesis research"), > time is of the essence. So waiting for a translation team to > translate output back into English is not an option. It seems to me this would be mitigated by two factors: 1) if they know enough to realize they should be emailing you in English, they probably realize they need to send the error messages in English too (by running e2fsprogs in English if possible, or providing an impromptu translation if not); 2) in single user mode, where I would expect most of the time-critical support requests to originate, it requires a significant amount of dedication to get a locale other than the C locale. In practice, are you running into support requests where there is a language barrier because of l10n of the e2fsprogs? The VMS-style error codes occurred to me as well. Though if one goes that route, I wonder if gettext any longer has advantages over msgcat. :) -- Steve Langasek postmodern programmer pgpE88IRdiNPh.pgp Description: PGP signature
Re: Maintaining kernel source in sarge
On Mon, May 19, 2003 at 10:02:58AM +0200, Ola Lundqvist wrote: > I'll start here: > > Kernel package policy: "kernel image" to avoid confusion between kernel source, kernel headers, kernel modules, etc. > -- > > * It should only exist one kernel-source package. > * Every modification to the kernel should be added as a patch package. > * Modifications may be separated to make it easier to administrate and > for other people/packages to use it. Kernel image packages must include a list of patches which have been applied, and the packages from which they came. > Kernel module policy: > - > > * Kernel modules must be provided as a "binary source" package. > * Module source packages should provide a debian/rules file. > * The debian/rules file must compile the module if KSRC=kernelsourcedir > and KVERS=versionname is priovided. > * The debian/rules file may fail if an unsupported version of the kernel is > provided by the environment. > * The debian/rules file may fail if no kernel-headers is in that location. > * The debian/rules file should handke KMAINT and KEMAIL env variables. It would be a significant gain if kernel modules could always be built against kernel-headers, without requiring full kernel-source. Is there any situation where this is not feasible, or could it be made a requirement? -- - mdz
Re: Do not touch l10n files
On Sun, May 18, 2003 at 06:55:37PM +0200, Marc Haber wrote: > Highly technical packages like zebra, netfilter-related stuff and > linux-atm are most likely to be used by people who know English. Not > speaking English will make running routers and/or internet security > systems almost impossible anyway. I've done most of the work to internationalize e2fsprogs (at least as far as gettext is concerned; I haven't done the framework to internationalize man pages yet), and while it was done mostly for my own edification, to learn about gettext, I have had some concerns about whether or not Internationalization is actually a *good* thing. The main problem here is support. If uses e2fsck with NLS support enabled, and with a non-US locale, the messages will come out in their native language. Which is all very well-and-good until they run into problems and they start asking me for help. If it's in some language I don't speak, such as Swahili, I'm going to be very hard pressed to actually help them. E2fsprogs may be a special case in that why I get these cries for help (which mainly are of the form, "help me, I'm a loser, I didn't make backups, can you help me recover my 10 years of thesis research"), time is of the essence. So waiting for a translation team to translate output back into English is not an option. Furthermore, when you're dealing with a filesystem which may have been modified by e2fsck during its initial run, the possibility of resetting the locale back to C to defeat the translation may not help, as the second e2fsck run may not have same messages as the first e2fsck run. I suppose that I could try to look at the Swahili's .po file, and try to match the output and turn it back into English, but that will be very, very tedious, and so I won't be able to help as many people when they give me their sad stories of years of research being lost. There are a couple of possible solutions: 1) Someone could write a program which takes output, and a .po file, and tries to undo the translation. This is a lot harder than it might first appear, since the strings may have printf expansions (i.e., %d, %x, and %s, with the last being particularly hard to deal with). 2) Use VMS or VM style message prefixes to make it easier for someone who doesn't under-stand the internationalization to figure out what's going on. (i.e., "SYS-EXT2-YOURFUCKED-14326: Stupid summer intern who shouldn't have been given root access ran mke2fs on half of a MD device", where "SYS-EXT2-YOURFUCKED-14326" is the same regardless of the translation, so it can be easily looked up). 3) Tell users to either not use the NLS support at all for e2fsprogs, or resign themselves to a second-class citizen level of support, simply because the developer can't provide free support in a language he (unfortunately) doesn't understand. Right now the default answer is #3, but that's not very satisfying. Among other things, it calls into question whether or not the internationalization of e2fsprogs was actually a good idea or not, or just a complete waste of time. As for the other possible solutions, I don't have time to write #1, but if someone is looking for a good summer project, I think it would be very useful. - Ted
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 10:01:31PM -0500, Taral <[EMAIL PROTECTED]> was heard to say: > Looks like the python2.2 stuff migrated into testing without noticing > that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) > are advised not to upgrade. aptitude has nothing to do with python-apt. You may be thinking of apt-listchanges. Daniel -- / Daniel Burrows <[EMAIL PROTECTED]> ---\ | It is hard to think of anything | | less sentient than a pumpkin. | | -- Terry Pratchett, _Witches Abroad_| \ Be like the kid in the movie! Play chess! -- http://www.uschess.org ---/
Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
From: Agustin Martin Domingo <[EMAIL PROTECTED]>
Subject: Re: ITP: latex209 -- macro files of LaTeX 2.09 25-mar-1992 version
Date: Fri, 16 May 2003 13:50:39 +0200
> I am cc'ing this message to the debian-tetex-maint list. I think they
> would also like to know about this and will have a much better knowledge
> than I have about how possible it is and the incompatibilities that
> might arise.
Even in the latest teTeX 2.0.2, there are settings in texmf.cnf
as follows;
TEXINPUTS.latex = .;$TEXMF/tex/{latex,generic,}//
TEXINPUTS.latex209 = .;$TEXMF/tex/{latex209,generic,latex,}//
that is, there is basically no problem to provide latex209
macros under $TEXMF/tex/latex209 if the command was called
"latex209".
Thanks, 2003-5-19(Mon)
--
Debian Developer & Debian JP Developer - much more I18N of Debian
Atsuhito Kohda <[EMAIL PROTECTED]>
Department of Math., Tokushima Univ.
Evolution 1.2.4. "mailto:" attachments
Hello Debian-devel, hello Takuo,
I patched Evolution 1.2.4 to be able to send attachments with a "mailto:";
URL. Simply use
evolution 'mailto:[EMAIL PROTECTED]
subject=attachment&body=Hello%20list&attach=/path/to/file'
Please note that this functionality is enclosed in Evolution 1.3 beta, but
not in 1.2.4, the current stable version (AFAIK).
Patching is simple:
--- e-msg-composer.cSat Dec 7 07:09:39 2002
+++
/mnt/images/evolutionchroot/tmp/evolution-1.2.4/build-tree/evolution/composer/e-msg-composer.c
Fri May 16 15:35:27 2003
@@ -3719,7 +3719,9 @@
} else if (!g_strncasecmp (header, "body", len)) {
g_free (body);
body = g_strdup (content);
- } else {
+ } else if (!strncasecmp (header, "attach", len)) {
+e_msg_composer_attachment_bar_attach
(E_MSG_COMPOSER_ATTACHMENT_BAR (composer->attachment_bar), content);
+} else {
/* add an arbitrary header */
e_msg_composer_add_header (composer, header,
content);
}
That's all. Recompile and off you go. You will need additional patches in
debian/control: the libnss3, libnss-dev and libnspr4 dependencies are all
>=2:1.2 here.
.deb-files are to be found at
http://olivier.sessink.nl/~valentyn/evolution-1.2.4/
Use at own risk!
Best regards,
Valentijn
--
http://www.openoffice.nl/ Open Office - Linux Office Solutions
Valentijn Sessink [EMAIL PROTECTED]
Re: DSA's via rsync
> On Mon, 19 May 2003 18:28:19 +1000 > "AP" == Andrew Pollock <[EMAIL PROTECTED]> wrote: AP> AP> AP> This would be made easier if the DSA's were obtainable in a more parseable AP> format. DSA'a are available in RDF. There exists a link on the bottom of www.debian.org/security to it. -- Alexander Kotelnikov Saint-Petersburg, Russia
Re: Debian conference in the US?
* Aaron M. Ucko ([EMAIL PROTECTED]) wrote: > What are other developers' feelings on the matter these days? I'm all for it, and GWU would be most excellent in my view. Of course, I live just outside DC... ;) Stephen pgpSnD1TuI4Jx.pgp Description: PGP signature
Re: Bug#190038: libgtkdatabox_1:0.2.3.0-1(m68k/unstable/thing2): FTBFS on m68k
On Mon, May 19, 2003 at 09:30:52AM +0200, Andreas Tille wrote: > On Sat, 17 May 2003, Junichi Uekawa wrote: > > > > It's strange, because on my i386 system > > > > objdump -T /usr/lib/libgdk-X11-2.0.so gives > > > > > > > > 0002e71c gDF .text 0049 Base_gdk_display_x11_get_type > > > > 00045ebc gDF .text 014c Base_gdk_windowing_window_init > > > > 0005017c gDF .text 0106 BaseXineramaIsActive > > > > 00010a20 gDF .init Base_init > > > > 0002b8b0 gDF .text 0041 Basegdk_image_type_get_type > > > > 00050284 gDF .text 01ba BaseXineramaQueryScreens > > > > DF *UND* 00c3 g_get_charset > > > > 00026e3c gDF .text 0097 Base_gdk_screen_close > > > > > > > > and that probably means the symbol should be defined within that > > > > library. > > > > > > On crest (m68k) this results in: > > > > > > D *UND* XineramaIsActive > > > 00016970 gDF .init Base_init > > > 0002ffd4 gDF .text 004c Basegdk_image_type_get_type > > > D *UND* XineramaQueryScreens > > > DF *UND* 00c6 g_get_charset > > > 0002b8fa gDF .text 009a Base_gdk_screen_close > > > DF *UND* 0148 XkbSetDetectableAutoRepeat > > > > > > Any idea why it seems to be undefined (*UND*) on m68k? > > > > Noone seems to have replied to this mail yet, but > > for this kind of thing to happen, a possible cause would be > > a XineramaQueryScreens function that is expected to be > > defined in a static library (and linked into the > > shared library) was once provided as a shared library. > > > > libXinerama.a is only provided as a static library, > > but apparently, on m68k, I suspect some symbols were provided > > through some shared library, at some time. > Thanks for having a look at problem. I have to admit that I have no idea > what to do to fix the problem. Sorry, should've replied to this thread a bit earlier. The exact problem you're quoting (the Xinerama thing), being a bug in libgtk2.0 on m68k only, was of course known to us m68k porters. It turned out to be a problem with logtool, which has now been fixed. The new libgtk2.0 package is linked correctly again. However, that's not why the bug was filed. There are a lot of undefined references to other functions in the bugreport, that have nothing to do with the (now fixed) Xinerama-problem. You may want to check them out. -- Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org "An expert can usually spot the difference between a fake charge and a full one, but there are plenty of dead experts." -- National Geographic Channel, in a documentary about large African beasts. pgpydMs56iBgB.pgp Description: PGP signature
steambox ripper
Hi, Could you please help me to find the website from where I am able to download steambox ripper. Thanks, Reda.
Re: DSA's via rsync
On Mon, May 19, 2003 at 06:28:19PM +1000, Andrew Pollock wrote: > This would be made easier if the DSA's were obtainable in a more parseable > format. Currently they're being retrieved from > http://www.debian.org/security/ via a recursive wget. Perhaps CVS would be easier? :pserver:[EMAIL PROTECTED]/cvs/webwml, module webwml, /english/security. You may need some extra bits to build the WML files. -- Colin Watson [EMAIL PROTECTED]
DSA's via rsync
As previously mentioned on this list, where I work, we have a sizeable chunk of infrastructure that can't connect out to a Debian mirror[1] One of my colleages has written a script, which works on the /var/lib/dpkg/status file on a host that may require updating comparing it against the /var/lib/apt/lists/security.debian.org_debian-security_dists_stable_updates_*Packages files and then generating a list along with the appropriate DSAs, of the packages that require updating. This would be made easier if the DSA's were obtainable in a more parseable format. Currently they're being retrieved from http://www.debian.org/security/ via a recursive wget. Would it be possible, and would it be beneficial to anyone else, if they were made available individually via rsync? Andrew [1] http://lists.debian.org/debian-devel/2003/debian-devel-200305/msg00468.html
Re: Maintaining kernel source in sarge
Hello
On Sun, May 18, 2003 at 04:52:54PM +0200, Martin Schulze wrote:
*SNIP*
> Removing one kernel version and including another without rebuilding
> all modules packages will break several installations. Not removing
> the old packages will make the archive grow through time which will
> cause problems with CD build scripts.
>
> Hence, it is important that when a new kernel is added (e.g. for
> security reasons) an older package is removed *and* all relevant
> modules packages are rebuilt and included as well.
Rebuilding module pacakges is not always trivial. I hope that code
can help some. The reason is that most of them depend on a kernel-tree
that is already compiled. The following code fixes that (at least for my
situations).
I use it to compile modules for custom kernels. If you want me to make a command
line tool, just tell me. :)
Modify it as you wish.
# This file should be sourced by a file that sets the following variables.
#revision=01
#kernver=2.4.19
#arch=686
#append=freeswan+vlan+mppe+ctx+netboot+raid
#clean=no
#prepmods=
# Reasonable defaults
#E=${revision:=01}
# Some other settings.
srcdir=/usr/src
kernbdir=kernel-source-$kernver
curdir=`pwd`
modsrcdir=modules
kernsrcdir=$curdir/$kernbdir
FAKE=
if [ "$UID" != "0" ] ; then
FAKE=fakeroot
fi
if [ -z "$maint" ] ; then
I="[^:][^:]*"
maint=$(grep "^$USER:" /etc/passwd | \
sed "s|$I:$I:$I:$I:||;s|[,:].*||;")
fi
if [ -z "$email" ] ; then
email="$EMAIL"
fi
if [ "$cleanall" = "yes" -a -d "$modsrcdir" ] ; then
for d in $(find $modsrcdir -type d -mindepth 1 -maxdepth 1) ; do
rm -Rf $d
done
fi
if [ ! -d $kernbdir ] ; then
echo "Unpacking source kernel-source-$kernver.tar.bz2"
tar xfj $srcdir/kernel-source-$kernver.tar.bz2
else
echo "CD $kernbdir"
cd $kernbdir
if [ -d "debian" ] ; then
$FAKE debian/rules clean < I would be glad if somebody could investigate the modules situation
> and describe which modules packages require which kernel versions
> (and/or depend on which other packages).
>
> I also wonder if there are efforts in progress to unify the kernel
> source through more than two architectures? This would require a
> group or architecture maintainers (current kernel package mantainers)
> to work collaboratively towards this goal.
A policy for kernel, kernel-patcha and kernel-module packages should be
great.
I'll start here:
Kernel package policy:
--
* It should only exist one kernel-source package.
* Every modification to the kernel should be added as a patch package.
* Modifications may be separated to make it easier to administrate and
for other people/packages to use it.
Kernel module policy:
-
* Kernel modules must be provided as a "binary source" package.
* Module source packages should provide a debian/rules file.
* The debian/rules file must compile the module if KSRC=kernelsourcedir
and KVERS=versionname is priovided.
* The debian/rules file may fail if an unsupported version of the kernel is
provided by the environment.
* The debian/rules file may fail if no kernel-headers is in that location.
* The debian/rules file should handke KMAINT and KEMAIL env variables.
What do you think?
Regards,
// Ola
> Regards,
>
> Joey
>
> --
> Ten years and still binary compatible. -- XFree86
>
> Please always Cc to me when replying to me on the lists.
>
>
> --
> To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
>
--
- Ola Lundqvist ---
/ [EMAIL PROTECTED] Annebergsslingan 37 \
| [EMAIL PROTECTED] 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---
Re: [RFC] Chapter for the debian reference about l10n
On Mon, 19 May 2003, Martin Quinson wrote: > I repost this because I got no feedback at all. I guess it shows that my > email was long enough for not being read :) Or there is no other comment from my side than: Go for it! It is an important topic! Kind regards Andreas.
[RFC] Chapter for the debian reference about l10n
Hello, I repost this because I got no feedback at all. I guess it shows that my email was long enough for not being read :) Thanks, Mt. On Wed, May 14, 2003 at 05:29:00PM +0200, Martin Quinson wrote: > In order to help the current discution to find an usefull conclusion, I > would like to propose you the following blahblah for inclusion in the debian > reference "Managing packages" chapter, for example after the one on porting > and geting ported. This is very far from being perfect, and I would be more > than happy to discuss it before the actual inclusion. But, please, do > respect the reply-to to debian-i18n, so that we discuss it on the right ML. > > Friendly, Mt. > > > >> Internationalizing, translating and being internationalized and translated Debian supports an ever-increasing number of natural language. Even if you are native english speaker and do not speak any other language, it is part of your duty as a maintainer to be aware of issues of internationalization (abbreviated i18n because there is 18 letters between the 'i' and the 'n' in internationalization). Therefore, even if you are ok with english only programs, you should read most of this chapter. According to "Introduction to i18n" from Tomohiro KUBOTA, (http://www.debian.org/doc/manuals/intro-i18n/), "I18N (internationalization) means modification of a software or related technologies so that a software can potentially handle multiple languages, customs, and so on in the world." while "L10N (localization) means implementation of a specific language for an already internationalized software." l10n and i18n are tied, but the difficulties related to each of them are very different. It's not really difficult to allow the program to change the language in which texts are displayed based on user settings, but it is very time consuming to actually translate the messages. On the other hand, setting the character encoding is trivial, but adapting the code to use several character encodings is a really hard problem. Letting alone the i18n problems, where no general receipt exist, there is actually no central infrastructure for l10n within Debian which could be compared to the dbuild mecanism for porting. So, most of the work have to be done manually How are handled translations within Debian? === Handling translation of the texts contained in a package is still a manual task, and the process depends on the kind of text you want to see translated. For program messages, the gettext infrastructure is used most of the time. Most of the time, the translation is handled upstream within projects like the Free Translation Project (http://www.iro.umontreal.ca/contrib/po/HTML/), the Gnome translation Project (http://developer.gnome.org/projects/gtp/) or the KDE one (http://i18n.kde.org/). The only centralized resource within Debian is the Central Debian translation statistics (http://www.debian.org/intl/l10n/), where you can find some statistics about the translation files found in the actual package, but no real infrastucture to ease the translation process. An effort to translate the package descriptions started long ago even very few support is offered by the tools to actually use them (ie, only APT can use them, when configured correctly). There is nothing to do for the maintainers, and the translators should use the DDTP (http://ddtp.debian.org/). For debconf templates, maintainer should use the po-debconf package to ease the work of your translators, which should use the DDTP to do their work. Some statistics can be found both on the DDTP site (about what is actually translated), and on the Central Debian translation statistics site (http://www.debian.org/intl/l10n/ -- about what is integrated in the packages). For webpages, each l10n team have access to the relevant CVS, and the statistics are available from the Central Debian translation statistics site. For general documentation about debian, the process is more or less the same than for the webpages (the translators have an access to the CVS), but there is no statistics pages. For package specific documentation (man pages, info document, other formats), almost everything have yet to be done. Most notably, the KDE project handles translation of its documentation in the same way than its program messages. Debian specific man pages begin to be handled within a specific CVS repository (http://cvs.debian.org/manpages/?cvsroot=debian-doc). I18N & L10N FAQ for maintainers === This is a list of problems that maintainers may face concerning i18n and l10n. While reading this, keep in mind that there is no real consensus on those points within Debian, and that they are only advices. If you have a better idea for a given problem, or if you disagree on some points, feel free to provide your feedback, so that this document can be enhanced. How to get a given text translated? ---
Re: Where are translated man pages packaged?
On Fri, May 16, 2003 at 10:02:18PM +0200, Fabio Massimo Di Nitto wrote: > On Fri, 16 May 2003, Keegan Quinn wrote: > > > On Friday 16 May 2003 11:45 am, Fabio Massimo Di Nitto wrote: > > > On Fri, 16 May 2003, Keegan Quinn wrote: > > > > > more than once i had to install small dns servers on boxes with less > > > > > than 100Mb flash and stuff like that... so basically also the minimal > > > > > installation has to be tight.. then rm doc and man and after install > > > > > the minimum sets of pkgs to provide the services. > > > > > > > > Please do not try to force this methodology upon the standard Debian > > > > base > > > > system. Administrators of embedded systems have many tools to deal with > > > > these problems already, that do not require ever unpacking the full base > > > > onto the target. > > > > > > sorry but i can hardly read from the previous post that i am trying to > > > force something to someone. I guess this is just a misunderstanding. > > > > Perhaps the word 'force' was a bit harsh, but it's essentially how it works > > for an end-user. It seemed to me that you were suggesting that the standard > > installer should be optimized for embedded systems, which does not sound > > like > > a very good idea. These systems have many specialized needs which cannot be > > easily accounted for. > > No i was not suggesting either. I was just explaining why i would like to > avoid to get a bigger base system and giving out one of the reason. it was > an example, no more no less. anyway no big deal ;) Ok, so, it wouldn't hurt anyone if all translated man pages were along the original one, or did I miss something again ? Thanks, Mt. -- Dans la france profonde, il y a surtout des spéléologues. -- Le Chat
Re: Bug#190038: libgtkdatabox_1:0.2.3.0-1(m68k/unstable/thing2): FTBFS on m68k
On Sat, 17 May 2003, Junichi Uekawa wrote: > > > It's strange, because on my i386 system > > > objdump -T /usr/lib/libgdk-X11-2.0.so gives > > > > > > 0002e71c gDF .text 0049 Base_gdk_display_x11_get_type > > > 00045ebc gDF .text 014c Base_gdk_windowing_window_init > > > 0005017c gDF .text 0106 BaseXineramaIsActive > > > 00010a20 gDF .init Base_init > > > 0002b8b0 gDF .text 0041 Basegdk_image_type_get_type > > > 00050284 gDF .text 01ba BaseXineramaQueryScreens > > > DF *UND* 00c3 g_get_charset > > > 00026e3c gDF .text 0097 Base_gdk_screen_close > > > > > > and that probably means the symbol should be defined within that library. > > > > On crest (m68k) this results in: > > > > D *UND* XineramaIsActive > > 00016970 gDF .init Base_init > > 0002ffd4 gDF .text 004c Basegdk_image_type_get_type > > D *UND* XineramaQueryScreens > > DF *UND* 00c6 g_get_charset > > 0002b8fa gDF .text 009a Base_gdk_screen_close > > DF *UND* 0148 XkbSetDetectableAutoRepeat > > > > Any idea why it seems to be undefined (*UND*) on m68k? > > Noone seems to have replied to this mail yet, but > for this kind of thing to happen, a possible cause would be > a XineramaQueryScreens function that is expected to be > defined in a static library (and linked into the > shared library) was once provided as a shared library. > > libXinerama.a is only provided as a static library, > but apparently, on m68k, I suspect some symbols were provided > through some shared library, at some time. Thanks for having a look at problem. I have to admit that I have no idea what to do to fix the problem. Kind regards Andreas.
Re: Debian conference in the US?
* Aaron M. Ucko ([EMAIL PROTECTED]) [030519 04:26]: > * As mentioned, we have an enthusiastic sponsor lined up, which is a > definite plus. What do we get from that sponsor? Conference rooms, network, accomodation, food, flights and tshirts?
Re: Do not touch l10n files (was Re: DDTP issue)
On Sun, 18 May 2003, Denis Barbier wrote: > [All Cc's removed] > > On Sat, May 17, 2003 at 07:54:55AM +0200, Fabio Massimo Di Nitto wrote: > [...] > > I don't believe that there is not an estestic layout that can satisfy > > all the languages we have in Debian. > > What is the rationale for having a single layout for all languages? since we are talking about estetic, i believe that it looks nicer keeping the layout coherent across translation. > How do developers check how translations are rendered? sorry but i don't understand what you mean. > > Don't forget that most of the text we use in descriptions (or > > templates, or whatever) are based on technical language and terms, > > imho most of them farly new i would say and only recently adopted by > > common languages. > > Could you please be more explicit? I do not understand how this sentence > is related to the issue discussed here. I will make a couple of example so we can understand each other better but they are just examples that i don't mind to discuss, but out of the mailing list since it will become too much off-topic imho. When you translate old literature, for instance, it is extremely difficult since you have to stick to tons of rules (ancient and new ones) and probably you will have to use some obsolete terms in your language that correspond to the same one in the other. In a case like this you need to apply atleast 3 grammatic rule sets. the old one in the other language, the old one in your language and the new one in your langauge, and if you don't do that in a really pedantic way you will loose everything of the meaning of the original text. Now evaluate computer related terms. They are not older than 20 years, only some of them have been accepted in common languages (read dictionaries), and in most cases we inveted new terms that will probably never flow in laguages other than computer ones. Think to something like: "I've debianized X4.3! ;-)" (an exagerate example but just to get the idea) in italian i would translate in something like: "Ho debianizato X4.3! ;-)". The verb "to debianize" doesn't exist in any dictionary other than the "Debian one" but somehow we imported it and adapted to out language. Keeping the same meaning and a very close layout. Point is that this is a shorcut to a more long and possibly boring translation that will look like: "Io ho creato un pacchetto Debian che contiene i binari di X4.3" (exagerated a bit in the other way but still just to get the idea). Somehow the language evolves and since computer related language is farly new i don't see any problem in adapting it a bit for our targets. Of course you might argue that is not clean but afaik noone has ever really set rules for cases like this one. The point is that using a farly new language gives us a bit more freedom than using a normal language in a strict way. Can you see my point? Fabio -- Our mission: make IPv6 the default IP protocol "We are on a mission from God" - Elwood Blues http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp4.html
Re: Debian conference in the US?
Ben Collins <[EMAIL PROTECTED]> writes: >> What are other developers' feelings on the matter these days? > > If we're doing "let's have a conf where we normally don't" how about we > have it on the US's east coast aswell. I'd personally argue for the > nothern Virginia are myself. > > Too many conferences are held on the US's West coast, and if conferences > do get to the East coast, they are always in New York. That leaves the > south eastern US folks out in the cold. Wrong. It doesn't get cold out in the southeastern US. :P -- Looks like excitement by repetition!
Re: Warning: python-apt in testing broken, aptitude users DO NOT UPGRADE
On Sun, May 18, 2003 at 11:29:14PM -0500, Adam Majer wrote: > On Sun, May 18, 2003 at 10:01:31PM -0500, Taral wrote: > > Looks like the python2.2 stuff migrated into testing without noticing > > that it breaks python-apt. Anyone using python-apt (e.g. aptitude users) > > are advised not to upgrade. > > > > Anyone know how exactly the testing scripts managed to miss this > > breakage? > > I'm just guessing here (didn't check yet), but isn't it more likely that > people just didn't file a bug against python2.2? python-apt has a very clear set of deps: Depends: python (>= 2.1), python (<< 2.2), ... That's NOT satisfied anymore in the current testing. -- Taral <[EMAIL PROTECTED]> This message is digitally signed. Please PGP encrypt mail to me. "Most parents have better things to do with their time than take care of their children." -- Me pgpabX9jDlwvy.pgp Description: PGP signature
Re: Warning: python-apt in testing broken, ** apt-listchanges ** users DO NOT UPGRADE
> Huh? What's aptitude got to do with python-apt? > > Package: aptitude > Version: 0.2.11.1-3 > Depends: libapt-pkg-libc6.2-3-2-3.2, libc6 (>= 2.2.4-4), libncurses5 (>= > 5.2.20020112a-1), libsigc++0, libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810) Okay, I feel like an idiot. It's supposed to be apt-listchanges, not aptitude. -- Taral <[EMAIL PROTECTED]> This message is digitally signed. Please PGP encrypt mail to me. "Most parents have better things to do with their time than take care of their children." -- Me pgpE5rH4YfQTY.pgp Description: PGP signature
