Re: [gentoo-user] Re: XFCE weather plugin does not work
On 10/18/2014 02:37 AM, David W Noon wrote: I have prepared some patches from the Xfce repository with line addressing to match the Gentoo sources tarball. I attach a tarball of theses patches that can be untarred in /etc/portage/patches/ applied. thank you
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Fri, 17 Oct 2014 23:37:16 +0100
David W Noon dwn...@ntlworld.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 17 Oct 2014 22:33:45 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141017223345.16c96...@digimed.co.uk):
On Fri, 17 Oct 2014 21:13:52 + (UTC), James wrote:
And last, can any patch that ends in .patch be applied to the
intended ebuild or does the gentoo ebuild auther have to put some
special code into an (EAPI-5) ebuild to facilitate user patches?
AFAIR the ebuild simply has to call epatch_user() in src_unpack()
and any matching patches in /etc/portage/patches are applied.
The usual place is src_prepare().
I have prepared some patches from the Xfce repository with line
addressing to match the Gentoo sources tarball. I attach a tarball of
theses patches that can be untarred in /etc/portage/patches/.
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world
instead of # emerge xfce4-weather-plugin
did not worked.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlRBmhwACgkQRQ2Fs59Psv8YHgCghXa931NC2rJSa8394L2FvZGB
UIAAoIiiIpd7PktyaQE9Av/RxRYjnLE0
=68v7
-END PGP SIGNATURE-
Re: [gentoo-user] [OT] Routing Problems
On Saturday 18 Oct 2014 04:45:21 Alec Ten Harmsel wrote: Hey guys, This is not Gentoo-specific, but one of my roommates just replaced our router with a DD-WRT routers. For the most part, everything is great and I love it. There's one problem, that may or may not be cause by said new router. Between my desktop and my server, I can not ping/SSH/whatever. The ARP request never gets resolved. Every other connection between any other pair of machines works, just not desktop to server and vice versa. The only stuff I could find on Google (which is mainly a front for searching stackoverflow) is that it's a MAC collision (it's not) or that it's a hardware problem (which I guess it may be, although I've tried numerous permutations). If anyone has any insight, I would appreciate it. I've been banging my head against this for nearly one week now. Can you give some additional information on the network topology? Are we talking about LAN/WAN? Same subnet? VLAN? DMZ? Any firewall rules or special routing/bridging/etc.? What do the router logs say? Have you captured any packets on both ends and in between? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Sat, 18 October 2014, at 8:03 am, Gevisz gev...@gmail.com wrote: I have unpacked your patches to /etc/portage/patches as described here: http://wiki.gentoo.org/wiki//etc/portage/patches and then run # emerge xfce4-weather-plugin After restarting xfce4, the weather-plugin started to work. Thank you. Nevertheless, just # emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world instead of # emerge xfce4-weather-plugin did not worked. I think that's because the ebuild's version number didn't change. Hence the package wasn't included when you told portage to run an update - when you told portage explicitly to install the latest xfce4-weather-plugin it found the patches. Stroller.
[gentoo-user] An alternative keyboard layout is lost
This is the continuation from the thread
XFCE weather plugin does not work
2014-10-18 10:03 GMT+03:00 Gevisz gev...@gmail.com:
On Fri, 17 Oct 2014 23:37:16 +0100
David W Noon dwn...@ntlworld.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 17 Oct 2014 22:33:45 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141017223345.16c96...@digimed.co.uk):
On Fri, 17 Oct 2014 21:13:52 + (UTC), James wrote:
And last, can any patch that ends in .patch be applied to the
intended ebuild or does the gentoo ebuild auther have to put some
special code into an (EAPI-5) ebuild to facilitate user patches?
AFAIR the ebuild simply has to call epatch_user() in src_unpack()
and any matching patches in /etc/portage/patches are applied.
The usual place is src_prepare().
I have prepared some patches from the Xfce repository with line
addressing to match the Gentoo sources tarball. I attach a tarball of
theses patches that can be untarred in /etc/portage/patches/.
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world
instead of # emerge xfce4-weather-plugin
did not worked.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
Just after emerging xfce4-weather-plugin with the patches
provided by David W Noon, I have noticed that I lost all my
alternative keyboard layouts.
I tried to set them anew via xfce4 Keyboard Layouts Plugin
version 0.5.6 but there is no keyboard layout that suits my
keyboard.
Unfortunately, unmerging xfce4-weather-plugin did not help.
Another thing I did just before re-emerging xfce4-weather-plugin
was a routine system update. This time only net-dns/libidn package
was updated from version 1.28 to version 1.29, and before that
update my alternative keyboard layouts were still present, as
I remember using them just after the update but before rebooting
the system.
So, it also may be that updating libidn package caused the damage.
I remember that, while installing Gentoo about 15 months ago,
I set my keyboard layout not via an xfce4 plugin but somewhere
in the X11 settings. (At that time I had gnome2 instead of xfce4 anyway).
So, may be now, re-emerging xfce4-weather-plugin, or trying
to set the alternative keyboard layout anew, I have created some
xfce4 configuration file that shadows X11 (or old gnome2) settings
that xfce4 used for keyboard layout previously.
Any thoughts?
Re: [gentoo-user] An alternative keyboard layout is lost
On Saturday 18 Oct 2014 09:34:53 gevisz wrote:
This is the continuation from the thread
XFCE weather plugin does not work
2014-10-18 10:03 GMT+03:00 Gevisz gev...@gmail.com:
On Fri, 17 Oct 2014 23:37:16 +0100
David W Noon dwn...@ntlworld.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 17 Oct 2014 22:33:45 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141017223345.16c96...@digimed.co.uk):
On Fri, 17 Oct 2014 21:13:52 + (UTC), James wrote:
And last, can any patch that ends in .patch be applied to the
intended ebuild or does the gentoo ebuild auther have to put some
special code into an (EAPI-5) ebuild to facilitate user patches?
AFAIR the ebuild simply has to call epatch_user() in src_unpack()
and any matching patches in /etc/portage/patches are applied.
The usual place is src_prepare().
I have prepared some patches from the Xfce repository with line
addressing to match the Gentoo sources tarball. I attach a tarball of
theses patches that can be untarred in /etc/portage/patches/.
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
world instead of # emerge xfce4-weather-plugin
did not worked.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
Just after emerging xfce4-weather-plugin with the patches
provided by David W Noon, I have noticed that I lost all my
alternative keyboard layouts.
I tried to set them anew via xfce4 Keyboard Layouts Plugin
version 0.5.6 but there is no keyboard layout that suits my
keyboard.
Unfortunately, unmerging xfce4-weather-plugin did not help.
Another thing I did just before re-emerging xfce4-weather-plugin
was a routine system update. This time only net-dns/libidn package
was updated from version 1.28 to version 1.29, and before that
update my alternative keyboard layouts were still present, as
I remember using them just after the update but before rebooting
the system.
So, it also may be that updating libidn package caused the damage.
I remember that, while installing Gentoo about 15 months ago,
I set my keyboard layout not via an xfce4 plugin but somewhere
in the X11 settings. (At that time I had gnome2 instead of xfce4 anyway).
So, may be now, re-emerging xfce4-weather-plugin, or trying
to set the alternative keyboard layout anew, I have created some
xfce4 configuration file that shadows X11 (or old gnome2) settings
that xfce4 used for keyboard layout previously.
Any thoughts?
I think you are referring to the XkbLayout. In /etc/X11/xorg.conf.d/10-
evdev.conf you can add a section like so with the keyboard languages of your
choice:
Section InputClass
Identifier evdev keyboard catchall
MatchIsKeyboard on
MatchDevicePath /dev/input/event*
Driver evdev
Option XkbLayout gb,el
Option XkbOptions
grp:alt_shift_toggle,grp_led:scroll,compose:menu,terminate:ctrl_alt_bksp
EndSection
--
Regards,
Mick
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] An alternative keyboard layout is lost
On Sat, 18 Oct 2014 10:12:29 +0100
Mick michaelkintz...@gmail.com wrote:
On Saturday 18 Oct 2014 09:34:53 gevisz wrote:
This is the continuation from the thread
XFCE weather plugin does not work
2014-10-18 10:03 GMT+03:00 Gevisz gev...@gmail.com:
On Fri, 17 Oct 2014 23:37:16 +0100
David W Noon dwn...@ntlworld.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 17 Oct 2014 22:33:45 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141017223345.16c96...@digimed.co.uk):
On Fri, 17 Oct 2014 21:13:52 + (UTC), James wrote:
And last, can any patch that ends in .patch be applied to the
intended ebuild or does the gentoo ebuild auther have to put some
special code into an (EAPI-5) ebuild to facilitate user patches?
AFAIR the ebuild simply has to call epatch_user() in src_unpack()
and any matching patches in /etc/portage/patches are applied.
The usual place is src_prepare().
I have prepared some patches from the Xfce repository with line
addressing to match the Gentoo sources tarball. I attach a tarball of
theses patches that can be untarred in /etc/portage/patches/.
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask
world instead of # emerge xfce4-weather-plugin
did not worked.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
Just after emerging xfce4-weather-plugin with the patches
provided by David W Noon, I have noticed that I lost all my
alternative keyboard layouts.
I tried to set them anew via xfce4 Keyboard Layouts Plugin
version 0.5.6 but there is no keyboard layout that suits my
keyboard.
Unfortunately, unmerging xfce4-weather-plugin did not help.
Another thing I did just before re-emerging xfce4-weather-plugin
was a routine system update. This time only net-dns/libidn package
was updated from version 1.28 to version 1.29, and before that
update my alternative keyboard layouts were still present, as
I remember using them just after the update but before rebooting
the system.
So, it also may be that updating libidn package caused the damage.
I remember that, while installing Gentoo about 15 months ago,
I set my keyboard layout not via an xfce4 plugin but somewhere
in the X11 settings. (At that time I had gnome2 instead of xfce4 anyway).
So, may be now, re-emerging xfce4-weather-plugin, or trying
to set the alternative keyboard layout anew, I have created some
xfce4 configuration file that shadows X11 (or old gnome2) settings
that xfce4 used for keyboard layout previously.
Any thoughts?
I think you are referring to the XkbLayout. In /etc/X11/xorg.conf.d/10-
evdev.conf you can add a section like so with the keyboard languages of your
choice:
Section InputClass
Identifier evdev keyboard catchall
MatchIsKeyboard on
MatchDevicePath /dev/input/event*
Driver evdev
Option XkbLayout gb,el
Option XkbOptions
grp:alt_shift_toggle,grp_led:scroll,compose:menu,terminate:ctrl_alt_bksp
EndSection
Yes, something like that. But I have no /etc/X11/xorg.conf.d/ directory.
So, I did that configuration in another file.
But the problem is that I have not changed anything related to the keyboard
layout just before my alternative keyboard layouts disappeared.
[gentoo-user] Re: An alternative keyboard layout is lost
2014-10-18 11:34 GMT+03:00 gevisz gev...@gmail.com:
This is the continuation from the thread
XFCE weather plugin does not work
2014-10-18 10:03 GMT+03:00 Gevisz gev...@gmail.com:
On Fri, 17 Oct 2014 23:37:16 +0100
David W Noon dwn...@ntlworld.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 17 Oct 2014 22:33:45 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141017223345.16c96...@digimed.co.uk):
On Fri, 17 Oct 2014 21:13:52 + (UTC), James wrote:
And last, can any patch that ends in .patch be applied to the
intended ebuild or does the gentoo ebuild auther have to put some
special code into an (EAPI-5) ebuild to facilitate user patches?
AFAIR the ebuild simply has to call epatch_user() in src_unpack()
and any matching patches in /etc/portage/patches are applied.
The usual place is src_prepare().
I have prepared some patches from the Xfce repository with line
addressing to match the Gentoo sources tarball. I attach a tarball of
theses patches that can be untarred in /etc/portage/patches/.
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world
instead of # emerge xfce4-weather-plugin
did not worked.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
Just after emerging xfce4-weather-plugin with the patches
provided by David W Noon, I have noticed that I lost all my
alternative keyboard layouts.
I tried to set them anew via xfce4 Keyboard Layouts Plugin
version 0.5.6 but there is no keyboard layout that suits my
keyboard.
Unfortunately, unmerging xfce4-weather-plugin did not help.
Another thing I did just before re-emerging xfce4-weather-plugin
was a routine system update. This time only net-dns/libidn package
was updated from version 1.28 to version 1.29, and before that
update my alternative keyboard layouts were still present, as
I remember using them just after the update but before rebooting
the system.
So, it also may be that updating libidn package caused the damage.
I remember that, while installing Gentoo about 15 months ago,
I set my keyboard layout not via an xfce4 plugin but somewhere
in the X11 settings. (At that time I had gnome2 instead of xfce4 anyway).
So, may be now, re-emerging xfce4-weather-plugin, or trying
to set the alternative keyboard layout anew, I have created some
xfce4 configuration file that shadows X11 (or old gnome2) settings
that xfce4 used for keyboard layout previously.
Any thoughts?
I have found out that my problem with xfce4 keyboard plugin
reduces to the fact that now I cannot choose Russian Winkeys
alternative keyboard: there is no such option in the corresponding
keyboard layout settings. So, I have to choose Osetinian Winkeys
alternative keyboard as it is appears to be the next best choice:
only one extra unnecessary letter ӕ in place of э and the letter
э is set in another easy to remember position.
But everything worked perfect before emerging xfce4-weather-plugin
with patches and libidn!
Re: [gentoo-user] kernel 3.17.0
On 18/10/2014 06:17, Philip Webb wrote: I just installed Kernel 3.17.0 (gentoo-sources) noticed there are specific options for Gentoo right at the beginning. Are we really privileged to have our own place in kernel-land or have these been added by the Gentoo devs ? The latter. They've also been there for a rather long time already, perhaps as much as a year :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Trying to set up HP printer with foo2zjs
On Sat, Oct 18, 2014 at 03:02:59AM +, James wrote: Frank Steinmetzger Warp_7 at gmx.de writes: I am trying to set up an HP LaserJet 1000 printer with foo2zjs. I had been using hplip in the past (which did work), but for several (mostly non- techical) reasons, I don’t want to use that. I was happy with foo2zjs back in the day when it was still “stable” in portage. cups + hplip is pretty robust. I can't quell my curiousity as to why you would not want to use that solution, paticualrly for an HP printer? Mostly because I want a minimal system. I have cups already which KDE can use, I don’t need (or want) another tool that does the same job and that has a lot of GUI stuff that my printer doesn’t support anyway (scanners and such). Furthermore, it installs a tool which I don’t need and pollutes my tray and which has no off-switch. Tries to deactivate it in the past had not succeeded (as I said, non-technical reasons). Also, with every update it wants to download the proprietary plugin anew (which I had trouble with in the past b/c I did offline updates) or else no printo worko. Lastly, this plugin installation doesn’t work if system python was not version 2, so every time I had to eselect python 2, install hplip, and switch back again. You may certainly call me backward minded, but it worked in the past[TM] without hplip, and I would like that again. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. There are those and those. But there are more of those than those. signature.asc Description: Digital signature
[gentoo-user] Re: [OT] Routing Problems
Alec Ten Harmsel alec at alectenharmsel.com writes: This is not Gentoo-specific, but one of my roommates just replaced our router with a DD-WRT routers. For the most part, everything is great and I love it. There's one problem, that may or may not be cause by said new router. Between my desktop and my server, I can not ping/SSH/whatever. The ARP request never gets resolved. Every other connection between any other pair of machines works, just not desktop to server and vice versa. First simple thing. Make sure your pc is in the arp tables for the router. Log into the router, however, and just ping your unresponsive manchine: You shlould be able to just run the 'arp' command: # arp In fact run that command from several nix machines. If it is not in your dd-wrt OS, then research how to add it or route the router with a similar (embedded) OS hth, James
[gentoo-user] Re: Trying to set up HP printer with foo2zjs
Frank Steinmetzger Warp_7 at gmx.de writes: cups + hplip is pretty robust. Mostly because I want a minimal system. I have cups already which KDE can use, I don’t need (or want) another tool that does the same job and that has a lot of GUI stuff that my printer doesn’t support anyway (scanners and such). hey, I run LXDE, and as folks know, I am a minimalist, despite have several machines with 8 core, 32 gigs of ram. So you have compiled these before, with a minimum of flags activated? The know the number of flags, the smaller the binaries. (as you know). Furthermore, it installs a tool which I don’t need and pollutes my tray and which has no off-switch. Tries to deactivate it in the past had not succeeded (as I said, non-technical reasons). Ah, kde frustration? Been there, left that constant_change environment. Personally, I would not use kde as part of my printing solution. Cups + hplip work fine without kde involvement. Also, with every update it wants to download the proprietary plugin anew (which I had trouble with in the past b/c I did offline updates) or else no printo worko. OK, so mask the offending codes? Lastly, this plugin installation doesn’t work if system python was not version 2, so every time I had to eselect python 2, install hplip, and switch back again. Weird. I have python 3.3 set and it is fine? Ok, set hplip to use the latest (stable) version of python 2.x only. You may certainly call me backward minded, but it worked in the past[TM] without hplip, and I would like that again. Frank, I would not call you this. I enjoy running minimal systems too. Did you have a ppd file setup via cups? (/etc/cups/ppd) YOu mave have a copy of the old ppd config file in the cups/ppd dir? There are a myriad of ways to set up printing. It is your choice. If you go with somethhing nobody knows about, your most likely will be 'alone', imho. What is your computer-printer interface? (usb/eth/par/ser/rf)? Do have sys-apps/hwids installed? With hplip, I only set these flags: X hpcups libnotify, but my printer is ethernet. On a side note, you may want to try lxqt-0.8.0 in a few weeks, when it is released. James
Re: [gentoo-user] Re: Trying to set up HP printer with foo2zjs
On Sat, 18 Oct 2014 14:02:28 +0200, Frank Steinmetzger wrote:
cups + hplip is pretty robust. I can't quell my curiousity as to
why you would not want to use that solution, paticualrly for an
HP printer?
Mostly because I want a minimal system. I have cups already which KDE
can use, I don’t need (or want) another tool that does the same job and
that has a lot of GUI stuff that my printer doesn’t support anyway
(scanners and such).
We have these things called USE flags...
eix hplip
* net-print/hplip
Available versions: 3.14.1 (~)3.14.6 (~)3.14.10 {X doc fax +hpcups
hpijs kde libnotify -libusb0 minimal parport policykit qt4 scanner
snmp static-ppds}
--
Neil Bothwick
Always remember you're unique, just like everyone else.
signature.asc
Description: PGP signature
Re: [gentoo-user] [OT] Routing Problems
On 10/18/2014 04:06 AM, Mick wrote: Can you give some additional information on the network topology? Are we talking about LAN/WAN? Same subnet? VLAN? DMZ? It's a LAN. Just a simple TP-Link router setup to do DHCP. No VLAN, no DMZ, only one subnet 192.168.0.0/24. It's at my apartment, so nothing fancy. Any firewall rules or special routing/bridging/etc.? Firewall is disabled on the server (CentOS) and my desktop. No special routing or bridging. What do the router logs say? DD-WRT is not very informative. It only has system-type stuff in /var/log/messages, nothing LAN-related. Have you captured any packets on both ends and in between? Capturing packets on my desktop shows strange behavior. When I ping my server (kwopper), my desktop (greenbeast) starts generating a bunch of ARPs, none of which get answered. When my laptop pings kwopper, the first ARP is answered instantly and the pings succeed. Pinging from kwopper is the same; instantly finds and connects to my laptop, but my desktop does not see any ARPs or ICMPs from kwopper. I can attach Wireshark dumps if helpful. tcpdump doesn't seem to want to work on my server for some reason. Alec
[gentoo-user] gigabyte mobo latency
Hello, OK, so I run a minimalist DE (LXDE) and htop to monitor system performance. The mobo has an fx8350 with 8 cores (currently set at 4GHz (unclocked). The system rarily uses over 8/32 gig of it's ram. So the resources are not even close to exhausted. cpus mostly idle. I do keep (2) browsers up, with tabs aplenty, but they are not being used very much. It's mostly a myriad of documents to read while I hack at code. Often the latency is minimal and the system response (as guaged) from the keyboard is fine (quick). Other times the active terminal session is a pig mostly in the web browser windows. So. Is there a make.conf setting or elsewhere to make the terminal session response times, in the browsers (seamonkey, firefox) faster? Something like a ram_disk just for the browsers? Note, after I finish up a project, many (browser) terminal sessions are deleted and things are fine again. I'm just asking for a way to ensure more ram/cpu resources are dedicated to the browsers to boost performance, on a dynamic basis (without manual intervention). Maybe a ram_disk_cache (dynamic renice to-10 for the active window?) just for the active browser window (the browser window I'm typing in? (background code compilations are not concurrent with the typing latency in the browser windows). ideas? James
Re: [gentoo-user] gigabyte mobo latency
Am 18.10.2014 um 17:49 schrieb James: Hello, OK, so I run a minimalist DE (LXDE) and htop to monitor system performance. The mobo has an fx8350 with 8 cores (currently set at 4GHz (unclocked). The system rarily uses over 8/32 gig of it's ram. So the resources are not even close to exhausted. cpus mostly idle. I do keep (2) browsers up, with tabs aplenty, but they are not being used very much. It's mostly a myriad of documents to read while I hack at code. Often the latency is minimal and the system response (as guaged) from the keyboard is fine (quick). Other times the active terminal session is a pig mostly in the web browser windows. So. Is there a make.conf setting or elsewhere to make the terminal session response times, in the browsers (seamonkey, firefox) faster? Something like a ram_disk just for the browsers? Note, after I finish up a project, many (browser) terminal sessions are deleted and things are fine again. I'm just asking for a way to ensure more ram/cpu resources are dedicated to the browsers to boost performance, on a dynamic basis (without manual intervention). Maybe a ram_disk_cache (dynamic renice to-10 for the active window?) just for the active browser window (the browser window I'm typing in? (background code compilations are not concurrent with the typing latency in the browser windows). ideas? James idea: have a look at the websites you visit. Some loadrun megabytes of javascript which bogs down everything. Nothing you can do about that except turning of js.
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Sat, 18 Oct 2014 10:03:10 +0300, Gevisz (gev...@gmail.com) wrote
about Re: [gentoo-user] Re: XFCE weather plugin does not work (in
544210d1.22a0700a.56bc.5...@mx.google.com):
On 18/10/14 08:03, Gevisz wrote:
[snip]
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
You're welcome. The Xfce developers did the hard yakka, I simply
massaged the patches so that they would apply cleanly on Gentoo systems.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world
instead of # emerge xfce4-weather-plugin
did not worked.
That's because the plugin's version/release number has not been
modified, so emerge will not process it.
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
That can be a bit variable. I still put the epatch_user command in
explicitly, just to be certain.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
If you modify the ebuild then you *must* update the manifest. If you
don't modify the ebuild then there is no need.
--
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
[gentoo-user] Re: gigabyte mobo latency
Volker Armin Hemmann volkerarmin at googlemail.com writes: idea: have a look at the websites you visit. Some loadrun megabytes of javascript which bogs down everything. Nothing you can do about that except turning of js. Well, that was it on the performance (typing latency). Still I find this very disturbing that I cannot alter some settings and de_tune javascript in browser windows that are not active? I had to diable javascript, terminate (with save) and start up seamonkey again. Obviously, there are too many things I need that use javascript, so I re-enabled javascript and terminated (a second time, with a save) the seamonkey application and start it again (now again with javascript enabled). So the problem is gone; I have seamonkey with tabs aplenty and javascript enabled again. Why can't I achieve this without manual intervention? It's not that I'm doubting what you are saying, it just seems dumb that I cannot have auto_mastery on javascript tabs that are not active. Maybe a browser plug-in? Maybe a bug/feature request to the mozilla devs? Really? curiously, James
Re: [gentoo-user] [OT] Routing Problems
On Saturday 18 Oct 2014 16:38:52 Alec Ten Harmsel wrote: On 10/18/2014 04:06 AM, Mick wrote: What do the router logs say? DD-WRT is not very informative. It only has system-type stuff in /var/log/messages, nothing LAN-related. As James suggested, if you have SSH or telnet access to the router run arp to see what the arp tables include. Also ping the server from the router to see if you get any responses. I expect that these will not reveal anything untoward, but it is best to follow a process of elimination a step at a time. Have you captured any packets on both ends and in between? Capturing packets on my desktop shows strange behavior. When I ping my server (kwopper), my desktop (greenbeast) starts generating a bunch of ARPs, none of which get answered. Only to state the obvious, that this is not the expected behaviour. Are you sure that the server firewall isn't configured to only allow connections from your laptop and/or drop arp packets to avoid arp attacks? What happens when you disable the firewall? When my laptop pings kwopper, the first ARP is answered instantly and the pings succeed. Pinging from kwopper is the same; instantly finds and connects to my laptop, but my desktop does not see any ARPs or ICMPs from kwopper. Using arpscan and arping between desktop and server you should be able to find out what is happening, but I suspect something to do with the server configuration. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] [OT] Routing Problems
Am Samstag, 18.10.2014 um 11:38 schrieb Alec Ten Harmsel a...@alectenharmsel.com: On 10/18/2014 04:06 AM, Mick wrote: Can you give some additional information on the network topology? Are we talking about LAN/WAN? Same subnet? VLAN? DMZ? It's a LAN. Just a simple TP-Link router setup to do DHCP. No VLAN, no DMZ, only one subnet 192.168.0.0/24. It's at my apartment, so nothing fancy. Check the LAN for duplicate IP's. Regards wabe
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Sat, 18 Oct 2014 17:18:34 +0100
David W Noon dwn...@ntlworld.com wrote:
On Sat, 18 Oct 2014 10:03:10 +0300, Gevisz (gev...@gmail.com) wrote
about Re: [gentoo-user] Re: XFCE weather plugin does not work (in
544210d1.22a0700a.56bc.5...@mx.google.com):
On 18/10/14 08:03, Gevisz wrote:
[snip]
I have unpacked your patches to /etc/portage/patches as described here:
http://wiki.gentoo.org/wiki//etc/portage/patches
and then run # emerge xfce4-weather-plugin
After restarting xfce4, the weather-plugin started to work. Thank you.
You're welcome. The Xfce developers did the hard yakka, I simply
massaged the patches so that they would apply cleanly on Gentoo systems.
Thank you anyway. :)
But may I ask you if applying those patches could result
in disappearing an alternative keyboard layout?
I guess not, but somehow I've got that result after updating libidn packet
and applying these patches afterwards. :(
The details are in the An alternative keyboard layout is lost thread.
Nevertheless, just
# emerge --update --deep --with-bdeps=y --newuse --backtrack=90 --ask world
instead of # emerge xfce4-weather-plugin
did not worked.
That's because the plugin's version/release number has not been
modified, so emerge will not process it.
Ok, I've got it. :)
The ebuild should have the following lines added:
src_prepare() {
epatch_user
}
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
That can be a bit variable. I still put the epatch_user command in
explicitly, just to be certain.
Don't forget to redo the manifest for the ebuild.
I never dealt with ebuilds on a maintaner level.
So, may I ask if it is really necessary and for which purpose.
If you modify the ebuild then you *must* update the manifest. If you
don't modify the ebuild then there is no need.
Do you mean that putting the patches into /etc/portage/patches/ directory
and emerging the packet does not change the corresponding ebuild?
According to my experience, it is not the case because, reemerging the
xfce4-weather-plugin with the patches deleted from /etc/portage/patches/
directory, I've still got the working plugin and, only after unmerging it
and re-emerging it again without the patches, I returned to its no-data
condition.
(But, as it did not helped me to return my alternative keyboard layout,
I re-emerged the plugin back, with the patches.)
[gentoo-user] Re: An alternative keyboard layout is lost
On Sat, 18 Oct 2014 13:10:15 +0300 gevisz gev...@gmail.com wrote: I have found out that my problem with xfce4 keyboard plugin reduces to the fact that now I cannot choose Russian Winkeys alternative keyboard: there is no such option in the corresponding keyboard layout settings. So, I have to choose Osetinian Winkeys alternative keyboard as it is appears to be the next best choice: only one extra unnecessary letter ӕ in place of э and the letter э is set in another easy to remember position. Oh, no. I was wrong! Because, in the Osetinian Winkeys keyboard layout, I cannot find letter ё. And this issue significantly slows down my work! But everything worked perfect before emerging xfce4-weather-plugin with patches and libidn!
Re: [gentoo-user] [OT] Routing Problems
On 10/18/2014 12:37 PM, Mick wrote: On Saturday 18 Oct 2014 16:38:52 Alec Ten Harmsel wrote: On 10/18/2014 04:06 AM, Mick wrote: What do the router logs say? DD-WRT is not very informative. It only has system-type stuff in /var/log/messages, nothing LAN-related. As James suggested, if you have SSH or telnet access to the router run arp to see what the arp tables include. Also ping the server from the router to see if you get any responses. I expect that these will not reveal anything untoward, but it is best to follow a process of elimination a step at a time. All fine here; pinging from router to server works, and the ARP table has entries for both desktop and server. Have you captured any packets on both ends and in between? Capturing packets on my desktop shows strange behavior. When I ping my server (kwopper), my desktop (greenbeast) starts generating a bunch of ARPs, none of which get answered. Only to state the obvious, that this is not the expected behaviour. Are you sure that the server firewall isn't configured to only allow connections from your laptop and/or drop arp packets to avoid arp attacks? What happens when you disable the firewall? Firewall is completely disabled on the server, as is SELinux. When my laptop pings kwopper, the first ARP is answered instantly and the pings succeed. Pinging from kwopper is the same; instantly finds and connects to my laptop, but my desktop does not see any ARPs or ICMPs from kwopper. Using arpscan and arping between desktop and server you should be able to find out what is happening, but I suspect something to do with the server configuration. arpscanning the entire subnet results in 3 responses, with 2 being displayed and 1 being dropped by the kernel. arpping, even with -D and -U, returns nothing. I have no idea what's going on. I think what I'm gonna do is install my old router behind the new router and plug in all my device to that one and see if it works, because I absolutely need my desktop and server to be able to reach each other. Alec
Re: [gentoo-user] XFCE weather plugin does not work
On Sat, 18 Oct 2014 20:58:40 +0300, Gevisz (gev...@gmail.com) wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work (in 5442aa74.8212980a.2836.7...@mx.google.com): On Sat, 18 Oct 2014 17:18:34 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] You're welcome. The Xfce developers did the hard yakka, I simply massaged the patches so that they would apply cleanly on Gentoo systems. Thank you anyway. :) But may I ask you if applying those patches could result in disappearing an alternative keyboard layout? There is nothing in those patches that can affect keyboard configuration. The patches only handle data received over a HTTP connection to the Norwegian Meteorological Institute. No keyboard stuff at all. If you modify the ebuild then you *must* update the manifest. If you don't modify the ebuild then there is no need. Do you mean that putting the patches into /etc/portage/patches/ directory and emerging the packet does not change the corresponding ebuild? The ebuild is a small text file that scripts the build process. The patches are external files to this process. As a result, the patches do not affect the MD5 checksum for the ebuild file in the package's manifest. According to my experience, it is not the case because, reemerging the xfce4-weather-plugin with the patches deleted from /etc/portage/patches/ directory, I've still got the working plugin and, only after unmerging it and re-emerging it again without the patches, I returned to its no-data condition. If it remained working then it was probably because you remained logged in to your Xfce desktop, which has the plugin cached inside the Xfce panel's address space. -- Regards, Dave [RLU #314465] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* dwn...@ntlworld.com (David W Noon) *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Re: [gentoo-user] [OT] Routing Problems
On 10/18/2014 02:13 PM, Alec Ten Harmsel wrote: I have no idea what's going on. I think what I'm gonna do is install my old router behind the new router and plug in all my device to that one and see if it works, because I absolutely need my desktop and server to be able to reach each other. Alec Well, this fixed it. I'm gonna stick with that. Thanks for the help. Alec
Re: [gentoo-user] Re: gigabyte mobo latency
141018 James wrote: Volker Armin Hemmann volkerarmin at googlemail.com writes: Some websites load run MB of javascript which bogs down everything. Nothing you can do about that except turning of js. Well, that was it on the performance (typing latency). I had to diable javascript, terminate + save and restart Seamonkey. Obviously, there are too many things I need that use javascript, so I re-enabled javascript and terminated (a second time, with a save) the seamonkey app and start it again (now again with javascript enabled). Perhaps you could use Lynx for those items which don't need JS reserve Firefox for those which do. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] XFCE weather plugin does not work
On Sat, 18 Oct 2014 20:07:22 +0100 David W Noon dwn...@ntlworld.com wrote: On Sat, 18 Oct 2014 20:58:40 +0300, Gevisz (gev...@gmail.com) wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work (in 5442aa74.8212980a.2836.7...@mx.google.com): On Sat, 18 Oct 2014 17:18:34 +0100 David W Noon dwn...@ntlworld.com wrote: [snip] You're welcome. The Xfce developers did the hard yakka, I simply massaged the patches so that they would apply cleanly on Gentoo systems. Thank you anyway. :) But may I ask you if applying those patches could result in disappearing an alternative keyboard layout? There is nothing in those patches that can affect keyboard configuration. The patches only handle data received over a HTTP connection to the Norwegian Meteorological Institute. No keyboard stuff at all. If you modify the ebuild then you *must* update the manifest. If you don't modify the ebuild then there is no need. Do you mean that putting the patches into /etc/portage/patches/ directory and emerging the packet does not change the corresponding ebuild? The ebuild is a small text file that scripts the build process. The patches are external files to this process. As a result, the patches do not affect the MD5 checksum for the ebuild file in the package's manifest. According to my experience, it is not the case because, reemerging the xfce4-weather-plugin with the patches deleted from /etc/portage/patches/ directory, I've still got the working plugin and, only after unmerging it and re-emerging it again without the patches, I returned to its no-data condition. If it remained working then it was probably because you remained logged in to your Xfce desktop, which has the plugin cached inside the Xfce panel's address space. May be.
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Sat, 18 Oct 2014 17:18:34 +0100, David W Noon wrote:
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
That can be a bit variable. I still put the epatch_user command in
explicitly, just to be certain.
You don't need to modify the ebuild to do that. Put this
in /etc/portage/env/category/package
post_src_unpack() {
cd ${S}
epatch_user
}
You can use unpack or prepare. The difference is that the former runs
immediately before the prepare function in the ebuild, the latter
immediately after. Not only does it save manifesting the ebuild each time
you modify it, it saves having the remember to modify it at all after an
update. More importantly, your work is not destroyed on the next sync.
--
Neil Bothwick
I can't walk on water, but I can stagger on alcohol.
signature.asc
Description: PGP signature
Re: [gentoo-user] Re: gigabyte mobo latency
Am 18.10.2014 um 21:27 schrieb Philip Webb: 141018 James wrote: Volker Armin Hemmann volkerarmin at googlemail.com writes: Some websites load run MB of javascript which bogs down everything. Nothing you can do about that except turning of js. Well, that was it on the performance (typing latency). I had to diable javascript, terminate + save and restart Seamonkey. Obviously, there are too many things I need that use javascript, so I re-enabled javascript and terminated (a second time, with a save) the seamonkey app and start it again (now again with javascript enabled). Perhaps you could use Lynx for those items which don't need JS reserve Firefox for those which do. I am sure there are some plugins to enable js on a per-page basis for firefox. If konqueror can do it...
Re: [gentoo-user] Re: gigabyte mobo latency
On Sat, 18 Oct 2014 22:24:43 +0200, Volker Armin Hemmann wrote: I am sure there are some plugins to enable js on a per-page basis for firefox. If konqueror can do it... There are several for Chromium, I think the favourite for FF is noscript. -- Neil Bothwick Top Oxymorons Number 17: Clearly misunderstood signature.asc Description: PGP signature
Re: [gentoo-user] Re: XFCE weather plugin does not work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, 18 Oct 2014 21:18:36 +0100, Neil Bothwick (n...@digimed.co.uk)
wrote about Re: [gentoo-user] Re: XFCE weather plugin does not work
(in 20141018211836.63981...@digimed.co.uk):
On Sat, 18 Oct 2014 17:18:34 +0100, David W Noon wrote:
I have not done this relying on the promise by Greg Kubaryk
that the ebuild is epatch_user enabled.
That can be a bit variable. I still put the epatch_user command
in explicitly, just to be certain.
You don't need to modify the ebuild to do that. Put this in
/etc/portage/env/category/package
post_src_unpack() { cd ${S} epatch_user }
You can use unpack or prepare. The difference is that the former
runs immediately before the prepare function in the ebuild, the
latter immediately after. Not only does it save manifesting the
ebuild each time you modify it, it saves having the remember to
modify it at all after an update. More importantly, your work is
not destroyed on the next sync.
One can also use /etc/portage/bashrc and enable epatch_user on all
ebuilds. But neither of these is what I want.
I put the src_prepare() function into the specific ebuilds that I want
to install patches, and I avoid having it in ebuilds where I don't
want patches applied. The reason for this is that I create quite a
few patches overall. Many of these are a bit flakey, so I don't want
them applied to what I view as a production system, except under
controlled circumstances. To that end, I maintain my own Portage
tree, exempted from emerge --sync, that has the epatch_user included
in its ebuilds where needed. This, in turn, allows me to keep
experimental patches in /etc/portage/patches without the threat of
them turning up in a normal emerge run.
I accept that this is not a normal user's use case, but I'm not really
a normal user.
- --
Regards,
Dave [RLU #314465]
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
dwn...@ntlworld.com (David W Noon)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlRC0oMACgkQRQ2Fs59Psv+H1ACfQ4mIJl8ie5JIwVtLwOImjOii
DTQAnR8SmAg/P/hrtcanyDHm+0K+O9z0
=iaRu
-END PGP SIGNATURE-
Re: [gentoo-user] Re: An alternative keyboard layout is lost
On Oct 18, 2014, at 21:04, Gevisz gev...@gmail.com wrote: On Sat, 18 Oct 2014 13:10:15 +0300 gevisz gev...@gmail.com wrote: I have found out that my problem with xfce4 keyboard plugin reduces to the fact that now I cannot choose Russian Winkeys alternative keyboard: there is no such option in the corresponding keyboard layout settings. So, I have to choose Osetinian Winkeys alternative keyboard as it is appears to be the next best choice: only one extra unnecessary letter ӕ in place of э and the letter э is set in another easy to remember position. Oh, no. I was wrong! Because, in the Osetinian Winkeys keyboard layout, I cannot find letter ё. And this issue significantly slows down my work! But everything worked perfect before emerging xfce4-weather-plugin with patches and libidn! Well you should configure keyboard layouts through evdev. If you update xorg-server you will need to remerge x11-drivers. So configure evdev as suggested by previous emails and then remerge x11-drivers. -- -M
Re: [gentoo-user] kernel 3.17.0
What do they do for us lucky chaps? ;-) On October 18, 2014 1:33:18 PM GMT+02:00, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/10/2014 06:17, Philip Webb wrote: I just installed Kernel 3.17.0 (gentoo-sources) noticed there are specific options for Gentoo right at the beginning. Are we really privileged to have our own place in kernel-land or have these been added by the Gentoo devs ? The latter. They've also been there for a rather long time already, perhaps as much as a year :-) -- Alan McKinnon alan.mckin...@gmail.com -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Re: [gentoo-user] kernel 3.17.0
Am 18.10.2014 um 06:17 schrieb Philip Webb: I just installed Kernel 3.17.0 (gentoo-sources) noticed there are specific options for Gentoo right at the beginning. Are we really privileged to have our own place in kernel-land or have these been added by the Gentoo devs ? and that is why I don't use gentoo-sources.
Re: [gentoo-user] gigabyte mobo latency
On 18/10/14 16:49, James wrote: Hello, OK, so I run a minimalist DE (LXDE) and htop to monitor system performance. The mobo has an fx8350 with 8 cores (currently set at 4GHz (unclocked). The system rarily uses over 8/32 gig of it's ram. So the resources are not even close to exhausted. cpus mostly idle. I do keep (2) browsers up, with tabs aplenty, but they are not being used very much. It's mostly a myriad of documents to read while I hack at code. Often the latency is minimal and the system response (as guaged) from the keyboard is fine (quick). Other times the active terminal session is a pig mostly in the web browser windows. So. Is there a make.conf setting or elsewhere to make the terminal session response times, in the browsers (seamonkey, firefox) faster? Something like a ram_disk just for the browsers? Note, after I finish up a project, many (browser) terminal sessions are deleted and things are fine again. I'm just asking for a way to ensure more ram/cpu resources are dedicated to the browsers to boost performance, on a dynamic basis (without manual intervention). Maybe a ram_disk_cache (dynamic renice to-10 for the active window?) just for the active browser window (the browser window I'm typing in? (background code compilations are not concurrent with the typing latency in the browser windows). ideas? James two things you might like to look into: 1. cgroups (including freezer) to help isolate your browsers and also 2. look at atop instead of htop as this includes disk io
[gentoo-user] Re: gigabyte mobo latency
Volker Armin Hemmann volkerarmin at googlemail.com writes: I am sure there are some plugins to enable js on a per-page basis for firefox. If konqueror can do it... Short term I'll uses this. Long term, I need to learn more about cgroups and tuning for my clustering ambitions. thx, James
[gentoo-user] Re: gigabyte mobo latency
thegeezer thegeezer at thegeezer.net writes: So. Is there a make.conf setting or elsewhere to make the terminal session response times, in the browsers (seamonkey, firefox) faster? the typing latency in the browser windows). ideas? two things you might like to look into: 1. cgroups (including freezer) to help isolate your browsers and also 2. look at atop instead of htop as this includes disk io 2. The system rarely uses 8 G of the 32 G available, so disk IO is not the problem. No heavy writes. It was the java scripts 1. Ahhh! tell me more. I found these links quickly: https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt http://wiki.gentoo.org/wiki/LXC#Freezer_Support I'm not sure if you've read any of my clustering_frustration posts over the last month or so, but cgroups is at the heart of clustering now. It seems many of the systemd based cluster solutions are having all sorts of OOM, OOM-killer etc etc issues. So any and all good information, examples and docs related to cgroups is of keen interests to me. My efforts to build up a mesos/spark cluster, center around openrc and therefore direct management of resources via cgroups. The freezer is exactly what I'm looking for. Maybe I also need to read up on lxc? What are the best ways to dynamically manage via cgroups? A gui? A static config file? a CLI tool? curiously, James
Re: [gentoo-user] kernel 3.17.0
On 18/10/2014 23:09, Stefan G. Weichinger wrote: What do they do for us lucky chaps? ;-) Read the supplied descriptions in your choice of make *config options On October 18, 2014 1:33:18 PM GMT+02:00, Alan McKinnon alan.mckin...@gmail.com wrote: On 18/10/2014 06:17, Philip Webb wrote: I just installed Kernel 3.17.0 (gentoo-sources) noticed there are specific options for Gentoo right at the beginning. Are we really privileged to have our own place in kernel-land or have these been added by the Gentoo devs ? The latter. They've also been there for a rather long time already, perhaps as much as a year :-) -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: XFCE weather plugin does not work
On Sat, 18 Oct 2014 21:50:11 +0100, David W Noon wrote: You can use unpack or prepare. The difference is that the former runs immediately before the prepare function in the ebuild, the latter immediately after. Not only does it save manifesting the ebuild each time you modify it, it saves having the remember to modify it at all after an update. More importantly, your work is not destroyed on the next sync. One can also use /etc/portage/bashrc and enable epatch_user on all ebuilds. But neither of these is what I want. I think globally enabling it in bashrc is a little too risky for me. I only use that file to register a die hook so I know when an ebuild fails. I put the src_prepare() function into the specific ebuilds that I want to install patches, and I avoid having it in ebuilds where I don't want patches applied. Isn't that the point of /etc/portage/env? You can enable what you want when you want. Either for all versions of a package or only one. I accept that this is not a normal user's use case, but I'm not really a normal user. Normal is optional, do whatever works for you. I sometimes use portage/env and sometimes copy the ebuild to my local overlay for modification. Each case is different. -- Neil Bothwick A good pun is its own reword. signature.asc Description: PGP signature
Re: [gentoo-user] Re: gigabyte mobo latency
On 18/10/14 22:51, James wrote: thegeezer thegeezer at thegeezer.net writes: So. Is there a make.conf setting or elsewhere to make the terminal session response times, in the browsers (seamonkey, firefox) faster? the typing latency in the browser windows). ideas? two things you might like to look into: 1. cgroups (including freezer) to help isolate your browsers and also 2. look at atop instead of htop as this includes disk io 2. The system rarely uses 8 G of the 32 G available, so disk IO is not the problem. No heavy writes. It was the java scripts 1. Ahhh! tell me more. I found these links quickly: https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt http://wiki.gentoo.org/wiki/LXC#Freezer_Support I'm not sure if you've read any of my clustering_frustration posts over the last month or so, but cgroups is at the heart of clustering now. It seems many of the systemd based cluster solutions are having all sorts of OOM, OOM-killer etc etc issues. So any and all good information, examples and docs related to cgroups is of keen interests to me. My efforts to build up a mesos/spark cluster, center around openrc and therefore direct management of resources via cgroups. The freezer is exactly what I'm looking for. Maybe I also need to read up on lxc? What are the best ways to dynamically manage via cgroups? A gui? A static config file? a CLI tool? curiously, James the thing with cgroups is that you can choose to create a hierarchy of what _you_ want to have as your priority unfortunately you need to tell the machine what it is you want, it can't really guess granularly iuc e.g. your favourite terminal / ide etc you want high prio and your favourite file mangler to be low prio ( assuming you want compiling to take precedence over bit munging to usb etc) there is however cgroup support in htop, and i thought that you could adjust cgroup in stead of nice but a quick google is showing that i dreamed it as a nice feature; that would be super slick as you can easily adjust all parts of program demand -- io / memory / cpu using openRC you can start services i.e. apache to have a certain priority, and ssh to have another http://wiki.gentoo.org/wiki/OpenRC/CGroups http://qnikst.github.io/posts/2013-02-20-openrc-cgroup.html the reason i suggest freezer is that you can more easily pause or CTRL-Z something that would otherwise be in a GUI and maybe not respond to SIGSTP on my laptop :- # mount | grep freez freezer on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) # cd /sys/fs/cgroup/freezer/ call the folder something meaningful # mkdir investigate # cd investigate you can use the following, i just did echo $$ for local bash pid... make sure to get all threads especially something like chrome spawns many children # ps -eLf | grep mybadapp note the single actually concatenates # echo $PID tasks to remove you actually have to move the process into a different cgroup i.e. # echo $PID /sys/fs/cgroup/freezer/tasks ok so once you have all your tasks in there just make sure you are in /sys/fs/cgroup/freezer/investigate # echo FROZEN freezer.state to thaw # echo THAWED freezer.state there is a little more here http://gentoo-en.vfose.ru/wiki/Improve_responsiveness_with_cgroups which will allow you to script creating a cgroup with the processID of an interactive shell, that you can start from to help save hunting down all the threads spawned by chrome. you can then do fun stuff with echo $$ /sys/fs/cgroup/cpu/high_priority/tasks but for your original point of maybe it's not an issue with something like IO it could still be a very high number disk reads -- low actual thoughput but the demand on the io system was high, i.e. 6zillion reads hopefully this will give you a bit more control over all of that though
[gentoo-user] Kernel 3.17.1-r1
2 more kernel problems, both solved fairly quickly. (1) Somehow, presumably in 'make menuconfig' for 3.17.0 , the real-time-clock option got unchecked, resulting in a can't find hardware clock error at start/shutdown. Perhaps it's a bug in menuconfig or perhaps the option got moved around ; since it's not new, I shouldn't have been asked about it during the dialog. (2) There's been a sudden masking of 3.17.0 in favor of 3.17.1-r1 , now successfully running my machine. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Kernel 3.17.1-r1
On Sat, Oct 18, 2014 at 8:21 PM, Philip Webb purs...@ca.inter.net wrote: (2) There's been a sudden masking of 3.17.0 in favor of 3.17.1-r1 , now successfully running my machine. Yup - the changelog mentions filesystem corruption issues but not which, and I'm too lazy to check the patches. :) However, anybody running btrfs on 3.17 should be on the lookout for 3.17.2 or deploying patches - there was a fairly nasty readonly snapshot bug in 3.17 which is tracked for the next stable kernel. The good news is that the patch prevents it from happening again, and btrfs-progs-3.17 (not yet in portage) repairs it. -- Rich
[gentoo-user] Re: gigabyte mobo latency
thegeezer thegeezer at thegeezer.net writes: there is a little more here http://gentoo-en.vfose.ru/wiki/Improve_responsiveness_with_cgroups which will allow you to script creating a cgroup with the processID of an interactive shell, that you can start from to help save hunting down all the threads spawned by chrome. you can then do fun stuff with echo $$ /sys/fs/cgroup/cpu/high_priority/tasks Yea this is cool. But when it's a cluster, with thousands of processes this seem to be limited by the manual parsing and CLI actions that are necessary for large/busy environments. (We shall see). hopefully this will give you a bit more control over all of that though Gmane mandates that the previous lines be culled. That said; you have given me much to think about, test and refine. In /sys/fs/cgroup/cpu I have: cgroup.clone_children cgroup.procs cpu.shares release_agent cgroup.event_control cgroup.sane_behavior notify_on_release tasks So I'll have to research creating and priotizing dirs like high_priority I certainly appreciate your lucid and direct explanations. Let me play with this a bit and I'll post back when I munge things up. Are there any graphical tools for adjusting and managing cgroups? Surely when I apply this to the myriad of things running on my mesos+spark cluster I'm going to need a well thoughout tool for cgroup management, particularly on memory resources organization and allocations as spark is an in_memory environment that seems sensitive to OOM issues of all sorts. thx, James
