woof-CE needs you

[jrb]

@jrb: I have a few 0 byte ones too, I think in my case it's because they're only used in the devx.

Thanks for checking Sailor. Could you check the contents of the automake folder and see if there is anything in it? As I say, when I checked mine it was empty.

[Lassar]

Deleted

[Sailor Enceladus]

@jrb: I have a few 0 byte ones too, I think in my case it's because they're only used in the devx.

Thanks for checking Sailor. Could you check the contents of the automake folder and see if there is anything in it? As I say, when I checked mine it was empty.

Yup. There's just two red symlinks which I think get removed, the rest is in automake_DEV and automake_DOC folders.

[Lassar]

Woof-ce needs to be changed so the internet comes up automatically.

Including the firewall.

Here is how to do it:

In /etc/init.d you need to copy rc.firewall in it.

In /etc/rc.d/rc.local add this line to it.

dhcpcd


Also you will need auto dhcp on.

Am I missing anything here?

[Sailor Enceladus]

Woof-ce needs to be changed so the internet comes up automatically.

Including the firewall.

Here is how to do it:

In /etc/init.d you need to copy rc.firewall in it.

In /etc/rc.d/rc.local add this line to it.

dhcpcd


Also you will need auto dhcp on.

Am I missing anything here?

I don't mind setting it up the first time, but I'm using wifi and there's lots of channels to pick from and my wifi has a password so it makes sense. Guessing you're talking about ethernet port internet, where you plug it in, and it doesn't connect automatically in your puppy when you first boot... wish I had that to test, because my wifi signal is far away so it cuts out a lot.

[peebee]

Help / advice requested....

In Slackware based builds Guile is a dependency of GnuTLS (but not apparently in Ubuntu/Debian builds).

Slackware Current has just updated to guile-2.2.3-i586-1.txz and one of the changes from previous
versions is that the type for .go files has changed:

e.g. 'file *.go' now gives:
ELF 32-bit LSB shared object, no machine, version 1 (embedded), dynamically linked, with debug_info, not stripped
'file --mime-type *.go' gives:
application/x-sharedlib

(previously 'file *.go' gave:
Guile Object, little endian, 32bit, bytecode v2.0
'file --mime-type *.go' gave:
application/octet-stream )

This change causes 2createpackages to spit out lots of error messages because strip at line #673 fails on .go files
which now pass the tests for strip to be applied (e.g. 'ELF' & 'shared object').

Another consequence of the change is that the installed contents of /usr/lib/guile/2.2/ccache
(which contains many .go files) has grown from c.5 MB to c. 35 MB (presumably because of debug_info)
however
it appears that /usr/lib/guile/2.2/site-ccache
can be deleted entirely in Woof-CE Puppy builds without introducing any unwanted consequences.

Not expecting a rush of answers, but if anybody can help with:
- is there a version of strip which can reduce the size of the 'new' .go files and should 2createpackages be amended to strip .go files?
- should there be a package-template for guile which deletes /usr/lib/guile/2.2/site-ccache (and possibly further parts of guile-2.2.3-i586-1.txz)?
- should guile be in the devx rather than the puppy.sfs? (as it appears to be a programming language)

Cheers
PeeBee

p.s. in LxPupSc-17.12+1T /usr/lib/guile/2.2/site-ccache has been deleted in _00build.conf

[amigo]

It sounds like it's maybe the version of 'file' which makes that difference.

[jamesbond]

Slackware Current has just updated to guile-2.2.3-i586-1.txz and one of the changes from previous
versions is that the type for .go files has changed:

e.g. 'file *.go' now gives:
ELF 32-bit LSB shared object, no machine, version 1 (embedded), dynamically linked, with debug_info, not stripped
'file --mime-type *.go' gives:
application/x-sharedlib

This was discussed a while ago for the Ubuntu / Debian pup derivative. I wrote a few explanation (amigo did too, and few others), as well as some recommendations. I can't recall the thread, you just need to duckduckgo it.

