Light-Debian-Core-Live-CD-Wheezy + Porteus-Wheezy

[fredx181]

Hi Toni, long time no see

Just for information:
......
......

Thanks, I'll look into it later, probably next week because I'm suddenly involved in trying to create some sort of kiosk distro for my volunteer work.
As base I use DD and it needs to be completely in dutch language.
I discovered some wrong things (some have to do with locale change) I'll inform you later about it.

Fred

[saintless]

Take your time, Fred

Synchronize dpkg status scripts are something for experimenting and I guess nobody will actually use them (it is so easy to remaster the system as you like it adding or removing programs and changing settings).
But having tool that can solve most (or all) dpkg status problems makes the system more flexible.

Toni

[saintless]

Hi, Fred.

Some more troubles for later
If we are going to make DebianDog packages compatible (as much as possible) with standard Debian I think we have a problem with gsu line in most of the scripts.
I can't find gsu command in Debian or package that contains gsu. I'm sure gksu will do the same job as gsu but since Debian does not use root most scripts will exit with "gsu command not found" message.
We need to decide what to do before editing packages on the site. I see two possible solutions:

1. Change gsu to gksu (or search for gksu if gsu not found) - i don't like this solution because we have to edit many included scripts and the previous DD versions will not have this fix.

2. Create gsu.deb and add in each package that contains gsu line symlink /usr/local/bin/gsu pointing to /usr/bin/gksu (link created from postinst script) and add as dependency in each package gsu or gksu (if gksu is already installed). But it is not easy to do also because gsu in Jwm asks for user password and in OpenBox it asks for root password (the scripts are different because activated XDM exports permissions for user and root different way and gsu with root password does not work well).

I'm sure there are other solutions but can't find better one yet.

Toni

[fredx181]

Hi Toni,

Some more troubles for later Smile
.....
.....

Ahh, I like troubles
For info:
I'm no good in concentrating on different things.
After wednesday (that's the deadline for the kiosk distro I'm working on) I'll get back to DD.

Take care!

Fred

[saintless]

OK, Fred
You better take few days vacation after kiosk project finish.
BTW my laptop is alive again Found and fixed cold solder connector problem and now it works.

Toni

[fredx181]

Hi Toni,

Ok, where were we?

The kiosk distro turned out very well but took much more time as expected (which is almost always the case).
After it was finished I jumped directly in trying to improve gdrive-get due to a conversation I had with Stemsee through PM (he had some great ideas for fixes and improvements)
So attached new gdrive-get.tar.gz for testing with the following improvements:
- huge improvement in speed for creating or updating lists (using elinks instead of wget for it)
- same way as smokey-get, config files for every drive in /usr/local/gdrive-get.
- download list items truncated (not whole https address).
- option to filter by filetype
- option to use 'human readable' names for drive, e.g. 'toni'
- download list stays open while downloading, to have the chance to select more again (I'm not sure yet if I like it this way, what's your opinion ?)

Some things I'd like to implement also for smokey-get later (specially I like the filetype filter) but I'd like to know what you think also.

To answer your proposition about gsu (sorry for the delay):

2. Create gsu.deb and add in each package that contains gsu line symlink /usr/local/bin/gsu pointing to /usr/bin/gksu (link created from postinst script) and add as dependency in each package gsu or gksu (if gksu is already installed). But it is not easy to do also because gsu in Jwm asks for user password and in OpenBox it asks for root password (the scripts are different because activated XDM exports permissions for user and root different way and gsu with root password does not work well).

