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.Sailor Enceladus wrote:@jrb: I have a few 0 byte ones too, I think in my case it's because they're only used in the devx.
woof-CE needs you
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Yup. There's just two red symlinks which I think get removed, the rest is in automake_DEV and automake_DOC folders.jrb wrote: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.Sailor Enceladus wrote:@jrb: I have a few 0 byte ones too, I think in my case it's because they're only used in the devx.
Internet needs to start up automatically
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?
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?
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Re: Internet needs to start up automatically
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.Lassar wrote: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?
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:
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
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:
This change causes 2createpackages to spit out lots of error messages because strip at line #673 fails on .go filese.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 )
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
LxPup = Puppy + LXDE
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
Main version used daily: LxPupSc; Assembler of UPups, ScPup & ScPup64, LxPup, LxPupSc & LxPupSc64
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.peebee wrote: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
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.
Fatdog64 forum links: [url=http://murga-linux.com/puppy/viewtopic.php?t=117546]Latest version[/url] | [url=https://cutt.ly/ke8sn5H]Contributed packages[/url] | [url=https://cutt.ly/se8scrb]ISO builder[/url]
-
- Posts: 109
- Joined: Sat 29 Jul 2017, 03:16
- Location: Wisconsin
pngoverlay
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
The binary is located at
woof-CE/woof-arch/arm/target/rootfs-skeleton/usr/sbin/pngoverlay
Re: pngoverlay
And the source at woof-CE/woof-code/rootfs-skeleton/usr/sbin/pngoverlay.cwoodenshoe-wi wrote:The binary is located at
woof-CE/woof-arch/arm/target/rootfs-skeleton/usr/sbin/pngoverlay
( 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
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
-
- Posts: 109
- Joined: Sat 29 Jul 2017, 03:16
- Location: Wisconsin
pngoverlay
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/?
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/?
Re: pngoverlay
Yeah woof-CE/sources or ibiblio is fine.woodenshoe-wi wrote:Maybe we need woof-CE/woof-arch/sources?
Another place I had looked was http://distro.ibiblio.org/puppylinux/sources/p/
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.
== [url=http://www.catb.org/esr/faqs/smart-questions.html]Here is how to solve your[/url] [url=https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]Linux problems fast[/url] ==
-
- Posts: 109
- Joined: Sat 29 Jul 2017, 03:16
- Location: Wisconsin
pngoverlay
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/...
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/...
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
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.
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.
Last edited by Sailor Enceladus on Thu 11 Jan 2018, 21:40, edited 1 time in total.
Puduan woof-CE iso
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.
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.
- Attachments
-
- puduan-openfile-problem.jpg
- 'Open file' dialog box 'Places' panel - too many unwanted unmounted 'Places'
- (111.09 KiB) Downloaded 220 times
-
- puduanfrugal-1st-reboot.jpg
- puduan with many app pets installed - first reboot misses many icons and no pwidgets
- (70.58 KiB) Downloaded 216 times
-
- puduan-restartX.jpg
- icons and pwidgets appear after restarting X
- (97.82 KiB) Downloaded 214 times
woof-CE needs you
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.
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.
- Attachments
-
- screenshot.jpg
- (37.01 KiB) Downloaded 1276 times
-
- Posts: 1543
- Joined: Mon 22 Feb 2016, 19:43
Re: woof-CE needs you
I noticed there was two new dbuses added a week ago (I think). This is what the commit says:Billtoo wrote: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.
Code: Select all
dpup: essential fixes
address dbus, glib, cryptsetup issues
other important updates to get a nice system
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.
Re: woof-CE needs you
I downloaded pminstaller-0.2.4.tar.bz2 this morning and installed palemoon-27.6.2Sailor Enceladus wrote: 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.
Palemoon is working fine,was using Firefox-ESR-52.5.0 and that worked well.
Stretch-b1 comes with QTweb only.
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??
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,belham2 wrote: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??
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