Dpup Exprimo 5.X.3.4.12 with 3.4.2 kernel.
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.
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.
It goes beyond my knowledge to find out what's wrong...
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.
It goes beyond my knowledge to find out what's wrong...
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.
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.
- Iguleder
- Posts: 2026
- Joined: Tue 11 Aug 2009, 09:36
- Location: Israel, somewhere in the beautiful desert
- Contact:
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
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
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]
Broadcom fix integration into puppy - experiment-8
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
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
- Attachments
-
- rerwin_woof_fixes-delta-3b-broadcom_experiment-8.pet
- backend_modprobe with Broadcom logic
plus shrunken/fewer modprobe-configuration files.
NOT to be merged into the wl-driver multi-kernel package. - (18.76 KiB) Downloaded 363 times
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?Iguleder wrote: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
Re: Broadcom fix integration into puppy - experiment-8
Hi Richardrerwin wrote:pemasu, Terry H, stu91, peebee and now anyone using a "preference",............Please try this by installing it and rebooting. Thank you, all.
Richard
All seems AOK here with my HP550 with relatively well behaved B43 wifi - have sent you pmodemdiags by pm.
Cheers
Peter
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
Dpup Exprimo 5.X.3.4.10 with 3.4.2 kernel.
I did a manual frugal install to the hard drive.
Dpup Exprimo, version 5.X.3.4.10 on Tue 28 Aug 2012
Chip description:
0.0 VGA compatible controller
Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
oem: SiS
product: 6325 1.05.00
X Server: Xorg
Driver used: sis
X.Org version: 1.7.7
dimensions: 1440x900 pixels (411x263 millimeters)
depth of root window: 16 planes
Computer
Processor mobile AMD Duron(tm)
Memory 708MB (100MB used)
Operating System Unknown distribution
User Name root (root)
Date/Time Tue 28 Aug 2012 04:13:12 PM EDT
Processor
Name mobile AMD Duron(tm)
Family, model, stepping 6, 7, 0 (AMD Duron (Morgan))
Vendor AuthenticAMD
Configuration
Cache Size 64kb
Frequency 850.04MHz
BogoMIPS 1700.92
Byte Order Little Endian
It's working pretty well, I made a pet of links web browser, it runs a
little faster than firefox on this pc
Dpup Exprimo, version 5.X.3.4.10 on Tue 28 Aug 2012
Chip description:
0.0 VGA compatible controller
Silicon Integrated Systems [SiS] 65x/M650/740 PCI/AGP VGA Display Adapter
oem: SiS
product: 6325 1.05.00
X Server: Xorg
Driver used: sis
X.Org version: 1.7.7
dimensions: 1440x900 pixels (411x263 millimeters)
depth of root window: 16 planes
Computer
Processor mobile AMD Duron(tm)
Memory 708MB (100MB used)
Operating System Unknown distribution
User Name root (root)
Date/Time Tue 28 Aug 2012 04:13:12 PM EDT
Processor
Name mobile AMD Duron(tm)
Family, model, stepping 6, 7, 0 (AMD Duron (Morgan))
Vendor AuthenticAMD
Configuration
Cache Size 64kb
Frequency 850.04MHz
BogoMIPS 1700.92
Byte Order Little Endian
It's working pretty well, I made a pet of links web browser, it runs a
little faster than firefox on this pc
- Attachments
-
- screenshot.jpg
- (50.88 KiB) Downloaded 1181 times
Problem with headphones (VAIO laptop)
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.x
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.x
Last edited by Fabio T on Mon 03 Sep 2012, 21:37, edited 1 time in total.
Dpup Exprimo 5.X.3.4.10 with 3.4.2 kernel.
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.
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.
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.
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.
A python word processor that saves its documents in HTML
________________________________________________________
new Deadbeef 5.5 works in Exprimo
http://murga-linux.com/puppy/viewtopic. ... 01&t=79351
___________________________________________
http://writetype.bernsteinforpresident.com/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.
________________________________________________________
new Deadbeef 5.5 works in Exprimo
http://murga-linux.com/puppy/viewtopic. ... 01&t=79351
___________________________________________
Has this been tested in Exprimo?don570 wrote:A python word processor that saves its documents in HTML
http://writetype.bernsteinforpresident.com/Let’s welcome WriteType 1.3.163
Is there a PET or SFS, please?
One our children may really benefit from this.
[b]Thanks! David[/b]
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603
[i]Home page: [/i][url]http://nevils-station.com[/url]
[i]Don't google[/i] [b]Search![/b] [url]http://duckduckgo.com[/url]
TahrPup64 & Lighthouse64-b602 & JL64-603
Current Exprimo tested. Boots all the way to desktop without issues on 2 laps and 1 X2 6GB RAM. Spectacular again!
JRE, SAMBA, and muCommander all work as you designed them. Performance of Windows accessing Puppy's resources is outstanding over SAMBA.
Thanks for all you do for us.
P.S. Latest stable version of SAMBA is 3.67.
JRE, SAMBA, and muCommander all work as you designed them. Performance of Windows accessing Puppy's resources is outstanding over SAMBA.
Thanks for all you do for us.
P.S. Latest stable version of SAMBA is 3.67.
- charlie6
- Posts: 1230
- Joined: Mon 30 Jun 2008, 04:03
- Location: Saint-Gérard / Walloon part of Belgium
WriteType 1.3.163
Hi don570
hope it could run ootb
Hmmmm.....it looks lightweight (1.6MB archive) but needs Python + PyQt4 + Qt4 ...don570 wrote:A python word processor that saves its documents in HTML
http://writetype.bernsteinforpresident.com/Let’s welcome WriteType 1.3.163
... WriteType is now available in four new languages: Russian, Bulgarian, Italian, and Dutch.
hope it could run ootb
@Pemasu. Thanks for your reply! You are right.
Yes, it seems that I need delays here and there, not only for Bluetooth startup. There are some other, probably related, timing problems that I'm looking into. I''l come back on that later. A reason could be that I work with relatively slow USB 1.1 flash memory only, no HD.
For completeness sake: I use a Compaq Presario 1712AP laptop with Intel 1Ghz processor and 512Mb ram.
It seems I have found the reason why Bluetooth won't startup initially, that is, from a fresh, never-used- before squeezesave: there is no
'bluetoot-share directory' in /root. It is to be created and that is done in '/root/Startup/bluetooth' with the line 'mkdir /root/bluetooth-share'. That takes time and may be the reason why bluetooth won't startup. Changing the first 'sleep 1' in /root/Startup/bluetooth into 'sleep 5' seems to take car of that, initially.
At the very second boot, '/root/bluetooth-share' already exists (it is never removed) and the same line 'mkdir/root/bluetooth-share' results in a (hidden) error but takes less time, apparently, but not always.
Changing the second 'sleep 1' in '/root/Starup/bluetooth' into 'sleep 5' takes care of any second or later boots. The first 'sleep 5' then becomes irrelevant and could be reverted back to 'sleep 1' or the mkdir action could not executed at all.
Note that this is similar to my previous method by initially running /root/Startup/bluetooth twice from terminal: it could be about the initial creation of /root/bluetooth-share.
Whatever the solution (or workaround) is, I think that when the bluetooth tray icon initially shows a red "x", the user should be able to turn bluetooth on with a right-click on that icon. But it doesn't. It replies with a clickable 'Turn Bluetooth On' but you can't.
That's as far as my observations go. I understand that it may be hard or impossible to reproduce this on a relatively modern laptop, anyway, not like my rather battered, nearly 11 year old one.
Yes, it seems that I need delays here and there, not only for Bluetooth startup. There are some other, probably related, timing problems that I'm looking into. I''l come back on that later. A reason could be that I work with relatively slow USB 1.1 flash memory only, no HD.
For completeness sake: I use a Compaq Presario 1712AP laptop with Intel 1Ghz processor and 512Mb ram.
It seems I have found the reason why Bluetooth won't startup initially, that is, from a fresh, never-used- before squeezesave: there is no
'bluetoot-share directory' in /root. It is to be created and that is done in '/root/Startup/bluetooth' with the line 'mkdir /root/bluetooth-share'. That takes time and may be the reason why bluetooth won't startup. Changing the first 'sleep 1' in /root/Startup/bluetooth into 'sleep 5' seems to take car of that, initially.
At the very second boot, '/root/bluetooth-share' already exists (it is never removed) and the same line 'mkdir/root/bluetooth-share' results in a (hidden) error but takes less time, apparently, but not always.
Changing the second 'sleep 1' in '/root/Starup/bluetooth' into 'sleep 5' takes care of any second or later boots. The first 'sleep 5' then becomes irrelevant and could be reverted back to 'sleep 1' or the mkdir action could not executed at all.
Note that this is similar to my previous method by initially running /root/Startup/bluetooth twice from terminal: it could be about the initial creation of /root/bluetooth-share.
Whatever the solution (or workaround) is, I think that when the bluetooth tray icon initially shows a red "x", the user should be able to turn bluetooth on with a right-click on that icon. But it doesn't. It replies with a clickable 'Turn Bluetooth On' but you can't.
That's as far as my observations go. I understand that it may be hard or impossible to reproduce this on a relatively modern laptop, anyway, not like my rather battered, nearly 11 year old one.
Last edited by linuph on Thu 30 Aug 2012, 16:22, edited 1 time in total.