December Extensions


Forum: The Testing Area
Topic: December Extensions
started by: roberts

Posted by roberts on Dec. 05 2007,05:51
Thanks to Juanito for
svn.uci
and an update to:
compile-3.3.5.uci

And in the modules area:
irda_modules-2.4.31.dsl

Posted by roberts on Dec. 05 2007,23:40
From the screenshots thread, now posted in the testing area:

classic-bakgrounds.tar.gz
jwmThemes.tar.gz


Read the info file before using.

Thanks to Lucky13 for creating and sharing the new JWM color schemes.

Many combinations of classic backgrounds and the new JWM color schemes go very well together.

Posted by stupid_idiot on Dec. 06 2007,11:16
Plan for this week:
VLC does work on DSL already, but I am trying to improve the mini-GTK2 extension by using a version of GTK+ that uses Cairo. More and more apps nowadays seem to require Cairo.
I would like to call it 'gtk2.unc', or anything simple.
Possibly follow up with a 'gnome-libs.unc' or similar to cover the patchwork of GNOME-originated libraries needed by some apps.

I'll submit the multimedia extensions (ffmpeg, mencoder/mplayer, VLC) once I finish the GTK2 extension.

Posted by WDef on Dec. 06 2007,13:00
@Robert: does the backgrounds extension include the Fractal Movement backroungd from ~ 2.1b?  I always kind of liked that.  Also like the Saturn rings image from dsl-n.

@stupid_idiot: thx for your work on both.  May I suggest perhaps putting something in the name of the the mini gtk2 extension to remind people that it is 'mini' eg mini-gtk2.unc, or core-gtk2-libs or something.

Posted by Juanito on Dec. 06 2007,13:13
Quote
More and more apps nowadays seem to require Cairo

- I'd never heard of Cairo before I had a go at compiling conky-2 (hence the svn extension), but I got bogged down with the Cairo dependencies on freetype and fontconfig and trying to use what is already in dsl.

I'd be interested to know if you get Cairo to work with freetype/fontconfig in dsl.

Posted by stupid_idiot on Dec. 06 2007,14:24
Juanito:
I do all my compiling on a Debian Sarge chroot. I didn't have any trouble from the latest version 1.4.12 of Cairo. I have 'libfreetype-dev' and 'libfontconfig-dev' installed.

Do you mean you had a problem with Cairo not detecting freetype/fontconfig? In that case I'd look at 'config.log' to see what happened.

Posted by Juanito on Dec. 06 2007,14:43
Quote
Do you mean you had a problem with Cairo not detecting freetype/fontconfig?

- that's exactly it, even thought I added the headers/libs/executables missing in dsl. I didn't pick up anything useful from config.log as yet but I'll keep trying.

I was compiling against debian sarge before but moved to [trying] to compile against the libs actually in dsl.

Posted by stupid_idiot on Dec. 06 2007,15:21
Cairo's 'configure' uses 'pkg-config' to detect freetype/fontconfig. So I think:
- pkg-config must be installed.
- '/usr/lib/pkgconfig/freetype2.pc' and '/usr/lib/pkgconfig/fontconfig.pc' must be installed.
Here's the test section for freetype/fontconfig from my config.log (on Debian Sarge chroot):
Code Sample
configure:27156: checking for cairo's FreeType font backend
configure:27173: checking for FONTCONFIG
configure:27181: $PKG_CONFIG --exists --print-errors "$ft_REQUIRES"
configure:27184: $? = 0
configure:27199: $PKG_CONFIG --exists --print-errors "$ft_REQUIRES"
configure:27202: $? = 0
configure:27240: result: yes
configure:27251: checking for FcFini
configure:27307: gcc -o conftest -Os -fomit-frame-pointer -fdata-sections -ffunction-sections    -Wl,--gc-sections conftest.c  -lm -lfontconfig   >&5
configure:27313: $? = 0
configure:27331: result: yes
configure:27349: checking for FREETYPE
configure:27357: $PKG_CONFIG --exists --print-errors "freetype2 >= $FREETYPE_MIN_VERSION"
configure:27360: $? = 0
configure:27375: $PKG_CONFIG --exists --print-errors "freetype2 >= $FREETYPE_MIN_VERSION"
configure:27378: $? = 0
configure:27418: result: yes
configure:27505: checking whether cairo's FreeType font backend could be enabled
configure:27508: result: yes
configure:27556: creating src/cairo-ft.pc

Posted by roberts on Dec. 06 2007,15:27
Quote
@Robert: does the backgrounds extension include the Fractal Movement backroungd from ~ 2.1b?  I always kind of liked that.  Also like the Saturn rings image from dsl-n.

The classic-backgrounds does include Fractal Movement as well as:
saturn_occultation.jpg
Tree_and_Moon.jpg
fractalMovementscape.jpg
Elefanter.jpg

Posted by Juanito on Dec. 08 2007,10:36
Quote
- pkg-config must be installed.

- it's included in compile-3.3.5.uci, but I was using freetype2-2.1.2 by mistake (I need to update compile-3.3.5.uci.info) which does not have a *pc file - the correct version, freetype2-2.1.5 does have a *pc file. Next, the fontconfig "make install" craters when it tries to write to /etc/fonts - I thought everything of interest had been copied, but not the *pc file...

Finally, the cairo compile fails with something about double-buffer extensions in X.

I think I'll wait for you to compile cairo before continuing with conky-2  :)

Posted by lucky13 on Dec. 08 2007,17:25
Ping Juanito. The thread for March is closed, but I have a question about one of your submissions.

Does your ntfsprogs extension use XFS? I loaded ntfsprogs.dsl to my hard drive install of DSL 4.0 release. I didn't know DSL had XFS, but now I have it and have XFS daemons running.

