Puppy 5.3

[Béèm]

Anyway, Lobster is doing his promotion job.
I know know about the 5.3 plans and I am happy it is spup based. I use that for quite some releases now. Good work 01mick.

As for functionality, I see Bluetooth and udf (udftools) to be added if possible.

Also I am eager to see how the bug tracking system will work.
Needs good management for it, but anyway those 200+ thread are almost impossible to digest, specially if one is away for (even a short) while and without internet access.

[live]

>Also I am eager to see how the bug tracking system will work.

I agree:
1/ bug reporting is poor, I'm ready to give some hand, as have a reputation to be witted in that area.
2/ bug reporting is nice, but without actions it's an intellectual masturbation.

My personal wish would be
1/ fix booting bugs - I have at least one.
2/ fix missing hardware support - I have couple, some other complained about same issues.
3/ fix software bugs - I have some as well.

Some bugs I reported are still unfixed in Lupu525 and I won't report any other, until I see actual fixes.
I have not the knowledge (maybe it'll come with experience) to fix them myself.

Last being "conservative".
Well, sure if you introduce too much novelty at once, you are at risk to be unable to pinpoint the effect of radical changes. I remember an interview of a test pilot during the quest for super & hyper-sonic planes (X-series projects), that in one of the X-model, NASA introduced so many new technologies, that they never figured out why this model didn't fly correctly and had to revert back to the previous X-model fork.

At the same time, staying with outdated technology for conservative purpose is also unwise (I'm thinking here at staying with Iron 6 in Debian, or old ntfs-3g).
Inspire yourself of http://partedmagic.com/doku.php?id=changelog

Respectfully,

Live

[bones01]

Hi all,



stu90, (16 April)
Browser chooser was nice but I am of the opinion that we need a full featured secure browser in the disto by default. When I first used Puppy I didn't like seamonkey too much either, but I am a former netscape user and I soon realised the similarities. In Lupu there is Midori, Dillo, the nss and nspr libs, and Sylpheed. All this adds up to about 9M compressed. Current Seamonkey is about 12M compressed. I preferred Puppy 500's approach with Puppy Browser but it's too out dated now. Of course browser choosing can be in, but Seamonkey (if I have any say), is in by default. I'm sure I'll get a million detractors, but that's how I feel about it.

Cheers!

Micko, I want to add my voice to the inclusion of a working browser. It has been an immense frustration to me that when I run a Live CD I can't have full access to the net. Seamonkey is OK for me. I can get Firefox myself (or Opera) later if I choose.

Cheers

Bones

[tubeguy]

Logo idea, need feedback!



Some different versions:

http://tubeguy.org/puppybg/spup_logo_transparent.png

http://tubeguy.org/puppybg/spup_logo_blue_gradient.png

http://tubeguy.org/puppybg/spot_logo_plain.png

http://tubeguy.org/puppybg/spot_logo_blue_back.png

http://tubeguy.org/puppybg/spot_logo_blue_gradient2.png

Edit: 2 more:

http://tubeguy.org/puppybg/puppy_linux_ ... ground.png

http://tubeguy.org/puppybg/puppy_linux_ ... _plain.png

[dejan555]

I like this one the best
http://tubeguy.org/puppybg/spot_logo_blue_back.png

Not sure about the white eye though.

[tubeguy]

I like this one the best
http://tubeguy.org/puppybg/spot_logo_blue_back.png

Not sure about the white eye though.

http://tubeguy.org/puppybg/spot_logo_bl ... rayeye.png

Better?

[sc0ttman]

01micko, regarding the WM utils, I have a few ideas, yours are probably better! I can PM you when I have a bit more flesh on the bone... Still not at all up to date with all the WMs and their utils, but have a plan to make a BASH script which takes a given task, checks the current WM, and then loads up a relevant WM app/util.

About the dependencies/compiling, as long we we keep in mind that it would be nice to make compiled packages as backwards compatible as possible, whether it be through fewer dependencies due to a slackware base, or whatever else, then that's good.

Amixer is a tiny mixer GUI... There's a few different tiny mixers on the PupnGo thread, but they are quite old/basic looking.

Barry said he plans to update or improve the /usr/local/bin/default*** stuff, so I wonder where that would need to go... Still think we need a 'defaults-chooser' thing - particularly as this forum has seen many users complain when a PET package changes a default*** without their consent.

And, personally, for what it's worth, I think it's better to include things like Xchat and Transmission as standard, even older versions are better than nothing, particularly when these packages are like 200kb-300kb...

Although I still think we should go for a small, lean ISO if we can, so users of older PCs don't miss out as much as they might have done with Lucid.

[dejan555]

Looks better tubeguy

[MinHundHettePerro]

http://tubeguy.org/puppybg/spot_logo_bl ... rayeye.png

Better?

The best image yet of the S(ubGenius)Pup..........

Cheers / MHHP

[scsijon]

@tubeguy, personally what i'd to see happen (please):

1/ get rid of the pipe (anti-smoking legislation and all that stuff does include pipes in australia), really don't think puppy (and barry as it's public officer) needs those hastles;

2/ put a 'cloud' symbol above spup and have the version number appear in it (?could this be done as part of the loading or running rather than have to be manually recreated for each version), don't know the number of times i've had to search to find which one i'm using at that time when testing and found i'm testing on an old one;

3/ allow users to 'do' the background colour themselves (if possible) from a full colourset;

and

4/ Make it suitable to be the background image as well as spup 'icon'.

just my thoughts

scsijon
ps preferably not a white-spot in eye, usually associated with glaucomic blindness in both humans and animals.

[tubeguy]

@tubeguy, personally what i'd to see happen (please):

1/ get rid of the pipe (anti-smoking legislation and all that stuff does include pipes in australia), really don't think puppy (and barry as it's public officer) needs those hastles;

