On Sunday 29 January 2006 10:26, Brian Green wrote:

Followed the 0.9.1 tar.gz sequence on http://synce.sourceforge.net/synce/tarballs.php until I had problems with LIBDIR after 'tar zxf libmimedir-0.5.tar.gz' (i.e. but, NOT 'tar zxf synce-libmimedir-X.X.tar.gz' (sic) ). Then couldn't make synce-rra (tried; despite it being optional)

So, revert to installing: /synce/synce-0.9.0-1.i386.rpm (i.e. http://prdownloads.sourceforge.net/synce/synce-0.9.0-1.i386.rpm?download) from article on synce at http://enterprise.linux.com/ via yast

Hi Brian, I can't access Sourceforge right now... it seems they're having technical problems or maybe a DOS attack... I'll check back later this evening. I've got some errands to run, anyway. - Carl

Carl Hartung wrote:

On Sunday 29 January 2006 10:26, Brian Green wrote: ... Hi Brian,

...

Please verify the sequence you referenced included the following packages and that I've marked their status on your system correctly:

synce-librapi2 - built and installed synce-synce - built and installed synce-dccm - built and installed synce-serial - built and installed synce-rra - failed to build libmimedir - built and installed synce-multisync_plugin - not built or installed synce-trayicon - not built or installed synce-gnomevfs - not built or installed rapip - not built or installed

Absolutely!

...

So, revert to installing: /synce/synce-0.9.0-1.i386.rpm (i.e. http://prdownloads.sourceforge.net/synce/synce-0.9.0-1.i386.rpm?download) from article on synce at http://enterprise.linux.com/ via yast

Did YaST issue any warnings or error messages when it installed the rpm package? Are you able to log in and work on the system as root from a console?

No warnings from YaST. SynCE could be started, but then failed, to complete communications with the iPAQ. Also a SynCE conduit started but as this didn't include an iPAQ option (i.e. only included other PDAs) I didn't explore it any further. BUT: All the root/"Session management error:"/"MIT-MAGIC-COOKIE-1" problems then became apparent. Hi Carl Finally, late yesterday, having exhausted all other options, I did a "dirty" install of my system (from my distro: floppies/CDs downloaded from SuSE). All's (i.e. 99%+) was working fine - only appear to have lost some codec's. All the 'root/"Session management error:"/"MIT-MAGIC-COOKIE-1"' were resolved ... So, just did a Yast System Update, rebooted, and the 'root/"Session management error:"/"MIT-MAGIC-COOKIE-1"' problems have returned ... SynCE installation temporary on hold ... Cheers Brian

Carl Hartung wrote:

On Monday 30 January 2006 05:09, Brian Green wrote:

...

Finally, late yesterday, having exhausted all other options, I did a "dirty" install of my system ...

...

Hi Brian,

Sorry to hear this. I /was/ going to help you repair the system...

For future reference, ...

... ...

Good luck & regards,

- Carl

Hi Carl I'm suitably admonished! And, I've paid penance by doing a clean install of the system (But note: I used, rebel that I am, the (incredibly QUICK - only deletes the pointers in the / ReiserFS partition?) format option during the install process. All is OK; with a significantly smaller O/S foot-print. However, the rebuild has taken some time - hence the delay in sending my thanks! I've thrown a couple of tarballs in (without problem ...) and even got CUPS and my all-in-one printer/scanner fully functioning again (my notes: remember to unplug/replug the USB to the printer after installing ...). But, ... 1) I'm really troubled by your "... moved to 10.0 from 9.3, ..." comment. Must I expect to do a repeat clean install when I move from 10.X to 11.0 followed by a tedious rebuild of all the functionality I've grown accustom to in the interim and just deleted? Is there no short cut? Some reference table of installed packages that can be archived before a format/clean install? Ditto, some reference table that might aid a roll-back (i.e. solution to my original problem) to some earlier working state? 2) I'm really (really!) frustrated with YaST2! I dutifully attempted to use YaST2 to install RPMs from a number of servers. However, some sources appear to be unsupported by YaST2. They are rejected during the "Software Source Media" option in the "Installation Sources" in YaST2. So my fix: download the RPMs to a local directory and get YaST2 to source from there ... Specifically, Amarok (yeah: KDE on a GNOME ... but I like some of it's functionality with Podcasts. Particularly being able to directly downloaded the MP3s to my player). Ultimately I have got this to work. YaST2 did install the RPM from the local directory. But: it required a combination of deleting the source, re-entering the source, restarting YaST2, ... etc etc ... YaST2 would see the RPMs, acknowledge the later version, check the dependencies, but then fail to install ... no such directory/no such file ... Is this a bug? Is there a work around? Why wont it refresh a local directory? ... Learnt a lot - thanks for your help, Brian (Tomorrow: back to SynCE ...)

On Wednesday 01 February 2006 11:11, Brian Green wrote: Hi Brian, Glad to see you are persistent!

I've thrown a couple of tarballs in (without problem ...)

I suggest you look into 'checkinstall,' which comes with the distribution. It can be used to build rpm packages from tarballs, so you can remove the software with YaST (or CLI rpm) if it breaks your system.

I'm really troubled by your "... moved to 10.0 from 9.3, ..." comment.

The more familiar you are with SUSE, the easier it is to *upgrade* from one release to the next. I've done it both ways and, IMHO, the "fresh" installs are a lot less work. If you use a separate /home partition, you can move '/home/you' to '/home/.you' and install "fresh" without formatting /home. This technique preserves your personal settings and data without modifying them. You can then migrate them into the newly created and pristine user directory at your convenience. You also might consider keeping a 'lab book' handy to record and keep notes on all your customizations. You'll outgrow the need for it in short order, if your present progress is any indication. :-)

2) I'm really (really!) frustrated with YaST2!

This is one of the oldest complaints about setting up installation sources in YaST. If you browse to a mirror and study a proper YaST source directory, you'll see a specific directory structure and files that are needed by YaST. You can't just dump a bunch of rpms into a directory and point YaST to it... it won't be recognized as a legitimate source because it lacks the proper format. The second oldest complaint about setting up installation sources in YaST concerns *how* you enter a server and installation source directory. The installation source will *not* be accepted if you use leading or trailing slashes. Correct example using my preferred mirror: server type: ftp (checkbox) server: mirror.mcs.anl.gov directory: pub/suse/i386/10.0/SUSE-Linux10.0-GM-Extra OK, Brian, the ball is back in your court. I'm sure you're going to be a very interesting and productive contributor to this list. regards, - Carl

On Thu, 2006-02-02 at 13:19 +0100, Carlos E. R. wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

The Wednesday 2006-02-01 at 18:36 -0500, Carl Hartung wrote:

...

...

I've thrown a couple of tarballs in (without problem ...)

I suggest you look into 'checkinstall,' which comes with the distribution. It can be used to build rpm packages from tarballs, so you can remove the software with YaST (or CLI rpm) if it breaks your system.

I concur :-)

...

...

I'm really troubled by your "... moved to 10.0 from 9.3, ..." comment.

The more familiar you are with SUSE, the easier it is to *upgrade* from one release to the next. I've done it both ways and, IMHO, the "fresh" installs are a lot less work.

I rather find the contrary is true, updates are less work for me... :-p

It depends a lot on each case, I suppose.

By the way, if you have a number of localized rpms, it is not a bad idea to have /usr/local in a different partition - same reason as for /home.

Also, I believe a full backup previous to either update or new install is mandatory. Should be.

Mandatory -no-, highly recommended -yes-.

...

You also might consider keeping a 'lab book' handy to record and keep notes on all your customizations. You'll outgrow the need for it in short order, if your present progress is any indication. :-)

Yes! Notes are very handy for future reference, it is easy to forget that obscure one line configuration change that made all the difference!

Note are your best friend when making a lot of changes. Makes it easier to back out changes that did not go as planned. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998

Carl Hartung wrote:

On Wednesday 01 February 2006 11:11, Brian Green wrote: ...

...

I've thrown a couple of tarballs in (without problem ...)

I suggest you look into 'checkinstall,' which comes with the distribution. It can be used to build rpm packages from tarballs, so you can remove the software with YaST (or CLI rpm) if it breaks your system.

Thanks for this - I also plan to explore the build utility build.rpm (Novell: cool solutions home) to build RPMs from tarballs. Any experience of this tool? The article, by Paul MacKay, ends with "... and use the rpm command:" Can I assume, as the article suggest it, that YaST2 uses the rpm command (but see below)?

If you use a separate /home partition, you can move '/home/you' to '/home/.you' and install "fresh" without formatting /home.

I'm not entirely sure what's going on here. Specifically, in my case, I have separate partitions for /, /home, and /local (and swap). I did a clean install to a freshly formated '/' partition, and I (had to - the settings were lost!) re-specified the mount points for the other partitions, in particular /home . However, I observed some minor quirky behavior when, for example, Firefox was next first run. It was initially a little confused, and only on the second run did it collect all the previous settings (a "feature" of this Firefox implementation?) ... But, (and back to the point) how would I restore my settings (Firefox say) from /home/.me to /home/me ? Sure, I should backup all my data folders (Personal warning: the last time you did a backup of your data prior to a major system upgrade you later discovered that the newly installed restore application could not read the backup data - it was incompatible ...) so, what's the best way to handle all the /.xx xx folders?

...

2) I'm really (really!) frustrated with YaST2!

