April extensions


Forum: The Testing Area
Topic: April extensions
started by: roberts

Posted by roberts on April 05 2008,18:24
Now posted with thanks to Juanito:
sane.uci
cups-1.3.5.uci
hplip-2.8.2.uci
hplip-2.8.2_site-packages.tar.gz


Read the info files for more information.
If using the new mydslBrowser then select update database.
You should see 897 packages in the database.

Posted by WDef on April 05 2008,21:17
Ping Juanito: I see you got sick of waiting for my sane.uci, though it looks like we built much the same extension - fair enough. Can't seem to get any extensions from my email to Robert at the moment anyway.

On another matter:  has anyone had any luck with guipdftk.dsl?  When I tried it, didn't seem to work.

Posted by Juanito on April 06 2008,03:31
Quote
Ping Juanito: I see you got sick of waiting for my sane.uci

- no, is wasn't that  :)

hplip depends on several of the sane libs and a couple of the binaries, I would have had to either include these in hplip or take a guess at the name of your extension for the symlinks.

BTW, I could only test the sane extension with the scanner part of a couple of hp all-in-ones, I'd be grateful if somebody could test sane with a stand-alone scanner and let me know how they get on.

Posted by Jason W on April 06 2008,04:26
Juanito,
Your sane.uci detects my umax scanner fine using sane-find-scanner, but that is as far as I can go, being spoiled by xsane no doubt.  I am not too familiar with scanning at the command line, and my xsane.dsl does not work with this extension.  Since it finds my scanner, I am sure it is just a pebkac/configuration issue on my part.  Are either you or WDef working on an xsane.uci?  If not I would be happy to build one that would work with a sane.uci package.

Posted by stupid_idiot on April 06 2008,05:05
Re: Version of X11 in DSL chroot

Built xfree86 4.3.0 using this custom host.def file:
Code Sample
#define HasExpat YES
#define HasFontconfig YES
#define HasFreetype2 YES
#define HasZlib YES

#define BuildDPSLibraries NO
#define BuildFontCache NO
#define BuildGLULibrary NO
#define BuildGLXLibrary NO
#define BuildGLwLibrary NO
#define BuildRandR NO
#define BuildRandRLibrary NO
#define BuildXF86RushExt NO
#define BuildXKB NO
#define BuildXTrap NO
#define BuildXaw6 NO
#define BuildXcursorLibrary NO
#define BuildXdmcpLib NO
#define BuildXvExt NO
#define NormalLibXrender NO
#define NormalLibXres NO
#define NormalLibXxf86dga NO
#define NormalLibXxf86misc NO
#define NormalLibXxf86vm NO
#define SharedLibXau YES
#define XserverStaticFontLib NO

#define XF86Server NO
#define XnestServer NO
#define XVirtualFramebufferServer NO
#define XprtServer NO

#define BuildFontServer NO

#define BuildFonts NO

#define DefaultGcc2i386Opt -Os

#define TermcapLibrary -lncurses

#define FontencCompatibility YES

#define BuildScreenSaverExt NO

#define BuildXinerama NO

#define BuildGlxExt NO

#define BuildLinuxDocText NO
#define BuildLinuxDocHtml NO
#define BuildLinuxDocPS NO


Resulting contents of /usr/X11R6/lib:
Code Sample
X11                                
libFS.a
libICE.so.6.3
libSM.so.6.0
libX11.so.6.2
libXau.so.6.0
libXaw.so.7.0
libXext.so.6.4
libXfont.so.1.4
libXft.so.1.1
libXft.so.2.1
libXi.so.6.0
libXmu.so.6.2
libXmuu.so.1.0
libXpm.so.4.11
libXrender.so.1.2
libXRes.a
libXtst.so.6.1
libfntstubs.a
libfontenc.a
liboldX.a
libxkbfile.a
libxkbui.a
pkgconfig
Mismatches:
(1) libXau.so.6 (DSL has libXau.so.0)
(2) libXfont.so.1 (DSL has libXfont.so.0)

< xfree86 in Debian Woody > is version 4.1.0.
I think that's the correct version!
Will try building 4.1.0 now.

Posted by Juanito on April 06 2008,05:14
Quote
Your sane.uci detects my umax scanner fine using sane-find-scanner, but that is as far as I can go, being spoiled by xsane no doubt.  I am not too familiar with scanning at the command line, and my xsane.dsl does not work with this extension.

Thanks for trying it out - I'm not too sure what you mean by xsane - the sane.uci extension has scanimage (command line) and xscanimage (gui).

Quote
Since it finds my scanner, I am sure it is just a pebkac/configuration issue on my part.

I believe that if "sane-find-scanner"/"scanimage -L" find your scanner, it is just a question (how easy that is to say) of adding a suitable .conf file to /etc/sane.d/ and then scanimage and xscanimage should work.

Posted by Juanito on April 06 2008,05:20
Quote
xfree86 in Debian Woody is version 4.1.0.

