Rajko M wrote:

Basic for MiniSUSE is that it is intended for machines with small memory footprint (64-128MB RAM) even lesser if possible. The desktops were first in mind, but small low traffic servers, are good idea too. They don't need GUI for applications, They need very basic OS and few software packages.

Look at http://en.opensuse.org/MiniSUSE#Usage Profiles

there is effectively a great interest for mini personal servers, specially with second hand faulty laptops. My own is a laptop with a broken screen, no more battery nor fan :-( I don't need screen 99% of the time (and can connect a CRT the other 1%), I have got a $10 UPS (and a new $20battery for it) and a big fan glued under the laptop box (with a large hole for air flow :-). this one is a PII with 256Mb ram, runs 10.0 easily, but I wonder if I wan 10.2 that 256Mb ram should be just. and I have also a sublaptop P233 that had initially 12Mb ram, then 80Mb and hopefully I was given for free a 128Mb chip, so I have now 146Mb ram (most laptops have one soldered ram chip and so can only change one) This last latop is completely new (that is never used), fitted with 12Gb HD and all PCMCIA + USB it can't boot the pcmcia cd, so the various hacks I had to setup. and I know of countries with 386 computers (but there, no hope, Linux on a 386 is only a challenge) :-) may be the first thing I will do is to collect various infos on the way of booting/installing with a machine that can't boot cd. The info IS on the wiki, but may be not so easy to find. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Rajko M wrote:

Not sure what do you mean:

look at the minisuse page :-) there is much data jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Hi! On 7/9/06, Peter Flodin wrote:

I see that it could be the base of many custom versions of SUSE, a MythTV SUSE, a thinclient SUSE, router SUSE, etc.

I just installed 10.1 on my VMware as test. This time I wanted to create a small installation. I'm not exactly a new Linux or SUSE user, but still I do not know all the packages that I should select in all cases (there are a few of them). So I was thinking that the installation gives some predefined selections - so let's test those! The choices were about these 1) Gnome 2) KDE 3) Minimal X support 4) No X Not much choices... I chose minimal X support (because, YaST is the reason why I use SUSE - yes, it can be used from the comman line also). The end result: I was using more than 800Mb of disk (probably close to 900). Later on at the installation, I chose the new network managing system (to see how it works). Suddenly it installed KDE base libraries. Now after everything is done, I'm already using 1.2Gb of disk! The bloat is here somewhere! So, I'm very interested in miniSUSE. But can it be implemented just by creating number of different predefined package selections to start from at installation time. You could have things like: 1) Full KDE 2) Minimal KDE 3) Minimal X with other than Gnome/KDE 4) Home server (nfs+samba+ssh+apache+minimal X) 5) Home server with minimal KDE 6) Old computer 7) Laptop with KDE 8) Old laptop with lightwight X 9) MythTV 10) Thinclient 11) Firewall router 12) ... That way you would not have to make another distribution of it, but have the mini-ideas included in the normal SUSE distribution. I think the integration would be easier, and people the selection would then be easier to grow according to everybody's needs. Of course, installation media needs to be rethought. But maybe the minimal installation packages could be on the first CD and rest on the other ones. Then give a warning if some "non-mini" is selected that you need another media or pointer to internet source. And for the current mini/one-CD/internet-installation, there would be no changes except having more predefined packages choices. What do you think? -- HG. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Hi! On 7/22/06, jdd wrote:

HG wrote:

...

But can it be implemented just by creating number of different predefined package selections

this should be possible with the new package management system.

the problem I see is that dependencies are written in rpm's by dveloppers of the application, not SUSE. So at first this may be only available for packages homed in the openSUSE build system :-(

What do you mean? Do you mean that SUSE does not have control over which packages some other package require and therefore... I don't know what? Do you mean that the dependencies from average program created by average developer would very quick introduce all the bloat back? What I'm hoping with my proposal is that the SUSE system would be the same for all installations, but at the installation time you could more easily change the role of the particular SUSE system you are installing. After that, many will install more packages and whatever dependencies those might have need to be handled. But this would be done with the normal SUSE way (whatever that will be) using the repositories with all the packages for full SUSE system. Yes, by starting from minimal installation, you could end up with very bloated system. As an example, I'm hoping to build a file server to my home. Now freeNAS would be perfect OS for that, except that I'd like to have SSH and HTTP servers there also. Not to talk about lenghty SUSE downloads (with torrents) happening there and not on the desktop. So I can not start with freeNAS and as I'm only familiar with SUSE, I'd like to do it with SUSE. Anyways, this is just one scenario. -- HG. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

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