2/ put a 'cloud' symbol above spup and have the version number appear in it (?could this be done as part of the loading or running rather than have to be manually recreated for each version), don't know the number of times i've had to search to find which one i'm using at that time when testing and found i'm testing on an old one;

3/ allow users to 'do' the background colour themselves (if possible) from a full colourset;

and

4/ Make it suitable to be the background image as well as spup 'icon'.

just my thoughts

scsijon
ps preferably not a white-spot in eye, usually associated with glaucomic blindness in both humans and animals.

Thanks for the feedback!

If this is a double post, sorry.

1-The pipe is a subhuman/slackware thing but I can do version without.

2-Cloud thing should be easy enough.

3-Do you mean multiple versions with different backgrounds?

4-Originals are 2000px wide so backgrounds are not a problem. Not sure how the rectangular format will translate to an icon though.

Also all the .psd originals are uploaded here in no particular order, anyone can feel free to modify.

Edit: No more white eye!

[rjbrewer]

@tubeguy, personally what i'd to see happen (please):

1-The pipe is a subhuman/slackware thing

Wrong;

Slack and the pipe are from Reverend J.R.(Bob) Dobbs and the
Church of the Subgenius.

[scsijon]

3-Do you mean multiple versions with different backgrounds?

4-Originals are 2000px wide so backgrounds are not a problem. Not sure how the rectangular format will translate to an icon though.

Hi, thanks for the quick reply.

for 3/ I was considering if it could be userset, say like the 'base' as forground and fixed with the background setable by the user? Like having a transparent background, not sure if it could be done though.

for 4/ most people don't realize you can have any shape for an icon in linux, it's just having the config capable of displaying them. It's only by default that we use squares.
-------------------
extracted from my other post for others thoughts (please)

As an outcome of previous posts and threads by others, I would like to put forth the idea of only one wm be built-in to 53, jwm of course as most are able to use it and it's puppy's 'standard'. The others are to built and maintained by their own 'sub-teams', to be available via the quickpet or ppm applications as pet's. Should mean a somewhat easier development of the base product, and those people that want other wm's could work as individual teams to concentrate on getting their's working, while knowing the underlying system behind it all is solid and stable. Also means they could deal with updates of individual wm's easier.
------------------
And lastly for 01Micko,

This ?may do what we want to help for a dynamic menu system, has a slackware package at www.linuxpackages.net. if you want to try it.
Quote: Wmconfig is a text-based menu generation tool for various X window managers for desktops. Toolkits like Qt or Gtk are not required. It uses a simple configuration layout and the configuration may be edited with a text editor.
http://www.arrishq.net/home

regards to all
scsijon
ps, can someone 'talk' ziggy into the "team", he does come up with some interesting things (I missed his presence in 525).

[tubeguy]

@tubeguy, personally what i'd to see happen (please):

1-The pipe is a subhuman/slackware thing

Wrong;

Slack and the pipe are from Reverend J.R.(Bob) Dobbs and the
Church of the Subgenius.

Subgenius. I meant Subgenius. Brain damage from past excesses.

[tubeguy]

Hi, thanks for the quick reply.

for 3/ I was considering if it could be userset, say like the 'base' as forground and fixed with the background setable by the user? Like having a transparent background, not sure if it could be done though.

for 4/ most people don't realize you can have any shape for an icon in linux, it's just having the config capable of displaying them. It's only by default that we use squares.

3- Not sure how that would be done. Transparent background is easy though, just has to be a png or gif or other format that can do transparency. With that anyone can open it in gimp and make their own background.

4-Did not know that.

