SolydXK 9 (stretch) alpha build testing

SolydXK is too quiet for you? SolydXK Enthusiast Editions, based on Debian Testing is for you! Here you can find news about Debian Testing and Unstable too, and also tests on SolydXK programs.
The support for SolydXK EE is provided by the community.
User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 07 Mar 2017 09:49

I think this one will work better:

Code: Select all

#!/bin/bash

# Script variables
DEBUG=false
ENGINES='python python3 bash sh'
# Arguments that need a value
ARGSPLUS='-c -u -p --comment --attach -i -f --user --description -D --message -m -a --app --icon --desktop --config --style --geometry --display --session -ncols --fn --font --bg --background --fg --foreground --btn --button --name --title --visual --inputstyle --im --stylesheet --graphicssytem --qmljsdebugger'

# Prepare for translations
# https://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html
. gettext.sh

TEXTDOMAIN=xksudo
export TEXTDOMAIN
TEXTDOMAINDIR=/usr/share/locale
export TEXTDOMAINDIR

# Get translations
# Create pot: xgettext -o xksudo.pot  -L Shell --keyword --keyword=GETTEXT  xksudo
MSG_ADM=$(eval_gettext "needs administrative privileges.")
MSG_PWD=$(eval_gettext "Please enter your password.")

# Check launcher
KDESUDO=false
LAUNCHER=$(which kdesudo)
if [ ! "$LAUNCHER" ]; then
  LAUNCHER=$(which gksudo)
  if [ ! "$LAUNCHER" ]; then
    # This is bad, but we try anyway
    GROUP=$(id -gn)
    if [ ! "$GROUP" ]; then
      GROUP=$USER
    fi
    sudo -E $@; find $HOME -user root -exec chown $USER:$GROUP {} \;
    exit 1
  else
    DIVERT=$(grep "$LAUNCHER" "/var/lib/dpkg/diversions" | grep divert)
    if [ -f "$DIVERT" ]; then
      LAUNCHER=$DIVERT
    fi
  fi
else
  DIVERT=$(grep "$LAUNCHER" "/var/lib/dpkg/diversions" | grep divert)
  if [ -f "$DIVERT" ]; then
    LAUNCHER=$DIVERT
  fi
  KDESUDO=true
fi

if $DEBUG; then  echo "LAUNCHER = $LAUNCHER"; fi

# Loop all arguments
OPTS=''
APP=''
ADDNEXT=false
HASMSG=false
HASICON=false
HASAPP=false
if $DEBUG; then echo "Arguments = $@"; fi
for i in "$@"; do
  if $DEBUG; then echo "  arg=$i"; fi
  if [ "${i:0:1}" == "-" ]; then
    for a in $ARGSPLUS; do
      if [ "$i" == "$a" ]; then
        ADDNEXT=true
        case "$i" in
          --comment|--message|-m)
            if $DEBUG; then echo "HASMSG"; fi
            HASMSG=true
            ;;
          -i|--icon|-a|--app)
            if $DEBUG; then echo "HASICON"; fi
            HASICON=true
            i=''
            ;;
          -c)
            ADDNEXT=false
            i=''
            ;;
          *)
            ;;
        esac
        break
      fi
    done
    if [ "$i" ]; then OPTS="$OPTS $i"; fi
    if $DEBUG; then echo "OPTS = $OPTS"; fi
  elif $ADDNEXT; then
    # Get the value of the argument
    ADDNEXT=false
    if $HASICON; then
      HASICON=false
      if [[ ! "$i" =~ '/' ]]; then
        # No path to icon, assume application name
        APP=$i
        if $DEBUG; then echo "APP (from -i) = $APP"; fi
      else
        ICON=$i
        if $DEBUG; then echo "ICON (from -i) = $ICON"; fi
      fi
    else
      # Quote the value of the argument
      OPTS="$OPTS \"$i\""
      if $DEBUG; then echo "OPTS = $OPTS"; fi
    fi
  else
    # Guess the application name
    if [ ! "$APP" ]; then
      for a in $i; do
        APP=$(basename $a)
        break
      done
      if $DEBUG; then echo "APP = $APP"; fi
    fi
    # Build the command
    if [ ! "$CMD" ]; then
      CMD=$i
    else
      CMD="$CMD $i"
    fi
    if $DEBUG; then echo "CMD = $CMD"; fi
  fi
