Re: [gentoo-user] Kpdf crashes with large documents.
Philip Webb wrote: 081231 darren kirby wrote: On Wed, Dec 31, 2008 at 6:59 PM, Dale rdalek1...@gmail.com wrote: I recently stole a Motorola Razr phone which didn't come with manual. I downloaded it off the Motorola website and was attempting to read, when Kpdf crashed. It does this when I scroll down to about page 30 . http://www.phonedog.com/cell-phone-research/motorola-razr-v3i_user-manual.aspx it crashed my kpdf and my xpdf. Oddly, KGhostView renders it fine. Something fishy... Same here on a generally stable Gentoo on which Kpdf Xpdf are reliable. IIRC i've seen rare cases of this before, when KGV saved the day. The problem here happens with certain pages in the file, eg p 10 ; some later pages, eg pp 11-12 , are ok. There must be something in a few pages which is not correct PDF format. Has anyone searched Gentoo Forum/Bugs or KDE bugs ? Anyway, it's clearly a bug in Kpdf, which sb reported. Could it be a font that is missing or corrupt? It is strange that Kghostview works tho if it is a missing font. Could it be qt or some other lib that has a issue? I did search for kpdf crash on fgo but have not searched bgo. Should this be reported to KDE folks or Gentoo folks? Dale :-) :-)
Re: [gentoo-user] nvidia warning comes a tad late
Michael P. Soulier wrote: So, like a good gentoo user I'm emerging some updates available for my system. To my surprise when I happen to look at the screen (as it's taking some time to build and I'm obviously not watching the entire time), I see this: * * WARNING * * * You are currently installing a version of nvidia-drivers that is * known not to work with a video card you have installed on your * system. If this is intentional, please ignore this. If it is not * please perform the following steps: * * Add the following mask entry to /etc/portage/package.mask by * echo =x11-drivers/nvidia-drivers-177.0.0 /etc/portage/package.mask * * Failure to perform the steps above could result in a non-working * X setup. * * For more information please read: * http://www.nvidia.com/object/IO_32667.html * You must be in the video group to use the NVIDIA device * For more info, read the docs at * http://www.gentoo.org/doc/en/nvidia-guide.xml#doc_chap3_sect6 * * This ebuild installs a kernel module and X driver. Both must * match explicitly in their version. This means, if you restart * X, you most modprobe -r nvidia before starting it back up * * To use the NVIDIA GLX, run eselect opengl set nvidia * * nVidia has requested that any bug reports submitted have the * output of /usr/bin/nvidia-bug-report.sh included. * * To work with compiz, you must enable the AddARGBGLXVisuals option. * * If you are having resolution problems, try disabling DynamicTwinView. Sure enough, X no longer works. I'm following the instructions now, but... Don't you think the default action here should be to do nothing instead of breaking my system? Not impressed. Hopefully this critical message would be summarized at the end of the build too. Kind of important. I got lucky and happened to see it... Thanks, Mike I just did a reinstall on my rig and it did the exact same thing. I had to mask the one it installed and re-emerge the older one that does work. Isn't there some way for it to pick the right one? After all, it new it was the WRONG one it was installing. Looks to me like it could pick the right one. Dale :-) :-)
[gentoo-user] Re: nvidia warning comes a tad late
In 200901010423.25783.volker.armin.hemm...@tu-clausthal.de, Volker Armin Hemmann volker.armin.hemm...@tu-clausthal.de wrote: That is why you have to go to nvnews first and then upgrade. Where is nvnews? I've been going to http://www.nvidia.com/object/unix.html, selecting the driver I'm thinking of upgrading to, and checking its compatibility list. -- »Q« Kleeneness is next to Gödelness.
Re: [gentoo-user] Kpdf crashes with large documents.
090101 Dale wrote: Could it be a font that is missing or corrupt? It is strange that Kghostview works tho if it is a missing font. I don't have problems with fonts otherwise. The version of p 10 shown by KGV doesn't seem to have anything unusual, but perhaps one of the little graphics is causing a problem. Could it be qt or some other lib that has a issue? Not given that Kghostview renders it. I did search for kpdf crash on fgo but have not searched bgo. Should this be reported to KDE folks or Gentoo folks? One of us shd report it to the KDE bugzilla, but also their database sb searched first. One further idea is to see what happens if you try to open it with Open Office 3 , which claims to input PDF. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] [OT] High-pitched sound from inside the PC when opening menus
On Wednesday 31 December 2008 17:36:39 Paul Hartman wrote: I can't remember the exact reasoning, but I do recall being told it's normal and that it varies from one system to another, even with the same hardware. I think it's related to capacitors or voltage regulator or something like that. (I am not an electrical engineer) If it's consistent with high load, it's most likely inductors windowing vibrating inside their casing. i.e. loosely wound transformers. The biggest one is in the power supply, which is easy enough to swap out and check. The irritating part is that it's extremely hard to detect where the sound comes from - you can't just turn your head to get the direction as human ears aren't too good at those frequencies When trying KDE4 with all the desktop effects, it was really annoying, everything I did would cause the hissing noise, presumably because it's using more CPU load to do basic things. So, in other words, it's normal. :) Harmless, yes. Annoying, yes. Normal, should not be :-) This happens when vendors use cut-rate components, or the Chinese factory they outsourced the production to uses crappy parts. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Kpdf crashes with large documents.
Philip Webb wrote: 090101 Dale wrote: Could it be a font that is missing or corrupt? It is strange that Kghostview works tho if it is a missing font. I don't have problems with fonts otherwise. The version of p 10 shown by KGV doesn't seem to have anything unusual, but perhaps one of the little graphics is causing a problem. Could it be qt or some other lib that has a issue? Not given that Kghostview renders it. I did search for kpdf crash on fgo but have not searched bgo. Should this be reported to KDE folks or Gentoo folks? One of us shd report it to the KDE bugzilla, but also their database sb searched first. One further idea is to see what happens if you try to open it with Open Office 3 , which claims to input PDF. I have OOo3 here and it said it was a 13,000 page document and it was full of garbage at that. That didn't work or I did something wrong one. May be the later tho. Dale :-) :-)
Re: [gentoo-user] Blocking object does not exist...
On Thursday 01 January 2009 10:10:08 meino.cra...@gmx.de wrote: Hi, HAPPY NEW YEAR ! :O) I have got a problem while updateing my Gentoo-Linux-box: Witzh this command: emerge Net-Daemon PlRPC DBI rxvt-unicode gstreamer e2fsprogs-libs nano e2fsprogs zynaddsubfx sox boost autounmask cmake smplayer kdelibs wxGTK firehol xulrunner xorg-server vlc I got (beside a list of updateable/new package) the following warning: [blocks B ] x11-libs/qt-core (x11-libs/qt-core is blocking x11-libs/qt-4.3.3) [blocks B ] =x11-libs/qt-4.4.0_alpha:4 (=x11-libs/qt-4.4.0_alpha:4 is blocking x11-libs/qt-script-4.4.2, x11-libs/qt-dbus-4.4.2, x11-libs/qt-qt3support-4.4.2, x11-libs/qt-sql-4.4.2, x11-libs/qt-gui-4.4.2, x11-libs/qt-svg-4.4.2, x11-libs/qt-test-4.4.2, x11-libs/qt-core-4.4.2, x11-libs/qt-opengl-4.4.2) Due to that I decided to do a emerge -C qt-core which was answered with: --- Couldn't find 'qt-core' to unmerge. How cabn I solve the problem to get blocking packages, which do not exist? Long long ago when I used to fix electronic bits, the best advice I ever ound for my techies was OYFEAL: Open your fscking eyes and look. Some of that would help you a lot right now :-) When emerge runs, it builds a tree in memory of what it intends to do, that's where the blockers come from. So it doesn't have to be what you already have, it's portage telling you it can't follow your instructions. Look carefully at the first block. It clearly says that qt-core (no version) cannot be merged because of a block with qt-4.3.3. The second block says that all versions of qt less than or equal to 4.4.0_alpha block a bunch of 4.4.2 qt stuff. What happened here is that qt was split into several small package instead of one huge one. The new is therefore not compatible with the old and cannot co-exist, so you must unmerge the old version to be able to put the new ones on the system. You want: unmerge -avC qt emerge -av qt IIRC, there is a new qt meta package that will install core and others in step 2. If not, just emerge qt-core manually. emerge's block output is worded confusingly, the exact selection of words can lead you to believe that you have to do B in order to do A, when actually it's the other way round. this is because the devs block B in A's ebuild and also block A in B's ebuild, so that no stupid circumstances can arise. Best way to wrap your head around it is to open each ebuild, read it and compare it to the console output. Sooner or later a lightbulb will go on in your head, at least that's how it worked for me and most others I've helped over the years. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] pre-emerge steps
On Thursday 01 January 2009 02:29:15 Stroller wrote: On 31 Dec 2008, at 23:51, Michael P. Soulier wrote: Having just been bitten by some of my hardware being abandoned with the latest version of a software package I am left to question the entire philosophy in gentoo of always running bleeding edge. Not touching a system that's working is becoming far more tempting, and I'm curious as to what others here have to say about that. I think what you should be asking is why upstream have stopped supporting your hardware. Hopefully they'll be able to give a good reason for doing so. He also asked a very generic question, the kind that doesn't really have an answer. So no-one likely will. For all we know, the hardware in question is a floppy drive. Or token ring. Michael, what package, what hardware are we talking about? Your question can only be answered in context. IMO the Gentoo philosophy is not to run bleeding edge, but just to install from upstream, keeping it as pure and unchanged as possible. Gentoo is also somewhat general-purpose. There comes a point where obscure hardware is no longer worth the effort of supporting, or no-one is willing to do it, so that hardware has to be dropped. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] nvidia warning comes a tad late
On Thursday 01 January 2009 02:25:10 Stroller wrote: On 31 Dec 2008, at 23:33, Michael P. Soulier wrote: ... Don't you think the default action here should be to do nothing instead of breaking my system? That proposal is ludicrous and completely counter to the Unix way of doing things. Not my opinion, just quoting. nice one :-) The Unix way is to do what the user told it to do, no more and no less. If you tell the system to install a driver, ignore the prompt or even type y, why are users constantly surprised when the system does exactly what they told it to do? What's the computer supposed to say? Um, no my china, look here: I don't think that's a smart move. I don't care what you asked, I'm just not going to do it. Eat dust, sucker That's how Windows works. On Unix, if you break it you get to keep both pieces. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Kpdf crashes with large documents.
On Wed, 31 Dec 2008 16:18:55 -0600, Dale wrote: It is pretty big so I'll post a link. http://www.phonedog.com/cell-phone-research/motorola-razr-v3i_user-manual.aspx Worked OK here with kpdf-3.5.10, but I didn't try every page. an you confirm which page causes the crash? This may also be a bas download. In my searches on google, someone mentioned a bad/missing font could cause that but I got a lot of fonts installed on here. Why are you downloading from a site like this when the first result from a Google search for motorola razr v3i user manual is to a PDF on motorola.com? -- Neil Bothwick On a clear disk, you can seek forever. signature.asc Description: PGP signature
Re: [gentoo-user] Blocking object does not exist...
Alan McKinnon wrote: emerge's block output is worded confusingly, the exact selection of words can lead you to believe that you have to do B in order to do A, when actually it's the other way round. this is because the devs block B in A's ebuild and also block A in B's ebuild, so that no stupid circumstances can arise. Best way to wrap your head around it is to open each ebuild, read it and compare it to the console output. Sooner or later a lightbulb will go on in your head, at least that's how it worked for me and most others I've helped over the years. Amen to the confusing part. It almost always stumps me. I'm glad the unstable portage sort of deals with this itself, so far at least. Dale :-) :-)
Re: [gentoo-user] nvidia warning comes a tad late
On Thursday 01 January 2009 11:02:23 Dale wrote: I just did a reinstall on my rig and it did the exact same thing. I had to mask the one it installed and re-emerge the older one that does work. Isn't there some way for it to pick the right one? After all, it new it was the WRONG one it was installing. Looks to me like it could pick the right one. The software does not have the slightest vaguest foggiest concept of what the RIGHT and the WRONG drivers are. That's a human being's conclusion. It therefore cannot decide. The devs therefore correctly decided to not even try and decide. Unix-like systems demand that the user actually has a clue, is more than a mere automatonic moron, can and does read information and can and does really make decisions. And is prepared to live with the results. Some Unix people try to get all politically correct and hide this fundamental fact, but that is just plain wrong. It will never work any other way than how it is working right now. Users that are not prepared to actually think about what they are doing should switch back to Windows. That system specializes in treating their customers like complete idiots. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] nvidia warning comes a tad late
On Thu, 1 Jan 2009 12:27:48 +0200, Alan McKinnon wrote: Don't you think the default action here should be to do nothing instead of breaking my system? That proposal is ludicrous and completely counter to the Unix way of doing things. Not my opinion, just quoting. nice one :-) The Unix way is to do what the user told it to do, no more and no less. If you tell the system to install a driver, ignore the prompt or even type y, why are users constantly surprised when the system does exactly what they told it to do? What's the computer supposed to say? Except in this case, portage knew the action was risky but issued the warning after the event you really shouldn't have done that, like a typical smartarse with20:20 hindsight. There are numerous examples of ebuilds that stop if an upgrade is risky, postfix is one such, and provide the user with the an option to carry on if they choose, usually be setting an environment variable. I really don't see the point in an ebuild making this sort of test and then continuing to install anyway. -- Neil Bothwick I couldn't repair your brakes, so I made your horn louder. signature.asc Description: PGP signature
Re: [gentoo-user] Blocking object does not exist...
On Thu, 1 Jan 2009 12:18:39 +0200, Alan McKinnon wrote: What happened here is that qt was split into several small package instead of one huge one. The new is therefore not compatible with the old and cannot co-exist, so you must unmerge the old version to be able to put the new ones on the system. You want: unmerge -avC qt emerge -av qt The second command should be unnecessary, just carry on with the emerge world or whatever, and postage will pull in the required packages. -- Neil Bothwick If everything is coming your way then you're in the wrong lane. signature.asc Description: PGP signature
Re: [gentoo-user] Blocking object does not exist...
On Thu, 1 Jan 2009 09:10:08 +0100, meino.cra...@gmx.de wrote: emerge Net-Daemon PlRPC DBI rxvt-unicode gstreamer e2fsprogs-libs nano e2fsprogs zynaddsubfx sox boost autounmask cmake smplayer kdelibs wxGTK firehol xulrunner xorg-server vlc Running this without --oneshot will break your world file -- Neil Bothwick My brain's in gear, neutral's a gear ain't it? signature.asc Description: PGP signature
Re: [gentoo-user] Kpdf crashes with large documents.
090101 Neil Bothwick wrote: On Wed, 31 Dec 2008 16:18:55 -0600, Dale wrote: It is pretty big so I'll post a link. http://www.phonedog.com/cell-phone-research/motorola-razr-v3i_user-manual.aspx Worked OK here with kpdf-3.5.10, but I didn't try every page. Can you confirm which page causes the crash? See the rest of the thread ! -- try page 10 ... Why are you downloading from a site like this when the first result from a Google search for motorola razr v3i user manual is to a PDF on motorola.com? That seems to render ok upto c page 32 . However, it doesn't alter the fact that there is a bug in Kpdf, which should never crash whatever file it's given: at least, there sb an appropriate error message with 'ok' to close cleanly. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Kpdf crashes with large documents.
090101 Dale wrote: Philip Webb wrote: One further idea is to see what happens if you try to open it with Open Office 3 , which claims to input PDF. I have OOo3 here and it said it was a 13,000 page document and it was full of garbage at that. That didn't work or I did something wrong one. May be the later tho. You need to install the (beta) add-on, which should open it in Impress. However, when I try that -- even with a much shorter PDF file -- it just goes on on on using CPU till I kill OO. Has anyone managed to get PDF import to work with OO 3 on Gentoo ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Kpdf crashes with large documents.
Neil Bothwick wrote: On Wed, 31 Dec 2008 16:18:55 -0600, Dale wrote: It is pretty big so I'll post a link. http://www.phonedog.com/cell-phone-research/motorola-razr-v3i_user-manual.aspx Worked OK here with kpdf-3.5.10, but I didn't try every page. an you confirm which page causes the crash? If you have the thumbnails on the left, just scroll down a good ways. It crashes every time here. It doesn't even start to render the page before it dies and I don't even have to select a page either. Does give me that cryptic error message tho. So nice of it to do that. :/ This may also be a bas download. In my searches on google, someone mentioned a bad/missing font could cause that but I got a lot of fonts installed on here. Why are you downloading from a site like this when the first result from a Google search for motorola razr v3i user manual is to a PDF on motorola.com? Well, that one was the first one for me. Your Google may vary. LOL Dale :-) :-)
Re: [gentoo-user] Kpdf crashes with large documents.
Philip Webb wrote: 090101 Dale wrote: Philip Webb wrote: One further idea is to see what happens if you try to open it with Open Office 3 , which claims to input PDF. I have OOo3 here and it said it was a 13,000 page document and it was full of garbage at that. That didn't work or I did something wrong one. May be the later tho. You need to install the (beta) add-on, which should open it in Impress. However, when I try that -- even with a much shorter PDF file -- it just goes on on on using CPU till I kill OO. Has anyone managed to get PDF import to work with OO 3 on Gentoo ? Well, my CPU went to 100% for a bit to but it did eventually come up. I don't mind my CPU going to 100% since I run folding anyway. I wouldn't let it run forever but a few minutes doesn't bother me. Dale :-) :-)
Re: [gentoo-user] nvidia warning comes a tad late
090101 Neil Bothwick wrote: On Thu, 1 Jan 2009 12:27:48 +0200, Alan McKinnon wrote: Don't you think the default action here should be to do nothing instead of breaking my system? If you tell the system to install a driver, ignore the prompt or even type y, why are users constantly surprised when the system does exactly what they told it to do? Except in this case, portage knew the action was risky but issued the warning after the event you really shouldn't have done that, like a typical smartarse. There are numerous examples of ebuilds that stop if an upgrade is risky, postfix is one such, and provide the user with the an option to carry on if they choose, usually be setting an environment variable. I really don't see the point in an ebuild making this sort of test and then continuing to install anyway. I agree. I ran into this on my back-up box which has an older card, but as I never do 'emerge world' without '-pv', I saw it in time aborted via '^c'. I've now made a prominent note in my pkg list for that machine not to try to upgrade the Nvidia driver. Portage knows that what is proposed is going to break the user's system, so it should refuse to do it. It's like Package A blocks package B, which causes the emerge to stop till the user acts more sensibly. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] nvidia warning comes a tad late
Alan McKinnon wrote: On Thursday 01 January 2009 11:02:23 Dale wrote: I just did a reinstall on my rig and it did the exact same thing. I had to mask the one it installed and re-emerge the older one that does work. Isn't there some way for it to pick the right one? After all, it new it was the WRONG one it was installing. Looks to me like it could pick the right one. The software does not have the slightest vaguest foggiest concept of what the RIGHT and the WRONG drivers are. That's a human being's conclusion. It therefore cannot decide. The devs therefore correctly decided to not even try and decide. Unix-like systems demand that the user actually has a clue, is more than a mere automatonic moron, can and does read information and can and does really make decisions. And is prepared to live with the results. Some Unix people try to get all politically correct and hide this fundamental fact, but that is just plain wrong. It will never work any other way than how it is working right now. Users that are not prepared to actually think about what they are doing should switch back to Windows. That system specializes in treating their customers like complete idiots. Not disputing what you say but if it doesn't know what card we are using, why does it warn us that it is not compatible? Exact same thing happened to me a couple weeks ago and it has not happened before that, that I can recall anyway. Dale :-) :-)
Re: [gentoo-user] Kpdf crashes with large documents.
On Thu, 1 Jan 2009 05:41:11 -0500, Philip Webb wrote: Worked OK here with kpdf-3.5.10, but I didn't try every page. Can you confirm which page causes the crash? See the rest of the thread ! -- try page 10 ... I think I did, I've scrolled as far as page 52 now with no problems. Why are you downloading from a site like this when the first result from a Google search for motorola razr v3i user manual is to a PDF on motorola.com? That seems to render ok upto c page 32 . Got to page 50 on this one too, still no problems. Could it be version or USE flag dependent? % emerge -pv kpdf These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] kde-base/kpdf-3.5.10 USE=-debug 0 kB OK, that rules out USE flags, but it may be worth trying it with debug enabled. However, it doesn't alter the fact that there is a bug in Kpdf, which should never crash whatever file it's given: at least, there sb an appropriate error message with 'ok' to close cleanly. Agreed. -- Neil Bothwick Any program which runs right is obsolete. signature.asc Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On Thu, 1 Jan 2009 05:54:33 -0500, Philip Webb wrote: Portage knows that what is proposed is going to break the user's system, so it should refuse to do it. It's like Package A blocks package B, which causes the emerge to stop till the user acts more sensibly. This is different in that the problem is not detected until the emerge starts, but portage could skip this package and carry on with the rest, issuing an elog message explaining what happened and how to force an install if that's what you really want. -- Neil Bothwick I cna ytpe 300 wrods pre mniuet!!! signature.asc Description: PGP signature
Re: [gentoo-user] Blocking object does not exist...
Hi Neil - could you explain why? - from man emerge: --oneshot (-1) Emerge as normal, but do not add the packages to the world file for later updating. This would imply that if you use oneshot, the system wont know about the package and wont update it - not what you would normally want with any package except under special circumstances. In fact, unless you have a package you dont want updated, *EVERY* package on the system *SHOULD* be in world? BillK On Thu, 2009-01-01 at 10:40 +, Neil Bothwick wrote: On Thu, 1 Jan 2009 09:10:08 +0100, meino.cra...@gmx.de wrote: emerge Net-Daemon PlRPC DBI rxvt-unicode gstreamer e2fsprogs-libs nano e2fsprogs zynaddsubfx sox boost autounmask cmake smplayer kdelibs wxGTK firehol xulrunner xorg-server vlc Running this without --oneshot will break your world file -- William Kenworthy bi...@iinet.net.au Home in Perth!
Re: [gentoo-user] Blocking object does not exist...
Am Donnerstag, 1. Januar 2009 12:19:44 schrieb William Kenworthy: Hi Neil - could you explain why? Because only packages which are not a dependency for any other package should be in world. If you install that many packages in one go emerge will put all of them into world, regardless of their dependencies with each other. - from man emerge: --oneshot (-1) Emerge as normal, but do not add the packages to the world file for later updating. This would imply that if you use oneshot, the system wont know about the package and wont update it Nope. It wont take them into account for _normal_ update. There's also --deep. - not what you would normally want with any package except under special circumstances. In fact, unless you have a package you dont want updated, EVERY package on the system SHOULD be in world? Nope, see above. If you have packages you don't want updated, mask the higher versions. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Blocking object does not exist...
On Thu, 01 Jan 2009 20:19:44 +0900, William Kenworthy wrote: Hi Neil - could you explain why? - from man emerge: --oneshot (-1) Emerge as normal, but do not add the packages to the world file for later updating. This would imply that if you use oneshot, the system wont know about the package and wont update it - not what you would normally want with any package except under special circumstances. In fact, unless you have a package you dont want updated, *EVERY* package on the system *SHOULD* be in world? World should contain only those packages you explicitly want, not their dependencies. emerge world takes care of dependencies at varying levels depending on whether you use --deep, --update or neither, but you do not want them in world. Otherwise, when you unstall packages, you end u with lots of cruft that emerge --depclean will not identify. -- Neil Bothwick When companies ship Styrofoam, what do they pack it in? signature.asc Description: PGP signature
Re: [gentoo-user] Kpdf crashes with large documents.
[Please CC me on all replies] On Wednesday 31 December 2008, Dale wrote: Hi, I recently stole me a Motorola Razr phone and it didn't come with the manual. I downloaded it off the Motorola website and was reading, or attempting to read, it when Kpdf crashed. It does this when I scroll down to about page 30 or so. It's a pretty large document since it has both English and Spanish. For me, this pdf crashed evince in cffparse.c:361, which is indicative of a bug in freetype (bug 247104) for which I just committed a fix. Please add to your package.keywords and test. +*freetype-2.3.7-r1 (01 Jan 2009) + + 01 Jan 2009; Peter Alfredsen loki_...@gentoo.org + +files/freetype-2.3.7-b.g.o-247104.patch, + +files/freetype-2.3.7-b.g.o-253029.patch, + +files/freetype-2.3.7-fix-incorrect-scaling.patch, + +files/freetype-2.3.7-no-segfault-on-load_mac_face.patch, + +freetype-2.3.7-r1.ebuild: + Fix bug 247104, segfault in cffparse.c:361, bug 253029, missing letters in + certain fonts, thanks to Andreas Turriff for the patch-pointer. Also + import patches for alien bugs: http://bugs.debian.org/487101, segfault + when building certain fonts and + http://savannah.nongnu.org/bugs/index.php?23973 , incorrect scaling of + certain fonts. + -- /PA signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] nvidia warning comes a tad late
Volker Armin Hemmann ha scritto: On Donnerstag 01 Januar 2009, Michael P. Soulier wrote: On 01/01/09 Volker Armin Hemmann said: after the emerge you read the messages with elogv and downgrade. No harm done. I'll be sure to try that, thank you. However, would not avoiding a bad upgrade in the first place be a better-behaved tool? Especially when the package in question knew that it was likely incompatible? I'm not saying that this could not be avoided with more work, I'm saying that I shouldn't have to if the tools were better behaved. Cheers, Mike how should 'the tool' know what card you are using? The tool knew -in fact it told him of the breakage , *after* doing it. and even if portage could parse lspci output - why make it slower and more easily to break if all breakage can be avoided by simply reading first - then upgrading? If you don't know there's something to read... Do you always install the latest drivers without reading up on them first? Usually, yes. Could be my fault, but am I expected to read technical docs everytime I update a package? Anyway, the system *knows* that there's a problem, so your point is moot. The only thing we're asking is to warn and stop *before* and not *after*. Nvidia's 'deprecation' strategy is a pain in the ass and they are doing it for a long time now. So this time it bit you. Next time it will be 6XXX card users, then 7XXX card users and so on. That is why you have to go to nvnews first and then upgrade. Not the other way round. Thanks for advice. m.
Re: [gentoo-user] Kpdf crashes with large documents.
090101 Peter Alfredsen wrote: [Please CC me on all replies] For me, this pdf crashed evince in cffparse.c:361, which is indicative of a bug in freetype (bug 247104) for which I just committed a fix. Please add to your package.keywords and test. +*freetype-2.3.7-r1 (01 Jan 2009) + + 01 Jan 2009; Peter Alfredsen loki_...@gentoo.org + +files/freetype-2.3.7-b.g.o-247104.patch, + +files/freetype-2.3.7-b.g.o-253029.patch, + +files/freetype-2.3.7-fix-incorrect-scaling.patch, + +files/freetype-2.3.7-no-segfault-on-load_mac_face.patch, + +freetype-2.3.7-r1.ebuild: + Fix bug 247104, segfault in cffparse.c:361, bug 253029, missing letters in + certain fonts, thanks to Andreas Turriff for the patch-pointer. Also + import patches for alien bugs: http://bugs.debian.org/487101, segfault + when building certain fonts and + http://savannah.nongnu.org/bugs/index.php?23973 , incorrect scaling of + certain fonts. + You beat me to it ! -- I've just submitted KDE bug 179280 . -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] Re: [OT] test, if module was loaded with module option?
Hi, Christian Franke schrieb: On 12/29/2008 02:32 PM, Marc Blumentritt wrote: is there a general way to test, if a kernel module was loaded with a module option and which module options were used? There is at least /sys/module/modulname/parameters/parametername If there is nothing else, one could at least compare each parameter to its default value or something like that. Attention, not everything in /sys/module _is_ a module, seems more like everything that is or _could_ be a module is there. Thanks for the info, but at my system there is no parameters folder for the module I want to check. To be specific, I use lirc (which is still outside of the kernel) and load the required modules during boot up. I use baselayout-2 and set the option inside /etc/conf.d/modules: module_lirc_imon_args=pad2keys_active=1 Now I want to see, if this option is really set, because my remote is not working good (have to press a button a few times before something happens). I have to load 2 modules for lirc: lirc_dev (general module) and lirc_imon (my remote). For lirc_dev, there is a parameters dir, but not for lirc_imon. I think I have to ask the lirc maintainer for help. Thanks anyway. Marc
Re: [gentoo-user] nvidia warning comes a tad late
I am total Gentoo newb :D but it seems kind of fundamental to the concept of this distribution that its users are going to make themselves aware of the details of system updates. Short of reading ridiculous amounts of doco...folks should be reading the output of the emerge commands to learn about edge cases like this one. In the short few days I've been using Gentoo, there have been several occasions where had I not read that output, my system would have been 'broken' on next reboot. At the very least there were additional steps needed for me to install that package I tried to emerge (missing USE flags, requests to rebuild other packages, external data downloads, etc.). Personally, I rather like this approach. The folks maintaining the builds take the time to identify these edge cases, which makes the portage text output quite helpful. -- Matt On Thu, Jan 1, 2009 at 1:09 PM, b.n. brullonu...@gmail.com wrote: Volker Armin Hemmann ha scritto: On Donnerstag 01 Januar 2009, Michael P. Soulier wrote: On 01/01/09 Volker Armin Hemmann said: after the emerge you read the messages with elogv and downgrade. No harm done. I'll be sure to try that, thank you. However, would not avoiding a bad upgrade in the first place be a better-behaved tool? Especially when the package in question knew that it was likely incompatible? I'm not saying that this could not be avoided with more work, I'm saying that I shouldn't have to if the tools were better behaved. Cheers, Mike how should 'the tool' know what card you are using? The tool knew -in fact it told him of the breakage , *after* doing it. and even if portage could parse lspci output - why make it slower and more easily to break if all breakage can be avoided by simply reading first - then upgrading? If you don't know there's something to read... Do you always install the latest drivers without reading up on them first? Usually, yes. Could be my fault, but am I expected to read technical docs everytime I update a package? Anyway, the system *knows* that there's a problem, so your point is moot. The only thing we're asking is to warn and stop *before* and not *after*. Nvidia's 'deprecation' strategy is a pain in the ass and they are doing it for a long time now. So this time it bit you. Next time it will be 6XXX card users, then 7XXX card users and so on. That is why you have to go to nvnews first and then upgrade. Not the other way round. Thanks for advice. m.
[gentoo-user] dispatch-conf problem
Hi. I just now started to use dispatch-conf, but I have a question and there seems to be a problem. I have replace-unmodified=yes, however this seems to be ignored -- at least it gave me all the config files it could find even though I had not modified some of them. Also, if I want to roll back, say, /etc/init.d/fsck, I am not sure which file to choose -- in the archive directory there is an /etc/init.d directory which contains fsck and fsck.dist. I would imagine that fsck is my old one and fsck.dist is the new one -- now what happens if this file is updated again? Thanks in advance for any help. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: dispatch-conf problem
Am Donnerstag, 1. Januar 2009 16:57:46 schrieb Nikos Chantziaras: You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. However, if you want that, you should switch to cfg-update. Bye... Dirk signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: dispatch-conf problem
on Thursday 01/01/2009 Nikos Chantziaras(rea...@arcor.de) wrote John covici wrote: Also, if I want to roll back, say, /etc/init.d/fsck, I am not sure which file to choose -- in the archive directory there is an /etc/init.d directory which contains fsck and fsck.dist. I would imagine that fsck is my old one and fsck.dist is the new one -- now what happens if this file is updated again? No, that is not how it works. New files have the prefix ._ (as is also reported by dispatch-conf.) .dist is usually a file that is bundled with the upstream tarball. It usually serves as an example. You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. Then what is the purpose of the config-archive directory which I was asked to create? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Re: dispatch-conf problem
Nikos Chantziaras rea...@arcor.de writes: You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. You can if you have use-rcs=yes in /etc/dispatch-conf.conf, which the OP is probably using as the post mentions the archive directory.
[gentoo-user] Re: dispatch-conf problem
John covici wrote: Also, if I want to roll back, say, /etc/init.d/fsck, I am not sure which file to choose -- in the archive directory there is an /etc/init.d directory which contains fsck and fsck.dist. I would imagine that fsck is my old one and fsck.dist is the new one -- now what happens if this file is updated again? No, that is not how it works. New files have the prefix ._ (as is also reported by dispatch-conf.) .dist is usually a file that is bundled with the upstream tarball. It usually serves as an example. You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first.
[gentoo-user] Re: nvidia warning comes a tad late
On 2009-01-01, Matt Causey matt.cau...@gmail.com wrote: I am total Gentoo newb :D but it seems kind of fundamental to the concept of this distribution that its users are going to make themselves aware of the details of system updates. Short of reading ridiculous amounts of doco...folks should be reading the output of the emerge commands to learn about edge cases like this one. There are plenty of ebuilds that when they know they are going to break the system will abort with a warning to the user how to either prevent the breakage or how to force the install. I don't see any reason why the nvidia ebuild should go ahead and break the system and then tell you about it afterwards. Why not tell you about how the update will break your system and then _not_ doing the update? Personally, I rather like this approach. The folks maintaining the builds take the time to identify these edge cases, which makes the portage text output quite helpful. It would be even more helpful if the ebuild _doesn't_ break your system. -- Grant
[gentoo-user] Re: dispatch-conf problem
John covici wrote: on Thursday 01/01/2009 Nikos Chantziaras(rea...@arcor.de) wrote You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. Then what is the purpose of the config-archive directory which I was asked to create? Oh, sorry. I never knew about it :P
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Alan McKinnon said: The software does not have the slightest vaguest foggiest concept of what the RIGHT and the WRONG drivers are. That's a human being's conclusion. Apparently it did, hence the warning. It therefore cannot decide. It did decide. It decided to continue. The devs therefore correctly decided to not even try and decide. Unix-like systems demand that the user actually has a clue, is more than a mere automatonic moron, can and does read information and can and does really make decisions. And is prepared to live with the results. Orthogonal to the discussion. You are blaming users for laziness in the system that could have made it easier to notice a potential problem. Some Unix people try to get all politically correct and hide this fundamental fact, but that is just plain wrong. It will never work any other way than how it is working right now. Justification by tradition won't help anyone here. I see nothing in this post but inflammatory, flawed logic. Users that are not prepared to actually think about what they are doing should switch back to Windows. That system specializes in treating their customers like complete idiots. Like this statement. I see many posts like this but few suggestions as to how the problem could have been avoided ahead of time. I saw one suggestion of how to roll the driver back after the fact, which I did, after it was already broken. Does anyone have any rational arguments to support the system not stopping due to the warning, or is this all I can expect? Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpSGtVJl4JDJ.pgp Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Alan McKinnon said: nice one :-) The Unix way is to do what the user told it to do, no more and no less. If you tell the system to install a driver, ignore the prompt or even Ignore what prompt? There was no prompt, a prompt requiring feedback is in fact, exactly what I am looking for. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpoiu6Zo2NmE.pgp Description: PGP signature
[gentoo-user] Re: nvidia warning comes a tad late
Michael P. Soulier wrote: [...] I see many posts like this but few suggestions as to how the problem could have been avoided ahead of time. You can open a bug about it and suggest something.
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Neil Bothwick said: This is different in that the problem is not detected until the emerge starts, but portage could skip this package and carry on with the rest, issuing an elog message explaining what happened and how to force an install if that's what you really want. Yes, that would have been helpful. The message in fact was very helpful in showing me how to fix the problem, and I am thankful that the effort was taken as Gentoo is still a little new to me (I come from Debian/RedHat land mostly). I'm not against the warning, as the subject of this thread states, it just came a little late. :) I like Gentoo, but I find it in the wrong in this particular case. Cheers, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpmR9mzhVXA3.pgp Description: PGP signature
Re: [gentoo-user] Re: nvidia warning comes a tad late
On 01/01/09 Nikos Chantziaras said: You can open a bug about it and suggest something. I did yesterday when it happened. Thanks, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgp5pj6BuQRwo.pgp Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
Am Donnerstag, 1. Januar 2009 00:33:27 schrieb Michael P. Soulier: Don't you think the default action here should be to do nothing instead of breaking my system? What we think here is irrelevant. You should file a bug and see what the devs think. We can then express what we think by voting for it. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] nvidia warning comes a tad late
On Thu, 1 Jan 2009 11:26:27 -0500, Michael P. Soulier wrote: Ignore what prompt? There was no prompt, a prompt requiring feedback is in fact, exactly what I am looking for. That would be wrong. Emerge is supposed to run non-interactively, apart from a prompt at the start of the process when using --ask. A world update can take many hours and is often run overnight, imagine your frustration the next morning when you see it is asking if you want to proceed on package 3/184. -- Neil Bothwick Pedestrians come in two types: Quick or Dead. signature.asc Description: PGP signature
Re: [gentoo-user] Re: dispatch-conf problem
on Thursday 01/01/2009 Graham Murray(gra...@gmurray.org.uk) wrote Nikos Chantziaras rea...@arcor.de writes: You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. You can if you have use-rcs=yes in /etc/dispatch-conf.conf, which the OP is probably using as the post mentions the archive directory. In fact, I have rcs=no, but the directory does have files in it, so if I know which file to copy back, I can restore things -- but my questions remain -- what is the file naming conventions for those files and what happens if I update the same file again? -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] nvidia warning comes a tad late
Neil Bothwick wrote: On Thu, 1 Jan 2009 11:26:27 -0500, Michael P. Soulier wrote: Ignore what prompt? There was no prompt, a prompt requiring feedback is in fact, exactly what I am looking for. That would be wrong. Emerge is supposed to run non-interactively, apart from a prompt at the start of the process when using --ask. A world update can take many hours and is often run overnight, imagine your frustration the next morning when you see it is asking if you want to proceed on package 3/184. Only thing worse is a system that completed the emerge but don't work. I have one word: Great! That is a bit sarcastic to. I can think of a couple other words but you may get the idea. The others are. . . dirty. Dale :-) :-)
Re: [gentoo-user] Re: nvidia warning comes a tad late
On Donnerstag 01 Januar 2009, »Q« wrote: In 200901010423.25783.volker.armin.hemm...@tu-clausthal.de, Volker Armin Hemmann volker.armin.hemm...@tu-clausthal.de wrote: That is why you have to go to nvnews first and then upgrade. Where is nvnews? http://www.nvnews.net/vbulletin/forumdisplay.php?s=forumid=14
Re: [gentoo-user] nvidia warning comes a tad late
On Donnerstag 01 Januar 2009, Neil Bothwick wrote: On Thu, 1 Jan 2009 12:27:48 +0200, Alan McKinnon wrote: Don't you think the default action here should be to do nothing instead of breaking my system? That proposal is ludicrous and completely counter to the Unix way of doing things. Not my opinion, just quoting. nice one :-) The Unix way is to do what the user told it to do, no more and no less. If you tell the system to install a driver, ignore the prompt or even type y, why are users constantly surprised when the system does exactly what they told it to do? What's the computer supposed to say? Except in this case, portage knew the action was risky but issued the warning after the event you really shouldn't have done that, like a typical smartarse with20:20 hindsight. There are numerous examples of ebuilds that stop if an upgrade is risky, postfix is one such, and provide the user with the an option to carry on if they choose, usually be setting an environment variable. I really don't see the point in an ebuild making this sort of test and then continuing to install anyway. but as long as X is not restarted, the upgrade doesn't break anything. You come back, you read the elogs, you downgrade the drivers and everything is fine and dandy.
Re: [gentoo-user] nvidia warning comes a tad late
On Donnerstag 01 Januar 2009, Michael P. Soulier wrote: On 01/01/09 Alan McKinnon said: The software does not have the slightest vaguest foggiest concept of what the RIGHT and the WRONG drivers are. That's a human being's conclusion. Apparently it did, hence the warning. the ebuild warned you. Portage and ebuilds are different things. And portage has to assume that you know what you are doing. It therefore cannot decide. It did decide. It decided to continue. because it SUCKS when a world update breaks somewhere along 25 of 223. People don't want portage to stop. The devs therefore correctly decided to not even try and decide. Unix-like systems demand that the user actually has a clue, is more than a mere automatonic moron, can and does read information and can and does really make decisions. And is prepared to live with the results. Orthogonal to the discussion. You are blaming users for laziness in the system that could have made it easier to notice a potential problem. the user is the only one to blame - if you restart X or your system before reading the elogs, it is your own fault if something breaks. A running service, like X, ssh, apache, isn't influenced by any update until you restart it. So a user who didn't read up before updating and then doesn't read after it too deserves what he get. Some Unix people try to get all politically correct and hide this fundamental fact, but that is just plain wrong. It will never work any other way than how it is working right now. Justification by tradition won't help anyone here. I see nothing in this post but inflammatory, flawed logic. no, he is right. Linux is not Windows. There are some people who want to turn linux into windows. These people should buy a mac. Users that are not prepared to actually think about what they are doing should switch back to Windows. That system specializes in treating their customers like complete idiots. Like this statement. I see many posts like this but few suggestions as to how the problem could have been avoided ahead of time. I saw one suggestion of how to roll the driver back after the fact, which I did, after it was already broken. Does anyone have any rational arguments to support the system not stopping due to the warning, or is this all I can expect? BECAUSE STOPPING IS EVIL! PORTAGE IS NON INTERACTIVE! People want to start an update then go away or sleep. I think Neil already told you that.
Re: [gentoo-user] nvidia warning comes a tad late
On Thu, 1 Jan 2009 18:42:23 +0100, Volker Armin Hemmann wrote: BECAUSE STOPPING IS EVIL! PORTAGE IS NON INTERACTIVE! People want to start an update then go away or sleep. I think Neil already told you that. Yes I did. But I also stated that I believe portage should skip the package when this situation occurs, unless you have explicitly told it to proceed with the potentially broken version. -- Neil Bothwick Why marry a virgin? If she wasn't good enough for the rest of them, then she isn't good enough for you. signature.asc Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On Thu, 1 Jan 2009 18:34:36 +0100, Volker Armin Hemmann wrote: but as long as X is not restarted, the upgrade doesn't break anything. You come back, you read the elogs, you downgrade the drivers and everything is fine and dandy. Except you've wasted time and resources compiling the broken version of the software and then recompiling the version you already had. If the ebuild, in fact it's the nvidia.eclass, can detect that proceeding will cause breakage, why proceed? Then there's the case where an update to another package now prevents the old one from compiling. It shouldn't happen, but it does, so why risk all those disadvantages when portage could use its --keep-going code to restart the emerge with the net package? -- Neil Bothwick God is real, unless specifically declared integer. signature.asc Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Volker Armin Hemmann said: the ebuild warned you. Portage and ebuilds are different things. And portage has to assume that you know what you are doing. Sure, the issue is that it warned me too late. because it SUCKS when a world update breaks somewhere along 25 of 223. People don't want portage to stop. Perhaps then all such checks should be done at the beginning of running portage, instead of at the beginning of the individual builds. Debian does this, running all pre-scripts before actually installing the packages. There are more than two options here. the user is the only one to blame - if you restart X or your system before reading the elogs, it is your own fault if something breaks. A running service, like X, ssh, apache, isn't influenced by any update until you restart it. No, untrue. Running services with loadable modules such as apache can easily be disasterously influenced by underlying changes while they are running. I've seen it many times. So a user who didn't read up before updating and then doesn't read after it too deserves what he get. I was upgrading on the order of 20 packages. Thank goodness I didn't deploy Gentoo in an enterprise environment and only broke the single machine. Your philosophy seems to put an undue amount of work on the administrator. Exactly how many websites should I be checking before I follow the simplistic instructions in the Gentoo handbook that tell me to just emerge --update world? I followed the instructions found here http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2chap=1#doc_chap3 no, he is right. Linux is not Windows. There are some people who want to turn linux into windows. These people should buy a mac. No argument here, although I don't see how we've gotten on this side-topic of how Linux is not Windows. I never once asked for that. BECAUSE STOPPING IS EVIL! PORTAGE IS NON INTERACTIVE! People want to start an update then go away or sleep. I think Neil already told you that. Which is why it's important to stop up front, not an hour into the process. Or don't stop at all, but skip the one ebuild. Cheers, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgp1PRvmMOze2.pgp Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Neil Bothwick said: That would be wrong. Emerge is supposed to run non-interactively, apart from a prompt at the start of the process when using --ask. A world update can take many hours and is often run overnight, imagine your frustration the next morning when you see it is asking if you want to proceed on package 3/184. Agreed. Skipping seems the easiest-to-implement option, as likely running all sanity checks beforehand would likely take an architectural change. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpHxDYbFR3T2.pgp Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
On 01/01/09 Volker Armin Hemmann said: but as long as X is not restarted, the upgrade doesn't break anything. You come back, you read the elogs, you downgrade the drivers and everything is fine and dandy. As long as X doesn't dynamically load a now binary-incompatible module and segfault. X does load modules on demand from time to time, does it not? Then of course there's the issue of power failures, my UPS only lasts for about five minutes and we've had some wicked winter storms lately. On another topic I'm assuming that this technique is inappropriate for managing large numbers of workstations or servers. I assume you'd patch one sacrificial box, and then use a completely different mechanism to push those changes out to your managed machines. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpkWrOcePJBP.pgp Description: PGP signature
Re: [gentoo-user] pre-emerge steps
On 01/01/09 Alan McKinnon said: He also asked a very generic question, the kind that doesn't really have an answer. So no-one likely will. For all we know, the hardware in question is a floppy drive. Or token ring. Michael, what package, what hardware are we talking about? Your question can only be answered in context. In this case an nvidia video card, that nvidia is dropping support for. But, I've been bitten in the past by kernel upgrades that suddenly don't work with my power management, or change apic support so suddenly my usb devices stop working, etc. I just wondering how many people check the delta on every package they're upgrading, and how many simply upgrade and hope it works. Gentoo is also somewhat general-purpose. There comes a point where obscure hardware is no longer worth the effort of supporting, or no-one is willing to do it, so that hardware has to be dropped. Understood. I think it might be best for me to block upgrades on packages that interface directly with my hardware unless there's a compelling reason to do so. Staying current isn't very compelling if what I have is working. At times the interdependencies get so complex that it's a wonder that anything on the system works at all. :) Cheers, Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpydcGHhn8Pb.pgp Description: PGP signature
Re: [gentoo-user] nvidia warning comes a tad late
Neil Bothwick wrote: On Thu, 1 Jan 2009 18:34:36 +0100, Volker Armin Hemmann wrote: but as long as X is not restarted, the upgrade doesn't break anything. You come back, you read the elogs, you downgrade the drivers and everything is fine and dandy. Except you've wasted time and resources compiling the broken version of the software and then recompiling the version you already had. If the ebuild, in fact it's the nvidia.eclass, can detect that proceeding will cause breakage, why proceed? Then there's the case where an update to another package now prevents the old one from compiling. It shouldn't happen, but it does, so why risk all those disadvantages when portage could use its --keep-going code to restart the emerge with the net package? I wonder if the same would be said about something like baselayout or some other system package that just can't be . . . screwed up? If a new udev would break my system and it knew it, then updated it anyway, it wouldn't be a inconvenience at that point. I would be pissed because I only have one system and no way to search for a fix either. I would be putting a new meaning to shooting in the dark. Dale :-) :-)
Re: [gentoo-user] pre-emerge steps
On Thursday 01 January 2009, Alan McKinnon wrote: On Thursday 01 January 2009 02:29:15 Stroller wrote: On 31 Dec 2008, at 23:51, Michael P. Soulier wrote: Having just been bitten by some of my hardware being abandoned with the latest version of a software package I am left to question the entire philosophy in gentoo of always running bleeding edge. Not touching a system that's working is becoming far more tempting, and I'm curious as to what others here have to say about that. I think what you should be asking is why upstream have stopped supporting your hardware. Hopefully they'll be able to give a good reason for doing so. He also asked a very generic question, the kind that doesn't really have an answer. So no-one likely will. For all we know, the hardware in question is a floppy drive. Or token ring. Michael, what package, what hardware are we talking about? Your question can only be answered in context. IMO the Gentoo philosophy is not to run bleeding edge, but just to install from upstream, keeping it as pure and unchanged as possible. Gentoo is also somewhat general-purpose. There comes a point where obscure hardware is no longer worth the effort of supporting, or no-one is willing to do it, so that hardware has to be dropped. Not sure if the OP has been bitten by the 2.6.27 kernel which does not seem aheam! compatible with my hardware too. Now, this could well be an one off - I can't recall having significant kernel problems with stable versions for years now. Or, it could be that it was half cooked and rushed to meet the Christmas hols. Time will show. I guess there is bugzilla for posting bugs or even requests, but if as Alan says the hardware in question is that obscure/obsolete, then interest for continuing its dev't will undoubtedly decline with time. Maybe the recent 2.6.27 kernel problems that I have experienced are an early warning that my PIII Coppermine is approaching the end of its useful life ... -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] nvidia warning comes a tad late
On Donnerstag 01 Januar 2009, Michael P. Soulier wrote: On 01/01/09 Volker Armin Hemmann said: but as long as X is not restarted, the upgrade doesn't break anything. You come back, you read the elogs, you downgrade the drivers and everything is fine and dandy. As long as X doesn't dynamically load a now binary-incompatible module and segfault. X does load modules on demand from time to time, does it not? nope. X loads everything on startup.
Re: [gentoo-user] Re: dispatch-conf problem
John covici wrote: on Thursday 01/01/2009 Graham Murray(gra...@gmurray.org.uk) wrote Nikos Chantziaras rea...@arcor.de writes: You cannot roll back if you choose to keep the new file with dispatch-conf and didn't backup the current one first. You can if you have use-rcs=yes in /etc/dispatch-conf.conf, which the OP is probably using as the post mentions the archive directory. In fact, I have rcs=no, but the directory does have files in it, so if I know which file to copy back, I can restore things -- but my questions remain -- what is the file naming conventions for those files and what happens if I update the same file again? If you have rcs=no, the files are, to my knowledge, the previous version of the configuration file and use exactly the same filename. In my experience dispatch-conf will _always_ ask about a file the first time it encounters it. Once it has asked you once, it then knows about the state of that file and can obey things like the unmodified rule when a new version of the file is considered. You can check the differences between 2 files using diff, eg: diff /etc/config-archive/etc/init.d/fsck /etc/init.d/fsck The format is: diff old-file new-file You may prefer the -u option: diff -u old new Or, in the package of the same name, colordiff: colordiff -u old new There are also graphical diff tools (eg. kompare) AllenJB
[gentoo-user] Re: nvidia warning comes a tad late
On Thu, 1 Jan 2009 13:28:55 -0500 Michael P. Soulier msoul...@digitaltorque.ca wrote: Your philosophy seems to put an undue amount of work on the administrator. I guess I'm in the camp that thinks the administrator should know what modules are needed for the hardware, and portage should keep working as it does now. ISTM the fundamental cause of the problem is with nVidia. Their different series of drivers support different hardware, but instead of distinguishing them by different package names, they only use version numbers. It looks like they now offer four different series, supporting four different hardware sets (with some overlap of the sets). IMO the best solution would be to regard the four series as four distinct software products and give them different names. So, e.g., if you had installed x11-drivers/nvidia-drivers173-173.14.14, emerge -u wouldn't install x11-drivers/nvidia-drivers177-177.82. And people like me, whose hardware would be supported by both packages, could just choose which one they wanted (without having to mask anything), which doesn't seem like too much of a burden. Or I guess slotting could work also, but probably create collision headaches for maintainers. -- »Q« Kleeneness is next to Gödelness.
Re: [gentoo-user] nvidia warning comes a tad late
Am Thursday 01 January 2009 17:54:12 schrieb Neil Bothwick: On Thu, 1 Jan 2009 11:26:27 -0500, Michael P. Soulier wrote: Ignore what prompt? There was no prompt, a prompt requiring feedback is in fact, exactly what I am looking for. That would be wrong. Emerge is supposed to run non-interactively, apart from a prompt at the start of the process when using --ask. A world update can take many hours and is often run overnight, imagine your frustration the next morning when you see it is asking if you want to proceed on package 3/184. Well, these days ebuilds can be marked as interactive, showing a yellow I in emerge -pv. That's what for example doom3-demo does with it's license, so if people run an emerge -uDN world over night, ignoring those flags, it's their fault. I too would like to see as few interactive ebuilds as possible. - Sascha signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: nvidia warning comes a tad late
On Thu, 1 Jan 2009 14:14:16 -0600, »Q« wrote: I guess I'm in the camp that thinks the administrator should know what modules are needed for the hardware, and portage should keep working as it does now. Then why the test and warning? -- Neil Bothwick God is real, unless specifically declared integer. signature.asc Description: PGP signature
Re: [gentoo-user] pre-emerge steps
On 01/01/09 Mick said: I guess there is bugzilla for posting bugs or even requests, but if as Alan says the hardware in question is that obscure/obsolete, then interest for continuing its dev't will undoubtedly decline with time. Maybe the recent 2.6.27 kernel problems that I have experienced are an early warning that my PIII Coppermine is approaching the end of its useful life ... I just stopped using a P-III myself. I was running 2.6.9 under CentOS-4 for ages. Mike -- Michael P. Soulier msoul...@digitaltorque.ca Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. --Albert Einstein pgpukjnS75udN.pgp Description: PGP signature
Re: [gentoo-user] pre-emerge steps
On Wed, Dec 31, 2008 at 3:51 PM, Michael P. Soulier msoul...@digitaltorque.ca wrote: Having just been bitten by some of my hardware being abandoned with the latest version of a software package I am left to question the entire philosophy in gentoo of always running bleeding edge. Not touching a system that's working is becoming far more tempting, and I'm curious as to what others here have to say about that. Part of the point of running Linux for me is to save money and run older hardware, but that doesn't work if the latest versions of the software that I like to use abandons that hardware. What do the rest of you do in preparation for regular upgrades? On BSD there was a /usr/ports/UPDATING file that I should check for notes on potential problems with upgrades before performing them. What's the best way to check if picking up a newer package could break my system? Ideally a way that isn't prohibitively time-consuming... Thanks, Mike Hey Mike, Logically I'm not sure there is ANY way to know for certain that an update will break your system. Better to plan on what you will do if you have to fall back. I've lived through a bit of this myself. I have two older Asus Pundit-R machines. They have built in video cards which have VGA and S-video outputs. The machines serve as MythTV frontend boxes and I use the S-video to drive a couple of TVs. Problem is that a couple of years ago the ATI proprietary driver dropped support for the S-video and none of the newer drivers work for me so in my case I had to set up overlays to keep copies of the drivers and change my masking files to prohibit updating of the driver. This has worked but I do wonder if one day the older ATI driver will stop being compatible with newer kernels and I may have to mask kernel upgrades also. Don't know. I would suggest that you make copies of your distfiles directory once you have a machine set up and working. One BIG portage problem is that when I do an eix-update portage will actually ERASE my copy of the ATI driver source code from MY distfiles directory simply because the portage maintainers have removed it from their end. If I didn't have an overlay it would be difficult to rebuild my driver with no source code. Anyway, after 8 or 9 years of running Gentoo I still run it even with these issues. I'm not a sys-admin. I don't really know much about Unix. I do appreciate the control I have over the system even if I strongly disagree sometimes with what the portage maintainers do. It's a good group of people and a very solid base to work from Good luck, Mark
Re: [gentoo-user] nvidia warning comes a tad late
On 1 Jan 2009, at 03:23, Volker Armin Hemmann wrote: ... [assuming] portage could parse lspci output - why make it slower and more easily to break if all breakage can be avoided by simply reading first - then upgrading? We have computers to make our lives simpler easier. If a computer can automatically detect breakage avoid it, then it saves the user reading documentation for many packages. Stroller.
Re: [gentoo-user] nvidia warning comes a tad late
On Wed, Dec 31, 2008 at 7:53 PM, Graham Murray gra...@gmurray.org.uk wrote: Michael P. Soulier msoul...@digitaltorque.ca writes: Sure enough, X no longer works. I'm following the instructions now, but... Don't you think the default action here should be to do nothing instead of breaking my system? I think that the default action should be that such 'breakages' should be checked during the dependency building phase, a message displayed and the emerge stop[0]. Then you could either mask the offending package or issue a special flag[1] to emerge to acknowledge the 'problem' but install/upgrade the package anyway. [0] As with package blockers. [1] A new flag, something like '--unsafe' [1] there isn't as new as you might think, though it's a variable rather than a flag... I quote from the Busybox ebuild: set env VERY_BRAVE_OR_VERY_DUMB=yes if this is realy what you want. silly options will destroy your system For any that haven't played with emerging Busybox to ROOT=/ and USE=make-symlinks, the text above is an excerpt from the message when the emerge chastises you ad calls 'die'. Incidentally... I'm going to go bug that typo (realy)... yay for Firefox's built in spell checking. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] pre-emerge steps
Michael P. Soulier wrote: On 01/01/09 Mick said: I guess there is bugzilla for posting bugs or even requests, but if as Alan says the hardware in question is that obscure/obsolete, then interest for continuing its dev't will undoubtedly decline with time. Maybe the recent 2.6.27 kernel problems that I have experienced are an early warning that my PIII Coppermine is approaching the end of its useful life ... I just stopped using a P-III myself. I was running 2.6.9 under CentOS-4 for ages. Mike I've got a dual PII-350 machine that does nicely for firewall/router, if a little slow to compile stuff. It's using the latest stable kernel :) Matt
Re: [gentoo-user] Kpdf crashes with large documents.
Peter Alfredsen wrote: [Please CC me on all replies] On Wednesday 31 December 2008, Dale wrote: Hi, I recently stole me a Motorola Razr phone and it didn't come with the manual. I downloaded it off the Motorola website and was reading, or attempting to read, it when Kpdf crashed. It does this when I scroll down to about page 30 or so. It's a pretty large document since it has both English and Spanish. For me, this pdf crashed evince in cffparse.c:361, which is indicative of a bug in freetype (bug 247104) for which I just committed a fix. Please add to your package.keywords and test. +*freetype-2.3.7-r1 (01 Jan 2009) + + 01 Jan 2009; Peter Alfredsen loki_...@gentoo.org + +files/freetype-2.3.7-b.g.o-247104.patch, + +files/freetype-2.3.7-b.g.o-253029.patch, + +files/freetype-2.3.7-fix-incorrect-scaling.patch, + +files/freetype-2.3.7-no-segfault-on-load_mac_face.patch, + +freetype-2.3.7-r1.ebuild: + Fix bug 247104, segfault in cffparse.c:361, bug 253029, missing letters in + certain fonts, thanks to Andreas Turriff for the patch-pointer. Also + import patches for alien bugs: http://bugs.debian.org/487101, segfault + when building certain fonts and + http://savannah.nongnu.org/bugs/index.php?23973 , incorrect scaling of + certain fonts. + Just synced and in the process of installing. Dale :-) :-)
Re: [gentoo-user] [OT] High-pitched sound from inside the PC when opening menus
On Thu, Jan 1, 2009 at 4:06 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Wednesday 31 December 2008 17:36:39 Paul Hartman wrote: I can't remember the exact reasoning, but I do recall being told it's normal and that it varies from one system to another, even with the same hardware. I think it's related to capacitors or voltage regulator or something like that. (I am not an electrical engineer) If it's consistent with high load, it's most likely inductors windowing vibrating inside their casing. i.e. loosely wound transformers. The biggest one is in the power supply, which is easy enough to swap out and check. The irritating part is that it's extremely hard to detect where the sound comes from - you can't just turn your head to get the direction as human ears aren't too good at those frequencies When trying KDE4 with all the desktop effects, it was really annoying, everything I did would cause the hissing noise, presumably because it's using more CPU load to do basic things. So, in other words, it's normal. :) Harmless, yes. Annoying, yes. Normal, should not be :-) This happens when vendors use cut-rate components, or the Chinese factory they outsourced the production to uses crappy parts. I went back in my old emails and Abit's (R.I.P.) explanation for me was that the noise comes from the digital PWM and it's normal...
Re: [gentoo-user] Kpdf crashes with large documents.
Dale wrote: Peter Alfredsen wrote: [Please CC me on all replies] On Wednesday 31 December 2008, Dale wrote: Hi, I recently stole me a Motorola Razr phone and it didn't come with the manual. I downloaded it off the Motorola website and was reading, or attempting to read, it when Kpdf crashed. It does this when I scroll down to about page 30 or so. It's a pretty large document since it has both English and Spanish. For me, this pdf crashed evince in cffparse.c:361, which is indicative of a bug in freetype (bug 247104) for which I just committed a fix. Please add to your package.keywords and test. +*freetype-2.3.7-r1 (01 Jan 2009) + + 01 Jan 2009; Peter Alfredsen loki_...@gentoo.org + +files/freetype-2.3.7-b.g.o-247104.patch, + +files/freetype-2.3.7-b.g.o-253029.patch, + +files/freetype-2.3.7-fix-incorrect-scaling.patch, + +files/freetype-2.3.7-no-segfault-on-load_mac_face.patch, + +freetype-2.3.7-r1.ebuild: + Fix bug 247104, segfault in cffparse.c:361, bug 253029, missing letters in + certain fonts, thanks to Andreas Turriff for the patch-pointer. Also + import patches for alien bugs: http://bugs.debian.org/487101, segfault + when building certain fonts and + http://savannah.nongnu.org/bugs/index.php?23973 , incorrect scaling of + certain fonts. + Just synced and in the process of installing. Dale :-) :-) I got it installed and it did not crash. I could scroll all the way to the bottom of it. This seems to have fixed it. I guess I was right, it was a font problem. That was what Google came up with and they were old as the hills. Thanks for getting it fixed for me and the rest of us. Dale :-) :-)