- I was thinking the version in dsl was xfree86-4.2.1 (but I can't remember why - from the dsl package listing maybe?)

Posted by Jason W on April 06 2008,05:39
Juanito,
 Xsane basically makes scanning point and click.  There is no configuration required.  You just click MyDSL -> Xsane and then click "preview" and then "scan".  Just makes the process easier.

Posted by Juanito on April 06 2008,06:04
OK, got it - I'll try to compile xsane into/against the sane.uci/gimp-1.2.uci extensions in the next couple of days.
Posted by stupid_idiot on April 06 2008,09:36
Re: Version of X11 in DSL chroot
Even xfree86 3.3.6 has libXau.so.6.
libXau.so.0 should be from xorg 6.x.
I'm trying out xorg 6.9.0 now.

Posted by Juanito on April 06 2008,10:01
Quote
I'll try to compile xsane into/against the sane.uci/gimp-1.2.uci extensions in the next couple of days.

- Done, much easier than I would have thought.

..and you were right Jason, xsane discovered my all-in-one on its own and automatically set itself up to scan. All this and it works from gimp-1.2.uci too.

I propose to re-submit sane.uci with xsane-0.995 included, it only adds +/-0.5MB - does that sound OK?

Posted by Jason W on April 06 2008,10:30
Sounds ok.
Posted by WDef on April 06 2008,10:44
Quote

I propose to re-submit sane.uci with xsane-0.995 included, it only adds +/-0.5MB - does that sound OK?


Good idea.  There's no real point in factoring that out, I least I don't think so.

Posted by WDef on April 06 2008,10:49
Quote
On another matter:  has anyone had any luck with guipdftk.dsl?  When I tried it, didn't seem to work.


Bumping this so it doen'st get lost

Posted by Juanito on April 06 2008,10:50
modified sane.uci submitted - early preview available < here >

Let me know if it works for a stand-alone scanner.

Posted by Juanito on April 06 2008,11:00
Quote
On another matter:  has anyone had any luck with guipdftk.dsl?  When I tried it, didn't seem to work

- it didn't work for me either, started to fire up and then disappeared.

The whole pdf thing is one of my last remaining "can't seem to get this to work in linux" issues. Even if I make a simple pdf by scanning in an image in gimp-1.2 at 150dpi, saving it as ps and then running ps2pdf, xpdf crashes when it tries to open it.

I tried many times to compile gs with the "make so" option in order to try gsview but the make fails with an error that gets no hits at all in google.

I also looked at foxit reader - it compiles and loads but the fonts don't work (I just get small squares) so I cannot do anything with it.

I looked at adobe pdf for linux, but the thing is so huge I didn't even try to make it work...

Posted by WDef on April 06 2008,13:04
I have had good success exporting files as pdf from Open Office.  I embed images etc and then export as pdf.   I'm not sure but text seems to look better if the odt is made using MS corefonts.

EDIT2: Also, imagemagick's convert works well for me for simple image conversion to pdf:

Code Sample
/opt/imagemagick/bin/convert Dalek.jpg out.pdf


As I recall you can also feed it multiple png's and set the compression to make the output pdf.

These aren't suitable for your purpose?

Regardless we badly need a decent pdf viewer extension for the new pdf formats.  I get sent pdf files made recently on Mac or whatever and xpdf can't display some of the graphical content.  Some other new pdf's don't display at all as you know.

There is a .dsl of Adobe's linux client available somewhere, but it's very big and not that current as I recall.

EDIT:  I just tried downloading and unpacking the current rpm of Adobe Reader.  Attempting to run this acroread on dsl gives:

Code Sample
.error while loading shared libraries: libstdc++.so.6: cannot handle TLS data


I think I tried that once before come to think of it.

Posted by stupid_idiot on April 06 2008,15:03
Re: Version of X11 in DSL chroot
I can't find libXau.so.0 and libXfont.so.0 in any version of xfree86 or xorg. Googling both library names gives very few results. I have no idea how to get these 2 libraries.
Code Sample
DSL 4.0:
/usr/local/lib/libXau.so.0 -- 9K
/usr/local/lib/libXfont.so.0 -- 152K

I will be sticking with xfree86 4.3.0 for now.
(xfree86 4.3.0 was released in Feb 2003.)

Posted by WDef on April 06 2008,15:14
Would these libs be somehow associated with TinyX?
Posted by roberts on April 06 2008,15:41
Thanks to Juanito for a quick update to
sane.uci
now posted.

Posted by WDef on April 06 2008,19:16
Quote

I can't find libXau.so.0 and libXfont.so.0 in any version of xfree86 or xorg. Googling both library names gives very few results. I have no idea how to get these 2 libraries.


< http://www.linuxfromscratch.org/blfs/view/svn/x/libXau.html >

< http://cgit.freedesktop.org/xorg/lib/libXfont >

Etch sources here. so should be able to find similar link to Woody's in Debian archives:

< http://ftp.de.debian.org/debian.....tar.gz >

Ping Robert: don't no how relevant this is to DSL but while googling I noticed libXfont was reported as having a nasty buffer overflow vulberability:

< http://lwn.net/Alerts/265758/ >
< http://www.gentoo.org/security/en/glsa/glsa-200609-04.xml >

Posted by stupid_idiot on April 07 2008,01:10
WDef:
Thank you for your kind help, but I still cannot find either libXau.so.0 or libXfont.so.0.

This link
< http://www.linuxfromscratch.org/blfs/view/svn/x/libXau.html >
refers to libXau 1.0.3, which will produce libXau.so.1, not libXau.so.0.

This link
< http://cgit.freedesktop.org/xorg/lib/libXfont >
has a history of libXfont going back to xorg 6.7.0.
The revision of libXfont in xorg 6.7.0 is 1.5 (libXfont.so.1.5).
(To verify this, you can see xc/config/cf/X11.tmpl in xorg 6.7.0 and look for SharedLibFont and SharedFontRev.
There is no mention of LibFont and SharedFontRev in X11.tmpl in xorg 6.6.)

Earliest appearance of libXfont in xfree86 is in < xfree86 4.0.0 >, SharedFontRev is 1.3 (libXfont.so.1.3).

Regarding this link:
< http://ftp.de.debian.org/debian.....tar.gz >
Debian Potato (Debian 2.2):
< http://archive.debian.org/dists....-12.deb >
This contains libXfont.so.1.3.
I couldn't find libXfont in any older Debian release.

Tried
< http://www.google.com/search?q=libxfont.so.0 >
which gives 2 irrelevant results.

Conclusion:
Still can't find the origin of
/usr/local/lib/libXau.so.0 and
/usr/local/lib/libXfont.so.0 in DSL.

Posted by Jason W on April 07 2008,02:23
Juanito,
Your sane.uci works like a charm.  I had to just copy over stuff from /opt/sane/etc/sane.d_conf/ to /etc/sane.d/ for xsane to work.  So it is almost point and click.  

I am putting together a .uci of gsview 4.9  built with GPL Ghostscript 8.62 and will hopefully have it submitted tonight.  It works well with pdf files that cause xpdf to crash.  I would appreciate any testing when it is posted.

Posted by Juanito on April 07 2008,03:31
Quote
Your sane.uci works like a charm. I had to just copy over stuff from /opt/sane/etc/sane.d_conf/ to /etc/sane.d/ for xsane to work. So it is almost point and click.

- Good to hear, I thought about having a startup script copy files to /etc/sane.d but there are so many possibilties I dropped the idea.

Just for interests sake, what scanner do you have and what file(s) did you need in /etc.sane.d?

I'm working on adding a menu item/icon for xsane - I also need to check if xsane depends on gimp when compiled for the gimp plug-in, I have a feeling it does...

I'll look forward to trying out gsview.

Posted by Jason W on April 07 2008,03:52
Xsane does depend on gimp-1.2.  I have a UMAX Astra 1220U scanner.  I copied the umax stuff, but truth be told, if all the files in /opt/sane/etc/sane.d_conf/ were copied over then Xsane would be just point and click for everyone I believe.  Or maybe if Sane was built with the configure option --sysconfdir=/opt/sane/etc/sane.d or something like it. (EDIT: that would be read-only and not much use).  A wrapper could be made that checks to see if the files are in /etc/sane.d and copies them if they are not that would make it more user friendly.  But hey, you have it all documented anyway, so it is not a big deal.

I packaged up gsview in a bare bones reader-only extension that is still a 7 MB .uci.  No create, convert, print, and all that.  That to me would warrant a seperate extension.  This is a reader only.  Hopefully it will be useful.

Posted by Juanito on April 07 2008,04:46
Quote
xsane does depend on gimp-1.2

Ah - I was afraid of that. I'll have a look to see if it's only a matter of a couple of libs - if that is the case then maybe it would make sense to include them with the sane extension to avoid the need for gimp and yet maintain the plug-in compatibility when gimp is present.

Quote
I am putting together a .uci of gsview 4.9  built with GPL Ghostscript 8.62 - I packaged up gsview in a bare bones reader-only extension that is still a 7 MB .uci

- I'd been trying with gsview-4.8 and gs-7.05 to use the gtk1/gs files already in dsl to keep the size down...

Posted by Jason W on April 07 2008,05:03
I had seen the gs files in DSL after I compiled 8.62.  But there is no /usr/*/lib/libgs.so* in DSL that I can see, and that would have to be there.  Correct me if I am wrong, though.  All my gsview extension consists of is /opt/gsview-4.9/bin/gsview and /opt/gsview-4.9/lib/libgs.so.8.62, with a couple of symlinks.  That is all it needs to read pdf files, but those two files take the .uci to 7MB.  I hope the space taken up by the newer versions is made up for by support of more modern pdf files.
Posted by Juanito on April 07 2008,05:14
Quote
But there is no /usr/*/lib/libgs.so* in DSL that I can see, and that would have to be there.  Correct me if I am wrong, though

- It is my understanding that the shared lib is required - I was working on a suggestion made by Curaga to try gsview - and that gs-7.05 would have to recompiled using "make so" (which fails when I try, but this could be due to the occasional weirdness that compile-3.3.5 throws up).

Quote
All my gsview extension consists of is /opt/gsview-4.9/bin/gsview and /opt/gsview-4.9/lib/libgs.so.8.62, with a couple of symlinks.  That is all it needs to read pdf files, but those two files take the .uci to 7MB.  I hope the space taken up by the newer versions is made up for by support of more modern pdf files.

- if your extension reads more pdf files, it'll be worth it. Did you strip the gsview binary and libgs.so?

Posted by Jason W on April 07 2008,05:25
I did not strip the library or binary.  Here is a .tar.gz version of the extension if you would like to take a look at it.  

< http://74.237.17.82/dsl/gsview-4.9.tar.gz >

Maybe it can be whittled down a little more.

Posted by Juanito on April 07 2008,07:59
I had a look at your gsview extension - it works a lot better for me than xpdf. I tried 8-10 pdf files, including some large technical manuals, all of which worked fine whereas xpdf would not open most of them.

The 12MB monster lib would not strip further, but the binary about halved in size reducing the extension by +/-200KB.

You might want to look at gsview's own icon (gsview48.png in gsview-4.8) for your finished extension :)

On the xsane front, adding libgimpui-1.2.so.0 & libgimp-1.2.so.0 stopped the dependency on gimp-1.2 for a +/-300KB increase in the size of sane.uci - I just noticed that xsane stand-alone will save in pdf (gimp-1.2 will not) which is a big plus.

Updated version of sane.uci (gimp libs & menu item/icons) < here >

Posted by WDef on April 07 2008,09:54
Quote
Conclusion:
Still can't find the origin of
/usr/local/lib/libXau.so.0 and
/usr/local/lib/libXfont.so.0 in DSL.


Don'tJohn and Robert offer to send a cd containing all dsl sources for a few dollars (or something) as part of satisfying the GPL?

In which case, the sources to these libs must be on there.

Posted by WDef on April 07 2008,09:56
Ping: Jason

If your extension works on the newer format pdfs (and it sounds like it does)  - then thanks very much!

Posted by Jason W on April 07 2008,10:37
I will strip the gsview binary when I get home tonight (got to go to work now) and resubmit it.



EDIT: 4.8.08   Been sidetracked, but will do the above including adding an icon for DSL 3.x .

Posted by Juanito on April 07 2008,11:00
Quote
I will strip the gsview binary when I get home tonight (got to go to work now) and resubmit it.

- Great. It'd help my old desktop installation if there was an icon/lnk for dsl-3.x too  :)

Posted by curaga on April 07 2008,13:53
Glad gsview was worth the job :)
Posted by Onyarian on April 07 2008,16:05
Quote (WDef @ April 05 2008,16:17)
On another matter:  has anyone had any luck with guipdftk.dsl?  When I tried it, didn't seem to work.