When booting DSL (4.0, 4.1) on CD or frugal, I don't have XFS in /proc/filesystems. The only other filesystem progs extension I've added is sshfs/fuse, and that doesn't give me XFS or start any daemons. I haven't had a chance to use ntfsprogs yet so I'm kind of befuddled where the XFS daemons came from. Is it resulting from the ntfsprogs.dsl extension?

Thanks.

Posted by Juanito on Dec. 09 2007,04:21
If XFS is included it wasn't intentional...

Seriously, as far as I remember, the extension contains various ntfs utilities and the library - all of which could probably use some stripping since this was made before I knew about that.

Maybe one of these days, I'll update to the latest version and repackage as a uci :)

Posted by Juanito on Dec. 09 2007,11:14
Note that hplip.uci supercedes hplip.tar.gz so hplip.tar.gz can be deleted.

After testing, it looks like bluez-utils.uci does everything that bluez-utils.dsl does, so bluez-utils.dsl can be deleted.

I managed to get alsa_bluezsco.dsl to work with bluez-utils.uci but am still struggling to incorporate this into bluez-utils.uci so alsa_bluezsco.dsl should stay for a while yet.

Posted by roberts on Dec. 09 2007,17:13
Now posted cvs.uci

Thanks to Juanito we have a cvs client.

Also deleted hplip.tar.gz and bluez-utils.dsl per request.

Posted by stupid_idiot on Dec. 10 2007,14:09
For tomorrow (hopefully):
(1) multimedia
ffmpeg.tar.gz [~30K]
ffmpeg2theora.tar.gz [~20K]
mencoder.tar.gz [~140K]
mplayer.tar.gz [~160K] (replaces 'mplayer-nogui.dsl')
vlc.uci [~730K]
mm-base.uci [~3.4M] (base libraries and files)
-- BTW: Bitstream Vera [72K] makes a great-looking subtitle font.

(2) GTK2
gtk2-core.unc [~1.7M] (required by VLC)
gtk2-core-dev.unc [~400K]

(3) wxWidgets, and related
i.
libwxgtk1.uci [~1.6M] (replaces current version; configuration changed)
libwxgtk1-dev.uci [~800K]
libwxgtk2.uci [~1.7M] (aside from toolkit difference, configuration is identical to 'libwxgtk1.uci')
libwxgtk2-dev.uci [~800K]
-- Note: The decrease in size from the current 'libwxgtk1.uci' [1.8M] is due to compiling with '-fno-exceptions' (by passing '--enable-no_exceptions' and '--disable-exceptions' to 'configure'). '-fno-rtti' can reduce size further, but some apps (e.g. amule) need RTTI to be enabled in the library in order to compile.
ii.
amule-gtk1.uci [~1.2M] (replaces 'amule.dsl')
xchm.tar.gz [~100K] (replaces 'xchm.dsl')

(4) codecs
codecs-misc.uci [4.3M] (replaces 'codecs-win32.uci')
codecs-QT.uci [2.1M] (replaces 'codecs-qtx.uci')
codecs-RM.tar.gz [160K] (replaces 'codecs-real.uci')
codecs-WM.uci [1.8M] (replaces 'codecs-wmp.uci')

Robert:
Very sorry for so many sudden changes.
Many apologies.

Edited on 2007/12/13.

Posted by roberts on Dec. 10 2007,21:30
Quote (roberts @ Dec. 05 2007,15:40)
From the screenshots thread, now posted in the testing area:

classic-bakgrounds.tar.gz
jwmThemes.tar.gz


Read the info file before using.

Thanks to Lucky13 for creating and sharing the new JWM color schemes.

Many combinations of classic backgrounds and the new JWM color schemes go very well together.

These two extensions have been moved to the < Themes > area of the Repository.

FYI: Clicking on the Date column displays by most recent. This will display the two new extensions at the top for easy access.

You can also access by using the MyDSL download tool, Themes button.

Since I do not want to load up the iso with many backgrounds and themes, these were moved so that 4.2 will have a simple fetch script to download and install.



Posted by roberts on Dec. 11 2007,06:37
Thanks to Juanito, now posted in testing:
conky-1.uci

Read the .info file for use.

Posted by lucky13 on Dec. 13 2007,13:10
Juanito: the XFS issue I mentioned before isn't related to ntfsprogs.dsl or any other extension.
Posted by stupid_idiot on Dec. 14 2007,11:22
Hi Robert:
I've sent the extensions by email. Due to the large number of files, I've split them into two attachments in two emails.

All the extensions are okay EXCEPT for 'gtk-core.unc' -- there is a slight problem with it. Could you please avoid putting it up? I will send the fixed version shortly.

It has to do with this warning:
Code Sample
Could not find the icon 'gnome-fs-home'. The 'gnome-hicolor' theme was not found either. Perhaps you need to install it.
You can get a copy from:
http://freedesktop.org/Software/icon-theme/releases
I will remove this warning from 'gtk/gtkicontheme.c'. There is no need to install the gnome icons since apps run fine without the icons. And if so, then there's no need for the warning.

Update:
The fixed version has been sent under the subject "Re-send: gtk2-core.unc".