HG wrote:

...

4) No X

with 10.0 I could strip this under 500Mb, with some work. It's much too big (I already installed debian in 180Mb)

The reason is mostly that Debian's packaging policy is to make a very large number of very small packages and subpackages. It really isn't simple. On one hand, from one piece of software (an application, a library, ...), you could have it split into several subpackages, e.g. the shared library (that is required by other applications or libraries), the files needed to compile against that library (the well-known "-devel" or "-dev" packages), additional binaries into yet another subpackages, etc etc... The advantage of that approach is that you more or less only install what is needed. As an example, if you install some application that only requires the shared library from another package, you'll just install that, and not the devel files, additional binaries, etc... Note that the split between libXXX and libXXX-devel is typically done on pretty much any distribution, and also on SUSE Linux, although not always. But that's a different topic, I won't rant about that now ;)) On the other hand, when you really split features or files into many small subpackages, you'll have a lot more dependencies to solve and handle. Actually, it's not *really* a problem. People complain about "dependency hell", but I really don't understand... never, ever install RPMs "manually" (with rpm -i/-U/-F) unless you really know what you are doing. Always use a package manager (yast2, zmd, rug, smart, apt, yum, whatever), as it will nicely resolve the dependencies for you and install everything that's needed. Personally, I totally disagree with people who complain about a lot of packages and dependencies (except that, in theory, the more dependencies, the more complex), but it's like that, there are people who don't like it. Well, all that just to explain that it's a sword that cuts both ways: if you want smaller systems, you need smaller (and more) subpackages, but there are people who don't like that and will complain.

...

But can it be implemented just by creating number of different predefined package selections

this should be possible with the new package management system.

This has been possible since a very long time with YaST2 ;) Those are just .sel files: http://ftp.belnet.be/pub/mirrors/ftp.opensuse.org/opensuse/distribution/SL-1...

the problem I see is that dependencies are written in rpm's by dveloppers of the application, not SUSE. So at first this may be only available for packages homed in the openSUSE build system :-(

Actually, it's exactly the opposite. Of course, when a developer of an application choses to use GTK, GNOME, QT or KDE libraries (or fltk, or whatever toolkit), then you have a dependency on those shared libraries. That's inevitable and, frankly, you cannot expect someone to write e.g. YaST2's GUI with plain Xlib instead of using a high-level toolkit (like QT). The only thing that could be done is to split those library packages into more, smaller subpackages to really only install the few files that are needed - no more, no less. But that's also pretty tedious to do. Anyhow, it's pretty much simplicity vs disk space ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEwhZpr3NMWliFcXcRAuoBAKC6t3nz32id/tVM6amERu1ZvjiX8gCgjqkQ 6YmVMZeGS6gNPjLFkuk2UBg= =7f2j -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

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

Pascal Bleser wrote: ...

...

hell", but I really don't understand... never, ever install RPMs "manually" (with rpm -i/-U/-F) unless you really know what you are doing. Always use a package manager (yast2, zmd, rug, smart, apt, yum, whatever), as it will nicely resolve the dependencies for you and install everything that's needed.

not right. The package manager know only about the libraries it have into it's own database, not other ones. most app I need to compile rely on the very last library that yast don't know of.

The package manager only knows about the packages that are in its list of repositories, indeed. That's pretty much the only issue with "dependency hell": if installing a package requires another package that's in another repository (e.g. if you install my amarok packages, they require libxine1 from packman). Now, needing the very latest version of a package is a totally different issue, that's not "dependency hell" (or at least not my understanding of it ;)). That's something that we "community packagers" (Packman team, various suser-* repositories on gwdg.de, other in the Build Service, my repository, ...) are trying to address, by providing the very latest version of many libraries and applications. It's not always easy to find the very latest version of some piece of software as a package. Either it's maintained in my repository (or Packman, or a suser-* repo, or in the Build Service, or ...) and you'll most probably find the latest version there, or it's not. It's not much better with other distributions btw. Yes, Debian and Ubuntu have huge repositories where you can find almost anything, but they often don't have the latest version. Source-based distributions (like Gentoo) seem better suited for that at first hand, but then again you have to compile *everything* yourself, and possibly recompile tons of dependencies and other things in order to get that version of a library. The authors of the software usually provide packages for Debian and/or Fedora, rarely for SUSE Linux (unfortunately). But then again, they are usually rather good at writing software but not necessarily very good at packaging and from what I see most of the time, those packages made directly by the authors themselves are not very good, not worth much more than a tarball with configure && make && make install.