done

# Show friendly message
if ! $HASMSG; then
  if [ ! "$APP" ]; then
    APP=$(echo $CMD | awk '{print$1}')
  fi
  MSG="\"<b>$APP</b> $MSG_ADM $MSG_PWD\""
  if $KDESUDO; then
    OPTS="$OPTS --comment $MSG"
  else
    OPTS="$OPTS --message $MSG"
  fi
fi

if $KDESUDO; then
  # Find the current theme icon if it doesn't exist
  if [ ! -e "$ICON" ] && [ "$APP" ]; then
    # Find the configured icon name in the app's .desktop file
    for F in $(find /usr/share/applications -type f -name "*$APP*.desktop"); do 
      DTICON=$(grep Icon= $F | cut -d'=' -f2)
      if [ "$DTICON" ] && [ "$DTICON" != "$APP"  ]; then
	APP=$DTICON
	if $DEBUG; then echo "DTICON = $DTICON"; fi
	break
      fi
    done
    # Find the appropriate theme icon
    if [ "$(which python3)" ]; then
      ICON=$(python3 -c 'import gi; gi.require_version("Gtk", "3.0"); from gi.repository import Gtk; import sys; theme = Gtk.IconTheme.get_default(); icon = theme.lookup_icon(sys.argv[1], int(sys.argv[2]), 0); print((icon.get_filename())) if icon else ""' $APP 32)
    elif [ "$(which python)" ]; then
      ICON=$(python -c 'import gtk, sys; theme = gtk.icon_theme_get_default(); icon = theme.lookup_icon(sys.argv[1], int(sys.argv[2]), ()); print icon.get_filename() if icon else ""' $APP 32)
    fi
    if $DEBUG; then echo "ICON (with python) = $ICON"; fi
  fi

  # Add the icon
  if [ -e "$ICON" ]; then
    OPTS="$OPTS -i \"$ICON\""
  fi
  # Make kdesudo use the user's theme
  GROUP=$(id -gn)
  if [ ! "$GROUP" ]; then
    GROUP=$USER
  fi
  CMD="-d -c \"HOME=$HOME $CMD; find $HOME -user root -exec chown $USER:$GROUP {} \;\""
fi

if $DEBUG; then
  echo "Run: $LAUNCHER $OPTS $CMD"
else
  eval "$LAUNCHER $OPTS $CMD"
fi


SolydXK needs you!
Development | Testing | Translations

User avatar
bas_otten
Posts: 199
Joined: 19 Oct 2013 12:22
Location: Netherlands

Re: SolydXK 9 (stretch) alpha build testing

Postby bas_otten » 07 Mar 2017 23:26

This last version tests OK for me.

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 13 Mar 2017 04:35

I've replaced the alpha ISOs with new ones. Check the OP for the link if you're interested.


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 13 Mar 2017 16:01

A comparison with the EEs shows new differences, while the previous ones are mostly gone. ;)

On the EE ISOs, removing updatemanager also removed dependencies that had been automatically installed. Unlike the Constructor, my build scripts do not mark everything as manually installed. These packages were (auto)removed from the EEs, but not from the alphas:
SolydK: gir1.2-appindicator3-0.1 libappindicator3-1 libdbusmenu-gtk3-4 libdbusmenu-glib4 libindicator3-7
SolydX: gir1.2-appindicator3-0.1 libappindicator3-1 libdbusmenu-gtk3-4 libdbusmenu-glib4 libindicator3-7 python-appindicator libappindicator1 libdbusmenu-gtk4

Today I removed some applications from the EEs which had already been removed from the alphas. The following packages still installed on the alpha were (auto)removed from the EE:
SolydX (dependencies of texlive): fonts-lmodern fonts-texgyre lmodern tex-gyre