Posted by stupid_idiot on Dec. 14 2007,13:21
Plan for this week:
- gimp-gtk2-2.2.uci [4.7M] (Possible replacement for ke4nt's 'gimp-gtk2-2.2.8.dsl'??)
- Update aging Mozilla-based extensions in 'net/' and 'uci/'?? (Compile and test to work with 'gtk2-core.unc' [1.7M])
- Possibly compile a 'libqt3.uci' as a central dependency for current Opera extensions?? (to reduce Opera size)
- Update WINE uci extensions (Change naming?? -- Replace 'wine-0.9.4x.uci' with 'wine-[ver].uci' at intervals of five: i.e. 'wine-0.9.[30,35,40,45,50].uci' Is this a good, or a bad idea? Thanks very much.)

Posted by roberts on Dec. 15 2007,00:58
What is the purpose of gtk2-core.unc?
It seems to be missing libs required by abiword and gnumeric?
libfribidi.so.0 & libgnutils.so.11

Posted by stupid_idiot on Dec. 15 2007,03:23
The intention is to streamline the GTK2 apps in DSL:
For example, Mozilla-based apps (e.g. Firefox, Flock, Seamonkey, Thunderbird) need only these basic libraries to run.
Other apps, like Abiword and Gnumeric, may require additional libraries -- e.g. libfribidi, libgnutls. Perhaps we could make a separate extension for them. (I would like to call it 'gtk2-extra.unc' -- Is this a suitable name?)

Whether or not to include a library in 'gtk2-extra.unc' or to integrate it into the app instead, might depend on this question:
Is the library needed by many other apps? If so, it may be best to let it be shared.
Otherwise, if it is a 'specialty' library, it would be better to integrate it into the app itself. (Example: libexif -- Compiled as 'libexif.a' and linked statically into the GIMP.)

Examples of libraries which can be shared by many apps, but which are not part of the basic GTK2 libraries:
(1) libbonobo, libglade, libgnome, libgnomecanvas, libgnomeprint, libgnomevfs, liborbit2, libxml2, etc (GNOME-related) [Needed by: gnucash, gnumeric]

The advantage we could get from this solution, as compared to the current monolithic 'gtk2-0705.unc', is that we don't need to download 14M of libraries just to run 'basic' GTK2 apps.

What I propose is: We gradually modify the current apps in 'mydsl/gtk2/' to work with the new 'gtk2-core.unc' and 'gtk2-extra.unc'. In the interim, the unmodified apps will still work with 'gtk2-0705.<unc/dsl>'.
ATM, I am ready to submit 'gimp-gtk2-2.0.uci' [4.2M] and 'gimp-gtk2-2.2.uci' [4.6M] as a replacement for ke4nt's 'mydsl/gtk2/gimp-gtk2-2.2.8.dsl' [13M]. They work directly with 'gtk2-core.unc' [1.7M].
I promise to start modifying abiword and gnumeric immediately.
-- Is this alright? (This refers to 'mydsl/gtk2/abiword-gtk2-2.2.7.dsl' and 'mydsl/gtk2/gnumeric.dsl'.)
I will have a look at the 'configure' options for abiword and gnumeric to see should be done for libfribidi and libgnutls.

Posted by stupid_idiot on Dec. 15 2007,03:50
Hello Robert:
Regarding libfribidi and libgnutls in abiword and gnumeric:
(1) libfribidi is needed by abiword, but not gnumeric.
QUOTE, 'abiword-2.2.11/configure':
Code Sample
error: * * * fribidi >= 0.10.4 is required * * *
(2) Doing 'grep -i gnutls' in the directories 'abiword-2.2.11/abi/' and 'gnumeric-1.6.3/' returns empty. Perhaps libgnutls is an indirect dependency?

Posted by stupid_idiot on Dec. 15 2007,05:13
List of libraries which I think could be included in an 'auxiliary' GTK2 extension:
< List of package names/versions/filesizes > [pastebin.com]
< List of source URLs > [pastebin.com]

Posted by WDef on Dec. 15 2007,11:26
I must say I'm terribly impressed (for what that's worth, I mean, who gives a rats arse what I think) by all this rampant, fiddly and time consuming compiling and extension building that's going on lately, particularly but not exclusively by Juanito and stupid_idiot.  Hats off to you chaps!

Looking forward to seeing if the compile.uci will solve some of those it-won't-compile-on-dsl-for-me type issues that we all come across from time to time.

Thought I'd say something encouraging while the mood took me.

Posted by Juanito on Dec. 15 2007,12:38
Quote
Looking forward to seeing if the compile.uci will solve some of those it-won't-compile-on-dsl-for-me type issues that we all come across from time to time
- Great, feedback would be welcome  :)

Quote
Thought I'd say something encouraging while the mood took me
- much appreciated, & speaking of encouragement, hows the final version of citytime coming on?

Posted by WDef on Dec. 15 2007,12:43
Quote
citytime


It's been dormant due to rather a lot of work commitments lately.  So far I have a C-version that uses child processes to download while it's displaying updated cached time, another that does the same thing with threads, and some other variants that I can't remember.  I have one of these running all the time on my dsl desktop via torsmo.

I'll get back to it in the near future, thanks for enquiring.

Posted by roberts on Dec. 15 2007,23:06
A big thank you to stupid_idiot, anon, anonymous, et al ?

Now posted

     1 amule-gtk1.uci
     2 codecs-misc.uci
     3 codecs-QT.uci
     4 codecs-RM.tar.gz
     5 codecs-WM.uci
     6 ffmpeg2theora
     7 ffmpeg.tar.gz
     8 gtk2-core-dev.unc
     9 gtk2-core.unc
    10 libwxgtk1-dev.unc
    11 libwxgtk1.uci
    12 libwxgtk2-dev.unc
    13 libwxgtk2.uci
    14 mencoder.tar.gz
    15 mm-base.uci
    16 mplayer.tar.gz
    17 mplayerplug-in.dsl
    18 vlc.uci
    19 xchm.tar.gz

Read .info files for details, dependencies, and features.

