Page 25 of 28

Posted: Wed 16 Dec 2009, 06:35
by shankargopal
gposil wrote:SHS makes a very good point, until application developers catch up with glibc development, we'll leave libiconv in the devx, but all new apps and upgrades should be taken from Debian branch(which doesn't use it).

Cheers
Guy
For an example: I recently was trying to compile Enlightenment DR17's latest snapshots and fell flat because of weird complaints about libiconv... which I now think I understand thanks to everyone. But there, for instance, is a set of code that is up to date as of Dec 2nd but still uses libiconv.

musher0: re devx, I've had exactly the same problem, but in my case it seems to be inconsistent - it works with some pupsave files and not with others. Can you check if maybe, just maybe, you are also having my "nothing saves in /etc" problem on your dpupsave? I had thought that was the source of the difficulty with loading the SFS file.

Sorry incidentally to not get back on your good suggestions in that regard... but have tried fsck'ing the file (it boots with pfix=fsck anyway) and the pen drive, and now tried changing the size of the dpupsave file, all with no luck so far.

Posted: Wed 16 Dec 2009, 07:48
by gposil
Iguleder wrote:gposil: pidgin-light maybe?

Should I compile udev for dpup? Does dpup use udev at all? If that's the case, I'll compile udev-147 with custom rules (I'll remove stuff like tape devices, all pre-i686 era stuff), because if I remembe right, it was released with 2.6.31.x. And no, udev-149 doesn't compile on my Debian. If that goes right, I'll try to compile util-linux-ng and module-init-tools.

EDIT: yes, it does ... ancient udev-124.

BTW: dpup has BusyBox svn from the 1.15 era, not 1.15.2.
Pidgin-light may be a good idea as well...Dpup484 already has udev-1.49 along with a fair smattering of the Squeeze core.

Posted: Wed 16 Dec 2009, 09:12
by Iguleder

locale en_GB : LC_TIME="C"

Posted: Wed 16 Dec 2009, 11:22
by Terryphi
Althought I have choosen en_GB as my locale Thunderbird is not picking up the UK date format DD/MM/YY.

Looking further into this I see that Dpup 4.82 produces a different output than Puppy 4.31 for # locale .

Dpup shows:

# locale
LANG=en_GB
LC_CTYPE="C" and so on.

Puppy 4.31 shows:
# locale
LANG=en_GB
LC_CTYPE="en_GB" and so on.

What is different ( or missing) in Dpup 4.82?

Posted: Wed 16 Dec 2009, 11:37
by dejan555
This one also looks nice, opens in sidebar and doesn't need extra tab opened if no conversation, but it's also big 2.2 MB!
https://addons.mozilla.org/en-US/firefox/addon/1833

Posted: Wed 16 Dec 2009, 11:44
by sinc
Since your trying to save space and i know his previous version is included in dpup. this is from ttuuxxx's thread
Here's another hash md5sum utility about 1/3 the size of gtkhash Smile and it provides more hash formats and its about 10 times faster Smile Smile Smile
excellent stuff, I even included rox right clicks on a few formats Smile
ttuuxxx
http://www.murga-linux.com/puppy/viewto ... start=2549

Re: locale en_GB : LC_TIME="C"

Posted: Wed 16 Dec 2009, 14:05
by gposil
Terryphi wrote:Althought I have choosen en_GB as my locale Thunderbird is not picking up the UK date format DD/MM/YY.

Looking further into this I see that Dpup 4.82 produces a different output than Puppy 4.31 for # locale .

Dpup shows:

# locale
LANG=en_GB
LC_CTYPE="C" and so on.

Puppy 4.31 shows:
# locale
LANG=en_GB
LC_CTYPE="en_GB" and so on.

What is different ( or missing) in Dpup 4.82?

Edit /etc/profile and comment out the lines below (line 92-93 I think)

Change from
LC_ALL=C
export LC_ALL
to
#LC_ALL=C
#export LC_ALL
That will fix it...Change already in 484

Re: locale en_GB : LC_TIME="C"

Posted: Wed 16 Dec 2009, 14:41
by Terryphi
gposil wrote:
Edit /etc/profile and comment out the lines below (line 92-93 I think)

Change from
LC_ALL=C
export LC_ALL
to
#LC_ALL=C
#export LC_ALL
That will fix it...Change already in 484
Thanks gposil. That worked. :)

