(old)Puppy Linux Discussion Forum

Testing at the San Antonio Public Library WIFI. Took 3 reboots, four scans on this last reboot, and two auto DHCP to get the WIFI on this HP zv6000 laptop to stay 'on'. 3.01 never had this problem here.

Will test at San Antonio College tonight. I always have problems there.

NathanO

At San Antonio College, managed to get on WIFI with only three 'scan', 'choose', and two auto DHCP. There seems to be a problem with keeping the WIFI in this HP zv6000 laptop 'on' between scanning for a connection and doing the auto DHCP. Once it gets an IP address then it will stay on.

This was not a problem with 3.01.

NathanO

BarryK wrote:

nic2109 wrote:A minor buglet is that the network connection wizard needs to be re-run each time to load and use the saved profile - it doesn't "remember" to use it. There's no such problem with eth0 wired which is picked up on re-boot just fine.

The guys who are currently maintaining the Network Wizard need to pick that one up. There was rarsa, tempestuous also I think, then pizzasgood had a look at it recently ...so I don't really know who wants to take this one on.

Has anyone had a look at this yet, or have I posted a howler?

I actually meant this for the Dingo Alpha 6 (Retro kernel) thread. It really IS a problem there, so might be in 3.02-alpha-1too.

Nick

AJ, to avoid confusion with later versions, would you mind renaming this thread as Puppy 3 Series Bugs? I know you don't have to, but it would be helpful.

Thank you.

Hi Warren.

The title is version, state and state-number specific. It was chosen with the express interest of avoiding confusion.

"Puppy 3 Series" is a rather broad umbrella, at least IMO. It covers:

3.00alpha(s)
3.00beta(s)
3.00 final
3.00retro
3.00 fat free
3.01alpha(s)
3.01beta(s)
3.01 final
3.01retro
3.01 fat free
3.01-NOP
3.01-NOP-rev1
Chihuahua(s)
DCL
Fire Hydrant Featherweight 3.0b
Fire Hydrant FHmainAbi3.0b
Fire Hydrant FMmainOoffice3.0b
Fire Hydrant Inferno3.0b
Fire Hydrant FH_Jwm3.01c
Lassie(s)
LighthousePup 3.01a4
LighthousePup 3.01a4oo2.2
Pupeee
Shard 3.01
Talking Stick(s)

... and perhaps more, but I've run out of time and interest in hunting them down.

I'll be more than happy to change the topic to your choice, however in light of the above, I'd appreciate an explanation of how it will avoid confusion. And please forgive me if I'm missing something obvious here.

I can see aj's point.
But maybe v3.02alpha* bugs would trim things down a bit.

I found a little bug in the network wizard in wag-profiles.sh in the function loadProfileData() :
This prevents the AP_MAC variable from beeing stored correctly.
Beware that old wag-config files might have entries with too few lines. (e.g. AP_MAC variable missing) These old files can get corrupted by the bugfixed version.

urban

here is a example of a bugfixed version:

alienjeff wrote:"Puppy 3 Series" is a rather broad umbrella, at least IMO. It covers:

3.00alpha(s)
3.00beta(s)
3.00 final
3.00retro
3.00 fat free
3.01alpha(s)
3.01beta(s)
3.01 final
3.01retro
3.01 fat free
3.01-NOP
3.01-NOP-rev1
Chihuahua(s)
DCL
Fire Hydrant Featherweight 3.0b
Fire Hydrant FHmainAbi3.0b
Fire Hydrant FMmainOoffice3.0b
Fire Hydrant Inferno3.0b
Fire Hydrant FH_Jwm3.01c
Lassie(s)
LighthousePup 3.01a4
LighthousePup 3.01a4oo2.2
Pupeee
Shard 3.01
Talking Stick(s)

... and perhaps more, but I've run out of time and interest in hunting them down.

Your point is taken, but I don't think users of the Puplets will be likely to post their bugs here, and I'm fine with all the others posting them here - they're interrelated.

