Woof CE Debian Stretch and Devuan Ascii Based Development

[Billtoo]

I did a new woof-CE (auto build) this morning.

System: Host: puppypc26908 Kernel: 3.14.79 i686 (32 bit) Desktop: JWM 2.3.6 Distro: Dpup Stretch 7.0.0a1
Machine: Device: desktop System: Compaq-Presario product: AU194AA-A2L CQ5123F serial: MXX9300M0F
Mobo: MSI model: Boston v: 1.0 BIOS: Phoenix v: 5.24 date: 06/19/2009
CPU: Dual core Pentium E5200 (-MCP-) speed/max: 1200/2500 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.19.1 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
tty size: 150x39 Advanced Data: N/A for root
Network: Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
Card-2: D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT2571W] driver: rt73usb
Drives: HDD Total Size: 500.1GB (10.5% used)
Info: Processes: 99 Uptime: 2:22 Memory: 196.6/3160.7MB Client: Shell (bash) inxi: 2.3.8

There are a few new bugs, there was no way to change the wallpaper in JWM or FbBox, I added 2 pets
mkwallpaper-0.8-i686_s700.pet and mkwallpaper-gui-2.3_32Bit.pet, that worked.
Geany can read,edit,and save a file but can't create a new file because the Save As command causes it to crash.
Same thing with Libre Office writer, permissions must be wrong I guess.

The build took less time even though I did it on a slower computer, approx. 1 hour on a dual core i3 with HT.

[ttuuxxx]

Here's 2 more backgrounds One is basic yet effective and the other well it has flare, lol

[ttuuxxx]

I did a new woof-CE (auto build) this morning.

System: Host: puppypc26908 Kernel: 3.14.79 i686 (32 bit) Desktop: JWM 2.3.6 Distro: Dpup Stretch 7.0.0a1
Machine: Device: desktop System: Compaq-Presario product: AU194AA-A2L CQ5123F serial: MXX9300M0F
Mobo: MSI model: Boston v: 1.0 BIOS: Phoenix v: 5.24 date: 06/19/2009
CPU: Dual core Pentium E5200 (-MCP-) speed/max: 1200/2500 MHz
Graphics: Card: NVIDIA GF108 [GeForce GT 430]
Display Server: X.org 1.19.1 drivers: nouveau (unloaded: modesetting,fbdev,vesa)
tty size: 150x39 Advanced Data: N/A for root
Network: Card-1: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
Card-2: D-Link System AirPlus G DWL-G122 Wireless Adapter(rev.C1) [Ralink RT2571W] driver: rt73usb
Drives: HDD Total Size: 500.1GB (10.5% used)
Info: Processes: 99 Uptime: 2:22 Memory: 196.6/3160.7MB Client: Shell (bash) inxi: 2.3.8

There are a few new bugs, there was no way to change the wallpaper in JWM or FbBox, I added 2 pets
mkwallpaper-0.8-i686_s700.pet and mkwallpaper-gui-2.3_32Bit.pet, that worked.
Geany can read,edit,and save a file but can't create a new file because the Save As command causes it to crash.
Same thing with Libre Office writer, permissions must be wrong I guess.

The build took less time even though I did it on a slower computer, approx. 1 hour on a dual core i3 with HT.

Does it compile out of the box ?
The compiler I have is very limited.
ttuuxxx

[Billtoo]

Does it compile out of the box ?
The compiler I have is very limited.
ttuuxxx

Yes, I just compiled Mplayer-1.3.0 so I could answer your question

[ttuuxxx]

Does it compile out of the box ?
The compiler I have is very limited.
ttuuxxx

Yes, I just compiled Mplayer-1.3.0 so I could answer your question

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.
Also man I don't think I'll ever get used to taskbar uptop and the jwmrc-tray2 on the bottom, I hate that tray, More of a traditional desktop guy on the bottom with icons and no extra trays. Took me about 2 mins to fix it up the way I like it
ttuuxxx

[Billtoo]

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.

[ttuuxxx]

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.

Yes it gives you a very unstable compiler, I've came across somethings that compile to the last step just before it builds the bin's and says it couldn't and doesn't really give much of an error. If you work it out let me know. I actually found better compiling results if you install debian Jessie gcc and a few other libs from debian packages, you'll get bin files but then somethings don't compile.

[musher0]

Hi ttuuxxx and all.

I don't know C so I probably can't help much. Still, asking the right
questions may point us in the right direction:

Can we retrace the steps that lead to this situation?
What is its history?
Is it local or upriver?
Do devs in other distros have the same complaint?
What do LFS or other reliable sources say?
If we (re)compile the new gcc toolchain from one that's healthy (that how
it's done, isn't it?), would it solve the problem?
Is it actually the gcc or is the origin of the problem in the glibc?

My 2¢. IHTH.

[ttuuxxx]

Hi ttuuxxx and all.

I don't know C so I probably can't help much. Still, asking the right
questions may point us in the right direction:

Can we retrace the steps that lead to this situation?
What is its history?
Is it local or upriver?
Do devs in other distros have the same complaint?
What do LFS or other reliable sources say?
If we (re)compile the new gcc toolchain from one that's healthy (that how
it's done, isn't it?), would it solve the problem?
Is it actually the gcc or is the origin of the problem in the glibc?

My 2¢. IHTH.

Well its usually best to compile it on the host system, So that things like libc and kernel are compatible. I started compiling gcc, and ran into a few issues, its 3:22 am time for bed I'll work on it for a bit tomorrow before work, Its a long compile usually, like Firefox Hopefully its that
ttuuxxx

[anikin]

Just a couple noobish thoughts:
In the toolchain, gcc is dependent on binutils, and it's an *absolutely* tight dependence - (binutils >= 2.27.90.20170124)
https://packages.debian.org/stretch/gcc-6
https://packages.debian.org/stretch/binutils
Do you guys have the required version of binutils? Also, I would go carefully through the list of all the other dependencies in the above Debian links, to make sure you really have a native compile environment.

BTW, gcc-6 isn't uniquely Debian's choice. All the major distros are adopting it - a call of times. So rolling back to an older (Jessie) version of GCC is not an option.

Maybe, some additional clues can be found here:
http://linuxfromscratch.org/lfs/view/de ... 6/gcc.html

[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