WDef,

For me works OK in a clean start of DSL from a CD, and in my normal DSL configuration also.

It creates a menu entry in Mydsl menu and runs well.

Can you tell me how you start DSL? or where is the problem to reproduce it?

Posted by roberts on April 07 2008,17:58
Thanks to Jason for gsview-4.9.uci. Now posted.
Posted by WDef on April 07 2008,20:27
Thanks for picking up on this Onkaryian. I don't want to try it right now since I'm in the middle of something.

I always use a toram dma boot from livecd, usually with java JRE uci and gtk2 installed (perhaps a conflict there?).

Not sure what Juanito uses; the overlap between our two setups might point to the problem.

Posted by WDef on April 07 2008,21:08
SInce the gods of cyberspace have decided for some unknown reason that it should be impossible for me to email an extension to Robert, the following link leads to a bz2 tarball containing testdisk.uci, checksum and info file:

< http://www.megaupload.com/?d=4P6513ME >

I repeat the md5sum here also:

Code Sample
08c2e4d575b822fda69e947c4de2ffe2  testdisk.uci


Please Robert could you post this?

testdisk also comes with a file recovery utility called photorec (included in the uci) for recovering many different typs of deleted files on a wide variety of filesystems.
.

Posted by roberts on April 08 2008,00:31
Thanks to WDef testdisk.uci is now posted. Number 900 in the database.
Posted by roberts on April 08 2008,04:05
Quote (WDef @ April 07 2008,02:54)
Quote
Conclusion:
Still can't find the origin of
/usr/local/lib/libXau.so.0 and
/usr/local/lib/libXfont.so.0 in DSL.


Don'tJohn and Robert offer to send a cd containing all dsl sources for a few dollars (or something) as part of satisfying the GPL?

In which case, the sources to these libs must be on there.

Just checked DSL v0.4.10 published on October 16, 2003. Which predates me!

And there is
/usr/local/lib/libXau.so.0 and
/usr/local/lib/libXfont.so.0

This would suggest to me that its likely source would be when John compiled Keith Packard's Kdrive code for tinyX.

FYI: John is the maintainer of all things source. That is one of the main reasons why I write script. I am always losing things and that means source. Over the years I have only slightly modified jwm, xtdesk, and dfm. That source I made sure to give to John.

Posted by stupid_idiot on April 08 2008,14:30
Thanks Roberts!

Re: Version of X11 in DSL chroot
I'm using xorg 7.3, because:
- xorg 7.x is modular, so the size of the sources altogether is very small.
- xorg 7.x is modular, it is very easy to build individual pieces. xfree86 works just as well, but building it is much "messier".

Re: DSL chroot
I finished the textfile version of the howto.
Now I have to format the howto in wiki markup.
These are the expected files:
debootstrap.tar.gz -- ???K
dsl_chroot.tar.gz -- ??M
dsl_chroot_docs.tar.gz -- ??K
lfs_sources.tar.gz -- ???K
("lfs_sources.tar.gz" contains wget urls to source tarballs.
Source tarballs are not included.)

A 100MB partition is needed to < debootstrap > Debian Woody.
Another 2.5G partition is needed to build everything.
(~400M safety margin.)

Estimated build times:
P-M/Athlon 64: Fast
P4/Athlon XP: OK
Pentium 3: Slow
Pentium 2: Horrifyingly slow

Posted by Onyarian on April 08 2008,17:37
Quote (WDef @ April 07 2008,16:27)
I always use a toram dma boot from livecd, usually with java JRE uci and gtk2 installed (perhaps a conflict there?).

I am writing this post with your configuration:
DSL 4.2.5 from liveCD
boot options: dma toram
load extensions: jre1_5_0.uci and gtk2-0705.unc
then I load guipdftk.dsl

works OK!!

perhaps you have to try another time.

Tell me something!

Posted by stupid_idiot on April 09 2008,03:42
Re: DSL chroot
I am trying to shorten the build process so that the user only needs to build gcc and glibc once, instead of twice.

That means that gcc will be compiled against glibc-2.2 on Woody, not LFS's glibc-2.3.2.
As long as no compatibility problems arise, this will save alot of time on slower systems.

p.s.
I will be very busy for the next few weeks, so I won't be able to come on here at all.

Posted by ^thehatsrule^ on April 11 2008,23:10
On testing/compile-3.3.5.uci (Juanito), downloaded April 2nd:

.../lib/libreadline.so.4.3 can be invalid because it points to /ramdisk/...
Should be just from /

.../lib/gconv points to an invalid reference to /KNOPPIX/usr/lib/gconv