alienjeff wrote:I'll be more than happy to change the topic to your choice, however in light of the above, I'd appreciate an explanation of how it will avoid confusion. And please forgive me if I'm missing something obvious here.

Possibly missing something obvious. 3.02Alpha1 has already been replaced by 3.02Alpha2. That should mean this thread would be closed when Alpha1-specific bugs have been resolved and a new 3.02Alpha2 thread opened. I can't see us being that pedantic. If "Puppy 3 series" seems too broad to you, then maybe 3.02 bugs would be sufficient. When we upgrade to Beta that would become 3.03 bugs, etc. Just a thought, and a suggestion. I know how you hate to be TOLD what to do!

What I'm taking issue with is maintaining subject clarity. My motives are honorable. I assure you it's not my well-known defiant streak rearing it's ugly head. Besides, if I wanted to really pick at nits, I would have said that using the word "Puppy" in the subject is unnecessary.

I remain unconvinced, but am open for further discussion.

alienjeff wrote:What I'm taking issue with is maintaining subject clarity. My motives are honorable. I assure you it's not my well-known defiant streak rearing it's ugly head. Besides, if I wanted to really pick at nits, I would have said that using the word "Puppy" in the subject is unnecessary.

Oh, I had no doubt your motives were honorable. I have never questioned your motives and I don't plan to start doing so now. Mentioning your "well-known defiant streak" was only my way of having a gentle "dig", so you would know I wasn't crustily pushing for my own special viewpoint on the issue.

alienjeff wrote:I remain unconvinced, but am open for further discussion.

Great. My view is that if you are an average user trying to help Puppy advance by testing, you're unlikely to post bugs about your 3.02Alpha2, or 3.02Beta or 3.02RC1, in a thread entitled 3.02Alpha1 Bugs. What usually happens is those users can't find a suitable thread so they start their own - "My 3.02Beta doesn't do this ....". Depending on how many bugs there are, that can lead to fragmentation of the bug squashing effort, and problems that fall through the cracks.

Even worse is the likelihood that same user won't look in that 3.02Alpha1 thread for an answer about their 3.02Beta bug before posting either. Why would they? It doesn't relate to THEIR version, does it! So they become frustrated when someone says "It's in the bug thread already, ffs"!

Your bug thread is Sticky, as it should be so it sits at the top of the Projects section where it is easily found. IMHO it should also be clearly stated that it is to be used for bugs found in ANY mainline version of Puppy 3.xx, but certainly not for those found in Puplets like pcPuppyOS, Lighthouse, Firehydrant, PupEEE, etc. Those have specific problems of their own and belong in their own bugs thread.

I hope my thoughts on the issue are now clear. If, and only IF, you agree then I'd be pleased if you would come up with an alternative title for the thread that manages to make that situation clearer and hopefully overcomes the potential problems.

Cheers

WhoDo wrote:Mentioning your "well-known defiant streak" was only my way of having a gentle "dig" ...

I don't mind digs from you, Warren - gentle or otherwise. As a matter of fact, I rather enjoy them! Keeps one on his toes, so to speak.

Great. My view is ... <snip> much well thought out justification <paste> ... come up with an alternative title for the thread that manages to make that situation clearer and hopefully overcomes the potential problems.

You've convinced me this time. Good stuff per usual, Warren. Please note subject/topic alteration. Thanks for the input, brother. Be well.

I just changed the way my test system is installed. While everything works, the way options are presented is bound to confuse newbies. I had a frugal install on a flash drive, and I still have a frugal install there. What has changed is that the system now boots from there instead of from CD. People would report all these configurations as frugal installs:

1) pup_save.2fs or pup_save.3fs (only) on flash drive, boots from CD
2) above, plus sfs files on flash drive, boots from CD
3) bootable installation on flash drive with USBFLASH, syslinux, vmlinuz, initrd.gz and above.

Depending on the space available on the flash drive, each alternative can make sense in some circumstances.

