Re: [arch-general] most efficient way to get linux kernel statistics
On 03/07/2016 09:20 PM, Damjan Georgievski wrote: > there's also `sysinfo(2)` > I didn't know there's a syscall for that. That seems like the easiest way to get memory data. I'm not sure if you can get the other information the original poster wanted without parsing /proc though. On 02/19/2016 04:01 AM, Jonathan Horacio Villatoro Córdoba wrote: > Don't worry. Actually, I understood your point perfectly. I suggested > free only because I originally supposed the OP wanted his program to > contain as little code as possible in his program, and didn't want to > parse the file himself. > OK :) .
Re: [arch-general] Htop 2.0 fonts
I had the same issue in xterm. Changing fonts didn't fix it, but switching to urxvt (with the same font) did. It seems like there's something screwy with xterm's unicode support. On Mon, Mar 7, 2016 at 12:12 AM, Grady Martin wrote: > On 2016年02月17日 00時06分, Garmine 42 wrote: > >> It was indeed a font issue, the one I used did not contain the braille >> characters. Because the same problem existed on my gettys I thought it >> was an encoding issue or something else. Using terminus font at the >> moment (as suggested) and it works perfectly fine. >> > > Well, I am glad I was not the only one affected by this. I wish there > were at least an option to decide which characters get displayed. >
Re: [arch-general] Missing Dependency virtualbox-host-dkms
On Mon, Mar 7, 2016 at 6:52 PM, Sebastiaan Lokhorst wrote: > Yes, I think that would be the best solution. Each '*-headers' package > could provide 'kernel-headers' (or something like that). > Provides does not imply conflict, so that wouldn't be a problem. > > Note that a user could still install a certain 'x-headers' which does not > match their 'y' kernel, since the headers do not depend on the kernel or > vice versa. (in the libgl case this is not a problem, since the libgl > packages depend on the matching driver) > > But I think most users who use the regular kernel and are not familiar with > other kernels would install the plain 'linux-headers' package when > prompted, and not the 'linux-lts-headers' package or something else. Now that you mention it, would it be possible to have virtualbox depend on a "virtualbox-host" fake package that both virtualbox-host-modules and virtualbox-host-dkms Provide? That way end users wouldn't need to install any headers or make dependencies, and their updates would be faster, while folks on other kernels would still be able to satisfy the dependency their own way. Or is there another reason virtualbox-host-modules was dropped as a dependency? Unfortunately, "virtualbox-host" wouldn't automatically fix anyone who's gotten into the broken state, since they'll now have virtualbox-host-dkms installed, but it won't be building any vbox* modules for them. Maybe it would be a good idea to create *both* virtual packages? If that's more work than it's worth, an Arch News post might do the trick too. But people using virtualbox-host-dkms really do require at least one kernel package, and it could be helpful to have pacman enforce that.
Re: [arch-general] most efficient way to get linux kernel statistics
On Mon, Mar 07, 2016 at 09:15:06PM +0100, Florian Pelz wrote: > Sorry, I didn't express myself properly. I didn't mean to criticize > free. What I meant to say was that the time it takes to parse > /proc/meminfo or free is negligible. It doesn't need to be any more > efficient. free parses /proc/meminfo. libgtop parses /proc/meminfo. > Querying the information probably takes much more time than parsing it. > > Your suggestion to use free may indeed be useful if the original poster > wants parsing to be slightly simpler and does not mind the additional > dependency. My impression was that they considered parsing to be too > inefficient. Don't worry. Actually, I understood your point perfectly. I suggested free only because I originally supposed the OP wanted his program to contain as little code as possible in his program, and didn't want to parse the file himself.
Re: [arch-general] Missing Dependency virtualbox-host-dkms
2016-03-08 0:10 GMT+01:00 Jack O'Connor : > > Would it be possible to depend on a "Provides" that all the different > kernel header packages share? Similar to how nvidia-libgl, > catalyst-libgl, and mesa-libgl all provide the "libgl" dependency. > That would solve the presumably-very-common case where users initially > installed virtualbox without any host headers at all, and are now > landing in a broken state by default. (Or would that mean that the > different header packages conflict where they didn't before?) Yes, I think that would be the best solution. Each '*-headers' package could provide 'kernel-headers' (or something like that). Provides does not imply conflict, so that wouldn't be a problem. Note that a user could still install a certain 'x-headers' which does not match their 'y' kernel, since the headers do not depend on the kernel or vice versa. (in the libgl case this is not a problem, since the libgl packages depend on the matching driver) But I think most users who use the regular kernel and are not familiar with other kernels would install the plain 'linux-headers' package when prompted, and not the 'linux-lts-headers' package or something else.
Re: [arch-general] Missing Dependency virtualbox-host-dkms
> I didn't force the deps to linux-headers because you could use the kernel > (linux, linux-lts, linux-zen, linux-grsec, etc) you prefer (or all together). > I will add a message with the next release of virtualbox. Would it be possible to depend on a "Provides" that all the different kernel header packages share? Similar to how nvidia-libgl, catalyst-libgl, and mesa-libgl all provide the "libgl" dependency. That would solve the presumably-very-common case where users initially installed virtualbox without any host headers at all, and are now landing in a broken state by default. (Or would that mean that the different header packages conflict where they didn't before?) - Jack
Re: [arch-general] most efficient way to get linux kernel statistics
>>> The free command gets its information from /proc/meminfo. >>> Performance-wise, it doesn't really matter if a few additional lines >>> need to be parsed. >> >> Hello, >> Thank you Florian. Actually, I already knew it's the same, I just >> thought that he could use the free command instead of parsing it >> himself. You're right. Performance-wise, it's pretty much the same. >> > > Sorry, I didn't express myself properly. I didn't mean to criticize > free. What I meant to say was that the time it takes to parse > /proc/meminfo or free is negligible. It doesn't need to be any more > efficient. free parses /proc/meminfo. libgtop parses /proc/meminfo. > Querying the information probably takes much more time than parsing it. > > Your suggestion to use free may indeed be useful if the original poster > wants parsing to be slightly simpler and does not mind the additional > dependency. My impression was that they considered parsing to be too > inefficient. there's also `sysinfo(2)` -- damjan
Re: [arch-general] most efficient way to get linux kernel statistics
On 03/07/2016 04:36 PM, Jonathan Horacio Villatoro Córdoba wrote: > On Sun, Mar 06, 2016 at 05:13:37PM +0100, Florian Pelz wrote: >> On 03/06/2016 04:47 PM, Jonathan Horacio Villatoro Córdoba wrote: >>> On Sun, Mar 06, 2016 at 03:23:33PM +0100, Andre Schmidt wrote: hello archers, thought i ask here first, before i try some kernel mailing list. i'm writing (for fun) a tiny daemon that sends linux usage (cpu, mem, net, etc.) statistics as efficiently as possible to another machine, repeatedly, to get "live" data. at the moment i'm simply sending /proc files, but they sometimes have too much data. so was wondering if there is a more efficient way to get (only parts of) the data thats available in /proc? for example, /proc/meminfo has all this info: […] if /proc is the only way to get this info, i wonder if creating a kernel module for this would be more efficient, or even possible? >>> >>> Hello Andre, >>> >>> According to what you need, you may want to use the 'free' command >>> instead, as its output is much simpler than the output of the >>> /proc/meminfo file >>> >>> […] >>> >> >> Hello, >> >> The free command gets its information from /proc/meminfo. >> Performance-wise, it doesn't really matter if a few additional lines >> need to be parsed. > > Hello, > Thank you Florian. Actually, I already knew it's the same, I just > thought that he could use the free command instead of parsing it > himself. You're right. Performance-wise, it's pretty much the same. > Sorry, I didn't express myself properly. I didn't mean to criticize free. What I meant to say was that the time it takes to parse /proc/meminfo or free is negligible. It doesn't need to be any more efficient. free parses /proc/meminfo. libgtop parses /proc/meminfo. Querying the information probably takes much more time than parsing it. Your suggestion to use free may indeed be useful if the original poster wants parsing to be slightly simpler and does not mind the additional dependency. My impression was that they considered parsing to be too inefficient.
Re: [arch-general] most efficient way to get linux kernel statistics
On Sun, Mar 06, 2016 at 05:13:37PM +0100, Florian Pelz wrote: > On 03/06/2016 04:47 PM, Jonathan Horacio Villatoro Córdoba wrote: > > On Sun, Mar 06, 2016 at 03:23:33PM +0100, Andre Schmidt wrote: > >> hello archers, > >> > >> thought i ask here first, before i try some kernel mailing list. > >> > >> i'm writing (for fun) a tiny daemon that sends linux usage (cpu, mem, net, > >> etc.) statistics as efficiently as possible to another machine, > >> repeatedly, to get "live" data. > >> > >> at the moment i'm simply sending /proc files, but they sometimes have too > >> much data. so was wondering if there is a more efficient way to get (only > >> parts of) the data thats available in /proc? > >> > >> for example, /proc/meminfo has all this info: > >> > >> […] > >> > >> if /proc is the only way to get this info, i wonder if creating a kernel > >> module for this would be more efficient, or even possible? > > > > Hello Andre, > > > > According to what you need, you may want to use the 'free' command > > instead, as its output is much simpler than the output of the > > /proc/meminfo file > > > > […] > > > > Hello, > > The free command gets its information from /proc/meminfo. > Performance-wise, it doesn't really matter if a few additional lines > need to be parsed. Hello, Thank you Florian. Actually, I already knew it's the same, I just thought that he could use the free command instead of parsing it himself. You're right. Performance-wise, it's pretty much the same.
[arch-general] dkms remove
When upgrading [root@archlinux rocketmouse]# grep 5.0.14-4 /var/log/pacman.log [2016-03-07 10:48] [ALPM] upgraded virtualbox-host-dkms (5.0.14-1 -> 5.0.14-4) [2016-03-07 10:49] [ALPM] upgraded virtualbox (5.0.14-1 -> 5.0.14-4) automatically the modules for all installed kernels were build. [root@archlinux rocketmouse]# pacman -Q linux linux-rt linux-rt-lts linux 4.4.3-1 linux-rt 4.0.4_rt1-1 linux-rt-lts 3.10.61_rt65-1 [root@archlinux rocketmouse]# ls -Ggh /var/lib/dkms/vboxhost/ total 8.0K drwxr-xr-x 5 4.0K Mar 7 10:47 5.0.14 drwxr-xr-x 5 4.0K Mar 7 10:53 5.0.14_OSE lrwxrwxrwx 1 35 Jan 27 12:22 kernel-3.10.61-rt65-1-rt-lts-x66_64 -> 5.0.14/3.10.61-rt65-1-rt-lts/x66_64 lrwxrwxrwx 1 39 Mar 7 10:50 kernel-3.10.61-rt65-1-rt-lts-x86_64 -> 5.0.14_OSE/3.10.61-rt65-1-rt-lts/x86_64 lrwxrwxrwx 1 32 Mar 7 10:52 kernel-4.0.4-rt1-1-rt-x86_64 -> 5.0.14_OSE/4.0.4-rt1-1-rt/x86_64 lrwxrwxrwx 1 26 Jan 27 12:19 kernel-4.3.3-3-ARCH-x86_64 -> 5.0.14/4.3.3-3-ARCH/x86_64 lrwxrwxrwx 1 26 Feb 3 08:08 kernel-4.4.1-1-ARCH-x86_64 -> 5.0.14/4.4.1-1-ARCH/x86_64 lrwxrwxrwx 1 30 Mar 7 10:53 kernel-4.4.3-1-ARCH-x86_64 -> 5.0.14_OSE/4.4.3-1-ARCH/x86_64 however, I want to get rid of the unneeded modules in /lib/modules and I want to get rid of the dkms directory and links that belong to 5.0.14. I expected that 'dkms remove -m vboxhost -v 5.0.14 --all' would remove all 5.0.14 modules. IIRC it worked _after_ an upgrade, when I removed modules in the past. I can't remember that I removed old modules _before_ I upgraded. [root@archlinux rocketmouse]# dkms remove -m vboxhost -v 5.0.14 --all Error! Could not locate dkms.conf file. File: does not exist. Sure, the new config is available, just the old isn't. [root@archlinux rocketmouse]# ls -Ggh /usr/src/vboxhost*/dkms.conf -rw-r--r-- 1 1.1K Mar 4 22:50 /usr/src/vboxhost-5.0.14_OSE/dkms.conf Am I mistaken, is there the need to remove old modules before upgrading when using 'dkms remove' or did something change and it was possible in the past? https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support#Remove_modules only mentions that after removing the package 'dkms' the required information to remove kernel modules gets lost. If I use the browser's find option to search "remove", I don't find information about removing old modules using 'dkms remove' here: https://wiki.archlinux.org/index.php/VirtualBox I'm aware the 'rm -r' and 'unlink' could be used either, it's just a surprise that 'dkms remove' doesn't work. Perhaps I'm mistaken and I used 'dkms remove' in the past before I upgraded. Regards, Ralf
Re: [arch-general] JasPer vulnerabilities
On 07-Mar-2016 5:59 PM, "Levente Polyak" wrote: > > On 03/07/2016 01:04 PM, Harrison Wells wrote: > > Haven't reported in security list before. Should I just repost my previous > > message? > > It's a announcement only mailing list, discussions should go here > (arch-general) and most of the time we also notice and read that. > However to directly report or ask the security team about a security > issue then the easiest and fastest way is to do it via IRC chan > #archlinux-security on freenode. We are sitting there all the time and > you will most likely get an answer within 1h. > > Thanks for raising awareness about the jasper vulns, I will look into > this after some meetings that I need to participate in. > > cheers, > Levente > I'm glad I could do something for the community. Will post my message on the security IRC channel then.
Re: [arch-general] JasPer vulnerabilities
On 03/07/2016 01:04 PM, Harrison Wells wrote: > Haven't reported in security list before. Should I just repost my previous > message? It's a announcement only mailing list, discussions should go here (arch-general) and most of the time we also notice and read that. However to directly report or ask the security team about a security issue then the easiest and fastest way is to do it via IRC chan #archlinux-security on freenode. We are sitting there all the time and you will most likely get an answer within 1h. Thanks for raising awareness about the jasper vulns, I will look into this after some meetings that I need to participate in. cheers, Levente signature.asc Description: OpenPGP digital signature
Re: [arch-general] JasPer vulnerabilities
Haven't reported in security list before. Should I just repost my previous message? On 07-Mar-2016 5:28 PM, "LoneVVolf" wrote: > On 07-03-16 10:55, Harrison Wells wrote: > >> Is the package JasPer in extra repo vulnerable to CVE-2016-1577, >> CVE-2016-2089 and CVE-2016-2116? I noticed that the version number of >> JasPer is same in Debian, Ubuntu and Arch, i.e. 1.900.1. Debian and Ubuntu >> seem to have updated/patched it, is Arch not vulnerable to it? >> >> With regards, >> >> Harrison Wells >> > The most recent added patch appears to be jasper-1.900.1-CVE-2015-5203 . > I suggest you report this to arch-security mailinglist, > https://lists.archlinux.org/listinfo/arch-security > LW >
Re: [arch-general] JasPer vulnerabilities
On 07-03-16 10:55, Harrison Wells wrote: Is the package JasPer in extra repo vulnerable to CVE-2016-1577, CVE-2016-2089 and CVE-2016-2116? I noticed that the version number of JasPer is same in Debian, Ubuntu and Arch, i.e. 1.900.1. Debian and Ubuntu seem to have updated/patched it, is Arch not vulnerable to it? With regards, Harrison Wells The most recent added patch appears to be jasper-1.900.1-CVE-2015-5203 . I suggest you report this to arch-security mailinglist, https://lists.archlinux.org/listinfo/arch-security LW
[arch-general] JasPer vulnerabilities
Is the package JasPer in extra repo vulnerable to CVE-2016-1577, CVE-2016-2089 and CVE-2016-2116? I noticed that the version number of JasPer is same in Debian, Ubuntu and Arch, i.e. 1.900.1. Debian and Ubuntu seem to have updated/patched it, is Arch not vulnerable to it? With regards, Harrison Wells
