Puppy 3.00BETA bug reports here
man is set open the wikipedia page for the word of the command if it can't find the relevant info in /usr/share/doc
This currently means all busybox commands are pointed at wikipedia and the URL is calculated wrong
when I type
man man
I get
http://en.wikipedia.org/wiki/Man (warning gratuitous nudity)
when it should be
http://en.wikipedia.org/wiki/Man_(Unix)
note the upper M is not important as wikipedia will convert from lowercase
It is an interesting idea though I personally find the wikipedia pages less helpful than proper man pages. There is also the issue of the differences in switches available for full commands and for busybox ones, at least if you are pointing at busybox users will be aware of the difference.
Barry I still don't understand why the format
file:///usr/share/doc/busybox.htm#item_awk
file:///usr/share/doc/busybox.htm#item_rm
doesn't work for you, I've just tested it again in Netsurf.
Note to anybody else trying to test, /usr/share/doc/busybox.htm is not included in 3.00 beta.
Barry, I'm intrigued that you don't host proper man pages yourself if you want to do it this way. I would have thought that the bandwidth wouldn't be too excessive. If it does become a problem then you can post a small holding page with a dotpup patch to point it somewhere else the next time the person uses man. Whatever happens the problem could be solved in the next release.
This currently means all busybox commands are pointed at wikipedia and the URL is calculated wrong
when I type
man man
I get
http://en.wikipedia.org/wiki/Man (warning gratuitous nudity)
when it should be
http://en.wikipedia.org/wiki/Man_(Unix)
note the upper M is not important as wikipedia will convert from lowercase
It is an interesting idea though I personally find the wikipedia pages less helpful than proper man pages. There is also the issue of the differences in switches available for full commands and for busybox ones, at least if you are pointing at busybox users will be aware of the difference.
Barry I still don't understand why the format
file:///usr/share/doc/busybox.htm#item_awk
file:///usr/share/doc/busybox.htm#item_rm
doesn't work for you, I've just tested it again in Netsurf.
Note to anybody else trying to test, /usr/share/doc/busybox.htm is not included in 3.00 beta.
Barry, I'm intrigued that you don't host proper man pages yourself if you want to do it this way. I would have thought that the bandwidth wouldn't be too excessive. If it does become a problem then you can post a small holding page with a dotpup patch to point it somewhere else the next time the person uses man. Whatever happens the problem could be solved in the next release.
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
Wikipaedia is just temporary. I wanted to use:
http://linux.die.net/man/
but NetSurf does not display it properly -- I have informed the NetSurf developers about this, so hopefully it will be fixed for pup 3.01. Well, can't guarantee I'll stay with NetSurf anyway.
Note, the die.net site has a wider range of man pages than other online man pages that I checked out.
http://linux.die.net/man/
but NetSurf does not display it properly -- I have informed the NetSurf developers about this, so hopefully it will be fixed for pup 3.01. Well, can't guarantee I'll stay with NetSurf anyway.
Note, the die.net site has a wider range of man pages than other online man pages that I checked out.
Woops, that's not good! Good catch, kirk.
linux.die.net is a great man page resource, my favorite. Excellent place to point to, Barry. I ran their ifconfig man page through the W3C validator and it showed 6 errors. So part of the problem might be with them.
I tried Dillo on those pages and much of the pretty formatting was gone, but the text was fine.
linux.die.net is a great man page resource, my favorite. Excellent place to point to, Barry. I ran their ifconfig man page through the W3C validator and it showed 6 errors. So part of the problem might be with them.
I tried Dillo on those pages and much of the pretty formatting was gone, but the text was fine.
If anybody else wants to try, take a look at:dgi wrote:I just looked at this:dgi wrote:Hi. I've finally decided to try Puppy for the first time, jumping in with both feet. The machine is a Toshiba Satellite 105CS made in 1996, maxed out to 40MB RAM. Since there is no CD drive, and no PCI bus for a USB host, I thought I'd manually install the contents of the CD onto the HD. I felt that the only real choice for a filesystem on the HD is the lightning-fast JFS, but I found Puppy 2.17 missing it from its kernel, so I figured I should get involved in broadening Puppy3's horizons. Of course, the 3.00beta doesn't have JFS in the kernel nor initrd either, so I can't boot Puppy yet. Please build a second beta with JFS support included. Thank you.
http://puptrix.org/sources/kernel-2.6.2 ... N07-9.20pm
I see that the JFS module is already built. BarryK, will the 3.00beta2 initramfs have this module, and if not, why not? Also, I'm going to try using the CD with an external SCSI CD drive via WakePup2. For that, the i82365 and aha152x_cs modules will also need to be in the initramfs, which is just as simple, since they are also already being built. Sound might be an add-on PET package later, once Puppy gets a 2.6.22 kernel.
http://www.murga-linux.com/puppy/viewto ... 017#143017
- BarryK
- Puppy Master
- Posts: 9392
- Joined: Mon 09 May 2005, 09:23
- Location: Perth, Western Australia
- Contact:
...er, yes, the plugins package wasn't included, has to be installed separately.kirk wrote:Gnumeric in 3.00beta is missing most of it's functions. Only has 3. Not much use like that. Gnumeric in puppy 2.17 must have over 100.
Just click the f(x) button and then click on all functions to see the list.
Edit: /usr/lib/gnumeric/1.6.3/plugins is missing most of files.
-
- Posts: 7
- Joined: Mon 17 Sep 2007, 23:50
- Location: Fort Walton Beach, Florida
still no sounds
Greetings,
Using Toshiba A135-S4427 laptop I am still not getting any sound from the HDA-Intel (built in) sound card. It uses a Realtek AC861 chip set
Alsa config finds the card, runs but no sound. Was wondering if the new alsa rc2 made it into this beta. Also still not finding my Audigy2 ZS pcmcia sound card at all. Added the snd-emu10k1 driver but still no go on the pcmcia sound card recognition. Maybe something I have overlooked.
On the positive side, everything else works hardware wise, and no problems with booting or file system.
Last release that I had working sound on the HDA-intel was 2.14.
Looks good so far. Thanks for your continuing support of the project.
Using Toshiba A135-S4427 laptop I am still not getting any sound from the HDA-Intel (built in) sound card. It uses a Realtek AC861 chip set
Alsa config finds the card, runs but no sound. Was wondering if the new alsa rc2 made it into this beta. Also still not finding my Audigy2 ZS pcmcia sound card at all. Added the snd-emu10k1 driver but still no go on the pcmcia sound card recognition. Maybe something I have overlooked.
On the positive side, everything else works hardware wise, and no problems with booting or file system.
Last release that I had working sound on the HDA-intel was 2.14.
Looks good so far. Thanks for your continuing support of the project.
- klhrevolutionist
- Posts: 1121
- Joined: Wed 08 Jun 2005, 10:09
3beta2 Problems (Edited again to simplify)
I know there have been great strides in development, and am very pleased that we will have good package handling. However I have been using the new "tiny" (233M iso) installed fluxbox version of PCLOS and it's (rpm) repository seems superior to Slackware. For instance one fetches a Thunderbird version with or without Enigmail in a selected language, and that's it. It installs 8 files, no fiddling with finding the extension and separately installing Gnupg. But hopefully a sparser Puppy with Gslapt will work equally well. I mention this as it seems impossible to use GPG in Seamonkey 1.12 in a pristine Puppy 3beta. Seamonkey closes immediately, as it did previously in 1.08.
I also tried to upgrade my 2.17.1 config., which I have done without problem from 2.13 through 2.17.1. Some programs do not run, most notably the whole Seamonkey suite. The files from both 108 and 112 remain there in /usr/lib/seamonkey but I can run neither. Maybe because folders have changed (or whatever) but it's not realistic for me (or many users) to sort that out. Some sort of adaptation is needed for this, as upgrades are important to the user who has tailored his system over time.
But if I download Seamonkey 1.14 from the Mozilla site and manually install it (into /opt/seamonkey, in this case) it works fine, even in a ver. 3 upgrade.
Henry
I also tried to upgrade my 2.17.1 config., which I have done without problem from 2.13 through 2.17.1. Some programs do not run, most notably the whole Seamonkey suite. The files from both 108 and 112 remain there in /usr/lib/seamonkey but I can run neither. Maybe because folders have changed (or whatever) but it's not realistic for me (or many users) to sort that out. Some sort of adaptation is needed for this, as upgrades are important to the user who has tailored his system over time.
But if I download Seamonkey 1.14 from the Mozilla site and manually install it (into /opt/seamonkey, in this case) it works fine, even in a ver. 3 upgrade.
Henry
Last edited by Henry on Sun 30 Sep 2007, 04:42, edited 2 times in total.
- veronicathecow
- Posts: 559
- Joined: Sat 21 Oct 2006, 09:41
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
dhcpcd update.
rerwin reported a MAC-address misidentification issue with the new version of dhcpcd earlier in this thread, and also on the Developer Forum.
So I emailed the maintainer of the dhcpcd project, Roy Marples, about the problem. Roy's prompt reply was this:
"dhcpcd-3.1 uses client node identifiers, which is correct.
http://www.rfc-archive.org/getrfc.php?rfc=4361
To stop this either disable ENABLE_DUID in config.h or use -I '' on the dhcpcd command line.
Basically, the error is that the DHCP server assumes that the clientID field holds the MAC address.
This assumption is invalid for a few reasons
1) RFC 2131 states that the ClientID is optional
2) RFC 2131 also states that it could be a user defined string (type 0)
OR a MAC address (type 1)
RFC 4361 goes on to extent this by using type 255.
In other words, the DHCP server in question doesn't allow the RFC guidelines."
So the question is now whether we make a HOWTO post on the forum about this subject, and trust that affected users will see the information and be able to launch dhcpcd with the required parameters ... or I recompile dhcpcd with "ENABLE_DUID" disabled.
Any opinions?
Do we think that enough routers will have this problem to justify permanently disabling DUID?
Or is the DUID function, which is supposed to be technically correct, worth keeping?
rerwin reported a MAC-address misidentification issue with the new version of dhcpcd earlier in this thread, and also on the Developer Forum.
So I emailed the maintainer of the dhcpcd project, Roy Marples, about the problem. Roy's prompt reply was this:
"dhcpcd-3.1 uses client node identifiers, which is correct.
http://www.rfc-archive.org/getrfc.php?rfc=4361
To stop this either disable ENABLE_DUID in config.h or use -I '' on the dhcpcd command line.
Basically, the error is that the DHCP server assumes that the clientID field holds the MAC address.
This assumption is invalid for a few reasons
1) RFC 2131 states that the ClientID is optional
2) RFC 2131 also states that it could be a user defined string (type 0)
OR a MAC address (type 1)
RFC 4361 goes on to extent this by using type 255.
In other words, the DHCP server in question doesn't allow the RFC guidelines."
So the question is now whether we make a HOWTO post on the forum about this subject, and trust that affected users will see the information and be able to launch dhcpcd with the required parameters ... or I recompile dhcpcd with "ENABLE_DUID" disabled.
Any opinions?
Do we think that enough routers will have this problem to justify permanently disabling DUID?
Or is the DUID function, which is supposed to be technically correct, worth keeping?
Add another button to the network wizard under the "Auto DHCP" button, "Auto DHCP w/o DUID"? And use it to launch with the -I switch? Normally, users trying to get their network up will attempt one, then the other, without much in the way of support on the forum...
Could add a short explanatory note there also, or something as simple as "If Auto DHCP does not work, try Auto DHCP w/o DUID."
First let's make sure adding the switch on the command line does actually fix the problems rerwin and maybe others have seen...
Could add a short explanatory note there also, or something as simple as "If Auto DHCP does not work, try Auto DHCP w/o DUID."
First let's make sure adding the switch on the command line does actually fix the problems rerwin and maybe others have seen...
-
- Posts: 5464
- Joined: Fri 10 Jun 2005, 05:12
- Location: Australia
Yes indeed. rerwin (and gliezl) the command is -PaulBx1 wrote:First let's make sure adding the switch on the command line does actually fix the problems rerwin and maybe others have seen...
Code: Select all
dhcpcd -I '' eth0
And it might be necessary to kill dhcpcd first, if it's already running
Code: Select all
dhcpcd -k eth0
rm /etc/dhcpc/dhcpcd-eth0.*
- veronicathecow
- Posts: 559
- Joined: Sat 21 Oct 2006, 09:41
Hi Barry, am using the 3.00 beta and have backgrounded the network with the code from this thread
http://www.murga-linux.com/puppy/viewtopic.php?t=13130
and it is working fine.
It Knocked 21% off my boot time (from 43 down to 34 seconds excluding POST)
PClinux takes 55 seconds to boot.
I think we should be able to boot in half that speed with a bit of tweaking
http://www.murga-linux.com/puppy/viewtopic.php?t=13130
and it is working fine.
It Knocked 21% off my boot time (from 43 down to 34 seconds excluding POST)
PClinux takes 55 seconds to boot.
I think we should be able to boot in half that speed with a bit of tweaking
- veronicathecow
- Posts: 559
- Joined: Sat 21 Oct 2006, 09:41