Woof CE Debian Stretch and Devuan Ascii Based Development

[666philb]

Also, I know it's not important, but has anyone been able to fix this since I (and Musher) mentioned it back in the woof-CE thread? Every single item you search for in PPM shows it as "ALREADY INSTALLED". Here's an example for VLC, which is nowhere in this build:

not sure if someone has already answered this, but there's a bug in /usr/local/petget/findnames.sh

i've posted about the issue on woofCE, but until it's fixed there you can use this older one

[Sailor Enceladus]

I'm trying out belham2 stretch version and when I compile live on it, By loading the devx on the fly, I get the same issue I had with my versions, Sometimes depending what you compile you get a lib type file when you should have a bin. For example look at the picture, Clearly it should be an executable file, if you click on it it doesn't start but if you use the .desktop file it runs just fine.

Get the same result here, got a lib type file for Mplayer-1.3.0.

When I compiled MPlayer 1.3 in Slacko the bin shows up with a lib icon in Rox too, so I guess it's not just with the dpups.

[musher0]

Hello all.

I really got fed up with the screen capture situation on this Stretch. SFR's
Take-a-shot does not work on it, and I have always found Screeny
unpractical and cumbersome.

I'm a co-operator at heart, not a competitor, so this little endeavor is not
meant to put anybody down. However, I badly needed an agile capture
utility in the context of this Stretch, so I decided to create one! And...
"If there is a genuine need, it will be met," as once said the great
American novelist Henry Miller.

~~~~~~~~~~~~~

This script requires:

-- vovchik's aemenu-pango system and

-- mtpaint.


Features:

-- Access to a potentially handy thin "run" terminal is provided.

-- A how-to will open if you hover the mouse vis-a-vis the title.

-- It automatically detects the language of your system (only FR and EN at
the moment; other translations welcome), based on the $LANG variable.

-- Tolerates other running instances of aemenu. Handy if you want to do a
screen cap of another aemenu.

-- This menu can move itself. If you wish to move it, click on the
separator nearest the direction you want to go.

Of course, if you want to move this menu from the bottom left of the
screen to the top right of the screen, it will tax your patience a bit, but
you'll get there!

This is the closest I could come to replicating the pekwm drag-menu
feature from within an aemenu.


Caveat:

-- If you edit anything in the strings or the entries, you'll have to erase
file /tmp/snapshot and re-run the script to see the changes.

~~~~~~~~~~~~~

The attached screen illustrations were created with it. This means that if
you wish to capture another aemenu opened on screen with it, you can.
Or any other menu, of course.

Please find attached and test to your heart's content. As usual,
constructive criticism welcome.

Enjoy!

~~~~~~~~~~~~~~

Code: Select all

#!/bin/sh
# /usr/bin/SnapshotMenu.sh # Lien : / Link: /usr/bin/Snapshots
# V. 01
#
# Requiert : / Requires:
# /usr/bin/aemenu-pango & /usr/local/bin/bcm (vovchik),
# ($MBINS/terminaux/)console-tres-mince.sh (musher0).
#
# Optionnel : / Optional: AkizaSans (font[e]).
#
# (c) musher0, Gatineau (Qc), Canada, 3 mars 2017. GPL3
####
killall -q aemenu;sleep 0.1s
export MBINS="/root/my-applications/bin"
# LANG="en_US.UTF-8"

if [ ! -f /tmp/snapshot ];then
	TitrE="Captures"

	ClRLignE="`cat /usr/local/share/MRUF/CouleurLigne`" || ClRLignE="DarkSeaGreen2"
	SprtR2="<span color='$ClRLignE'>

[OscarTalks]

The binutils package does appear to be installed.
In fact mplayer has been producing bins that look like libs for some time in other Puppies but it was just about the only program that did this.

The thing is, it is not just the programs we are compiling that display this. If you look in /usr/bin many of the Debian bins look like shared libs. If I unpack a Stretch .deb in Wheezy (as I did with binutils for example) the bins show as libs in Wheezy too.

Does anybody know if this is some attribute which the compiler sets?
Is there a configuration setting for the compiler?
Attempting a re-compile of gcc sounds like an interesting experiment.
Perhaps there is some way to edit this post-compilation?

The only function which does not work that I have found is exectuting from file manager by clicking. ROX and PCManFM both have the same result. Menu and .desktop file launching works as does starting from terminal. I take it this is not just a mime issue?