Posted: Wed 16 Dec 2009, 18:53
by musher0
Hello.

I'd like to submit this for review. It is a fixmenus replacement inspired by plinej's and MU's previous work on this script.

Code: Select all

#!/bin/sh
#v2.14 Puppy now has XDG menus.
#this script builds the menus from template files.
#Any templates can be placed into /etc/xdg/templates, and the file must be
#named to show its final destination. For example, the template for JWM:
# _root_.jwmrc
#...the '_' will be converted to a '/', so the generated JWM config file is:
# /root/.jwmrc
# 5jan2008: fbpanel, lxpanel support developed by plinej.
# 
# NAME THIS SCRIPT fixmenus2 TO AVOID CONFUSION
# NOMMER CE SCRIPT fixmenus2 POUR ÉVITER LA CONFUSION
# Voir aussi fixmenus-compagnon.sh
# Remanié par musher0, mi-décembre 2009

#-- patch by MU 
theme=`grep '<Include>/root/.jwm/themes' /root/.jwmrc` 

#-- patch2par MU pour fixmenus, remaniée
oldsize=`cat ~/.oldxdg`
newsize=`ls /usr/share/applications | wc -c` 
oldsize2=`cat ~/.oldxdg2` 
newsize2=`du -b -s /usr/share/applications` 
doit="0" 

if [ "$oldsize" != "$newsize" -o "$oldsize2" != "$newsize2" ];then 
   doit="1" 
fi 
if [ "$doit" = "0" ];then 
   exit 0 
fi 
echo "$newsize" > ~/.oldxdg 
echo "$newsize2" > ~/.oldxdg2 
#sync 
#-- end of patch2 by MU 

#-- added by MU: display a message 
xmessage -bg orange -center -buttons "" "rebuilding menus..." & 
pid=$! 
# -borderless

#Puppy 2.14: XDG menu 
TEMPLATES="`ls -1 /etc/xdg/templates | tr '\n' ' '`"

for ONETPL in $TEMPLATES
do
 [ "$ONETPL" = "README.txt" ] && continue
 ONEDEST="`echo -n "$ONETPL" | sed -e 's/_/\//g'`"
 ONESRC="/etc/xdg/templates/$ONETPL"
 echo "Generating $ONEDEST..."
 
 [ -f $ONEDEST ] && mv -f $ONEDEST ${ONEDEST}-previous

 cat $ONESRC |
 while read ONELINE
 do
  EXECMENU="`echo -n "$ONELINE" | grep -o 'PUPPYMENU.*' | cut -f 2-5 -d ' '`"
  if [ "$EXECMENU" = "" ];then
   echo "$ONELINE" >> $ONEDEST
  else
   ${EXECMENU} >> ${ONEDEST}
  fi
 done

done

#1nov2008: add space(s) beetween icon and text
# ajout par plinej (musher0)
sed -i -e 's/label="/label="  /g' ${ONEDEST}
# conservé

#-- patch by MU 
sed -i -e "s#</JWM>#$theme\n</JWM>#" /root/.jwmrc 

#support for fbpanel, lxpanel, openbox, fluxbox, pekwm... 
# Remplacé par fixmenus-companion.sh (musher0, 14 déc. 2009)
kill $pid 
# de fixmenusMU
###END###
As announced in the above script, I also produced this, a companion file that deals with additional manipulations we want to bring to the pekwm menu, etc. In this one, the case entries for openbox and fluxbox are commented on purpose. If someone can (in)validate them, I'd be grateful.