This is one of the oldest complaints about setting up installation sources in YaST.

...

regards,

- Carl

OK: I've calmed down. YaST2 good, tarballs bad; YaST2 good, ... ; ... YaST2 does work: * download all the (extra) RPMs you need to a folder (eg. home/me/DownLoads/RPM) * Run YaST2 = 'Installation Source' (select and delete any previous RPM folder entry) - Add - 'Local Directory ...' - 'Browse ...' for your RPM directory - 'OK' - ignore the "There is no product info ,,," warning message with 'Continue' - 'Refresh On or Off' i.e. you want it 'Off' (this removes subsequent errors) - 'Finish' = Then click: 'Software Management' YaST2 will then access and refresh (if set) all the CD/DVD/ftp/http sources you have setup including your local RPM folder! All the dependency/availability checks etc are then done correctly by YaST2. Notes: 1) Don't delete RPMs from your download folder - they are still referenced by YaST2 and you may get subsequent dependency errors 2) If you add new RPMs to your download folder recreate the Source (delete any previous RPM folder entry in YaST2 and then re-enter it (i.e. as above)) I've used the above to get amaroK 1.3.7 working whilst all the/my ftp/http sources/mirrors still reference 1.3.1 Now to follow your advice and see what's required to fool YaST2 into being able to 'Refresh' the local RPM folder ... Cheers Brian

