You are not logged in.
I was wondering if conky could be put into bl-backports.
A new feature which might be somewhat important is the
detect_battery
capability, which was merged into the master branch end of April:
https://github.com/brndnmtthws/conky/issues/190
Currently battery device BAT0 is hardcoded into the source files of conky, and this feature makes it possible to change to BAT1 or BAT2, etc, depending on the laptop. So whoever has BAT1, BAT2, etc. battery device on their laptops instead of BAT0 would benefit from this if they use
update_interval_on_battery
Offline
conky is what I would call a "basic element' of the BunsenLabs desktop, so I am fully all-in to providing a current version in our backports.
-edit- Hmm, not much of an upgrade available in Debian...
https://packages.debian.org/search?keywords=conky-all
Nore from the source...
https://github.com/brndnmtthws/conky/re … ag/v1.10.8
This is up to @johnraff, @nobody or @HoaS, they're the ones maintaining our packages. I should step up to the plate on this, though. I'm sure that incremental update has some good stuff in it.
Last edited by hhh (2018-06-19 16:47:57)
I don't care what you do at home. Would you care to explain?
Offline
Gaa! I was going to backport it, but I'm already running the latest version available in Debian...
rachel@TyrellCorp:~$ apt-cache policy conky-all
conky-all:
Installed: 1.10.8-1+b1
Candidate: 1.10.8-1+b1
Version table:
*** 1.10.8-1+b1 500
500 https://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
rachel@TyrellCorp:~$
buster freeze starts in January, prepare to dist-upgrade, everyone!
I don't care what you do at home. Would you care to explain?
Offline
@ghorvath I'm not a conky expert at all, but I see in 'man conky' for Stretch's 1.10.6-1 a number of references to different battery numbers that can be set:
battery (num)
Battery status and remaining percentage capacity of ACPI or APM
battery. ACPI battery number can be given as argument (default is
BAT0).battery_bar (height),(width) (num)
Battery percentage remaining of ACPI battery in a bar. ACPI bat‐
tery number can be given as argument (default is BAT0, use all to
get the mean percentage remaining for all batteries).battery_percent (num)
Battery percentage remaining for ACPI battery. ACPI battery num‐
ber can be given as argument (default is BAT0, use all to get the
mean percentage remaining for all batteries).battery_short (num)
Battery status and remaining percentage capacity of ACPI or APM
battery. ACPI battery number can be given as argument (default is
BAT0). This mode display a short status, which means that C is
displayed instead of charging, D for discharging, F for full, N
for not present, E for empty and U for unknown.battery_time (num)
Battery charge/discharge time remaining of ACPI battery. ACPI bat‐
tery number can be given as argument (default is BAT0).
This says that the default is BAT0 but others can be set.
The extra functionality in detect_battery is only for using update_interval_on_battery?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
The extra functionality in detect_battery is only for using update_interval_on_battery?
I am no conky expert, either, but the github issue I linked in the OP was closed right after the commit introducing detect_battery, and also the commit message said that the corresponding issue is fixed. So I would say yes.
I looked at some forums, and they claimed that BAT0 was hardcoded in the source for update_interval_on_battery. And the only way to make it work was to download the source, manually rewrite it to BAT1, and then recompile it.
However, I never tried it, because I would not like to mess with compiling such a core Bunsenlabs package on my shiny bl-helium laptop, especially if it were possible to load it from backports as a proper package. ;-)
Offline
Well, compiling and maintaining a backported package is not a trivial task. We need to be sure that the reasons for doing so are urgent enough...
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
^ This should be a simple backport, though I haven't tried it.
Non-critical for now, if you ask me, the user can backport it. But a recent conky should be default or a welcome option for buster/lithium, I would say.
I don't care what you do at home. Would you care to explain?
Offline
I looked at some forums, and they claimed that BAT0 was hardcoded in the source for update_interval_on_battery. And the only way to make it work was to download the source, manually rewrite it to BAT1, and then recompile it.
i think you looked in the wrong places, or for the wrong answers:
https://github.com/brndnmtthws/conky/issues/190
Offline
But a recent conky should be default or a welcome option for buster/lithium, I would say.
Sure, but Buster will presumably already ship a fairly new conky? How much better the very latest version is than that, and whether that's enough to justify a BL backport, we'll have to decide at the time I guess.
What I meant about non-trivial for BL backports was not necessarily the difficulty of compiling but also the resposibility that then comes of keeping it up to date with any security fixes. Debian would otherwise do that for us.
Last edited by johnraff (2018-06-21 06:45:41)
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
hhh wrote:But a recent conky should be default or a welcome option for buster/lithium, I would say.
Sure, but Buster will presumably already ship a fairly new conky? How much better the very latest version is than that, and whether that's enough to justify a BL backport, we'll have to decide at the time I guess.
I would not want to offend anyone, but bl-Helium came out a full year after Debian Stretch, which was in freeze for half year. So all packages at the time of bl-Helium coming out were 1.5 years outdated (1 year if we say that during the freeze there was no development, only bugfixes). If the same schedule will be kept for Buster and Lithium....
In any case, I threw the idea out there. Considering that I do not have the time to check out how to backport something, and definitely not to maintain the stuff afterwards, I completely understand if conky will not be backported to bl-Helium. To me it is not a very urgent/important matter, anyway, I will continue to use (and love) bl-Helium either way.
Offline
If the same schedule will be kept for Buster and Lithium....
It won't, I'm already running buster and @johnraff has been playing with it too.
Last year was bad for me, personally. I had major life-issues to deal with. Additionally, one of our team members moved to a different country, then moved back. We each had distractions that had to be attended to.
Fingers crossed, that's not the case this year. We're well aware that the freeze process for buster will start in January, with a probable release date of a year from now, about. We'll be ready with lithium at the release of buster, or very soon after.
I don't care what you do at home. Would you care to explain?
Offline
So all packages at the time of bl-Helium coming out were 1.5 years outdated (1 year if we say that during the freeze there was no development, only bugfixes).
That depends of who you compare with. This is Debian stable after all.
Offline
ghorvath wrote:So all packages at the time of bl-Helium coming out were 1.5 years outdated (1 year if we say that during the freeze there was no development, only bugfixes).
That depends of who you compare with. This is Debian stable after all.
Since we were talking about backporting the newest version, we compare it with that.
Offline
people who throw the word "outdated" around like that really shouldn't be using debian stable, or anything based thereon.
and i say that without malice; debian stable on my server, yay, but something less "outdated" for my desktop.
Offline