Auto-build a Puppy iso; single script with optional gui

Message

smokey01 · #166 Post by **smokey01** » Wed 20 Sep 2017, 01:07

EDIT: But I note not being able to run woof-CE on FatDog has already been answered smokey! makepup being a frontend for woof-CE... Wink :

@wiak, That would be the issue. I will try it again from slacko64-6999.

Cheers

Sailor Enceladus · #167 Post by **Sailor Enceladus** » Wed 20 Sep 2017, 20:18

davids45 wrote:However, for my regular user-packages, I find slackos miss more libraries than Tahr/Xenial Pups, so personalising a new Slacko is a longer process than a Tahr/Xenial. Maybe my regular packages were from Ubuntu originally hence the fewer library miscues.

Needed libs were:
libgcrypt.so.11
libjpeg.so.8
libpng12.so.0
libgtk-3.so.0

Next makpup run for a Slacko I should see if I can add these to the build during the -p pause?

Davids45,

I had asked you before what in Slacko 6.9.9.9 needs libpng12 and didn't get a response. I guess I'll ask the same for libjpeg8 as well. What do you need these libraries for? These are old libs and programs compiled for Slackware 14.2 should be using libpng16 and libjpeg62 I think (which are included).

Billtoo · #168 Post by **Billtoo** » Wed 20 Sep 2017, 20:38

I'm still working with my makepup xenial build from a couple of days ago.
I updated the kernel and ran ./3builddistro-Z, have installed the new iso to an
usb external hard drive, running from my HP desktop:

root# inxi -b
System: Host: puppypc25327 Kernel: 4.9.51-pae i686 (32 bit) Desktop: JWM 2.3.5 Distro: xenialpup 7.0.6
Machine: Device: desktop System: HP product: 260-p029 serial: CNV6240BWP
Mobo: HP model: 81B4 v: 01 serial: PFPSK0BWJ301LW UEFI [Legacy]: AMI v: F.04 date: 05/10/2016
CPU: Dual core Intel Core i3-6100T (-HT-MCP-) speed/max: 800/3101 MHz
Graphics: Card: Intel Sky Lake Integrated Graphics
Display Server: X.org 1.18.4 drivers: intel (unloaded: modesetting,fbdev,vesa)
tty size: 127x21 Advanced Data: N/A for root
Network: Card-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller driver: r8169
Card-2: Realtek RTL8723BE PCIe Wireless Network Adapter driver: rtl8723be
Drives: HDD Total Size: 2000.4GB (0.4% used)
Info: Processes: 192 Uptime: 1:25 Memory: 225.2/3898.0MB Client: Shell (bash) inxi: 2.3.8
root#

In version 7.0.6 smplayer and smtube won't install from PPM (I'm guessing that Xenialpup CE 7.0.8.1 has it fixed)
but apparently it's not a woof-CE build,
I got smtube working with some old pets, smplayer is still broken but vlc works well with smtube.

I do like this build

Thanks.
*************************************************************
EDIT: I connected a second monitor,set them up with arandr(PPM),saved monitors.sh to /root/.screenlayout,also copied
monitors.sh to /root/startup.
I found 2 1920x1080 jpg files at wallpaperscraft.com and used PeasyGlue to put them side by side, copied newwall.jpg to
/to usr/share/backgrounds and made it the default wallpaper.
Then exited to the prompt and ran xorgwizard,specified the driver,screen resolution as 3840x1080,and bith depth
as 24 exited, xwin back to desktop.

This allows a different background on each monitor in JWM, I hope someone will find this method useful.

belham2 · #169 Post by **belham2** » Wed 20 Sep 2017, 20:44

Anybody feeling frisky or adventurous enough to give Stemsee's new 64 kernel 4.12.12 a shot in a 'makepup' build? And report back how it goes??

http://www.murga-linux.com/puppy/viewto ... &start=450

musher0 · #170 Post by **musher0** » Wed 20 Sep 2017, 20:55

belham2 wrote:Anybody feeling frisky or adventurous enough to give Stemsee's new 64 kernel 4.12.12 a shot in a 'makepup' build? And report back how it goes??

http://www.murga-linux.com/puppy/viewto ... &start=450