I just got in for tonight, chores and things to do tomorrow morning, will work some more on this tomorrow afternoon.

[Iguleder]

Oh, something I just you reminded me - Debian has a nice package called "choosewm". It's a nice menu (configurable menu!) with a list of window managers that lets you choose which one to start and a checkbox that lets you make this choice persistent.

We could compile this baby and make it the default window manager - this way, the user can select a window manager/DE easily.

[rcrsn51]

The ability to install a DEB package just by clicking on it should be removed. There are numerous confirmed cases of this action corrupting the Puppy file system.

[scsijon]

The ability to install a DEB package just by clicking on it should be removed. There are numerous confirmed cases of this action corrupting the Puppy file system.

Part of the reason why I sugested all installs via ppm, it does at least some checking, like dependancies, and it's not only deb's for fairness, i've had early pets do the same, especially when found 'not what was thought it was' and uninstalled, lost access to others when bits have been uninstalled also. Maybe as part of the ppm changes some more rigorous checking could be added. It could even be a 2part install, 1stly unpack the package, check against existing or missing dependancies, report if so giving the right to stop, if a ok is pressed then 2-install. etc.

At least have a warning and breakout point in the deb install script to start with.

[01micko]

The ability to install a DEB package just by clicking on it should be removed. There are numerous confirmed cases of this action corrupting the Puppy file system.

I have a theory on why this happens.

Check help for dpkg-deb (how puppy installs debs)

Code: Select all

# dpkg-deb --help
Usage: dpkg-deb [<option> ...] <command>

Commands:
  -b|--build <directory> [<deb>]   Build an archive.
  -c|--contents <deb>              List contents.
  -I|--info <deb> [<cfile> ...]    Show info to stdout.
  -W|--show <deb>                  Show information on package(s)
  -f|--field <deb> [<cfield> ...]  Show field(s) to stdout.
  -e|--control <deb> [<directory>] Extract control info.
  -x|--extract <deb> <directory>   Extract files.
  -X|--vextract <deb> <directory>  Extract & list files.
  --fsys-tarfile <deb>             Output filesystem tarfile.

  -h|--help                        Show this help message.
  --version                        Show the version.
  --license|--licence              Show the copyright licensing terms.

<deb> is the filename of a Debian format archive.
<cfile> is the name of an administrative file component.
<cfield> is the name of a field in the main `control' file.

Options:
  --showformat=<format>            Use alternative format for --show.
  -D                               Enable debugging output.
  --old, --new                     Select archive format.
  --nocheck                        Suppress control file check (build bad
                                     packages).
  -z#                              Set the compression level when building.
  -Z<type>                         Set the compression type used when building.
                                     Allowed values: gzip, bzip2, lzma, none.

Format syntax:
  A format is a string that will be output for each package. The format
  can include the standard escape sequences \n (newline), \r (carriage
  return) or \\ (plain backslash). Package information can be included
  by inserting variable references to package fields using the ${var[;width]}
  syntax. Fields will be right-aligned unless the width is negative in which
  case left alignment will be used.

Use `dpkg' to install and remove packages from your system, or
`dselect' or `aptitude' for user-friendly package management.  Packages
unpacked using `dpkg-deb --extract' will be incorrectly installed !

To me that warning down bottom seems pretty strong.

I have successfully installed debs converting them to pets in a sandbox, with no corruption as far as I could tell, so perhaps using dpkg-deb to unpack the deb in a sandbox, then merging the files with the filesystem would be safer, not 100% sure, will do some testing.

here's (I think) the offending code in /usr/local/petget/installpkg.sh (line 131)

Code: Select all

*.deb)
  DLPKG_MAIN="`basename $DLPKG_BASE .deb`"
  PFILES="`dpkg-deb --contents $DLPKG_BASE | tr -s ' ' | cut -f 6 -d ' '`"
  [ $? -ne 0 ] && exit 1
  echo "$PFILES" > /root/.packages/${DLPKG_NAME}.files
  install_path_check
  dpkg-deb -x $DLPKG_BASE ${DIRECTSAVEPATH}/
  if [ $? -ne 0 ];then
   rm -f /root/.packages/${DLPKG_NAME}.files
   exit 1
  fi

where ${DIRECTSAVEPATH} is self explanatory (in case of frugal /initrd/pup_rw .. where I was experiencing permissions corruption).

I will do further testing in hope of fixing this bug.

[ttuuxxx]

well if this is a slackware based distro, Installing Debian packages should be removed, since many of them won't work, a few will, Its just a bad practice to install debian packages on a slackware base and should be Outlawed yes I said Outlawed. But of course automatically sending .deb packages to archiver for extraction purposes only does make sense.
Just my point of view.
ttuuxxx