When the web page of the app author is well done (for example the kdenlive one), each needed library is exactly listed with the link to it, it's enough to go and take it. but if this is not done, one need to compile (or run rpm, this is sensibly the same), look at the error message and go on.

Mhhh, well, it's not the same. When you build an RPM, rpmbuild automatically scans resulting binaries for dependencies on shared libraries (e.g. libssl.so.0) and script interpreters (e.g. /usr/bin/python). Those automatically discovered dependencies are put (as "Requires") into the resulting RPM package. If you install a package that requires libssl.so.0 and you don't have that library provided by any installed package, RPM will complain and abort the transaction (unless you specified --nodeps, but that's a really bad idea). Package managers (like yast2, rug, smart, apt, ...) will resolve such dependencies (e.g. libssl.so.0 or /usr/bin/python) onto packages and understand that they also have to install e.g. openssl or python. Finding out about dependencies to *build* something from source is a totally different thing, I wasn't referring to that (usually, typical end-users don't do that).

so: use Yast, and thank SUSE for having one of the largest available repository or be prepared to face dependency problems

Well, kindof, you are talking about building something from source, not about resolving dependencies when you install a package ;)

...

This has been possible since a very long time with YaST2 ;) Those are just .sel files:

there are no more sel files in 10.1 (or none that yast can create)

So, why are there still .sel files here: http://ftp.belnet.be/pub/mirrors/ftp.opensuse.org/opensuse/distribution/SL-1... ? ;)

and I think you miss the point (sorry, probably my fault).

Many developpers makes (or autoconfig) from they own computer. They have on it a bunch of libraries. The tools include in the definition file all the libraries that could ever be used.

Ok, so you really mean some dependency definition for *building* stuff from source, right ? That's the whole point of having packages and RPM .spec files ;) Usually those are not made nor maintained by the authors of the software, unfortunately.

* it's a good idea to have a gnome menu on a kde app? the tool note gnome as needed * there is a gui front end to your console app? the tool makes X and kde needed * I never use ogg, but want mp3, why do amarok install ogg libraries? (because it don't know what I want)

Sounds to me like you should use Gentoo instead of SUSE Linux. But Gentoo has other problems.

all this I _have_ encountered Yast is not at present time sufficiently fine grained to cope with this.

YaST2 has absolutely nothing to do with that. What you are referring to is how the packages are made (the RPM .spec files), not how package managers work. If you don't have a lot of subpackages in the first place, no package manager will be able to be as fine grained in the package selection anyway.

I hope the new package system will be able to know that some dependencies must _not_ be solved for some profile.

Dependencies must *always* be resolved, especially on shared libraries. Let's take your amarok/ogg example. You get an amarok RPM that has been compiled with Ogg/Vorbis support (because almost everyone wants that). That means the amarok binary or one of its own shared libs (libamarok.so.xxx) requires symbols from libogg.so.xxx and libvorbis.so.xxx If you start amarok and don't have libogg.so.xxx and libvorbis.so.xxx installed, the runtime linker (ld.so) will complain about unresolved symbols and will *not* start amarok. That's how it works, and there is no way to circumvent that. For some applications, it's possible to do that though, because they externalize their features/capabilities as plugins (usually shared libraries loaded with dlopen() or libtool/libltdl) and are smart enough to disable features if the corresponding plugin could not be loaded. But that's really the exception, and not the rule. 90-95% of applications don't work that way and burn dependencies into their binaries at compile time (usually depending on what you pass to the ./configure script), not at runtime.

in fact libraries should be split in more catagories: * absolutely necessary to run the app (gcc :-) * mandatory for some functions, but not for others (codecs, desktops)

and I think this will need some work with the packagers. If the build service is as attractive as I feel it will be, the problem will be much simpler.

I'm afraid you are dreaming of something that is not technically feasible :\ cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEwqUYr3NMWliFcXcRAlZOAJ9kT79g0R4ql7pQ7xksmmUxBv506ACfWKO6 Qwo13efJ/OzNY2MJcASsDXk= =/LOH -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Rajko M wrote:

Pascal Bleser wrote:

...

jdd wrote:

...

...

Pascal Bleser wrote:

<snip>

...

Sounds to me like you should use Gentoo instead of SUSE Linux. But Gentoo has other problems.

The basic problem with Gentoo is that any major change locks computer for a long time until compilation is done. No one that uses Gentoo is rushing to get the newest KDE, just to try.

