You are not logged in.

#1 2019-04-13 10:01:56

alban
Member
Registered: 2019-04-13
Posts: 8

Upgrade to stretch : some misc problems

Ola !

Since I've been replacing s/jessie/stretch in my sources and done the dist-upgrade, I've had a few problems which I thought I'd mention and eventually require help about.

I've solved various minor troubles, like my gpg-agent -which I use to manage SSH keys for confirming the use of the ssh agent everyt time I (or suspectedly someone else) wants to use an active socket agent- using the wrong pinlock gui.

Also, dmenu-run was looking after /usr/bin/bash ? Made a symlink, but that was weird.

Now I'm left with :

- tint2 is not running as a service ? It has conflicted with tint, apparently, because tint was running right after the upgrade and crashed when I changed the tint2 configuration. I have to run AltF2 + tint2

- I've lost the screen luminosity control, either keys or via the tint2 GUI. Is that something happening to others?

Offline

#2 2019-04-13 14:16:28

ohnonot
...again
Registered: 2015-09-29
Posts: 3,773
Website

Re: Upgrade to stretch : some misc problems

alban wrote:

Since I've been replacing s/jessie/stretch in my sources and done the dist-upgrade, I've had a few problems which I thought I'd mention and eventually require help about.

good for you.
which instructions did you follow, and did you log the process?

Also, dmenu-run was looking after /usr/bin/bash ? Made a symlink, but that was weird.

dmenu_run on my system is just a short shell script.
it should reside in /usr/bin - does it?
it should not rely on bash, but on sh.
i suspect you have a custome version in your $HOME/bin.

tint2 is not running as a service ? It has conflicted with tint, apparently, because tint was running right after the upgrade and crashed when I changed the tint2 configuration. I have to run AltF2 + tint2

tint (without 2) has been dead for many, many years.
frankly, i have no idea what you're talking about there.

I've lost the screen luminosity control, either keys or via the tint2 GUI. Is that something happening to others?

yes.
it requires some troubleshooting.
please search existing threads, maybe you can find a solution or at least hints for what to troubleshoot & what info to provide.

Offline

#3 2019-04-13 16:11:11

alban
Member
Registered: 2019-04-13
Posts: 8

Re: Upgrade to stretch : some misc problems

ohnonot wrote:

which instructions did you follow, and did you log the process?

Debian wiki upgrade page. I did not record the whole process. I've been upgrading servers for many years, and as I use aptitude to fix depencies troubles, it turns out logging is not an habit anymore.

ohnonot wrote:

it should not rely on bash, but on sh.
i suspect you have a custome version in your $HOME/bin.

Indeed, the script command goes like this:

dmenu_path | dmenu "$@" | ${SHELL:-"/bin/sh"} 

Turns out I had indeed a messed up SHELL environment variable. Fixed that, thanks. Don't know how that happened, will check on pre upgrade backup :s

ohnonot wrote:

tint (without 2) has been dead for many, many years.
frankly, i have no idea what you're talking about there.

Mmm. Did the "jessie" bunsenlabs use tint2 already? Because I have the feeling I used a tint version that showed on top by default, full width. But that's not the problem, actually.

The problem: I guess tint2 should be launched by the system on every login, but is not. I can add it to my own openbox session startup script, but that feels weird. So the question is : What is the «canonical» way to run tint2 on bunsenlabs, in terms of init?

ohnonot wrote:

it requires some troubleshooting.
please search existing threads, maybe you can find a solution or at least hints for what to troubleshoot & what info to provide.

Thanks a lot. I'll do that.

Last edited by alban (2019-04-13 16:11:43)

Offline

#4 2019-04-13 16:31:52

damo
....moderator....
Registered: 2015-08-20
Posts: 4,972

Re: Upgrade to stretch : some misc problems

alban wrote:

...
Mmm. Did the "jessie" bunsenlabs use tint2 already? Because I have the feeling I used a tint version that showed on top by default, full width. But that's not the problem, actually.

The problem: I guess tint2 should be launched by the system on every login, but is not. I can add it to my own openbox session startup script, but that feels weird. So the question is : What is the «canonical» way to run tint2 on bunsenlabs, in terms of init?
....

Tint2 has been in use since the Crunchbang days, and has always been used by BL. The appearance is set by the tint2 config in use, so you can have whatever layout you like - check the tint2rc which is being run.

