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

For talk and support relating specifically to Puppy derivatives
Message
Author
User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3871 Post by 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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3872 Post by 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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3873 Post by 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
Last edited by fredx181 on Mon 29 Dec 2014, 21:58, edited 2 times in total.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3874 Post by saintless »

fredx181 wrote: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
Posts: 994
Joined: Thu 10 May 2012, 06:16

#3875 Post by 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.

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3876 Post by 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

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3877 Post by 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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3878 Post by 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
Posts: 994
Joined: Thu 10 May 2012, 06:16

#3879 Post by anikin »

Hi Toni, Fred et al,

Here's the screenshot.
Attachments
shutdownmenu.jpeg
(32.64 KiB) Downloaded 255 times

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3880 Post by saintless »

Hi, Fred.
fredx181 wrote: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

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3881 Post by fredx181 »

Hi Toni,
fredx181 wrote:
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.
.....
.....
Ok, it's only for the packages, not the included scripts so all we have to do is change the gsu line in the existing packages and then reinstall them for next release. And there will be a 'gsu.deb' I suppose.
It's fine for me, did I summarize this well?
I suggest to use the gsudo script (change name to gsu), the yad version or the gsu version pointing to ktsuss-sudo (the one I uploaded few days ago) if it works for you well
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.
Yes, good point.

About libc6-i686, are you sure it doesn't give problems for older computers? (you can test this better than me)

Fred

User avatar
saintless
Posts: 3862
Joined: Sat 11 Jun 2011, 13:43
Location: Bulgaria

#3882 Post by saintless »

Hi, Fred.
fredx181 wrote:Ok, it's only for the packages, not the included scripts so all we have to do is change the gsu line in the existing packages and then reinstall them for next release. And there will be a 'gsu.deb' I suppose.
It's fine for me, did I summarize this well?
Yes. There is gsu package (yad version) that contains your latest attached gsudo (renamed to gsu). It is here but maybe I will make some small changes inside Control file. Yad is also added in section included packages on the site.
We do not need to reinstall all moded packages, but I think it will be better to do it because of the new dependencies we will add in each package. It is good to update status file with the correct information for moded packages.
I suggest to use the gsudo script (change name to gsu), the yad version or the gsu version pointing to ktsuss-sudo (the one I uploaded few days ago) if it works for you well
I will test ktsuss-sudo version more but instead yad it will need moded ktsuss package conflicting with debian ktsuss package. I think it is easier to use yad version.
About libc6-i686, are you sure it doesn't give problems for older computers? (you can test this better than me)
I will test this properly but I think it is not a problem. The kernel for example is i686 reading the output from uname -a.

Toni
Last edited by saintless on Mon 24 Nov 2014, 21:19, edited 1 time in total.

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3883 Post by fredx181 »

Hi Anikin,

Looking at the screenshot you posted I see it's the same for me.
I thought for a while maybe the shutdown dialog icons are showing larger for you as for me.
I like the large icons, btw.

About duplicate launchers on desktop and panel I'm planning to clean things up for next release.
There are also lots of double entries in the menu (in different categories, though)
And the 'Accessories' category is to full.

Fred

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3884 Post by fredx181 »

Toni wrote:I will test ths ktsuss-sudo version more but instead yad it will need moded ktsuss package conflicting with debian ktsuss package. I think it is easier to use yad version.
There's only ktsuss package for SID, AFAIK.
A possibility maybe is to include the ktsuss-sudo in the gsu.deb, then you solve the problem of the yad dependency (since yad is not in Debian repo)

Fred

stemsee

#3885 Post by stemsee »

Hi Fred, Saintless, Anikin

I too think that the shutdwn icons are too large, however I think that if the grey border was transparent it would look much better!

stemsee

mcewanw
Posts: 3169
Joined: Thu 16 Aug 2007, 10:48
Contact:

#3886 Post by mcewanw »

I can't myself find any problem with big shutdown icons. It is for shutdown afterall and makes it easy to click the correct button! :-)

But I don't mind smaller icons either... not an issue either way

William
github mcewanw

User avatar
fredx181
Posts: 4448
Joined: Wed 11 Dec 2013, 12:37
Location: holland

#3887 Post by fredx181 »

Hi stemsee, anikin,

Ok, two strong opinions I can't resist :) I'll make the icons smaller (and total size smaller) for next release.
Transparency, I don't think it's possible but I'll have a look at it.

Fred

stemsee

#3888 Post by stemsee »


anikin
Posts: 994
Joined: Thu 10 May 2012, 06:16

#3889 Post by anikin »

Fred wrote:Ok, two strong opinions I can't resist :) I'll make the icons smaller (and total size smaller) for next release
Mine wasn't a strong opinion! :)
Well, guys, I don't have an issue with large icons, either. What I'm saying is that one particular component of the desktop is way out of proportion relative to other parts of the desktop GUI. BTW, it's not only the icons but font size also. Don't get me wrong, I'm not demanding or insisting on anything. Just some humble user feedback.

sklimkin
Posts: 157
Joined: Wed 11 Jul 2012, 21:21
Location: Russia Moscow

remasrering filesystem

#3890 Post by sklimkin »

Hi All.

In our topic a few months ago someone suggested a script to re-create the system. I liked the simplicity and reliability of this script. Thanks to the author for this nifty idea.
I took it when experimenting with different systems based on Debian, Ubuntu and Debian Dog.
Then decided to add to the author's script the GUI.
But in the GTK-dialog I have failed.
Then do it in C using GTK+

1 version: remaster-filesystem.zip - more user-friendly, but it does not correctly display lists in DebianDog (see screenshots 1-2-3-4)
2 version: 12remaster-filesystem.zip - made earlier, it is easier, but it works fine in DebianDog (see screenshots 5-6).
For the program needs a file 'remaster.sh.txt' to the original settings.
After the user changes in the three drop-down lists have to press the "write file".
User settings are stored in the file 'remasterout.txt' (for reuse).
Then, create a new (remastered) system image 'squashfs' file.
The file is created in the directory /tmp

This application I made to create a container squashfs-file from standard installed operating systems such as Ubuntu. But then decided to test the application of the established Frugal system (Ubuntu. Runtu, Debian, Debian Dog).
Application should be finished (correctly identify the names of user directories, exclude external file presets, etc.), but now it can be used for certain experimental tasks.

Source code and the compiled binary file attached - for both versions.
If someone wants to improve or correct something - read the source code, I commented on in detail.
I would be grateful for guidance on the errors found in the source code.

Sergey.
Attachments
remaster-filesystem.zip
1-st variant
(35.53 KiB) Downloaded 140 times
12remaster-filesystem.zip
2-nd variant
(31.34 KiB) Downloaded 134 times
1_scrot.png
1
(34.37 KiB) Downloaded 256 times
2_scrot.png
2
(130.36 KiB) Downloaded 261 times
3_scrot.png
3
(52.64 KiB) Downloaded 255 times
4_scrot.png
4
(47.19 KiB) Downloaded 252 times
5_scrot.png
5
(91.6 KiB) Downloaded 257 times
6_scrot.png
6
(105.52 KiB) Downloaded 252 times

Post Reply