I just tested Iguleder's buildpkg in action with his geany.sh script.
It's pretty sweet! He took almost everything into account.

No use letting such good code go to waste, and instead of me re-inventing the wheel, I think I am just going to modify the buildpkg system to include a few more things...mainly a suffix at the end of the pet name, eg geany-0.21-dpup or geany-0.2.1-w5 ..etc

Also, I prefer to have some extra info such as any make errrors and make-install errors sent to a temporary folder.

There's a problem with Bluetooth at startup: the applet icon is there but with a red cross in it. I cannot turn it on by clicking it.
Bluetooth is (should be) automatically started with the /root/Startup/bluetooth script. If I click that script the bluetooth icon disappears and when clicked a second time, the bluetooth reappears and it is working.

To automatically start bluetooth, I added a workaround script in /root/Startup:

#!/bin/sh
bluetooth
bluetooth

Bluetooth is now turned on at startup and I can turn it off and on again by clicking the icon.

Thank you all of the feedback.
Tman. Yep, I know that Iguleders builder package works nicely. I use it sometimes, I just check the latest version of the application and update the .sh script accordingly. I also modify the /etc/builder.profile sometimes so that tuning options are what I like. Puppizard itself does not work anymore, since the repo which it calls is not anymore.

Linuph. I will look that bluetooth autostart problem, when I have time. I have interest to get it right. I am just now hopping between Dpup Wheezy development and Dpup Exprimo. Using both. So...my bug hunting is not immediate.

Yes - there is a new implementation, which is now part of roar-ng, my distro's framework (a-la Woof).

This new implementation has some improvements, but produces packages in its own format. I wrote some script which converts them to PET (yes, with automated splitting and stuff) - that's what I used to generate the dpup64 repository so far.

Don't worry - I'll make sure I document the dpup64 effort so you can build heaps of packages in few hours, too _________________My homepageMy GitHub profile

pemasu, Terry H, stu91, peebee and now anyone using a "preference",
This has to be my final implementation of the Broadcom logic. I am concerned that the code up until now was in modprobe configuration files and contained some duplication. I have now moved the code to the module loader for eventual integration into woof.

Although the module-reloading logic is now added to the backend_modprobe script, I also changed preference handling so that no module is blacklisted in the process of determining whether to use a preferred module. My goal is that conflicting modules (supporting the same devices) may not overlap completely, leaving the possibility that a PC might contain similar (usually wifi) devices but where only one uses the preferred module, while the other needs to "old" module.

The idea is consistent with piratesmack's concept of loading modules in order of preference, but with a twist. If a networking module gets unloaded then reloaded, any connection it might have established would be broken and not re-established. So, when a non-preferred module is chosen, a 1-second delay is inserted before continuing the loading process. This should allow another device's preferred module to get loaded, before the older one completes loading, avoiding the need for the reload process for them.

Given that delay, the reload process should occur for only those modules that are preloaded during early initialization (i.e., ssb and bcma). Those do not themselves make a network connection, but trigger loading of modules (b43, b44, brcmsmac) that do connect. We have not yet seen whether the latter would stay connected if reloaded, since that occurs only when the wl module is used instead. That test needs to be done by someone with a combination of devices, say, a wifi using wl and an ethernet using b44. Or 2 wifis, one with wl and the other with b43. We also need to know whether the problematic bcm4311 cards still automatically use b43 instead of wl.

The advantages of putting the logic in the module loader are that (1) it occurs earlier, before wl actually gets modprobed and (2) all preference-related actions are logged, eliminating guesswork as to what happened. The log file is:
/tmp/pup_event_backend/preferences.log
Please post the content of that file in any report about this. The file is now included in the pmodemdiag version included in the package.

As you can infer from the package name, my intent is to contribute it to woof once our experimentation with it completes. The two goals, now, are to verify both/all preference-related devices function and that preferences related to networking work as well as before. And we may find some PCs with similar devices that may now both operate.

