Re: Which mirror to install etch or sid
Goswin von Brederlow wrote: thierry <[EMAIL PROTECTED]> writes: thierry wrote: I am trying to install a box with amd64, using the latest daily build image (ie: downloaded about an hour ago). But I can't get a mirror to work. I get the following message: The specified Debian archive mirror is either not available, or does not have a valid Release file on it. Please try a different mirror. But all the mirrors give that error. Does anyone knows what to do? Thanks Thierry OOOpss! I forgot to say that I used the netinst iso. Thierry http://ftp.debian.org/README.mirrors.html MfG Goswin Thanks for your answer, Goswin, but I had seen that page. Did not help. I tried a few of those sources, and still got the same error message. I got out of it using a source with debian_amd64 in it. I know it is outdated know, but it worked...sort of! Anyhow, I could get a running system from them, and then I changed the sources to ftp.fr.debian.org/debian, dist-upgrade, and I am happy with a nice sid box. Thanks again Thierry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
messages from Anacron
Hi All! Since last upgrade I started getting these annoying messages from Anacron every day. How can I make it happy again? From: Anacron <[EMAIL PROTECTED]> Subject: Anacron job 'cron.weekly' on zv5260 To: [EMAIL PROTECTED] Date: Wed, 07 Jun 2006 16:18:12 -0700 /etc/cron.weekly/man-db: mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapreset.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapproto.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapstats.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/atobm.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapchar.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapout.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapinfo.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/bitmap.1x: No such file or directory mandb: warning: /usr/share/man/man1/bmtoa.1x.gz: bad symlink or ROFF `.so' request mandb: can't open /usr/share/man/man1x/xtrap.1x: No such file or directory mandb: warning: /usr/share/man/man1/xtrapin.1x.gz: bad symlink or ROFF `.so' request -- "When I was a kid I used to pray every night for a new bicycle. Then I realised that the Lord doesn't work that way so I stole one and asked Him to forgive me." - Emo Philips. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xorg 7.0 (glx problems--Error: couldn't find RGB GLX visual)
>Do you have the following line in /etc/apt/sources.list ? > deb-src http://debian.mirror.frontiernet.net/debian/ testing main My line actually said "http://debian.mirror.frontiernet.net/debian/ testing main contrib non-free," and that was the problem. I removed "contrib non-free" and that cleared the errors. Everything ran with no errors, but I still have no GLX. Most obvious symptom ... No GL screensavers work. ... I wonder if I should have pulled the xserver-xorg-core source from Sid. -- View this message in context: http://www.nabble.com/xorg-7.0-%28glx-problems--Error%3A-couldn%27t-find-RGB-GLX-visual%29-t1737529.html#a4786006 Sent from the debian-amd64 forum at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
A J Stiles wrote: > We seem to be getting a lot of spam being sent to the list lately. Can we do > anything to block it? Only accepting inbound mail from addresses on the > recipients list would be a good start. Also, since we're all Debian users > here, it might make sense to reject mail apparently coming from a > Windows-based user-agent. > > It was ironically endearing when it was adverts for pirated Windows software; > but I get enough pr0n, phishing and share scams elsewhere without them coming > through this list. > Um, no, no, no and no. Here is why those are all bad ideas: - List volume is huge and many people want to post without subscribing - All posts to this list do not originate by email, e.g., news groups - Lots of people post from work (where they only have windows) - Lots of people admin Debian servers, with Windows as a workstation OS - You can do those things (except for filtering based on subscribers) -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
Re: dosemu or dosbox
On Thu, Jun 08, 2006 at 09:34:07AM -0400, Lennart Sorensen wrote: > On Thu, Jun 08, 2006 at 11:08:58AM +1000, Alexander Samad wrote: > > so how does dosbox work ? > > Dosbox is a dos environment emulator, including all the hardware. It > emulates all the old PC video modes (cga/ega/vga/tandy/etc) and sound > cards (tandy/sb/gus/adlib/roland/etc) and the x86 cpu. It is of course > much slower than dosemu since it emulates everything, but it runs on any > architecture, and given the speed of modern PCs and the expectations of > dos software, speed should not be a big problem. wow thanks > > Len Sorensen > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > signature.asc Description: Digital signature
Pango Problems on 32bit-env
Hi, I have problems when I launch gtk applications (like firefox or realplayer) in 32-env: chars are not displayed (just empty boxes). In runtime I got these errors (realplayer): (realplay.bin:6865): Gdk-WARNING **: locale not supported by Xlib (realplay.bin:6865): Gdk-WARNING **: cannot set locale modifiers Failed to load pixbuf file: /home/giulio/bin32/RealPlayer/share/realplay/icon.png: Unable to load image-loading module: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so: /usr/lib/gtk-2.0/2.4.0/loaders/libpixbufloader-png.so: cannot open shared object file: No such file or directory (realplay.bin:6865): Pango-WARNING **: /usr/lib/pango/1.5.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory Failed to load Pango module for id: 'BasicScriptEngineFc' (realplay.bin:6865): Pango-WARNING **: /usr/lib/pango/1.5.0/modules/pango-basic-fc.so: cannot open shared object file: No such file or directory In 32-env I have pango-basic-fc.so (and other requested libs) in right paths, but they seem not existing when I launch from 64bit-env (with or without "linux32 dchroot -c ia32 -d"). My ld.so.conf is: /var/chroot/sid-ia32/lib /var/chroot/sid-ia32/usr/lib /var/chroot/sid-ia32/usr/X11R6/lib /var/chroot/sid-ia32/usr/local/lib Have you any idea? Thanks, Giulio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
For people wanting to install Sarge on AMD64 I recommend using the mini.iso found here: http://amd64.debian.net/debian-installer/daily/netboot/ I did a sarge jfs on RAID with home on jfs/raid1/lvm with only minor problems with this iso. There should be a mention of this iso on the main installer page for the time being. Karl Schmidt EMail [EMAIL PROTECTED] Transtronics, Inc. WEB http://xtronics.com 3209 West 9th StreetPh (785) 841-3089 Lawrence, KS 66049 FAX (785) 841-0434 Time wounds all heels -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
Frans Pop <[EMAIL PROTECTED]> writes: > On Thursday 08 June 2006 13:33, Goswin von Brederlow wrote: >> > - increasing differences between the Sarge 2.6.8 and current kernels; >> >> That is a reason for. > > Only if we _would_ include some backports repository that is known to have > a current backported kernel and all other packages needed with that > kernel, but without random backports of other packages. And we would need > some guarantees about the maintenance of and procedures for changes in > such a repository (compare volatile.d.n). > If we don't include such a repository, we're only offering an installation > that is known not to work on the reboot. And currently we don't. Worst case you have to add testing to sources.list and get the kernel from there. With the right pining or default release that still leaves you nearly completly stable. I also think we can trust backports.org to continue its great service of backporting. Lay out some groundrules that need to be met to support testing->sarge installs and I'm sure something can be worked out from there. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xorg 7.0 (glx problems--Error: couldn't find RGB GLX visual)
* rickh <[EMAIL PROTECTED]> [Jun 08. 2006 14:27]: > Frederik Juul Christiani-2 wrote: > > > > $ sudo apt-get install -t unstable mesa-swx11-source > > $ sudo apt-get build-dep xserver-xorg-core > > $ sudo apt-get install fakeroot > > $ apt-get source xserver-xorg-core > > $ cd xorg-server-1.0.2/ > > $ dpkg-buildpackage -rfakeroot > > $ cd .. > > $ sudo dpkg -i xserver-xorg-core_1.0.2-8_amd64.deb > > Didn't get far. 2nd instruction, $ sudo apt-get build-dep > xserver-xorg-core, returns: > E: Could not open file > /var/lib/apt/lists/debian.mirror.frontiernet.net_debian_dists_testing_main_source_Sources > - open (2 No such file or directory) Do you have the following line in /etc/apt/sources.list ? deb-src http://debian.mirror.frontiernet.net/debian/ testing main Make sure you do, and follow up with "sudo apt-get update". I hope this helps. Frederik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
On Thursday 08 June 2006 13:33, Goswin von Brederlow wrote: > > - increasing differences between the Sarge 2.6.8 and current kernels; > > That is a reason for. Only if we _would_ include some backports repository that is known to have a current backported kernel and all other packages needed with that kernel, but without random backports of other packages. And we would need some guarantees about the maintenance of and procedures for changes in such a repository (compare volatile.d.n). If we don't include such a repository, we're only offering an installation that is known not to work on the reboot. And currently we don't. > > If it does make it, there will be disclaimers shown to the user after > > mirror selection to the effect that there is only limited support and > > not to come complaining if there are problems on reboot. > > Isn't it enough that you already need expert mode? IMO not. Especially if we would add a backported repo by default as we'd have to make clear that the upgrade path of such a system to the next stable release is not guaranteed. Too many "regular" users choose expert mode (and you don't even need expert mode; deconf/priority=medium will offer Sarge as well). pgpH6PurOB7QA.pgp Description: PGP signature
Re: gcc
As to packages available from another distribution, I forgot to tell the whole
instructions I was given:
Looks like there is a debian mpqc package. See
http://packages.debian.org/unstable/science/mpqc
You should be able to do an 'apt-get mpqc' and it will install mpqc,
along with any missing packages that mpqc depends on.
Does this fit with your suggestion below? I wonder about those and where to address that apt-get, and why does not
precede the name of the package.
thank you
francesco pietra
On Thursday 08 June 2006 18:14, A J Stiles wrote:
> On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> > Finally, I issued #make (from root) and then changed the ownership of all
> > *.c, *.o, *.h, and *.prm files, including the directory containing them.
> > It works perfectly at truly 64bit (of course it has no graphics, to this
> > end, but on the 32bit pc I have a sister program to examine graphically
> > the output). Impressive speed. The most tricky part is to create the
> > input on the 32bit pc and transfer to the 64bit workstation through a usb
> > card reader, complex because of the strict adherence of debian to
> > ownerships and permissions.
>
> Is there a good reason why you can't set up an NFS share between the two
> machines?
Really not. I am just at the beginning, with recoursing problems. NFS will be
the solution. And may be even vetter to create a 32bit chroot to run there my
pre-program. It may be useful in case of pc32 down. I never created a chroot
and take into account that I am a chemist (one of the very few scientists in
my country who does not know about Microsoft), I have to do chemistry. Time
is short.
I am experiencing unusual difficulties with these particular file transfers
from the 64bit side. Root is not allowed to transfer with preservation of
properties of output files (may be I am using wrong commands, however) and
files on the card reader refuse to be changed of ownership (here I am sure to
use the right commands). Moreover, umount does not work and occupancy pid is
both to user (why, he was only involved in the property of output files) and
root, and a simple kill pid does not work, I had to make recourse to the
dangerous kill -kill pid (always, not only once). In contrast, everything
flows smoothly with the same card and same file on the 32bit pc (either from
terminal window or kde). On the 64bit machine I had even a suggestion to
report a bug about malfunction of -p --preserve. Unfortunately I did nothing
and I did not take notice.
> > > If `make install` is not working,
> >
> > There is no makeinstall in the Makefile. Things are arranged that make
> > creates the executable that can be placed everywhere (with its needed
> > companions)
>
> Ah. Well, this is the sort of thing I should have expected from a
> programmer who is still using gets() . ;-)
I would be more cautious about that. That person was able to transfer
computational programs from mainframe to the first IBM PC (and I was using
them from the beginning), and he wrote ones that still have no equivalent on
earth. But I understand, he do not know him.
>
> > I believe you have grasped the point [about user #500] perfectly. Who
> > wrote
>
> the program is a
>
> > RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> > that, on my solicitation, he has installed debian too, but he was
> > probably pressed by the time. I was looking at 500: is that the decimal
> > corresponding to octal 764?
>
> 7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
>
> > At any event, I am happy to have the first important piece for my
> > calculations at 64bit with multiprocessor. Now I have to check if the
> > program is bug-free. A molecule of my repertoire will test that fully.
> >
> > Could you please help me further? I posed to the mpqc list the question
> > (unanswered) if it is safe to install on amd64 debian etch mpqc (the
> > second part of my calculations) made available for debian sid at
> >
> > http://packages.debian.org/unstable/science/mpqc
> >
> > What do you think? If safe, should I add a repository to my sources.list
> > for etch or there is another less risky way?
>
> What I've mostly done in the past, when wanting packages not available in
> the distribution I am using {e.g. my 32-bit Etch at home, when some KDE
> packages were unavailable}, has been to download the .dsc, .diff.gz and
> .orig.tar.gz files by hand, build the package:
> # dpkg-source -x foo.dsc
> # cd foo
> # dpkg-buildpackage
> and install the resulting .deb using
> # dpkg -i foo.deb
>
> Unstable {sid} packages generally will build fine on testing {etch at
> time of writing} except when a huge transition is taking place {eg. KDE2
> to KDE3, XFree86 to Xorg} and a dependency hasn't made it through the
> system yet. Depending upon how actively mpqc is being developed, you may
> even find that the Etch and Sid versions are the same.
>
> Good luck with it!
>
Thanks a lot
> --
> AJS
> de
Re: gcc
On Thursday 08 June 2006 18:14, A J Stiles wrote:
> On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> > Finally, I issued #make (from root) and then changed the ownership of all
> > *.c, *.o, *.h, and *.prm files, including the directory containing them.
> > It works perfectly at truly 64bit (of course it has no graphics, to this
> > end, but on the 32bit pc I have a sister program to examine graphically
> > the output). Impressive speed. The most tricky part is to create the
> > input on the 32bit pc and transfer to the 64bit workstation through a usb
> > card reader, complex because of the strict adherence of debian to
> > ownerships and permissions.
>
> Is there a good reason why you can't set up an NFS share between the two
> machines?
Really not. I am just at the beginning, with recoursing problems. NFS will be
the solution. And may be even vetter to create a 32bit chroot to run there my
pre-program. It may be useful in case of pc32 down. I never created a chroot
and take into account that I am a chemist (one of the very few scientists in
my country who does not know about Microsoft), I have to do chemistry. Time
is short.
I am experiencing unusual difficulties with these particular file transfers
from the 64bit side. Root is not allowed to transfer with preservation of
properties of output files (may be I am using wrong commands, however) and
files on the card reader refuse to be changed of ownership (here I am sure to
use the right commands). Moreover, umount does not work and occupancy pid is
both to user (why, he was only involved in the property of output files) and
root, and a simple kill pid does not work, I had to make recourse to the
dangerous kill -kill pid (always, not only once). In contrast, everything
flows smoothly with the same card and same file on the 32bit pc (either from
terminal window or kde). On the 64bit machine I had even a suggestion to
report a bug about malfunction of -p --preserve. Unfortunately I did nothing
and I did not take notice.
> > > If `make install` is not working,
> >
> > There is no makeinstall in the Makefile. Things are arranged that make
> > creates the executable that can be placed everywhere (with its needed
> > companions)
>
> Ah. Well, this is the sort of thing I should have expected from a
> programmer who is still using gets() . ;-)
I would be more cautious about that. That person was able to transfer
computational programs from mainframe to the first IBM PC (and I was using
them from the beginning), and he wrote ones that still have no equivalent on
earth. But I understand, he do not know him.
>
> > I believe you have grasped the point [about user #500] perfectly. Who
> > wrote
>
> the program is a
>
> > RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> > that, on my solicitation, he has installed debian too, but he was
> > probably pressed by the time. I was looking at 500: is that the decimal
> > corresponding to octal 764?
>
> 7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
>
> > At any event, I am happy to have the first important piece for my
> > calculations at 64bit with multiprocessor. Now I have to check if the
> > program is bug-free. A molecule of my repertoire will test that fully.
> >
> > Could you please help me further? I posed to the mpqc list the question
> > (unanswered) if it is safe to install on amd64 debian etch mpqc (the
> > second part of my calculations) made available for debian sid at
> >
> > http://packages.debian.org/unstable/science/mpqc
> >
> > What do you think? If safe, should I add a repository to my sources.list
> > for etch or there is another less risky way?
>
> What I've mostly done in the past, when wanting packages not available in
> the distribution I am using {e.g. my 32-bit Etch at home, when some KDE
> packages were unavailable}, has been to download the .dsc, .diff.gz and
> .orig.tar.gz files by hand, build the package:
> # dpkg-source -x foo.dsc
> # cd foo
> # dpkg-buildpackage
> and install the resulting .deb using
> # dpkg -i foo.deb
>
> Unstable {sid} packages generally will build fine on testing {etch at
> time of writing} except when a huge transition is taking place {eg. KDE2
> to KDE3, XFree86 to Xorg} and a dependency hasn't made it through the
> system yet. Depending upon how actively mpqc is being developed, you may
> even find that the Etch and Sid versions are the same.
>
> Good luck with it!
>
Thanks a lot
> --
> AJS
> delta echo bravo six four at earthshod dot co dot uk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Thursday 08 June 2006 13:08, Francesco Pietra wrote:
> Finally, I issued #make (from root) and then changed the ownership of all
> *.c, *.o, *.h, and *.prm files, including the directory containing them. It
> works perfectly at truly 64bit (of course it has no graphics, to this end,
> but on the 32bit pc I have a sister program to examine graphically the
> output). Impressive speed. The most tricky part is to create the input on
> the 32bit pc and transfer to the 64bit workstation through a usb card
> reader, complex because of the strict adherence of debian to ownerships and
> permissions.
Is there a good reason why you can't set up an NFS share between the two
machines?
> > If `make install` is not working,
>
> There is no makeinstall in the Makefile. Things are arranged that make
> creates the executable that can be placed everywhere (with its needed
> companions)
Ah. Well, this is the sort of thing I should have expected from a programmer
who is still using gets() . ;-)
> I believe you have grasped the point [about user #500] perfectly. Who wrote
the program is a
> RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
> that, on my solicitation, he has installed debian too, but he was probably
> pressed by the time. I was looking at 500: is that the decimal
> corresponding to octal 764?
7 * 64 + 6 * 8 + 4 = 448 + 48 + 4 = 500, yes.
> At any event, I am happy to have the first important piece for my
> calculations at 64bit with multiprocessor. Now I have to check if the
> program is bug-free. A molecule of my repertoire will test that fully.
>
> Could you please help me further? I posed to the mpqc list the question
> (unanswered) if it is safe to install on amd64 debian etch mpqc (the second
> part of my calculations) made available for debian sid at
>
> http://packages.debian.org/unstable/science/mpqc
>
> What do you think? If safe, should I add a repository to my sources.list
> for etch or there is another less risky way?
What I've mostly done in the past, when wanting packages not available in the
distribution I am using {e.g. my 32-bit Etch at home, when some KDE
packages were unavailable}, has been to download the .dsc, .diff.gz
and .orig.tar.gz files by hand, build the package:
# dpkg-source -x foo.dsc
# cd foo
# dpkg-buildpackage
and install the resulting .deb using
# dpkg -i foo.deb
Unstable {sid} packages generally will build fine on testing {etch at time
of writing} except when a huge transition is taking place {eg. KDE2 to
KDE3, XFree86 to Xorg} and a dependency hasn't made it through the system
yet. Depending upon how actively mpqc is being developed, you may even find
that the Etch and Sid versions are the same.
Good luck with it!
--
AJS
delta echo bravo six four at earthshod dot co dot uk
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Not avle to boot from the cd
On Thu, Jun 08, 2006 at 09:11:06PM +0530, Vinay Babu wrote: > I downloaded Sarge r2 disc1 and burned the iso onto CD for AMD 64 for my new > Tower ( Amd 3000+ 64 bit, Asus A8n motherboard, 512 MB 400 MHz Ram) I not > able to boot the CD. Please assist me. What program did you burn it in? What files do you see when you mount the cd and look at it? Is cd boot enabled in the bios before other drives? Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Not avle to boot from the cd
Hi all,I downloaded Sarge r2 disc1 and burned the iso onto CD for AMD 64 for my new Tower ( Amd 3000+ 64 bit, Asus A8n motherboard, 512 MB 400 MHz Ram) I not able to boot the CD. Please assist me.thanks in advance, vinay
Re: Unwanted messages
Jeudi 8 juin 2006, 17:15:54 CEST, Erik Mouw a écrit : > > On Thu, Jun 08, 2006 at 02:51:29PM +0100, A J Stiles wrote: > > We seem to be getting a lot of spam being sent to the list lately. > > Can we do anything to block it? Only accepting inbound mail from > > addresses on the recipients list would be a good start. Debian lists are open. It would be a policy change for all of them. The idea is that you don't have to subscribe to post. Some people don't like to have to "enlist" just to ask a single question. (Even if it doesn't too much for a single list, IMHO, having to subscribe is way too frequent these days.) > > Also, since > > we're all Debian users here, it might make sense to reject mail > > apparently coming from a Windows-based user-agent. And if Windows users want to get help for their not yet installed debian? Or, anything can happen, their not wishing-to-boot debian? The only way to stop spam is to stop buying their "stuff": if they spam it's because it works enough to make profit. -- Sylvain Sauvage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
Hello, the debian-ppc list suffers the same problem... I'm quite sure that the lists.d.o. admins are aware of the increasing spam. Kind regards, Marko -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
On Thu, Jun 08, 2006 at 01:33:57PM +0200, Goswin von Brederlow wrote: > Frans Pop <[EMAIL PROTECTED]> writes: > What changes are those? Is Debian finaly going to use LABEL= or UUID= > in the generated fstab? I hope not; /dev/disk/by-* names seem a lot less kludgy to me. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
On Thu, Jun 08, 2006 at 02:51:29PM +0100, A J Stiles wrote:
> We seem to be getting a lot of spam being sent to the list lately. Can we do
> anything to block it? Only accepting inbound mail from addresses on the
> recipients list would be a good start. Also, since we're all Debian users
> here, it might make sense to reject mail apparently coming from a
> Windows-based user-agent.
apt-get install spamassassin
Put this in your .procmailrc:
:0fw
* < 50
| /usr/bin/spamassassin
:0e
{
EXITCODE=$?
}
:0
* ^X-Spam-Status: Yes
spam
Erik
--
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
2006/6/8, [EMAIL PROTECTED] <[EMAIL PROTECTED]>: .. > first, there is already a spamassasin running on lists.debian.org it > seems... th best isconnect to http://lists.debian.org/ports.html read de mail in the list and mark it as spam -- Pere Nubiola Radigales Telf: +34 656316974 e-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
On Thu, Jun 08, 2006 at 04:45:36PM +0200, Albert Dengg wrote: > A J Stiles wrote: > > We seem to be getting a lot of spam being sent to the list lately. Can we > > do > > anything to block it? Only accepting inbound mail from addresses on the > > recipients list would be a good start. Also, since we're all Debian users > > here, it might make sense to reject mail apparently coming from a > > Windows-based user-agent. > > > > It was ironically endearing when it was adverts for pirated Windows > > software; > > but I get enough pr0n, phishing and share scams elsewhere without them > > coming > > through this list. > > > there are points against that... > first, there is already a spamassasin running on lists.debian.org it > seems... > > and to your suggestions: > i don't think blocking certian oses is good practice... > i for one am currently sitting on a windows machine, and i suspect that > there are some companies with debian servers and windows clients...so > block them? For that matter, I can well imagine posting from a friend's Windows machine when my Linux machine is hosed. Or when I'm having trouble installing my first dual-boot Windlws + Debian system I might will ask questions fom my Windows box. > > and the subscriber only policy is another problem: > because posting to a debian mailing list is nearly garanty for recieving > spam on that address, some people use fake addresse they don't read for > posting and let the messages be delivered to another one...so block > people that don't want to recieve spam? Further, the listmasters want to make it as easy as possible to ask for help. -- hendrik -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Unwanted messages
A J Stiles wrote: > We seem to be getting a lot of spam being sent to the list lately. Can we do > anything to block it? Only accepting inbound mail from addresses on the > recipients list would be a good start. Also, since we're all Debian users > here, it might make sense to reject mail apparently coming from a > Windows-based user-agent. > > It was ironically endearing when it was adverts for pirated Windows software; > but I get enough pr0n, phishing and share scams elsewhere without them coming > through this list. > there are points against that... first, there is already a spamassasin running on lists.debian.org it seems... and to your suggestions: i don't think blocking certian oses is good practice... i for one am currently sitting on a windows machine, and i suspect that there are some companies with debian servers and windows clients...so block them? and the subscriber only policy is another problem: because posting to a debian mailing list is nearly garanty for recieving spam on that address, some people use fake addresse they don't read for posting and let the messages be delivered to another one...so block people that don't want to recieve spam? yours albert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Thursday 08 June 2006 11:35, Adam Stiles wrote:
> On Wednesday 07 June 2006 20:06, Francesco Pietra wrote:
> > Yes, it was compiled OK. However, because make was from root, the
> > property of all compiled *.o files is root root. This makes some problems
> > in the use of the program, such as in deleting files.
> > Issuing
> >
> > ln -s /usr/bin/gcc-41 /usr/local/bin/gcc
> >
> > either as $ or #, followed by
> >
> > $ make
> >
> > reports
> > gcc -g -02 -c -o active.o active.c
> > cc1: error: active.c: Permission denied
> > make: *** [active.o] Error 1
> >
> > Perhaps, unless link/make can be arranged differently, the easiest would
> > be to change the property of all *.o files. Don'y remember how this could
> > be done with a single command.
>
> When you do
> # make install
> all the important files are copied somewhere sensible, usually
> /usr/local/bin which is in the standard path and out of reach of the
> package management system. You have to be root to do this, because
> ordinary users really should not be writing to such places.
>
Finally, I issued #make (from root) and then changed the ownership of all *.c,
*.o, *.h, and *.prm files, including the directory containing them. It works
perfectly at truly 64bit (of course it has no graphics, to this end, but on
the 32bit pc I have a sister program to examine graphically the output).
Impressive speed. The most tricky part is to create the input on the 32bit pc
and transfer to the 64bit workstation through a usb card reader, complex
because of the strict adherence of debian to ownerships and permissions.
> >
> If `make install` is not working,
There is no makeinstall in the Makefile. Things are arranged that make creates
the executable that can be placed everywhere (with its needed companions)
> then that indicates an error {as opposed
> to a warning; errors are serious enough actually to stop the compilation}
> somewhere. So you probably want to capture the full output to analyse at
> your leisure. Type
> $ script [filename]
> to begin capturing the terminal output into a file {if you don't give a
> filename the default will be 'typescript'}; then
> $ make
> to start the make process. Press ctrl+D at the end, to stop writing to the
> script file and save it.
>
> Now you can look through the file with an editor and see where the error
> occurred.
>
> > Incidentally, in previous compilation the proprty of *.c files was
> > francesco francesco. Now it is 500 500; I imagine that 500 stands for
> > francesco. True? You know, when such affaris are carried out
> > sporadically, memory about tends to vanish to make room to other storage.
>
> Unix stores the users and groups associated with files numerically, and
> looks them up for display. It's conventional that the low numbers are used
> for system users and "artificial" users, and higher numbers are the "real"
> users. On Red Hat systems and derivatives, non-system users start at 500;
> on Debian systems, non-system users start at 1000.
>
> What probably happened is that someone generated the tarball as the first
> non-system user on a Red Hat-ish system, who would have been numbered 500.
> One of the times that you extracted it, you took over ownership of the
> files; the other time, you preserved the original file ownerships {perhaps
> you extracted it as root or something}. Your Debian system doesn't have a
> user #500, so it can't give you a username.
I believe you have grasped the point perfectly. Who wrote the program is a
RedHat_ist, as far as linux is concerned. Normally he is BSD_ist. I known
that, on my solicitation, he has installed debian too, but he was probably
pressed by the time. I was looking at 500: is that the decimal corresponding
to octal 764?
>
> Not that it matters much because only root can do `make install`, and root
> can always read files belonging to anyone regardless of permission modes.
At any event, I am happy to have the first important piece for my calculations
at 64bit with multiprocessor. Now I have to check if the program is bug-free.
A molecule of my repertoire will test that fully.
Could you please help me further? I posed to the mpqc list the question
(unanswered) if it is safe to install on amd64 debian etch mpqc (the second
part of my calculations) made available for debian sid at
http://packages.debian.org/unstable/science/mpqc
What do you think? If safe, should I add a repository to my sources.list for
etch or there is another less risky way?
Thanks a lot
francesco pietra
>
> --
> AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Unwanted messages
We seem to be getting a lot of spam being sent to the list lately. Can we do anything to block it? Only accepting inbound mail from addresses on the recipients list would be a good start. Also, since we're all Debian users here, it might make sense to reject mail apparently coming from a Windows-based user-agent. It was ironically endearing when it was adverts for pirated Windows software; but I get enough pr0n, phishing and share scams elsewhere without them coming through this list. -- AJS delta echo bravo six four at earthshod dot co dot uk -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [MailServer Notification]Security Notification
On Thursday 08 June 2006 15:02, [EMAIL PROTECTED] wrote: > WORM_NETSKY.GEN has been detected,and Delete entire message has been taken be clear in language and please stte whether UTC > on 08.06.2006 16:02:08. > > Sistemimiz tarafından bu mailin içeriğinde virüs tespit edildiğinden dolayı > mesajınız silinmiştir. > > CMC IT
Re: dosemu or dosbox
On Thu, Jun 08, 2006 at 11:08:58AM +1000, Alexander Samad wrote: > so how does dosbox work ? Dosbox is a dos environment emulator, including all the hardware. It emulates all the old PC video modes (cga/ega/vga/tandy/etc) and sound cards (tandy/sb/gus/adlib/roland/etc) and the x86 cpu. It is of course much slower than dosemu since it emulates everything, but it runs on any architecture, and given the speed of modern PCs and the expectations of dos software, speed should not be a big problem. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[MailServer Notification]Security Notification
WORM_NETSKY.GEN has been detected,and Delete entire message has been taken on 08.06.2006 16:02:08. Sistemimiz tarafından bu mailin içeriğinde virüs tespit edildiğinden dolayı mesajınız silinmiştir. CMC IT -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: xorg 7.0 (glx problems--Error: couldn't find RGB GLX visual)
Frederik Juul Christiani-2 wrote: > > * rickh <[EMAIL PROTECTED]> [Jun 07. 2006 18:56]: >> When you say you 'installed' mesa-swx11-source, I assume you >> mean that you did compile/make. That doesn't intimidate me. >> ... But, if 'rebuilding and installing xserver-xorg-core' means >> you also compiled that from source, ... I'm hesitant. > > It really isn't as scary as it apparently sounds. > > $ sudo apt-get install -t unstable mesa-swx11-source > $ sudo apt-get build-dep xserver-xorg-core > $ sudo apt-get install fakeroot > $ apt-get source xserver-xorg-core > $ cd xorg-server-1.0.2/ > $ dpkg-buildpackage -rfakeroot > $ cd .. > $ sudo dpkg -i xserver-xorg-core_1.0.2-8_amd64.deb > > It worked for me. Let us know the results if you decide to try it. > Didn't get far. 2nd instruction, $ sudo apt-get build-dep xserver-xorg-core, returns: E: Could not open file /var/lib/apt/lists/debian.mirror.frontiernet.net_debian_dists_testing_main_source_Sources - open (2 No such file or directory) -- View this message in context: http://www.nabble.com/xorg-7.0-%28glx-problems--Error%3A-couldn%27t-find-RGB-GLX-visual%29-t1737529.html#a4771227 Sent from the debian-amd64 forum at Nabble.com. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
Frans Pop <[EMAIL PROTECTED]> writes: > (Also replying to other mails about Sarge support in Etch installer) > > On Wednesday 07 June 2006 20:42, Goswin von Brederlow wrote: >> Frans Pop <[EMAIL PROTECTED]> writes: >> I ment that when you select sarge in choose-mirror in expert mode you >> get the inofficial list and if you choose etch/etch+1/sid you get the >> official one. > > Ah, OK. > > The Etch installer currently has extremely basic support for Sarge > installations which has only really been tested for i386. The real > downside of using the Etch installer for Sarge is that, although a > current kernel will be used for the installation, it will still install > 2.6.8 for the target system (it does not use any backports). > > This means that there is a relatively high chance that the user will > experience problems on the reboot into the target system. Basicaly 100% since the user would/should have used the sarge installer if possible. But adding backports to the sources.list and installing a newer kernel is easily explained in a HowTo and done by the user on the fly. I don't think that this is a real show stopper. One could think about adding backports to sources.list automatically though if the testing installer is used to install stable. > I'm currently unsure if the udeb that adds Sarge support for the Etch > installer will make it into the final release of d-i for Etch. The main > reasons are: > - increasing differences between the Sarge 2.6.8 and current kernels; That is a reason for. > - questionable usability of systems installed this way; Hmm, what is questionable? A stable system with a fresher kernel is totaly usable. A lot, if not the majority, of users do this. > - Sarge support may be incompatible with changes needed to realize > persistent device naming for harddrives. What changes are those? Is Debian finaly going to use LABEL= or UUID= in the generated fstab? Isn't that also just limited to kernel, udev and fstab? udev is also available on backports so there should be no big problem there. > If it does make it, there will be disclaimers shown to the user after > mirror selection to the effect that there is only limited support and not > to come complaining if there are problems on reboot. Isn't it enough that you already need expert mode? > To finally answer your question: I don't think we will offer the > unofficial AMD64 mirrors in the Etch installer in this case, if only > because the mirror selection happens _before_ the suite/codename is > selected. That is a problem indeed. > Cheers, > FJP MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Which mirror to install etch or sid
thierry <[EMAIL PROTECTED]> writes: > thierry wrote: >> I am trying to install a box with amd64, using the latest daily >> build image (ie: downloaded about an hour ago). But I can't get a >> mirror to work. I get the following message: >> The specified Debian archive mirror is either not available, or does >> not have a valid Release file on it. Please try a different mirror. >> But all the mirrors give that error. Does anyone knows what to do? >> Thanks >> Thierry >> >> > OOOpss! I forgot to say that I used the netinst iso. > Thierry http://ftp.debian.org/README.mirrors.html MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: gcc
On Wednesday 07 June 2006 20:06, Francesco Pietra wrote:
> Yes, it was compiled OK. However, because make was from root, the property
> of all compiled *.o files is root root. This makes some problems in the use
> of the program, such as in deleting files.
>
> Issuing
>
> ln -s /usr/bin/gcc-41 /usr/local/bin/gcc
>
> either as $ or #, followed by
>
> $ make
>
> reports
> gcc -g -02 -c -o active.o active.c
> cc1: error: active.c: Permission denied
> make: *** [active.o] Error 1
>
> Perhaps, unless link/make can be arranged differently, the easiest would be
> to change the property of all *.o files. Don'y remember how this could be
> done with a single command.
When you do
# make install
all the important files are copied somewhere sensible, usually /usr/local/bin
which is in the standard path and out of reach of the package management
system. You have to be root to do this, because ordinary users really should
not be writing to such places.
If `make install` is not working, then that indicates an error {as opposed to
a warning; errors are serious enough actually to stop the compilation}
somewhere. So you probably want to capture the full output to analyse at
your leisure. Type
$ script [filename]
to begin capturing the terminal output into a file {if you don't give a
filename the default will be 'typescript'}; then
$ make
to start the make process. Press ctrl+D at the end, to stop writing to the
script file and save it.
Now you can look through the file with an editor and see where the error
occurred.
> Incidentally, in previous compilation the proprty of *.c files was
> francesco francesco. Now it is 500 500; I imagine that 500 stands for
> francesco. True? You know, when such affaris are carried out sporadically,
> memory about tends to vanish to make room to other storage.
Unix stores the users and groups associated with files numerically, and looks
them up for display. It's conventional that the low numbers are used for
system users and "artificial" users, and higher numbers are the "real" users.
On Red Hat systems and derivatives, non-system users start at 500; on Debian
systems, non-system users start at 1000.
What probably happened is that someone generated the tarball as the first
non-system user on a Red Hat-ish system, who would have been numbered 500.
One of the times that you extracted it, you took over ownership of the files;
the other time, you preserved the original file ownerships {perhaps you
extracted it as root or something}. Your Debian system doesn't have a user
#500, so it can't give you a username.
Not that it matters much because only root can do `make install`, and root can
always read files belonging to anyone regardless of permission modes.
--
AJS
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sarge3 kernel build & r3
(Also replying to other mails about Sarge support in Etch installer) On Wednesday 07 June 2006 20:42, Goswin von Brederlow wrote: > Frans Pop <[EMAIL PROTECTED]> writes: > I ment that when you select sarge in choose-mirror in expert mode you > get the inofficial list and if you choose etch/etch+1/sid you get the > official one. Ah, OK. The Etch installer currently has extremely basic support for Sarge installations which has only really been tested for i386. The real downside of using the Etch installer for Sarge is that, although a current kernel will be used for the installation, it will still install 2.6.8 for the target system (it does not use any backports). This means that there is a relatively high chance that the user will experience problems on the reboot into the target system. I'm currently unsure if the udeb that adds Sarge support for the Etch installer will make it into the final release of d-i for Etch. The main reasons are: - increasing differences between the Sarge 2.6.8 and current kernels; - questionable usability of systems installed this way; - Sarge support may be incompatible with changes needed to realize persistent device naming for harddrives. If it does make it, there will be disclaimers shown to the user after mirror selection to the effect that there is only limited support and not to come complaining if there are problems on reboot. To finally answer your question: I don't think we will offer the unofficial AMD64 mirrors in the Etch installer in this case, if only because the mirror selection happens _before_ the suite/codename is selected. Cheers, FJP pgp3KEfKaHthS.pgp Description: PGP signature