[belham2]

[quote="musher0"]Hello all.

I really got fed up with the screen capture situation on this Stretch. SFR's
Take-a-shot does not work on it, and I have always found Screeny
unpractical and cumbersome.

I'm a co-operator at heart, not a competitor, so this little endeavor is not
meant to put anybody down. However, I badly needed an agile capture
utility in the context of this Stretch, so I decided to create one! And...
"If there is a genuine need, it will be met," as once said the great
American novelist Henry Miller.

~~~~~~~~~~~~~

This script requires:

-- vovchik's aemenu-pango system and

-- mtpaint.


Features:

-- Access to a potentially handy thin "run" terminal is provided.

-- A how-to will open if you hover the mouse vis-a-vis the title.

-- It automatically detects the language of your system (only FR and EN at
the moment; other translations welcome), based on the $LANG variable.

-- Tolerates other running instances of aemenu. Handy if you want to do a
screen cap of another aemenu.

-- This menu can move itself. If you wish to move it, click on the
separator nearest the direction you want to go.

Of course, if you want to move this menu from the bottom left of the
screen to the top right of the screen, it will tax your patience a bit, but
you'll get there!

This is the closest I could come to replicating the pekwm drag-menu
feature from within an aemenu.


Caveat:

-- If you edit anything in the strings or the entries, you'll have to erase
file /tmp/snapshot and re-run the script to see the changes.

~~~~~~~~~~~~~

The attached screen illustrations were created with it. This means that if
you wish to capture another aemenu opened on screen with it, you can.
Or any other menu, of course.

Please find attached and test to your heart's content. As usual,
constructive criticism welcome.

Enjoy!

~~~~~~~~~~~~~~

Code: Select all

#!/bin/sh
# /usr/bin/SnapshotMenu.sh # Lien : / Link: /usr/bin/Snapshots
# V. 01
#
# Requiert : / Requires:
# /usr/bin/aemenu-pango & /usr/local/bin/bcm (vovchik),
# ($MBINS/terminaux/)console-tres-mince.sh (musher0).
#
# Optionnel : / Optional: AkizaSans (font[e]).
#
# (c) musher0, Gatineau (Qc), Canada, 3 mars 2017. GPL3
####
killall -q aemenu;sleep 0.1s
export MBINS="/root/my-applications/bin"
# LANG="en_US.UTF-8"

if [ ! -f /tmp/snapshot ];then
	TitrE="Captures"

	ClRLignE="`cat /usr/local/share/MRUF/CouleurLigne`" || ClRLignE="DarkSeaGreen2"
	SprtR2="<span color='$ClRLignE'>

[belham2]

Also, I am presently including/putting in the following in the dpup-stretch build I did, and so far I see no problems from them:

--Youtube-Getv2

--SmokeyGet

--Dogradio

--Edit-SFS

--Convert-SFS

