Problem with some conky variables

[Duncan_Idaho]

hi
I'm trying to use conky to monitor a few things on my laptop, but I get this error when running it

Code: Select all

rob[~]$ conky
Conky: unknown variable wireless_essid
Conky: unknown variable wireless_link_qual_perc
2010-06-28 22:50:28 |Up:23h 53m |Temp:49C |RAM:16% |CPU:17% |Batt:F |WiFi:${wireless_essid} ${wireless_link_qual_perc}% |Vol:42%

the funny things is that I got those variables from conky's manpages
here's my .conckyrc if it helps

Code: Select all

out_to_x no
out_to_console yes
update_interval 1.0
total_run_times 0
use_spacer none
TEXT
${time} |Up:${uptime_short} |Temp:${acpitemp}C |RAM:$memperc% |CPU:${cpu}% |Batt:${battery_short BAT1} |WiFi:${wireless_essid wlan0} ${wireless_link_qual_perc wlan0}% |Vol:${mixer}%

any help is appreciated

[Shador]

I guess conky is not built with support for this functionality. If you think this might be of common interest and doesn't pull in to many deps, I might rebuild it at some point.
Otherwise, I have to say that I'm sorry, but can't support it, so you will have to build an own version yourself, if you really need it.

[Duncan_Idaho]

I guess conky is not built with support for this functionality. If you think this might be of common interest and doesn't pull in to many deps, I might rebuild it at some point.

Well, yes I think it might be of common interest as it allows to provide useful information regarding wifi conectivity, as you can see the ESSID of the network you are connected to, or the MAC address of the router, as well as signal quality among other things.
Conky is really useful for minimalist desktops, or if you like information in your desktop and/or don't use panels.
So I'd be really happy if you could check the conky build

[Shador]

Ok, it turns out I was mislead when I first built conky as wireless support only adds another build-time dep. So I will have to accept wireless-tools on my over-wired desktop.

I'm sure we can replace the packages for 13.1 after you've tested them too:
http://gaia.homelinux.org/salix/package ... 86-2ab.txz
http://gaia.homelinux.org/salix/package ... 86-2ab.txz

[Duncan_Idaho]

Cool! thanks shador!
I'll test them when I get back home from college

[Duncan_Idaho]

I've been testing the i486 package, so far so good.
just two issues:
+ is kinda misleading that the x86_64 packages has the same filename that the i486
+ gslapt tells me that "there are upgrades available" and wants me to upgrade from your package to the one in the repo, even when the only difference is the -1ab/-2ab at the end of the name

other than that it works great! thank you very much!

[pwatk]

Yet another case of wireless discrimination in Salix

[laprjns]

+ gslapt tells me that "there are upgrades available" and wants me to upgrade from your package to the one in the repo, even when the only difference is the -1ab/-2ab at the end of the name

I believe that gslapt / slapt-get will always want to "upgrade" to the version on the repository no matter what the version number says. Since the -2ab version is not on the repository, gslapt wants to upgrade to -1ab.
Rich

[Shador]

+ gslapt tells me that "there are upgrades available" and wants me to upgrade from your package to the one in the repo, even when the only difference is the -1ab/-2ab at the end of the name

I believe that gslapt / slapt-get will always want to "upgrade" to the version on the repository no matter what the version number says. Since the -2ab version is not on the repository, gslapt wants to upgrade to -1ab.
Rich

Exactly.

is kinda misleading that the x86_64 packages has the same filename that the i486

Ooops, I should have changed and commented out the arch variable.

other than that it works great! thank you very much!

Ok, I'll fix that one small problem and I guess then gapan will be fine to replace the existing package (that fixes also your upgrade messages )

Yet another case of wireless discrimination in Salix

Is such a comment really necessary. Just because I wanted to keep the runtime dependencies low in the first place so that nobody is forced into installing wireless-tools when he only wants conky, doesn't mean I discriminate it. Now it turned out we're only dealing with a build-time dependency which is not really a problem.

[pwatk]

Is such a comment really necessary. Just because I wanted to keep the runtime dependencies low in the first place so that nobody is forced into installing wireless-tools when he only wants conky, doesn't mean I discriminate it. Now it turned out we're only dealing with a build-time dependency which is not really a problem.

I was only joking, I didn't mean to cause offence