I ran into some problems using bison, but it was noted in the .info that some old version was used for xf421.
I did not think the xf version used was 421, and looked at the notes/forums - which seems to indicated that 0.4.10 was the version that the tinyx servers were updated from cvs.
DSL v0.4.10 was released in October 2003, whereas xf430 was released in February 2003.  So my guess is that it is probably some version based on 430.
My guess is that you saw the version from the packages page..?
Links: < http://www.xfree86.org/xnews/#release43 > and < http://damnsmalllinux.org/cgi-bin....4;t=756 > and notes/archives


Did you consider adding glib-2.0 support in it?  Libs seem to be in the base.

Posted by Juanito on April 12 2008,05:25
Thanks for the feedback - I thought I'd caught all the symlinks with /ramdisk in them, I'll have a look at this again (and the gconv link - edit: the gconv link looks OK to me, what problem did you see?).

It might be better to update bison to the latest version rather than using something circa 2003 - since this is not in the base dsl and only used for compiling, I guess it should be OK - what does anybody think?

I believe I took the version of xf from the packages page - it would be nice if we could confirm exactly which version is in dsl...

Let me look at glib-2.0

Posted by curaga on April 12 2008,07:02
Yeah, Bison, Yacc, Pkg-config and Flex are only used at the compile step, so they can be as new as wanted.
Posted by Juanito on April 12 2008,13:40
I seem to remember reading somewhere that the latest version of bison stands in for yacc as well, so I might yet save a few KB :)
Posted by ^thehatsrule^ on April 12 2008,18:27
Quote
I believe I took the version of xf from the packages page - it would be nice if we could confirm exactly which version is in dsl...
I would guess it would be some experimental version from the 430 branch.  I couldn't find versioning on the binaries, so I guess the only option would be to ask John.

Quote
I seem to remember reading somewhere that the latest version of bison stands in for yacc as well, so I might yet save a few KB
It's already there - yacc is a wrapper script to bison.  iirc lex -> flex so you might want to look into that as well.

Posted by WDef on April 13 2008,00:01
I have a vague memory that  I compiled something once that needed lex by symlinking lex -> flex
Posted by Juanito on April 13 2008,09:54
Quote
Did you consider adding glib-2.0 support in it?  Libs seem to be in the base.

- by a bit of trial and error, it seems that glib-2.6.4 is the one used in dsl (or at least it produces a lib with the same name):
Code Sample
$ ls /opt/glibtest2/lib
libglib-2.0.so.0.600.4 [in dsl base]
libgmodule-2.0.so.0.600.4 [not in dsl base]
libgobject-2.0.so.0.600.4 [not in dsl base]
libgthread-2.0.so.0.600.4 [not in dsl base]

- given that three of the glib2 related libs are not in the dsl base, I'm concerned that including the headers for this in compile-3.3.5 might cause more problems that it solves?

Posted by curaga on April 13 2008,11:22
LFS makes a wrapper as "lex" that calls flex -l (lex compatibility mode); seems better than just symlinking to me
Posted by Juanito on April 13 2008,12:00
Already found that via google :)
Posted by ^thehatsrule^ on April 13 2008,18:38
Quote
- given that three of the glib2 related libs are not in the dsl base, I'm concerned that including the headers for this in compile-3.3.5 might cause more problems that it solves?
From a preliminary ldd scan, it seems sshfs in the base is the only one needing that lib.  Maybe you can just include the dev stuff for that lib?  But otherwise, I'd agree with you.  (could note it in the .info either way)

And yes, it is glib-2.6.4.  I should've thought to say that as well and save you a bit of time.

Posted by WDef on April 13 2008,21:55
Quote
Yeah, Bison, Yacc, Pkg-config and Flex are only used at the compile step, so they can be as new as wanted.


Same goes for autoconf and automake I think.

Good the way you've put several automake versions in there - some things want older versions, other things won't build without a recent automake.

Quote
seems better than just symlinking to me


I'm sure.  I can't remember what I did.

Posted by roberts on April 14 2008,16:32
Thanks to Jason for:
rox-filer-2.7.1.uci
gsview-4.9.uci


Thanks to Onyarian for:
guipdftk.unc

Thanks to Juanito for an update to:
sane.uci

902 extensions in the database

Posted by Juanito on April 16 2008,05:33
I just finished the latest updates to compile-3.3.5

Quote
Yeah, Bison, Yacc, Pkg-config and Flex are only used at the compile step, so they can be as new as wanted.

- autoconf, bison, expat, flex, m4, make, pkg-config & texinfo updated to the latest versions

Quote
...several automake versions in there - some things want older versions, other things won't build without a recent automake

- automake/aclocal 1.7 & 1.10 added

Quote
...wrapper as "lex" that calls flex -l (lex compatibility mode); seems better than just symlinking to me

- lex wrapper added

I also removed KNOPPIX from the symlinks. I think I need to do some more testing before adding glib2 headers/libs - since the full suite of glib2 libs are not in the dsl base, adding this may cause missing lib errors

I'll do some "stress testing" (^hats^ cp -a /opt/compile-3.3.5/include /opt & export CPPFLAGS=-I/opt/include seems to work well) and then submit the revised extension.

