woof-CE needs you

[radky]

roadkill13 wrote:

Installed latest alpha to my little EEE PC 901.

Billtoo wrote:

After seeing the report from @roadkill13 I thought there might be hope
for my eeepc 701 netbook.

It seems Dpup is netbook compatible.

Thanks for testing on the ASUSTeK Eee PC.

[Billtoo]

Pale Moon updated this morning.

[hamoudoudou]

Why not a topic about Dpup Stretch ? Information is lost here, title 'Woof-CE needs you'
Is Dpup-Stretch only For training or for Public release ? Who is the Project leader ?
One version as Public would not stop development, as Xenial does not prevent developers going on zesty, artful, Bionic..
We cannot keep ten flavours, even if satisfied. One has to be elected.
We could choose Puppy or Debian Dog to install in schools in Marroco, so you can understand people will not change everyday the version. And we will need somebody to help.
Of course computing is a little part of the project, but not a tiny one.

[Sailor Enceladus]

Why not a topic about Dpup Stretch ? Information is lost here, title 'Woof-CE needs you'
Is Dpup-Stretch only For training or for Public release ? Who is the Project leader ?
One version as Public would not stop development, as Xenial does not prevent developers going on zesty, artful, Bionic..
We cannot keep ten flavours, even if satisfied. One has to be elected.
We could choose Puppy or Debian Dog to install in schools in Marroco, so you can understand people will not change everyday the version. And we will need somebody to help.
Of course computing is a little part of the project, but not a tiny one.

I kind of agree, the iso has enough fixes and enhancements that are not in woof-CE that it could be considered a derivitive, either way it's great to see radky improving Stretch. Maybe when it goes to beta and it's own thread it can be added to the official page eventually too: http://puppylinux.com/download.html

The replacement volume icon on taskbar in radky's newest iso is still acting strange for me, I think the one in the original Stretch / Puduan in woof-CE works for me though, maybe the problem Billtoo and I are having with this one is hardware specific?

[belham2]

Why not a topic about Dpup Stretch ? Information is lost here, title 'Woof-CE needs you'
Is Dpup-Stretch only For training or for Public release ? Who is the Project leader ?
One version as Public would not stop development, as Xenial does not prevent developers going on zesty, artful, Bionic..
We cannot keep ten flavours, even if satisfied. One has to be elected.
We could choose Puppy or Debian Dog to install in schools in Marroco, so you can understand people will not change everyday the version. And we will need somebody to help.
Of course computing is a little part of the project, but not a tiny one.

I kind of agree, the iso has enough fixes and enhancements that are not in woof-CE that it could be considered a derivitive, either way it's great to see radky improving Stretch. Maybe when it goes to beta and it's own thread it can be added to the official page eventually too: http://puppylinux.com/download.html

The replacement volume icon on taskbar in radky's newest iso is still acting strange for me, I think the one in the original Stretch / Puduan in woof-CE works for me though, maybe the problem Billtoo and I are having with this one is hardware specific?

Well, if Billtoo and you would use proper "puppy hardware", i.e. minimum 8-10 year old stuff that creaks, groans and sometimes decides to take a day off, and not all that new fangled stuff, then the volume icon would work!

P.S. Volume icon has been always working great on my Luddite machines here.

[radky]

A new iteration of Dpup Stretch is now available for testing.

http://murga-linux.com/puppy/viewtopic.php?t=112125

Thanks

[hamoudoudou]

"Why not a topic about Dpup Stretch ? Information is lost here, title 'Woof-CE needs you'
Is Dpup-Stretch only For training or for Public release ? Who is the Project leader ? "
Specific Topic now created by Radky I suppose That i can replace tttuxxx , sailor enceladus versions by radky's one . They were working nice, Devs working together under leadership of one was a clever idea.
'For testing" By who ?
All feed backs give 'Green light'
Questions to be transfered to Dpup Stretch Topic .

Woof-CE needs me ? Really ? Surprising.

[greengeek]

P.S. Volume icon has been always working great on my Luddite machines here.

Did you know that the Luddites were actually great adopters of technical innovation - despite the fact that the term is generally used to suggest that a person does not like new technology.

In fact the Luddites were only fighting against technology that made people redundant and impoverished.

"New" is not "better" unless it advances human enjoyment of life and freedom.

I like being a Luddite.

[rockedge]

I am having problems today building with woof-ce testing. I posted on the Users forum section but it would be better here:
http://www.murga-linux.com/puppy/viewtopic.php?t=112126

I get this error during the running of #./3builddistro-Z

Code: Select all

* Extracting initrd_progs-20170322-static.tar.xz...
Arch: x86_64

* Using default locale
* Using default keymap


*** INITRD: initrd.gz [x86_64]
*** /DISTRO_SPECS: xenialpup64 7.0.8.4 x86_64