I felt that this new script was needed in the presence of two or more WM's on a particular Puppy.

Code: Select all

#!/bin/sh
# fixmenus-companion.sh
# Emplacement suggéré / suggested location : /root/my-applications/bin
# musher0, 13 décembre 2009
# Script pour mettre à jour seulement les menus des
# barres et gestionnaires de fenêtres ACTIFS.

# 1) Mise à jour du menu de référence pour jwm.
/usr/sbin/fixmenus2 &
sleep 5s
# Patience ! Ça prend le temps que ça prend !

# 2) Mise à jour de la barre active
# Inspection des variables -- d'après patch2 de MU pour fixmenus

oldsize=`cat ~/.oldxdg` 
newsize=`ls /usr/share/applications | wc -c` 
oldsize2=`cat ~/.oldxdg2` 
newsize2=`du -b -s /usr/share/applications` 

if [ "$oldsize" != "$newsize" -o "$oldsize2" != "$newsize2" ];then 
    if [ "`ps -C fbpanel|tail -c 8`" = "fbpanel" ];then
        tempicons &
        fbpanel_menu_refresh &
        sleep 12s
        else
        if [ "`ps -C lxpanel|tail -c 8`" = "lxpanel" ];then
            tempicons &
            lxpanel_menu_refresh &
            sleep 12s
        fi
    fi
fi
if [ "`ps -C fbpanel|tail -c 8`" != "fbpanel" -a  "`ps -C lxpanel|tail -c 8`" != "lxpanel" ];then
    echo non > non.txt &
# obmenu_refresh ? 
# what other panels are there?  
fi

# 3) Mise à jour du menu du gestionnaire de fenêtres actif
CURRENTWM=""
CURRENTWM=`cat /etc/windowmanager | head -c 3`
# ligne ci-dessus par 01micko
case $CURRENTWM in 
pek)
    if [ "$oldsize" != "$newsize" -o "$oldsize2" != "$newsize2" ];then 
        jwm2pekwm &
        sleep 8s
# On attend que le menu des barres soit entièrement mis à jour. 
    fi
    cd /root/.pekwm/
    /root/.pekwm/manip_menu_pekwm2.sh &
    # modifier en conséquence si on utilise le présent "compagnon".
    ;;
wmx)
    if [ "$oldsize" != "$newsize" -o "$oldsize2" != "$newsize2" ];then 
        /usr/sbin/gen_menu_wmx.sh &
        sleep 8s
    fi
    ;;
# flu)
# Dé-commenter après validation
#    if [ "$oldsize" != "$newsize" -o "$oldsize2" != "$newsize2" ];then 
#    jwm2fluxbox &
#    sleep 8s
#   fi
#    ;;
# ope)
# Dé-commenter après validation
#    if [ "$oldsize" != "$newsize" -a "$oldsize2" != "$newsize2" ];then 
#    obmenu-refresh &
#    sleep 8s
#    fi
#    ;;

# Ni echinus ni ouriço n'ont de menu à eux, et les menus de 
# icewm et de jwm sont mis à jour par fixmenus même.
# Autres ??

esac
echo "$newsize" > ~/.oldxdg 
echo "$newsize2" > ~/.oldxdg2 
The whole thing works quite well and I'll be including them in the pekwm pet. However I do not like the fact that the variables oldsize, etc. are redundant in both scripts, but I get an error if I try to export them from the first script.

Any and all comments / suggestions for improvements / positive criticisms are welcome.

Sincerely,

Posted: Wed 16 Dec 2009, 19:03
by musher0
Hello again.

Perhaps a rationale for the above is in order.

The main difference with the regular fixmenus is that the above scripts do NOT check for the presence of file x on the user's machine.