I noticed xksudo-packages has been added to the SolydX alpha. I'm curious. What exactly is the benefit of that package on an Xfce system?

Also, the virtualbox-guest-* packages on the alphas have not been updated (current version in unstable is 5.1.16-dfsg-1).
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 13 Mar 2017 16:30

Thanks for the surplus packages. I don't know how to prevent apt marking packages as manually installed. I learned to live with it, I suppose.
grizzler wrote:I noticed xksudo-packages has been added to the SolydX alpha. I'm curious. What exactly is the benefit of that package on an Xfce system?
Consistent design of the password entry window. Not needed, but pretty...at least I think so...
grizzler wrote:Also, the virtualbox-guest-* packages on the alphas have not been updated (current version in unstable is 5.1.16-dfsg-1).
I have to manually check, download and add them to the repository manually and I don't check very often. Just did that, though.

Thanks!


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 13 Mar 2017 18:12

Schoelje wrote:I don't know how to prevent apt marking packages as manually installed.
Well, maybe you could start with removing line 61 from /usr/lib/solydxk/constructor/files/cleanup.sh (aptitude -y unmarkauto ~M)...
To be honest, I thought you put that there on purpose. :?

When I was writing my ISO build scripts, I left that bit out. I never actively reconstructed the 'auto state' of any package that was already installed on the EEs at the time, so I don't really know why so many packages have that state now (376 on the 64-bit SolydX EE).
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 16 Mar 2017 12:39

I've updated xksudo to run the following command after the kdesudo command ends:

Code: Select all

find $HOME -user root -exec chown $USER:$GROUP {} \;
GROUP is set by:

Code: Select all

id -gn
I've been testing this for a while and while the kdesudo command runs and creates new files in $HOME they are owned by root. When the kdesudo command ends the owner:group of those files was set correctly to the user:group.

I've updated the xksudo code in: viewtopic.php?p=64570#p64570
Scroll down to the bottom and check the code below "# Make kdesudo use the user's theme".


SolydXK needs you!
Development | Testing | Translations

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 16 Mar 2017 19:07

What do you think about moving xksudo to /usr/local/bin/kdesudo as suggested by bas_otten?

I think the last hurdle to take was solving the root owned files in the user's home directory, or am I mistaken?
Now that that seems solved (I've been using the script for the past two days without issues) it would be a nice solution for the incoherent theming for some applications and if you don't like it you can simply purge xksudo.

What do you think?


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 16 Mar 2017 19:33

Strictly speaking, that would mean you can't put it in a package, because the package manager isn't allowed to touch anything in /usr/local: https://refspecs.linuxfoundation.org/FH ... lHierarchy

After I found that some of my own scripts in /usr/local/bin were overwritten by misbehaving packages, I wrote some code to prevent that. This effectively blocks any package from installing anything in /usr/local. So this script would never appear there, or in the build structure of any of the ISOs I maintain.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 16 Mar 2017 20:51

Bummer!
But what about doing the same with kdesudo as we did with apt?


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 16 Mar 2017 21:14

That should work.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
bas_otten
Posts: 199
Joined: 19 Oct 2013 12:22
Location: Netherlands

Re: SolydXK 9 (stretch) alpha build testing

Postby bas_otten » 16 Mar 2017 21:19

Ah, that's what I was thinking already: /usr/local/bin is not a correct location for a final/apt-controlled result - my apologies. That is meant for users their own programs/scripts, after installation of the system. In fact, the discussion is a little bit different now: I mentioned /usr/local/bin as a precedence location for a modified kdesudo. But by now, we're talking about a separate xksudo which calls the regular kdesudo. What makes most sense to me - correct me if I'm wrong - is to choose the same location as kdesudo itself, so /usr/bin.

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 16 Mar 2017 22:04

Our solution for apt was to divert /usr/bin/apt and save our own script as /usr/bin/apt which uses the diverted apt internally to run the commands. That way our script, a wrapper for apt, replaces the original apt and adds some very nifty features to it.

I could do the same by diverting /usr/bin/kdesudo and use the current xksudo as /usr/bin/kdesudo that uses the diverted kdesudo internally to run the commands.

Are there any objections to that?


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 17 Mar 2017 19:40

Schoelje wrote:
grizzler wrote:Also, the virtualbox-guest-* packages on the alphas have not been updated (current version in unstable is 5.1.16-dfsg-1).
I have to manually check, download and add them to the repository manually and I don't check very often.
And Unstable now has virtualbox 5.1.18-dfsg-1... ;)

