Dpup482-beta5 testing

Message

gposil · #451 Post by **gposil** » Mon 14 Dec 2009, 15:08

dejan555 wrote:Well, libiconv is in devx so most apps that use libiconv compile against it, I'll see if there's option in configure not to use it, is there some other library I can specify in compile options instead? But I don't think I saw that in ./configure --help
Library is quite huge ~1.3 MB, that's half the size of iguleder's distro xD so it would be good if I could compile apps without it. I understand that it's used for charset support/conversion?

Yes, it was only in the devx for backward compatability, charset support/conversion in Debian Lenny and later are part fo the core libc...your best bet it to grab the source from the debian repo, or use the Debian Squeeze binary packages, as beta6 has the Squeeze core.

dejan555 · #452 Post by **dejan555** » Mon 14 Dec 2009, 15:18

Hmm, what if I just delete libiconv and header files if there

dejan555 · #453 Post by **dejan555** » Mon 14 Dec 2009, 15:38

Well, maybe better not to compile until we settle for definite base/have compatible devx, or maybe I should learn more on compile options

I see that there are newer versions of both weechat/fluxbox in testing repo but like ttuuxxx said sometimes it's best to compile and configure packages for puppy, like small things as setting wallpaper folder /usr/share/backgrounds and using Puppy Wallpaper's set_bg instead fbsetbg and including option to switch to jwm from menu and such... But there's no point in putting packages in repo which will have libs for something that's already supported in core system.

Iguleder · #454 Post by **Iguleder** » Mon 14 Dec 2009, 16:21

gposil: should I compile BusyBox, module-init-utils, util-linux-ng, udev, all those? I think Puppy needs a complete overhaul of all basic utilties, they're totally outdated (things like DVB are supported by the newer udevs, for example). I also think it's possible to ditch dhcpcd in favor of udhcpc to save some space, I use it in my distro and it works just fine. /etc/resolv.conf has the same syntax.

Another thing, what CFLAGS do you use? I think we needs some dpup "standard" of CFLAGS=-march=i686 -mtune=i686 or something.

Oh, last thing ... I'm quite enthusiastic about this one ... SliTaz and Tiny Core compatibility for Puppy, how does that sound? SliTaz's package manager is just bash scripts and one gtkdialog frontend, that can be easily ported. TC's extensions mechanism is even simpler, just SFSs with all files, plus a script (similar to pinstall.sh). The problem is FLWM/JWM menu incompatibility.

dejan555 · #455 Post by **dejan555** » Mon 14 Dec 2009, 16:54

Now don't get too excited we're making it debian compatible we don't rewrite whole system

Iguleder · #456 Post by **Iguleder** » Mon 14 Dec 2009, 17:09

I didn't say that. A newer kernel needs a newer udev, newer module-init-utils and util-linux-ng. New file systems, new hardware support.

Don't say this doesn't make any sense.

musher0 · #457 Post by **musher0** » Mon 14 Dec 2009, 17:42

dejan555 wrote:Well, libiconv is in devx so most apps that use libiconv compile against it, I'll see if there's option in configure not to use it, is there some other library I can specify in compile options instead? But I don't think I saw that in ./configure --help
Library is quite huge ~1.3 MB, that's half the size of iguleder's distro xD so it would be good if I could compile apps without it. I understand that it's used for charset support/conversion?

To dejan555 but perhaps more to gposil:

If libconv is used for charset support/conversion, and it's deprecated in Debian, what is dpup using now for charset support/conversion?

Is that why some iso-8859-1 text won't save in utf-8 and vice-versa?

I'll be greatly affected / concerned if the dpup distro loses multi-lingual capacity...

Sit Heel Speak · #458 Post by **Sit Heel Speak** » Mon 14 Dec 2009, 19:35

I have been wrestling with libiconv on several fronts this past week. To summarize my findings:

glibc now contains libiconv's functions and so the use of libiconv is in flux.