When the installer found the pup_save.2fs file on a mounted drive, it gave me a message talking about a pup_save.3fs file. When it explained the options for solving the problem I didn't see the one I used, reboot with "pfix=ram", so it will ignore the pup_save.2fs file, do a typical frugal install to flash drive, choose "do not save" on shutdown. On reboot the system comes up using the previously created pup_save.2fs file. There is no confusing renaming, and no need to boot another system.

It is very likely more and more people will be using flash drives with preexisting pup_save files. (I'm out of empty flash drives. All are in use testing something.) We need to handle this better.

There is also the minor irritation of being asked about copying sfs files that were just installed. This is mostly harmless, but another source of confusion. ("Did I or did I not install these?")
---------Firefox "minefield"
This beta keeps trying to install the DOM inspector and then discovering it is incompatible, forcing an uninstall and restart. I thought I turned updating off, but it did it again. Anyone else experiencing this?

---------Xorg and modelines
Ages ago, by Puppy standards, I rashly told AJ I could solve his i810 video problem. All my experiments with systems having Xorg 7.2 failed to accept a modeline. This has been my secret weapon for getting video working whenever one Linux system was able to use video, but another was not. Can somebody explain what happened to modelines? I haven't seen anything elsewhere stating that these are no longer allowed, yet it seems Xorg is overriding an explicit modeline which is demonstrably within the range of the video adapter and monitor.

BTW: after years in which scarcely a week went by without a call to do something on a machine using one of the i810 chip sets I have now been two months without finding one I could use to reproduce AJs problem.

prehistoric

alienjeff wrote:

Great. My view is ... <snip> much well thought out justification <paste> ... come up with an alternative title for the thread that manages to make that situation clearer and hopefully overcomes the potential problems.

You've convinced me this time. Good stuff per usual, Warren. Please note subject/topic alteration. Thanks for the input, brother. Be well.

I've just noticed your response, AJ. Thank you to you, too, for being open to suggestions. It is much appreciated, mate.

Cheers.

urban soul wrote:I found a little bug in the network wizard in wag-profiles.sh in the function loadProfileData() :
This prevents the AP_MAC variable from beeing stored correctly.

Code: Select all

line 671 should read 
"PROFILE_DATA=`grep -A 11 ... "
instead of
"PROFILE_DATA=`grep -A 10 ... "

Beware that old wag-config files might have entries with too few lines. (e.g. AP_MAC variable missing) These old files can get corrupted by the bugfixed version.

urban

here is a example of a bugfixed version:

Thanks for that. The network wizard in Puppy4 Dingo has some later modifications than the package currently in 3.02alphax.
So, I've applied your fixes to the Dingo package, and posted it here.
You can see the comments at start of wag-profiles.sh that document changes.

Will have a look at it till friday.
Urban

@tronkel

Just burned 3.02alpha4.iso and booted with "pfix=ram". Boot message says alpha3.
Setup keyboard, video, networking - no problem.
Change background; conkey background stays same.
Insert flash drive to save setup. Shutdown blanks screen, can't even tell if there is a message about saving.

Personal preference: on a small screen like my laptop I'd prefer to have conkey near the top, with that background. I still prefer galculator to calcoo. I was happy with JWM, (but then any interface has to be better than the O26 keypunch I started computing with.)

Puzzled: the amount of free memory and the memory use displayed by conkey don't add up, alpha 4 appears to have substantially less free than alpha 3. Could it be difference in booting alpha 3 off USB flash and booting alpha 4 off CD?

Substantial changes between last two versions, have to expect some problems. The behavior at shutdown is the only killer I see.

Hi Barry,

I tested net-setup v.398 and everything works fine. I found only one little inconsistency which does not affect any of its functionality (in the extraction of iwlist params).

wag-profiles.sh v3.98:
line 1012: line 1128:
I tested it with my autoconnect script, which may fit into the usability-concept of puppy: regardless of where you are with you laptop, press a connect button and it will search profiles.conf for usable "titles" and connect you. Press again and radio is turned off.
You can set priority of profiles by re-ordering them in profiles.conf. Version 1.0 coming out soon. If feedback is positive, I make a nice GUI or tray app. Can rework pwireless to use profiles.conf as database also.

greetings,
urban