Right. And their dependency management doesn't work that well. But on Gentoo, as you build (almost) everything from source yourself anyway, you have a very fine grained (build/compilation) configuration of what features you want and what features you don't want. As an example, if you don't want Ogg/Vorbis anywhere, you can define that more or less globally for your system. But when you change such a "USE flag" (how they like to call it ;)), you might have to rebuild almost all your distribution (that's not a cup of coffee, that's usually 2 or 3 days without a working system). So, yeah, fine-grained control over features you want to be compiled in or not, but Gentoo has its own share of problems and most importantly, it requires a *lot* of work to tweak and maintain your system. (note, this is not a rant against Gentoo, they have a very healthy community and for certain scenarios, it is a very good solution)

...

...

...

all this I _have_ encountered Yast is not at present time sufficiently fine grained to cope with this. YaST2 has absolutely nothing to do with that.

I'm afraid that you are right. It has little to do with YaST. We can tweak selections and achieve some improvements, but to make SUSE linux really slick, we have to find the ways to overcome rpm packaging limitations.

I wouldn't say it's rpm packaging limitations. It's how the .spec files are written for SUSE Linux (or miniSUSE). Take an example: kdelibs3. kdelibs3 contains all the basic KDE libraries and core services (note that normally you need at least both kdelibs3 and kdebase3 to have a working KDE desktop, as kdebase3 contains more stuff about konqueror, etc...). The package weights 120MB of disk space: $ expr $(rpm -q --queryformat="%{SIZE}") / 1024 / 1024 119 If you look at all the files it contains (rpm -ql kdelibs3 | less), you can see that there's a lot of stuff in there, and you most probably don't need all that if you just install an application that requires KDE shared libraries (to resolve its symbols through the dynamic loader, as explained in my previous mail) and you use, say, a GNOME, XFCE, fluxbox desktop. Say you use fluxbox or XFCE as a window manager, but you want to use amarok. amarok has been built against shared libraries that are contained in kdelibs3 (amongst other things, such as xine, etc... - but let's just consider the KDE dependency for the sake of simplicity). Let's have a look at amarok's shared library dependencies (remember, I'm only showing the QT/KDE dependencies here): $ ldd /opt/kde3/bin/amarok | cut -f 1 -d " " [...] libkdecore.so.4 => /opt/kde3/lib64/libkdecore.so.4 libqt-mt.so.3 => /usr/lib/qt3/lib64/libqt-mt.so.3 libDCOP.so.4 => /opt/kde3/lib64/libDCOP.so.4 libkdefx.so.4 => /opt/kde3/lib64/libkdefx.so.4 For RPM (and YaST2, rug, smart, apt, ...), that means you also have to install the following packages: $ rpm -qf /opt/kde3/lib64/libkdecore.so.4 kdelibs3-3.5.3-7.1 $ rpm -qf /usr/lib/qt3/lib64/libqt-mt.so.3 qt3-3.3.6-37.1 $ rpm -qf /opt/kde3/lib64/libDCOP.so.4 kdelibs3-3.5.3-7.1 $ rpm -qf /opt/kde3/lib64/libkdefx.so.4 kdelibs3-3.5.3-7.1 We can automate that somewhat ;) $ ldd /opt/kde3/bin/amarok | cut -f 3 -d " " | while read lib; do \ [ -n "$lib" ] && rpm -qf "$lib"; done \ | sort |uniq Here's the output, again, only considering QT and KDE: kdelibs3-3.5.3-7.1 qt3-3.3.6-37.1 So when you install amarok, you'll get the full kdelibs3 (120MB) and qt3 (56MB) packages onto your system, although not everything inside those packages is needed just to run amarok (on a non-KDE desktop). The "solution" to solve that "problem" is to split the kdelibs3 RPM package into several smaller bits, e.g. one package that really only contains libkdecore.so.4 + libDCOP.so.4 and another one that only contains libkdefx.so.4, as those are most often required by KDE applications. Same for qt3: have a package that only contains the core library (libqt-mt.so.3) That way you would only install 58 MB for the KDE/QT dependencies: - - libkdecore.so.*: 9MB - - libkdefx.so.*: 692K - - libqt-mt.so.*: 49MB So much for the technical background. Note that I'm really, really oversimplifying here, and in practice it is much more complex to find a solution to that "problem". The more packages, the more complex the build and package management becomes. Ultimately, you'd end up with one or two files per subpackage, and I guess the system could become really hard to manage. Also, there are a lot more dependencies to consider, I really only kept the KDE and QT ones here, but you also have Xorg, libpng, zlib, GCC C++ runtime libs, and much more stuff that amarok loads through plugins (MySQL client libs, PostgreSQL client libs, sqlite3, ...). Keep in mind that this is also pretty much a case by case analysis, and that a lot of time and effort must be spent into looking at such packages, which files are usually required by most other packages, which files are necessary to make a KDE application work (e.g. you might also need a few .desktop files, a few binaries like knotify, etc... to actually make amarok work properly).

The miniSUSE is a project that needs a lot of data, before it can produce real improvements, it can influence application writing and packaging philosophy as we know it today. What we need is more heavy weights like you that have deep understanding of present status and possible ways to go around.

Well, yes, in theory. You can effectively improve the situation through RPM packaging, but that doesn't solve the other issue I explained in my previous mail (see below).

<snip>

...

For some applications, it's possible to do that though, because they externalize their features/capabilities as plugins (usually shared libraries loaded with dlopen() or libtool/libltdl) and are smart enough to disable features if the corresponding plugin could not be loaded.

But that's really the exception, and not the rule. 90-95% of applications don't work that way and burn dependencies into their binaries at compile time (usually depending on what you pass to the ./configure script), not at runtime.

Nice point.

To "solve" that, you'd have to tell hundreds of software developers to completely change their sources, to try to externalize dependencies through plugins. Understand that it's often a lot more complex to implement an application that way (and sometimes it's even not feasible at all). More complexity means more error-prone... which means more bugs and less quality. IMO that's just not possible.

That points one of the ways to overcome present status, more smart applications, that adjust themselves to existing environment. To cut on load time, check has to be done only if system indicates new installed plugins.

Hm? "check" ? what check ? Applications must be written to load features as plugins. e.g. MySQL client support for amarok amarok should try to load every .so file that's in /opt/kde3/lib64/amarok/ If you don't have the necessary MySQL client shared libraries installed, the dlopen() call on e.g. /opt/kde3/lib64/amarok/mysql.so will fail The application must be so smart to say "ok, could not load that plugin for some reason, so just ignore it and don't have that feature". That sounds really simple, but it isn't, it really isn't...

To cut on multitude of ways that kind of checkup can be done and the number of ways that plugin communicate to main application, we need operating system to take over setup procedure and include some standard way for communication between processes.

Ewww... stop stop stop ;) You are running into the wrong direction here ;) The kernel has absolutely nothing to do with that. The necessary stuff to work with plugins is already available: it's dlopen() (or libltdl from libtool, does the same in a slightly simpler way). There's no need for "communication" either.