I think this is best and I can change things to sudo then on openbox version.
Did you like the 'gsudo' script I made a while back? We could rename to gsu maybe. (attached, just in case you don't have)
I ask because I like more a graphical program then a 'xterm' sudo solution.

Edit: And congrats with your new reborn laptop!

Edit2: Re-uploaded, added checkbox to show filenames only in download list.

Fred

[saintless]

Hi, Fred

I will try to test gdrive-get properly tonight. Too much work these days unfortunately.

I will think a bit more about gsu added as dependency and how to make it right. Official debian gksu package offers to run as root by default from quick testing so there is no need to change openbox gsu version to use user password (unless you prefer to change it anyway).

Did you like the 'gsudo' script I made a while back? We could rename to gsu maybe. (attached, just in case you don't have)
I ask because I like more a graphical program then a 'xterm' sudo solution.

I will check it again. I think I have the same gsudo included in /opt/bin

Edit: Reading gsudo script I think it is not a problem to rename it to gsu for next iso update but it needs yad and (if I do not mistake) standard debian system will most likely not have yad installed or yad repository available in sources list. This means every package with gsu line will have to start with auto-downloading and installing yad on first run or we must think of some other way to do it. Debian should have gksu installed already on the other hand.
If we think only about DebianDog compatibility it is fine, but I like to make the packages as much as possible compatible with standard Debian system.
What is your opinion, Fred? Do you see packages compatibility with standard Debian as important? I think it is because DebianDog is Debian down to the core. We can do it and start making new packages compatible for DebianDog and standard Debian but it will take some work and testing till we mod the existing packages proper.

BTW I think I will remove change-jwm-theme package. It is only for Jwm version and depends Terry's menu scripts and it is already included in Jwm version. No need to have it as separate package.

Toni

[saintless]

Hi, Fred.
Quick tested new gdrive-get and I like the improvements

- download list stays open while downloading, to have the chance to select more again (I'm not sure yet if I like it this way, what's your opinion ?)

I like this new option to choose more files after the download finish. If you ask me keep it.

Some things I'd like to implement also for smokey-get later (specially I like the filetype filter) but I'd like to know what you think also.

Any way you like to change or improve smokey-get is fine for me, Fred.

The one thing I do not like is elinks dependency that adds too much for DebianDog-Squeeze, but I keep there the old versions.

Toni

[fredx181]

Hi Toni,

Edit: Reading gsudo script I think it is not a problem to rename it to gsu for next iso update but it needs yad and (if I do not mistake) standard debian system will most likely not have yad installed or yad repository available in sources list. This means every package with gsu line will have to start with auto-downloading and installing yad on first run or we must think of some other way to do it. Debian should have gksu installed already on the other hand.

Sorry,I may have lost track on this, you think of making a package for gsu or gsudo and create maybe symlink to gksu?

Is it alright if we can make the gsudo script work with something else than yad, e.g. zenity or gxmessage (gxmessage doesn't have the 'hide-text' option (for password) but zenity does have this option).
And possibly include the portable zenity in the gsu package.
Btw, how it is now, if the user installs latest zenity, it's not going to be used AFAIK, because /opt/bin/zenity is first in PATH, this needs fixed, I think.
I don't have good view on this at this moment, just some thoughts.

What is your opinion, Fred? Do you see packages compatibility with standard Debian as important?

Yes, but first priority in my opinion is that DD packages won't conflict with standard Debian.
And for such essential things as sudo or gksu it's important to have compatibility.

Quick tested new gdrive-get and I like the improvements

Ah, nice! Thanks to Stemsee for his suggestions!
I'll work soon on smokey-get to include these improvements.

Fred

[saintless]

Hi, Fred.

I don't have good view on this at this moment...

Me too Just posting the problems I see now in case I forget them later.

Sorry,I may have lost track on this, you think of making a package for gsu or gsudo and create maybe symlink to gksu?

I'm not sure yet what is the best option. Maybe adding official gksu dependency in DebianDog packages but then we need to add in status and available the information gsu provides gksu. Still inside every package that needs gsu we need to add symlink gsu pointing to gksu. Then for new packages we can use gsu=gksu if gksu is installed. Let me think a little bit more about this and I will make a suggestion.

Is it alright if we can make the gsudo script work with something else than yad, e.g. zenity or gxmessage (gxmessage doesn't have the 'hide-text' option (for password) but zenity does have this option).
And possibly include the portable zenity in the gsu package.

It could be one way to solve the problem but I'm sure there is easier solution keeping yad and making the packages to use gksu for official debian.

Btw, how it is now, if the user installs latest zenity, it's not going to be used AFAIK, because /opt/bin/zenity is first in PATH, this needs fixed, I think.

I think the best way to go here is to make deb package with portable zenity and add new zenity version as conflicting package. Then installing the new one will uninstall portable zenity.

Yes, but first priority in my opinion is that DD packages won't conflict with standard Debian.
And for such essential things as sudo or gksu it's important to have compatibility.

I'm sure we can have all in one for the next iso update. I will think a bit more about packages compatibility problem and make a suggestion how to solve it best in my opinion.

Toni

[fredx181]

Hi Toni,

Me too Smile Just posting the problems I see now in case I forget them later.
Quote:
Sorry,I may have lost track on this, you think of making a package for gsu or gsudo and create maybe symlink to gksu?

I'm not sure yet what is the best option. Maybe adding official gksu dependency in DebianDog packages but then we need to add in status and available the information gsu provides gksu. Still inside every package that needs gsu we need to add symlink gsu pointing to gksu. Then for new packages we can use gsu=gksu if gksu is installed. Let me think a little bit more about this and I will make a suggestion.

It seems like you have more view on this matter than me.
But tell me if I can change the gsudo script, for example to basically something like:
If yad is installed then use yad, else use zenity if installed, if not, use gxmessage or (maybe even better) gtkdialog.

I think the best way to go here is to make deb package with portable zenity and add new zenity version as conflicting package. Then installing the new one will uninstall portable zenity.

Yes, I will make it, can you put it on the changes list?

Fred

[saintless]

Hi, Fred.

Zenity deb package change included in next version fixes post.

The problem with gsu and other packages containing gsu line could be solved easy by changing gsu to gksu (or adding extra gksu line in case gsu is missing). But we have mirrored many old iso versions and this will make the new packages from section included incompatible with some of the previous DebianDog versions. But I'm sure we will find a way to fix this properly for the next update.

BTW I'm adding in fixes post again apt-get upgrade. I see wget is upgradable already and maybe other programs will need security updates too.

Toni

[fredx181]

Hi Toni,

Here's attached: different ktsuss, compiled with sudo enabled so it will work for user password.
The gsu script needs then changed to:

Code: Select all

ktsuss -u root -m "Enter password for $USER" "$@"

Perhaps this helps solving the problem.

Edit: Removed attachment ktsuss-sudo, as it's really not working as expected.

Fred

[saintless]

Here's attached: different ktsuss, compiled with sudo enabled so it will work for user password.

Thank you, Fred, I will test it.

But I do not think it will solve the problem. Instead yad we will need available for reintsalling moded ktsuss and it must conflict with official debian ktsuss package. i think it is better to keep yad as dependency. it is already uploaded in section included on the site and if we make official DebianDog repository yad will be available there.

The main problem as I see it is adding gsu in the scripts and gsu is not available command in debian. We can change it to gksu in all scripts and create gksu package that conflicts with official debian gksu, but this will make the included packages (after we mod them) incompatible with previous DebianDog versions. And seems we have many old versions available for download (not only in my google-drive) here, here and here for example. We have also DevilDog that depends on DebianDog iso as a base and we could break something there changing already existing scripts.

For me the safe way is to keep the included packages and scripts in /opt/bin and to add symlink to /usr/local/bin line in postinst script only in the packages for reinstalling and mod them to prevent conflicts + adding all needed dependencies.

I'm testing some options here but it is too early to say it is the best way to fix the problem:
http://smokey01.com/saintless/DebianDog ... sting/tmp/
The gsu package for example contains yad dependency and creates symlink /opt/bin/gsu to /usr/local/bin/gsu. The gsu package does not conflict with gksu and both can be installed.
Yad is uploaded in section included and if we make it official DebianDog repository it will be added in sources list. The same can be done in standard Debian and yad and gsu will be installable with apt-get.
If gsu is installed it will create link /usr/local/bin/gsu pointing to /opt/bin/gsu
If other package (sfs-gets-smokey-get for example) is installed it has line in postinst to check for /usr/bin/gksu and if it is available will link it to /usr/local/bin/gsu. The package also contains dependency gsu or gksu. If gksu is already installed it will not install gsu but only create gksu symlink /usr/local/bin/gsu
We can use this method for the included packages but for not-yet-included and new packages we can change the location from /opt/bin to /usr/local/bin and even change the gsu line to search also gksu if gsu is not installed. Maybe we can also change the included scripts with gsu line to search for gksu also if it is available and this could prevent better some incompatibility troubles with old DebianDog versions but I'm not sure about this yet.

Edit: Maybe it seems not very important issue and we can continue further as it is, but this problem reminds me the multiuser and wrong permissions problem we had in the past. If we fix it now and make new DebianDog packages properly - the development will be much easier in the future.

Edit2: I'm starting to like more and more the idea to change the gsu line inside the included packages uploaded on the site. If we change it to use gksu if gsu not found then we can skip the symlinks to /usr/bin/gksu in the packages. And this should not break anything in the old iso versions. Reinstalling the included package in old DD version will still use gsu line and skip searching for gksu since gsu is available. I will make some tests in the next days.

Toni

[anikin]

Hi Toni, Fred et al,

Nice to see the whole DD crew is back in the sweatshop again!
Debian will never cease to surprise me, here's another little discovery. Debian's binaries by default are compiled as i386, unlike for example, Arch Linux with its default i686 architecture. This may look like a bit of disadvantage, but the situation isn't entirely hopeless, as Debian has a bit of everything for everyone. It has a GLIBC package optimized for i686. https://packages.debian.org/wheezy/libc6-i686

This set of libraries is optimized for i686 machines, and will only be used on an i686 class CPU (check the output of `uname -m'). This includes Pentium Pro, Pentium II/III/IV, Celeron CPU's and similar class CPU's (including clones such as AMD Athlon/Opteron, VIA C3 Nehemiah, but not VIA C3 Ezra)

Great, let's perform a dangerous experiment. To celebrate Fred's comeback, I will do it on his DD, he will accept the blame in case of failure.

root@dog:~# ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u4) 2.13
root@dog:~#

root@dog:~# apt-get install libc6-i686
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
libc-bin libc6
Suggested packages:
glibc-doc locales
The following NEW packages will be installed:
libc6-i686
The following packages will be upgraded:
libc-bin libc6
2 upgraded, 1 newly installed, 0 to remove and 22 not upgraded.
Need to get 6301 kB of archives.
After this operation, 2716 kB of additional disk space will be used.
Do you want to continue [Y/n]? Y
...
Preconfiguring packages ...
(Reading database ... 31436 files and directories currently installed.)
Preparing to replace libc-bin 2.13-38+deb7u4 (using .../libc-bin_2.13-38+deb7u6_i386.deb) ...
Unpacking replacement libc-bin ...
Setting up libc-bin (2.13-38+deb7u6) ...
(Reading database ... 31437 files and directories currently installed.)
Preparing to replace libc6:i386 2.13-38+deb7u4 (using .../libc6_2.13-38+deb7u6_i386.deb) ...
Unpacking replacement libc6:i386 ...
Setting up libc6:i386 (2.13-38+deb7u6) ...
Selecting previously unselected package libc6-i686:i386.
(Reading database ... 31437 files and directories currently installed.)
Unpacking libc6-i686:i386 (from .../libc6-i686_2.13-38+deb7u6_i386.deb) ...
Setting up libc6-i686:i386 (2.13-38+deb7u6) ...

Done. We have a new directory created at /lib/i386-linux-gnu/i686/

root@dog:~# ldd --version
ldd (Debian EGLIBC 2.13-38+deb7u6) 2.13
root@dog:~#

In theory DD should now run a bit faster and consume less power. Maybe future upgrades should have this package installed, what you think, guys?

Taking this opportunity, Fred, this DD is really nicely built, I fully agree with jrb. What I don't like though, the shutdown menu occupies almost the whole screen. It is disproportionately large. Nice to have the terminal in the bar, why is it also duplicated on the desktop?

edit I'm not sure, i386 is Debian's actual architecture. It might well be i486, or even a recent upgrade to i586 as seen mentioned somwehere. But it definitely is NOT i686.

[saintless]

Hi, Anikin.

Quick calculation shows libc6-i686 will add 832KB to the iso size.
Even less because for next version we will execute apt-get upgrade and this will free some space reading the terminal output:

Code: Select all

root@debian:~# apt-get upgrade
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages have been kept back:
  lame roxterm-gtk2
The following packages will be upgraded:
  apt apt-utils base-files ca-certificates curl debian-archive-keyring file
  libapt-inst1.5 libapt-pkg4.12 libc-bin libc6 libcurl3 libcurl3-gnutls
  libgcrypt11 libkeyutils1 libmagic1 libperl5.14 libssl1.0.0 libtasn1-3
  libxml2 live-config live-config-sysvinit multiarch-support openssl perl
  perl-base perl-modules rsyslog tzdata wget wpasupplicant
31 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 26.2 MB of archives.
After this operation, 1090 kB disk space will be freed.
Do you want to continue [Y/n]? y

I will add libc6-i686 in next version changes post (if Fred doesn't mind).

Toni

[saintless]

Hi, Fred.

Instead creating symlink gsu to /usr/bin/gksu in DD packages I think we can replace gsu line in the scripts from:

Code: Select all

[ "`whoami`" != "root" ] && exec gsu ${0}

to

Code: Select all

if [ -z `which gsu` ]; then
[ "`whoami`" != "root" ] && exec gksu ${0}
else
[ "`whoami`" != "root" ] && exec gsu ${0}
fi

Still we need to add "gsu | gksu" as dependency in packages with gsu line (existing and new packages).
Then:
We skip symlinking in postins script.
We do not need to change existing packages in DD (except the packages with conflicting files like frisbee and sns), but I think it is good to reinstall all moded packages anyway for next version.
All moded packages from included will be compatible with old DD versions (and with standard Debian if we add all needed dependencies inside Control file).
I think this is the best way to do it.
if you agree I will start editing and testing packages from section included in the next days and see if I can find something more missing in packaging method post.
We can change gsu line different way if you have better suggestion from the above example. The point is if gsu is not installed to make sure gksu will be used. Since "gsu | gksu" is added in Control we make sure the script will find the needed command.

Toni

[fredx181]

Still we need to add "gsu | gksu" as dependency in packages with gsu line (existing and new packages).
Then:
We skip symlinking in postins script.
-----
......

Thanks, Toni!

It seems like you figured it out well, I don't understand all but I trust you
Couldn't take the time last few days to test and think about these things.
So if you are sure the editing of the scripts with gsu line cannot be avoided, I agree with the way you proposed.
And libc6-i686 could give advantage maybe and since it's so small I don't mind.

Anikin, I'll reply later more, thanks for your suggestions!

Edit: could you send screenshot of the extremely large shutdown dialog?
I've never seen it like that, maybe it depends on the resolution of the screen, I have only at most 1024X768.

Fred

[anikin]

Hi Toni, Fred et al,

Here's the screenshot.

[saintless]

Hi, Fred.

So if you are sure the editing of the scripts with gsu line cannot be avoided, I agree with the way you proposed.

It can be avoided if we use symlink lines in postinst in every package that needs gsu.
But I think it is better to edit the gsu line instead creating symlinks in each package. This will make the scripts universal for debian based system.
And we nee to use the new gsu + gksu line in the future when we make scripts,
Note we do not need to edit gsu line in scripts already included in the iso.
We need to do it only in the scripts inside the packages uploaded on the site. And we can reinstall only the packages that have conflicting files from apt-check reports you made for the next update.

It will take some time and I will ask you for help for some packages. Maybe some better solution will come up later.

Edit: Fred, if you prefer not to use gsu + gksu line in new scripts in the future we can do it by adding symlink lines in the packages. This means some more work for each new package but I do not mind to use symlinking instead changing gsu line inside the packages. Both solutions will work.
On the other hand I suggest in the future not to use unique names for dependency scripts like gsu. Many scripts use gsu and this unique gsu name makes all scripts incompatible for other debian system.
No need to do it this way since we have gksu standard script and actually gsu is gksu alternative. We can try to avoid this in the future.
The best fix for me is to change gsu name to gksu and make package gksu-debdog addiing as conflicting package debian gksu. But it is too late for such fix now.

Toni