Enough explanation. Please try this by installing it and rebooting. (For other distros that do not have wl, peebee's multi-kernel broadcom package should be installed before this experiment package.) Please post the content of the /tmp...preferences.log file. Thank you, all.
Richard

rerwin_woof_fixes-delta-3b-broadcom_experiment-8.pet

Description

backend_modprobe with Broadcom logic plus shrunken/fewer modprobe-configuration files.NOT to be merged into the wl-driver multi-kernel package.

Yes - there is a new implementation, which is now part of roar-ng, my distro's framework (a-la Woof).

This new implementation has some improvements, but produces packages in its own format. I wrote some script which converts them to PET (yes, with automated splitting and stuff) - that's what I used to generate the dpup64 repository so far.

Don't worry - I'll make sure I document the dpup64 effort so you can build heaps of packages in few hours, too

Thanks, Iguleder! Buildpkg was/is a great piece of work, but it didn't seem to catch the interest of very many members of this forum. I will see if I can help change that, so that even newbies can compile their own apps, when they are not readily availiable for their particular version of Puppy. What do you think about creating a front-end GUI for buildpkg?

I've found a problem with the management of the audio in Exprimo from version 5.3.4.2.8. and next.

On my laptop Sony Vaio is impossible to hear music/sound with headphones, only from speakers, but sound works correctly with Exprimo 3.2.14. (in fact I am hear a song with this version while I am writing this post, with headphones!) The problem don't happen to the other my laptop Hp EliteBook 2530p.

I've tweaked a lot with Alsamixer and Retrovol but no success.

Audio Chipset of Vaio TT46GX is found by HardInfo like Intel 82801 and by Multiple Sound Card Wizard like ALC889 Analog.

What can I do for fix this inconvenient?

I've non yet found a fix with Search in the forum, so please help me...
Thank you a lot for this puplet.

EDIT: Perhaps the problem came from kernel. 3.4.2.has this defect for me.
I've tried a lot of distro with various kernel and this trouble is happened with kernel 3.4.xLast edited by Fabio T on Mon 03 Sep 2012, 17:37; edited 1 time in total

I noticed that streamradio had some of my favorite stations so gave it
a try, it gave an error about mplayer bus (or something) and wouldn't
work.
I compiled mplayer 1.1 which took well over an hour but it completed
successfully and streamradio now works, yay.

Linuph. For me /root/Startup/bluetooth script works as expected. It starts the bluetooth-applet in jwm tray for me when I reboot. Or when I restart X.

So....could it be that you need longer sleep time before executing bluetooth-applet&

Launch in console: /root/Startup/bluetooth
and check does it execute allright for you and test with prolonging the sleep time before bluetooth-applet& in the script. There is also another instance of sleep in the script. That might also need longer sleep for you.
I couldnt find problem in the script execution in my laptop.

I would like to report success so far with the new build. I have tried on 2 systems so far, no network issues and no screen issues to be reported so far. I need to go through and test all the APPS to confirm, but so far Frisbee, Firefox, GetFlash and alsamixer are all I can think of that I have used and none have presented problems.

I do have a minor issue I have noticed with both .09 and .10 of the 5.X.3.4.X build in regards to Adobe Flash. There is an odd boxy, dithered look to videos that is not present in the 5x15 and 3.1.10 builds which I also have on thumb drives using the same version of Adobe Flash via GetFlash on all of the above distros. I have tried using different browsers such as Chromium, Seamonkey and Opera and they all have the same issue in this particular flavor of Exprimo. It's not enough of an issue to bother troubleshooting atm as it does not prevent use of flash, so I would not concern yourself with that, I would like to hear from others that use Exprimo 3.2.X and see if this issue has been replicated by others so that a commonality can be established.

Let’s welcome WriteType 1.3.163
Posted by max on 10th August and posted in News
WriteType 1.3.163 is now available! WriteType is a word-processor designed to help elementary school students write better. It gives students who have a hard time writing an easier approach in putting their ideas on paper. In addition to fixing many bugs, the latest WriteType release has several new features to help students succeed. Some new features include:

New translations — WriteType is now available in four new languages: Russian, Bulgarian, Italian, and Dutch.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum