Re: [gentoo-user] Yahoo and strange traffic.
On Tue, Aug 24, 2010 at 10:36 PM, Dale wrote: > BRM wrote: >> >> Wireshark will show you the raw packet data, and decode only a little of >> it - >> enough to identify the general protocol, senders, etc. >> So to understand the packet, you will need to understand the application >> layer >> protocol - in this case HTTP - yourself as Wireshark won't help you there. >> >> But yet, Wireshark, nmap, and nessus security scanner are the tools, less >> so >> nessus as it really is more of a port scanner/security hole finder than a >> debug >> tool for applications (it's basically an interface for nmap for those >> purposes). >> >> HTH, >> >> Ben >> >> >> > > If finally did it again, and is doing it as I type. I captured some of the > traffic with Wireshark. Can someone tell me what to do with it now? This > is one frame of it: > > Frame 4 (881 bytes on wire, 881 bytes captured) > Arrival Time: Aug 24, 2010 21:03:35.518314000 > [Time delta from previous captured frame: 0.000383000 seconds] > [Time delta from previous displayed frame: 0.000383000 seconds] > [Time since reference or first frame: 0.010995000 seconds] > Frame Number: 4 > Frame Length: 881 bytes > Capture Length: 881 bytes > [Frame is marked: False] > [Protocols in frame: eth:ip:tcp:http] > [Coloring Rule Name: HTTP] > [Coloring Rule String: http || tcp.port == 80] > Ethernet II, Src: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3), Dst: > Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > Destination: Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > Address: Motorola_aa:96:e4 (00:1d:6b:aa:96:e4) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) > Source: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3) > Address: ArchtekT_81:d5:d3 (00:01:53:81:d5:d3) > ...0 = IG bit: Individual address (unicast) > ..0. = LG bit: Globally unique address > (factory default) > Type: IP (0x0800) > Internet Protocol, Src: 192.168.1.2 (192.168.1.2), Dst: 98.136.112.30 > (98.136.112.30) > Version: 4 > Header length: 20 bytes > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) > 00.. = Differentiated Services Codepoint: Default (0x00) > ..0. = ECN-Capable Transport (ECT): 0 > ...0 = ECN-CE: 0 > Total Length: 867 > Identification: 0xe5fb (58875) > Flags: 0x02 (Don't Fragment) > 0.. = Reserved bit: Not Set > .1. = Don't fragment: Set > ..0 = More fragments: Not Set > Fragment offset: 0 > Time to live: 64 > Protocol: TCP (0x06) > Header checksum: 0xbd48 [correct] > [Good: True] > [Bad : False] > Source: 192.168.1.2 (192.168.1.2) > Destination: 98.136.112.30 (98.136.112.30) > Transmission Control Protocol, Src Port: 43281 (43281), Dst Port: http (80), > Seq: 0, Ack: 1, Len: 815 > Source port: 43281 (43281) > Destination port: http (80) > [Stream index: 1] > Sequence number: 0 (relative sequence number) > [Next sequence number: 815 (relative sequence number)] > Acknowledgement number: 1 (relative ack number) > Header length: 32 bytes > Flags: 0x18 (PSH, ACK) > 0... = Congestion Window Reduced (CWR): Not set > .0.. = ECN-Echo: Not set > ..0. = Urgent: Not set > ...1 = Acknowledgement: Set > 1... = Push: Set > .0.. = Reset: Not set > ..0. = Syn: Not set > ...0 = Fin: Not set > Window size: 92 > Checksum: 0x0d09 [validation disabled] > [Good Checksum: False] > [Bad Checksum: False] > Options: (12 bytes) > NOP > NOP > Timestamps: TSval 177975147, TSecr 3960038659 > [SEQ/ACK analysis] > [Number of bytes in flight: 815] > Hypertext Transfer Protocol > GET /v1/displayImage/custom/yahoo/?redirect=0 > HTTP/1.1\r\n > [Expert Info (Chat/Sequence): GET > /v1/displayImage/custom/yahoo/?redirect=0 > HTTP/1.1\r\n] > [Message: GET /v1/displayImage/custom/yahoo/ here>?redirect=0 HTTP/1.1\r\n] > [Severity level: Chat] > [Group: Sequence] > Request Method: GET > Request URI: /v1/displayImage/custom/yahoo/ here>?redirect=0 > Request Version: HTTP/1.1 > Host: rest-img.msg.yahoo.com\r\n > Connection: close\r\n > User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux > 2.6.30-gentoo-r8; X11; i686; en_US) KHTML/4.4.5 (like Gecko)\r\n > Accept: text/html, image/jpeg;q=0.9, image/png;q=0.9, text/*;q=0.9, > image/*;q=0.9, */*;q=0.8\r\n > Accept-Encoding: x-gzip, x-deflate, gzip, deflate\r\n > Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5\r\n > Accept-Language: en-US, en\r\n > [truncated] Cookie: B=ailkv295qsqnr&b=3&s=dn; > Y=v=1&n=bt77n8119ils3&l=30b4a_rzwx/o&p=m2316qt01300&jb=16|47|&r=eg&lg=en-US&intl=us&np=
[gentoo-user] why is the gentoo-arm maillist stop?
why is the gentoo-arm maillist stop? -- pete_doherty
[gentoo-user] Re: KDE and hdparm
I wrote: > Mick writes: > > From KDE-4.4.4 the start up interferes with the hard drives: > > > > http://thread.gmane.org/gmane.linux.gentoo.user/232044 > > > > I don't why but it does, messes up any settings that hdparm may have > > set up and p*sses me off. o_O > > > > As soon as KDE starts up (even when waking up from suspend to ram) it > > resets the drives. I haven't found a way of telling it how to behave > > (i.e. by respecting existing settings in hdparm). > > Argh, that's annoying. Thanks for the information. O well, first I > setuid'ed hdparm to make it work as a user, then I reverted that back > as I started it in /etc/init.d/local, and now I'm again setuid'ing it > so I can set the settings from /etc/conf.d/hdparm in > ~/.kde4/Autostart/. > > I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905 > You might want to vote for it so it gets some attention and will > hopefully be fixed soon. They say it's probably specific to Gentoo, so I filed this bug: http://bugs.gentoo.org/show_bug.cgi?id=334393 Wonko
Re: [gentoo-user] Yahoo and strange traffic.
Joshua Murphy wrote: Well, glancing at the GET request it's making there, as well as the API google points me to when I look it up... http://developer.yahoo.com/messenger/guide/ch03s02.html#d4e4628 You're right that it's after an image from their profile, but the cause of the failure appears to be related to some sort of credentials Yahoo wants the messenger to provide. You might poke Kopete's bugtracker to see if they've a related bug on file already, and if they don't, throw one their way. The API Yahoo appears to be using there (based on a response I got back in poking lightly) is, or is based on, OAuth, which according to this: http://oauth.net/core/1.0/#http_codes specifies that a request should give a 401 response (Authorization Required vs Unauthorized is purely the choice of phrase used in the program decoding the numerical code, i.e. wireshark in your example of it there) in the following cases: HTTP 401 Unauthorized * Invalid Consumer Key * Invalid / expired Token * Invalid signature * Invalid / used nonce Yahoo, essentially, *does* give a "bugger off"!! with that response, but Kopete simply takes it, considers it a brief instant, then decides "Maybe the answer will change if I try again *now*!"... at which point it proceeds to introduce its proverbial cranium to the proverbial brick and mortar vertical surface one might term "the wall." Repeatedly. I was sort of figuring that it was trying to get something and Yahoo wasn't liking it. At least now we know for sure. I went to bug.kde and searched but I didn't see anything. Of course, I'm not really sure what the heck to look for since I don't know what is failing, other than Kopete. Thanks. Dale :-) :-)
[gentoo-user] CHOST on Cygwin?
Hello, I try to setup Gentoo Prefix on Cygwin. Cygwin is a POSIX layer on windows. That means that the environment is POSIX but the binaries are COFF instead of ELF AFAIK. Now I wonder which CHOST to set in this case. What does it describe, the environment or the file format? Al
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On 08/24/2010 08:07 PM, Dale wrote: > dhk wrote: >> On 08/24/2010 06:59 PM, Paul Hartman wrote: >> >>> On Tue, Aug 24, 2010 at 5:37 PM, Dale wrote: >>> Paul Hartman wrote: > On Tue, Aug 24, 2010 at 5:07 PM, Kevin O'Gorman > wrote: > > >> Yah, I might have some luck with that. Since I'm years out of >> practice >> fooling with this stuff (last seen in 2002) can someone point me >> at the >> tools for >> 1) Computing a modeline (I understand the quality varies a lot) >> 2) Configuring an xorg.conf >> >> > Check out x11-apps/amlc -- it has an interactive modeline generator > where you tell it the aspect ratio& size of your screen and it spits > out modelines for you. You'll still need to fill in the > HSync/VSync/Clock speed stuff. > > > > Does this help any? Section "Screen" Identifier "Screen0" Device "Card0" Monitor"Monitor0" Option "DPMS" "TRUE" SubSection "Display" Viewport0 0 Depth 24 Modes "1280x1024" "1024x768" "800x600" EndSubSection SubSection "Display" Viewport0 0 Modes "1280x1024" "1024x768" "800x600" EndSubSection SubSection "Display" Viewport0 0 Depth 4 Modes "1280x1024" "1024x768" "800x600" EndSubSection SubSection "Display" Viewport0 0 Depth 8 Modes "1280x1024" "1024x768" "800x600" EndSubSection That's just a part of my xorg.conf. I don't use hal and don't like udev doing mine so I still got my full xorg.conf file. If you need more, just let me know. Heck, I'll post the whole thing if it will help you any. Also, have you tried running "X -configure" yet? I used it on another machine and it worked pretty well. Dale >>> After creating a basic xorg.conf the modeline should go in the >>> "Monitor" section. I don't use a modeline now but the only example I >>> have from my xorg.conf archives are these: >>> >>> Section "Monitor" >>># 2048x1152 @ 50.00 Hz (GTF) hsync: 59.30 kHz; pclk: 162.24 MHz >>>Modeline "2048x1152_50.00" 162.24 2048 2176 2392 2736 1152 1153 >>> 1156 1186 -HSync +Vsync >>># 2048x1152 @ 60.00 Hz (GTF) hsync: 71.52 kHz; pclk: 197.97 MHz >>>Modeline "2048x1152_60.00" 197.97 2048 2184 2408 2768 1152 1153 >>> 1156 1192 -HSync +Vsync >>> EndSection >>> >>> And then in the Screen section like Dale posted you'd use for example >>> "2048x1152_60.00" as your modeline (or whatever you decided to entitle >>> your modes). >>> >>> At least that's how it used to work. With modern video cards& modern >>> Xorg/Gnome/KDE it does a pretty good job of autodetecting that kind of >>> thing so I haven't had to worry about it in a long time. :) >>> >>> >>> >> My monitor resolution is a little off after the last Xorg upgrade today. >> Everything looks larger than usual. As far as this email thread goes, >> I thought xorg.conf was obsolete. >> >> > > It is if you can use udev and hal to sort out things. Only thing is, if > hal or udev doesn't work, you are stuck with using xorg.conf. As some > may know here, hal didn't work for me. It was good at locking up my > keyboard and mouse tho. At one point, even the SysRq key wouldn't work. > > I don't know where but I also read where someone had trouble with a LCD > screen one time. It would work on a console but no GUI. They had to > use a xorg.conf file to set the display up properly so that it would > work. Hal works for most people but doesn't for others. Then some > others can do some minor tweaking and get it to work. > > I wouldn't even think of trying to tell someone how to tweak hal's > config file. It's in xml and I can't read that. > > I did find this link which may help. The part at the bottom is what I > think you need. > > http://howto-pages.org/ModeLines/ > > Hope that helps. > > Dale > > :-) :-) > > We'll I have an LCD screen that stopped displaying correctly yesterday after the Xorg update. It's not terrible, but not like it was. I may have to use xorg.conf now.
[gentoo-user] trouble emerging vmware-workstation from the vmware overlay
Hello.
I am having some trouble installing vmware-workstation from the vmware
overlay:
# emerge -avt vmware-workstation
These are the packages that would be merged, in reverse order:
Calculating dependencies... done!
[ebuild N f ] app-emulation/vmware-workstation-7.1.1.282343
USE="vmware-tools -doc -vix" 0 kB [1]
[ebuild N] app-emulation/vmware-modules-238 0 kB [1]
[ebuild N F ] app-emulation/vmware-player-3.1.0.261024 USE="vmware-tools
-doc" 100,067 kB [1]
[blocks B ] app-emulation/vmware-workstation
("app-emulation/vmware-workstation" is blocking
app-emulation/vmware-player-3.1.0.261024)
[blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player" is
blocking app-emulation/vmware-workstation-7.1.1.282343)
Total: 3 packages (3 new), Size of downloads: 100,067 kB
Fetch Restriction: 2 packages (1 unsatisfied)
Conflict: 2 blocks (2 unsatisfied)
Portage tree and overlays:
[0] /usr/portage
[1] /var/lib/layman/vmware
* Error: The above package list contains packages which cannot be
* installed at the same time on the same system.
(app-emulation/vmware-player-3.1.0.261024, ebuild scheduled for merge) pulled
in by
~app-emulation/vmware-player-3.1.0.261024 required by
(app-emulation/vmware-modules-238, ebuild scheduled for merge)
(app-emulation/vmware-workstation-7.1.1.282343, ebuild scheduled for merge)
pulled in by
vmware-workstation
For more information about Blocked Packages, please refer to the following
section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
Any help?
Romildo
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
> Hello.
>
> I am having some trouble installing vmware-workstation from the vmware
> overlay:
>
>
> # emerge -avt vmware-workstation
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [ebuild N f ] app-emulation/vmware-workstation-7.1.1.282343
> USE="vmware-tools -doc -vix" 0 kB [1]
> [ebuild N] app-emulation/vmware-modules-238 0 kB [1]
> [ebuild N F ] app-emulation/vmware-player-3.1.0.261024
> USE="vmware-tools -doc" 100,067 kB [1]
> [blocks B ] app-emulation/vmware-workstation
> ("app-emulation/vmware-workstation" is blocking
> app-emulation/vmware-player-3.1.0.261024)
> [blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player"
> is blocking app-emulation/vmware-workstation-7.1.1.282343)
>
> Total: 3 packages (3 new), Size of downloads: 100,067 kB
> Fetch Restriction: 2 packages (1 unsatisfied)
> Conflict: 2 blocks (2 unsatisfied)
> Portage tree and overlays:
> [0] /usr/portage
> [1] /var/lib/layman/vmware
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (app-emulation/vmware-player-3.1.0.261024, ebuild scheduled for merge)
> pulled in by
> ~app-emulation/vmware-player-3.1.0.261024 required by
> (app-emulation/vmware-modules-238, ebuild scheduled for merge)
>
> (app-emulation/vmware-workstation-7.1.1.282343, ebuild scheduled for
> merge) pulled in by
> vmware-workstation
>
>
> For more information about Blocked Packages, please refer to the following
> section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
>
>
>
>
> Any help?
>
> Romildo
>
>
[blocks B ] app-emulation/vmware-workstation
("app-emulation/vmware-workstation"
is blocking app-emulation/vmware-player-3.1.0.261024)
[blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player" is
blocking app-emulation/vmware-workstation-7.1.1.282343)
Here is the reason of your problem. Try to mask vmware-player
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
On Wed, Aug 25, 2010 at 03:23:13PM +0400, d.fedo...@timeweb.ru wrote:
> > Hello.
> >
> > I am having some trouble installing vmware-workstation from the vmware
> > overlay:
> >
> >
> > # emerge -avt vmware-workstation
> >
> > These are the packages that would be merged, in reverse order:
> >
> > Calculating dependencies... done!
> > [ebuild N f ] app-emulation/vmware-workstation-7.1.1.282343
> > USE="vmware-tools -doc -vix" 0 kB [1]
> > [ebuild N] app-emulation/vmware-modules-238 0 kB [1]
> > [ebuild N F ] app-emulation/vmware-player-3.1.0.261024
> > USE="vmware-tools -doc" 100,067 kB [1]
> > [blocks B ] app-emulation/vmware-workstation
> > ("app-emulation/vmware-workstation" is blocking
> > app-emulation/vmware-player-3.1.0.261024)
> > [blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player"
> > is blocking app-emulation/vmware-workstation-7.1.1.282343)
> >
> > Total: 3 packages (3 new), Size of downloads: 100,067 kB
> > Fetch Restriction: 2 packages (1 unsatisfied)
> > Conflict: 2 blocks (2 unsatisfied)
> > Portage tree and overlays:
> > [0] /usr/portage
> > [1] /var/lib/layman/vmware
> >
> > * Error: The above package list contains packages which cannot be
> > * installed at the same time on the same system.
> >
> > (app-emulation/vmware-player-3.1.0.261024, ebuild scheduled for merge)
> > pulled in by
> > ~app-emulation/vmware-player-3.1.0.261024 required by
> > (app-emulation/vmware-modules-238, ebuild scheduled for merge)
> >
> > (app-emulation/vmware-workstation-7.1.1.282343, ebuild scheduled for
> > merge) pulled in by
> > vmware-workstation
> >
> >
> > For more information about Blocked Packages, please refer to the following
> > section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
> >
> > http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
> >
> >
> >
> >
> > Any help?
> >
> > Romildo
> >
> >
> [blocks B ] app-emulation/vmware-workstation
> ("app-emulation/vmware-workstation"
> is blocking app-emulation/vmware-player-3.1.0.261024)
> [blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player" is
> blocking app-emulation/vmware-workstation-7.1.1.282343)
>
> Here is the reason of your problem. Try to mask vmware-player
That does not seem to be enough.
Looking at the ebuilds, I have found the following:
# grep vmware-modules
/var/lib/layman/vmware/app-emulation/vmware-workstation/vmware-workstation-7.1.1.282343.ebuild
PDEPEND="~app-emulation/vmware-modules-238
# grep -B 2 vmware-workstation
/var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.ebuild
DEPEND="${RDEPEND}
|| ( ~app-emulation/vmware-player-3.1.0.261024
~app-emulation/vmware-workstation-7.1.0.261024 )"
# grep -B 2 vmware-workstation
/var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.1.ebuild
DEPEND="${RDEPEND}
|| ( ~app-emulation/vmware-player-3.1.1.282343
~app-emulation/vmware-workstation-7.1.1.282343 )"
Therefore it seems that there are errors in the dependencies in the
ebuilds: vmware-workstation-7.1.1.282343 depends on vmware-modules-238,
which depends on vmware-workstation-7.1.0.261024.
Is this a bug? If so, where should it be reported?
Romildo
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
On Wed, 2010-08-25 at 08:58 -0300, José Romildo Malaquias wrote:
> > Here is the reason of your problem. Try to mask vmware-player
>
> That does not seem to be enough.
>
> Looking at the ebuilds, I have found the following:
>
>
>
> # grep
> vmware-modules
> /var/lib/layman/vmware/app-emulation/vmware-workstation/vmware-workstation-7.1.1.282343.ebuild
> PDEPEND="~app-emulation/vmware-modules-238
>
> # grep -B 2
> vmware-workstation
> /var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.ebuild
> DEPEND="${RDEPEND}
> || ( ~app-emulation/vmware-player-3.1.0.261024
> ~app-emulation/vmware-workstation-7.1.0.261024 )"
>
> # grep -B 2
> vmware-workstation
> /var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.1.ebuild
> DEPEND="${RDEPEND}
> || ( ~app-emulation/vmware-player-3.1.1.282343
> ~app-emulation/vmware-workstation-7.1.1.282343 )"
>
>
>
>
>
> Therefore it seems that there are errors in the dependencies in the
> ebuilds: vmware-workstation-7.1.1.282343 depends on
> vmware-modules-238,
> which depends on vmware-workstation-7.1.0.261024.
>
>
It's an OR (||) relationship. The modules depend on vmware-player OR
vmware-workstation. And likely vmware-player and vmware-workstation
block each other. So you need to install one OR the other and make sure
the other one isn't installed.
Re: [gentoo-user] failed reiserfs partition - help!
On Tue, 2010-08-24 at 10:44 -0400, James wrote: > Albert, > > Thanks for the response. > > "dd" for the lazy -- takes 2 seconds to wipe the top of the drive > instead of getting rid of numerous partitions that the manufacturer > put on the drive. But what I'm saying is... you "wipe" the partition table and then you use fdisk (or whatever) to create partitions. The very act using fdisk and writing to the partition table wipes out the previous one. The sending $25 to namesys part was a joke. Namesys isn't around anymore.
Re: [gentoo-user] Re: 32/64bit confusion
On 8/24/2010 5:46 PM, tpar...@etherstorm.net wrote: On 8/24/2010 5:15 PM, Nikos Chantziaras wrote: There is no such package. There are only very few -bin packages. In other words, "-bin" is not a magic string you append to package names. As for Wine, the ebuild changed recently to offer both 64bit as well as 32bit Wine. I think the binaries are called "wine32" and "wine64". Two new USE flags have been introduced to control this: "win32" and "win64". By default, both are enabled. If you disable the "win64" USE flag, you'll get only the 32bit Wine. And vice versa of course. Thank you, that helps a great deal. Is it correct that if a program does have a -bin package I can emerge that and have it work as a 32 bit program in the 64 bit environment (and the same with wine32)? Generally speaking, yes -- if everything is set up properly with the package in portage, that will be true. However, in many of those cases there's also a source package that builds and runs equally well on 64-bit OS's, so using the -bin package should be done only if there's a specific reason to. Currently, for example, many people are using the firefox-bin or chromium-bin packages because of issues with Adobe Flash Player. --Mike
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
On Wed, Aug 25, 2010 at 08:02:17AM -0400, Albert Hopkins wrote:
> On Wed, 2010-08-25 at 08:58 -0300, José Romildo Malaquias wrote:
> > > Here is the reason of your problem. Try to mask vmware-player
> >
> > That does not seem to be enough.
> >
> > Looking at the ebuilds, I have found the following:
> >
> >
> >
> > # grep
> > vmware-modules
> > /var/lib/layman/vmware/app-emulation/vmware-workstation/vmware-workstation-7.1.1.282343.ebuild
> > PDEPEND="~app-emulation/vmware-modules-238
> >
> > # grep -B 2
> > vmware-workstation
> > /var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.ebuild
> > DEPEND="${RDEPEND}
> > || ( ~app-emulation/vmware-player-3.1.0.261024
> > ~app-emulation/vmware-workstation-7.1.0.261024 )"
> >
> > # grep -B 2
> > vmware-workstation
> > /var/lib/layman/vmware/app-emulation/vmware-modules/vmware-modules-238.1.ebuild
> > DEPEND="${RDEPEND}
> > || ( ~app-emulation/vmware-player-3.1.1.282343
> > ~app-emulation/vmware-workstation-7.1.1.282343 )"
> >
> > Therefore it seems that there are errors in the dependencies in the
> > ebuilds: vmware-workstation-7.1.1.282343 depends on
> > vmware-modules-238,
> > which depends on vmware-workstation-7.1.0.261024.
> >
>
> It's an OR (||) relationship. The modules depend on vmware-player OR
> vmware-workstation. And likely vmware-player and vmware-workstation
> block each other. So you need to install one OR the other and make sure
> the other one isn't installed.
Yes, that is the way to solve the blocking. But even after masking
vmware-player, I have trouble getting vmware-workstation-7.1.1.282343
installed.
How can mware-workstation-7.1.1.282343 depend on vmware-modules-238, and
vmware-modules-238 depend on vmware-workstation-7.1.0.261024. To me this
is bug.
Probably mware-workstation-7.1.1.282343 should depend on
vmware-modules-238.1 (notice the .1 in the version 238.1), which is also
available in the overlay.
Romildo
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
Just type this in ur terminal :
sudo sed -i 's/vmware-modules-238/vmware-modules-238.1/'
/var/lib/layman/vmware/app-emulation/vmware-workstation/vmware-workstation-7.1.1.282343.ebuild
&&
sudo ebuild
/var/lib/layman/vmware/app-emulation/vmware-workstation/vmware-workstation-7.1.1.282343.ebuild
manifest
2010/8/25 José Romildo Malaquias
> Hello.
>
> I am having some trouble installing vmware-workstation from the vmware
> overlay:
>
>
> # emerge -avt vmware-workstation
>
> These are the packages that would be merged, in reverse order:
>
> Calculating dependencies... done!
> [ebuild N f ] app-emulation/vmware-workstation-7.1.1.282343
> USE="vmware-tools -doc -vix" 0 kB [1]
> [ebuild N] app-emulation/vmware-modules-238 0 kB [1]
> [ebuild N F ] app-emulation/vmware-player-3.1.0.261024
> USE="vmware-tools -doc" 100,067 kB [1]
> [blocks B ] app-emulation/vmware-workstation
> ("app-emulation/vmware-workstation" is blocking
> app-emulation/vmware-player-3.1.0.261024)
> [blocks B ] app-emulation/vmware-player ("app-emulation/vmware-player"
> is blocking app-emulation/vmware-workstation-7.1.1.282343)
>
> Total: 3 packages (3 new), Size of downloads: 100,067 kB
> Fetch Restriction: 2 packages (1 unsatisfied)
> Conflict: 2 blocks (2 unsatisfied)
> Portage tree and overlays:
> [0] /usr/portage
> [1] /var/lib/layman/vmware
>
> * Error: The above package list contains packages which cannot be
> * installed at the same time on the same system.
>
> (app-emulation/vmware-player-3.1.0.261024, ebuild scheduled for merge)
> pulled in by
>~app-emulation/vmware-player-3.1.0.261024 required by
> (app-emulation/vmware-modules-238, ebuild scheduled for merge)
>
> (app-emulation/vmware-workstation-7.1.1.282343, ebuild scheduled for
> merge) pulled in by
>vmware-workstation
>
>
> For more information about Blocked Packages, please refer to the following
> section of the Gentoo Linux x86 Handbook (architecture is irrelevant):
>
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
>
>
>
>
> Any help?
>
> Romildo
>
>
Re: [gentoo-user] trouble emerging vmware-workstation from the vmware overlay
On Wed, 2010-08-25 at 09:40 -0300, José Romildo Malaquias wrote: > Yes, that is the way to solve the blocking. But even after masking > vmware-player, I have trouble getting vmware-workstation-7.1.1.282343 > installed. > > How can mware-workstation-7.1.1.282343 depend on vmware-modules-238, > and > vmware-modules-238 depend on vmware-workstation-7.1.0.261024. To me > this > is bug. > > Probably mware-workstation-7.1.1.282343 should depend on > vmware-modules-238.1 (notice the .1 in the version 238.1), which is > also > available in the overlay. Well, you are using an overlay so.. caveat emptor.
Re: [gentoo-user] Yahoo and strange traffic.
- Original Message > Joshua Murphy wrote: > > Well, glancing at the GET request it's making there, as well as the > > API google points me to when I look it up... > > > > http://developer.yahoo.com/messenger/guide/ch03s02.html#d4e4628 > > > > You're right that it's after an image from their profile, but the > > cause of the failure appears to be related to some sort of credentials > > Yahoo wants the messenger to provide. You might poke Kopete's > > bugtracker to see if they've a related bug on file already, and if > > they don't, throw one their way. > > > > The API Yahoo appears to be using there (based on a response I got > > back in poking lightly) is, or is based on, OAuth, which according to > > this: > > > > http://oauth.net/core/1.0/#http_codes > > > > specifies that a request should give a 401 response (Authorization > > Required vs Unauthorized is purely the choice of phrase used in the > > program decoding the numerical code, i.e. wireshark in your example of > > it there) in the following cases: > > > > HTTP 401 Unauthorized > >* Invalid Consumer Key > >* Invalid / expired Token > > * Invalid signature > >* Invalid / used nonce > > > > Yahoo, essentially, *does* give a "bugger off"!! with that response, > > but Kopete simply takes it, considers it a brief instant, then decides > > "Maybe the answer will change if I try again *now*!"... at which point > > it proceeds to introduce its proverbial cranium to the proverbial > > brick and mortar vertical surface one might term "the wall." > > Repeatedly. > > > > > > I was sort of figuring that it was trying to get something and Yahoo > wasn't liking it. At least now we know for sure. > > I went to bug.kde and searched but I didn't see anything. Of course, > I'm not really sure what the heck to look for since I don't know what is > failing, other than Kopete. Best bet would probably be to check with the Kopete devs on IRC or mailing list (kopete-devel). Ben
Re: [gentoo-user] Yahoo and strange traffic.
On Wed, Aug 25, 2010 at 9:21 AM, BRM wrote: > - Original Message > >> Joshua Murphy wrote: >> > Well, glancing at the GET request it's making there, as well as the >> > API google points me to when I look it up... >> > >> > http://developer.yahoo.com/messenger/guide/ch03s02.html#d4e4628 >> > >> > You're right that it's after an image from their profile, but the >> > cause of the failure appears to be related to some sort of credentials >> > Yahoo wants the messenger to provide. You might poke Kopete's >> > bugtracker to see if they've a related bug on file already, and if >> > they don't, throw one their way. >> > >> > The API Yahoo appears to be using there (based on a response I got >> > back in poking lightly) is, or is based on, OAuth, which according to >> > this: >> > >> > http://oauth.net/core/1.0/#http_codes >> > >> > specifies that a request should give a 401 response (Authorization >> > Required vs Unauthorized is purely the choice of phrase used in the >> > program decoding the numerical code, i.e. wireshark in your example of >> > it there) in the following cases: >> > >> > HTTP 401 Unauthorized >> > * Invalid Consumer Key >> > * Invalid / expired Token >> > * Invalid signature >> > * Invalid / used nonce >> > >> > Yahoo, essentially, *does* give a "bugger off"!! with that response, >> > but Kopete simply takes it, considers it a brief instant, then decides >> > "Maybe the answer will change if I try again *now*!"... at which point >> > it proceeds to introduce its proverbial cranium to the proverbial >> > brick and mortar vertical surface one might term "the wall." >> > Repeatedly. >> > >> > >> >> I was sort of figuring that it was trying to get something and Yahoo >> wasn't liking it. At least now we know for sure. >> >> I went to bug.kde and searched but I didn't see anything. Of course, >> I'm not really sure what the heck to look for since I don't know what is >> failing, other than Kopete. > > Best bet would probably be to check with the Kopete devs on IRC or mailing > list > (kopete-devel). > > Ben Yep, but... just from a glance at their bug tracker and their commits list... they made quite a few changes to the Yahoo plugin's handling of avatars and such in January that're in 4.4... so their go-to answer on Yahoo avatar related issues seems to be "Try it on 4.4, then come back if it's still broken." So... to save a little time and effort when that answer's thrown around... might be best to test with that. I don't have QT or anything that depends on it on any of my boxes (the only box I actually have X on right now's my netbook, so adding's not even a feasable option) and my yahoo account went dead a few years ago, so I'm not much use for testing. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Re: 32/64bit confusion
On 08/24/2010 03:17 PM, tpar...@etherstorm.net wrote: > On 8/24/2010 5:45 PM, Zeerak Mustafa Waseem wrote: >> A good idea might be to install the package app-portage/eix. It allows >> you to, amongst other things, to search for packages in case you're >> uncertain about a package name. The search will also tell you whether >> the package is installed, what version as well as what use-flags there >> are for the package. >> There are a lot of other benefits to this application so read the man >> page. > > Extremely useful, grabbing it now, thank you! That's an understatement. I think, of all the portage tools out there, I have used eix the most. Of course, revdep-rebuild comes in second, but it's not even really close.
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman wrote: > I found the specs with Hsync and VSync limits, but they don't mention the > clock speed. I guess I'll just have to fool with it until it works or > catches fire. That basically describes the way I've done my X monitor settings for the past 10 years or so. I just made up a bunch of numbers and hope they accidentally work. :) Now I'm thankful for EDID in monitors and smarter video drivers.
Re: [gentoo-user] Feckless xdm not much of a manager
On 08/24/2010 08:36 PM, Kevin O'Gorman wrote: > In order to make progress on this thing, it's useful to be able to > control the display manager. My problem has been that going to /etc/init.d > and commanding "./xdm stop" seems to work, but has no effect on KDE. > Manually killing kde (ps -ef | grep kde, etc) just starts another one. > I finally figured out that I have to find the 'kdm' process and kill > that, then a logoff or Ctl_Alt_BS actually gets rid of X, so I can do > things like > "X -configure" and so on. You ~should~ be able to log onto a console vty by using Ctrl-Alt-Fn (where n=1-6). You can then log on from there and commence all manner of Gentacular shelly goodness. There's really no need to kill the display manager ever. In fact, you can have more than one running at a time. > Oddly, "./xdm start" worked fine, and was responsible for kdm being > started. But isn't it odd that the display "manager" has such weak > control on its "subordinate"? Big PITA for me. Yeah, that's just a semantic problem, really. The generic term is "xdm" but depending upon your setup, you can plug in any display manager.
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On 25 August 2010 15:17, Paul Hartman wrote: > On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman wrote: >> I found the specs with Hsync and VSync limits, but they don't mention the >> clock speed. I guess I'll just have to fool with it until it works or >> catches fire. > > That basically describes the way I've done my X monitor settings for > the past 10 years or so. I just made up a bunch of numbers and hope > they accidentally work. :) Now I'm thankful for EDID in monitors and > smarter video drivers. I think that if xrandr -q does not show the resolution you are seeking, then the video card or driver in question cannot provide it. I'm not sure that feeding xorg any odd modeline will change things, plus unlike a CRT monitor, LCDs only provide a clear image at their native resolution (denoted by '+' in the xrandr list of resolutions) -- Regards, Mick
Re: [gentoo-user] Feckless xdm not much of a manager
On 25 August 2010 15:22, Bill Longman wrote: > On 08/24/2010 08:36 PM, Kevin O'Gorman wrote: >> In order to make progress on this thing, it's useful to be able to >> control the display manager. My problem has been that going to /etc/init.d >> and commanding "./xdm stop" seems to work, but has no effect on KDE. >> Manually killing kde (ps -ef | grep kde, etc) just starts another one. >> I finally figured out that I have to find the 'kdm' process and kill >> that, then a logoff or Ctl_Alt_BS actually gets rid of X, so I can do >> things like >> "X -configure" and so on. > > You ~should~ be able to log onto a console vty by using Ctrl-Alt-Fn > (where n=1-6). You can then log on from there and commence all manner of > Gentacular shelly goodness. > > There's really no need to kill the display manager ever. In fact, you > can have more than one running at a time. > >> Oddly, "./xdm start" worked fine, and was responsible for kdm being >> started. But isn't it odd that the display "manager" has such weak >> control on its "subordinate"? Big PITA for me. > > Yeah, that's just a semantic problem, really. The generic term is "xdm" > but depending upon your setup, you can plug in any display manager. Running /etc/init.d/xdm stop should kill kdm too. If it respawns, then run /etc/init.d/xdm zap. -- Regards, Mick
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wed, Aug 25, 2010 at 9:25 AM, Mick wrote: > On 25 August 2010 15:17, Paul Hartman wrote: >> On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman wrote: >>> I found the specs with Hsync and VSync limits, but they don't mention the >>> clock speed. I guess I'll just have to fool with it until it works or >>> catches fire. >> >> That basically describes the way I've done my X monitor settings for >> the past 10 years or so. I just made up a bunch of numbers and hope >> they accidentally work. :) Now I'm thankful for EDID in monitors and >> smarter video drivers. > > I think that if xrandr -q does not show the resolution you are > seeking, then the video card or driver in question cannot provide it. > I'm not sure that feeding xorg any odd modeline will change things, > plus unlike a CRT monitor, LCDs only provide a clear image at their > native resolution (denoted by '+' in the xrandr list of resolutions) I've been able to generate modelines in the past for all kinds of crazy non-standard resolutions. I think the ones listed may be the ones defined in the card's BIOS. I just remembered about CVT, I think it's what I used to generate the modelines I posted earlier. It is part of the x11-base/xorg-server package and will generate the frequencies and everything for you based on VESA standards. You simply give it X and Y resolution and it does the rest. For example: $ cvt 1280 720 # 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz Modeline "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 748 -hsync +vsync
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On 25 August 2010 15:38, Paul Hartman wrote: > On Wed, Aug 25, 2010 at 9:25 AM, Mick wrote: >> On 25 August 2010 15:17, Paul Hartman wrote: >>> On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman wrote: I found the specs with Hsync and VSync limits, but they don't mention the clock speed. I guess I'll just have to fool with it until it works or catches fire. >>> >>> That basically describes the way I've done my X monitor settings for >>> the past 10 years or so. I just made up a bunch of numbers and hope >>> they accidentally work. :) Now I'm thankful for EDID in monitors and >>> smarter video drivers. >> >> I think that if xrandr -q does not show the resolution you are >> seeking, then the video card or driver in question cannot provide it. >> I'm not sure that feeding xorg any odd modeline will change things, >> plus unlike a CRT monitor, LCDs only provide a clear image at their >> native resolution (denoted by '+' in the xrandr list of resolutions) > > I've been able to generate modelines in the past for all kinds of > crazy non-standard resolutions. I think the ones listed may be the > ones defined in the card's BIOS. > > I just remembered about CVT, I think it's what I used to generate the > modelines I posted earlier. It is part of the x11-base/xorg-server > package and will generate the frequencies and everything for you based > on VESA standards. You simply give it X and Y resolution and it does > the rest. For example: > > $ cvt 1280 720 > # 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz > Modeline "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 > 748 -hsync +vsync Fair enough, but anything other than the native resolution on an LCD monitor will end looking distorted or blurred. -- Regards, Mick
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wed, Aug 25, 2010 at 9:44 AM, Mick wrote: > On 25 August 2010 15:38, Paul Hartman wrote: >> On Wed, Aug 25, 2010 at 9:25 AM, Mick wrote: >>> On 25 August 2010 15:17, Paul Hartman wrote: On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman wrote: > I found the specs with Hsync and VSync limits, but they don't mention the > clock speed. I guess I'll just have to fool with it until it works or > catches fire. That basically describes the way I've done my X monitor settings for the past 10 years or so. I just made up a bunch of numbers and hope they accidentally work. :) Now I'm thankful for EDID in monitors and smarter video drivers. >>> >>> I think that if xrandr -q does not show the resolution you are >>> seeking, then the video card or driver in question cannot provide it. >>> I'm not sure that feeding xorg any odd modeline will change things, >>> plus unlike a CRT monitor, LCDs only provide a clear image at their >>> native resolution (denoted by '+' in the xrandr list of resolutions) >> >> I've been able to generate modelines in the past for all kinds of >> crazy non-standard resolutions. I think the ones listed may be the >> ones defined in the card's BIOS. >> >> I just remembered about CVT, I think it's what I used to generate the >> modelines I posted earlier. It is part of the x11-base/xorg-server >> package and will generate the frequencies and everything for you based >> on VESA standards. You simply give it X and Y resolution and it does >> the rest. For example: >> >> $ cvt 1280 720 >> # 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz >> Modeline "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 >> 748 -hsync +vsync > > Fair enough, but anything other than the native resolution on an LCD > monitor will end looking distorted or blurred. Of course, and I agree completely, but what I was going for was at least he can get blurry 16:9 that fills the whole screen rather than 4:3 that is either stretched or leaves gaps on the sides. :)
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wednesday 25 August 2010 15:44:58 Mick wrote: > Fair enough, but anything other than the native resolution on an LCD > monitor will end looking distorted or blurred. Why? Granted, LCD panels are made up of discreet pixels, but so are CRTs: the dots are deposited in trios, each illuminated through a hole in the shadow mask. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
2010/8/25 Peter Humphrey : > On Wednesday 25 August 2010 15:44:58 Mick wrote: > >> Fair enough, but anything other than the native resolution on an LCD >> monitor will end looking distorted or blurred. > > Why? Granted, LCD panels are made up of discreet pixels, but so are > CRTs: the dots are deposited in trios, each illuminated through a hole > in the shadow mask. Right, but nature does a better job at upsampling an image than DSPs. Br, Maciej Grela
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
2010/8/25 Peter Humphrey : > On Wednesday 25 August 2010 15:44:58 Mick wrote: > >> Fair enough, but anything other than the native resolution on an LCD >> monitor will end looking distorted or blurred. > > Why? Granted, LCD panels are made up of discreet pixels, but so are > CRTs: the dots are deposited in trios, each illuminated through a hole > in the shadow mask. Right, but nature does a better job at upsampling an image than DSPs. Br, Maciej Grela
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wednesday 25 August 2010 17:39:15 Maciej Grela wrote: > 2010/8/25 Peter Humphrey : > > On Wednesday 25 August 2010 15:44:58 Mick wrote: > >> Fair enough, but anything other than the native resolution on an > >> LCD monitor will end looking distorted or blurred. > > > > Why? Granted, LCD panels are made up of discreet pixels, but so are > > CRTs: the dots are deposited in trios, each illuminated through a > > hole in the shadow mask. > > Right, but nature does a better job at upsampling an image than DSPs. Can't say I've noticed it, but then maybe my eyes aren't good enough to see the difference. They certainly aren't very good. -- Rgds Peter. Linux Counter 5290, 1994-04-23.
Re: [gentoo-user] Is there any games base on openCL?
On Wednesday 25 August 2010, Blackdream W wrote: > I install the ati-drivers-10.7.1 just now,this version it seem support > openCL 1.1. > > Any games base on it? > > Thanks. games can not be based on opencl. Games might be able to use opencl to speed up certain kinds of calculations. But you can not 'use' opencl like opengl to base a game on it.
Re: [gentoo-user] Re: KDE and hdparm
On Wednesday 25 August 2010 10:54:23 Alex Schuster wrote: > I wrote: > > Mick writes: > > > From KDE-4.4.4 the start up interferes with the hard drives: > > > > > > http://thread.gmane.org/gmane.linux.gentoo.user/232044 > > > > > > I don't why but it does, messes up any settings that hdparm may have > > > set up and p*sses me off. o_O > > > > > > As soon as KDE starts up (even when waking up from suspend to ram) it > > > resets the drives. I haven't found a way of telling it how to behave > > > (i.e. by respecting existing settings in hdparm). > > > > Argh, that's annoying. Thanks for the information. O well, first I > > setuid'ed hdparm to make it work as a user, then I reverted that back > > as I started it in /etc/init.d/local, and now I'm again setuid'ing it > > so I can set the settings from /etc/conf.d/hdparm in > > ~/.kde4/Autostart/. > > > > I filed a bug: https://bugs.kde.org/show_bug.cgi?id=248905 > > You might want to vote for it so it gets some attention and will > > hopefully be fixed soon. > > They say it's probably specific to Gentoo, so I filed this bug: > http://bugs.gentoo.org/show_bug.cgi?id=334393 > > Wonko Thank you! I topped it up. ;-) -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
Apparently, though unproven, at 18:30 on Wednesday 25 August 2010, Peter Humphrey did opine thusly: > On Wednesday 25 August 2010 15:44:58 Mick wrote: > > Fair enough, but anything other than the native resolution on an LCD > > monitor will end looking distorted or blurred. > > Why? Granted, LCD panels are made up of discreet pixels, but so are > CRTs: the dots are deposited in trios, each illuminated through a hole > in the shadow mask. That is incorrect. A CRT display is not pixelated - it is made up of triads (not trios) and there is no way of knowing which triad is lit up for any given "logical pixel". The electron beam is an analogue signal and it works mainly because there are more triads than logical pixels. LCDs on the other hand are pixelated. Each group of three display elements is addressable in a consistent fashion. CRTs and LCDs are about as different as cassette tapes and CDs, and just as incompatible. Both cases need lots of magic voodoo to arrive at some commonality. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Feckless xdm not much of a manager
On Wed, Aug 25, 2010 at 7:22 AM, Bill Longman wrote: > On 08/24/2010 08:36 PM, Kevin O'Gorman wrote: > > In order to make progress on this thing, it's useful to be able to > > control the display manager. My problem has been that going to > /etc/init.d > > and commanding "./xdm stop" seems to work, but has no effect on KDE. > > Manually killing kde (ps -ef | grep kde, etc) just starts another one. > > I finally figured out that I have to find the 'kdm' process and kill > > that, then a logoff or Ctl_Alt_BS actually gets rid of X, so I can do > > things like > > "X -configure" and so on. > > You ~should~ be able to log onto a console vty by using Ctrl-Alt-Fn > (where n=1-6). You can then log on from there and commence all manner of > Gentacular shelly goodness. > > There's really no need to kill the display manager ever. In fact, you > can have more than one running at a time. > > > Oddly, "./xdm start" worked fine, and was responsible for kdm being > > started. But isn't it odd that the display "manager" has such weak > > control on its "subordinate"? Big PITA for me. > > Yeah, that's just a semantic problem, really. The generic term is "xdm" > but depending upon your setup, you can plug in any display manager. > Sorry, but that has several bits of misinformation. There are 2 or three activities that the system refuses to perform while the display is active. They require X to be shut down, and you must therefore use one of the non-X console ptys. "xdm" is not a generic term, or at least I didn't mean it that way. It's the package x11-apps/xdm. Look it up. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Feckless xdm not much of a manager
On Wed, Aug 25, 2010 at 7:28 AM, Mick wrote: > On 25 August 2010 15:22, Bill Longman wrote: > > On 08/24/2010 08:36 PM, Kevin O'Gorman wrote: > >> In order to make progress on this thing, it's useful to be able to > >> control the display manager. My problem has been that going to > /etc/init.d > >> and commanding "./xdm stop" seems to work, but has no effect on KDE. > >> Manually killing kde (ps -ef | grep kde, etc) just starts another one. > >> I finally figured out that I have to find the 'kdm' process and kill > >> that, then a logoff or Ctl_Alt_BS actually gets rid of X, so I can do > >> things like > >> "X -configure" and so on. > > > [snip] > > Running /etc/init.d/xdm stop should kill kdm too. If it respawns, > then run /etc/init.d/xdm zap. > -- > Regards, > Mick > > zap does nothing about respawning. It is used when a daemon has somehow died, but is still marked as running. In such a case, you cannot start it again without zapping that marking so that it is recorded as being stopped. I had more or less the opposite case -- a running daemon that was marked as stopped. Not exactly, because it was xdm marked as stopped, and kdm that was running. This problem is repeatable on my system, so I probably borked it somehow. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Feckless xdm not much of a manager
Kevin O'Gorman writes: > This problem is repeatable on my system, so I probably borked it > somehow. I know this effect, this happens from time to time. At the moment it is working fine, but I got used to killall kdm when the init script did not work. It did not bother me too much, so I did not file a bug yet. Wonko
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wed, Aug 25, 2010 at 7:57 AM, Paul Hartman > wrote: > On Wed, Aug 25, 2010 at 9:44 AM, Mick wrote: > > On 25 August 2010 15:38, Paul Hartman > > > > wrote: > >> On Wed, Aug 25, 2010 at 9:25 AM, Mick > wrote: > >>> On 25 August 2010 15:17, Paul Hartman > >>> > > wrote: > On Tue, Aug 24, 2010 at 7:03 PM, Kevin O'Gorman > wrote: > > I found the specs with Hsync and VSync limits, but they don't mention > the > > clock speed. I guess I'll just have to fool with it until it works > or > > catches fire. > > That basically describes the way I've done my X monitor settings for > the past 10 years or so. I just made up a bunch of numbers and hope > they accidentally work. :) Now I'm thankful for EDID in monitors and > smarter video drivers. > >>> > >>> I think that if xrandr -q does not show the resolution you are > >>> seeking, then the video card or driver in question cannot provide it. > >>> I'm not sure that feeding xorg any odd modeline will change things, > >>> plus unlike a CRT monitor, LCDs only provide a clear image at their > >>> native resolution (denoted by '+' in the xrandr list of resolutions) > >> > >> I've been able to generate modelines in the past for all kinds of > >> crazy non-standard resolutions. I think the ones listed may be the > >> ones defined in the card's BIOS. > >> > >> I just remembered about CVT, I think it's what I used to generate the > >> modelines I posted earlier. It is part of the x11-base/xorg-server > >> package and will generate the frequencies and everything for you based > >> on VESA standards. You simply give it X and Y resolution and it does > >> the rest. For example: > >> > >> $ cvt 1280 720 > >> # 1280x720 59.86 Hz (CVT 0.92M9) hsync: 44.77 kHz; pclk: 74.50 MHz > >> Modeline "1280x720_60.00" 74.50 1280 1344 1472 1664 720 723 728 > >> 748 -hsync +vsync > > > > Fair enough, but anything other than the native resolution on an LCD > > monitor will end looking distorted or blurred. > > Of course, and I agree completely, but what I was going for was at > least he can get blurry 16:9 that fills the whole screen rather than > 4:3 that is either stretched or leaves gaps on the sides. :) > > Precisely my goal when I started this thread. In my case, native appears to be 1920x1080. With no xorg.conf, X finds 1280x1024, which is usable either stretched, or with the gaps. There is no discernable flicker, blur or distortion, just capacity that is not being used. There are some confusing things about this. - The log contains 1920x1080 modelines, but is not using them or clearly stating the reason. - The log contains the lines (!!) MACH64(0): Virtual resolutions will be limited to 8191 kB due to linear aperture size and/or placement of hardware cursor image area. I have no idea how to reconcile that with the fact that the resolution being used results in 1310720 (1.3 million) pixels, at 3 bytes (24 bits) per pixel, which sounds to me like over 3 megabytes. The desired resolution would have 2073600 (2 million) pixels and about 6 megabytes. They sound too big, but the first one actually works. I don't understand this at all. - (--) MACH64(0): Internal programmable clock generator detected. (--) MACH64(0): Reference clock 157.5/11 (14.318) MHz. (II) MACH64(0): : Using hsync range of 30.00-85.00 kHz (II) MACH64(0): : Using vrefresh range of 55.00-75.00 Hz (II) MACH64(0): : Using maximum pixel clock of 160.00 MHz (II) MACH64(0): Estimated virtual size for aspect ratio 1.7931 is 1920x1080 (this bothers me because, 1920/1080 is more like 1.) (II) MACH64(0): Maximum clock: 120.00 MHz So it's still contemplating 1920x1080, but mentions both 120MHz and 160MHz as the max for pixel clock. Anyway, for 2 million pixels, 120MHz is not going to cover any overhead at 60 Hz, and 55Hz might not make it either. Maybe the MACH64 cannot actually get above 120 MHz. How to find out if that's what the log is trying to say? - it complains about memory for 2048x1536, but not for anything smaller (I don't think the monitor has that many pixels anyway.) So I guess there's memory enough for all the others. Instead it complains about many modelines in this fashion (but showing just the last 2 lines) (II) MACH64(0): Not using driver mode "1920x1080" (bad mode clock/interlace/doublescan) (WW) MACH64(0): Shrinking virtual size estimate from 1920x1080 to 1280x1024 -- Kevin O'Gorman, PhD
Re: [gentoo-user] Feckless xdm not much of a manager
On Wed, Aug 25, 2010 at 8:33 PM, Kevin O'Gorman wrote: > Sorry, but that has several bits of misinformation. > > "xdm" is not a generic term, or at least I didn't mean it that way. It's the > package x11-apps/xdm. Gentoo uses the term xdm in two ways, one is for the xdm display manager, provided by that package. The other is for the init scripts used to launch a display manager. The init script launches the display manager specified in the config files, kdm being the common one choosen for KDE. You are complaining about kdm not shutting down, this is nothing at all to do with x11-apps/xdm, which is an entirely separate package. If you have both running, than, again, kdms inability to behave is NOT a problem of x11-apps/xdm, though, arguably, it could be said to be a problem of openrc. RobbieAB
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
Den 24. aug. 2010 04:27, skrev Kevin O'Gorman: I had to replace an 4:3 Westinghouse monitor this weekend. I got a new ASUS VH242H, which is very wide. But Xorg is still running 1280x1024, instead of the monitor's normal 1920x1080, according to xorg logs because of lack of video memory (using the ATI on the motherboard). I can make the screen use a 4:3 aspect ratio, so I'm up and running, much better than I started, but I'd like to do better. I guess I've gotta look for a video card, but all I have is PCIX slots, so I don't want to put a lot of money into it (I'll be upgrading the mobo when finances permit -- which is not right now.) Just did a cursory read of the entire thread here. I notice the card is on the mobo, did you try to see if there is a BIOS setting to increase the amount of video RAM? I.e enter BIOS setup during boot, and look around in the chip setup.
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wed, Aug 25, 2010 at 1:48 PM, Håkon Alstadheim wrote: > Den 24. aug. 2010 04:27, skrev Kevin O'Gorman: > > I had to replace an 4:3 Westinghouse monitor this weekend. I got a new >> ASUS VH242H, which is very wide. But Xorg is still running 1280x1024, >> instead of the monitor's normal 1920x1080, according to xorg logs because of >> lack of video memory (using the ATI on the motherboard). I can make the >> screen use a 4:3 aspect ratio, so I'm up and running, much better than I >> started, but I'd like to do better. >> >> I guess I've gotta look for a video card, but all I have is PCIX slots, so >> I don't want to put a lot of money into it (I'll be upgrading the mobo when >> finances permit -- which is not right now.) >> > > Just did a cursory read of the entire thread here. I notice the card is on > the mobo, did you try to see if there is a BIOS setting to increase the > amount of video RAM? I.e enter BIOS setup during boot, and look around in > the chip setup. > Hmmm. Be right back. -- Kevin O'Gorman, PhD
Re: [gentoo-user] FYI: Rules for distro-friendly packages
* Alan McKinnon wrote: > Some more: > > Don't depend on some arb version number of libs. Nothing worse than being > forced to use some lib 4 versions behind current when current actually works > just fine ACK. But most times, that IMHO comes from incompatible API (or ABI) changes. Perhaps I should add some rules about that - libs have to maintain backwards API (or even ABI ?) compatibility, at least within the same major version. > No hardcoded locations. If I want to install to /opt/csw/package/, then I > should be able to do it, it makes zero difference to upstream if I do ACK. Packages should be (build-time) relocatable, following FHS-style classifications. > Maintain the README, NEWS, INSTALL, ChangeLog, etc. We users actually do read > them, and up to date metadata gives us a warm fuzzy where we feel good about > your code Well, separate changelog (beside the vcs' log) should only be required for large packages. Better a releas-notes file, stating everthing that's important for upgrades. BTW: meanwhile I've set up an sf.net project w/ maillist: https://sourceforge.net/p/oss-qm/home/ cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [gentoo-user] Yahoo and strange traffic.
Joshua Murphy wrote: Yep, but... just from a glance at their bug tracker and their commits list... they made quite a few changes to the Yahoo plugin's handling of avatars and such in January that're in 4.4... so their go-to answer on Yahoo avatar related issues seems to be "Try it on 4.4, then come back if it's still broken." So... to save a little time and effort when that answer's thrown around... might be best to test with that. I don't have QT or anything that depends on it on any of my boxes (the only box I actually have X on right now's my netbook, so adding's not even a feasable option) and my yahoo account went dead a few years ago, so I'm not much use for testing. Then I guess they would have to look at the bug report then. [ebuild R ] kde-base/kopete-4.4.5-r1 USE="addbookmarks autoreplace contactnotes groupwise handbook highlight history nowlistening pipes privacy ssl statistics texteffect translator urlpicpreview yahoo zeroconf (-aqua) -debug -gadu -jabber -jingle (-kdeenablefinal) (-kdeprefix) -latex -meanwhile -msn -oscar -otr -qq -skype -sms -testbed -v4l2 -webpresence -winpopup" Since I am on 4.4.5 already, I am using their preferred version. My current fix, just close Kopete. I'll see if that keeps it from doing this. lol I bet that works too. Maybe 4.5.* will be better. Dale :-) :-)
Re: [gentoo-user] Feckless xdm not much of a manager
On 25 Aug 2010, at 04:36, Kevin O'Gorman wrote: ... My problem has been that going to /etc/init.d and commanding "./xdm stop" seems to work, but has no effect on KDE. Manually killing kde (ps -ef | grep kde, etc) just starts another one. I finally figured out that I have to find the 'kdm' process and kill that, then a logoff or Ctl_Alt_BS actually gets rid of X, so I can do things like "X -configure" and so on. If you run `/etc/init.d/xdm stop` and then log out of KDE using the logoff button in the Start Menu, what happens, please? Does xdm return? Stroller.
Re: [gentoo-user] Feckless xdm not much of a manager
On 08/25/2010 03:37 PM, Kevin O'Gorman wrote: I had more or less the opposite case -- a running daemon that was marked as stopped. Not exactly, because it was xdm marked as stopped, and kdm that was running. This problem is repeatable on my system, so I probably borked it somehow. Please accept this wild-ass guess from when my Apache instances used to do the same thing. /etc/conf.d/rc -- # Set to "yes" if start-stop-daemon should attempt to kill # any children left in the system. # Be careful with this as it really does what it was on the tin. # fex, if you're in an ssh process and you restart a service on which # ssh depends then your terminal will be killed also. RC_KILL_CHILDREN="yes"
Re: [gentoo-user] New HD monitor stretches everything. How to teach Xorg?
On Wed, Aug 25, 2010 at 1:56 PM, Kevin O'Gorman wrote: > On Wed, Aug 25, 2010 at 1:48 PM, Håkon Alstadheim < > ha...@alstadheim.priv.no> wrote: > >> Den 24. aug. 2010 04:27, skrev Kevin O'Gorman: >> >> I had to replace an 4:3 Westinghouse monitor this weekend. I got a new >>> ASUS VH242H, which is very wide. But Xorg is still running 1280x1024, >>> instead of the monitor's normal 1920x1080, according to xorg logs because of >>> lack of video memory (using the ATI on the motherboard). I can make the >>> screen use a 4:3 aspect ratio, so I'm up and running, much better than I >>> started, but I'd like to do better. >>> >>> I guess I've gotta look for a video card, but all I have is PCIX slots, >>> so I don't want to put a lot of money into it (I'll be upgrading the mobo >>> when finances permit -- which is not right now.) >>> >> >> Just did a cursory read of the entire thread here. I notice the card is on >> the mobo, did you try to see if there is a BIOS setting to increase the >> amount of video RAM? I.e enter BIOS setup during boot, and look around in >> the chip setup. >> > > Hmmm. Be right back. > > Well, it was an interesting thought, but no joy. Lots of configuration things showed up -- I didn't realize I did not have the ECC memory to alert on uncorrectable errors, so it wasn't all a waste. -- Kevin O'Gorman, PhD
Re: [gentoo-user] Is there any games base on openCL?
Sorry..I don't know how to describe it clearly, with my poor English... 2010/8/26 Volker Armin Hemmann > On Wednesday 25 August 2010, Blackdream W wrote: > > I install the ati-drivers-10.7.1 just now,this version it seem support > > openCL 1.1. > > > > Any games base on it? > > > > Thanks. > > games can not be based on opencl. Games might be able to use opencl to > speed > up certain kinds of calculations. But you can not 'use' opencl like opengl > to > base a game on it. > >