Basically, this happens because the use the "-pie" flag when building those libraries. A binary compiled with "-pie" will show itself as a shared library (because essentially that's what it is).

There is nothing you can do about it, short of re-compiling guile yourself. So your only recourse is to modify the build script so it doesn't spit to much errors to the console.

[woodenshoe-wi]

The ARM version of pngoverlay isn't working right and I want to try recompiling it but I can't find the source code.

The binary is located at
woof-CE/woof-arch/arm/target/rootfs-skeleton/usr/sbin/pngoverlay

[mavrothal]

The binary is located at
woof-CE/woof-arch/arm/target/rootfs-skeleton/usr/sbin/pngoverlay

And the source at woof-CE/woof-code/rootfs-skeleton/usr/sbin/pngoverlay.c
( I really have no idea why is there... It should be moved in woof-CE/woof-code/support)

@peebee I think james is referring to this post

[woodenshoe-wi]

Thanks!

I recompiled it and now it works.

I looked in woof-CE/initrd-progs/pkg/w_apps_static/w_apps/
and found printcols.c but w_apps are compiled statically and pngoverlay isn't.

woof-CE/woof-code/c_apps is just a link to woof-CE/initrd-progs/pkg/w_apps_static/w_apps

Maybe we need woof-CE/woof-arch/sources?

Another place I had looked was http://distro.ibiblio.org/puppylinux/sources/p/

Because I recompiled it in a Raspbian based build it might now be ARM hard float. This might be a problem if someone wanted to start doing ARM soft float builds for something other than Raspberry Pi.

Should I make the new pngoverlay into a pet or put it in woof-CE/woof-arch/arm/target/rootfs-skeleton/usr/sbin/?

[mavrothal]

Maybe we need woof-CE/woof-arch/sources?

Another place I had looked was http://distro.ibiblio.org/puppylinux/sources/p/

Yeah woof-CE/sources or ibiblio is fine.
Fewer people have access to ibiblio though and changes there may be more cumbersome. On the other hand keeping multiple versions may be trickier in github unless we keep tarballs there instead of flat files.

[woodenshoe-wi]

As far as I know there is only one version of pngoverlay.c and I didn't change it, I just recompiled it.

What I am concerned about is that since it is not compiled statically it will link against the libs in whichever distro it is compiled in.

Should I put the compiled pngoverlay into woof-CE/woof-arch/arm/... or make it into a pet and ask peebee to upload it for me?

EDIT:
Never mind, I decided to put it in woof-distro/arm/raspbian/stretch/rootfs-skeleton/...

[Sailor Enceladus]

I tried a puduan-7.0.0b1 (Devual Ascii) build with woof-CE today. Here's the iso:
http://www.mediafire.com/file/2u3k4rpkwmaba9c
md5sum: 61557bb57b8cbf7cfe273e28264c9c64

The devx is inside, the only thing I did was compile a kernel 4.4.111 nopae and use it in _00build.conf.

[davids45]

G'day Sailor Enceladus,

Thanks for offering the latest Puduan iso.

I've made a Frugal and a Full of this.

'Open file' dialog window has the too-many-partitions problem when all I want are my mounted partitions and maybe /root.

I had the DBus message in each Puduan using my preferred Seamonkey browser which, as you found with other browsers, runs well despite this message.

As with other recent Pups on my desktop, I found a tardiness(?) in loading X for the first time after adding numerous pets to the pinboard such that a re-boot lacks many correct icons and pwidgets doesn't start up. Restarting X brings these back (screenshots).

Once up and running, Puduan looks fine so far in either install-mode (in the Full now).

David S.

[Billtoo]

I did a build of stretch-7.0.0b1-g4dos-altkernel-devx.iso today, I
added applications with PPM, also installed JWMDesk-2.4.2.pet.

System: Host: puppypc1939 Kernel: 4.9.75 i686 (32 bit) Desktop: JWM 2.3.6 Distro: Dpup Stretch 7.0.0b1
Machine: Device: desktop System: Hewlett-Packard product: HPE-410f serial: MXX0370KF3
Mobo: FOXCONN model: 2AB1 v: 1.00 BIOS: American Megatrends v: 6.02 date: 07/21/2010
CPU: Hexa core AMD Phenom II X6 1045T (-MCP-) speed/max: 800/2700 MHz
Graphics: Card: Advanced Micro Devices [AMD/ATI] Redwood PRO [Radeon HD 5550/5570/5630/6510/6610/7570]
Display Server: X.org 1.19.2 driver: radeon tty size: 154x36 Advanced Data: N/A for root
Network: Card-1: Ralink RT3090 Wireless 802.11n 1T/1R PCIe driver: rt2800pci
Card-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169
Drives: HDD Total Size: 1189.4GB (2.0% used)
Weather: Conditions: 36 F (2 C) - light showers rain Time: January 8, 8:36 PM EST
Info: Processes: 211 Uptime: 5:11 Memory: 574.4/8091.6MB Client: Shell (bash) inxi: 2.3.5

Changed kernels.

No problems so far.
*******************************************************
EDIT:I installed kpat,kiriki,and kshisen with PPM but they wouldn't run until I installed dbus-1.12.2.tar.gz from BLFS.
Kpat etc run fine in Dpup-Stetch-7.5 CE.

[Sailor Enceladus]

EDIT:I installed kpat,kiriki,and kshisen with PPM but they wouldn't run until I installed dbus-1.12.2.tar.gz from BLFS.
Kpat etc run fine in Dpup-Stetch-7.5 CE.

I noticed there was two new dbuses added a week ago (I think). This is what the commit says:

Code: Select all

dpup: essential fixes

address dbus, glib, cryptsetup issues

other important updates to get a nice system

Entry in Packages-puppy-stretch-official
Entries in DISTRO_PKGS_SPECS-debian-stretch

I'm guessing this new stretch one is normally used and the debian one is there as a backup, though haven't looked at how to switch to the other one to test, maybe I'll check if that fixes my warning in Hexchat and Palemoon later or makes things worse.

[Billtoo]

I'm guessing this new stretch one is normally used and the debian one is there as a backup, though haven't looked at how to switch to the other one to test, maybe I'll check if that fixes my warning in Hexchat and Palemoon later or makes things worse.

I downloaded pminstaller-0.2.4.tar.bz2 this morning and installed palemoon-27.6.2
Palemoon is working fine,was using Firefox-ESR-52.5.0 and that worked well.
Stretch-b1 comes with QTweb only.

[belham2]

Hi Billtoo & Sailor,

When doing stretch builds, are you guys getting them to turn out at all like what Radky is giving us with his ISO stretch releases? I tried awhile back, but gave up, since booting up Radky's was a lot different than booting up the builds I did. Has Woof-CE changed radically in the past 2-3 weeks with Stretch builds??

[Billtoo]

Hi Billtoo & Sailor,

When doing stretch builds, are you guys getting them to turn out at all like what Radky is giving us with his ISO stretch releases? I tried awhile back, but gave up, since booting up Radky's was a lot different than booting up the builds I did. Has Woof-CE changed radically in the past 2-3 weeks with Stretch builds??

Hi belham2,

There were a lot of changes done to the testing branch in the past week or so.
It builds stretch-7.0.0b1-g4dos-altkernel-devx.iso, the iso contains the devx and an alternative kernel.

https://github.com/puppylinux-woof-CE/w ... ts/testing