Rather they check for presence of size and time changes (MU's modifications) and for existence of a particular process in activity (my contribution).

This way, a lot of time is saved when updating the menus. In addition, the second script allows for fine-tuning for particular WM's, which the original fixmenus did not allow for, or minimally.

Sincerely,

Posted: Wed 16 Dec 2009, 19:18
by musher0
Another note concerning the above scripts.

fixmenus2 can be called independently, as usual, OR from its "companion" file. It would be pointless and a waste of time to execute fixmenus2 and then the "companion" file.

(Please do if you are checking them out, of course, but for regular use, it is pointless to use both.)

Execution of the companion file "fixmenus-compagnon.sh" is recommended if you are actively using an alternate window manager. Its use is absolutely not necessary if you're simply using jwm or icewm all the time.

Posted: Fri 18 Dec 2009, 09:18
by gposil
Hi guys...working on the devx for 484...but have also been adding some more pets to the Dpup repo (http://distro.ibiblio.org/pub/linux/dis ... ackages-5/).

Keep an eye on the repo for new additions, and let me know if we need to add something...

Posted: Sat 19 Dec 2009, 07:32
by James C
Starting to get a good selection of pets in there. Great job..... :)

Posted: Sat 19 Dec 2009, 08:46
by ttuuxxx
the gnome-games-Lite_2.26.1-i486-dpup.pet looks like a repack of the one I made up for upup, I totally understand why, lol it was a pain to make up the first time round and it worked on dpup out of the box.
great work gposil :)
ttuuxxx

Posted: Sat 19 Dec 2009, 19:49
by Jim1911
dposil wrote:Jim1911 said:
Quote:
2. Installed gnome-games-Lite_2.26.1-i486-uj using ppm. It is missing libltdl.so.7. All games appear to work fine after renaming libltdl.so.3 in /usr/lib/ to libltdl.so.7

You need the original libltdl.so.3, libtdl7 is a slightly different library, it is here ..http://distro.ibiblio.org/pub/linux/dis ... a-dpup.pet

Cheers
Guy
ttuuxxx,
As indicated above, dposil modified your upup version slightly for dpup to take care of the differences in libtdl in upup and dpup. Thank you for that pet among many others that you have shared with us.

Merry Christmas and Happy New Year to all the dpup team,
Jim

Posted: Sun 20 Dec 2009, 03:24
by gulk
Arriving late on the dpup testing part...

Well, my first impression of dpup 482 beta5 is wow. That's actually an understatement. That thing is über fast, extremely stable and correct all of the quirks I had with 4.2.1.

You guys are good. Another understatement.

Best wishes for 2010! And thousands thanks for such commitment.

Posted: Sun 20 Dec 2009, 05:03
by musher0
I can't speak for the other devs, but as for me: many thanks, gulk! Your comment is very encouraging! We're certainly doing our best!

Discussion regarding sfs-Linker on ChoicePup thread

Posted: Sun 20 Dec 2009, 15:46
by mikeslr
Dear gposil and 01micko:

Just a note to call your attention to the discussion by sunburnt & jrb on the ChoicePup thread regarding the problems with linker and their solutions.

http://murga-linux.com/puppy/viewtopic. ... 5&start=90

mikesLr

Posted: Sun 20 Dec 2009, 15:49
by gerry
I tried dpup482b5 on my old machine, which normally needs a retro kernel, because some modern kernels are patched to still work on old m/c.
Well, it worked beautifully- I really like the clean desktop option. BUT when I clicked on reboot, intending to create the pupsave etc, the computer crashed, with a multicoloured line about 20mm wide across the screen.
Oh dear! I do need the retro after all.

Still, it works fine on the Acer Aspire One.... (not tried camera and other netbook gadgets that I don't know about).

If you can cast your mind back to the dpup that does have a retro kernel (477b1), and which won't boot up a second time (it gets a kernel panic) was there a quick fix that I could put in?

gerry

Posted: Mon 21 Dec 2009, 03:01
by gposil
gerry,

If you can stand waiting a week or so, the 484beta will be coming with a retro kernel as well as std kernel...I am just finalizing it now...


Cheers
Guy