Re: freeradius and EAP-TLS
On Thu, 2006-01-12 at 16:58 +, Andrei Mikhailovsky wrote: > Hello, > > I am wondering if there is a particular reason for the debian freeradius > not having an EAP-TLS support? Is there any plans to include it in the > near future? FreeRADIUS is distributed under the GPL. However, in order to support EAP-TLS, OpenSSL is needed, which is considered to be distributed under an incompatible license. Thus, you will need to build it yourself. Before you do so, please read http://bugs.debian.org/337511 I have no idea if it actually works on amd64 - YMMV. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: orinoco usb adapter
On Tue, 2005-11-15 at 13:12 +0100, [EMAIL PROTECTED] wrote: > hi, > > * On 2005-11-15 01:20 <[EMAIL PROTECTED]> wrote: > > : Hmm, thanks for your answer... I don't get my card work - even I tried all I > : knew and what I found in the net. Next time I won't buy anything without > : knowing debian-amd64 can handle it. > : > : Has anyone a hint, which wlan-card/adapter is usable with debian-amd64 > : without any problems? > > buy a d-link dwl-122 for example, costs more or less 20 euro, it has > prism2 chipset and works flawless with the linux-wlan-ng-drivers. > ok, this is not the newest and hottest out there, but it works and > is inexpensive. DWL-122 (rev A1 and A2) is hard to find these days, at least in my locale - the newer DWL-G122 (rev B1) is not prism2, but supposedly ralink 2500. Now ralink supposedly has GPL:d drivers - you might want to check the mail archives. As with most WiFi gear these days, YMMV. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: MAME?
On Wed, Sep 28, 2005 at 09:23:31PM +0200, antongiulio05 wrote: > > for my free time I thought to install mame, but in repository there is > 'xmame-common' not installable. Latest version is 0.100 (i'm not sure). Is > there a working repository for it? Regular xmame 0.100 is in the non-free section of sid for most architectures. However, due to license restrictions, the amd64 mirror is unable to provide it at this time. If you're running sid, it does build out of the box without any problems from debian sources on amd64, albeit it takes an hour or two to build on my lowly box. It appears to run fine without any problems, but I'm not really a gamer... -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Kernel Recompile from 2.6.8-11-amd64-k8
On Sun, Aug 07, 2005 at 09:53:34PM -0400, Robert Barber wrote: > I've followed this recipe before for the DWL-122, > (http://julian.coccia.com/blog/index.php?p=53&more=1), and he says that you > need to recompile your kernel locally or you will get module dependency > errors > when you try to insert the modules. Guess I've done a lot of recompiles in > the > past for no reason. :) If I'm not entirely mistaken, the DWL-122 revision A1 and A2 use the Prism chipset, but later B1 revisions Ralink, so the above recipe might not work for everyone. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free package archive
On Thu, 2005-05-12 at 11:14 -0500, Adam M wrote: > On 5/12/05, Kaare Hviid <[EMAIL PROTECTED]> wrote: > > On Thu, 2005-05-12 at 01:13 -0500, Adam M wrote: > > > Hi, > > > > > > I have compiled a list of packages in non-free that can be included in > > > Amd64's non-free. A few days ago I have posted the entire list of good > > > and bad packages on debian-devel[1]. They can also be found at, > > > > > > http://people.debian.org/~adamm/non-free/ > > > > > > bad.txt - not distributable > > > good.txt - distributable > > > > > > I think non-free is important to be part of Amd64 port for Sarge due > > > to a few important packages like, like RFCs and the nvidia drivers. > > > > > > Now that I have reviewed these licenses, will Amd64 port carry > > > non-free in Sarge? > > > > > > - Adam > > > > I just finished my own review of the non-free packages. > > Please don't misunderstand me - I'm not trying to tell you what to > > do, I just thought I'd give it a shot and have a look at the non-free > > licenses. Also, I'm by no means a lawyer, nor am I a DD - I'm just a > > layman. I've used the Packages list of a current i386 *sarge* box, and > > had invaluable help from http://nonfree.alioth.debian.org/. My criteria > > I didn't use nonfree.alioth.debian.org and I didn't use Packages. I > used current Sources and read the dreaded debian/*copyright files from > each of the source packages. It might have been better if you raised > some questions about why I put something in good.txt and other stuff > in bad.txt and then point to relevant sections of the licenses I > looked at [1]. Trying to match the binary<->source can be tricky. I wasn't aware that you had done a proper audit of the licenses when I embarked on looking at it. Once finished, I found your mail, and rather than throwing away my own list, I replied you, thinking someone might want a second opinion. I have also read each of the dreaded debian/copyright files, (which nonfree.alioth.debian.org links to) and have tried to find further information when it was lacking. Our findings match up pretty good anyway, with the exception of libforms-doc (that I find clearly non-distributable), and moria and trn4 (where I didn't find anything compelling hindering distribution). > Anyway, I just want to look at the nvidia package where you said, > > > "Notwithstanding the foregoing terms of > > Section 2.1.1, SOFTWARE designed exclusively for use on the > > Linux operating system may be copied and redistributed, provided > > that the binary files thereof are not modified in any way > > (except for unzipping of compressed files)." Debian, and > > apparently Ubuntu, have special permission for distributing. > > The intent is probably only to deny OEMs to rebundle the stuff > > without nVidia's permission. > > What I think nVidia does is use the same license for distribution for > Linux, Windows and Mac but they have an exception for Linux > distributions that allow redistribution of their binary drivers. The > binary drivers themselves are not permitted to be modified (how? with > a hex editor? :). GPLed stuff of course can be modified. I found it unclear if distributing it in a .deb was allowed, as it could be seen as of a form of modification beyond unzipping of compressed files. As such, I also marked it with a "?", denoting that I couldn't tell if it was "good" or "bad". Given nVidia's presence in the Linux desktop market, I'd be surprised if they wouldn't *promote* distribution of ready-to-go driver packages for the Debian amd64 sarge port. Didn't they even sponsor Gentoo with amd64 hardware to get going? > If nothing else, I think the nVidia drivers and the RFCs must be > distributed by Amd64 for Sarge if the port is going to have some > penetration into the destrop market. If there is no nvidia drivers, > people will try to install them with the nvidia installer and butcher > their installations. They will then complain that Amd64 Sarge is crap > because they cannot even get their FX card to work! I certainly agree - the number of consumer desktops with the amd64 nVidia combination is staggering to the brink of almost becoming synonymous in the consumer electronics shops. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Kerberos5, OpenAFS and 64bit
On Mon, May 02, 2005 at 02:45:05PM +0200, Lars Schimmer wrote: > > I haven't found the openafs-krb5 in the pure64 tree of Debian sid. Anyone > knows > anything about that package? This affects all platforms, c.f. http://bugs.debian.org/304933 However, if you're in a hurry, it's quite easy to fix it yourself. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NDIS problem on amd64-pure install
On Thu, 2005-03-31 at 02:16 -0600, Donald Spoon wrote: > I am unable to get the built-in 802.11g/b device to work. It is an > INPROCOMM IPN2220 wireless chipset, and it is supposed to work with the > ndiswrapper program from Source Forge. I have d/l the ndiswrapper > source, compiled it with the same gcc as my kernel (3.4) and have > obtained the Windows XP drivers and installed them per the instructions. > A "ndiswrapper -l" shows the hardware present and the drivers loaded. > A "modprobe ndiswrapper" works without complaint, but the "iwconfig" > command doesn't show any wlan0 or other devices for wireless! Looking > at the logs givess the following 4-line message: > > ndiswrapper version 1.1 loaded (preempt=no,smp=no) > ndiswrapper (check_nt_hdr:145): Windows driver is not 64-bit; bad magic: ndiswrapper on amd64 in native 64-bit mode requires Windows XP 64-bit drivers - the "standard" 32-bit XP drivers won't work. Thus, are you sure you were able to get hold of 64-bit XP drivers? (I know, I had the same experience, but it's somewhat comforting to know that the miracle of proprietary binary-only drivers is hitting back at Windows users too every time a major shift takes place on that Other Platform.) -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#248043: ftp.debian.org: Request for new architecture: amd64
On Tue, Mar 22, 2005 at 03:16:39PM +1000, Dave Whitla wrote: > Jeroen van Wolffelaar wrote: > > > > >This will happen post-sarge, amd64 will not get released with sarge, and > >adding it to sid now would only cause more work that can better be spent > >elsewhere (read: releasing sarge). > > > >--Jeroen > > > > > > > (read: "I don't own an AMD64") Nah. The second-most popular arch with the fastest buildd, expecting an exponential growth over the years to when (hopefully) etch is frozen, doesn't cut it in sid. The days and nights all you great amd64 people out there have spent hunting bugs (that has been of great help to other archs too), fixing installers, maintaining mirrors, helping newcomers getting started and creating a port in an excellent shape - isn't good enough. The amount of work involved in adding amd64 to sid proper is of such unfathomable magnitude that we'd rather wait a couple of years, filling up sid and sarge with a constant flow of broken packages and RC bugs. You're too greedy and should've spent the extra dollars on Itanium2s instead. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Idea for structure of Apt-Get
On Sat, Mar 19, 2005 at 12:30:35AM -0600, Patrick Carlson wrote: > > Hello. I'm not sure if anyone has suggested something like this or > not but I was thinking about the apt-get system and bittorrent today. You might want to check out http://sianka.free.fr/ Which was mentioned in DWN November 2nd, 2004. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
On Fri, Jan 14, 2005 at 11:56:31AM +0100, Giacomo Mulas wrote: > On Fri, 14 Jan 2005, Kaare Hviid wrote: > > >1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave > >with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain. > > Yes, I actually came to this same conclusion, after some more work. What > puzzles me is that _every_ time I start the nis server with the stock > /etc/init.d/nis script, be it manually or at boot time, the maps are > transferred anew! Perhaps, due to the fact that map files are not > identical to the ones on the master server, the nis slave server thinks > its maps are outdated and tries to refresh them every time it is started, > every time falling back to the enumerate mechanism, and thus every time > creating new files which are not identical to the ones on the master > server... If I'm not mistaken, this functionality was introduced in the sarge NIS package. And if you think about it, it makes sense. The NIS slave has no way of telling if its maps are outdated or not (all updates are normally initiated from the master). Thus, if the slave server has been down, you might be sitting with an old passwd database without knowing about it - and you certainly want to avoid old passwds flying around on the net if you want to remain sane. If you've previously only used woody NIS servers, watch out! There are syntactic changes in the /etc/ypserv.conf file. Thanks to the excellent packaging of the Debian nis package, it should be an almost painless upgrade though. (Yes, I really do think the Debian nis package is extremely well maintained.) > >2) Avoid mixing architecture, OS, distro, implementation and version of > >NIS servers in a production environment unless you actually find > >pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-)) > > Well, I do find some pleasure in a moderate use of voodoo and the black > magic of NIS/YP myself, but I do not have a choice. I will replace old > x86 computers in the cluster I administer with amd64 ones, gradually, > which means that for some time I will have to live with a mixed > environment. And I will have to do my best to ensure that 64bits machines > are used near their full potential (hence a 64bit system) but still > sacrificing as little functionality as possible (hence a full 32 bit > system in a chroot cage as well). Oh, and it should be as transparent as > possible to users, as well. I think I am going to need some psychiatric > help in the near future... IMHO, NIS doesn't make use of much resources - thus, dedicating an old low-memory box with reliable hardware is my own personal policy regarding slave NIS servers. -ukh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bug reporting?
OK, I just conducted a few non-scientific tests regarding the use of
amd64 as an NIS slave. This is, as I suspected, not a gcc-3.4/pure64
issue, nor an amd64 issue. IIRC, rpc.ypxfrd transfers the raw
databases in the host native format - and if I'm not mistaken that's
the way it works in the original Sun ONC implementation as well. (The
Linux NIS/YP stuff is reverse engineered, since Sun wants $$$ and NDAs
for code and/or proper protocol documentation.) Indeed, the problem
arises when trying to use an alpha as a slave server as well, and I
wouldn't be surprised if it will happen on, say, PPC too because of the
endianess. The Linux NIS/YP implementation does, however, have a
fallback mechanism for these cases. If, after doing the ypinit, you
actually check your /var/yp/${nisdomainname} catalog, you should find
all the databases there anyway, and you should also find that the slave
server actually works. In other words, ypinit complains, but it still
should work and function.
To make a long story short:
1) Using a pure64 amd64 box (or alpha for that matter) as an NIS slave
with an i386 box as master _will_ work, albeit rpc.ypxfrd will complain.
2) Avoid mixing architecture, OS, distro, implementation and version of
NIS servers in a production environment unless you actually find
pleasure in voodoo and the black magic of NIS/YP. (I obviously do :-))
-ukh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Problems upgrading gv
On Tue, Jan 04, 2005 at 10:30:42AM +0100, Andree Zeulner wrote: > > I was dist-upgrading today and I got this error while configuring gv > > No `START-INFO-DIR-ENTRY' and no `This file documents'. > > install-info(/usr/share/info/gv.info): unable to determine description > > for `dir' entry - giving up > > I have the same problem here. Debian has an excellent bug tracking system, which, IMHO, on its own makes Debian stand out from all other distros. This is not an amd64 issue, c.f. http://bugs.debian.org/288291 -ukh
Re: Fwd: Support for x86_64 added to DriverLoader
On Wed, Dec 29, 2004 at 11:34:35AM -0600, Kunjan Shah wrote: > Hi, > > we have released DriverLoader 2.20 and this new version adds support for > the x86_64 architecture. Has the advertisment of this proprietary closed-source software been paid for? http://www.debian.org/MailingLists/#ads -ukh
Re: mounting xfs on x86_64
On Fri, Nov 26, 2004 at 09:24:19AM +0100, Dennis Grevenstein wrote: > On Fri, Nov 26, 2004 at 08:56:32AM +0100, Daniel van Eeden wrote: > > I'm using XFS on my amd64 box w/o any issues. > > The kernel is a stock 2.6.9 debian kernel from pure64. Try creating a > > xfs filesystem on another device (e.g. a file) and see if that works. > > As I said. XFS works in general with my amd64 kernel. > I can create and mount filesystems, but I cannot mount my > old disk with most of my data on it. OK, I did a fast unscientific test and created xfs filesystems in flat image files on both amd64 and i386, exchanged the images between the systems, and I can mount and read them. I can also mount and read i386 and amd64 xfs image files on my alpha. All systems with 2.6.9 kernels. I unfortunately lack the resources to try it out with real disks, pre-2.6 and/or pre-sid systems. -ukh
Re: problems with nautilus
On Mon, Nov 15, 2004 at 11:17:55PM +0100, Johan Groth wrote:
> Hi,
> I've just installed the gcc-3.4 branch from alioth on a dual Opteron 244.
> Works well except Nautilus in Gnome which crashes during Gnome's start up
> phase. I can't start it manually either so I wonder if anyone else has seen
> this?
>
Probably BTS #266376, solved in the pure64 repository with:
diff -Naur orbit2-2.10.2/debian/patches/amd64-fix.diff
orbit2-2.10.2.pure64/debian/patches/amd64-fix.diff
--- orbit2-2.10.2/debian/patches/amd64-fix.diff 1970-01-01 01:00:00.0
+0100
+++ orbit2-2.10.2.pure64/debian/patches/amd64-fix.diff 2004-11-17
11:12:12.164260086 +0100
@@ -0,0 +1,10 @@
+--- src/orb/orb-core/allocators.c.old 2004-08-23 13:28:59.655571630 +0200
src/orb/orb-core/allocators.c 2004-08-23 13:29:41.717608111 +0200
+@@ -59,6 +59,7 @@
+ }
+ case CORBA_tk_except:
+ case CORBA_tk_struct:
++ mem = ALIGN_ADDRESS (mem, tc->c_align);
+ for (i = 0; i < tc->sub_parts; i++) {
+ subtc = tc->subtypes [i];
+ mem = ALIGN_ADDRESS (mem, subtc->c_align);
However, not in the gcc-3.4 repository... Andreas? Please? :-)
-ukh
Re: blackdown Java, amd64 and java-package
http://bugs.debian.org/274844 contains a patch against java-package 0.14 that also takes into account the Blackdown 1.4.2-fcs release from 28th of September, that apparently fixes some things for upstream Eclipse. -ukh
Re: cfs and NFS export do not work in pure64. RPC problems?
On Fri, Oct 08, 2004 at 12:23:17PM +0100, Oliver Elphick wrote: > No, there are no nfsd processes. In the log, on startup, I get: > > nfsd: nfssvc: Function not implemented > > In the kernel config, under Network File Systems, I have: > > CONFIG_NFS_FS=y > CONFIG_NFS_V3=y > CONFIG_LOCKD=y > CONFIG_LOCKD_V4=y > CONFIG_SUNRPC=y Then, there you go. NFS _client_ support, but no server. You should have CONFIG_NFSD=y too. (I _think_ NFS daemon is enabled on stock Debian kernels.) And you probably want CONFIG_NFSD_TCP=y as well for a smooth run on 2.6.8. (NFS over TCP is considered much less errorprone by many on the linux-nfs list.) And please use NFSv3 - NFSv2 is more or less deprecated and NFSv4 is still in its infancy. Cheers, -- Kåre Hviid [EMAIL PROTECTED] +45 3815 3075 Sys Admin Institut for Datalingvistik, Handelshøjskolen i København
Kudos (was Re: install error)
On Wed, Oct 06, 2004 at 08:51:04PM +0200, Frederik Schueler wrote: > In the first place, we decided to not change the mirrors list and > distribution in the installer, since we where told pure64 would be added > to Sid as soon as 95% of source packages would be ported. 95%? If I'm not completely wrong, at least for gcc-3.4, we're currently approaching 98%. And that is _with_ the binary-all packages, that they seemingly don't count or even bother about at buildd.debian.org... Actually, it would be kind of interesting to know how much of i386 builds on sid if one counts binary-all as well. I wouldn't be surprised if pure64 and gcc-3.4 are approaching i386. I'm not into Debian politics, but I'd guess the people in power are way too busy getting sarge out of the door, and I won't argue with that objective. Frederik Schüler, Andreas Jochens, and all you other guys - your work is absolutely stunning! -- Kåre Hviid [EMAIL PROTECTED] +45 3815 3075 Sys Admin Institut for Datalingvistik, Handelshøjskolen i København
Re: ati video card driver problem
On Mon, Sep 06, 2004 at 12:31:56PM +0100, Hugo Mills wrote: >ATi have not released binary drivers for amd64. If you want to use > your graphics card under Linux, you will have to run a 32-bit kernel > and a 32-bit system. Needless to say, this has made a number of people > (including myself) somewhat angry. The XFree86 ati drivers in the gcc-3.4 tree seems to be rock solid, although you will only get 2D support. >I suspect that they won't release 64-bit drivers for Linux until > 64-bit Windows ships. That makes no sense since they're shipping 64-bit AMD64 drivers for 64-bit Windows XP: http://www.ati.com/support/infobase/4424.html Considering that 64-bit Linux on AMD64 probably is an order of magnitude more popular than 64-bit Windows, I wouldn't hold my breath. Cheers, -- Kåre Hviid [EMAIL PROTECTED] +45 3815 3075 Sys Admin Institut for Datalingvistik, Handelshøjskolen i København
Re: video card ?
On Mon, Sep 06, 2004 at 12:44:08PM +0200, LOMPREZ Olivier wrote: > I don't know which video card i must choose. > I would like to know if the following video cards : > 1) "*Point of View GeForce FX 5900 XT 128 Mo DDR/DVI > is compatible" with Debian-amd64 ?. > 2) " **ASUSTEK V9570/TD 256 Mo TV/DVI (NVIDIA GeForce FX5700) > is compatible with Debian amd-64 ?. > 3) is there any hardware data base for the compatibility ?. > Thank you for your answers and your suggestions. > Olivier. Me too. In fact, I ask myself a quite similar question all the time: If I want to have a good card with fully non-proprietary drivers, what should I go for? I don't mind absence of 3D-accelleration, TV-out, dual head, or the obligatory cardboard box with vicious aliens on it. But I _do_ mind choosing a state of the art card that the XFree86 drivers only support 2D on, knowing that the jet engine mounted on the card is only cooling things that I will never be able to use. Especially since that same jet engine generally needs to be replaced every 6 months. Back in the old days, a safe choice used to be the Matrox Millenium, but today even the lowly Matrox G550 requires a binary IA32 HAL driver - and that at the price that DGA won't work. And even though I can live without 3D, I'd really like some 2D performance - at least an order of magnitude better than the cheap built-in Intel Extreme Sluggishness found in too many boxes today. Today, I'm using the Radeon 9800 that came with my Athlon 64 box. No 3D, no TV-out, no TV-tuner support - but with one of those jet engines. So, is there anything out there running smoothly on AMD64 without power drain and without noise pollution? Cheers, -- Kåre Hviid [EMAIL PROTECTED] +45 3815 3075 Sys Admin Institut for Datalingvistik, Handelshøjskolen i København