Posted by ^thehatsrule^ on April 16 2008,07:46
Juanito: did you ever post a guide or your steps that you did in making compile-3.3.5?  There might be something someone could pick out that could be causing the problem.
Posted by Juanito on April 16 2008,10:50
I guess the issue in question is how I made ../include in the compile-3.3.5 extension. Apart from the headers coming from the various apps, I did:
Code Sample
$ make mrproper
$ make include/linux/version.h
$ make symlinks
$ make menuconfig
$ sudo mkdir /opt/compile-3.3.5/include/asm
$ sudo cp -v include/asm/* /opt/compile-3.3.5/include/asm
$ sudo cp -vR include/asm-generic /opt/compile-3.3.5/include
$ sudo cp -vR include/linux /opt/compile-3.3.5/include

Posted by roberts on April 20 2008,03:24
Thanks to Juanito for:
compile-3.3.5.uci
cups-1.3.5.uci

Posted by ^thehatsrule^ on April 20 2008,03:43
Quote (Juanito @ April 16 2008,10:50)
I guess the issue in question is how I made ../include in the compile-3.3.5 extension. Apart from the headers coming from the various apps, I did:

I think the issue lies with the compiler setup, preprocessor, etc. since the .../include dir works fine in other locations.

Is there a reason for the libpng related files in /tmp? (in user.tar.gz)

Also, the updated .info is messed up again (from a conversion to plain ascii?)

Posted by Juanito on April 20 2008,03:59
Quote
Is there a reason for the libpng related files in /tmp? (in user.tar.gz)

- from the info file:
Quote
Since dsl has three versions of libpng a choice needs to be made as to which versions of headers/pkgconfig to use. Links have been placed in /tmp that point to the most recent version of libpng - modify these links if you wish to compile based on an older version of png.


Quote
Also, the updated .info is messed up again (from a conversion to plain ascii?)

- sorry, I checked it in dsl before I submitted and it looked OK...

Posted by roberts on April 20 2008,04:39
Thanks to Juanito for updated and much smaller:
gimp-2.4.uci
gtk+-2.10.uci

Posted by WDef on April 20 2008,06:23
Ping: Juanito:


1. md5sum fails for me with cairo-1.2.uci

2. gtk+-2.10.uci - Since it depends on the cairo uci, perhaps when you rebuild gtk2 you could include cairo if you still have the cairo sources?  One extension load is better than two for me.  This may not suit you though.

Thanks.

Posted by Juanito on April 20 2008,10:28
Quote
1. md5sum fails for me with cairo-1.2.uci

- I downloaded cairo-1.2 and the md5 file from mydsl/testing and got this:
Code Sample
$ cd /mnt/sda1/tmp
$ md5sum -cv cairo-1.2.uci.md5
cairo-1.2.uci  OK
- ??

Quote
One extension load is better than two for me.  This may not suit you though.

- I tend to agree, but I had a couple of reasons:

1. I needed to stop at some kind of "way point" in compiling  the whole chain of dependencies leading up to gimp-2.4 since the 1GB ram on my laptop is not enough to do it in one go...
2. I had a couple of projects (conky-2 ?) that needed cairo but not gtk+

It sounds like Jason is working on updated versions of cairo/gtk+ in one extension, but in the meantime at least both extensions have the headers and pc files  :)

..speaking of which, with newer apps it seems setting PKG_CONFIG_PATH works at least as well, if not better, than pointing to the libs/headers manually. There are still some exceptions though - gimp-2.4 picked up all of the dependencies using pkgconfig except lcms, even though lcms.pc was there...

Posted by Jason W on April 20 2008,11:40
Juanito,
I loaded, cairo-1.2.uci, gtk+-2.10.uci, and gimp-2.4.uci and when trying to run gimp it complains of missing libXrandr.so.0.  That is when running it without xorg-7.2.uci installed.

I will see if I can get Firefox to work with your gtk+-2.10.uci.  It just needs a few more libs.  I am up against a wall with gtk+-2.12.9 with the glib/freetype and antialiasing issues.  I cannot make a proper .uci out of it.  It would be nice to have a gtk2 uci that would run Firefox and such, though.

EDIT 4.22.08:  gtk+-2.12.9.uci has been made and submitted.  Gtk2 fonts are antialiased out of the box and editing /etc/ld.so.conf solves the library path issues.

Posted by Juanito on April 20 2008,11:49
Quote
...complains of missing libXrandr.so.0.

- hmm, I ran gimp-2.4 on my laptop without xorg72, but I need xfree86 due to the i855 graphics so I guess it must have picked the lib up from there. Thanks, I will try it on my old desktop without xorg72/xfree86 to double-check. Interesting that gimp-2.4.0 didn't appear to need this lib but gimp-2.4.5 does, or maybe it is some of the additional libs (lcms, rsvg, etc)...

Edit: The culprit is gnu-utils - sigh...

I also got stuck with the glib2/freetype thing - and no amount of "-rpath" seems to fix it. What does work though is starting an app with, for example:
Code Sample
$ LD_LIBRARY_PATH=/opt/gimp-2.4/lib /opt/gimp-2.4/bin/gimp-2.4
- with symlinks to the glib2/freetype libs you want to use in /opt/gimp-2.4/lib. This seems to make the app ignore the base dsl libs.

Posted by WDef on April 20 2008,22:06
Re: md5sum for cairo:

Code Sample
cat cairo-1.2.uci.md5.txt
1bf9dd92df7c6eea12e5c72a85c900db  cairo-1.2.uci


Code Sample
md5sum cairo-1.2.uci
8dbb6f1200bad6e0d4fd6c329fe35eda  cairo-1.2.uci


I'm downloading via the web from < http://distro.ibiblio.org/pub....testing >

and have deleted the files and repeated this several times.

What md5sum do you have?

Posted by ^thehatsrule^ on April 20 2008,22:58
wdef: if it checks out for him, he gets the same hash as in the md5 file.  It's probably something wrong on your end... (network, filesystem, etc.) ?
Posted by Juanito on April 21 2008,04:14
From windows (since I'm not at a dsl machine) I get this:
Code Sample
G:\tmp>md5sums cairo-1.2.uci

MD5sums 1.2 freeware for Win9x/ME/NT/2000/XP+
Copyright (C) 2001-2005 Jem Berkes - http://www.pc-tools.net/
Type md5sums -h for help

[Path] / filename                              MD5 sum
-------------------------------------------------------------------------------
[G:\tmp\]
cairo-1.2.uci                                  1bf9dd92df7c6eea12e5c72a85c900db

G:\tmp>type cairo-1.2.uci.md5
1bf9dd92df7c6eea12e5c72a85c900db  cairo-1.2.uci


...downloading from < http://distro.ibiblio.org/pub....testing >

It seems to be OK...

Posted by meo on April 21 2008,10:34
Hello guys!

I'm sorry if I'm kind of intruding but the whole lot works just fine for me. I'm still running DSL v. 3.3 (off of a 8 GB CF-card) since it has proven the most robust version after an extensive remastering. My KNOPPIX-file is 130+ MB big since I've included what's needed for compiling source-code and also the GNU debugger (which I had to compile into the remaster from source-code) but as I mentioned Gimp-2.4, cairo etc. works just fine for me.

Have fun with this awsome distro,
meo

Posted by meo on April 21 2008,13:14
Hello again guys!

I'm sorry but my previous post was based on a misunderstanding. I thought You were discussing the previous versions of these extensions. They work all right for me but I can't make the last versions of gimp etc. work either. So I'm very sorry for my mistake.

As always have fun with this wonderful distro.
meo

Posted by Juanito on April 21 2008,13:43
Quote
They work all right for me but I can't make the last versions of gimp etc. work either.

- do you mean cairo-1.2 + gtk+-2.10 + gimp-2.4 ? If so, it would be useful if you could post the error you get. From Jason's post it looks like a lib (libXrandr.so.0) is missing that I should have included but was fooled by the fact that the lib is also found in gnu-utils - but maybe you got a different error?

Posted by jls legalize on April 21 2008,22:24
I did't manage to make working my parallel scanner mustek 600 CP, infact in dll.conf the mustek pp line begins with a # and also the mustek_pp file is missing. In ubuntu after uncommenting the above mentioned line the scanner works.

legalize cannabis, coke...

Posted by WDef on April 22 2008,00:35
Ping Juanito:

cairo uci downloaded fine tonight to /home/dsl - md5sum OK.

Never struck that before.  As Hats says, must be either or both the flaky network or the flaky vfat partition onto which I was downloading.

Thanks for checking it out though.

Posted by Juanito on April 22 2008,03:36
Quote
I did't manage to make working my parallel scanner mustek 600 CP, infact in dll.conf the mustek pp line begins with a # and also the mustek_pp file is missing. In ubuntu after uncommenting the above mentioned line the scanner works.

- I did not delete any conf files from sane-frontends/backends in the sane extension, so I'm not sure why the mustek file would be missing. Does your scanner work with the sane extension after you copy the mustek_pp file across from ubuntu and uncomment the line in dll.conf? Is the parallel module loaded in dsl? Did you try "scanimage -L" and xsane?

Posted by Juanito on April 22 2008,08:30
Quote
...and when trying to run gimp it complains of missing libXrandr.so.0.

- after checking cairo-1.2 + gtk+-2.10 + gimp-2.4 without gnu-utils loaded, libXrandr.so.2 & libXcursor.so.1 are missing.

I'll do some more checking and then re-submit cairo-1.2.uci & gimp-2.4.uci

Posted by roberts on April 23 2008,05:02
Thanks to Jason for:
gtk+-2.12.9.uci
leafpad-0.8.14.uci


Now posted.

Posted by Juanito on April 24 2008,15:06
@Jason

I tried out rox-filer-2.7.1.uci with gtk+-2.10.uci just to see what would happen. I got the dreaded glib2 error so I added a symlink to glib2 in gtk+-2.10 and the problem went away and rox worked fine.

I'm not at all suggesting that you do the above (especially since you recommend to use a different version of gtk2) but that's a couple of times now (gimp-2.4 being the other) that this approach gets around the glib2 issue, so I thought it worth pointing out.

Posted by Jason W on April 24 2008,17:30
Juanito,
Thanks for the tip.  I would like for the gtk+-2.12 extension to not need any manual trickery to work after loading, so I will give the symlink a try.

My goal with future extensions is for them to work with any of the gtk2 extensions whenever possible and not be locked into any particular one.  That is why I am not building any against gtk+-2.12.  I built Leafpad to work with gtk2-0705.dsl as well as the others (I used gtk+-2.6 to build it with).  Since Rox works with your gtk+-2.10, and I will put that in the info file when I update it.  Same with Leafpad.  I will test extensions against gtk+-2.10.uci and include it in the info file in the future.  It would be nice to know when you only need a 3MB gtk2 extension instead of a 15MB one.

Posted by WDef on April 26 2008,17:04
Ping: Robert

Recent rsync release extension (fixes buffer overflow) < http://www.megaupload.com/?d=M6V8K2GQ >

066fff3e233e26347125de87fcf30dbb  rsync-302.dsl

Please post - thanks.  If you have any trouble downloading from megaupload let's know and I'll try the vagueries of yahoo again (maybe gmail).

Posted by WDef on April 26 2008,19:39
On a roll:

combina.uci:

< http://www.megaupload.com/?d=PTAUNQKI >

Please post also.  Thanks.

a6e82c34caad68270474c15ecc9af047  combina.uci

Posted by WDef on April 30 2008,16:46
Ping Jason:

If needed you could add a wrapper to your gtk2.12.9 uci and start it from the right-click menu (sudo of course) as "Setup_gtk2" or something:

Code Sample

#!/bin/bash

# Add path to gtk libs to ld.so.conf

if grep -q '/opt/gtk+-2.12.9/lib' /etc/ld.so.conf; then
      # already done
       exit 1;  
fi

if [ -L /etc/ld.so.conf ]; then
       rm -f /etc/ld.so.conf
        cp /KNOPPIX/etc/ld.so.conf /etc/ld.so.conf
else
       cp -f /etc/ld.so.conf /etc/ld.so.conf.bak
fi

sed -i '1 i\
/opt/gtk+-2.12.9/lib' /etc/ld.so.conf

ldconfig

exit 0


But like Juanito I thought something like this already happened for ucis in recent dsl.  (I'm on an old dsl right now).

EDIT2: I thought /opt/lib was now in /etc/ld.so.conf with ldconfig getting run automatically by the extension install scripts?  If so, perhaps all you do is symlink all the libs into /opt/lib and pack the symlinks away in user.tar.gz

EDIT2: 1 May2008

Posted by WDef on April 30 2008,17:14
Jason: gtk2.12.9 uci  is working really great for me so far.

Thanks to both you and Juanito for these ram-saving efforts.  gtk2 .dsl was a huge ramdisk hog!

Posted by Jason W on April 30 2008,17:20
Wdef,
Thanks for the script, and I think it would be nice for the setup to be automated to save time.  I like things to be the least hassle necessary.  /etc/ld.so.conf does get updated with the /opt/gtk+-2.12.9/lib directory in the most recent DSLs but it is the bottom line in the file.  I will add this and resubmit.  I will also submit the gtk+-2.12.9-dev.tar.gz.   To be used, would require making a .tar.gz out of the gtk+-2.12.9.uci and untarring the -dev extension over it.  I wanted to separate the -dev stuff for size reasons.  I sent it in with the gtk+-2.12.9.uci but put it on hold since it would not load and work in the usual way.  But a -dev extension does not have to be click and run of course.

Posted by WDef on April 30 2008,18:05
Quote
/etc/ld.so.conf does get updated with the /opt/gtk+-2.12.9/lib directory in the most recent DSLs


Perhaps we need to ping Robert and see if he would consider changing this so the additions are made at the top of ld.so.conf.  That sed line above for example will do it.

Similarly: /opt/bin might be best at the beginning of PATH for the same reason, if it isn't already - so that extension  binaries get found before those on the system.

In case you need to add the little script above:  I'll edit it  now to exit if the line has already been added.

Posted by Jason W on April 30 2008,18:49
Quote

Perhaps we need to ping Robert and see if he would consider changing this so the additions are made at the top of ld.so.conf.  That sed line above for example will do it.


The only issue I see is that adding to the beginning of /etc/ld.so.conf can break things in base.  But that will happen whether they are added manually or automatically.  So I don't know if it would be good to do that universally for all extensions.  But a good idea nonetheless.It looks like DSL 5.x will be small enough not to have many conflicts when loading extensions, since the less in base the less there is to conflict with.  There is one app in base that depends on the base glib2, and I cannot remember the name or if it gets broken.  Usually newer libraries do not break old apps, but a possibility.

As for /opt/bin being at the beginning of $PATH I fully agree since when you load a .uci or .tar.gz you of course are wanting to use the commands in /opt/bin instead of /usr/* if there are duplicates.  With gtk+-2.12.9 installed, issuing the command 'fc-cache' will not work.  /opt/gtk+-2.12.9/bin/fc-cache has to be used.  I do not have symlinks in /opt/bin (I will add them before I resubmit) but the result would be the same - base fc-cache would be called up.  Maybe having /opt/bin at the beginning of the $PATH could be done.

Posted by WDef on April 30 2008,19:09
Quote
/etc/ld.so.conf can break things in base.


If the uci is umounted, you mean an entry to /etc/ld.so.conf that no longer exists after ldconfig is run causes a problem?

Perhaps try testing this after umounting your uci.  Wouldn't it be fixed by just running ldconfig again after umounting?

EDIT: If not, easy enough to have another little script to REMOVE the line from ld.so.conf (or restore the backup).

Code Sample


#!/bin/bash

# Remove path to gtk libs from ld.so.conf

if ! grep -q '/opt/gtk+-2.12.9/lib' /etc/ld.so.conf; then
     # already done
      exit 1;  
fi

if [ -L /etc/ld.so.conf ]; then
   exit 1
fi

sed -i  '/\/opt\/gtk+-2.12.9\/lib/dg'  /etc/ld.so.conf

ldconfig

exit 0

Posted by Jason W on April 30 2008,20:04
Quote

Quote
/etc/ld.so.conf can break things in base.


If the uci is umounted, you mean an entry to /etc/ld.so.conf that no longer exists after ldconfig is run causes a problem?


Not that, but linking base apps to libs in an extension could possibly break the app.  But it is necessary of course to put the extension library path at the beginning of /etc/ld.so.conf with the gtk.uci extensions  and it seems to work pretty well.  

I am pretty sure that directory entries in /etc/ld.so.conf that do not exist or have no libs in them are harmless, though.

Posted by WDef on April 30 2008,23:06
Re empty dirs in ld.so.conf: without  checking, that's what I assumed it would be.

Running ldd on everything in the executables directories and greping for your extension libs, if I haven't forgotten any bin dirs that is:

Code Sample
#!/bin/bash

DIR="/KNOPPIX/bin /KNOPPIX/usr/bin /KNOPPIX/usr/X11R6/bin /KNOPPIX/sbin /KNOPPIX/usr/sbin /KNOPPIX/usr/local/bin /KNOPPIX/usr/local/sbin"

CD=$PWD
for F in ${DIR}; do
cd ${F}
for G in *; do
H="$F/$G"
[ -d "$H" ] && continue
if [ -x "$H" ]; then
ldd "$H" 2>/dev/null | grep '/opt/gtk+-2.12.9/lib' && echo "[ $H ]"
fi
done
done

cd $CD



On tonight's old running dsl that gives:

Quote

libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4005e000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4007c000)
[ /KNOPPIX/usr/bin/Ted ]
libfontconfig.so.1 => /opt/gtk+-2.12.9/lib/libfontconfig.so.1 (0x4001b000)
libfreetype.so.6 => /opt/gtk+-2.12.9/lib/libfreetype.so.6 (0x40045000)
libexpat.so.1 => /opt/gtk+-2.12.9/lib/libexpat.so.1 (0x400c2000)
libxml2.so.2 => /opt/gtk+-2.12.9/lib/libxml2.so.2 (0x40211000)
[ /KNOPPIX/usr/bin/fc-cache ]
libfontconfig.so.1 => /opt/gtk+-2.12.9/lib/libfontconfig.so.1 (0x4001b000)
libfreetype.so.6 => /opt/gtk+-2.12.9/lib/libfreetype.so.6 (0x40045000)
libexpat.so.1 => /opt/gtk+-2.12.9/lib/libexpat.so.1 (0x400c2000)
libxml2.so.2 => /opt/gtk+-2.12.9/lib/libxml2.so.2 (0x40211000)
[ /KNOPPIX/usr/bin/fc-list ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4005e000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4007c000)
[ /KNOPPIX/usr/bin/ted ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x402f1000)
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40310000)
[ /KNOPPIX/usr/bin/xtdesk ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40183000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x401a2000)
[ /KNOPPIX/usr/bin/xzgv ]
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40029000)
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4007c000)
[ /KNOPPIX/usr/X11R6/bin/xpaint ]
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x4006b000)
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4008e000)
[ /KNOPPIX/usr/local/bin/bm_srv12 ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x4001b000)
libpng12.so.0 => /opt/gtk+-2.12.9/lib/libpng12.so.0 (0x40039000)
[ /KNOPPIX/usr/local/bin/dillo ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40151000)
[ /KNOPPIX/usr/local/bin/gs ]
libjpeg.so.62 => /opt/gtk+-2.12.9/lib/libjpeg.so.62 (0x40042000)
libtiff.so.3 => /opt/gtk+-2.12.9/lib/libtiff.so.3 (0x40060000)
[ /KNOPPIX/usr/local/bin/xsri ]


So if you feel like it run this on your doubtless more up to date dsl and it will give you an idea what is at risk of breaking from your uci, if it does break that is.

afaik newer libs like this aren't supposed to break apps depending on earlier minor releases with the same major release number.

Re
Quote
The only issue I see is that adding to the beginning of /etc/ld.so.conf can break things in base.  But that will happen whether they are added manually or automatically.  So I don't know if it would be good to do that universally for all extensions.


I think it would be worth trying.  That's why we have a testing repo. Robert may or may not agree.    Presumably? reversible by uninstalling the extension anyway.

EDIT: Another thank you - some of the old gtk2 apps in the repo are looking fabulous with this uci - a new lease of life!

Posted by Jason W on April 30 2008,23:52
Thanks for your input and scripts.  I did not realize how many apps in base were linked to the gtk+-2.12.9 libs when the extension was loaded.  And nothing seems broken, except for /usr/bin/fc-cache that gives an error about scanning directories.  I will put a menu extension to automate the configuration.
Posted by WDef on May 01 2008,16:04
Jason: in that setup script, which I didn't actually test until now, cp complains about overwriting a symlink with its target even with the force option, so I've:

- edited it to remove the target  before copying.
- only need a backup of the file if it isn't a symlink - changed.

So suggest using the updated version.

Posted by Jason W on May 03 2008,00:58
Ok, here is pretty much what i plan to include in the menu - a setup and a remove setup entry.  The setup:

Code Sample

#!/bin/bash
#Script to setup gtk+-2.12.9
#Idea and script by WDef, tweaked for dialog.

dialog --title "Setup GTK+-2.12.9" --yesno "This setup will cause the system to link programs to the newer libraries in /opt/gtk+-2.12.9/lib in priority over those in the system or other extensions.  This is basically harmless and shouldn't break anything.  Do you want to proceed?" 20 50 3


if [ $? = 1 ]; then
dialog --title "Setup GTK+-2.12.9" --msgbox "No changes were made.  Exiting.." 20 50 10

else

# Check for the existance of /etc/ld.so.conf
if [ ! -e /etc/ld.so.conf ]; then
dialog --title "Setup GTK+-2.12.9" --msgbox "You do not have an /etc/ld.so.conf.  Something is very wrong.  Exiting.." 20 50 3
exit 1;
fi
# Check for /etc/ld.so.conf entry.
if head -1 /etc/ld.so.conf | grep /opt/gtk+-2.12.9/lib > /dev/null 2>&1; then
sudo ldconfig
dialog --title "Setup GTK+-2.12.9" --msgbox "GTK+-2.12.9 is already set up on the system.  No changes were made.  Exiting..." 20 50 3    
      # already done
      exit 1;
       
   fi

# Get rid of symlink and copy file from KNOPPIX image if needed.
if [ -L /etc/ld.so.conf ]; then
       sudo rm -f /etc/ld.so.conf
       sudo cp /KNOPPIX/etc/ld.so.conf /etc/ld.so.conf
    else
       sudo cp -f /etc/ld.so.conf /etc/ld.so.conf.bak
fi

# Add entry to first line of /etc/ld.so.conf.

sudo sed -i '1 i\
/opt/gtk+-2.12.9/lib' /etc/ld.so.conf
sudo ldconfig
dialog --title "Setup GTK+-2.12.9" --msgbox "Finished setup.  GTK+-2.12.9 is ready for use." 20 50 10
fi



The unsetup:


Code Sample

#!/bin/bash
#Script to unsetup gtk+-2.12.9
#Idea and script by WDef, tweaked for dialog.

dialog --title "Deconfigure GTK+-2.12.9" --yesno "This setup will restore your /etc/ld.so.conf file and library linking to the state it was before running the setup menu for GTK+-2.12.9.  Do you want to proceed?" 20 50 3

if [ $? = 1 ]; then
dialog --title "Deconfigure GTK+-2.12.9" --msgbox "No changes were made.  Exiting.." 20 50 10

else

# Check for the existance of /etc/ld.so.conf
if [ ! -e /etc/ld.so.conf ]; then
dialog --title "Deconfigure GTK+-2.12.9" --msgbox "You do not have an /etc/ld.so.conf.  Something is very wrong.  Exiting.." 20 50 3
exit 1;
fi

# Check for /etc/ld.so.conf entry.
if head -1 /etc/ld.so.conf | grep /opt/gtk+-2.12.9/lib > /dev/null 2>&1; then
sudo sed -i 1d /etc/ld.so.conf
sudo ldconfig
dialog --title "Deconfigure GTK+-2.12.9" --msgbox "/opt/gtk+-2.12.9/lib was removed from the first line of /etc/ld.so.conf and ldconfig was run.  Exiting..." 20 50 3
else
dialog --title "Deconfigure GTK+-2.12.9" --msgbox "GTK+-2.12.9 is not setup on the system.  No changes were made.  Exiting..." 20 50 3    
      # already done
      exit 1;  
   fi
fi


Seems to work and make things easier.   Thanks again.

Posted by ^thehatsrule^ on May 03 2008,06:42
Quote (Jason W @ May 03 2008,00:58)
Ok, here is pretty much what i plan to include in the menu - a setup and a remove setup entry.

Some comments after a glance at the code:

- are you sure you want to only look at the first line? What if other extensions want to do something similar, etc.?
- the grep line may work, but it's actually checking wildcards.  You'd need to escape it, or use -F, etc. and use anchors.  A better way may be to use test (i.e. if [ `command` = "this" ]; then ) while (maybe) saving on some trivial resources

Posted by WDef on May 03 2008,14:16
Good to use dialog to inform the user something's happened (see the loop-aes extension module setup script for something similar).

I'd probably just call it with sudo from the menu and save typing redundant sudos everywhere (less clutter is usually good practice).  If you are concerned non-X users might run it as ordinary user and wonder why it's broken, the usual thing is test if it's being run with root rights at the beginning:

Code Sample
if [ $EUID -ne 0 ];then
      echo "You're not root, exiting .."
      exit 1
fi


But it doesn't really matter much, whatever you' re happy with.

Posted by Jason W on May 04 2008,00:40
You're right, using sudo from the menu is much cleaner.  And the exit script can check the first 4 lines of /etc/ld.so.conf just in case another extension does this kind of thing also and remove the right line.  Even though an extension that would have to do this would be something like gtk2 and therefore be mutually exclusive to this one.  I will look into using test, as well.  I think those would be good finishing touches.
Posted by ^thehatsrule^ on May 04 2008,01:52
Is there a reason for not looking through the whole file?  iirc it's not very big
Posted by Jason W on May 04 2008,02:12
If /opt/gtk+-2.12.9/lib is not before /usr/lib, then the freetype and glib2 in base will be the ones linked instead of the newer versions in /opt/gtk+-2.12.9.  The whole reason for having the entry on the first line.  Of course it could be on a later line as long as it is before /usr/lib.  Mounting the uci puts /opt/gtk+-2.12.9/lib at the end of the file.  Just not where it needs to be for the extension to function.  I have the unsetup script searching and removing the line from any of the first four lines of the file.  Now making the setup make sure that if the entry is in the first four lines that it is above /usr/lib.
Posted by ^thehatsrule^ on May 04 2008,02:28
It's not about that - it just seems like an artificial solution to me.  Even if it is there after that /usr/lib line, it doesn't affect it (if it's there anyways shouldn't it be removed?) - but if that is of concern, maybe searching up until /usr/lib would be better imo.
Posted by Jason W on May 04 2008,05:07
At this point I say the best thing is to let the user edit the file.  The info file has the details.  User has complete control and knowledge that way, which is how I like it.

Thanks WDef for the script and Hats for the feedback and input, but now after 100 lines of code and 2 evenings of ignoring my wife and kids (I only see them 2 evenings a week) I reaffirm that simple is elegant.   If one wants to have a script to automate this extension, there is enough example here for him to do so.  The best script is one you make for you and your environment.

Posted by WDef on May 04 2008,16:44
Please reconsider and include your setup script when you get time, I wouldn't get too bothered about the details though -  if yours works, just include it next rebuild.  That's the best way to test it anyway, and the benefits of your work will then reach more people.

Many newbies won't know how/what to do to edit ld.so.conf, and it's tedious editing files every time one uses an extension, and that is a useful extension that will get loaded every boot for a lot of people.

We already showed nothing seems break in the base, so I don't think there is much in the way of environmental differences to  consider at this stage.

No need to risk any further quality time with the family though.

Your efforts are appreciated Jason.

Posted by Jason W on May 04 2008,17:48
WDef,
Thanks.  I had posted the rough draft of what I was going to submit so there could be peer review.  It is suggestions for improvement, and critique, helps make for a better final product.  I am not a good script person, and I have learned from the suggestions made in this thread.  I knew there would be at least a few things that could be improved upon in my version of the script.   I have always found the DSL forum a friendly place, my home away from home.  Knowing this, I shouldn't such have a thin skin at times.  I welcome all comments and suggestions, and appreciate the feedback and interest you guys give to the things I am doing.  

While dealing with the first few lines of /etc/ld.so.conf would do, the ideal thing is to determine if the library path is listed above /usr/lib.  Anything that is listed under that is created by loading the uci and is then removed by unloading the uci.  (I think that unloading the uci removes the entries, but we are not dealing with stuff created by the uci). That is a bit of complexity, for me at least, but I will study up on it that will be the goal.  It would then be bulletproof in the case of other extensions that may in the future do the same thing.  It will take some learning on my part, but it will be a good experience.

Posted by WDef on May 05 2008,09:57
Up to you entirely. BTW a lot people seem to get a bit touchy about their scripts esp. to begin with - perfectly normal.

I'll have to re-read your post later (post coffee).  Sing out if you need anything.

Posted by meo on May 05 2008,11:16
Dear Jason W!

I'm using your extension now and I think it's great! I have added 38+ MB of truetype fonts to home/dsl/.fonts and added it to my remaster. And it really is a joy using Firefox (the most recent version) and also Thunderbird in my own language (swedish). I have posted a hint about this in the Remaster HOWTO found in Other help topics so others can take advantage of theese new possibilities. Thanks for sharing your extension!

Have fun and keep up your fine work,
meo

Posted by meo on May 06 2008,06:11
Hi again Jason W!

The extension that I was referring to is bittorrent-gui.dsl, which does load but when I try to start it from the menu nothing happens. Not even the cpu-meter reacts in the torsmo monitor.

Have fun and keep up your good work for the DSL-community,
meo

EDIT PS This extension doesn't work at all in DSL 4.3 and I am running DSL 3.3 which I have remastered heavily (the KNOPPIX file is three times bigger than the original but it is solid as a rock). What I mean is that it might be something else than your extension that affects the bittorrent-gui.dsl adversely. DS

Posted by kuky on May 06 2008,21:09
how to clean extensions?

the OOo.2.2.es.uci is updated by ver 2.3 and its not necessary

also with firefox209.es.uci

Posted by stupid_idiot on May 10 2008,08:39
Hi guys!
I'm OK and well, but my life is really, really busy right now. I won't have any time at all (seriously) to spend on DSL in the next year or so, which makes me feel rather sad. :)

Special thanks to JasonW for the GREAT JOB on GTK2. (Am I missing out anyone??)

p.s.
DSL will always have a special place in my heart.

Posted by jpeters on May 10 2008,19:06
Quote (stupid_idiot @ May 10 2008,08:39)
Hi guys!I won't have any time at all (seriously) to spend on DSL in the next year or so, which makes me feel rather sad. :)

p.s.
DSL will always have a special place in my heart.

sure, I've heard that line before.  You've found something else that pays better.  That's it, isn't it?    just admit it....
Posted by WDef on May 10 2008,20:55
Sorry to see you go stupid_idiot, you've made some valuable contributions to the community.  Perhaps you'll come back to us when life calms down a bit.

I was also hoping you might be around in part to provide some input on future mplayer, vlc etc builds, esp. x264 support which I've had trouble with in the past.  

Would you be pingable on that if need be?

Posted by roberts on May 10 2008,22:00
We will all really miss you. You are a valuable and cherished member of our family. Hope you can at least check in and lets us know how things are going for you.

All the best.

-- Robert

Posted by stupid_idiot on May 11 2008,00:31
Quote (WDef @ May 11 2008,04:55)
Would you be pingable on that if need be?

I am VERY busy on weekdays, but I will definitely be around on weekends. I'll try to help out if I can. You could send me a PM?? :)
Posted by curaga on May 11 2008,09:20
Whatever you do, have fun and go calm :)
Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.