Posted by stupid_idiot on Dec. 16 2007,00:43
Hi Roberts:
(1) There is a typo in 'gtk2-core.unc' -- The 'Copying Policy' line should read "Copying-policy: all -- LGPL v2 [1991]", and not "Copying-policy: All -- LGPL v2 [1991]".
(2) There has been an error in 'mm-base.uci.info'. The filename for Bitstream Vera Mono is listed as 'VeraSe.ttf' -- This is incorrect, it should be 'VeraMono.ttf'.

May I request that you change these please?
Thank you very much.

Posted by roberts on Dec. 16 2007,04:54
Requested changes completed.
Thanks again for all of your efforts.

Posted by roberts on Dec. 16 2007,05:32
Thanks to pmisch, we now have

kernelsource-2.4.31.dsl

now posted in the testing area.

Posted by b1ackmai1er on Dec. 16 2007,12:42
@Jaunito

Hi, I am not that experienced with compiling.

Is your compile-3.3.5.uci intended for use with gcc1-with-libs and gnu-utils?

Thanks Phil

Posted by Juanito on Dec. 16 2007,12:50
compile-3.3.5.uci is intended to be used instead of gcc1-with-libs. gnu-utils can be used with compile-3.3.5 (which is what I do) - I don't believe it is absolutely necessary, but some of the full-featured tools in gnu-utils (eg find) make life easier.

Any feedback on using compile-3.3.5 would be welcome  :)

Posted by andrewb on Dec. 16 2007,22:38
Quote (Juanito @ Dec. 15 2007,21:50)
Any feedback on using compile-3.3.5 would be welcome  :)

Should there not be a warning with this extension not to use it for compiling modules for the already compiled DSL kernels as the extension uses a different version of the gcc compiler & so may be incompatible? Is this not why you created the gcc-2.95.unc extension? I'm assuming Robert has also used gcc 2.95 to compile the 2.4.31 kernel.
Posted by Juanito on Dec. 17 2007,03:23
You're right in that the notes with the 2.4.26 kernel sources (I did not check the 2.4.31 kernel sources) recommends using gcc-2.95.

I initially started with gcc-2.95 for the compile extension, but gcc-2.95 will not compile the version of the glibc library used in dsl, so I switched to gcc-3.3.5.

I have not seen any adverse effects compiling modules (eg bluetooth, irda, cifs) with the compile extension, but I will add a warning to the compile extension info file as suggested.

Edit: here is what it says on the subject in ../Documentation/Changes in both the 2.4.26 and 2.4.31 kernel sources:
Quote
Current Minimal Requirements
============================

Upgrade to at *least* these software revisions before thinking you've
encountered a bug!  If you're unsure what version you're currently
running, the suggested command should tell you.

Again, keep in mind that this list assumes you are already
functionally running a Linux 2.2 kernel.  Also, not all tools are
necessary on all systems; obviously, if you don't have any PCMCIA (PC
Card) hardware, for example, you probably needn't concern yourself
with pcmcia-cs.

o  Gnu C                  2.95.3                  # gcc --version
o  Gnu make               3.77                    # make --version
o  binutils               2.9.1.0.25              # ld -v
o  util-linux             2.10o                   # fdformat --version
o  modutils               2.4.14                   # insmod -V
o  e2fsprogs              1.25                    # tune2fs
o  jfsutils               1.0.12                  # fsck.jfs -V
o  reiserfsprogs          3.6.3                   # reiserfsck -V 2>&1|grep reiserfsprogs
o  xfsprogs               2.6.0                   # xfs_db -V
o  pcmcia-cs              3.1.21                  # cardmgr -V
o  quota-tools            3.09                    # quota -V
o  PPP                    2.4.0                   # pppd --version
o  isdn4k-utils           3.1pre1                 # isdnctrl 2>&1|grep version
 
Kernel compilation
==================

GCC
---

The gcc version requirements may vary depending on the type of CPU in your
computer. The next paragraph applies to users of x86 CPUs, but not
necessarily to users of other CPUs. Users of other CPUs should obtain
information about their gcc version requirements from another source.

The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it
should be used when you need absolute stability. You may use gcc 3.0.x
instead if you wish, although it may cause problems. Later versions of gcc
have not received much testing for Linux kernel compilation, and there are
almost certainly bugs (mainly, but not exclusively, in the kernel) that
will need to be fixed in order to use these compilers. In any case, using
pgcc instead of egcs or plain gcc is just asking for trouble.

Note that gcc 2.7.2.3 is no longer a supported kernel compiler. The kernel
no longer works around bugs in gcc 2.7.2.3 and, in fact, will refuse to
be compiled with it. egcs-1.1.2 has register allocation problems in very
obscure cases. We have ensured the kernel does not trip these in any known
situation. The 2.5 tree is likely to drop egcs-1.1.2 workarounds.

The Red Hat gcc 2.96 compiler subtree can also be used to build this tree.
You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build
the kernel correctly.

In addition, please pay attention to compiler optimization.  Anything
greater than -O2 may not be wise.  Similarly, if you choose to use gcc-2.95.x
or derivatives, be sure not to use -fstrict-aliasing (which, depending on
your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing).

Posted by andrewb on Dec. 17 2007,05:46
My experience was compiling the modules for one of the Zydas USB 802.11 dongles. When I used the gcc1-with-libs extension I got a message about the module having been compiled with a different compiler from the kernel when I tried to use it. I needed both the gcc1-with-libs & the gcc-2.95 extensions installed as the 2.95 extension doesn't have make etc. It may also be worth adding to the 2.95 info file that the compiler isn't called gcc, but gcc-2.95 (i.e. it needs the command gcc-2.95 called to invoke the compiler)
Posted by Juanito on Dec. 17 2007,06:06
Quote
It may also be worth adding to the 2.95 info file that the compiler isn't called gcc, but gcc-2.95 (i.e. it needs the command gcc-2.95 called to invoke the compiler)
- Hmm, maybe it would be better to add a symlink gcc -> gcc-2.95 (and perhaps cc -> gcc-2.95) to the extension and re-post it.

