Re: glx for ia32 applications does not work
Javier Kohen wrote: Does your user have permission to access DRI? Yes, I have got this section in my XF86Config-4, but I have disabled the module 'Load dri' for the nvidia driver. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
AW: Asus A8V Deluxe, Xfree display problems with BIOS 1011
Hiho.. So whats the point about your actual problem: Did you updated your BIOS or so ? I recently switched to debian back again. Because these same strange things used to happen under gentoo too. Thought it had something to do with the patchtree they are aplyiing to their sources. You might want to take a look at the corresponding gentoo-forum thread (more than 28 pages): http://forums.gentoo.org/viewtopic-t-198023-highlight-lockups.html But that puts the whole case under another light. ingo
Re: Asus A8V Deluxe, Xfree display problems with BIOS 1011
Le 10.05.2005 11:44:28, Jean-Luc Coulon (f5ibh) a écrit : Le 10.05.2005 11:25:59, Jannick Ingo a écrit : Hiho.. So whats the point about your actual problem: Did you updated your BIOS or so ? I recently switched to debian back again. Because these same strange things used to happen under gentoo too. Thought it had something to do with the patchtree they are aplyiing to their sources. You might want to take a look at the corresponding gentoo-forum thread (more than 28 pages): http://forums.gentoo.org/viewtopic-t-198023-highlight-lockups.html But that puts the whole case under another light. In *my* case (Asus A8V Deluxe + Radeon 9250 and free drivers), I've reverted to BIOS 1009 and this fixed the problem. By the way, I've seent here is a 1012.002 Beta version of this BIOS (only downloadable from China, others links / repository are dead ;-) ) Any candidate to test it ? Jean-Luc pgpgxWthAb9rK.pgp Description: PGP signature
Re: gcc4, thunderbird: emacs key bindings lost?
Harald Dunkel wrote: Since the migration to gcc4 the Emacs key bindings in Thunderbird's compose window seem to be gone. Is this just me? I ran into that some months ago too. But it has nothing to do with gcc4. This is true on all architectures. I found this solution on the firefox site. I have the following in my ~/.gtkrc-2.0 file. # /etc/gtk-2.0/gtkrc # Restore the previous GTK behavior and allow emacs keys to be active. # To use the GTK 2.0 default MS-like behavior set Default either here # or in your $HOME/.gtkrc-2.0 file. # # gtk-key-theme-name = Default gtk-key-theme-name = Emacs Bob signature.asc Description: Digital signature
AW: Asus A8V Deluxe, Xfree display problems with BIOS 1011
Give me some minutes :)) Actually have to get of work this afternoon, install new bios stuff, and then sit there an wait that this thing crashes my system ;)) Hopefully not. And see me sittin there for weeks and scooping at my runnin system ;)) Thx ingo -Ursprüngliche Nachricht- Von: Jean-Luc Coulon (f5ibh) [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 10. Mai 2005 11:53 An: debian-amd64@lists.debian.org Betreff: Re: Asus A8V Deluxe, Xfree display problems with BIOS 1011 Le 10.05.2005 11:44:28, Jean-Luc Coulon (f5ibh) a écrit : Le 10.05.2005 11:25:59, Jannick Ingo a écrit : Hiho.. So whats the point about your actual problem: Did you updated your BIOS or so ? I recently switched to debian back again. Because these same strange things used to happen under gentoo too. Thought it had something to do with the patchtree they are aplyiing to their sources. You might want to take a look at the corresponding gentoo-forum thread (more than 28 pages): http://forums.gentoo.org/viewtopic-t-198023-highlight-lockups.html But that puts the whole case under another light. In *my* case (Asus A8V Deluxe + Radeon 9250 and free drivers), I've reverted to BIOS 1009 and this fixed the problem. By the way, I've seent here is a 1012.002 Beta version of this BIOS (only downloadable from China, others links / repository are dead ;-) ) Any candidate to test it ? Jean-Luc
Re: Asus A8V Deluxe, Xfree display problems with BIOS 1011
Hi all, I had this trouble too on my Asus A8V with Version 1011 BIOS. After I upgraded the BIOS to 1012-xyz that problem disappeared. Even on Windows 2000 sporadic gfx problems occured with the 1011 BIOS! Best regards, Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Strange start for nvidia + xfree86
Hi, I have compiled and installed nvidia driver (7174). When I start my system, xfree86 exits and returns this error: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (--) NVIDIA(0): Linear framebuffer at 0xE000 (--) NVIDIA(0): MMIO registers at 0xC100 (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: nvidia (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found * If I re-launch kdm or startx it works. How can I avoid start-error? Thanks Giulio -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vuoi ricevere gratuitamente, ogni giorno, un trucco per imparare a smanettare con il tuo PC? * Iscriviti ad Untruccoalgiorno, è GRATIS, è per tutti! Clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3413d=10-5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
OOo and CUPS on AMD64
Is OOo (32bits, of course) supposed to work with CUPS on Debian for AMD64? Someone asked me the question, but I don't know myself and cannot test it. It seems that printing from OOo does not work in Ubuntu for AMD64. Someone here already tested? -- Jerome Warnier [EMAIL PROTECTED] BeezNest -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OOo and CUPS on AMD64
On Tue, 10 May 2005, Jerome Warnier wrote: Is OOo (32bits, of course) supposed to work with CUPS on Debian for AMD64? Someone asked me the question, but I don't know myself and cannot test it. yes, it works fine here. bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OOo and CUPS on AMD64
Works like a charm without any additional configurations -- Andrei On Tue, 2005-05-10 at 13:40 +0200, Jerome Warnier wrote: Is OOo (32bits, of course) supposed to work with CUPS on Debian for AMD64? Someone asked me the question, but I don't know myself and cannot test it. It seems that printing from OOo does not work in Ubuntu for AMD64. Someone here already tested? -- Jerome Warnier [EMAIL PROTECTED] BeezNest signature.asc Description: This is a digitally signed message part
Re: OOo and CUPS on AMD64
I had OOo working back when alioth was still the main server, but cannot get it working from our current server. Anyone have any luck with the deb's on http://amd64.debian.net/debian/? They all seem to point as openoffice.org-bin (pulling this off the top of my head since I am not at my box right now) as an unmet dependencie. -John
Re: OOo and CUPS on AMD64
On Tue, 10 May 2005, John Baab wrote: I had OOo working back when alioth was still the main server, but cannot get it working from our current server. Anyone have any luck with the deb's on http://amd64.debian.net/debian/? They all seem to point as openoffice.org-bin (pulling this off the top of my head since I am not at my box right now) as an unmet dependencie. I had problems with the debs a long time ago, since then I just installed the original package from Openoffice.org and had no problems with it. I prefer to use debian packages, when they work, but in this case I made an exception and installed it all in /usr/local (in the 32bit chroot). Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OOo and CUPS on AMD64
The deb's on alioth used to run with out a 32bit chroot, I was trying to avoid having one if I didn't need it and OOo is the only thing I have come across which isn't 64bit compatable yet. -John On 5/10/05, Giacomo Mulas [EMAIL PROTECTED] wrote: On Tue, 10 May 2005, John Baab wrote: I had OOo working back when alioth was still the main server, but cannot get it working from our current server. Anyone have any luck with the deb's on http://amd64.debian.net/debian/? They all seem to point as openoffice.org-bin (pulling this off the top of my head since I am not at my box right now) as an unmet dependencie. I had problems with the debs a long time ago, since then I just installed the original package from Openoffice.org and had no problems with it. I prefer to use debian packages, when they work, but in this case I made an exception and installed it all in /usr/local (in the 32bit chroot). Bye Giacomo -- _ Giacomo Mulas [EMAIL PROTECTED] _ OSSERVATORIO ASTRONOMICO DI CAGLIARI Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA) Tel. (OAC): +39 070 71180 248 Fax : +39 070 71180 222 Tel. (UNICA): +39 070 675 4916 _ When the storms are raging around you, stay right where you are (Freddy Mercury) _ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Useful Software: Mozilla Firefox - http://www.spreadfirefox.com/?q=affiliatesamp;id=15270amp;t=1 Mozilla Thunderbird - http://www.mozilla.org/products/thunderbird/ OpenOffice.org(OOo) - http://www.openoffice.org/ Gaim - http://gaim.sourceforge.net/ 7-Zip - http://www.7-zip.org/ http://clusty.com/ - The David that takes down Goliath -Bartos
Re: Asus A8V Deluxe, Xfree display problems
Hi all, I also have AV8, bios 1008. i work most time in X, but start it via startx, and everything works fine. and some days ago i want to try display manager (xdm, gdm, kdm). after installing gdm via apt-get, all work fine, but after reboot keyboard locks (mouse still work, machine is accesible via network). same results for xdm and kdm. after little experimentation i found: 1. if X is started before mingetty in inittab, keyboard locks (randomly). 2. if X is started manually ( startx, /etc/init.d/gdm start) after rc scripts, all work fine. i belive this info may be helpful to find real problem best regards, -- Jamil Djadala
Re: nvidia-glx and other non-free packages
On Sunday 08 May 2005 5:22am, mtms wrote: Who needs nvidia-glx or other non-free packages can (still) find them adding these lines to sources.list: ### non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sarge non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sid non-free Hope it helps, Thanks for this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
LAN problems
Hi, I've tried to install sarge-amd-64 on my PC by means of the netinstall CD, but had some troubles with the integrated Gigabit LAN. I have MSI K8T NEO FSR (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=496), on which there is an integrated Realtek® 8110S Dual layout LAN. It says that there is no driver for the ethernet card, and the Packages.gz, where it is looking for that, is empty, anyway. So I couldn't finished the installation :( Does anybody know any sollution? Has using the netinstall CD worked for you properly? Is there any other way? Thanks a lot __ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OOo and CUPS on AMD64
On Tuesday 10 May 2005 12:40, Jerome Warnier wrote: Is OOo (32bits, of course) supposed to work with CUPS on Debian for AMD64? Someone asked me the question, but I don't know myself and cannot test it. It seems that printing from OOo does not work in Ubuntu for AMD64. Someone here already tested? -- Jerome Warnier [EMAIL PROTECTED] BeezNest I think you would need to have a 32-bit cupsys-client running in the chroot and a 64-bit cupsys server. But all this mucking around with a 32-bit chroot just sounds like teaching a cat to bark . the real solution would be a 64-bit version of OpenOffice. According to the OO.org team, it's been done already; but I can't find the necessary files for love nor money. Has anyone had any luck getting the OpenOffice.org sources to compile cleanly under 64-bit Debian? I tried pulling the latest CVS, and had a partial success after doing some hacking. But unfortunately, I got sidetracked; and now I can't get it to work at all . Just what tricks did they pull to make OpenOffice.org so flaky anyway?! I thought the whole idea of using C and C++ was that it shouldn't care if it's running on a 32-bit processor, a 64-bit processor or a 4-bit processor . -- AJS deb64 at earthshod dot co dot uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian We ARE Debian for Heaven's sake! This move to another server is just TEMPORARY! We WILL be Debian as soon as sarge gets out and development on etch picks up. Who in the world is going to get upset when they know we will soon be part of official Debian, and they've already given permission for Debian to distribute their stuff! Get real people! How many non-free packages have been cleared? Why haven't you at least set up non-free and moved the packages known to be ok into it? I know for sure that the rogue-like games in non-free are perfectly fine and can brought on-line now, since they and a lot of other stuff is in non-free just because they are old pre-GPL software with don't sell for money restrictions which make them fail the DFSG test on distribution, but are otherwise fully open-source (and who's earlier authors can no longer be found to ask them if they'd agree to a change to the GPL or some other Free license). In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. thats all you need to get! Hogwash. This sounds like an extremely defensive response. How many packages have been cleared for non-free? Why haven't you just put up a non-free section with the stuff thats been cleared? Why has it been more than a week, with no non-free section at all, no indication of how the vetting process is going, and with you telling us above that we don't need to know anything more? Now do you understand why I'm just a little bit skeptical? Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. Re-evaluating non-free is just silly when we're going to officially become Debian again in a few months, certainly less than a year, anyway (assuming Debian gets Sarge out soon). Heck, Debian doesn't even advertise us, we're the bastard child they don't want to talk about, because when they do it reignites the argument about which architectures to officially support, and why... and why not. NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OOo and CUPS on AMD64
At some point there was a working deb of OOo, 1.1.2 I believe, on alioth. It installed fine other than forcing a shared file issue with ia32-libs. It was actually 32bit though not 64bit, that is the closest I have seen anyone in here get. As far as I know, I haven't seen any other 64bit distros running OOo. It has been said that 2.0 should be able to build 64bit cleanly. -John On 5/10/05, A J Stiles [EMAIL PROTECTED] wrote: On Tuesday 10 May 2005 12:40, Jerome Warnier wrote: Is OOo (32bits, of course) supposed to work with CUPS on Debian for AMD64? Someone asked me the question, but I don't know myself and cannot test it. It seems that printing from OOo does not work in Ubuntu for AMD64. Someone here already tested? -- Jerome Warnier [EMAIL PROTECTED] BeezNest I think you would need to have a 32-bit cupsys-client running in the chroot and a 64-bit cupsys server. But all this mucking around with a 32-bit chroot just sounds like teaching a cat to bark . the real solution would be a 64-bit version of OpenOffice. According to the OO.org team, it's been done already; but I can't find the necessary files for love nor money. Has anyone had any luck getting the OpenOffice.org sources to compile cleanly under 64-bit Debian? I tried pulling the latest CVS, and had a partial success after doing some hacking. But unfortunately, I got sidetracked; and now I can't get it to work at all . Just what tricks did they pull to make OpenOffice.org so flaky anyway?! I thought the whole idea of using C and C++ was that it shouldn't care if it's running on a 32-bit processor, a 64-bit processor or a 4-bit processor . -- AJS deb64 at earthshod dot co dot uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- Useful Software: Mozilla Firefox - http://www.spreadfirefox.com/?q=affiliatesamp;id=15270amp;t=1 Mozilla Thunderbird - http://www.mozilla.org/products/thunderbird/ OpenOffice.org(OOo) - http://www.openoffice.org/ Gaim - http://gaim.sourceforge.net/ 7-Zip - http://www.7-zip.org/ http://clusty.com/ - The David that takes down Goliath -Bartos
Re: OOo and CUPS on AMD64
On Tue, May 10, 2005 at 03:15:01PM +0100, A J Stiles wrote: I think you would need to have a 32-bit cupsys-client running in the chroot and a 64-bit cupsys server. But all this mucking around with a 32-bit chroot just sounds like teaching a cat to bark . the real solution would be a 64-bit version of OpenOffice. According to the OO.org team, it's been done already; but I can't find the necessary files for love nor money. Has anyone had any luck getting the OpenOffice.org sources to compile cleanly under 64-bit Debian? I tried pulling the latest CVS, and had a partial success after doing some hacking. But unfortunately, I got sidetracked; and now I can't get it to work at all . Just what tricks did they pull to make OpenOffice.org so flaky anyway?! I thought the whole idea of using C and C++ was that it shouldn't care if it's running on a 32-bit processor, a 64-bit processor or a 4-bit processor . But C and C++ allow casting things (both implicitly and explicitly) between values and pointers and other stupid things, and that doesn cause problems when you used the wrong type and move to 64bit. So many things have used int to store memory addresses when void* would have been the right thing instead, and they will fail to work on 64bit systems. Also something mix pointer types back and forth and happen to work because of the size of those types, and on 64bit systems they are often different (ie int is 32bit on both 32 and 64bit linux systems in general, while long is 32bit on 32bit systems and 64bit on 64bit systems). Well written and carefully written C/C++ code should just recompile and work. Sloppy code on the other hand (and there is quite a bit of that) breaks. If you are lucky the compiler can warn you about the problem, but sometimes it has no idea what the programmer was trying to do. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: LAN problems
On Tue, May 10, 2005 at 07:06:52AM -0700, Attila Kocsis wrote: I've tried to install sarge-amd-64 on my PC by means of the netinstall CD, but had some troubles with the integrated Gigabit LAN. I have MSI K8T NEO FSR (http://www.msi.com.tw/program/products/mainboard/mbd/pro_mbd_detail.php?UID=496), on which there is an integrated Realtek? 8110S Dual layout LAN. What is the PCI id of that network chip? cat /proc/pci or lspci -n |grep 0200 It says that there is no driver for the ethernet card, and the Packages.gz, where it is looking for that, is empty, anyway. So I couldn't finished the installation :( Does anybody know any sollution? Has using the netinstall CD worked for you properly? Is there any other way? If the network chip has no driver in the kernel on the install CD, then network install isn't going to do much good for you (unless you pop in a cheap add in card that is supported). I would have guessed the 8169 driver might run that chip, but I don't know for sure. I try to avoid anything with realtek in the name on principle. Here is what 2.6.10 lists on a grep for 8110: drivers/net/r8169.c:_R(RTL8169s/8110s,RTL_GIGA_MAC_VER_D, 0xff7e1880), drivers/net/r8169.c:_R(RTL8169s/8110s,RTL_GIGA_MAC_VER_E, 0xff7e1880) Not sure what 2.6.8 had (don't have it handy) so if that is what the install cd is using, it could be a problem too. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn [EMAIL PROTECTED] wrote: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! You're entirely right. After having to read that lot, I'd be impressed if anyone cared about making sure amd64 shipped with non-free. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: Nathan Dragun wrote: While setting up PAM in conjunction with SSH I included the following line to deny access unless found in the following file: authrequiredpam_listfile.so sense=allow onerr=fail item=user file=/etc/sshloginusers Which works, sort of. Don't use it. sshd(8) lets you deny and allow users via /etc/ssh/sshd_config. Reading the daemon documentation before doing something like this is always good idea. He didn't say there wasn't another way to do it, he said there was a security hole. --Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Tue, May 10, 2005 at 10:09:59AM -0500, Pete Harlan wrote: On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: Nathan Dragun wrote: While setting up PAM in conjunction with SSH I included the following line to deny access unless found in the following file: authrequiredpam_listfile.so sense=allow onerr=fail item=user file=/etc/sshloginusers Which works, sort of. Don't use it. sshd(8) lets you deny and allow users via /etc/ssh/sshd_config. Reading the daemon documentation before doing something like this is always good idea. He didn't say there wasn't another way to do it, he said there was a security hole. I believe SSH supports multiple types of authentication. If pam fails, it will use the next configured one. It's a feature of ssh. It isn't as if pam can disable ssh key logins either. Is that a security hole? Misconfiguring sshd doesn't mean it is insecure. It still requires a valid account and password to login. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
On Tue, May 10, 2005 at 11:19:15AM -0400, Lennart Sorensen wrote: On Tue, May 10, 2005 at 10:09:59AM -0500, Pete Harlan wrote: On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: Nathan Dragun wrote: While setting up PAM in conjunction with SSH I included the following line to deny access unless found in the following file: authrequiredpam_listfile.so sense=allow onerr=fail item=user file=/etc/sshloginusers Which works, sort of. Don't use it. sshd(8) lets you deny and allow users via /etc/ssh/sshd_config. Reading the daemon documentation before doing something like this is always good idea. He didn't say there wasn't another way to do it, he said there was a security hole. I believe SSH supports multiple types of authentication. If pam fails, it will use the next configured one. It's a feature of ssh. Thanks, that is helpful. It isn't as if pam can disable ssh key logins either. Is that a security hole? It would be nice if there were a way to have the pam module indicate, this failed, and that's final, as distinct from, this failed so try something else. It still requires a valid account and password to login. True, but I imagine that if someone is using this feature then they have some accounts they trust less than others. There are various ways to go about restricting logins (including sshd's AllowUsers), but the pam method seemed reasonable to me. Particularly because with PAM you could use the same user list for any number of services, not just sshd. (And I don't understand why it would work intermittently, but that's getting far afield.) --Pete -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian We ARE Debian for Heaven's sake! This move to another server is just TEMPORARY! We WILL be Debian as soon as sarge gets out and development on You said it yourself. etch picks up. Who in the world is going to get upset when they know we will soon be part of official Debian, and they've already given permission for Debian to distribute their stuff! Get real people! How many non-free packages have been cleared? Why haven't you at least set up non-free and moved the packages known to be ok into it? I know for sure that the rogue-like games in non-free are perfectly fine and can brought on-line now, since they and a lot of other stuff is in non-free just because they are old pre-GPL software with don't sell for money restrictions which make them fail the DFSG test on distribution, but are otherwise fully open-source (and who's earlier authors can no longer be found to ask them if they'd agree to a change to the GPL or some other Free license). In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. Will you pay us for the work and cover legal fees if any should arise? Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. thats all you need to get! Hogwash. This sounds like an extremely defensive response. How many packages have been cleared for non-free? Why haven't you just put up a non-free section with the stuff thats been cleared? Why has it been more than a week, with no non-free section at all, no indication of how the vetting process is going, and with you telling us above that we don't need to know anything more? Now do you understand why I'm just a little bit skeptical? We had (an empty) non-free right after the dns switch so apt-get wouldn't fail. And we told you exactly what the status is: Someone has to do the work. Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Re-evaluating non-free is just silly when we're going to officially become Debian again in a few months, certainly less than a year, anyway (assuming Debian gets Sarge out soon). Heck, Debian doesn't even advertise us, we're the bastard child they don't want to talk about, because when they do it reignites the argument about which architectures to officially support, and why... and why not. NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! It will be at least 18 month going by the release plans till etch will be stable and sarge amd64 can be dropped. Considering the track record of past timelines 2-3 years is probably more accurate. That is a long time for someone to start suing. In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. Please excuse us for not giving it higher priority than fixing RC bugs or otherwise vital archive maintainance. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Strange start for nvidia + xfree86
Hi, I have compiled and installed nvidia driver (7174). When I start my system, xfree86 exits and returns this error: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (--) NVIDIA(0): Linear framebuffer at 0xE000 (--) NVIDIA(0): MMIO registers at 0xC100 (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: nvidia (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found * If I re-launch kdm or startx it works. How can I avoid start-error? Thanks Giulio -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Prestiti Online. Scopri subito se sei finanziabile. in 24 ore senza spese né anticipi, clicca qui * Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2908d=10-5 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
Pete Harlan wrote: On Mon, May 09, 2005 at 10:16:24PM -0400, Adam Skutt wrote: He didn't say there wasn't another way to do it, he said there was a security hole. Hence I said, don't use it. There is another way to do what he wants (more or less) that doesn't have this security hole assuming the real issue wasn't misconfiguration. Seeing as he wasn't apparently aware of the sshd configuration, I pointed it out to him, seeing as it does exactly what he wants. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: SSH package concerns...
Pete Harlan wrote: It would be nice if there were a way to have the pam module indicate, this failed, and that's final, as distinct from, this failed so try something else. There is. Mark the module requisite, and a failure from it will stop the stack immediately. Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? Regards, Rafael Rodríguez Goswin von Brederlow dijo: Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian We ARE Debian for Heaven's sake! This move to another server is just TEMPORARY! We WILL be Debian as soon as sarge gets out and development on You said it yourself. etch picks up. Who in the world is going to get upset when they know we will soon be part of official Debian, and they've already given permission for Debian to distribute their stuff! Get real people! How many non-free packages have been cleared? Why haven't you at least set up non-free and moved the packages known to be ok into it? I know for sure that the rogue-like games in non-free are perfectly fine and can brought on-line now, since they and a lot of other stuff is in non-free just because they are old pre-GPL software with don't sell for money restrictions which make them fail the DFSG test on distribution, but are otherwise fully open-source (and who's earlier authors can no longer be found to ask them if they'd agree to a change to the GPL or some other Free license). In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. Will you pay us for the work and cover legal fees if any should arise? Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. thats all you need to get! Hogwash. This sounds like an extremely defensive response. How many packages have been cleared for non-free? Why haven't you just put up a non-free section with the stuff thats been cleared? Why has it been more than a week, with no non-free section at all, no indication of how the vetting process is going, and with you telling us above that we don't need to know anything more? Now do you understand why I'm just a little bit skeptical? We had (an empty) non-free right after the dns switch so apt-get wouldn't fail. And we told you exactly what the status is: Someone has to do the work. Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Re-evaluating non-free is just silly when we're going to officially become Debian again in a few months, certainly less than a year, anyway (assuming Debian gets Sarge out soon). Heck, Debian doesn't even advertise us, we're the bastard child they don't want to talk about, because when they do it reignites the argument about which architectures to officially support, and why... and why not. NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! It will be at least 18 month going by the release plans till etch will be stable and sarge amd64 can be dropped. Considering the track record of past timelines 2-3 years is probably more accurate. That is a long time for someone to start suing. In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. Please excuse us for not giving it higher priority than fixing RC bugs or otherwise vital archive maintainance. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc4, thunderbird: emacs key bindings lost?
Bob Proulx wrote: I found this solution on the firefox site. I have the following in my ~/.gtkrc-2.0 file. Beware that if you're running gnome, you may need to do this in gconf instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc4, thunderbird: emacs key bindings lost?
On Tue, May 10, 2005 at 12:55:09PM -0400, Anthony DeRobertis wrote: Bob Proulx wrote: I found this solution on the firefox site. I have the following in my ~/.gtkrc-2.0 file. Beware that if you're running gnome, you may need to do this in gconf instead. Quick tip. If you hate the typeaheadfind keys, grab /usr/lib/mozilla-firefox/res/builtin/platformHTMLBindings.xml, drop it in your ~/.mozilla/firefox/70xxx.default/ directory as HTMLBindings.xml and cut out the following lines:: handler event=keypress key='... handler event=keypress key=/... Quit and restart firefox. Violla! No more typeaheadfind! Now if I could only get firefox to ignore the ESC key-sequence while editing a form... -- Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ signature.asc Description: Digital signature
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote: Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Give us one reasonable example of why some one would waste time and money to sue the amd64.debian.net server owner in this matter, when they have absolutely nothing to gain, and potentially a lot to LOSE if the judge gets angry about the pointlessness of their suit? This would happen in Germany, and the German judicial system hasn't yet become as screwed up as the American system. Besides, by the time they FIND OUT, we'll be officially part of Debian anyway! Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Then load everything up but pine, if that's the only one you know of. I've already listed more packages that I know about, and I'm just a regular user. I'll bet if you had asked on d.d you could have quickly put together a list of 30 - 50 packages which were ok. So why nothing in over a week? Are you holding up all of non-free just because of 1 package? And what is the point? We are Debian. It doesn't matter which server we're on. It will be at least 18 month going by the release plans till etch will be stable and sarge amd64 can be dropped. Considering the track record of past timelines 2-3 years is probably more accurate. That is a long time for someone to start suing. Hogwash again. We aren't talking about *release* dates, Goswin, we're only talking about how long it takes before debian.org is ready to move the amd64 port onto it. Once sarge is out, everybody can get back to moving *forward*, as opposed to running in place right now, which means the ftpmasters of debian.org can do what they need to do to make room for pure64 *Sid*, and move it over so we get synced up as Etch. Sarge can stay where it is, that's not the issue. Getting the *next* Debian AMD64 port onto debian.org is not going to take 3 years. In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. Right, only the relatively few users of this technically unofficial and mostly unknown-to-the-world official Debian port have noticed you left non-free behind. So explain to us why you believe any copyright holder of one of these problem packages OUTSIDE OF DEBIAN is going to find out about this, and for some irrational reason bothers to sue amd64.debian.net, because it isn't on debian.org (but its contents *is* Debian)? Geez, compared to that, I'd say me getting hit by a meteorite when I next leave my apartment is a guaranteed certainty... heck, let me go write my will before I go to the grocery store. All you need is official blessing from Debian proper, in writing, or at least publicly announced on the net, that yes, the AMD64 port on amd64.debian.net is officially part of Debian, and isn't on debian.org only because of technical problems, but will be physically integrated soon (which is all true). With that, you don't have to worry about any lawsuits. So please stop with this weird excuse. Please excuse us for not giving it higher priority than fixing RC bugs or otherwise vital archive maintainance. But you do have the time to re-verify non-free all over again? So you've wasted a whole week on this, *but* you'd rather be doing vital work. Uh-huh. Well, I do agree with you on one thing Goswin, we all have important things that need to be done, so please stop this pointless exercise, which basically amounts to nothing more than
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 12:44pm, Rafael Rodríguez wrote: I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well).
Re: SSH package concerns...
On Tuesday 10 May 2005 17:46, Adam Skutt wrote: Pete Harlan wrote: It would be nice if there were a way to have the pam module indicate, this failed, and that's final, as distinct from, this failed so try something else. There is. Mark the module requisite, and a failure from it will stop the stack immediately. Only for pam. sshd is still free to try something else if pam returns a failure. but sshd.conf contains the needed flags to limit the authentication methods doing man sshd_config saids something like : UsePAM = yes PasswordAuthentication = no might do the trick Adam -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc4, thunderbird: emacs key bindings lost?
Bob Proulx wrote: Harald Dunkel wrote: Since the migration to gcc4 the Emacs key bindings in Thunderbird's compose window seem to be gone. Is this just me? I ran into that some months ago too. But it has nothing to do with gcc4. This is true on all architectures. I found this solution on the firefox site. I have the following in my ~/.gtkrc-2.0 file. It worked. Thanx very much. Is it possible to set this stuff somewhere in /etc for all users? I wonder why the default has changed for amd64, but not for i386. Regards Harri signature.asc Description: OpenPGP digital signature
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 05:44:29PM +0100, Rafael Rodr?guez wrote: I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? If I have understood correctly, when sarge releases, the debian amd64 porters will be maintaining (seperately from debian) an amd64 sarge release, and maintain it until Etch releases. testing for Etch and unstable will contain amd64 after sarge releases, but if we don't get any of non-free setup on the porters maintained unofficial sarge for amd64, then it won't be there for anyone wanting to run amd64 with sarge (even though it is an unofficial sarge port). This is not a problem that will go away until Etch releases. Hence some people care, although mostly about the missing nvidia drivers. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 01:12:22PM -0400, Ed Cogburn wrote: Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). So you think Etch will be released soon? Until it is, Sarge AMD64 port (which will never be part of Debian as far as I know) is going to be around and maintained seperate from Debian, and anything in a non-free that it includes will have to be checked. If you think Etch will take less than 3 years, then well that's good. i sure hope so too, but who knows. The problem doesn't go away when Sarge is released and amd64 enters unstable/testing on Debian unfortunately. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 01:07:30PM -0400, Ed Cogburn wrote: On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote: Ed Cogburn [EMAIL PROTECTED] writes: On Sunday 08 May 2005 9:27am, Joerg Jaspert wrote: In fact, looking through the non-free docs section, most of that can go in right now because they don't require anyone's permission to distribute since they're in non-free because of the dispute between Debian and FSF over documentation. Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Odd. I'm a rational person, and I don't know that. Maybe I'm not really rational. I feel rational though. Hmm. Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). Ah, there we go with that word again... In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. Right, only the relatively few users of this technically unofficial and mostly unknown-to-the-world official Debian port have noticed you left non-free behind. So explain to us why you believe any copyright holder of one of these problem packages OUTSIDE OF DEBIAN is going to find out about this, Well, first off, you just posted about it on a public list...duh. and for some irrational reason bothers to sue amd64.debian.net, because it isn't on debian.org (but its contents *is* Debian)? And there's that word AGAIN. Geez, compared to that, I'd say me getting hit by a meteorite when I next leave my apartment is a guaranteed certainty... heck, let me go write my will before I go to the grocery store. Well, we can hope, because then this stupid thread might die. All you need is official blessing from Debian proper, in writing, or at least publicly announced on the net, that yes, the AMD64 port on amd64.debian.net is officially part of Debian, and isn't on debian.org only because of technical problems, but will be physically integrated soon (which is all true). With that, you don't have to worry about any lawsuits. So please stop with this weird excuse. And you can categorically state this on what authority? Can we assume you're a lawyer in whatever municipality has jurisdiction? Can you even tell me what municipality has jurisdiction? Sheesh, you might have a decent argument if you constrained yourself to facts instead of assertions... But you do have the time to re-verify non-free all over again? So you've wasted a whole week on this Oh my. A *whole week*? I can't believe it. Compared to how long it took to release sarge, that's... let's see... er... insignificant. That's the word I'm looking for. You know what - I don't give a shit about this subject, but I'm getting tired of posts like this one. Chill out. KEN -- Kenneth J. Pronovici [EMAIL PROTECTED] pgpMGLhpD6dIU.pgp Description: PGP signature
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 1:33pm, Lennart Sorensen wrote: On Tue, May 10, 2005 at 01:12:22PM -0400, Ed Cogburn wrote: Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). So you think Etch will be released soon? If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 01:48:14PM -0400, Ed Cogburn wrote: If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. I for one as a user would like to be able to run sarge on my amd64 machine, and have the nvidia driver (and maybe a few other non-free packages), so not all of us are talking about sid and etch. A lot of us are talking about sarge for amd64 unofficial port. That will require checking of the non-free packages (or at least of the packages anyone cares about). At least non-US seems to have died out so we don't need to worry about that. Maybe I should go read the license about the nvidia driver and report on that one. If everyone reports on the packages in non-free they would like, we might get this job done soon. here is an excerpt from /usr/share/doc/nvidia-kernel-source/copyright: First a note from the README file Q: Why does NVIDIA not provide rpms anymore? A: Not every Linux distribution uses rpm, and NVIDIA wanted a single solution that would work across all Linux distributions. As indicated in the NVIDIA Software License, Linux distributions are welcome to repackage and redistribute the NVIDIA Linux driver in whatever package format they wish. To me this looks like nvidia drivers are fine for inclusion. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed, El mar, 10-05-2005 a las 13:48 -0400, Ed Cogburn escribi: If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. Except that you risk getting sued. That is a risk that, even if it's very unlikely to happen, nobody who is responsable for Debian AMD64 in any way wants to take. And you'd have to convince not only one of them, but all. I understand your disappointment (and also partially share it), but please, drop it. I suggest that instead you use your time to write a FAQ entry on how people can get the non-free packages by other completely legal means. NVidia users will find that particularly useful. Regards, -- Javier Kohen [EMAIL PROTECTED] ICQ: blashyrkh #2361802 Jabber: [EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part
pine license
[was Re: Debian AMD64 Archive Move] On Tue, 10 May 2005, Goswin von Brederlow wrote: Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Can we stop with that particular piece of FUD? The authors of Pine have no problems with third-party redistribution of of their software as long as the version number contains an L to show it is not the pristine UW version. We don't distribute it because we follow the letter of their license which unfortunately doesn't match their intentions and even more unfortunately they are not in a hurry to fix. But the authors of Pine don't mind at all. They even have a page of links to third party ports [1] for heavens sake! [1] http://www.washington.edu/pine/getpine/non-UW.html -- Jaldhar H. Vyas [EMAIL PROTECTED] La Salle Debain - http://www.braincells.com/debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn wrote: If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. If you are so certain that providing non-free amd64 from a non-debian server will not pose any legal problems, and so determined that there are packages (other than nvidia) in non-free that people actually want to use, then why don't you host it yourself? You can apt-get source -b the source packages from ftp.debian.org, upload the amd64-compiled .debs to any webserver you have access to, and get a script to generate Packages.gz. There is no rational reason why pure64 main and pure64 non-free need to be on the same server. By building and hosting the packages yourself for the short time until amd64 gets into etch, you can solve your own problem and help the community without putting the project at risk legally. -- Alexander Rapp -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On 10 May 2005, 17:19, Goswin von Brederlow [EMAIL PROTECTED] wrote: Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Just out of curiosity, are pine sources distributed in official Debian Sarge? (the usual yes/no reply will suffice :)) In one point you are right though: NO ONE IS GOING TO CARE ABOUT OUR NON-FREE! None of us anyway. With the exception of nvidia* package it seems. That is the only package that users missed so far. http://packages.debian.org/changelogs/pool/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_1.0.7174-3/nvidia-glx.copyright I'm not a lawyer, but it seems quite clear to me. Isn't it? Btw, when will come the time to check non-free will you please, pretty please, put an eye to lha package too? Thanks in advance :)) -- @,@ Il corpo del povero cadrebbe subito in pezzi [`-'] se non fosse legato ben stretto dal filo dei sogni -----Anonimo indiano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: g++ compile failure
On Monday 09 May 2005 18:24, Ernest jw ter Kuile wrote: I suspect, however, you would be beter off on the gcc list. amd64 is officially supported there. I will do this next. Thought it would fit in here better, because I only have this problem with debian-amd64, same gcc-versions on from other distributions and debian 32Bit work fine. Mario -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 08:13:39PM +0200, mtms wrote: Just out of curiosity, are pine sources distributed in official Debian Sarge? (the usual yes/no reply will suffice :)) As far as I can tell it is not. pine-tracker is the closest thing I can find in sarge. http://packages.debian.org/changelogs/pool/non-free/n/nvidia-graphics-drivers/nvidia-graphics-drivers_1.0.7174-3/nvidia-glx.copyright I'm not a lawyer, but it seems quite clear to me. Isn't it? Btw, when will come the time to check non-free will you please, pretty please, put an eye to lha package too? Thanks in advance :)) Maybe we need a new thread of packages that have been checked and are OK to include. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: nvidia-glx and other non-free packages
On 10 May 2005, 09:23, Ed Cogburn [EMAIL PROTECTED] wrote: On Sunday 08 May 2005 5:22am, mtms wrote: Who needs nvidia-glx or other non-free packages can (still) find them adding these lines to sources.list: ### non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sarge non-free deb http://bytekeeper.as28747.net/debian-amd64-alioth-old/pure64/ sid non-free Hope it helps, Thanks for this. If you or any other is available for writing a FAQ about non-free packages on Debian AMD64 port, please contact me by e-mail. I'll be glad to help. -- @,@ Il corpo del povero cadrebbe subito in pezzi [`-'] se non fosse legato ben stretto dal filo dei sogni -----Anonimo indiano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tue, May 10, 2005 at 01:07:30PM -0400, Ed Cogburn wrote: On Tuesday 10 May 2005 11:19am, Goswin von Brederlow wrote: Seriously, get some patience and don't inflame the situation please. Things like most of that is of zero help in deciding what can go in and what not. We know most of it can, the question is what packages are those in particular. We can't just add all of non-free and say it is mostly OK. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). Are you a lawyer? If not, I'm not particularly inclined to believe you on this count. Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Then load everything up but pine, if that's the only one you know of. It's the only one we know of /now/. There might be more. That's the whole problem. [rest of blatter snipped, doesn't make sense anyway] -- The amount of time between slipping on the peel and landing on the pavement is precisely one bananosecond -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn [EMAIL PROTECTED] writes: On Tuesday 10 May 2005 12:44pm, Rafael Rodríguez wrote: I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). The sarge amd64 archive will remain till etch is released. When amd64 enters sid only unstable/testing will be on ftp-master. So amd64.debian.net will have to maintain non-free stable till etch is released, may that be 18 month after sarge or 3 years. Who knows. A lot longer than 1 month anyway. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
Ed Cogburn [EMAIL PROTECTED] writes: On Tuesday 10 May 2005 1:33pm, Lennart Sorensen wrote: On Tue, May 10, 2005 at 01:12:22PM -0400, Ed Cogburn wrote: Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). So you think Etch will be released soon? If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. And that is where you are wrong. The amd64.debian.net archive is for sarge/stable as much as anything else. If the plan where to merge into debian completly when etch comes to live we wouldn't have moved to a new server one month before that happens. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On 10285 March 1977, Ed Cogburn wrote: Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Laywers arent rationale. Give us one reasonable example of why some one would waste time and money to sue the amd64.debian.net server owner in this matter, when they have absolutely nothing to gain, and potentially a lot to LOSE if the judge gets angry about the pointlessness of their suit? With that logic: Why does SCO still exist? Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). No we cant. Just get a CLUE, we are *NOT* debian. We are as similar as one can get, but the Debian stuff is on .d.o hosts. user. I'll bet if you had asked on d.d you could have quickly put together a list of 30 - 50 packages which were ok. So why nothing in over a week? Are you holding up all of non-free just because of 1 package? No. Because of all the crap that is in there and because WE HAVE MORE IMPORTANT THINGS TODO - which includes reading crap from someone who just trolls on lists and not does any work for it. And what is the point? We are Debian. It doesn't matter which server we're on. We arent, get a clue. Hogwash again. We aren't talking about *release* dates, Goswin, we're only talking about how long it takes before debian.org is ready to move the amd64 port onto it. Once sarge is out, everybody can get back to moving *forward*, as opposed to running in place right now, which means the ftpmasters of debian.org can do what they need to do to make room for pure64 *Sid*, and move it over so we get synced up as Etch. Sarge can stay where it is, that's not the issue. Getting the *next* Debian AMD64 port onto debian.org is not going to take 3 years. Hell, please go and read what amd64.d.n is and you would see what a mess you just wrote. amd64.d.n will exist as long as Sarge is there. And actually there was one who just went over the non-free crap, looking at the licenses, giving us something to work with. If non-free is so important for you - why did you wasted time writing such mails and havent done that work yourself? Thats my last mail in this thread, I have more important things todo. -- bye Joerg Some AM after a mistake: Sigh. One shouldn't AM in the early AM, as it were. grin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
[EMAIL PROTECTED] (Lennart Sorensen) writes: On Tue, May 10, 2005 at 08:13:39PM +0200, mtms wrote: Just out of curiosity, are pine sources distributed in official Debian Sarge? (the usual yes/no reply will suffice :)) As far as I can tell it is not. pine-tracker is the closest thing I can find in sarge. http://packages.qa.debian.org/p/pine.html Last version4.62-1 Testing 4.62-1 Stable 4.44-4 Priority Section optional - non-free/mail lftp ftp.de.debian.org:/debian/pool/non-free/p/pine ls -rw-r--r-- 1 ftp ftp 9106 Apr 17 2002 pine-tracker_4.44-4_all.deb -rw-r--r-- 1 ftp ftp 10396 Jan 22 17:47 pine-tracker_4.62-1_all.deb -rw-r--r-- 1 ftp ftp 39266 Apr 17 2002 pine_4.44-4.diff.gz -rw-r--r-- 1 ftp ftp 657 Apr 17 2002 pine_4.44-4.dsc -rw-r--r-- 1 ftp ftp 3478476 Jan 10 2002 pine_4.44.orig.tar.gz -rw-r--r-- 1 ftp ftp 34224 Jan 22 17:47 pine_4.62-1.diff.gz -rw-r--r-- 1 ftp ftp 608 Jan 22 17:47 pine_4.62-1.dsc -rw-r--r-- 1 ftp ftp 4108969 Jan 22 17:47 pine_4.62.orig.tar.gz % cat pine_4.62-1.dsc -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.0 Source: pine Version: 4.62-1 Binary: pine, pine-tech-notes, pilot, pine-tracker ... Pine sources are legal to distribute. Pine-tracker (achitecture independant) tracks source uploads of pine and warns the user of the pine package about it. The pine deb itself has to be build and installed manually by the user. The autobuilder (if it would include non-free) would build it and upload it against the explicit wish of the author as stated in the license. Pine is an example of software in non-free that may not be build and distributed. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange start for nvidia + xfree86
On 10 May 2005, 19:52, antongiulio [EMAIL PROTECTED] wrote: I have compiled and installed nvidia driver (7174). When I start my system, xfree86 exits and returns this error: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (--) NVIDIA(0): Linear framebuffer at 0xE000 (--) NVIDIA(0): MMIO registers at 0xC100 (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: nvidia (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found * If I re-launch kdm or startx it works. How can I avoid start-error? Did you install nvidia-glx package? If yes and it doesn't solve, add 'nvidia' to /etc/modules and see what happens. Email.it, If you need a gmail mailbox not carrying all this sponsored crap, just ask in e-mail (in our own language, i'm Italian like you) and I will be glad to send you an invite ;-) -- @,@ Il corpo del povero cadrebbe subito in pezzi [`-'] se non fosse legato ben stretto dal filo dei sogni -----Anonimo indiano -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Strange start for nvidia + xfree86
antongiulio kiedys napisal: Hi, I have compiled and installed nvidia driver (7174). When I start my system, xfree86 exits and returns this error: (II) Setting vga for screen 0. (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (==) NVIDIA(0): RGB weight 888 (==) NVIDIA(0): Default visual is TrueColor (==) NVIDIA(0): Using gamma correction (1.0, 1.0, 1.0) (--) NVIDIA(0): Linear framebuffer at 0xE000 (--) NVIDIA(0): MMIO registers at 0xC100 (EE) NVIDIA(0): Failed to initialize the NVIDIA graphics device! (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: nvidia (EE) Screen(s) found, but none have a usable configuration. Fatal server error: no screens found * If I re-launch kdm or startx it works. How can I avoid start-error? Thanks Giulio -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Vuoi ricevere gratuitamente, ogni giorno, un trucco per imparare a smanettare con il tuo PC? * Iscriviti ad Untruccoalgiorno, ? GRATIS, ? per tutti! Clicca qui Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=3413d=10-5 I had the same. I've added line nvidia to /etc/modules and now it works great -- Registered Linux User 369908 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pine license
Jaldhar H. Vyas [EMAIL PROTECTED] writes: [was Re: Debian AMD64 Archive Move] On Tue, 10 May 2005, Goswin von Brederlow wrote: Just establish the non-free section and move everything over. If anyone complains then just drop the package they're complaining about. Of course, NO ONE is going to complain since they know we will become Debian soon anyway (and for all intents we ARE Debian - just not on their server), and they've already given Debian permission to distribute. For the rest of non-free, permission to distribute is not an issue, and not the reason they're in non-free to begin with. The pine author would for one thing. Can we stop with that particular piece of FUD? The authors of Pine have no problems with third-party redistribution of of their software as long as the version number contains an L to show it is not the pristine UW version. We don't distribute it because we follow the letter of their license which unfortunately doesn't match their intentions and even more unfortunately they are not in a hurry to fix. But the authors of Pine don't mind at all. They even have a page of links to third party ports [1] for heavens sake! [1] http://www.washington.edu/pine/getpine/non-UW.html Ok, I stand corrected. The pine author doesn't care, he just mistakenly wrote he would. Doesn't solve the legal problem for us or debian. And it is just one of many packages. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: glx for ia32 applications does not work - SOLVED
I don't know why, but now it's working and the problem is solved. I think I have reinstalled the nvidia-glx-ia32 packet but I'm not sure. Regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
xemacs path problem?
Anybody else having this error or am I missing an something obvious? Setting up emacsen-common (1.4.16) ... emacsen-common: Handling install of emacsen flavor emacs emacsen-common: Handling install of emacsen flavor xemacs21 emacsen-common: byte-compiling for xemacs21 WARNING: Couldn't find obvious defaults for: data-directory lisp-directory Perhaps some directories don't exist, or the XEmacs executable, /usr/bin/xemacs21 is in a strange place?Loading /usr/share/emacs/site-lisp/debian-startup... Loading 00debian... Error while loading 00debian Loading 00debian-vars... Loading 50a2ps... Loading a2ps-print... Loading 50autoconf... Error while loading 50autoconf Loading 50dictionaries-common... Error while loading 50dictionaries-common Loading 50emacs-wiki... Error while loading 50emacs-wiki Loading 50festival... Loading 50gtk-doc-tools... Loading 50preview-latex... Loading 50records-xemacs... Loading 50sawfish... Loading 50x-symbol... Error while loading 50x-symbol Loading 51planner-el... Error while loading 51planner-el Symbol's function definition is void: batch-byte-compile xemacs exiting . emacs-package-install: /usr/lib/emacsen-common/packages/install/emacsen-common xemacs21 xemacs21 failed at /usr/lib/emacsen-common/emacs-package-install line 30, TSORT line 1. dpkg: error processing emacsen-common (--configure): subprocess post-installation script returned error exit status 255 $ xemacs -debug-paths emacs-roots: (/usr/) configure-package-path: (~/.xemacs ~/.xemacs/packages ~/.xemacs/xemacs-packages /usr/share/xemacs21/xemacs-packages /usr/share/xemacs21/site-packages) early-packages and early-package-load-path: (/home/kgk/.xemacs/) nil late-packages and late-package-load-path: (/usr/share/xemacs21/xemacs-packages/ /usr/share/xemacs21/site-packages/) (/usr/share/xemacs21/xemacs-packages/lisp/ /usr/share/xemacs21/xemacs-packages/lisp/Sun/ /usr/share/xemacs21/xemacs-packages/lisp/ada/ /usr/share/xemacs21/xemacs-packages/lisp/apel/ /usr/share/xemacs21/xemacs-packages/lisp/auctex/ /usr/share/xemacs21/xemacs-packages/lisp/bbdb/ /usr/share/xemacs21/xemacs-packages/lisp/build/ /usr/share/xemacs21/xemacs-packages/lisp/c-support/ /usr/share/xemacs21/xemacs-packages/lisp/calc/ /usr/share/xemacs21/xemacs-packages/lisp/calendar/ /usr/share/xemacs21/xemacs-packages/lisp/cc-mode/ /usr/share/xemacs21/xemacs-packages/lisp/clearcase/ /usr/share/xemacs21/xemacs-packages/lisp/cookie/ /usr/share/xemacs21/xemacs-packages/lisp/crisp/ /usr/share/xemacs21/xemacs-packages/lisp/debug/ /usr/share/xemacs21/xemacs-packages/lisp/dictionary/ /usr/share/xemacs21/xemacs-packages/lisp/dired/ /usr/share/xemacs21/xemacs-packages/lisp/docbookide/ /usr/share/xemacs21/xemacs-packages/lisp/ecb/ /usr/share/xemacs21/xemacs-packages/lisp/ecrypto/ /usr/share/xemacs21/xemacs-packages/lisp/edebug/ /usr/share/xemacs21/xemacs-packages/lisp/ediff/ /usr/share/xemacs21/xemacs-packages/lisp/edit-utils/ /usr/share/xemacs21/xemacs-packages/lisp/edt/ /usr/share/xemacs21/xemacs-packages/lisp/efs/ /usr/share/xemacs21/xemacs-packages/lisp/eieio/ /usr/share/xemacs21/xemacs-packages/lisp/elib/ /usr/share/xemacs21/xemacs-packages/lisp/emerge/ /usr/share/xemacs21/xemacs-packages/lisp/erc/ /usr/share/xemacs21/xemacs-packages/lisp/escreen/ /usr/share/xemacs21/xemacs-packages/lisp/eshell/ /usr/share/xemacs21/xemacs-packages/lisp/ess/ /usr/share/xemacs21/xemacs-packages/lisp/eterm/ /usr/share/xemacs21/xemacs-packages/lisp/eudc/ /usr/share/xemacs21/xemacs-packages/lisp/footnote/ /usr/share/xemacs21/xemacs-packages/lisp/forms/ /usr/share/xemacs21/xemacs-packages/lisp/fortran-modes/ /usr/share/xemacs21/xemacs-packages/lisp/frame-icon/ /usr/share/xemacs21/xemacs-packages/lisp/fsf-compat/ /usr/share/xemacs21/xemacs-packages/lisp/games/ /usr/share/xemacs21/xemacs-packages/lisp/general-docs/ /usr/share/xemacs21/xemacs-packages/lisp/gnats/ /usr/share/xemacs21/xemacs-packages/lisp/gnus/ /usr/share/xemacs21/xemacs-packages/lisp/haskell-mode/ /usr/share/xemacs21/xemacs-packages/lisp/hm--html-menus/ /usr/share/xemacs21/xemacs-packages/lisp/hyperbole/ /usr/share/xemacs21/xemacs-packages/lisp/ibuffer/ /usr/share/xemacs21/xemacs-packages/lisp/idlwave/ /usr/share/xemacs21/xemacs-packages/lisp/igrep/ /usr/share/xemacs21/xemacs-packages/lisp/ilisp/ /usr/share/xemacs21/xemacs-packages/lisp/ispell/ /usr/share/xemacs21/xemacs-packages/lisp/jde/ /usr/share/xemacs21/xemacs-packages/lisp/liece/ /usr/share/xemacs21/xemacs-packages/lisp/mail-lib/ /usr/share/xemacs21/xemacs-packages/lisp/mailcrypt/ /usr/share/xemacs21/xemacs-packages/lisp/mew/ /usr/share/xemacs21/xemacs-packages/lisp/mh-e/ /usr/share/xemacs21/xemacs-packages/lisp/mine/ /usr/share/xemacs21/xemacs-packages/lisp/misc-games/ /usr/share/xemacs21/xemacs-packages/lisp/mmm-mode/ /usr/share/xemacs21/xemacs-packages/lisp/net-utils/ /usr/share/xemacs21/xemacs-packages/lisp/ocaml/ /usr/share/xemacs21/xemacs-packages/lisp/oo-browser/ /usr/share/xemacs21/xemacs-packages/lisp/os-utils/ /usr/share/xemacs21/xemacs-packages/lisp/pc/
user dchroot does not work
Hello, I have followed the instructions for chrooting on https://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id274293 but I can't dchroot as user. I can start openoffice in a chroot environment and with 'dchroot -c ia32 -d openoffice' as root but as user I only get the following error: $ dchroot -c ia32 -d openoffice (ia32) openoffice No shell dchroot: Child exited non-zero. dchroot: Operation failed. In google I've found the same problem with this answer: Literally that looks like you have no shell. Check your password field entry in your chroot and verify that shell exists in the chroot and is executable there along with all required libraries for it. I have the same users and passwords in debian amd64 and chroot ia32. /home is the same directory using a mount bind. The shell (/bin/bash) exists and is readable and executable for everyone. So what have I done wrong? Thanks regards, Alexander -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
can't open licq options-dialog with windowmaker - bug?
Hello, there is no dialog window (e.g. options, skin browser...) opening in licq (1.3.0-2, SID) with windowmaker as windowmanager. Pressing ALT+TAB I can see that there should be the just opened dialog windows but I can't switch to any of them and they seem to be invisible. It is working with ia32 debian, so it seems to be a bug in licq for amd64. Can anybody confirm this? Regards, Alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: xemacs path problem?
kristian kvilekval [EMAIL PROTECTED] writes: Anybody else having this error or am I missing an something obvious? Something seems to have been wrong with our emacsen-common package and now that we only ahve the debian build arch independent packages that seems to blow up. Reinstalling (x)emacs and emacsen-common seems to solve it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
This one time, at band camp, Ed Cogburn said: On Tuesday 10 May 2005 12:44pm, Rafael Rodríguez wrote: I don't know why some of you are making all that noise... if I have understood correctly, non-free will be made available after sarge release (which is supposed to happen within 3 or 4 weeks)... so... why bother the developers instead of thaking them for all the work they've already made? Just trying to be helpful and point out to those developers that's there no reason to hold back non-free at all. There isn't a problem, except the one they are conjuring up. Besides, according to Goswin in the post you responded to, it could be 3 years, not 3 weeks, by his logic (which I disagree with as well). In order to be reasonably helpful, why not do something instead of demanding that the volunteers who have very nicely, and on their own time, do more for you? It seems to me that you can: A) host non-free yourself B) Go through all of the licenses in all of the packages in non-free (with the help of counsel, if need be) and determine what are redistributable by parties not Debian. Afterwards, submit a report to the amd64 archive maintainers. C) Have a little patience. Pick any combination of the above, but only if you are actually interested in seeing this get done. If that's not the motivation, we can all listen to more reasons why the nice folks already shouldering all the load should get to do more. Take care, -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpx5L3UruFPR.pgp Description: PGP signature
Re: SSH package concerns...
This one time, at band camp, Ernest jw ter Kuile said: On Tuesday 10 May 2005 17:46, Adam Skutt wrote: Pete Harlan wrote: It would be nice if there were a way to have the pam module indicate, this failed, and that's final, as distinct from, this failed so try something else. There is. Mark the module requisite, and a failure from it will stop the stack immediately. Only for pam. sshd is still free to try something else if pam returns a failure. but sshd.conf contains the needed flags to limit the authentication methods doing man sshd_config saids something like : UsePAM = yes PasswordAuthentication = no might do the trick As well as PubkeyAuthentication ChallengeResponseAuthentication The various Kerberos options, and there used to be a Keyboard one, but I guess that's deprecated now. sshd supports quite a few auth mechanisms. If you want only one to be authoritative, you're going to have to actually disable the others. This is not a security flaw. -- - | ,''`.Stephen Gran | | : :' :[EMAIL PROTECTED] | | `. `'Debian user, admin, and developer | |`- http://www.debian.org | - pgpQAcG4dIgYT.pgp Description: PGP signature
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 2:09pm, Alexander Rapp wrote: Ed Cogburn wrote: If you had read my response to Goswin, you would know we aren't talking about release dates for anything, I'm talking about Sid, which will eventually become Etch, but obviously will exist for a long time before Etch does. :) The issue here is just the co-location of non-free and the AMD64 repository (whatever its called, wherever its located). Those 2 will find themselves together again on debian.org long before Etch sees the light of day, but the point is there is no reason to separate them *now*. If you are so certain that providing non-free amd64 from a non-debian server will not pose any legal problems, and so determined that there are packages (other than nvidia) in non-free that people actually want to use, then why don't you host it yourself? You can apt-get source -b the source packages from ftp.debian.org, upload the amd64-compiled .debs to any webserver you have access to, and get a script to generate Packages.gz. Because its already been done. mtms announced earlier that he's keeping a mirror of our old non-free. And he's not going to get sued by anyone either. There is no legal threat, that's just the excuse they used to get rid of something they never wanted to keep, even though a majority vote of DDs voted to keep it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Tuesday 10 May 2005 3:22pm, Joerg Jaspert wrote: On 10285 March 1977, Ed Cogburn wrote: Will you pay us for the work and cover legal fees if any should arise? Sure. Because any rational person knows it won't happen. Laywers arent rationale. Give us one reasonable example of why some one would waste time and money to sue the amd64.debian.net server owner in this matter, when they have absolutely nothing to gain, and potentially a lot to LOSE if the judge gets angry about the pointlessness of their suit? With that logic: Why does SCO still exist? All laywers are rational enough to know to not waste their time going after an organization THAT DOESN'T HAVE A BILLION DOLLARS. That's why nobody is going to care, Debian is broke anyway, there is no point in a lawsuit. Yes you can. That's my point. Non-free has already been vetted by Debian itself, and we are part of Debian. Any rational judge will see that, if given evidence by the Debian organization itself (see below). No we cant. Just get a CLUE, we are *NOT* debian. We are as similar as one can get, but the Debian stuff is on .d.o hosts. What difference does it make where we are located if Debian itself says we're part of them? user. I'll bet if you had asked on d.d you could have quickly put together a list of 30 - 50 packages which were ok. So why nothing in over a week? Are you holding up all of non-free just because of 1 package? No. Because of all the crap that is in there and because WE HAVE MORE IMPORTANT THINGS TODO - which includes reading crap from someone who just trolls on lists and not does any work for it. Nobody did any work before because it wasn't necessary. Now you're telling us there has been no work done at all on non-free. So you guys really had no plan at all to get non-free moved over, did you? So why didn't you just say that to begin with? And what is the point? We are Debian. It doesn't matter which server we're on. We arent, get a clue. I'm not the clueless one here. Hogwash again. We aren't talking about *release* dates, Goswin, we're only talking about how long it takes before debian.org is ready to move the amd64 port onto it. Once sarge is out, everybody can get back to moving *forward*, as opposed to running in place right now, which means the ftpmasters of debian.org can do what they need to do to make room for pure64 *Sid*, and move it over so we get synced up as Etch. Sarge can stay where it is, that's not the issue. Getting the *next* Debian AMD64 port onto debian.org is not going to take 3 years. Hell, please go and read what amd64.d.n is and you would see what a mess you just wrote. amd64.d.n will exist as long as Sarge is there. And I've said twice now that I'm not talking about Sarge, I'm talking about Sid. This has nothing to do with release dates on anything, its just about co-location of the port and non-free. And actually there was one who just went over the non-free crap, looking at the licenses, giving us something to work with. If non-free is so important for you - why did you wasted time writing such mails and havent done that work yourself? Because the work has bloody well already been DONE! Everybody knows we are destined to return to debian.org, and we ARE Debian now in all but a technicality, a technicality that won't make a bit of difference in court and goes away with a simple statement from Debian that we are part of them, just not on their servers yet. But you guys never bothered to ask, you just threw out non-free without thinking about it, because it was something you wanted to do anyway. Thats my last mail in this thread, I have more important things todo. Yea, like annoying users by leaving non-free behind just because you're still mad that the DDs voted to keep it. Sure. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gcc4, thunderbird: emacs key bindings lost?
Harald Dunkel wrote: Is it possible to set this stuff somewhere in /etc for all users? Bob Proulx wrote: # /etc/gtk-2.0/gtkrc Uhm, yes, in /etc/gtk-2.0/gtkrc. :-) I wonder why the default has changed for amd64, but not for i386. It affected me on i386 too. Bob signature.asc Description: Digital signature
Re: user dchroot does not work
Alexander Fieroch wrote: $ dchroot -c ia32 -d openoffice (ia32) openoffice No shell dchroot: Child exited non-zero. dchroot: Operation failed. In google I've found the same problem with this answer: Literally that looks like you have no shell. Check your password field entry in your chroot and verify that shell exists in the chroot and is executable there along with all required libraries for it. I think I actually wrote that previously so I might as well jump in again. :-) I have the same users and passwords in debian amd64 and chroot ia32. /home is the same directory using a mount bind. The shell (/bin/bash) exists and is readable and executable for everyone. Use dchroot as root to become root in the chroot. Then from there can you su to the user? sudo dchroot -c ia32 At that point you should be root in your chroot. Use su to load the user environment. Where 'youruser' is your normal user account. su - youruser What does that say? I am guessing it will say no shell. Look to see why. These commands should help. id youruser getent passwd youruser grep youruser /etc/passwd grep youruser /etc/group Somewhere along the way the problem will be obvious. Bob signature.asc Description: Digital signature
Re: can't open licq options-dialog with windowmaker - bug?
Hi, same here. When I ran licq, click System-Options ... nothing happens. I have windowmaker as well. Best regards Michal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian AMD64 Archive Move
On Sunday 08 May 2005 4:23pm, Goswin von Brederlow wrote: Ed Tomlinson [EMAIL PROTECTED] writes: On Sunday 08 May 2005 09:27, Joerg Jaspert wrote: On 10283 March 1977, Ed Tomlinson wrote: Whats going on == someone needs to check it. Thats it. That was the point made by Ed Cogburn. Its already been checked in the other arch! If this is not the case please explain why. Without that explanation I am forced to agree with Ed - the problem are political... Which is the bane of debian. We are *NOT* Debian, thats all you need to get! Ok. So from what I understand you are worried there are packages that debian can distribute but only debian has the permission... If this is the case is there not a way you can ask debian to distribute just the non free stuff? ie. This project builds the packages from debian sources, debian hosts the non free stuff on one of their servers. Who is to say we are allowed to build the binaries? This isn't an answer to his question. He's saying why not let the AMD64 non-free be distributed from a Debian server, since you're original excuse was that you aren't Debian. The answer is of course that you never even bothered to ask Debian for help or for a statement about your identity that would eliminate any theoretical legal threat. Hell, you could have just kept non-free on alioth and linked to it from AMD64's new location until a solution to the problem was found since non-free by itself is very small and the move away from alioth was because of space reasons, but no, even keeping the old location temporarily wasn't acceptable, non-free had to go, period. You saw a chance to get rid of non-free, even though its temporary, even though a majority of DDs have officially disagreed with you in a vote, and its only result is to annoy the AMD64 users until AMD64 returns to a Debian server, all because of your extremist ideology. I've been using Debian since pre-1.0 days when I got it off an Infomagic CD when I didn't have regular net access, but the times have changed, certainly the people around Debian have. I never would have thought that Debian would reach the point where it would deliberately and **pointlessly** annoy its own users because of software religion, instead of just trying to produce the best Linux distro possible, but its apparently come to that. No wonder Ubuntu looms large over Debian now, they're taking the best of Debian, but leaving behind the religious wars, and they will now gain strength and speed as Debian slows down due to endless religious infighting. Anyway, its been fun, but its time to move on now, apparently. Goodbye all. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