Tint2 isn't run by init as a service by BL, but started in your ~/.config/openbox/autostart. If it isn't starting properly by autostart, look for errors in ~/.xsession-errors


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Online

#5 2019-04-13 18:19:22

alban
Member
Registered: 2019-04-13
Posts: 8

Re: Upgrade to stretch : some misc problems

Right. I've looked at that file. Following line is broken:

(sleep 2s; bl-tint2-session) &

Why? Because bl-tint2-session failed to exec. See [1] for details.

Replaced the failing code with a simple call to the executable and now it works.

Thanks !

It seems to be the current package bunsen-utilities version. You might want to check it if I'm right.


[1]

Here is a snippet of the bl-tint2session script I had:

...
testSessionfile(){
...
        while read line;do
            tint2 -c "$line" &
            sleep 1s
        done < "$1" # Does not work. Note: use <( echo $1 ) eventually, 
...
}
...

The code did a `read < "file"`.  But a string is not a file descriptor and the while loop wouldn't work.

So I replaced the whole structure with

            done < <( cat "$1")

But I also had to remove the session file to regenerate it. Checking if empty would be better in the script.

Last edited by alban (2019-04-13 18:21:59)

Offline

#6 2019-04-13 18:34:59

damo
....moderator....
Registered: 2015-08-20
Posts: 4,972

Re: Upgrade to stretch : some misc problems

alban wrote:

...
But I also had to remove the session file to regenerate it. Checking if empty would be better in the script.

Maybe raise an issue on github? https://github.com/BunsenLabs/bunsen-ut … t2-session


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Online

#7 2019-04-13 19:40:25

alban
Member
Registered: 2019-04-13
Posts: 8

Re: Upgrade to stretch : some misc problems

damo wrote:
alban wrote:

...
But I also had to remove the session file to regenerate it. Checking if empty would be better in the script.

Maybe raise an issue on github? https://github.com/BunsenLabs/bunsen-ut … t2-session

Sounds good. I'll do that via a merge request smile

Now. Here's progress on the brightness problem troubleshooting.

Changing brightness via kernel works:

sudo bash -c 'echo 255 > /sys/class/backlight/intel_backlight/brightness'

xbacklight does not work:

xbacklight -set 50
No outputs have backlight property

Xrandr works :

xrandr --output eDP-1 --brightness 1.0

xfpm-power-backlight-helper works

sudo pkexec /usr/sbin/xfpm-power-backlight-helper --set-brightness 50

But xfce4-power-manager via tint2 does not work.
Touch keys don't work either.

Tried to read the xfce4-power-manager source code to identify the API it's using, but hard.

Offline

#8 2019-04-13 19:52:23

ohnonot
...again
Registered: 2015-09-29
Posts: 3,773
Website

Re: Upgrade to stretch : some misc problems

you shouldn't use xrandr for brightness, it's a software solution.
xbacklight has been known to not work on many machines.
you could try light instead, or just script something that modifies /sys/class/backlight/intel_backlight/brightness directly.

Offline

#9 2019-04-13 20:17:57

alban
Member
Registered: 2019-04-13
Posts: 8

Re: Upgrade to stretch : some misc problems

Well, that would work, but fixing function keys and xfce widget would be better IMO wink

I can't find any log, it fails silently.

Strace'd the process, here's what I got

...
[pid 15198] execve("/usr/bin/pkexec", ["pkexec", "/usr/sbin/xfpm-power-backlight-helper", "--set-brightness", "265"], [/* 27 vars */] <unfinished ...>
...
[pid 15198] write(2</dev/null>, "pkexec must be setuid root\n", 27) = 27
[pid 15198] exit_group(127)             = ?
[pid 15198] +++ exited with 127 +++

Which is weird, because pkexec seems fine:

$ ls -lh /usr/bin/pkexec
-rwsr-xr-x 1 root root 23K déc.   6 18:34 /usr/bin/pkexec

Edit:
And running the following works, after showing a pinentry GUI

/usr/bin/pkexec "pkexec" "/usr/sbin/xfpm-power-backlight-helper" "--set-brightness" "255"

Last edited by alban (2019-04-13 20:20:08)

Offline

#10 2019-04-26 07:27:17

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,460
Website

Re: Upgrade to stretch : some misc problems

alban wrote:

a string is not a file descriptor

If the string is a path to a file, it is. Bash is loosely typed, as you probably know already.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

Board footer

Powered by FluxBB