Joe Morris (NTM) wrote:

Brian Green wrote:

...

Now to follow your advice and see what's required to fool YaST2 into being able to 'Refresh' the local RPM folder ...

No black magic needed. In Yast Sources, simply choose your local directory and choose Edit>Refresh. I also use a directory for downloaded rpms as well as have a source set up for those I build.

But, Joe, (and hence my work-round) whenever I did a refresh all the later added RPM's are not referenced by YaST2 and/or YaST2 gives an error (which you have to acknowledged ...) that the directory cannot be refreshed. A problem with my configuration?

Carl Hartung wrote:

I use the YaST interface as follows:

- YOU (online update) to download and install official SUSE patches plus optional bits and pieces distributed through by SUSE through YOU.

- Install and Remove/Software Management for original SUSE package repositories (mirrors), including 'unofficial' supplementary directories.

I use the CLI "apt" system (another "bolt-on" rpm interface) to access community-maintained repositories with packages from "third parties" like Packman.

I'm curious why you use apt for this instead of just adding packman as a source in YaST?

The whole point of these systems is to allow one to define on-line sources at the start and take advantage of them without having to deal with manual downloads, installs and dependencies.

Absolutely :) Cheers, Dave

Brian Green wrote:

But, Joe, (and hence my work-round) whenever I did a refresh all the later added RPM's are not referenced by YaST2 Did I understand what you just said, that you added rpms AFTER you refreshed, and these were not picked up? If that is what you said, then obviously you need to refresh AFTER you add files for them to be found by Yast, and it does work that way for me (I use it often) in 9.3 x86_64 and/or YaST2 gives an error (which you have to acknowledged ...) that the directory cannot be refreshed. A problem with my configuration? When I refresh a directory in Yast>Change Source of Installation, it does popup with an informational message (which I did read the first time, but forget now since that was months ago), but it has always worked as expected for me.

-- Joe Morris Registered Linux user 231871