Hi belham2

Which means YOU are NOT feeling frisky or adventurous!!!

As for me, I know from experience that my old machine slows down to a
crawl with any of the newer kernels beyond 4,1.

BFN.

davids45 · #171 Post by **davids45** » Thu 21 Sep 2017, 02:27

G'day Sailor Enceladus,

I apologise for missing your earlier post about my lib files usage.

From the scrap of paper luckily still on my desk, I'd written:

libgcrypt - (my version of Moat's) "pwidgets"
libjpeg.so.8 - blank

- Gimp-2.8? - to use .jpg files as per older Gimps?
libpng12.so.0 - "several" (I didn't record each package but I think 3 needed this)
libgtk-3.so.0 - "U" mozilla-light

I don't update my application packages unless I have a Pup-wide problem so I am using not-the-latest versions in new Pups. I have these accumulated older packages in a combined sfs that gets boot-loaded in each Pup. LibreOffice and Wine would be the more frequent updates of things in my sfs, maybe every six months. New applications of interest get loaded as separate sfs until included in the big one when I get around to it.

I'm used to adding a library file (or several) from my archive when something doesn't run in a new Pup rather than re-doing the applications sfs which is just under a GB so takes a while to update even for just one package.

I think I've used Ubuntu-Pup pets or sfs as sources for my application packages more than Slackos, so when I have come across a lib file problem, it's mostly in a Slacko. But generally a lib file or two added to /usr/lib/ will get my new Slacko Pup using the old application in my sfs.

Let me know if you need more feedback.

David S.

wiak · #172 Post by **wiak** » Thu 21 Sep 2017, 02:29

davids45 wrote: However, for my regular user-packages, I find slackos miss more libraries than Tahr/Xenial Pups, so personalising a new Slacko is a longer process than a Tahr/Xenial. Maybe my regular packages were from Ubuntu originally hence the fewer library miscues.

Hi davids45,

One possibility (though I can't confirm this at present) is that UbuntuXenial _00build.conf contains:

## -- Dependency check --
CHECK_BINARY_DEPS=yes

whereas Slacko seems to use default woof-CE _00build.conf, where
CHECK_BINARY_DEPS=no

EDIT3: But my first look at the related woof-CE code suggests to me that this is just an "after build to rootfs-complete check" just to flag issues with dependencies missing or not used rather than to do further dependency-checking. Currently, I have makepup ignoring if missing dependencies so as to allow the build to complete rather than exiting in failure...

EDIT2: From what I can see, that variable is used in 3builddistro-Z and checks target architecture is same as host architecture before doing dependency checks (this is partially a note to myself):

Code: Select all

#build.conf
if [ "$WOOF_HOSTARCH" = "$WOOF_TARGETARCH" -a "$CHECK_BINARY_DEPS" = "yes" ];then
 echo "Wait awhile..."
 dependcheck

I'm looking into the woof-CE code for that just now because in the makepup 0.1.2 version I'm working on I also now have a drop/drag folder for distro-compatible packages. However, I have tried that with UbuntuXenial64 using downloaded ubuntu xenial package artha_...*, which has several dependencies. The package installed fine, but dependencies missing so there may be other problems more generally with dependencies handling (or not) in woof-CE, at this stage in woof-CE developments. Dependency handling is one of the most difficult, and fundamentally important, functions of package management, I feel, so if there are woof-CE limits in that regard then that is a priority pointer towards woof-CE code to be developed.

EDIT: Of course no Puppy dotpet-related package manager can deal with dependencies correctly if the individual dotpets developed do not adequately list dependencies in their pet.specs file. Though official Debian packages, for example, should have all their dependencies listed in the Debian control file, it is clearly a tricky matter to extract that information and rapidly-enough process it (in program-writing) from the point of view of a Puppy-based package manager. To complicate issues, woof-CE also has to be able to handle Slackware packages and so on) - that is both the challenge and the flexibility of woof-CE. Easy if it was just all Debian-based!

wiak

davids45 · #173 Post by **davids45** » Thu 21 Sep 2017, 06:21

G'day wiak,

Thanks for the post about the issues of mixing distribution packages and Pups. I run my standard list of older packages (applications) in new Pups rather that get the latest versions from repositories unless desperate. Happily, I'm rarely desperate with Puppy.

I have made a Stretch-Pup with makepup-0.1.1 (frugal desktop screenshot) and with a variety of pets in the pets2add directory (screenshot) including a pet of libs I find missing for some of my regular applications when I run a new Slacko (screenshot).

These Slacko-needed libs didn't seem to cause any major problem in making this Stretch. I'll actually do a makepup Slacko next

.

The Epson printer failure I get in Stretch Pups due to its ghostscript problem was not fixed during the build by having the two repair pets (ghostscript and gstoraster) in the pets2add directory. Still had the 'filter failed' in a test print with CUPS.

But when I manually installed these two pets to my Frugal Stretch, I could then print in Stretch. I think I needed to remove or turn 'yes' into 'no' for the non-working (newer) ghostscript file from the Stretch directory during the build as this may have over-ridden the two (earlier) ghostscript and gstoraster files in the pets2add directory? I assume there is a 'pecking order' when Woof sees two versions of the same file in its make-with-these lists?

I also noted that the two pets in my pets2add directory that were links (see the arrowed icons in the screenshot) to the pets in my Pets archive worked OK, so that's nice.

Any program I run frequently that has a config file in either /root or /root/.config I run via symlinks to my data partition so all Pups bring up the same history for these programs when I run them in any Pup. For example, all the browsers and LibreOffice. Now I'm wondering how to set up building these links into my makepups since I'm running them all on the same computer (at the moment). A pet of links? Could save a few minutes taken in making the config symlinks to the newly installed Pups, so not really apocalyptic if it doesn't happen.

Thanks again for your work.

David S.

wiak · #174 Post by **wiak** » Thu 21 Sep 2017, 10:30

ver 0.1.2 uploaded to first post of this thread.

Changes:

## 0.1.2 Bugfix: Now auto-creates mkdir -p ../local-repositories/${WOOF_TARGETARCH}/packages-pet if doesn't already exist.
# Added button for opening local-repositories/pkgs2add directory for drag/drop official distro-compatible packages to add to build.
# Added button for opening local-repositories/huge_kernels directory for drag/drop extra kernels to choose from for build.
# Also added option via commandline question to open up file DISTRO_PKGS_SPECS-* in a text editor when -p/--pause option is selected

Personally, when using makepup, I usually select all of -k (for keep previous woof-CE branch files), -p (for pause just after 0setup routine), -a (for pets2add), and -A (for pkgs2add). But all such switches are optional of course.

Note that the pkgs2add folder is really only for official targetarch packages (though you could drop other distro/binary packages in there if you also modified a Packages- list file with relevant details as well - but I won't go into that here). For example, if targetarch is ubuntuxenial64, any debs you have downloaded from the official repositories for that system can be added via pkgs2add folder if that is the build targetarch. When I say, 'any debs', I mean those that already have entries in the woof-CE downloaded official distro Packages- lists. As with pets2add, the necessary lines containing yes|... are added to the end of DISTRO_PKGS_SPECS-* automatically. You may need to edit that file if there are duplicate versions of that package already in there (I don't know the precedence of these entries at the moment).

In tests, I noted that dependencies do not seem to be resolved by this method by woof-CE code. I don't yet know the extent woof-CE code currently resolves package dependencies but am in process of checking out the internal woof-CE code concerning this (quite a complicated process however...). Hopefully, the new facilities will prove useful anyway, but some final tweaking re: dependencies will undoubtedly need to be completed after the build when it comes to theses added pet/pkg extras.

One thing I particularly see the drag/drop pet/pkg facility being useful for, is to create say a special dotpet that fixes errors (symlinks and so on) that may exist in some woof-CE distro branch (though ultimately fixing the woof-CE branch at woof-CE github itself is the ideal of course). The other useful possibility, would be to create a special dotpet (perhaps with pre-install script included) to automatically change window manager environment (that dotpet would have to be carefully crafted to fix any dependency issues too of course). Anyway, all is possible, so I'm sure any woof-CE dependency issues will eventually be sorted out via the continuous development/improvement of woof-CE itself.

wiak

musher0 · #175 Post by **musher0** » Thu 21 Sep 2017, 12:12

Many thanks, wiak.

LazY Puppy · #176 Post by **LazY Puppy** » Thu 21 Sep 2017, 22:13

Updated the related post and uploaded a new version of .mo file. So, you can keep the link from first post.

Btw.: how much is the amount of data downloaded to build a Puppy Linux by using makepup?

davids45 · #177 Post by **davids45** » Fri 22 Sep 2017, 03:08

G'day,

Still playing catch-up, with last night's makepup-0.1.1 trying to add missing application libs for Slacko via an added .pet during the build.

Only a few fixes needed in the subsequent Frugal Slacko to get all my apps working - fixes needed, mostly because my oversights.

Light Firefox (a.k.a. "U") needed libgdk-3.so.0 as well as libgtk-3.so.0 in the added pet - I'd done this double lib fix quite a few times before in Slackos so should have remembered

.

Printing still filter-failed - because the ghostscript version in the new Slacko was the faulty 9.19 which I obviously hadn't stopped being included and my 9.05 version in the added pet wasn't added. Manually I did this fix to the running Frugal but when I still had the "Filter-failed" message trying to print, I found I had the other problem with printing where a symlink was needed for a missing ld-lsb.so.3 file in /usr/lib (screenshot may help explain this). Both fixes done and this Slacko now prints on my Epson.

"Mapper", an open source multi-platform mapping package, needed a fix for its 'xcb' problem that involved another link repair - from /usr/lib/qt5 to /usr/bin. A bit esoteric this one.

And taking a leaf out of Billtoo's by now very large book, ...here's my computer's details with this 32-bit Slacko:

inxi -b
System: Host: puppypc14357 Kernel: 3.18.22 i686 (32 bit) Desktop: JWM 2.3.2
Distro: Slacko Puppy 6.9.9.9
Machine: Device: desktop System: Hewlett-Packard product: HP Compaq dc7600 Small Form Factor serial: AUD6200580
Mobo: Hewlett-Packard model: 09F8h serial: AUD6200580
BIOS: Hewlett-Packard v: 786D1 v01.03 date: 05/18/2005
CPU: Single core Intel Pentium 4 (-HT-) speed/max: 2800/3000 MHz
Graphics: Card: Intel 82945G/GZ Integrated Graphics Controller
Display Server: X.org 1.18.3 drivers: intel (unloaded: modesetting,fbdev,vesa)
tty size: 80x25 Advanced Data: N/A for root
Network: Card: Broadcom Limited NetXtreme BCM5752 Gigabit Ethernet PCI Express
driver: tg3
Drives: HDD Total Size: 1000.2GB (34.0% used)
Info: Processes: 116 Uptime: 2:22 Memory: 351.8/1757.1MB
Client: Shell (bash) inxi: 2.3.8

Not the freshest daisy in the bunch but still younger than me.

Now for 0.1.2.

David S.

nilsonmorales · #178 Post by **nilsonmorales** » Fri 22 Sep 2017, 03:46

Updated my post too, wiak please check your script is or [-i]?
cheers

LazY Puppy · #179 Post by **LazY Puppy** » Fri 22 Sep 2017, 04:02

In function usage it says: -i, so it needs a fix plus again an updated .mo file.

DE .mo file again updated for the fixed version.

I have fixed mine and added the following code to it, to copy the .mo file automatically for the locales in /usr/share/locale/de/LC_MESSAGES/

Code: Select all

# Copy DE locales into the System
APPDIR="`dirname "$0"`"
cp -a -u "$APPDIR"/makepup.mo /usr/share/locale/de/LC_MESSAGES/

Billtoo · #180 Post by **Billtoo** » Fri 22 Sep 2017, 04:42

I did a build of tahrpup64 with the newest makepup while running slacko64-6.9.9.9
I installed the iso to a 128gb usb ssd, it's running on my macmini.

I added some pets from april64 (smplayer,smtube), compiled mplayer-1.30, added gnome mplayer with PPM,
kodi with quickpet.
The older xorg doesn't support 2 monitors as well as xorg in xenialpup but streaming videos are rock solid.
The apple keyboard isn't fully supported (it is in xenialpup64-7.0.8.5) but still useable.
Palemoon works well.

I had to add "intel_pstate=disable" no quotes to the kernel line in menu.lst
to get the CPU Frequency Scaling Tool to work.

sh-4.3# inxi -b
System: Host: puppypc24718 Kernel: 3.14.79 x86_64 (64 bit) Desktop: JWM 2.3.6 Distro: tahrpup64 6.0.6
Machine: Device: laptop System: Apple product: Macmini6 1 v: 1.0 serial: C07JV98EDWYL
Mobo: Apple model: Mac-031AEE4D24BFF0B1 v: Macmini6 1 serial: C072496085YF1HCAG
BIOS: Apple v: MM61.88Z.0106.B03.1211161202 date: 11/16/2012
CPU: Dual core Intel Core i5-3210M (-HT-MCP-) speed/max: 1200/2501 MHz
Graphics: Card: Intel 3rd Gen Core processor Graphics Controller
Display Server: X.org 1.15.1 driver: intel tty size: 126x24 Advanced Data: N/A for root
Network: Card-1: Broadcom NetXtreme BCM57766 Gigabit Ethernet PCIe driver: tg3
Card-2: Broadcom BCM4331 802.11a/b/g/n driver: bcma-pci-bridge
Card-3: Linksys WUSB54GC v1 802.11g Adapter [Ralink RT73] driver: rt73usb
Drives: HDD Total Size: 626.4GB (0.8% used)
Info: Processes: 138 Uptime: 3:33 Memory: 391.7/15936.0MB Client: Shell (sh) inxi: 2.3.8
sh-4.3#

I like this build too

Thanks.

wiak · #181 Post by **wiak** » Fri 22 Sep 2017, 04:58

@nilsonmorales and RSH:

Thanks for the NLS lang updates. Yes, it should be -i

As for data download size during build of say a xenialpup64, it's around 600MB (including testing branch .zip and huge kernel of around 70MB). Once the main files are all downloaded, rebuilding only involves re-download of Package lists - I'm not sure how many MBs that takes but not a lot (could be made optional of course).

I've re-uploaded ver 0.1.2 with -i instead of i but kept same version number.
Not adding any extra code at the moment.

wiak

LazY Puppy · #182 Post by **LazY Puppy** » Fri 22 Sep 2017, 11:06

As for data download size during build of say a xenialpup64, it's around 600MB (including testing branch .zip and huge kernel of around 70MB).

Ok, thanks.

This sounds good, since I have limited prepaid high speed amount for down- and upload. So, I may try to build a Puppy using makepup - probably in October.

Billtoo · #183 Post by **Billtoo** » Sun 24 Sep 2017, 17:59

Hi

I tried running version 0.1.2 from tahrpup64 yesterday and it was working fine until it got to the ./3builddistro-Z step when it
went into a loop giving the same error over and over (I remember seeing something about gdkpixbuf) so I did ctrl-c to kill it,
it kept restarting so I restarted x, deleted the work directory and rebooted.
I was attempting to build xenialpup64 with it.

Thanks

wiak · #184 Post by **wiak** » Sun 24 Sep 2017, 19:07

Billtoo wrote:Hi

I tried running version 0.1.2 from tahrpup64 yesterday and it was working fine until it got to the ./3builddistro-Z step when it
went into a loop giving the same error over and over (I remember seeing something about gdkpixbuf) so I did ctrl-c to kill it,
it kept restarting so I restarted x, deleted the work directory and rebooted.
I was attempting to build xenialpup64 with it.

Thanks

Hi Billtoo,

I take it the issue wasn't fixed? I'll try it out later today to see if I can duplicate the problem. I also notice there have been a few main woof-CE script changes at woof-CE github though can't say if that is the problem or makepup itself. I haven't had much time to test 0.1.2 so was waiting on feedback, but it did work the times I tested it before.

wiak

Keef · #185 Post by **Keef** » Sun 24 Sep 2017, 19:17

I built a 32bit Slacko with it, on Quirky Xerus64. Haven't found any significant problems. Not tried adding any pets yet (to the build), but will try that next.

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum