Re: [gentoo-amd64] Re: simulating apt-get on gentoo

[James Ausmus]

On Thu, Apr 21, 2016 at 8:28 PM, Daiajo Tibdixious  wrote:
>
> Got src_install working except for mysterious (to me) problem:
> src_install () {
> into /opt
> dobin usr/bin/runescape-launcher
>
> exeinto /opt/${PN}
> doexe usr/share/games/runescape-launcher/runescape
>
> insinto /opt/${PN}
> doins usr/share/games/runescape-launcher/runescape.png
>
> insinto /usr/share/applications
> doins usr/share/applications/runescape-launcher.desktop
>
> insinto /usr/share/kde4/services
> doins usr/share/kde4/services/*.protocol

The insinto is the "to", the doins is the "from" - since the files are
installed in the image at:

/var/tmp/portage/games-rpg/RuneScape-2.2.2/image/usr/share/applications/*.protocol

they're not being found by your doins, as it's looking for them at:

/var/tmp/portage/games-rpg/RuneScape-2.2.2/image/usr/share/kde4/services/*.protocol

IOW, try:

insinto /usr/share/kde4/services
doins usr/share/applications/*.protocol

>
> dodoc usr/share/doc/runescape-launcher/changelog.gz
>
> #   usr/share/doc/runescape-launcher/copyright
>
> for size in 16 24 32 48 64 256 512; do
> doicon -s ${size}
> usr/share/icons/hicolor/${size}x${size}/apps/runescape.png
> done
> }
>
> Everything works fine except for the 2 protocol files:
> # find /var/tmp/portage/games-rpg/RuneScape-2.2.2/image -name "*.protocol"
> /var/tmp/portage/games-rpg/RuneScape-2.2.2/image/usr/share/applications/rs-launchs.protocol
> /var/tmp/portage/games-rpg/RuneScape-2.2.2/image/usr/share/applications/rs-launch.protocol
>
> Despite saying insinto kde4 services, they go into applications, which
> is the previous location.
>
> On Thu, Apr 21, 2016 at 12:58 PM, Daiajo Tibdixious  wrote:
> > Thanks very much for that. I managed to get the fetch & unpack
> > working, but nothing
> > I tried for src_install worked, and your code is much neater than mine.
> >
> > On Thu, Apr 21, 2016 at 9:59 AM, Jonathan Callen  wrote:
> >> On 04/18/2016 10:11 PM, Daiajo Tibdixious wrote:
> >>> dpkg has a native gentoo version app-arch/dpkg but dpkg --unpack gave an 
> >>> error.
> >>> However ar x worked fine.
> >>> Ended up with usr/bin/runescape-launcher which is fine, but also
> >>> usr/share stuff which I'll check for collisions.
> >>> (this is all in /var/tmp)
> >>>
> >>> Thanks very much, you saved me much trouble.
> >>>
> >>> Not sure if its just me, but apt is written in c++ using mostly C
> >>> constructs, and doesn't seem to have been through an oo design.
> >>> Makes it very weird to try to follow.
> >>>
> >>> I won't be able to install/run it today due to being busy.
> >>>
> >>
> >> Attached is my attempt at a proper ebuild for this package.  The
> >> dependencies are based on what the deps *should* have been, not what the
> >> .deb actually declares.  I haven't actually tested this fully.
> >>
> >> --
> >> Jonathan Callen
>

Re: [gentoo-amd64] intel processors x gentoo

[James Ausmus]

On Tue, Sep 28, 2010 at 10:03 AM, Zhu Sha Zang zhushaz...@yahoo.com.br wrote:
 I have some machines running gentoo and every machine running under AMD
 Processors (64-bit profile), everything is right. Every source code compile
 fine.

 But, some machines, i've installed under Intel Core 2 Quad or i7 processor
 and this machines have problem compile especific 2 packages:

 glibc (=2.11.2) and lvm2 (2.02.73-r1)

 It's weird, don't compile in any intel processor machine.

 Take a example of emerge --info uner i7 machine.

snip
 Some hint!?


Hard to diagnose without an exact compile error - please copy the
error from the actual compilation.

Thanks!

-James

Re: [gentoo-amd64] Where is '@system'?

[James Ausmus]

To see bare system, do:
USE=-* emerge -pev @system

On Mar 4, 2010 6:02 PM, Mark Knecht markkne...@gmail.com wrote:

On Thu, Mar 4, 2010 at 3:23 PM, Paul Hartman

paul.hartman+gen...@gmail.com paul.hartman%2bgen...@gmail.com wrote:
 On Thu, Mar 4, 2010 at 4:23 PM, Mark Knecht markkne...@gma...
Yeah, that's interesting and to some extent anyway probably involved
with why I'm getting a lot of the package I get. What I'm not
understanding yet is what packages themselves are in @system. Where do
those come from? I'm assuming that because of all these flags some
system packages then require more and more support packages as an
avalance, but I'm not understanding what list of packages gets the
whole things started.

@world is /var/lib/portage/world.

@system is ?

Thanks,
Mark

Re: [gentoo-amd64] Failure updating to gdbm-1.8.3-r4

[James Ausmus]

On Mon, Jan 18, 2010 at 12:37 PM, Daniel Dilts dilts.dan...@gmail.comwrote:

 I'm running the no-multilib version of gentoo-amd64 on a Core2 duo.
 When I try to run emerge --update --deep --newuse world I get the following
 error:


snip


 * If you need support, post the topmost build error, and the call stack if
 relevant.


snip

Please do as the error message suggests, and post the topmost build error -
the info you posted does not contain anything that can help root cause the
issue.

Thanks!

-James

Re: [gentoo-amd64] Failure updating to gdbm-1.8.3-r4

[James Ausmus]

On Mon, Jan 18, 2010 at 12:50 PM, Daniel Dilts dilts.dan...@gmail.comwrote:

 I'm running the no-multilib version of gentoo-amd64 on a Core2 duo.
 When I try to run emerge --update --deep --newuse world I get the
 following error:


 snip


 * If you need support, post the topmost build error, and the call stack if
 relevant.


 snip

 Please do as the error message suggests, and post the topmost build error -
 the info you posted does not contain anything that can help root cause the
 issue.


 The only other error type thing I can find (didn't find it before because
 of vim's default case sensitive search) is:

 mv -f .libs/gdbmfetch.lo gdbmfetch.lo
 make: *** [gdbmdelete.lo] Error 1
 make: *** Waiting for unfinished jobs
 mv -f .libs/gdbmopen.lo gdbmopen.lo

 Followed immediately by the last bit that I posted.


Hmm, it looks like it might still be higher up than that - try just visually
scanning upwards a bit from that point (it can actually be quite a bit
higher, if there are multiple make jobs running in parallel - ie.
MAKEOPTS=-j2 or more). Alternately, attach the build log, and we can take
a look through it. :)

-James

Re: [gentoo-amd64] New video card, finally!

[James Ausmus]

Congrats on the new HW!

On Dec 9, 2009 6:00 PM, Duncan 1i5t5.dun...@cox.net wrote:

As regulars are aware, I /was/ running an old Radeon 92xx series card,
r200 series chip.  My system was /relatively/ good, even if it's half a
decade old now, because it's a dual socket Opteron, which I had upgraded
to top-of-the-line dual-core Opteron 290s (2.8 GHz), with plenty of
memory (8 gigs, tho it's now six as a stick went bad on me and I've not
replaced it yet), and running four SATA drives in md/kernel RAID.

Well, a few weeks ago I switched the system partitions from RAID-6 to
RAID-1.  In many tasks the RAID-1 is actually faster than the RAID-6 was,
tho part of that might be that the new partitions aren't fragmented,
yet.  While I was at it, I rid myself of the LVM2 layer I was running
most of the non-rootfs system on.  No real issues with it here, but it
was a bit of a hassle since I couldn't put the rootfs on it directly, and
I have seen some horror stories I didn't like, tho whether they're
accurate on the current LVM2 I don't know.  But anyway, I decided that
layer was more hassle than it was worth, and experience with the new
layout so far says I was right.

But that just lays the groundwork for the REAL upgrade.  I FINALLY got
the video card upgrade that I'd been needing for awhile, thus bringing it
more inline with the rest of the system.  It's a Radeon hd4650, rv730
chip, gig video RAM (tho I have a feeling I'm not using anything near
that), dual DVI output (I'm not sure if both are dual-link tho, might be
one dual-link and one single-link), AGP bus as that's what my system is
-- five years old, remember, I have PCI-X but not PCI-E.

Of course, the xorg native xf86-video-ati driver (and xf86-video-
radeonhd, tho that seems to be falling behind now, unless you have HDMI
you want to support or something) only have 2D for anything r600 or newer
in their released drivers, thru the 6.12 series (with 6.12.4 being the
latest, and a possible 6.12.5 coming up).  There's not even a beta
tarball out for the 6.13 series yet, so if one wants OpenGL support,
really the whole point to the upgrade, one has to run the live driver,
straight from git or available in the x11 overlay as the traditional live
version .

So that's what I grabbed.  I already had the latest non-live xorg
components installed from the tree and x11 overlay, so I was fortunate
and didn't need any further live packages, only xf86-video-ati-.

Meanwhile, I basically gave up on the kernel bug I was git-bisecting, as
I couldn't duplicate it on the (then still unaccelerated) new radeon
hardware, tho I saved a bisect-log in case it comes back with the new
hardware after I enable acceleration, git-pulled, did a git-checkout of
v2.6.32 (Linus git tree), did the usual oldconfig, then a menuconfig and
changed my config around a bit, enabling KMS, etc.

Did a reboot into the new kernel and played around at the radeondrmfb
enhanced CLI for awhile, tweaking a couple things there, then started X/
kde4 and started tweaking things for the new hardware, there.

After editing xorg.conf and restarting X a few times, playing with
glxgears, etc, I started trying out the newly available kde4 OpenGL eye
candy options. =:^)  As I run dual 22 1920x1200 LCDs, stacked for
1920x2400, and the old card couldn't handle OpenGL at resolutions above
2048 either direction, I hadn't had the OpenGL effects available to play
with on the old card.  What a change the new card made! =:^)

So now I'm running kde 4.3.4 with OpenGL effects.  It's nice.  I've
actually had the snow on the desktop effect turned on as I worked, for
several hours now, tweaked a bit to add more flakes but reduce the size
to make them a bit more realistic, and with the behind windows option
turned off, so they float in front of the windows.  Much like watching
real snow fall outside the window while you're nice and warm inside, it's
quite a calming effect.

OTOH, there's still enough glitches to see why it's not released yet, and
I did have one crash.  Also, font anti-aliasing /really/ looks bad now,
it's /gotta/ be a bug somewhere I'm sure, so I turned off font anti-
aliasing entirely.  MUCH better!  With that, it's working well enough to
be usable if a few visual glitches, mostly background repaints turning
bits of the plasma panels and desktop weird colors at times, which goes
away with desktop switches, etc, but also a semi-regular flashing of bits
of one particular corner of the desktop, and artifacts appearing on
scrollbars and the like occasionally.  But it's good enough I've no
intention of going back, even if the driver code is unoptimized at
present and the snow makes new launches rather less than responsive!  But
I can always turn the snow bit off, if I want, and have a reasonably
responsive system with the other effects still.

So now I suppose I'm experiencing kde4 as it was meant to be seen, fully
accelerated opengl effects, cube desktop switching, snow on the desktop,
wobbly windows (which 

Re: [gentoo-amd64] Re: Hurray! Radeon KMS in 2.6.31

[James Ausmus]

On Wed, Jun 17, 2009 at 11:02 AM, Nikos Chantziaras rea...@arcor.de wrote:

 On 06/17/2009 08:35 PM, Mark Knecht wrote:

 Good stuff.

 So guessing about the path:

 1) Kernel get KMS.
 2) Xorg-X11 develops and tests for awhile. (probably on-going now?)


 Yup, it's working already because Intel graphics chips already had KMS for
 a while now.  It's already in Ubuntu and Fedora (though not enabled by
 default, I think.)


Just as a note - the Radeon KMS uses a different implementation path than
the Intel KMS - Intel, in the kernel, uses GEM for gfx memory management,
while Radeon (and Nouveau, and other upcoming) use the new TTM (which is
also new for .31) - I don't *think* this will affect how X interfaces with
the kernel driver, but, since TTM is newer than GEM (GEM/Intel KMS happened
in .29), it might still be a little bit before the wrinkles are worked out.
As far as the X server interfacing with the new kernel driver, I *believe*
that pretty much all the action behind the scenes happens in the X driver
itself, with the X server being pretty much unaware of the change (please
feel free to correct me if I'm wrong), so, just because the Intel driver has
already been utilizing the KMS kernel interface for a little while, doesn't
necessarily mean that it will make the Radeon X driver transition any
smoother/better/shorter.






  3) Gentoo devs and bleeding edge users play with it for awhile.
 4) Shows up in portage under ~amd64 (Is that the same as ~arch for AMD64?)


 ~arch means the same regardless of architecture ;)  It's ~x86 for
 IBM/Intel 32-bit systems, ~amd64 for AMD64, ~ppc for PowerPCs, etc.


  5) More bleeding edge users play with it
 6) Becomes stable
 7) I get it.

 What's that? About 1-2 years or something?


 Probably sooner.  New X.Org releases will hit stable portage much sooner
 then it took for 1.5 to arrive since the jump from 1.3 to 1.5 was much
 harder than the future jump from 1.5 to 1.6.


Dunno - X server 1.6 has been out for quite a while (several months - X
server 1.7 is due out in just about 1.5 months at this point), and it just
very recently hit the portage ~ tree (not that I'm complaining Devs - I
understand that there were issues that would've bit lots of users), so it
might be a while before you see Radeon KMS support in the fully stable
portage tree - don't hold your breath quite yet. ;) Of course, if your
system isn't mission-critical, you could always install the - versions,
or at least the ~ versions when they hit, and help move along the
debugging/stabilization process, so that they hit the stable tree faster...
;)





  None the less, sounds like quite a nice improvement. I've had LOTS of
 times where going back and forth between console and X hasn't been
 perfect, and I certainly don't like the annoying blinks, etc.


 Switching to a VT instantly (and it's really *instant*; it's like switching
 to another virtual desktop) is the most important feature for me.  Running X
 as user comes next.  The boot thingy isn't important at all to me.
  Unfortunately, it will be a whole while for me to get it since I'm on a
 Radeon HD4870 which is not supported by any open source drivers at all right
 now.


Having run the Intel KMS kernel/fbcon/X driver for a little while now, I can
say that 2 things *really* stand out to me (at least from my usage model):

1. Native framebuffer console resolution on my 1680x1050 widescreen LCD - no
more 1280x1024 stretched! (Actually not sure if this is directly due to the
kernel updates for Intel/KMS, or just happened to happen at the same time,
but still - Yay!)
2. Perfectly fast X/virtual console switching - I mean - Wow! I still, from
time to time, just sit there switching between the two a couple times just
to watch the speed and smoothness - it's amazing...

-James

Re: [gentoo-amd64] Are ECC ram worth buying?

[James Ausmus]

On 8/19/07, P.V.Anthony [EMAIL PROTECTED] wrote:
 On this day, 20-August-2007 11:30 AM,  P.V.Anthony wrote:

  Need some advice on ECC ram.
 
  Should I buy ECC rams for a web email and database server?
 
  The reason for asking is that ECC rams are really expensive. Need to
  know if it is worth getting them or are they just hype. Especially for
  the kind of use I am talking about.

 Sorry for wasting bandwidth by sending the above email. Should have done
 a google search first.

 Found a informative site.
 http://www.memorysuppliers.com/eccwhatisita.html

 So I better buy the ECC rams. :(


Before you do, make sure your motherboard supports ECC memory,
otherwise you'll just be wasting your money...

-James



 P.V.Anthony

 --
 [EMAIL PROTECTED] mailing list


-- 
[EMAIL PROTECTED] mailing list

Re: [gentoo-amd64] twinview

[James Ausmus]

On 3/4/07, list-catcher [EMAIL PROTECTED] wrote:

Does anyone use twinview to run two monitors at different resolutions?

I've got two monitors one on top of the other with the lower
resolutioned one on top.  The one on top (lower resolution) has a dead
area where the window manager/X thinks exists but doesn't show.
Sometimes the window manager will put windows there that I can't see.



I had a difficult time getting my twinview settings set up correctly
for my laptop, until I emerged nvidia-settings, and used it to
configure it just right - it makes it fairly simple to do - I'd
suggest just giving that a try. You can get it set up just right, then
either have the nvidia-settings application save the configuration to
your xorg.conf file, or just show you what that xorg.conf file would
look like, so you can cut and paste.

HTH-

James
--
gentoo-amd64@gentoo.org mailing list