chroot: can't execute 'echo': No such file or directory
ERROR: could not 'chroot' into sandbox3/rootfs-complete
This means that something is incomplete, perhaps a library
needed by bash. Check it out. Have to exit script now.

during the running of 3builddistro-Z it exits early no ISO is made.
I am attempting to build Xenial 64bit with the kernel option 31 using woof-CE-testing on a Tahr 6.0.6 64bit.
any help will be totally appreciated!

[belham2]

I am having problems today building with woof-ce testing. I posted on the Users forum section but it would be better here:
http://www.murga-linux.com/puppy/viewtopic.php?t=112126

I get this error during the running of #./3builddistro-Z

Code: Select all

* Extracting initrd_progs-20170322-static.tar.xz...
Arch: x86_64

* Using default locale
* Using default keymap


*** INITRD: initrd.gz [x86_64]
*** /DISTRO_SPECS: xenialpup64 7.0.8.4 x86_64

chroot: can't execute 'echo': No such file or directory
ERROR: could not 'chroot' into sandbox3/rootfs-complete
This means that something is incomplete, perhaps a library
needed by bash. Check it out. Have to exit script now.

during the running of 3builddistro-Z it exits early no ISO is made.
I am attempting to build Xenial 64bit with the kernel option 31 using woof-CE-testing on a Tahr 6.0.6 64bit.
any help will be totally appreciated!

Hi Rockedge,

In the woof-out*/packages-xenial64/busybox/bin folder, there should be a shortcut called "echo", which gets copied into rootfs-complete. Does it exist? If not, what is the partition you're working from formatted as?? I remember SailorE saying awhile back it's gotta be something (building in woof seems to prefer Ext2 or 4) that can create Linux shortcuts. If its not, then that "can't execute ECHO..." error will pop up.

[rockedge]

Hello! thanks for the quick info! I have the partition formatted as ext4 and woof-out folder is in /mnt/home.
I just managed to get an 32bit xenialpup to build on the same machine successfully.

I will try to build the 64bit version with kernel selection 31 again this time in /root/ftpd
I will report the results....

[belham2]

Hello! thanks for the quick info! I have the partition formatted as ext4

So the build is being done in an Ext 4 partition? Dang, that (not having Ext 2 or 4) is usually what causes that darn echo error to pop up.

Let me look at some of my recent build partitions I've still got and see if I can spot what might be going on.


[Edit] The tahr you're using, frugal install, full install, or...????

[belham2]

Rockedge,

Is this (below) what you are seeing (this was being built in my Tahr64 6.0.6 too)?

[belham2]

Ok, found it (early this year) where I ran into this problem:

Start reading here, see if anything helps:

http://www.murga-linux.com/puppy/viewto ... 534#955534

[rockedge]

that is exactly what I see!

[rockedge]

I was able to build a Xenialpup64 using the same woof-CE on a different machine using a 32bit xenial. All of the host OS's are frugally installed on a ext4 drive.

[rockedge]

on a machine that successfully built xenialpup64 with the kernel 4.9.15 failed when building xenialpup64 with the kernel 4.9.58 is showing the following error when running #./3builddistro-Z

Code: Select all

huge-4.9.58-xenialpup64.tar.bz2         : 5ef4ab0c3c097b3301cba549a279d410
huge-4.9.58-xenialpup64.tar.bz2.md5.txt : #
5f6c5e1addcc105928c25c0d20de07ce
#
fe94dce1a8be442dbf85774282c0fcbda5931e74
#
4415f572a8f17c14229e5829dab76902e35bb4b2334dc7f42d64418bd71e6fcc
checksum failed

interesting to learn why I can not build some of the options and how much does the machine matter?

[rockedge]

built 4 xenialpup64's...... 2 on a Dell inspirion 32bit running xenialpup and 2 on a Dell Optiplex 990 64 bit Tahr 6.0.6.
on the second one I ran woof-ce on a 16gig USB stick for 2 versions with different kernels.

It does seem to be an problem around the hard drive being used and although the HDD is ext4 it will not finish the scripts and make the iso when I have the woof-out on this HDD.

Perhaps it is some small configuration difference....important is I have 2 nice new Xenialpup64's with kernel 4.9.15 and 4.9.58!

[jrb]

Has anyone else had a problem with WOOFCE's /2createpackages messing up? I just happen to notice in /root/.packages/builtin_files that some of the packages listed were 0 bites and showed no contents. So I WOOFed up a plain vanilla stretch-7.0.0a2 with the latest WOOFCE and checked the /packages-stretch, sure enough 20 packages were empty. The .debs are not empty and I can build the packages manually.

I'm working in an EXT4 partition with both DPUP stretch and XenialPup. Both situations give the same results

See attached pic for details.

Edit: Correction, not all of these packages are empty. Some of them have correct contents but show as 0 size in /root/.packages/builtin_files but others are indeed empty

[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.