*Most* modern programs are designed to use glibc's functions. Those that aren't, often need a parameter on the compile configure line...consult the configure script for exact syntax, but typically it is

--with-libiconv=<dir+subdir libiconv is in>

typically

--with-libiconv=/usr/local/lib

and sometimes a make directive

LIB=-liconv

or, on the configure line,

--with-lib=-liconv

Sometimes moving the iconv.h file up to the top of /usr/include, from where it resides deeper within, is necessary. Or, copy it to the same subdir as the source of whatever you are compiling.

libiconv is also preloadable and I have found this to help; in the upup I've made (for a limited audience) I'm preloading it in /etc/profile, thusly:

export LD_PRELOAD=/usr/local/lib/preloadable_libiconv.so

musher0 · #459 Post by **musher0** » Mon 14 Dec 2009, 20:07

To all:
if you use use DOSBox in full screen mode in
* pekwm : the fbpanel or lxpanel will be moved to an unwanted position upon end of dos session
* echinus : DOSBox freezes the session under echinus in full screen mode.

That said, DOXBox works fine in windowed mode in both these WM's.

BFN.

musher0 · #460 Post by **musher0** » Mon 14 Dec 2009, 20:11

gposil wrote:Just a quick reminder for all Dpup devs, the PetSpec format should be as below, for inclusion in Dpup repository.

To gposil:

Thanks for the info, and sorry for any inconvenience I may have caused. Since the name "Lenny Puppy" appears on the initial startup screen, I thought it made sense also as an identification. So, I have to redo the ID card for my pets, is that it?

BFN

Edit, 16h20, Gatineau time:
Just re-uploaded all my pets with the requested ID card information.

Coincidentally, compass_boussole-1.0-dpup (http://dpup.org/musher0/compass_boussole-1.0-dpup.pet) is now finished. You can use this utility in either French or English. These menus do not rely on any localization engine to work. Re-uploaded along with the others.

If you're a dev or configuration type and ever wished to have fast access to most parts of your system with a minimal number of mouse clicks, this must-have utility will speed up things greatly!

My opinion, of course! But try for yourself!

BFN

gposil · #461 Post by **gposil** » Mon 14 Dec 2009, 23:31

Just a quick word on libiconv discussion....

As of beta6, the point will be somewhat moot, as beta6 has GLIBC_2.10 and a the Debian Squeeze core which will also reflect in a new devx with the updated dev files for the changes....libiconv will disappear from the devx, as glibc now handles all charset support/conversion.

gposil · #462 Post by **gposil** » Mon 14 Dec 2009, 23:41

Iguleder said:

gposil: should I compile BusyBox, module-init-utils, util-linux-ng, udev, all those? I think Puppy needs a complete overhaul of all basic utilties, they're totally outdated (things like DVB are supported by the newer udevs, for example). I also think it's possible to ditch dhcpcd in favor of udhcpc to save some space, I use it in my distro and it works just fine. /etc/resolv.conf has the same syntax.

You don't have to worry about Busybox, Dpup already has the latest stable version...but the others are well worth looking at, provided we use the Debian bases.

Sit Heel Speak · #463 Post by **Sit Heel Speak** » Tue 15 Dec 2009, 02:44

gposil wrote:...as glibc now handles all charset support/conversion.

I wouldn't discard libiconv just yet. Perhaps a year from now. Even though glibc 2.10.1 now has the code in it to handle all charset support/conversion, I have within the past two weeks compiled Xorg 7.5 per BLFS, and Gnome 2.28 using jhbuild, on my heavily modified upup-450 (which carries gcc 4.4.1 and /lib/libc.so.6 version 2.10.1). And have seen that many of these two large packages' components and dependencies, even the newest available versions from git and svn, fail to build without correctly addressing libiconv in their configure line. I presume this is because they have not yet been updated to call the internal iconv functions in the latest glibc.

gposil · #464 Post by **gposil** » Tue 15 Dec 2009, 03:12

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

gposil · #465 Post by **gposil** » Tue 15 Dec 2009, 04:20

Is anyone aware of another IM client we can use instead of ayttm, it just doesn't cut the mustard(so to speak). In fact i've never been able to get it to work with msn...and it crashes regularly.

01micko · #466 Post by **01micko** » Tue 15 Dec 2009, 05:25

Iguleder wrote: Oh, last thing ... I'm quite enthusiastic about this one ... SliTaz and Tiny Core compatibility for Puppy, how does that sound? SliTaz's package manager is just bash scripts and one gtkdialog frontend, that can be easily ported. TC's extensions mechanism is even simpler, just SFSs with all files, plus a script (similar to pinstall.sh). The problem is FLWM/JWM menu incompatibility.

big_bass has already ported the slitaz package manager. See the Slaxer_Pup thread.

dejan555 · #467 Post by **dejan555** » Tue 15 Dec 2009, 07:03

Yeah I already mentioned that ayttm crashes msn and doesn't work with current yahoo. I'm not sure that there's another good im that's lightweight and supports all protocols, pidgin is the only good alternative but it's fat. Maybe ditch ayttm and put xchat in for irc, and for other im's put menu entry that opens meebo or some other web client like they did in 4.2. After connecting to irc guys from #puppylinux can instruct users to install pidgin or something else. We should definitely have pidgin 2.6.4 compiled at least in repo. I managed to compile it but without voice/video suport as it requires a lot of gstreamer libs.

gposil · #468 Post by **gposil** » Tue 15 Dec 2009, 07:15

dejan555,

Agree, lets ditch ayttm and i'll compile latest pidgin with gstreamer and put it in repo...might as well have something available that we know works well.

gposil · #469 Post by **gposil** » Tue 15 Dec 2009, 09:22

Dpup482beta is no more....

After the huge backend updates i've just finished, the next Dpup will be 484beta1.
Polishing and bug fixing on 482 will continue, for addition to 484.
There is no timescale on this release yet....

Initial changes are listed below:

01micko · #470 Post by **01micko** » Tue 15 Dec 2009, 11:00

gposil

Can you ditch puptV in favour of my new app, pupRadio? (it includes pupTelly and is smaller.. more bang for byte

__________________________________________________________

Now, I managed to compile the latest tint2 but not without some extreme head banging! It is now only a 36k pet, and a special thanks to the guys at the google code tint2 site.

Musher0, you can start tint2 from your pekwm startup script.

Compiling tint2 was a nightmare. We certainly have a problem with our imlib2, it refused to compile against it, so I used patriot's version, sorry I don't have the link at hand.

The other problem is a Debian issue, but really a libtool problem. I finally got through ./configure with no errors only to have make flake on me

. The first problem was "can't find /usr/X11R7/libXext.la". Oh dear, so I stole the one out of 431.. naughty yes.. then it was lixcbxlib.la... hmmm, funny, libxcb and libxcb-xlib are there... so on some googling i found some heated discussion about lib*.la files and Debian not supporting them and how it's really a libtool issue. FFS! I wanna compile an app, not rebuild the OS! Anyway, I found libxcb-xlib on ttuuxxx repo at puppylinux.ca (thanks ttuuxxx, Eric) but on installing that I got a meltdown of X. Oh dear yet again. Lucky I know that I can restore originals from pup_ro2.. did that got X back. I left the libxcb-xlib.la file there though (/usr/lib). Ok , Next was libxcb! Oh dear again? It was a bit like dependency chasing manually in Puppy, a real PITA! Ok, one more the actual libXext.so lib, found that in 431. Yay 'make' ran! Woohoo.

Updated pet is on Page 1 of this thread ( .txt file is at dpup.org in my repo.)

Cheers

(old)Puppy Linux Discussion Forum

(old)Puppy Linux Discussion Forum

Dpup482-beta5 testing