Dark Age of Camelot Support Autoresponse
This is an auto-reply from Dark Age of Camelot support. Please do not reply to this e-mail. Your account transfer e-mail must have a valid account ID as the subject. DAoC Customer Support -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Auslaenderpolitik
Thank you for contacting Dark Age of Camelot Support. Your email has been received and you should expect a response from the Technical Team within 72 hours. Please be sure to have any e-mail spam filters properly configured to allow [EMAIL PROTECTED] through (so that further responses are not blocked). A ticket has been opened for you in our CS database: 5129812 IMPORTANT: If you are having a problem in-game, you must use the /APPEAL command in-game to get help. You will ONLY receive a response from this e-mail address for technical or billing related issues. If you are experiencing a technical issue that is preventing you from entering the game, please refer to our knowledge base on the web, located here: http://support.darkageofcamelot.com/kb/ Also, feel free to call our support center at 703-934-0169. Phone support is available Monday through Friday, between the hours of 11am and 8pm EST. If you are having an issue relating to game play and can enter the game, please utilize our In-Game Support by using the /appeal command. In-Game Support is available 24 hours a day, 7 days a week. A ticket has been opened for you in our CS database: 5129812 Thank you, Dark Age of Camelot Support --- If you are a European customer, please contact GOA, our European partners, for technical support at http://www.camelot-europe.com/. We cannot answer questions about the European version as that is handled by a different company. Si vous êtes un client européen, merci de bien vouloir contacter GOA, notre partenaire en Europe : vous trouverez un lien vers leur support technique à l'adresse http://www.camelot-europe.com . Nous ne pouvons répondre à des questions concernant la version européenne de DAoC, celle-ci étant gérée par une société différente. Sollten Sie ein Kunde der europäischen Version von DAoC sein, so kontaktieren Sie für den Customer Support bitte GOA, unseren europäischen Partner, unter der Adresse http://www.camelot-europe.com/. Da die europäische Version nicht von uns betrieben wird können wir Ihnen leider keine Hilfe zu Ihren Fragen anbieten. Se sei un giocatore italiano, puoi inoltrare le tue richieste di assistenza tecnica a CTOnet, il nostro partner italiano. Puoi metterti in contatto con loro tramite il sito di gioco al seguente indirizzo: http://www.daoc.it via email inoltrando le tue richieste al seguente indirizzo: [EMAIL PROTECTED] Non possiamo rispondere direttamente a domande relative alla versione italiana del gioco, che è gestita direttamente da CTOnet. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: new cogito package, OpenSSL license issue resolved
On Sat, May 14, 2005 at 08:19:38AM -0600, Sebastian Kuzminsky wrote: > > > This is the last issue I know of keeping this package out of the Debian > > > archives. Yay! There's still the manpage issue, but I expect it will > > > be resolved upstream in the next few days. > > > > Any chance you can make the package use the included assemly sha1 > > implementation on powerpc? It's a notable difference and with that > > change I could switch from self-compiled cognito to the package. > > > I've updated my Cogito source package (0.10+20050513-3) to use the > ppc-sha1 on powerpc, but I dont have a powerpc machine to compile on, > so I haven't tested it. It still uses mozilla-sha1 on all the other > architectures. Works just fine. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Sat, May 14, 2005 at 11:07:36AM +0200, Thomas Hood wrote: > On Wed, 11 May 2005 12:30:21 +0200, Adrian Bunk wrote: > > Completely MIA maintainers are one part of the problem. > > > > But then there's the class of maintainers who manage to upload a new > > upstream version and perhaps fix some RC bugs every few months but are > > not able to properly handle all bugs in their packages. > > > In part this is a consequence of scarce manpower. In part it is a > consequence of the institution of package ownership and other > organisational flaws. If you agree with this diagnosis then I am curious > to know which of the following you plan to do. > > 1. continue to participate in the Debian project despite its >dysfunctional organisation; > 2. push for changes to the organisation; > 3. participate in another project instead. > > (There are other possibilities, of course.) Some years ago the only choice for me was 1) since 2) was not possible for an average Debian maintainer. I was glad to hear if this had changed since I left. > Thomas Hood cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: packages missing from sarge
On Wed, May 11, 2005 at 09:33:36PM -0700, Steve Langasek wrote: > On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > > Steve Langasek schrieb: > > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > > >>not just get 2.3.x pushed into sarge? Are there any other big issues > > >>with it, that weren't in 2.2.x? Some people might certainly like the > > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > > >>fine for me though --- anything but 2.1.x for me :-) > > Mainly because 2.3.x causes other openswan boxes to crash in some > > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > > keep bugging upstream with it for at least 3 months. No fix until now, > > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > > even 2.2.0-5). > > > > Because 2.2.3 is no longer in the archive, and resurrecting new binaries > > > via > > > t-p-u gives us even less than the usual protection against breakage caused > > > by a lack of testing. :/ > > Does that mean that the only way to get the known stable 2.2.0-x back > > into testing is an upload to unstable with an epoch? I really wouldn't > > like to go that route if I can avoid it > > Well, AFAIK openswan has never actually been in testing /before/, so it's > not a matter of getting it /back/; but yes, the upshot is that I'm not > comfortable adding packages to testing via t-p-u. That's wrong, openswan was in testing earlier this year. Read e.g. [1]. > Steve Langasek cu Adrian [1] http://lists.debian.org/debian-release/2005/01/msg00181.html -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309241: ITP: dguitar -- Guitar Pro 3/4 tabs viewer and player
Package: wnpp Severity: wishlist Owner: Grzegorz Bizon <[EMAIL PROTECTED]> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Package name: dguitar Version : 0.4.2 Upstream Author : Mauricio Gracia Gutierrez <[EMAIL PROTECTED]> * URL : http://dguitar.sourceforge.net/ * License : GPL Description : Guitar Pro 3/4 tabs viewer and player DGuitar is a Guitar Pro (*.GP4,*.GP3,GTP) tabs viewer and player written in java. . Homepage - http://dguitar.sourceforge.net - -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.11.7 Locale: LANG=pl_PL, LC_CTYPE=pl_PL (charmap=ISO-8859-2) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQFCh733THuAN98y9TERAllSAKDfhOLlEsu6joa46u2IfR9ca5eorACfbwDh 6V63MldogVkCAvhV66SETEw= =9rf4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#309237: ITP: libkbanking -- KDE bindings for AqBanking
Package: wnpp Severity: wishlist Owner: Mark Purcell <[EMAIL PROTECTED]> * Package name: libkbanking Version : 0.9.9 Upstream Author : Martin Preuss<[EMAIL PROTECTED]> * URL : http://sourceforge.net/projects/aqbanking/ * License : GPL Description : KDE bindings for AqBanking AqBanking provides a middle layer between the applications and online banking libraries implementing various file formats and protocols. This package provides the KDE bindings and is used by packages such as kmymoney2. -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-2-686 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adduser: what is the difference between --disabled-password and--disabled-login
> "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: Steve> It does, if you use the authorization checks in PAM. If Steve> you only use the authentication checks, then PAM is only Steve> going to authenticate the user -- not check whether they're Steve> allowed access. When you say "authorization checks" vs "authentication checks" what do you mean? PAM has the following sections "auth", "account", "password", "session". All of these are configured by default on Debian. The implication I got when reading Marc's post (or did I read too much into it?) is if ssh is configured to use PAM and if you use RSA based authentication, it won't detect if the account is locked. I fail to see where terms like "authorization" and "authentication" fit into its configuration scheme. If I did misread Marc's post, and pam_unix does the right thing, this doesn't excuse pam_ldap for not doing the right thing either (as shown in my test results I already posted). Steve> This leaks information to attackers about the state of the Steve> account. Only if the attackers are able to successfully authenticate as you. If they can authenticate as you, then security is potentially lost anyway, right? ...unless the solution to the error is to update the password, but in that case leaking the information doesn't have any downside. Perhaps the only exception I can think of is if the account is locked due to "too many login attempts" as opposed to "password expired" or "account has expired" or some other predictable reason. Then, yes, that would be a problem. -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Against which package should this go?
> "Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: Bernd> I think it is a good idea. Even if we dont move to a web Bernd> based system there is no harm to support us web browser Bernd> users a bit :) Bernd> And consider especially the end-user. Also consider forwarding bugs to upstream, etc. They may not understand our BTS system, or how to access the full details of the bug. I often mention the URL by entering it manually, but this is potentially error prone (one day I suspect I will end up accidently cutting & pasting either the wrong bug id, or http://bugs.debian.org.au/123456> or http://bugs.debian.org/#123456>; all of these are wrong). The downside though is that this would require the BTS software to edit the email message, deal correctly with MIME attachments, etc. I think mailing list software does this correctly though(?), so it should be possible. Another option would be to add-yet-another-cool-macro to Gnus/the-kitchen-sink... errr.. I mean Gnus/emacs... that somehow does the task automatically if I-can-remember-the-stupid-sequence-of-keys-I-invent-to-activate-it, but I don't have the time or patience to learn that awful-programming-language-that-requires-lots-of-nested-brackets... errr... I mean LISP... right now. ;-) However, this won't work anyway for people stuck using lesser MUAs (e.g. mutt), fake MUAs (e.g. evolution), or worse (e.g. anything written by or for Microsoft). -- Brian May <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adduser: what is the difference between --disabled-password and--disabled-login
On Mon, May 16, 2005 at 08:22:26AM +1000, Brian May wrote: > > "Steve" == Steve Langasek <[EMAIL PROTECTED]> writes: > Steve> It does, if you use the authorization checks in PAM. If > Steve> you only use the authentication checks, then PAM is only > Steve> going to authenticate the user -- not check whether they're > Steve> allowed access. > When you say "authorization checks" vs "authentication checks" what do > you mean? > PAM has the following sections "auth", "account", "password", > "session". All of these are configured by default on Debian. The > implication I got when reading Marc's post (or did I read too much > into it?) is if ssh is configured to use PAM and if you use RSA based > authentication, it won't detect if the account is locked. > I fail to see where terms like "authorization" and "authentication" > fit into its configuration scheme. The PAM "auth" section is for authentication, and the "account" section is for (account) authorization. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: packages missing from sarge
On Sun, May 15, 2005 at 10:49:10PM +0200, Adrian Bunk wrote: > On Wed, May 11, 2005 at 09:33:36PM -0700, Steve Langasek wrote: > > On Tue, May 10, 2005 at 11:10:10AM +0200, Rene Mayrhofer wrote: > > > Steve Langasek schrieb: > > > >>If that 2.3.x bug really only affects the newer (> 2.6.8) kernel, why > > > >>not just get 2.3.x pushed into sarge? Are there any other big issues > > > >>with it, that weren't in 2.2.x? Some people might certainly like the > > > >>agressive mode support, or 2.3.1's NAT-T fixes. Personally, 2.2.x is > > > >>fine for me though --- anything but 2.1.x for me :-) > > > Mainly because 2.3.x causes other openswan boxes to crash in some > > > (reproducable) cases - that's a pretty bad regression from 2.2.0 and I > > > keep bugging upstream with it for at least 3 months. No fix until now, > > > so we can't wait until it will be fixed. I would vote for 2.2.0-4. (or > > > even 2.2.0-5). > > > > > > Because 2.2.3 is no longer in the archive, and resurrecting new > > > > binaries via > > > > t-p-u gives us even less than the usual protection against breakage > > > > caused > > > > by a lack of testing. :/ > > > Does that mean that the only way to get the known stable 2.2.0-x back > > > into testing is an upload to unstable with an epoch? I really wouldn't > > > like to go that route if I can avoid it > > Well, AFAIK openswan has never actually been in testing /before/, so it's > > not a matter of getting it /back/; but yes, the upshot is that I'm not > > comfortable adding packages to testing via t-p-u. > That's wrong, openswan was in testing earlier this year. Read e.g. [1]. Ah, ok. I couldn't seem to find any references to that the last time the question came up, and whichever member of the release team did the actual removal apparently didn't leave a trace. Still, the concerns about re-adding this software version (which has been out of testing for months) via t-p-u remain. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
need help on #271678 (sizefo struct?)
Hello, On Sat, May 14, 2005 at 06:36:21PM +0200, Cesare Tensi wrote: > The bugs #271678 (also #302181) is fixed in -10, so you can close it. > (X25 Compiled problem). It is not fixed, the code still reads sizeof(struct x25_address) and I think this is correct, since it compiles with recent GCC. I tagged this needhelp, cause I dont eat C language spec for dinner, but i am quite sure the bug report is invalid. Greetings Bernd -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Against which package should this go?
Brian May wrote: >>"Bernd" == Bernd Eckenfels <[EMAIL PROTECTED]> writes: > > > Bernd> I think it is a good idea. Even if we dont move to a web > Bernd> based system there is no harm to support us web browser > Bernd> users a bit :) > > Bernd> And consider especially the end-user. > > Also consider forwarding bugs to upstream, etc. They may not > understand our BTS system, or how to access the full details of the > bug. > > I often mention the URL by entering it manually, but this is > potentially error prone (one day I suspect I will end up accidently > cutting & pasting either the wrong bug id, or > http://bugs.debian.org.au/123456> or > http://bugs.debian.org/#123456>; all of these are wrong). > > The downside though is that this would require the BTS software to > edit the email message, deal correctly with MIME attachments, etc. I > think mailing list software does this correctly though(?), so it > should be possible. > Apparently, (as I mentioned in a previous post) someone came up with this ages ago: http://bugs.debian.org/9596 It is even tagged with a patch, though that only happened a couple of months ago. Hopefully, the fix will be integrated soon. I don't think that the problem you mention is a bug hurdle, though. People constantly send signed message to the Debian list and the mailing list software appends the boilerplate footer to every message without b0rking the signatures. > Another option would be to add-yet-another-cool-macro to > Gnus/the-kitchen-sink... errr.. I mean Gnus/emacs... that somehow does > the task automatically if > I-can-remember-the-stupid-sequence-of-keys-I-invent-to-activate-it, > but I don't have the time or patience to learn that > awful-programming-language-that-requires-lots-of-nested-brackets... errr... I > mean LISP... right now. ;-) > Sorry. I'm not an emacs user :-) > However, this won't work anyway for people stuck using lesser MUAs > (e.g. mutt), fake MUAs (e.g. evolution), or worse (e.g. anything > written by or for Microsoft). Personally, I use Mozilla Thunderbunny (when will they get a proper reply-to-list button? is it that hard?) at home and Horde when I am at school. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~sanchezr signature.asc Description: OpenPGP digital signature
Re: need help on #271678 (sizefo struct?)
Bernd Eckenfels <[EMAIL PROTECTED]> writes:
> Hello,
> On Sat, May 14, 2005 at 06:36:21PM +0200, Cesare Tensi wrote:
>> The bugs #271678 (also #302181) is fixed in -10, so you can close it.
>> (X25 Compiled problem).
> It is not fixed, the code still reads sizeof(struct x25_address) and I
> think this is correct, since it compiles with recent GCC. I tagged this
> needhelp, cause I dont eat C language spec for dinner, but i am quite
> sure the bug report is invalid.
sizeof(x25_address) returns the size of the typedef or variable by the
name x25_address. This isn't the same thing as the struct definition
named x25_address; in fact, they may be completely unrelated.
This is a woody vs. sarge difference. On sarge, linux/x25.h says:
struct x25_address {
char x25_addr[16];
};
so the current code, with sizeof(struct x25_address) is correct and
changing it would actually break the code. On woody, linux/x25.h says:
typedef struct {
charx25_addr[16];
} x25_address;
which means that sizeof(x25_address) is correct and the current code won't
compile (because nothing ever creates a struct x25_address, just an
anonymous struct that is typedef'd to x25_address). This is an
incompatible change in the kernel headers, and there isn't any way for the
code to compile on both systems without some additional portability work.
If you don't care about supporting woody, the current code is correct.
--
Russ Allbery ([EMAIL PROTECTED])
Re: ***SPAM*** Tuerkei in die EU - 1B9665EBA451
This is an automated response. Thank you for contacting RedEnvelope Customer Service. We will respond to your inquiry within one business day. If you have an urgent Customer Service issue, please call us toll-free at 1-877-733-3683. We look forward to responding to your email. Regards, RedEnvelope Customer Service Email: [EMAIL PROTECTED] Web: www.redenvelope.com Phone: 1-877-REDENVELOPE (1-877-733-3683) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#302181: need help on #271678 (sizefo struct?)
Hello Russ,
thanks for your help!!!
Ok, I could inline the definition and be happy or go with the sarge version.
In the past i tried to do nasty ifdef tricks to be portable, but I found
out that inlining those declarations is easier and more robust. In case of
networking the layout cant change, anyway.
Greetings
Bernd
On Sun, May 15, 2005 at 07:44:25PM -0700, Russ Allbery wrote:
> Bernd Eckenfels <[EMAIL PROTECTED]> writes:
>
> > Hello,
>
> > On Sat, May 14, 2005 at 06:36:21PM +0200, Cesare Tensi wrote:
> >> The bugs #271678 (also #302181) is fixed in -10, so you can close it.
> >> (X25 Compiled problem).
>
> > It is not fixed, the code still reads sizeof(struct x25_address) and I
> > think this is correct, since it compiles with recent GCC. I tagged this
> > needhelp, cause I dont eat C language spec for dinner, but i am quite
> > sure the bug report is invalid.
>
> sizeof(x25_address) returns the size of the typedef or variable by the
> name x25_address. This isn't the same thing as the struct definition
> named x25_address; in fact, they may be completely unrelated.
>
> This is a woody vs. sarge difference. On sarge, linux/x25.h says:
>
> struct x25_address {
> char x25_addr[16];
> };
>
> so the current code, with sizeof(struct x25_address) is correct and
> changing it would actually break the code. On woody, linux/x25.h says:
>
> typedef struct {
> charx25_addr[16];
> } x25_address;
>
> which means that sizeof(x25_address) is correct and the current code won't
> compile (because nothing ever creates a struct x25_address, just an
> anonymous struct that is typedef'd to x25_address). This is an
> incompatible change in the kernel headers, and there isn't any way for the
> code to compile on both systems without some additional portability work.
>
> If you don't care about supporting woody, the current code is correct.
>
> --
> Russ Allbery ([EMAIL PROTECTED])