--Pet2Deb (isn't this already included, via terminal or by default, in dpups??)

--Pet2SFS (same question as above??)

[jamesbond]

@gcc-compilation-problems: me thinks the problem with elsewhere, not with gcc. If you can use the compiler to build something as complex as mplayer until it completes, the toolchain is fine. Especially one of you said that that even though that "mplayer" is shown as "lib", if you create a desktop file, it will launch and work correctly.

Rather, the problem seems to be caused by ROX mis-identification of the file. Try to open terminal, and run "file /path/to/newly/compiled/binary" and see what it has to say. Compare that output with that you see when you run "file /path/to/a/know/library/file.so".

@screenshot-problems: I would humbly offer my simple screen capture tool. WM and desktop, agnostic, only depends on libX11 and libXfixes. I once joked with SFR that I intended to enhance this tool to make TAS obsolete Notes about the tool here, and tarball here. As a bonus you get Xannotate too. Its in C, so you have to compile it, but it has no other dependency.

[ttuuxxx]

@gcc-compilation-problems: me thinks the problem with elsewhere, not with gcc. If you can use the compiler to build something as complex as mplayer until it completes, the toolchain is fine. Especially one of you said that that even though that "mplayer" is shown as "lib", if you create a desktop file, it will launch and work correctly.

Rather, the problem seems to be caused by ROX mis-identification of the file. Try to open terminal, and run "file /path/to/newly/compiled/binary" and see what it has to say. Compare that output with that you see when you run "file /path/to/a/know/library/file.so".

@screenshot-problems: I would humbly offer my simple screen capture tool. WM and desktop, agnostic, only depends on libX11 and libXfixes. I once joked with SFR that I intended to enhance this tool to make TAS obsolete Notes about the tool here, and tarball here. As a bonus you get Xannotate too. Its in C, so you have to compile it, but it has no other dependency.

Well when I install Gcc 4.9 from Jessie I get the proper outcome, below is images of Gcc 6 VS 4.9 and the packages I used/compiled.

[jamesbond]

Yeah ttuuxxx, but does the "leafpad" binary you get from gcc-6 compilation works correctly? Don't try to launch it from Rox, instead, open terminal, cd to the build path, then run it from there (./leafpad); does it launch and work if you do it that way? If it does, then it is Rox problem, not gcc problem.

[OscarTalks]

Is it anything to do with the ELF headers being wrongly set?
readelf -h /path/to/file
If so, how are these headers defined?
Effect is the same in PCManFM as well as ROX

[belham2]

Also, I know it's not important, but has anyone been able to fix this since I (and Musher) mentioned it back in the woof-CE thread? Every single item you search for in PPM shows it as "ALREADY INSTALLED". Here's an example for VLC, which is nowhere in this build:

not sure if someone has already answered this, but there's a bug in /usr/local/petget/findnames.sh

i've posted about the issue on woofCE, but until it's fixed there you can use this older one

Thank you, Phil! The old findnames.sh you provided for download cleared the problem up right away.

[B.K. Johnson]

@musher0
I installed & ran the pet from tahr-6.0.5 not Stretch.

Is the download the same that created the snapshot displayed? I got a "plain Jane" display of only the durations list.

As you noted in your post, This text appears only when I move the cursor to the triangle/arrow on the header.
"Prepare the items on your screen,\" \" \"
cmd \"anticipate how much time you will need\" \" \"
cmd \"for the mouse movements, and then\" \" \"
cmd \"click on the number of seconds required.\" \" \"
cmd \" \" \" \"
cmd \"Uses mtpaint.\" \" \""

Most puppies will have /usr/aemenu-pango & /usr/local/bin/bcm & /usr/local/bin/console-tres-mince.sh installed, and I do. But most will not have /usr/local/share/MRUF/ and so, CouleurLigne, DarkSeaGreen2, AkizaSans, DejaVuSans or bisque would not be available. So, the graphic in the post is misleading FOR THE REST OF US.

Access to a potentially handy thin "run" terminal is provided.

Potential confirmed! But why not leave it out until you have it. It is confusing to users who click on 'Run' and see nothing visible happening.

Otherwise, selection of a time interval worked.

Question: With respect, I ask: Why such a convoluted name as "mtPaint-snapshot screen capture"? Not sure I'll keep this pet, but while it is on my pup, it will be named "snapshot".

Note: I don't intend to fight with you. These are observations which you may consider if you choose to improve the offering so that it will have a wider audience if you desire. Hope you consider the comments constructive.

[ttuuxxx]

Yeah ttuuxxx, but does the "leafpad" binary you get from gcc-6 compilation works correctly? Don't try to launch it from Rox, instead, open terminal, cd to the build path, then run it from there (./leafpad); does it launch and work if you do it that way? If it does, then it is Rox problem, not gcc problem.

So what your saying is that Rox is handling things compiled in Gcc6 differently than Gcc4.9, One says ELF 32-bit LSB executable,
the other says ELF 32-bit LSB shared object
ttuuxxx

[jamesbond]

Is it anything to do with the ELF headers being wrongly set?
readelf -h /path/to/file

Not wrongly set, but changed. I know from gcc 5.2.0 onwards (or may be even earlier 5.x, I didn't test anything before 5.2.0), gcc produces slightly different ELF header than earlier ones, at least for 64-bit target. I didn't test for 32-bit target so I can't confirm.

If so, how are these headers defined?
Effect is the same in PCManFM as well as ROX

It doesn't matter how these headers are defined, it only matters how the detection routine works.
My guess it that Rox and pcmanfm uses the same "file-identification" logic, the one usually is inside the shared-mime package. If you want to know how this identification works, look no further than /usr/share/mime/packages/freedesktop.org.xml, and search for "x-executable" you will see what I mean. Compare that with "x-sharedlib". As you can see it look at bytes in certain locations. The difference between programs and libraries (as far as Rox/pcmanfm is concerned) are in those bytes listed there.

Are you using older version of shared-mime, instead of the current one?

So what your saying is that Rox is handling things compiled in Gcc6 differently than Gcc4.9, One says ELF 32-bit LSB executable,
ELF 32-bit LSB shared object

No, I'm saying that Rox mis-recognises the file. I have a feeling that the file itself is fine. Can you launch "leafpad" from terminal as I said earlier?

Also, if you can upload your "leafpad" compiled under gcc-6, I can check it here.

[ttuuxxx]

So what your saying is that Rox is handling things compiled in Gcc6 differently than Gcc4.9, One says ELF 32-bit LSB executable,
ELF 32-bit LSB shared object

No, I'm saying that Rox mis-recognises the file. I have a feeling that the file itself is fine. Can you launch "leafpad" from terminal as I said earlier?

Also, if you can upload your "leafpad" compiled under gcc-6, I can check it here.

Yes it can launch via terminal and .desktop, but its also a bit a larger before and after stripping. I put them both in this package.
ttuuxxx

[jamesbond]

Ok apparently your gcc6 is indeed creating share libs instead of executable binaries .

I tested with with the latest readelf (binutils 2.27) and it also shows one file is DYN (shared lib) and one is EXEC (binary), so OscarTalk is right. The rest (shared-mime/rox/pcmanfm) just follows whatever is given in the file.

I'm not sure if this is Debian's default configuration or what. I have gcc 6.2.0 running (from LFS 7.10), and it produces files of the correct type just fine. You said above that official DEBs from Stretch, when extracted, all the files shows up as shared library as well, correct? May be it's Debian's compiler configuration then. Or a bug in their binutils.

Either way, it's back to square one.

[ttuuxxx]

Ok apparently your gcc6 is indeed creating share libs instead of executable binaries .

I tested with with the latest readelf (binutils 2.27) and it also shows one file is DYN (shared lib) and one is EXEC (binary), so OscarTalk is right. The rest (shared-mime/rox/pcmanfm) just follows whatever is given in the file.

I'm not sure if this is Debian's default configuration or what. I have gcc 6.2.0 running (from LFS 7.10), and it produces files of the correct type just fine. You said above that official DEBs from Stretch, when extracted, all the files shows up as shared library as well, correct? May be it's Debian's compiler configuration then. Or a bug in their binutils.

Either way, it's back to square one.

I tried compiling Gcc 4.9 last night and had errors, so I'm trying Gcc 7.0 and so far so good after 15mins Touch wood
ttuuxxx

[ttuuxxx]

I'm compiling it with fortran do we even use that anymore, Heck back in 1996 when I was in Uni we were using that.
I don't think any puppy apps compile with fortran do they?
ttuuxxx

[belham2]

I'm compiling it with fortran do we even use that anymore, Heck back in 1996 when I was in Uni we were using that.
I don't think any puppy apps compile with fortran do they?
ttuuxxx

Eeeeee, gods, there goes my Friday. Thanks a lot, ttuuxxx. Horrid memories in early 80s university school sitting in Fortran staring at the Indian fellow scribbling that gunk across the board like there was no tomorrow. And that sinking feeling of being totally lost, staring down on the floor at my ~500 high stack of mixed up compiler cards .........jeeezus what a freak show that all was.

[ttuuxxx]

I'm compiling it with fortran do we even use that anymore, Heck back in 1996 when I was in Uni we were using that.
I don't think any puppy apps compile with fortran do they?
ttuuxxx

Eeeeee, gods, there goes my Friday. Thanks a lot, ttuuxxx. Horrid memories in early 80s university school sitting in Fortran staring at the Indian fellow scribbling that gunk across the board like there was no tomorrow. And that sinking feeling of being totally lost, staring down on the floor at my ~500 high stack of mixed up compiler cards .........jeeezus what a freak show that all was.

Yeah not much uses it these days, It originally came out in the 1950's, Most the time Barry doesn't include it due to the size and it not widely being used anymore, I included with the build I'm doing because it was specified by LFS but really I don't see the need, I'll see how large the files are and If I have to recompile without it so be it. Around 1hr of compiling gcc 7 now
ttuuxxx