<snip>

...

I'm afraid you are dreaming of something that is not technically feasible :\

Not in a short term, but set as a goal it will produce results. Linus dreaming is what brought Linux to us :-) All we have to do is to continue the dream.

Well, yeah, you could also dream of having a car that drives 800 km/h, has room for 5000 liters of luggage, and all that for 100 EUR, but it's still not feasible - at least it's not realistic ;) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEwzGJr3NMWliFcXcRAjTLAJ9l65r2cyfnAp30QF0pa5QsrshfrQCfXYZf XL9rvVFZom89LUEQ46wp1cw= =Tlcc -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Pascal Bleser wrote:

I'm afraid you are dreaming of something that is not technically feasible :\

technically, all is feasible :-) - just a matter of willness. and I think this is very important. I have now ~ 8Gg of SUSE Linux installed and I'm sure 75% is unusefull. this must be addressed. of course I won't say how, but I'm pretty sure this will need a collaboration between developpers, packagers and distribution makers. Your comments seemed very acurate, thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org

Pascal Bleser wrote:

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

jdd wrote:

...

Pascal Bleser wrote:

...

I'm afraid you are dreaming of something that is not technically feasible :\

technically, all is feasible :-) - just a matter of willness.

Sorry, don't take this personally, but that's the dumbest statement in IT. No, technically, not everything is feasible.

it's possible, others do :-() Knoppix, DSL, do a great step in the direction we try to go. Debian do. so don't say it's impossible. the people who programmed busybox did a great job shrinking the stuff. I used to work with mulinux, even with X and three floppies. it's not the way SUSE worked until now, so it wont be easy. I think miniSUSE is far from asking a so important shrinking, but working in that direction could also slower the movement to always more than is very visible (not only here :-). of course building miniSUSE will need some compilation :-) (for us, not necessarily for the user) http://lwn.net/Distributions/ jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-help@opensuse.org