Posted by WDef on Dec. 17 2007,08:22
Ping: Juanito

Thanks very nuch for compile.uci - just used it to sucessfully build gnupg2 (being posted)!

Quote
have not seen any adverse effects compiling modules (eg bluetooth, irda, cifs) with the compile extension,


Andrewb is right - modules have to be compiled with the same gcc (and I think binutils) version as was the kernel.  If not, they might appear to work ok, but unpredictable things could happen, which in the kernel could be very bad.  If modules have been posted that were not compiled with gcc-2.95, these should be pulled immediately and rebuilt.

Quote
maybe it would be better to add a symlink gcc -> gcc-2.95


I suggest not doing that.  As we know, gcc-2.95 needs to be co-installed with eg gcc-with-libs on dsl when compiling the kernel or modules and these versions need to be kept seperate for other compiles.  It's better to explicitly point at CC=gcc-2.95 in the environment or if necessary in the Makefile if it doesn't say that already when building a module (the 2.4.xx kernel config points at it anyway and at least some module sources will get the gcc version  from the kernel sources). Then we're aware that we are doing so and these versions don't get mixed up.  gcc-2.95 is not recommended for compiling anything but the 2.4.xx kernel and modules since it's incapable of doing i686 optimization properly and is generally a pretty crappy gcc version.

Posted by roberts on Dec. 20 2007,07:11
New extensions now posted!

Thanks to Juanito for:
perl-5.8.0_XML.dsl
perl5.8.0.dsl
ntfsprogs-2.uci
compile-3.3.5.uci


Thanks to WDef for:
partimage.uci
gnupg2.uci


Thanks to humpty for:
sopcaster.uci
decurs-0.42.2.unc
mlvwm.uci

Posted by WDef on Dec. 20 2007,09:42
About gnupg2.uci:

1. This is the new "modularized" branch of GnuPG with new  features, more dependencies to build, and a different architecture. There is nothing wrong with the 1.4.x branch of GnuPG which is still actively maintained, partly because of small distributions such as dsl.

2. The executable is called "gpg2", so that is what you type on the commandline.

3. Applications that have GnuPG as a dependency may not be GnuPG-2  compatible as yet.

4. Applications that can use GnuPG (eg aespipe and loop-aes) for key encryption and so forth may not be able to find GnuPG on dsl unless it is in the standard locations, and not merely symlinked there.  This is why I didn't make a uci out of gnupg-1.4.7.  Hard linking might work.

5. I haven't tested this much yet.  Compiled on i686.  Older cpus  might be better off with gnupg-1.4.7.

Posted by stupid_idiot on Dec. 20 2007,14:53
Hi Robert:
There is a broken row in the table on the < MyDSL Testing > page.
It is very easy to spot.

Posted by roberts on Dec. 20 2007,15:44
Found it. Fixed it. Thanks!
Posted by kuky on Dec. 20 2007,23:39
to juanito
ntfs ...ntfsprogs-2.uci

how i mount a external usb media player with hd in ntfs?

its appear as mnt/sda1
when i writte
sudo ntfsmount /mnt/sda1 /mnt/ntfs it said that its needed a device and mount point

Posted by ^thehatsrule^ on Dec. 20 2007,23:55
Quote
sudo ntfsmount /mnt/sda1 /mnt/ntfs
Those are 2 mount points. Typically you need <device> <mountpoint>

Posted by Juanito on Dec. 21 2007,06:48
If you look in the info file, there is an example of what you have to do - something along the lines of:
Code Sample
$ sudo modprobe fuse
$ sudo mkdir /mnt/ntfs
$ sudo ntfsmount /dev/sda1 /mnt/ntfs -o noblkdev

- be sure to issue the "sync" command once you've finished and before you unmount the drive. Note also that chkdsk will run automatically next time you use the drive under windows.

Posted by kuky on Dec. 22 2007,12:11
thanks juanito..

i have a partial success...i can mount and copy but when finish, the next time when i ntfsmount said that its necessary to check in windows...and stop the mount..

who is "sync" command ....

its necesary to sudo modprobe and sudo mkdir every time ?

It can be the possibility to make a lua or script to ntfsmount device and mount point when load the uci..? to add to tools in dsl ...

and the last where are you from...?

Posted by john.martzouco on Dec. 22 2007,12:57
Quote (stupid_idiot @ Dec. 20 2007,09:53)
There is a broken row in the table on the < MyDSL Testing > page.

Hi Robert,

There's another one on the < Apps > page as well... there's only one 'o' in yellow (yelloow.gif).

Robert, another triviality... do you control the messages that scroll up on bootup?  There's a message that's associated to nodma that has two letter L in the word acceleration.  I'll get it from my dmesg when I run the laptop next time and post the entire phrase if it helps.

Posted by Juanito on Dec. 22 2007,17:09
Quote
the next time when i ntfsmount said that its necessary to check in windows...and stop the mount..

- I think that when a "foreign" device writes to a windows partition, the chkdsk bit is set and perhaps you cannot write again without performing chkdsk. Maybe one of the other ntfsprogs applets can take care of this?

Quote
who is "sync" command ....

- this empties the disk cache - i.e. it makes sure all of the data is written to disk..

Quote
its necesary to sudo modprobe and sudo mkdir every time ?

- not in the same dsl session, no. After rebooting you will need to repeat these two commands.

Quote
It can be the possibility to make a lua or script to ntfsmount device and mount point when load the uci..? to add to tools in dsl ...

- the problem is the script would have to prompt for the device name to mount which is beyond my scripting abilities...

Posted by roberts on Dec. 22 2007,17:26
Quote (john.martzouco @ Dec. 22 2007,04:57)
Quote (stupid_idiot @ Dec. 20 2007,09:53)
There is a broken row in the table on the < MyDSL Testing > page.

Hi Robert,

There's another one on the < Apps > page as well... there's only one 'o' in yellow (yelloow.gif).

Robert, another triviality... do you control the messages that scroll up on bootup?  There's a message that's associated to nodma that has two letter L in the word acceleration.  I'll get it from my dmesg when I run the laptop next time and post the entire phrase if it helps.

Found the two typos. Fixed. Thanks.
Posted by humpty on Dec. 22 2007,18:17
there's something i noticed about my wm extension mlvwm.uci.
the /opt/.mydsl_menu/mlvwm dir is not removed when unmounting
the uci.
is this intentional? or have i made a boo boo?
(dsl 4.2rc1)

Posted by roberts on Dec. 22 2007,18:52
If it is in user.tar.gz then typically yes.
If a file or directory is "in use" then no.

Posted by john.martzouco on Dec. 23 2007,15:22
I've installed and am running Juanito's HPLIP extension from the Testing category.

I've gotten as far as seeing my printer listed in the CUPS config page in Firefox and will continue with this later.

It took me 4-1/2 hours to install everything and I already had all the extensions downloaded.  I've written some scripts to make this easier for next time.  They can be downloaded < here. >  I don't know what commands to use to download files from the internet using the shell, so some of the code in the download.bash file is pseudocode.

It looks like it's going to work.

Juanito, I found it helpful to reword a tiny piece of the .info file:
Code Sample
                    Requires the following:

                    hplip.tar.gz               - the main programs (cups, espgs, hplip), libs, foomatic, fonts, etc
                    python-2.3.uci             - v2.3.6 with the latest security updates
                    hplip_etc.dsl              - conf files to be loaded once then added to backup
                    hplip_ppd.tar.gz           - ppds to be loaded once then appropriate printer(s) added to backup
                    hplip_site-packages.tar.gz - files shared by hplip & python-2.3
                   
                    samba-3.uci [optional]     - to share printers with windows

                    How-to


Thanks Juanito!

edit: PS - It's 45 minutes later, I've printed my first test page.  Only glitch I've seen so far is that clicking the Home tab on the CUPS config page results in a 404 Not Found error.

Good job Juanito!

Posted by john.martzouco on Dec. 24 2007,06:19
Juanito,

The init.d/cups executable displays a BusyBox man page for ps every time it's executed.

Posted by Juanito on Dec. 24 2007,15:39
Quote
Only glitch I've seen so far is that clicking the Home tab on the CUPS config page results in a 404 Not Found error.
- I think this happens because I removed the html help files to save some space...

Quote
The init.d/cups executable displays a BusyBox man page for ps every time it's executed.
- Hmmm, this doesn't happen to me. I'm going to be away from my desktop with hplip for the next couple of weeks, but I'll have a look when I get back.

Posted by kuky on Dec. 27 2007,19:45
ping to juanito

sorry by the delay but are xtimas days..

i finally solve the problem of the multimedia iomega hd screenplay that in the box said its only can managed with vista xp etc win new generation ntfs... its easilly formated to fat32 with dsl and the hd works fine included the media tv...the files are managed with dsl or my win98se

killing the dog  its stoped the Hydrophobia...

Posted by b1ackmai1er on Jan. 01 2008,06:04
Thanks goes to JasonW for an update to

gtk-gnutella.dsl

Now posted in the repository.

[from roberts]

Posted by roberts on Jan. 04 2008,15:46
Thanks goes to JasonW for a unc version.

gtk-gnutella.unc

Now posted in the repository.

Posted by chaostic on Jan. 06 2008,08:19
Note for vlc, was compiled with ncurses module, which might be a good thing for us CommandLine Commandos :}
Posted by humpty on Jan. 06 2008,15:30
vlc.uci
i loaded the required extensions;
gtk2-core.unc
libwxgtk2.uci
mm-base.uci

but i still get this error:
vlc: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

however added gtk2+-2.10.9.dsl works o.k

Posted by chaostic on Jan. 06 2008,21:54
Quote (humpty @ Jan. 06 2008,10:30)
vlc.uci
i loaded the required extensions;
gtk2-core.unc
libwxgtk2.uci
mm-base.uci

but i still get this error:
vlc: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

however added gtk2+-2.10.9.dsl works o.k

Funny, I used (and downloaded) all four of those yesterday and it worked. Which other packages have you installed?
Posted by stupid_idiot on Jan. 07 2008,12:14
Hi humpty:
You need to run
Code Sample
sudo ldconfig
after loading 'gtk2-core.unc'.
(This is mentioned in the info file for 'gtk2-core.unc'.)

Posted by Juanito on Jan. 07 2008,12:33
I think this (ldconfig) was automated on loading extensions in later versions of dsl-3.4.x/4.x.

I used gtk2-core.unc yesterday and a dependent application found the libs without me doing anything.

Posted by stupid_idiot on Jan. 07 2008,13:24
Omigosh, I just tested it out. You are right!

Humpty: In that case, I don't know what is causing the error. But, maybe you could do 'sudo ldconfig' anyway, just to be sure?
Thanks!

Posted by humpty on Jan. 07 2008,16:29
vlc.uci
hey, false alarm !
i rebooted and all is fine. tks folks.

