Re: ABI choice for MIPS on debian lenny?
On Fri, Feb 27, 2009 at 09:22:19PM +0100, Laurent GUERBY wrote: Hi, On debian lenny I'm playing with GCC trunk (4.4) to build a tri-ABI compiler on a lemote netbook (running gnewsense kernel and lenny userspace). My understanding is that lenny userspace is -mabi=32 (o32) and GCC and libc support abi=32,n32,64, the kernel being 64. n32 seems to be more performant than 32, do you know why it is not used by default? Is it unsupported on some hardware? Unsupported on R3k/R2k which used to be release targets pre-lenny - Decstation 5000 and Co. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Life - Un salto nella tua filiera
To view the message, please use an HTML compatible email viewer!
Life - Un salto nella tua filiera
To view the message, please use an HTML compatible email viewer!
Architecture usertags
Hi, I've often thought that it would be useful to have tags in the BTS so that users or maintainers could mark a bug as specific to a particular architecture. This way, when I have some spare time, I could go to the BTS, fetch a list of bugs that are specific to an architecture I care about, and see what I can do about them, or give some feedback if that would help. Using a set of usertags under my own email address on the BTS wouldn't really work for that, since it kindof defeats the whole purpose; I want to use these tags to find bugs that I care about in the first place, but in order for me to be able to add a usertag, I would have to know about the bug before I could find it. Kind of a chicken-and-egg problem. So I suggested to Don Armstrong that he add a set of architecture-specific regular tags; but he seemed averse to this, as the current informal policy of the debbugs maintainers is to require that a usertag is used for a particular purpose before they add a new regular tag; this is so that no tags get created which won't be used. I guess this is a worty goal. After a short discussion on IRC, we came up with another option: a set of publically documented usertags, the definition of which would be announced on debian-devel-announce and linked to from the BTS homepage, so that maintainers could apply them to architecture-specific bugs when necessary. The format, suggested by Steve Langasek, was to use the porters mailinglist as the user, and the architecture name as the usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as tag). Before I'll fire off an email to d-d-a announcing that, does anyone have any comments, objections, or suggestions to improve this proposal? Thanks, -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 signature.asc Description: Digital signature
Re: Architecture usertags
Wouter Verhelst wrote: Hi, I've often thought that it would be useful to have tags in the BTS so that users or maintainers could mark a bug as specific to a particular architecture. This way, when I have some spare time, I could go to the BTS, fetch a list of bugs that are specific to an architecture I care about, and see what I can do about them, or give some feedback if that would help. Using a set of usertags under my own email address on the BTS wouldn't really work for that, since it kindof defeats the whole purpose; I want to use these tags to find bugs that I care about in the first place, but in order for me to be able to add a usertag, I would have to know about the bug before I could find it. Kind of a chicken-and-egg problem. So I suggested to Don Armstrong that he add a set of architecture-specific regular tags; but he seemed averse to this, as the current informal policy of the debbugs maintainers is to require that a usertag is used for a particular purpose before they add a new regular tag; this is so that no tags get created which won't be used. I guess this is a worty goal. After a short discussion on IRC, we came up with another option: a set of publically documented usertags, the definition of which would be announced on debian-devel-announce and linked to from the BTS homepage, so that maintainers could apply them to architecture-specific bugs when necessary. The format, suggested by Steve Langasek, was to use the porters mailinglist as the user, and the architecture name as the usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as tag). Before I'll fire off an email to d-d-a announcing that, does anyone have any comments, objections, or suggestions to improve this proposal? Thanks, Excellent news.This will come very handy.Thanks. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problem with lenny /usr/lib64/libdl.a from lenny libc6-dev-mips64
On Mon, Mar 02, 2009 at 12:37:56AM +0100, Aurelien Jarno wrote: On Sun, Mar 01, 2009 at 07:57:12PM +0100, Luk Claes wrote: Hi Lets involve the glibc package maintainers (Cc-ed). Cheers Luk Laurent GUERBY wrote: Hi, While investigating libmudflap failures in the GCC trunk (4.4) testsuite: http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00071.html I found out that /usr/lib64/libdl.a is corrupted and is causing link failures: gue...@gcc51:~/tmp3$ ar x /usr/lib64/libdl.a ar: /usr/lib64/libdl.a: Malformed archive (lib32 and lib are ok under the same test). For reference I tried to extract it again from a clean .deb but ar x failed again so I guess it's a packaging issue: I am able to reproduce the problem here, but not with version 2.9-4. It may be a problem on the build daemon (though the build log looks ok), or a bug in binutils while stripping, as at some point it used to output a lot of warning messages during dh_strip. I will start a build of the lenny version to see if the problem is reproducible after a rebuild. The build has finished, and the problem is fully reproducible. The libdl.a from the build tree works, the one in libc6-dev-mips64 doesn't. Something happens in between, probably either during dh_strip. I'll investigate that in the next days. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
SSH Installer annoyances
Hi there, I know it's probably all about security and what not, but is there any chance that when installing a Qube2 via the SSH installer the username could just be hard set to something easy ? Having it randomly generate a new password everytime is all lovely but bloody annoying when you have to squint at a non-backlit LCD in a cupboard! :-) Regards Mark -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How should/does Debian adapt to various hardware features?
On Feb 19, 6:00 am, Stefan Monnier monn...@iro.umontreal.ca wrote: Since the MIPS port of Debian supposedly works on pretty much any MIPS machine, that means it both works on machines like the old SGIs with their massive floating-point engines, and on home routers where the CPU doesn't even have any hardware floating point support. How does Debian handle this? Do `mipsel' packages always try to use the FPU-less version of libraries (e.g. libvorbisidec), or always the FPU-full version, or is it chosen arbitrarily on a case by case basis? As a user, how can I make sure that I get the package version best adapted to my hardware platform? I was under the impression that if a hardware FPU was not present the software one was used, so apps don't need to know they can just use FP and get the answers (wether it is done in hardware or software is not something they need to know), been ages since I built a kernel :-) I can also only assume that libvorbisidec is a specific library that doesn't even attempt to use floating point. Mark -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Architecture usertags
On Tue, Mar 03, 2009 at 10:03:18PM +0200, Vasilios Karaklioumis wrote: Wouter Verhelst wrote: Hi, I've often thought that it would be useful to have tags in the BTS so that users or maintainers could mark a bug as specific to a particular architecture. This way, when I have some spare time, I could go to the BTS, fetch a list of bugs that are specific to an architecture I care about, and see what I can do about them, or give some feedback if that would help. Using a set of usertags under my own email address on the BTS wouldn't really work for that, since it kindof defeats the whole purpose; I want to use these tags to find bugs that I care about in the first place, but in order for me to be able to add a usertag, I would have to know about the bug before I could find it. Kind of a chicken-and-egg problem. So I suggested to Don Armstrong that he add a set of architecture-specific regular tags; but he seemed averse to this, as the current informal policy of the debbugs maintainers is to require that a usertag is used for a particular purpose before they add a new regular tag; this is so that no tags get created which won't be used. I guess this is a worty goal. After a short discussion on IRC, we came up with another option: a set of publically documented usertags, the definition of which would be announced on debian-devel-announce and linked to from the BTS homepage, so that maintainers could apply them to architecture-specific bugs when necessary. The format, suggested by Steve Langasek, was to use the porters mailinglist as the user, and the architecture name as the usertag (e.g., 'debian-m...@lists.debian.org' as user, and 'm68k' as tag). Before I'll fire off an email to d-d-a announcing that, does anyone have any comments, objections, or suggestions to improve this proposal? Thanks, Excellent news.This will come very handy.Thanks. +1 -- dann frazier -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Large SATA drives in the Qube2
Hi there, For people looking to put a disk larger than 750GB into a Qube2 would normally require also installed a PCI SATA board and buying a SATA hard disk. Well I got one of those cheap SATA - PATA converters that plug straight into the IDE connector of the motherboard and it seems to work a treat! I've only tested on an 80GB SATA drive so far, but will be getting a 1.5TB drive on the weekend (if it doesn't work I still have plans for it :-) All going well with that I can free up the PCI slot and maybe put in a gigabit ethernet board instead. Regards Mark -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Cobalt Qube3 Professional
I know this is a MIPS forum, but I have a Cobalt Qube3 Pro with all recovery disks, manuals AND the very rare padded carrying case that I no longer need. Upgraded to 128Mb RAM and a second hard drive (200Gb) installed. If anyone is interested, or knows someone who is, get them to email me directly and make an offer.. It will be going on eBay sometime next week. Please note: this is probably only suitable for someone in Australia as, with all the addons and the carr case, it is reasonably large. Postage available, depending on the area. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
