adamw
-
Posts
2327 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by adamw
-
-
"Actually Suse (at least the version preinstalled on my Mini-Note) uses the binary only driver from VIA."
Oh, that hunk of crap. Heh.
"I assume it's just a drop-in replacement, no need to upgrade anything else?"
It should be, yeah. It's completely untested as I have no Chrome hardware, but this is according to the suggestion of the upstream author, who has apparently already run into a couple of MiniNote users and found that current SVN fixes their troubles.
-
The first pre-release of Mandriva Linux 2009 Spring is now available. This alpha concentrates on updating to the major desktop components of the distribution, including KDE 4.2 Beta 2, GNOME 2.25.2, Xfce 4.6 Beta 2, X.org server 1.5, and kernel 2.6.28 rc8. It is also the first distribution to introduce the major new Tcl/Tk release, 8.6. The alpha is available only in the DVD Free edition with a traditional installer and no proprietary applications; future pre-releases will add the live CD One edition with proprietary drivers. Please help test this first pre-release and report bugs to Mandriva.
-
...but your monitor is not an input device.
The problem is not input hotplugging, which is irrelevant here, but RandR 1.2-compliant drivers. These don't use the old xorg.conf format for specifying preferred resolution and all that jazz, they'll happily ignore it. You can, however, specify preferred resolution in a way that RandR 1.2-compliant drivers should accept. Details here:
-
As it happens, I do have a suggestion.
Use this:
http://www.happyassassin.net/extras/x11-dr...2009.0.i586.rpm
and it should work no problems.
That's the current SVN openchrome, it's known to work fine on the MiniNote, 0.2.903 is known to have mode setting issues.
I suspect SUSE worked because they don't have openchrome properly at all, so you wind up with the 'vesa' driver, which happens to give you the right resolution but will be pretty slow. openchrome's a much better bet, with this bug fixed.
-
Ah, not so fast, boys. :)
It's actually normal that kernel-desktop won't detect all of 4GB of RAM.
What it can actually handle is all RAM in the address space from 0GB to 4GB.
Thanks to the vagaries of the PC architecture, on a system with 4GB of RAM, quite a lot of it winds up in the address space above 4GB. This is because there are various 'holes' between 0 and 1GB for all sorts of ancient and arcane reason. Bottom line is, on any OS kernel which can only detect up to the 4GB address space limit, you won't see all of 4GB if the system has it installed. Exactly how much you see depends on several factors, especially your video card.
This is explained in more detail by Dan of Dan's Data here:
http://www.dansdata.com/askdan00015.htm
But note that Dan doesn't consider the possibility of a 32-bit kernel capable of supporting 64GB of RAM, because there is no such thing in the Windows world. In the Linux world, there is.
but the bottom line, this is normal and expected. To access all 4GB you need a 64GB kernel, like kernel-server.
if you're running the x86-64 edition of Mandriva, BTW, there's no such limitation. The -desktop kernel in the x86-64 edition can address waaaaaaaaaaaaaaaaaaaay more than 4GB of RAM.
-
This should basically replace the old club.comm repo, and we will actually be able to provide updates for commercial stuff properly now. yay!
I don't know if it works for people who bought a PWP but don't have a PWP subscription. I'll check.
-
70771ff3 is the /main/release key, what repo did that package come from?
-
-
Chris: I did tell you to make sure you updated all the packages. I believe that's a symptom of updating some but not all.
-
I uploaded a fixed package to 2009.0 /main/testing yesterday. Any further crashes are likely bugs in upstream Kompozer, not something wrong with our build. Apparently the upstream guy is working on an update based on the latest Gecko, he is about half done.
-
Well, you can find the packages on the official repositories. There's a list of mirrors here:
http://api.mandriva.com/mirrors/basic.2009.0.i586.list
on any of those sites, in the /official/2008.0/i586/media/main/release , you'll find the packages. You may need to track down some dependencies, though, doing it manually. Why doesn't the system have internet access?
-
Can't give you an exact number but I suspect you'd be lucky to get it to build with much past 2.6.23. Definitely not 2.6.27, which is what 2009 is on. Sorry :\
What does Xorg.0.log say about the problem loading dri?
-
I'm not sure, but we did send 2.0 final to /main/testing lately. You could try that? Make sure to update *all* packages with amarok in the name, not just the main one.
-
What's the output of:
lspcidrake -v
run as root?
(Yes, I know these aren't PCI devices - lspcidrake will actually show USB devices too).
-
My point was only that Reiver was not correct to say that we were slow to respond to netbooks. We weren't. We ran on the Classmate (the predecessor of all modern netbooks), we work with Intel on UMPCs, we had our mainline distro running properly on netbooks way before anyone else, and we started working on OEM deals early. How, for instance, do you guys know we weren't involved in the competition for every one of those 'big manufacturer' deals? Maybe we were.
(I don't know. No-one tells me.)
-
"Mandriva was far too slow to react to the netbook boom loosing out to Xandros, Linpus and Ubuntu"
We had two netbook OEM deals announced before Ubuntu ever came up with Netbook Remix. One is already available in France - http://www.clubic.com/article-244144-7-pet...f-netbooks.html .
-
Great, glad it's all working out for you :)
-
Yes, that's why I was asking whether it was 2009 or 2008 Spring. Thing is, I didn't think that problem was present in 2009. I guess it might be with KDE 3, though. Well, let us know if that helps, OP.
-
Boot to a console, login as root, and do 'urpmi --auto-update -v'. And also 'urpmi kdm'.
-
Are you sure this is 2009 and not 2008 Spring?
-
orts: I really haven't done much on Bugzilla for a few months, I just haven't had time. If anything it's been Pacho Ramos and Stephane Teletchea taking care of it lately. I've only been handling matters of policy for the bug squad, and bugs that are listed in the Errata or that come up while I'm doing the forums.
surfer: "I have been chewing over the very same thoughts since this affair started. The next question is what does one need to maintain a distro, as in disk space etc. Aso the very big question I have asked myself, what does it take to produce and maintain a distro?"
To maintain an entirely independent distro takes quite a lot of resources. I think for a fairly basic desktop-only distro you'd need at least the equivalent of five to ten full-time maintainers, with a high degree of technical competence. You'd need a reasonably powerful build machine / cluster (Mandriva has five i586 build hosts that were cutting-edge hardware a couple of years back, and three x86-64 build hosts that were cutting-edge last year). It's not a particularly easy endeavour. You can run a piggyback distro like Mint or (to a lesser extent) PCLOS with fewer resources, but then you don't really control your own destiny.
Mandriva has, by my rough estimate, about the equivalent of 30 full-time staff working on the distro, plus maybe about an equivalent 20 further full-time staff provided by volunteers. Even that is basically a skeleton crew; other distros have far higher maintainer : package ratios. It'd be very hard to independently maintain a distro the size of MDV with any fewer bodies.
edit - disk space is, in fact, an issue, because you have to store all your sources, plus their history (well, you don't HAVE to store the history, but it's a really good idea - Mandriva's complete package revision history is stored in SVN/CVS), for all your releases. And it's a really good idea to do it on a proper RAID array (so you need even more space), and keep it properly backed up (so you need a whole second set of drives, or a proper tape backup system). Our build cluster is forever running out of disk space.
-
As I posted in the official forums:
I can't control anyone's reaction, of course, but I'd be really sad if this led to pain for Mandriva, the distribution. I've always been here, doing this job, because I love Mandriva the distribution and the community. I'm going to stick around those as long as they're still here, and I'd be really happy if the rest of you guys do that too. Whatever problems the company has, Mandriva to me is first and foremost a bunch of great, crazy people who believe we can make the best operating system in the world with a few dozen engineers and a lot of duct tape, and we're doing pretty damn well at it, I like to think. So I want that to keep going as long as it can.
I'm still working my ass off on 2009 Spring, and I hope it'll be a great release, and you guys will all be around to use it.
-
In any case, his premise is entirely flawed. Most of the Windows codebase has been leaked (it's happened several times) and is easily available in all the wrong places. Just because it's not *legal* to acquire the Windows source code doesn't mean you *can't* - and the kind of people who attempt to exploit operating systems are hardly likely to worry about legality.
The argument is completely wrong too, of course, but you don't even have to bother engaging him that far down the road. It fell at the first hurdle.
-
"I think therefore as an interim solution, to give users a choice it would still be great if we could have the binary VIA driver packaged up for Mandriva 2009 (at the very least to be on par with Ubuntu, as there is a Ubuntu version!)."
I agree it'd be nice, and if it were like the NVIDIA or ATI drivers - it came with an interface you could build to make it work on any distro - I'd do it. But it doesn't, so getting it would involve politics (i.e. find the right person to ask at VIA to get them to build a version for Mandriva), which is much more painful. Which is why it hasn't been done yet.
Of course, if you managed to get VIA to build a Mandriva version of the driver, I'd be happy to package it...
why so many dependency conflicts? [solved]
in Software
Posted
Yes. Packages in Main only rely on other packages in Main. Packages in Contrib rely on packages in Main and other packages in Contrib. Packages from PLF may depend on packages in any Mandriva repository. The Updates repositories are not full sets of packages, they only contain packages that have been updated since release; you're intended to have both X and X Updates enabled.