Posted by Jason W on Jan. 23 2008,06:41
Juanito-
 December is gone, but I have to say your compile-3.3.5 extension is making fast work out of building things for DSL that were tedious before, at least for me.  I just thought I would let you know that.  

-JW

Posted by Juanito on Jan. 23 2008,08:01
Thanks for the feedback (and thanks to everybody who helped in explaining what to do to build it...).

If you have any suggestions in what to add or change - feel free to say so.

Posted by curaga on Jan. 23 2008,08:58
OK, Juanito. How about adding popt development files?

Probably just copying them from my popt_dev.dsl, editing the .la libtool file, and making the library symlink would suffice.

Posted by Juanito on Jan. 23 2008,10:33
OK - I'll have a look in a couple of days
Posted by stupid_idiot on Jan. 23 2008,15:31
Hi Juanito:
Just a nitpick with 'compile-3.3.5.uci' -- I think there's an unnecessary symlink:
Code Sample
/opt/compile-3.3.5/lib/libGL.so.1.2 -> /opt/compile-3.3.5/X11R6/lib/libGL.so.1.2
Instead of the symlink, we could just move 'X11R6/lib/libGL.so.1*' over to 'lib/'.

Also, a suggestion:
Maybe we could rename 'compile-3.3.5.uci' to 'compile.uci'?
The reason is, I think '/opt/compile' is easier to type than '/opt/compile-3.3.5'.
e.g.
CPPFLAGS='-I/opt/compile-3.3.5/include'
vs
CPPFLAGS='-I/opt/compile/include'
IMO the '-3.3.5' suffix is not needed since 3.3 is the de facto version of GCC in DSL.

p.s.
I think an idealized 'compile.uci' is an improvement over a .dsl or .unc because it eliminates filesystem clutter. Also, it is self-contained, so it's much easier to tell which files belong to which extension.
So, thanks for coming up with this great idea, and for all the hard work so far.
Awww.... :)

Posted by ^thehatsrule^ on Jan. 23 2008,16:13
Quote (stupid_idiot @ Jan. 23 2008,10:31)
Just a nitpick with 'compile-3.3.5.uci' -- I think there's an unnecessary symlink:
Code Sample
/opt/compile-3.3.5/lib/libGL.so.1.2 -> /opt/compile-3.3.5/X11R6/lib/libGL.so.1.2
Instead of the symlink, we could just move 'X11R6/lib/libGL.so.1*' over to 'lib/'.

A monolithic X installation is typically contained in /usr/X11R6/ so it should be fine as it is.

Quote
IMO the '-3.3.5' suffix is not needed since 3.3 is the de facto version of GCC in DSL.
By which standard?  If you're looking at the kernel, it should also be 2.95

Maybe a script can be included in the package to set up those environmental variables?

Also, the .info file for the extension looks like it is corrupted... could be from a conversion to uniform encodings on the .info's?

