Re: DSO linking changes for wheezy
On Sun, Nov 14, 2010 at 10:06 AM, Roger Leigh rle...@codelibre.net wrote: On Sun, Nov 14, 2010 at 01:51:49PM +0100, Kurt Roeckx wrote: On Sun, Nov 07, 2010 at 04:19:10PM +, Roger Leigh wrote: On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote: For wheezy I'm planning to change the linking behaviour for DSOs (turning on --as-needed and --no-copy-dt-needed-entries. The rationale is summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues with these changes on some of the Debian ports, and if we need to disable one of these changes on some port. While I understand the rationale for --no-copy-dt-needed-entries for preventing encapsulation violations via indirect linking, I don't agree with the use of --as-needed *at all*. If a library has been explicitly linked in, it shouldn't be removed. This is an issue for fixing in individual packages, not in the toolchain. I can understand on using it on a per-package basis, but not in the actual toolchain defaults. The compiler and linker *should not be second-guessing the user*. This can break perfectly legitimate code making use of ELF constructors and other features which won't be picked out just by looking at symbol usage. People have been claiming that constructors or init section are a possible problem. I have yet to see an example where it breaks. It's not a very widely used feature. I'm sure it's trivial to make such a test case. Portable software tends not to make use of ELF- specific features like this, but that's not an excuse for breaking perfectly legitimate code. But whether or not there are real life examples, --as-needed is *fundamentally wrong*. It's deliberately *not doing what the user requested*, and to make that misfeature the system-wide default would be entirely inappropriate. If a package wishes to make use of such a feature after understanding the implications, then they are free to do so. But to make it the default--I don't think that's a technically sound decision. Please ignore me if I've misunderstood the situation, firstly. Both Fedora and Gentoo are using --as-needed by default now. And from what I've read (google: site:blog.flameeyes.eu as-needed) --as-needed is certainly useful and prevents lots of unnecessary problems. It's deliberately *not doing what the user requested* - In the case of Gentoo, the problem is that the user himself isn't specifically requesting all these libraries are linked in. They're specified by the build system or .la files. If the user wants lots of libraries linked in unnecessarily, then he can turn off --as-needed. So, I guess I'm not understanding what the problem with --as-needed is, exactly. Thanks, Matt -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktim6q3wvkh_crahhs_5rnkakq6rnfvfksmcpt...@mail.gmail.com
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 8:15 PM, Samuel Thibault sthiba...@debian.org wrote: Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit : On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh rle...@codelibre.net wrote: What's the actual problem --as-needed is trying to solve? The answer is mainly unwanted libraries being linked in as a result of using pkg-config (and various other -config variants), though there are other, lesser, culprits. The pkg-config .pc files for gtk, gnome and other libraries add in many libraries, most of which aren't typically needed. The solution: fix the .pc files! Using --as-needed is merely papering over the actual root problem. It fixes the symptoms, but it's not addressing the actual cause. The number of packages providing broken .pc files is not large, and the number breaking due to relying on this brokenness is likely just as small. I can't see why you think --as-needed is fundamentally wrong or unnecessary. Check out http://www.gentoo.org/proj/en/qa/asneeded.xml --as-needed has saved tons of time for upgrades like Cairo in Gentoo, where Cairo had been linked to glitz which is now useless and gone. Not a problem, if Cairo was properly exposing the dep. So when people upgraded Cairo, all the software that linked against it (and also unnecessarily linked against glitz) Why did it get linked against glitz? That's where the problem is. I think because -lglitz was in cairo's .pc file. Matt -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=tex5afxojxthnva0wcvrha9b-njkem7dnc...@mail.gmail.com
Re: [PATCH] build: Support building Loongson code for 2e, 2f, 3a
On Sun, Jan 6, 2013 at 7:46 PM, Cyril Brulebois k...@debian.org wrote: Hello Matt, Matt Turner matts...@gmail.com (06/01/2013): On Sat, Sep 15, 2012 at 11:59 PM, Matt Turner matts...@gmail.com wrote: pixman/Makefile.am contains a hack that allows pixman-mmx.c to be compiled with different overriding CFLAGS, since automake seriously doesn't have a way to do this. Seriously stupid. It works by defining a new rule and recursively calling make with modified CFLAGS set. Note the difference between the USE_LOONGSON* and HAVE_LOONGSON* preprocessor macros. Cc: Cyril Brulebois k...@debian.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51451 --- Cyril, I've updated the patch so that it builds .so files for each architecture against which pixman links and attached it to the bug report. Please give it a test. I cannot test it, as my system is compiled with -march=loongson2f and therefore I cannot even link code compiled with -march=loongson2e with my C library. thanks; unfortunately I'm busy working on the Debian Installer right now and pixman is a bit further down my todo list. Adding debian-mips@ to Cc, hoping somebody there will be able to perform some tests/share some insight. Mraw, KiBi. Any testers, debian-mips@? -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38f4ygbjecvgnz6txvratr4fpvgeug5hvoedpw489vh...@mail.gmail.com
Re: Possible GSoC idea: MIPS N32 ABI Port
On Fri, Mar 1, 2013 at 3:10 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? The things I know about are: - handling NaN cases for Loongson-specific floating-point instructions in the kernel FPU emulator. There are some patches, but they need to go through review and a bit of clean up. - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've spent /some/ time on each of these. BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) Not having to apply hacky patches the kernel and X server to have a usable system seems like an intrinsic benefit to me. As far as performance goes, maybe you could find something to optimize with the MMI instructions like I did for pixman [1]. I'm not sure what though. I think MIPS (the company) contributed a MIPS-backend to Firefox's JavaScript JIT compiler but only for o32. Updating it, or perhaps contributing a new one, for N32/N64 might make a nice project. It would certainly improve the Firefox user experience on Loongson. That would be useful for Loongson 2F, 3A, and any other hardware that's n32-capable. [1] http://mattst88.com/blog/2012/05/17/Optimizing_pixman_for_Loongson:_Process_and_Results/ -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38Eh=jdwjjuk-nzmczqdnt+xtgj-34q9a83z383ezht...@mail.gmail.com
Re: Possible GSoC idea: MIPS N32 ABI Port
On Fri, Mar 1, 2013 at 4:46 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: On Fri, Mar 01, 2013 at 04:14:56PM -0800, Matt Turner wrote: On Fri, Mar 1, 2013 at 3:10 PM, Aaro Koskinen aaro.koski...@iki.fi wrote: Hi, On Fri, Mar 01, 2013 at 11:01:20AM -0800, Matt Turner wrote: Besides questionable usefulness, since the hardware is sort of obsoleted by new Loongson 3A hardware, the actual work to do involves getting code upstream that Lemote was too lazy to upstream. What code are you referring to? The things I know about are: - handling NaN cases for Loongson-specific floating-point instructions in the kernel FPU emulator. There are some patches, but they need to go through review and a bit of clean up. Does (mainline) toolchains generate these instructions? But this sounds like a real issue. Yes, these instructions are generated. Problems are rare since it involves (IIRC) the instruction being given NaN or QNaN as input, though they have been seen: https://groups.google.com/forum/?fromgroups=#!topic/loongson-dev/vdtRTO-c5Bg - Making the X server work on 2F. Lemote (or someone?) wrote patches, but they're awful hacks not suitable for upstream. Real work needs to happen here. - There are patches for the siliconmotion DDX that use MMI to speed up YUV colorspace conversion. This code should really be in pixman, with the X server using that. I've used X (from Debian) on 2F, so it must work. :-) So I guess you are talking about optimizations here? No, not optimizations, and an unpatched X server does not work with the siliconmotion driver on Yeeloong. Are you using the siliconmotion driver or fbdev? BTW, what are the practical benefits of this effort, especially on Loongson 2F HW? (Any performance figures?) Not having to apply hacky patches the kernel and X server to have a usable system seems like an intrinsic benefit to me. (Actually, I meant the actual measured benefit of n32 vs. current ABI. I of course agree all critical patches should be upstreamed.) Ah, I see. In general N32 provides performance improvements over O32, yes. It allows - native 64-bit integer operations; - passing more than four (?) function arguments by register; - double the number of floating-point registers. Double the number of floating-point registers is hugely important for pixman's Loongson MMI code, and thus graphics in general since basically all rendering is done in software (via pixman) on the 2F+siliconmotion. I'm sure I've done some general benchmarks, but I don't have numbers easily available. As far as performance goes, maybe you could find something to optimize with the MMI instructions like I did for pixman [1]. I'm not sure what though. I think MIPS (the company) contributed a MIPS-backend to Firefox's JavaScript JIT compiler but only for o32. Updating it, or perhaps contributing a new one, for N32/N64 might make a nice project. It would certainly improve the Firefox user experience on Loongson. That would be useful for Loongson 2F, 3A, and any other hardware that's n32-capable. Last time I tried to use latest iceweasel/firefox, it failed due to assumption of 4 KB page size. So the first thing to improve user experience would be to fix all userspace not to assume any specific page size... Indeed. Or maybe fix kernel so that 4 KB page can be used again on Loongson. Until that n32 won't help nothing. It does (just not on Loongson 2). Avoiding the Firefox problem with page sizes and making the kernel use 4K pages is, I imagine at least, the thinking that has led to lots of hacky patches not being upstream. :) For reference, 315fe625 is the relevant kernel commit that disabled 4K pages on Loongson. Since 4K pages would require extra cache flushing to avoid aliasing problems, it's definitely not what you want to do if you care about performance. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38GgSrO5xrsdiZBOCfrsjqsa0M0F-LE=x8R1DjFYAq=3...@mail.gmail.com
Re: iceweasel mipsel builds failing
On Sun, Mar 10, 2013 at 6:23 AM, Steven Chamberlain ste...@pyro.eu.org wrote: Hi, Please could anyone suggest what is wrong with iceweasel builds on mipsel? It has failed twice on eysler at the same stage (linking libxul.so), despite always being able to build on that buildd in the past. Perhaps using a lot of memory and doing heavy swapping? Maybe it is worth giving back on buildd mayer in case it is any more powerful? https://buildd.debian.org/status/fetch.php?pkg=iceweaselarch=mipselver=10.0.12esr-1%2Bnmu1stamp=1362840128 rm -f libxul.so /usr/bin/python2.7 ../../../config/pythonpath.py -I../../config ../../../config/expandlibs_exec.py --uselist -- g++ -D_FORTIFY_SOURCE=2 -fno-rtti -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wformat -Werror=format-security -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe -DNDEBUG -DTRIMMED -g -Os -freorder-blocks -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsRDFResource.o-Wl,--as-needed -lpthread -Wl,-rpath-link,/build/buildd-iceweasel_10.0.12esr-1+nmu1-mipsel-68J7MH/iceweasel-10.0.12esr/build-xulrunner/dist/bin -Wl,-rpath-link,/usr/lib../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../st aticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libjetpack_s.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a .. /../stati clib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libsystem-pref.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../sta ticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfx2d.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libmozreg_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libycbcr.a ../../staticlib/libangle.a -L../../dist/bin -L../../dist/lib -ljpeg ../../media/libpng/libmozpng.a ../../gfx/qcms/libmozqcms.a /build/buildd-iceweasel_10.0.12esr-1+nmu1-mipsel-68J7MH/iceweasel-10.0.12esr/build-xulrunner/dist/lib/libmozjs.a -L/usr/lib/mipsel-linux-gnu -lssl3 -lsmime3 -lnss3 -lnssutil3 -lcrmf -lcairo -lpixman-1 -lfreetype -lfontconfig-lXrender -lcairo -lX11 ../../gfx/harfbuzz/src/libmozharfbuzz.a ../../gfx/ots/src/libmozots.a -lsqlite3- lz -lhun spell-1.3 -L/usr/lib -levent -L/usr/lib -lvpx -lasound -lrt -L../../dist/bin -L../../dist/lib -L/usr/lib/mipsel-linux-gnu -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -ldbus-glib-1 -ldbus-1 -lgobject-2.0 -lglib-2.0-lX11 -lXext -lpangoft2-1.0
Re: [GSoC 2013] MIPS N32/N64 ABI port project
On Thu, Apr 11, 2013 at 4:46 PM, Claudiu Olteanu olteanu.vasilica.clau...@gmail.com wrote: Hi there! My name is Claudiu Olteanu, I'm from Bucharest, Romania and I study at the University 'Politehnica' of Bucharest, the Faculty of Automatic Control and Computers Science. I'm a third year student and I would like to participate to GSoC this summer. After I took a look at the projects list I decided that it would be interesting and motivating to work on MIPS N32/N64 ABI port project. I will appreciate it if you give me more details about them and some advice that can put me on track. You can find my CV here[1] in case you want to know more about me. Regards, Claudiu [1] - https://docs.google.com/file/d/0BwSntkUS-WYzWUR0ejBmR0RrdzA/edit?usp=sharing I'll copy-and-paste what I said to the other guy who suggested an N32 Debian port (on March 1, check the archives for the full thread): Disclaimer: I'm not a Debian developer or even a user. I am, however, a Gentoo/MIPS developer who completed our n32 port. There were some annoying bits, like packages that hardcode 'lib', but overall it's not a difficult task. Other distributions are already n32, so there's not much if any package porting to do. The scope of this project would be entirely within Debian, getting Debian's infrastructure going for n32. I don't personally think that's a SoC project, but I don't know. Maybe a Debian/n32 port involves lots of work I don't know about, but for Gentoo it was mostly recompile a bunch of stuff and fix things that break. IIRC, I was *terribly* unimpressed with the 2009 Port Debian to N32 project. It was just a recompile everything and see what breaks endeavor, which is what other people have done with much more success (see: Gentoo, Parabola). [Removed paragraph about Lemote hardware] If you do this project, a suggestion: Ship gcc as an n64 binary. n32 has a virtual memory limit of 2G, so a n32 gcc binary would be unable to build large projects like webkit. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38e5bqivii6fh9p7k9jkaqdtfzhrr9fmho6ffrybx4u...@mail.gmail.com
Re: [GSoC 2013] MIPS N32/N64 ABI port project
On Thu, Apr 11, 2013 at 7:37 PM, Aron Xu happyaron...@gmail.com wrote: On Fri, Apr 12, 2013 at 10:10 AM, Matt Turner matts...@gmail.com wrote: I'll copy-and-paste what I said to the other guy who suggested an N32 Debian port (on March 1, check the archives for the full thread): Disclaimer: I'm not a Debian developer or even a user. I am, however, a Gentoo/MIPS developer who completed our n32 port. There were some annoying bits, like packages that hardcode 'lib', but overall it's not a difficult task. Other distributions are already n32, so there's not much if any package porting to do. The scope of this project would be entirely within Debian, getting Debian's infrastructure going for n32. I don't personally think that's a SoC project, but I don't know. Maybe a Debian/n32 port involves lots of work I don't know about, but for Gentoo it was mostly recompile a bunch of stuff and fix things that break. IIRC, I was *terribly* unimpressed with the 2009 Port Debian to N32 project. It was just a recompile everything and see what breaks endeavor, which is what other people have done with much more success (see: Gentoo, Parabola). I don't quite get the point why do you think others have done with much more success when this project isn't started anyway. Read the blog of the guy who tried to do this project in 2009: http://sandyleo26.wordpress.com/2009/04/05/gsoc-proposal-creating-a-new-mips-n32-abi-port-for-debian/ Gentoo and Parabola have working n32 ports. People use them. That's much more success than the previous N32 GSoC project (and I suppose any n32 work since then). Maybe this is actually an argument for doing an N32 port? It's really not simply recompiling everything because of the presence of real-life Multi-Arch, and actually recompiling everything isn't even a required task in the project's description. My experience porting Gentoo to N32 was bootstrapping my an N32 base system, finding and fixing bugs, and finally building installation media. I don't feel like there was enough actual development in what I did to warrant a GSoC project. But I'm not a Debian developer or user, so maybe I don't know what is required for Debian. What would your deliverables be? -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38F-wyjZ5Cx+0Ug91zwOs8VyfbHcebUpFO2tQ=fwqvk...@mail.gmail.com
Re: Multilib directory of n32 libs
On Sat, Jun 8, 2013 at 8:54 AM, YunQiang Su wzss...@gmail.com wrote: Any idea about is there another distribution has n32 or n64 port, and at the same time that multilib is supported? Yes, Gentoo. We do the standard o32 - lib, n32 - lib32, n64 - lib64. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38fhs1uzaf541v4xeejnfpyrtuqbrkm7lo2rv5adrbo...@mail.gmail.com
Re: Multilib directory of n32 libs
On Sat, Jun 8, 2013 at 7:23 PM, YunQiang Su wzss...@gmail.com wrote: On Sun, Jun 9, 2013 at 12:23 AM, Matt Turner matts...@gmail.com wrote: On Sat, Jun 8, 2013 at 8:54 AM, YunQiang Su wzss...@gmail.com wrote: Any idea about is there another distribution has n32 or n64 port, and at the same time that multilib is supported? Yes, Gentoo. We do the standard o32 - lib, n32 - lib32, n64 - lib64. Is there a port to n32 or n64 of gentoo? On n32 or n64 port, is it fit to put o32 libraries into lib directly? Yes, I have n32-multilib (n32 base system, and n64 and o32 glibc and gcc libraries) and n64. o32 goes in lib regardless of the ABI of the base system. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caedq38hpyikdlqqnjdghrbb7y7wg4oiws2ocbhl-2htqk61...@mail.gmail.com
Re: Is SGI Octane supported?
On Fri, Nov 29, 2013 at 5:45 AM, T. Ermlich pelegr...@gmx.net wrote: Dear list, Wheezy runs fine on my SGI O2, so I bought an Octane ... love the cases ;) I checked http://www.debian.org/ports/mips/ and mipsel, and found no information regarding an Octane. But I'm curious as arcload (http://packages.debian.org/stable/arcload) supports it ... Is it possible to install Debian on an Octane? Support for Octane never made is into the kernel and has seriously bitrotted since it was written (~2.6.19). Thus Debian can't support Octane. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAEdQ38FQm+n2H7t4NXuDeNnZpbvTsM=c1yv9sfr+5lqce62...@mail.gmail.com
Re: Multilib directory of n32 libs
On Wed, May 28, 2014 at 5:19 PM, David Kuehling dvdkh...@posteo.de wrote: What would you suggest WRT the build failures that Yunqiang mentioned? Do we now need to file bugs against all packages that assume that one or another library resides in /usr/lib? Yes. I expect there are very few problems in this area anymore. Gentoo's already done this work for you. -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caedq38hhmfqrckioqwgqhsje6vxrkmqdlow6fhin10f8igi...@mail.gmail.com
Re: Cobalt RaQ2 boot/shutdown sequence on LCD
On Wed, Mar 4, 2015 at 9:11 PM, v...@cgocable.ca v...@cgocable.ca wrote: On 2015-03-02 5:11 PM, Matt Turner wrote: On Sat, Feb 28, 2015 at 5:52 PM, v...@cgocable.ca v...@cgocable.ca wrote: Hi everyone, I used to have a patch or script to display startup and shutdown scripts on boot and shutdown years ago. I can't seem to find it online anymore and I have just refreshed my 2 RaQ2's. I'd like to have that information again if someone could help me find the patch/script to achieve this. It would say Starting up ... on the first line, and the second line would show apache.sh and change for every script. I don't know if this is the same thing, but Gentoo has a sys-apps/cobalt-panel-utils package. The homepage is dead since 2008, but the tarball is still available on the mirrors: http://gentoo.osuosl.org/distfiles/cobalt-panel-utils-1.2.tar.gz Dead link unfortunately. All I could find was a .ebuild which didn't help me much. Ah, apologies. I left out a .0 The real link is: http://gentoo.osuosl.org/distfiles/cobalt-panel-utils-1.0.2.tar.gz -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caedq38gwf-xslkrk+c4r8wzrggalvy_acvyxemwous_zi2a...@mail.gmail.com
Re: Cobalt RaQ2 boot/shutdown sequence on LCD
On Sat, Feb 28, 2015 at 5:52 PM, v...@cgocable.ca v...@cgocable.ca wrote: Hi everyone, I used to have a patch or script to display startup and shutdown scripts on boot and shutdown years ago. I can't seem to find it online anymore and I have just refreshed my 2 RaQ2's. I'd like to have that information again if someone could help me find the patch/script to achieve this. It would say Starting up ... on the first line, and the second line would show apache.sh and change for every script. I don't know if this is the same thing, but Gentoo has a sys-apps/cobalt-panel-utils package. The homepage is dead since 2008, but the tarball is still available on the mirrors: http://gentoo.osuosl.org/distfiles/cobalt-panel-utils-1.2.tar.gz -- To UNSUBSCRIBE, email to debian-mips-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAEdQ38EM=_fnziw_emczbqxlzdcsta+n68+20nqj++uag5d...@mail.gmail.com
Re: Debian/MIPSeb: proposal to drop mipseb port?
On Sat, Jul 21, 2018 at 12:18 PM J.P.Malhado wrote: > > On Mon, 9 Jul 2018 18:13:43 +0800, YunQiang Su wrote: > > We need some more build machines, current we use some ER8s, > > which use NFS as rootfs and they have no FPU. > > So the performance and stability are bad. > > I'm commenting here from a position of ignorance: > Would SGI hardware make good build machines for the architecture? I'm asking > because I have a 3 SGI Octanes I could give away. Doubtful. Octanes use hundreds of watts and aren't very fast compared with modern systems. They are indeed big endian, however. Debian used to have some Broadcom SWARM (BCM91250A) systems. They're bootable as big or little endian (controllable with a jumper on the motherboard). I have some that I attempt to use for Gentoo, but they're unstable and their kernel support seems to be totally unmaintained. Aurelien, do you know what happened to those systems? I don't see them listed here: https://wiki.debian.org/MIPSPort#Build_daemons_.26_porter_boxes (Gentoo would love your hand-me-downs if you're no longer using them :) > Last I checked, stretch kernels did not work on these machines, but I would > like > to be wrong. > Is the problem with the linux port, or is it related with Debian's compilation > options? Lack of upstream kernel support. > According to this information from Gentoo > https://wiki.gentoo.org/wiki/MIPS/Hardware_Requirements#IP30:_Octane > it should be semi-functional, but that information might be out of date. The maintainer of T2 Linux (René, Cc'd) has a YouTube channel in which he demonstrated an Octane running a modern (4.8?) kernel he had patched. I have not seen evidence of those patches going upstream though. As far as I know his work is in a significantly better state than that of Joshua's (from Gentoo).