I could keep an eye on these packages for you, even upload them (just did, in case that's useful...). I assume you would still have to move them, but at least you wouldn't have to check.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 17 Mar 2017 20:51

Thanks!
Moved to solydxk-9/import.


SolydXK needs you!
Development | Testing | Translations

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 17 Mar 2017 21:32

xksudo package replacing kdesudo/gksudo now in testing.
I'll upload some ISOs with this package installed.


SolydXK needs you!
Development | Testing | Translations

User avatar
bas_otten
Posts: 199
Joined: 19 Oct 2013 12:22
Location: Netherlands

Re: SolydXK 9 (stretch) alpha build testing

Postby bas_otten » 18 Mar 2017 12:50

Schoelje wrote: I could do the same by diverting /usr/bin/kdesudo and use the current xksudo as /usr/bin/kdesudo that uses the diverted kdesudo internally to run the commands.
I had to really dive into the concept of diverting, to understand what this sentence means ;-)
But now I get it, I think that is a very good solution, a typical case (wrapping a program with a script) for which diverting was intended.
It does (re)introduce the global scope of this change.

User avatar
Arjen Balfoort
Site Admin
Posts: 8720
Joined: 26 Jan 2013 19:36
Location: Netherlands
Contact:

Re: SolydXK 9 (stretch) alpha build testing

Postby Arjen Balfoort » 18 Mar 2017 13:12

I've uploaded new ISOs (see the OP for the download link) which use xksudo this way. If /usr/bin/kdesudo and/or /usr/bin/gksudo is present, they are diverted and replaced with symbolic links to /usr/bin/xksudo.

The xksudo packages that divert kdesudo and gksudo are not in main but in testing but while I was uploading the ISOs (which takes a really long time) I've updated the script twice. So, there's a newer xksudo version available in testing: http://repository.solydxk.nl/pool/testing/x/xksudo/


SolydXK needs you!
Development | Testing | Translations

User avatar
grizzler
Posts: 1992
Joined: 04 Mar 2013 15:45
Location: The Hague, NL

Re: SolydXK 9 (stretch) alpha build testing

Postby grizzler » 18 Mar 2017 13:43

Oh dear. I didn't expect gksudo to be dragged into this as well (although with hindsight, I suppose I should have expected that). I think you may want to reconsider. The real gksudo is a symlink to gksu, which suggests the executable's behaviour depends on the way it is called. I haven't checked yet (I will, later this weekend when I have more time), but it wouldn't surprise me if gksu being called (via a symlink) as /usr/bin/gksudo.divert interfered with that. That is, it may cause the executable to 'think' the caller meant gksu rather than gksudo.
As I wrote, I haven't checked yet, but please be prepared to drop gksudo from the equasion if necessary.
Frank

SolydX EE 64 - tracking Debian Testing

User avatar
ilu
Posts: 1941
Joined: 09 Oct 2013 12:45

Re: SolydXK 9 (stretch) alpha build testing

Postby ilu » 18 Mar 2017 13:56

Arjen mentioned gksudo almost from the beginning. And it's obvious from the code. I tried to very carefully voice objections but you know I'm not really qualified in that area. Thank you for looking into this.
I think diverting something in a perfectly working system (SolydX) just to correct something in another system (SolydK) is a bad idea, although I can understand that Arjen would want to keep his code convergent for both systems. But in my opinion systems should be kept as much standard as possible (to ease debugging) without loosing too much comfort, which - in the case of SolydX - seems to be possible without xksudo. The only problem was KDE.


Return to “Testing zone”

Who is online

Users browsing this forum: No registered users and 4 guests