Posted by stupid_idiot on Jan. 23 2008,17:17
Quote
A monolithic X installation is typically contained in /usr/X11R6/ so it should be fine as it is.
Yes, that's right, but I was referring to another thing, not the normal '/usr/X11R6/' directory.
Very sorry for the misunderstanding. :(
To clarify:
Code Sample
ls /opt/compile-3.3.5/X11R6/lib
X11 libGL.so.1 libGL.so.1.2

ls /opt/compile-3.3.5/lib
[all_X11_libs]
[misc]
libGL.so -> libGL.so.1.2 -> ../X11R6/lib/libGL.so.1.2
libGL.so.1 -> libGL.so.1.2 -> ../X11R6/lib/libGL.so.1.2
So, Juanito actually put all the X11 libs (they are actually symlinks to '/usr/X11R6/lib/lib*') in '/opt/compile-3.3.5/lib/' instead of '/opt/compile-3.3.5/X11R6/lib/'; I think he wants to make compiling software easier since we only need to do:
Code Sample
LDFLAGS='-L/opt/compile-3.3.5/lib'
versus
Code Sample
LDFLAGS='-L/opt/compile-3.3.5/lib -L/opt/compile-3.3.5/X11R6/lib'
If so, we shouldn't have any libs in 'X11R6/lib/'.
I thought the two files 'libGL.so.1' and 'libGL.so.1.2' were left-over in 'X11R6/lib/' by accident, or perhaps they were later additions (but they were put in the wrong dir).

Regardless of what happened, it seemed logical that we should do the following:
(1) remove 'X11R6/lib/libGL.so.1'
(2) remove 'lib/libGL.so.1.2'
(3) move 'X11R6/lib/libGL.so.1.2' to 'lib/'

Posted by stupid_idiot on Jan. 23 2008,18:41
Quote
If you're looking at the kernel, it should also be 2.95

Maybe a script can be included in the package to set up those environmental variables?
Thanks -- I missed thinking about gcc-2.95 entirely. If I'm not wrong, the common wisdom is that it is safest to use gcc-2.95 to compile modules for a kernel compiled with gcc-2.95. If so, does anyone know how/why gcc-2.95 is safer than gcc-3.3 in this case, assuming that both compilers are able to compile the module cleanly?

In any case, I think we should be able to mix gcc-2.95 and gcc-3.3 easily.
e.g. cpp-2.95:
Code Sample
make install [gcc-2.95]
cd /opt/compile-3.3.5/bin
mv cpp cpp-2.95
cpp-3.3:
Code Sample
make install [gcc-3.3]
cd /opt/compile-3.3.5/bin
mv cpp cpp-3.3
gcc:
Code Sample
cd /opt/compile-3.3.5/bin
ln -s i486-pc-linux-gnu-gcc-2.95 gcc-2.95
ln -s i486-pc-linux-gnu-gcc-3.3.5 gcc-3.3


After loading the extension, user can do the following:
Code Sample
export PATH=/opt/compile-3.3.5/bin:$PATH
and
Code Sample
ln -s /opt/compile-3.3.5/bin/cpp-2.95 /opt/bin/cpp
ln -s /opt/compile-3.3.5/bin/gcc-2.95 /opt/bin/gcc
or
Code Sample
ln -s /opt/compile-3.3.5/bin/cpp-3.3 /opt/bin/cpp
ln -s /opt/compile-3.3.5/bin/gcc-3.3 /opt/bin/gcc

Since these commands are very simple, I think we probably don't need to have a script (for setting certain environment variables automatically) after all.

Also, I strongly suggest that we let the user add '/opt/compile-3.3.5/bin' to $PATH, rather than installing symlinks in '/opt/bin/' with user.tar.gz. Since there is a large number of binaries in '/opt/compile-3.3.5/bin/', this will avoid cluttering up '/opt/bin/' unnecessarily, and will probably also make Juanito's life easier.

What does everyone think?
Thanks!

Posted by ^thehatsrule^ on Jan. 23 2008,18:55
Quote
If so, we shouldn't have any libs in 'X11R6/lib/'.
I thought the two files 'libGL.so.1' and 'libGL.so.1.2' were left-over in 'X11R6/lib/' by accident, or perhaps they were later additions (but they were put in the wrong dir).
That's what I was talking about... that's a typical place where those X libs reside...
And the same goes for the symlinking standard: the .so and .so.<minor> are symlinked to the actual binary (which has the exact version).

Quote
Since these commands are very simple, I think we probably don't need to have a script (for setting certain environment variables automatically) after all.

Also, I strongly suggest that we let the user add '/opt/compile-3.3.5/bin' to $PATH, rather than installing symlinks in '/opt/bin/' with user.tar.gz. Since there is a large number of binaries in '/opt/compile-3.3.5/bin/', this will avoid cluttering up '/opt/bin/' unnecessarily, and will probably also make Juanito's life easier.
Well the script is for those who prefer to use it, i.e. to set up $PATH as indicated.  It'd be more of a convenience to do so than to retype everything each time you'd need it, plus more user friendly.

Is the include directory compiled in?  This could also set up other compiler flags.

Also, just having the gcc link may not ensure the version that you want to invoke.  You may need cc or set $CC (another use for the script)

Posted by lucky13 on Jan. 23 2008,19:35
Quote
If so, does anyone know how/why gcc-2.95 is safer than gcc-3.3 in this case, assuming that both compilers are able to compile the module cleanly?

The principle is matching a compiler (and c library) version throughout kernelspace so there aren't any surprises between the way one version handles certain things compared to a different version. I don't think 2.95 is inherently "safer" than any other version of gcc. Some of the differences between 2.x and 3.x and now 4.x may seem relatively minor, but there is enough variation that it can matter a lot (especially at kernel level).

Posted by stupid_idiot on Jan. 23 2008,19:41
^thehatsrule^:
Yes, I understand that is how symlinking works (in terms of library versioning).
What I meant was:
-- There are 2 straggling files in '/opt/compile-3.3.5/X11R6/lib/' ('libGL.so.1' and 'libGL.so.1.2').
-- All the rest of the X11 libs had been put in '/opt/compile-3.3.5/lib/'.
-- There is a symlink '/opt/compile-3.3.5/lib/libGL.so.1.2' which points to '/opt/compile-3.3.5/X11R6/lib/libGL.so.1.2'.
-- For the sake of neatness, I suggested that we move the actual library file '/opt/compile-3.3.5/X11R6/lib/libGL.so.1.2' to '/opt/compile-3.3.5/lib/' (after first removing '/opt/compile-3.3.5/lib/libGL.so.1.2'), and delete the symlink '/opt/compile-3.3.5/X11R6/lib/libGL.so.1', so as to keep everything in one place, and remove files which do not belong ('/opt/compile-3.3.5/X11R6/lib/' should logically be vacated of libs since these had all been relocated to '/opt/compile-3.3.5/lib/').

Hope this helps clear up the confusion. Very sorry for taking up so many pages!

Posted by ^thehatsrule^ on Jan. 23 2008,19:53
Quote (lucky13 @ Jan. 23 2008,14:35)
Quote
If so, does anyone know how/why gcc-2.95 is safer than gcc-3.3 in this case, assuming that both compilers are able to compile the module cleanly?

The principle is matching a compiler (and c library) version throughout kernelspace so there aren't any surprises between the way one version handles certain things compared to a different version. I don't think 2.95 is inherently "safer" than any other version of gcc. Some of the differences between 2.x and 3.x and now 4.x may seem relatively minor, but there is enough variation that it can matter a lot (especially at kernel level).

And another one is that 3.3 supports a newer version of the C standard.

I guess I'm not getting my point across on the libGL things - there may be older programs that look in this location... but I also see your point about the rest of the X libs not being there.... so I will stop here also because this thread is old and perhaps opening a new thread specific to this extension would be more appropriate.

Posted by stupid_idiot on Jan. 23 2008,19:58
Quote (lucky13 @ Jan. 23 2008,22:35)
The principle is matching a compiler (and c library) version throughout kernelspace so there aren't any surprises between the way one version handles certain things compared to a different version. I don't think 2.95 is inherently "safer" than any other version of gcc. Some of the differences between 2.x and 3.x and now 4.x may seem relatively minor, but there is enough variation that it can matter a lot (especially at kernel level).

OIC. I think I get exactly what you are talking about.
Thanks for the explanation!

Powered by Ikonboard 3.1.2a
Ikonboard © 2001 Jarvis Entertainment Group, Inc.