[opensuse-packaging] /etc/sysconfig metadata documentation
Hi, I wonder if there is any documentation or specification about the metadata comments in /etc/sysconfig files. The only bit of documentation I could find is the fillup man page, but it doesn't say anything useful. What I'm looking for is information about the following things: ## Config: ispell ## ServiceRestart: bluetooth ## ServiceReload: autofs ## Command: /sbin/mkinitrd ## PreSaveCommand: /sbin/rcsyslog status /sbin/rcsyslog stop In particular: - What exactly do these keys mean; - Are there any other keys not mentioned here; - How are they applied, i.e. only to a specific sysconfig setting, or all settings within a specific file or path, or something else, can this be influenced somehow, e.g. does it make a difference where these keys are placed within the sysconfig files. - In which order are these things executed? Is the order fixed or can the packager influence it according to the order it is written in the sysconfig file? The reason I'm asking is that I think several sysconfig files have metadata which are not up to date or not complete. E.g. many SuSEconfig modules have been removed without a replacement, so the sysconfig metadata can be removed as well. Others have been replaced, but without reflecting the change in the /etc/sysconfig files. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] brp scripts in autobuild
Hi, from various discussions in bug reports I know that brp scripts for the following are installed in autobuild: - check whether .la files have an empty dependency_libs line - check whether .la and .pc files have references to the build root - check whether .desktop files have all their icons installed Are these scripts publicly available somewhere? They are not distributed with rpm, build or osc and I could not find them anywhere else either. If not, would it be possible to publish these (and others, if present)? Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] brp scripts in autobuild
and others, if present
The others are (or were):
brp-check-buildroot
brp-check-la
brp-desktop
brp-noexecstack
brp-pie
brp-rootfs (what does this do?)
brp-rpath
brp-strip-debug
brp-symlink (this one is present in rpm)
brp-tcl
Other interesting scripts seem to be applied after the build:
... checking for files with abuild user/group
... testing for empty debuginfo packages
... testing for serious compiler warnings
... checking filelist
... testing for suid/sgid and world writable files
... comparing permissions with standard set (/etc/permissions{,.secure})
... testing for pre/postinstall scripts that break patchrpms
... testing for modified permissions
... testing devel dependencies required by pkgconfig .pc files
... testing devel dependencies required by libtool .la files
Andreas Hanke
--
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Proposal: Any rm in .spec %install must be commented
Hi, With a high noise level around it, even the good comments become useless. So -- let us fight against those comments, that repeat just the obvious. But please don't exaggerate and continue adding good comments ;-) Yet another real-world example: https://bugzilla.novell.com/show_bug.cgi?id=238090 Useless and harmful/buggy .desktop file that must be removed, but without a comment, I'm pretty sure it would sooner or later come back when someone removes the removal. Andreas Hanke -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] no cdrecord
Hi, In a separate deprecated package cdrkit-cdrtools-compat. Does it get installed in the update case? In most cases it should be, because packages which need the cdrecord symlink should require cdrecord and this is only provided by cdrkit-cdrtools-compat. E.g. if k3b is installed, it requires /usr/bin/cdrecord and since cdrkit-cdrtools-compat is the only package which provides this, the depsolver has to install it. If this does not work, it's a bug. There is a possible case where the package will not be installed on upgrade: If the user had a minimalist system without any package that requires cdrecord (no k3b, no nautilus-cd-burner, no xcdroast etc.), cdrecord will be upgraded to wodim without installing cdrkit-cdrtools-compat. If it is desired to install cdrkit-cdrtools-compat even in that case, a split provides can be used. Andreas Hanke -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Where can I find the package nss-mdns?
Hi, avahi-daemon and avahi-dnsconfd don't require it. But for example avahi-bookmarks (from the same package) expects, that .local domain is resolved (otherwise you will end with unresolvable domains). In this case it is a circular dependency. Not actually in the rpm Requires sense (because nss-mdns does not have Requires: avahi), but http://0pointer.de/lennart/projects/nss-mdns/ says: nss-mdns will not work unless Avahi is running! That makes Avahi essentially a hard dependency of nss-mdns. If the packages really need each other, it might be a better idea to ship them in the same source tarball (but that would have to be handled upstream). Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Where can I find the package nss-mdns?
Hi, Where can I find the package nss-mdns? You cannot find it anywhere, this is a new package that is still missing from the factory tree. Since quite some time actually, at least since 20070221. That's when avahi started to require it: http://lists.opensuse.org/opensuse-commit/2007-02/msg00716.html Furthermore, the avahi.spec file says: # Not really required, but many tools expect nss-mdns installed: Requires: nss-mdns I wonder why a package should be allowed to require a package that is not really required... Anyway, you don't need to update avahi in order to verify whether the digikam crash is fixed because avahi has not even been touched in order to fix this. The problem has been fixed by removing mDNS support from libgphoto2. Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] kernel update
Hi, Since last month I upgrade/update my system with smart 3 or 4 times,but my kernel(you can see on my signature)is the same... There are any problem with kernels now? Thanks and regards There are kernel updates, but smart doesn't see them because they have version numbers that make smart think the kernel has been downgraded. The kernel version you probably have installed is: kernel-default-2.6.20_rcX The current kernel is: kernel-default-2.6.20 The latter is newer, but the former looks newer to the package manager because the version comparison algorithm considers the longer version newer if there is no difference between two versions other than one of them being longer. In short, you have to update the kernel package manually: sudo smart install kernel-default-2.6.20 Andreas Hanke -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
Hi, While I agree with many of your points, this argumentation is flawed. If libabc is not directly used (i.e. in the deplist without a relocation into it) then any API change in libabc can't break the application. If it can break the application then by definition it's not unused. Additionally, if it breaks the API, then probably some of the libraries directly depending on it, which are used by the application (otherwise the useless dep wouldn't exist), will break too. That breakage will occur no matter if the useless deps are removed or not. Hence: removing the useless deps will not magically make API breakages go away. What happens if libfreetype.so.6 becomes libfreetype.so.7 and is really not used? In such a case it can indeed break dependent packages unnecessarily. Or am I missing something? Andreas Hanke -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
Hi, just in case someone is still interested: Some packages have really creative and funny ways to defeat dependencies that are purely artificially generated by .la files. Bizarre example: http://svn.gnome.org/viewcvs/pango/trunk/sanitize-la.sh?revision=556view=markup http://svn.gnome.org/viewcvs/pango/trunk/pango/Makefile.am?r1=551r2=556 Andreas Hanke -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] .la files and dependencies, again
Hi, Some packages have really creative and funny ways to defeat dependencies that are purely artificially generated by .la files. just before I forget, the explanation why they are doing that: It's _very much_ desired to not expose the rather fragile freetype ABI via pango, but the .la files do it anyway, even if static libraries are not even built. Unfortunately it doesn't actually work because nowadays, pango integrates with cairo and cairo.la has /usr/lib/libfreetype.la in its dependency_libs line. The result is very sad: # ldd -u -r /usr/bin/* 2/dev/null | grep libfreetype\\.so\\.6 | wc -l 200 200 executables that possibly break if freetype breaks ABI although they don't have to. Andreas Hanke -- Feel free - 5 GB Mailbox, 50 FreeSMS/Monat ... Jetzt GMX ProMail testen: www.gmx.net/de/go/mailfooter/promail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] python-elementtree in Factory
Hi, I've noticed that python-elementtree was removed in Factory. Will it be returning? Probably not, as it's now part of the standard library. # rpm -ql python-xml | grep -i elementtree /usr/lib/python2.5/xml/etree/ElementTree.py /usr/lib/python2.5/xml/etree/ElementTree.pyc /usr/lib/python2.5/xml/etree/ElementTree.pyo /usr/lib/python2.5/xml/etree/cElementTree.py /usr/lib/python2.5/xml/etree/cElementTree.pyc /usr/lib/python2.5/xml/etree/cElementTree.pyo It's a very popular module that's used in a lot of Python projects, including osc. Is it possible to fix these projects to use import xml.etree instead of import elementtree? Andreas Hanke -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Gnome 2.18
Hi, Are there any plans to bring the latest gnome (at this moment it should be around 2.18 beta2. 2.17.91 started going into Factory late last week, expect it to be hitting the servers real soon. OK, nice, but I assumed you wanted to get rid of /opt/gnome before doing version upgrades? Right now at least the following packages are still using it: NetworkManager-openvpn-gnome seamonkey jpilot-Backup NetworkManager-vpnc-gnome seamonkey-mail OpenOffice_org apparmor-admin_en Not all of them are GNOME packages, but some of them are, they should be fixed. Andreas -- Feel free - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: www.gmx.net/de/go/mailfooter/topmail-out - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST problem after factory upgrade
Hi, I also notice that coreutils is also missing stuff in /usr/share/locale/en_GB, so apps like acroread and some firefox plugins continuously repeat a message expr: syntax error and fail to open. Forget it, there are no .mo files for en_GB because the English strings are hard-coded into the binaries. Only very few packages have en_GB translations, only if it would substantially differ from the default strings, and a missing translation is not a bug. The problem with acroread was pointed out to me by a friend in the USA and I got exactly the same here in the UK when I tried it - the expressions in /usr/X11R6/bin/acroread look sane looking at man expr. Regards This problem has nothing to do with missing .mo files either. It's a simple shell scripting/quoting bug. Fix: http://distro.ibiblio.org/pub/linux/distributions/rootlinux/rootlinux/ports/more/acroread/acroread-expr.patch There is already a report this, so there is no need to report it in bugzilla. Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST problem after factory upgrade
Hi, YaST comes up but won't open anything - hardware, software, Installation Sources or anything else https://bugzilla.novell.com/show_bug.cgi?id=238031 qt-3.3.7-24 is missing /usr/lib/qt3/translations/qt_en.qm. No, this file is not missing, it just doesn't exist. Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zenupdater unable to solve dependencies
Robert Schiele schrieb: Huh? And how do you expect people that have the 64bit Firefox from the installation get their security update then? That doesn't really matter after having it offered for more than 2 weeks, by now most x86_64 users have been upgraded to MozillaFirefox.x86_64 anyways, so this question is obsolete now. There is already a notable increase in complaints about no longer working plugins. And there's definitely something seriously wrong in zypp about biarch updates, see https://bugzilla.novell.com/show_bug.cgi?id=232413 for another case. The zypp smoothly updates biarch packages without changing the architecture thing simply doesn't work. In doubt, it doesn't update anything at all. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zenupdater unable to solve dependencies
Dominique Leuenberger schrieb: I have a Mozilla Firefox 64bit edition installed on my Box and the flash plugin works great in there (flash is known to exist only as 32bit). I have the nspluginwrapper installed (from repos.opensuse.org/mozilla) and this works just great. nspluginwrapper is not yet part of the (official) distribution. Distributing MozillaFirefox.x86_64 is not a problem at all, but if so, it should be done *consistently*, i.e. installed by default together with nspluginwrapper. The current situation is different (and illogial). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zenupdater unable to solve dependencies
Hi, In your case I suspect you installed a 64bit MozillaFirefox-translations and the 32bit MozillaFirefox and it blows up a bit. No. Mixing MozillaFirefox and MozillaFirefox-translations of different architectures is perfectly valid from the dependency point of view and cannot be the reason for this breakage because the dependency between the two packages is implemented in such a way that the depsolver completely ignores the architecture difference. MozillaFirefox-translations requires MozillaFirefox of any architecture, provided by MozillaFirefox of any architecture. There is no difference between i586+i586, i586+x86_64, x86_64+i586 and x86_64+x86_64 dependency-wise. I suspect it is just a case the updater does not handle yet. Sorry, this is a real bug and a damn serious one. It happens whenever a package uses Provides+Obsoletes and is available in a better architecture than the currently installed one. MozillaFirefox.x86_64 obsoletes MozillaFirebird of any architecture, provided by MozillaFirefox.i586. Therefore, MozillaFirefox.x86_64 is technically a newer version of MozillaFirefox.i586 and the architecture difference is completely ignored. The result is that the depsolver tries to install two architectures of MozillaFirefox. i586 because that's the direct update to the regularly installed package and x86_64 because that's also an upgrade via Provides+Obsoletes MozillaFirebird. This will of course fail. MozillaFirefox.x86_64 has to disappear from the update repository. Unfortunately it's there since 2 weeks already, making it a bit difficult to resolve now because users might have already installed it via other tools or manually. Andreas Hanke -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] GNOME: planned changes (move to /usr, scriptlets)
Richard Bos schrieb: Do you mean with a distro package, a package that is delivered by opensuse via the boxed or online version? Yes. And 3rd party binary packages that have been built specifically for openSUSE, and are not meant to be used across different distributions or to comply with LSB packaging rules [1], are included in this definition as well. (Packman, build service etc.) [1] Packages that belong to the distribution themselves don't need to comply with LSB packaging rules, otherwise *everything* would have to use /opt, be partially statically linked or ship a copy of half of the basesystem themselves etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zen-updater unable to solve dependencies.
M9. schrieb: I do not know if this is still the right place to come to? This is the message: Unresolved dependencies: Updating MozillaFirefox-translations-2.0-28.i586[System packages] to MozillaFirefox-translations-2.0.0.1-0.1.i586[update] Updating MozillaFirefox-2.0-28.i586[System packages] to MozillaFirefox-2.0.0.1-0.1.i586[update] Installing patch:MozillaFirefox-2418-0.noarch[update] Establishing atom:MozillaFirefox-2.0.0.1-0.1.x86_64[update] Marking MozillaFirefox-2.0-19.i586[20061125-120202] as uninstallable due to conflicts over MozillaFirebird from MozillaFirefox-2.0.0.1-0.1.i586[update] Marking MozillaFirefox-2.0.0.1-0.1.x86_64[update] as uninstallable due to conflicts over MozillaFirebird from MozillaFirefox-2.0.0.1-0.1.i586[update] Marking MozillaFirefox-2.0.0.1-0.1.x86_64[update 1] as uninstallable due to conflicts over MozillaFirebird from MozillaFirefox-2.0.0.1-0.1.i586[update] Establishing atom:MozillaFirefox-translations-2.0.0.1-0.1.x86_64[update] MozillaFirefox-2.0-28.i586[System packages] provides MozillaFirefox == 2.0-28, but is scheduled to be uninstalled. MozillaFirefox-2.0-19.i586[20061125-120202] provides MozillaFirefox == 2.0-19, but another version of that package is already installed. Can't satisfy requirement MozillaFirefox == 2.0 for MozillaFirefox-translations-2.0-28.i586[System packages] atom:MozillaFirefox-2.0.0.1-0.1.x86_64[update] needed by patch:MozillaFirefox-2418-0.noarch[update] Installing atom:MozillaFirefox-2.0.0.1-0.1.x86_64[update] atom:MozillaFirefox-translations-2.0.0.1-0.1.x86_64[update] needed by patch:MozillaFirefox-2418-0.noarch[update] Installing atom:MozillaFirefox-translations-2.0.0.1-0.1.x86_64[update] Can't install MozillaFirefox-translations-2.0.0.1-0.1.x86_64[update], since MozillaFirefox-translations-2.0.0.1-0.1.i586[update] is already marked as needing to be installed Marking this resolution attempt as invalid. Ah, great! An x86_64 build of MozillaFirefox appeared in the official update repository. This is really great because zmd not being able to cope with it is the smallest problem about it. Please file a bug. The x86_64 MozillaFirefox package should not exist at all. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zen-updater unable to solve dependencies.
M9. schrieb: Please file a bug. The x86_64 MozillaFirefox package should not exist at all. #230687 This is not a complete bug report, please attach the logfiles as well. (/var/log/zmd-*, bzip2 compressed) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] updates to 10.2
Felix Miata schrieb: The inexplicable part is that the base tree doesn't contain everything pertaining to a particular release: This: http://ftp.suse.com/pub/suse/update/10.2/ Should be: http://ftp.suse.com/pub/opensuse/update/10.2/ Because: http://ftp.opensuse.org/pub/opensuse/distribution/10.2/ Is not: http://ftp.opensuse.org/pub/suse/distribution/10.2/ Why? ftp.suse.com is /suse/, ftp.opensuse.org is /opensuse/. The mirror thing is not a problem either, the base distribution is separated from the update tree because mirrors don't necessarily want to have everything. There are many mirrors which have only the update tree, and there are some mirrors which have only the base distribution. Most mirrors don't even have both. Mirrors are documented/collected in the wiki. Users don't have to browse mirrors themselves, but if they want to, they can be expected to understand the mirror infrastructure themselves. I don't see why the mirrors shouldn't have the base tree and the update tree together, but I don't see why they should change their setup to have them together either because these really originate from different servers. The proposed change introduces inconsistency. http://ftp.suse.com/pub/suse/ http://ftp.opensuse.org/pub/opensuse/ ftp://ftp.adobe.com/pub/adobe ftp://ftp.redhat.com/pub/redhat Do you see the pattern? There should be no way to choose to update with a GUI tool and not be shown everything that is available, except by explicit choice to show less than everything. People are going to see the short list object, choose it, and think everything is all up to date, just like I did last night. Who made up this specification? Right now it's the other way round. You won't be able to get this into YOU. You're expecting YOU to do something it never claimed to do. Updating any sort of packages other than those that belong to a patch is explicitly unsupported. All security updates from SUSE are part of a patch; if YOU doesn't show anything, they are all installed. For anything else there is the regular software installation module: /sbin/yast2 sw_single (And yes, the functionality to update all packages to their most recent versions is really there. Just look for it.) Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] updates to 10.2
S Glasoe schrieb: Felix is right about the directory tree not making sense. The updates are not in the same path as the distribution. Why? Consistency throughout would be greatly appreciated. Please consider that having the /update and /distribution and the additional repositories such as software.opensuse.org/download/KDE: in a logical, easy to follow order would make openSUSE a lot easier to use. For example: whatever.opensuse.org/pub/opensuse/distribution/xx.y whatever.opensuse.org/pub/opensuse/update/xx.y whatever.opensuse.org/pub/opensuse/software/KDE:/KDE3/xx.y Or: distribution.opensuse.org/pub/opensuse/xx.y update.opensuse.org/pub/opensuse/xx.y software.opensuse.org/pub/opensuse/KDE:/KDE3/xx.y Would be a heck of a lot easier to remember and setup for all of us. Is this worthy of a bugzilla entry? You're talking about something completely different than Felix here. You want the update tree to be moved from ftp.suse.com to ftp.opensuse.org. This has been discussed, and as you can see, it has not been done. I don't know why, but it does not break anything as-is, worked without even the slightest valid problems (I mean real problems, not just complaints as in It's so hard for me to find it) since the first open SUSE release (10.0) and I really wonder why this should be important because users get both the update sources and the base installation sources offered during installation. Having said that, why not discuss it again (which doesn't mean that the result of the second discussion will be different from the result of the first one), but not under any circumstances will the update trees of released distribution be moved. This would cause major troubles for all users and benefit just those who don't want to follow the mirror lists in our wikis. Note that the current rationale is not everything from the same distribution together, but update trees together and release trees together. This reflects the fact that the update trees are always in flux while the release trees never change; an important difference for mirrors because some mirrors prefer to have only stable content (=the release trees) and others prefer having only the smaller things (=the update trees). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ctapi-cyberjack src.rpm is missing on ftp
Günther J. Niederwimmer schrieb:
the ctapi-cyberjack src. rpm is missing from the online repository and
factory.
Please include this.
It's of course not missing.
The ctapi-cyberjack binary package is built from the pcsc-cyberjack
source package.
In general, please first do
rpm -q --queryformat='%{SOURCERPM}\n' name-of-binary-package
before reporting missing source packages. More details can be found in
the rpm man page.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] What to do with the bad package mngr reviews
Benji Weber schrieb: Indeed, I've already seen problems with zen-updater and zmd reported by almost all I've recommended 10.2 to, and none after removing zmd. I'm so glad it was left in by default due to being better tested. Can we maybe try to be at least a little bit fair here? Appreciating all the work that has gone into YaST, zypper and opensuse-updater: They have many, many open/unresolved problems, too - with the most important difference being that they at least don't crash that often. The zmd bashing is sometimes reaching dimensions which are longer serious. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] What to do with the bad package mngr reviews
Druid schrieb: Yeah. First link problem is clearly the (almost always) broken http redirector. If he had added a mirror directly it would probably give no errors at all. My 10.2 box is working good, without any zmd stuff installed (as 10.1 was too, actually). That said, Andreas Hanke, about the zmd bashing volume: I expect it to be just as much as the size of the problem it caused in 10.1, which we both know what is the size of it, right? Something between destroyed the known universe and reverse big bang, 2nd revision. Just to remind we are talking about a program that in 10.1 would corrupt its data all by itself, without user intervention. You went to sleep, let computer on, wake up and there it goes, repo data corrupted on zmd. Really great. Can we maybe try to discuss this issue a tiny little bit more seriously - or not at all? Try to get a clue about the zmd architecture: For a regular user it's nearly impossible to tell whether it's zmd or zypp which currupts its data all by itself because both zmd AND zypp are accessing zmd.db. The regular user of course only knows about zmd and not about the zypp backend and concludes I hate zmd, now I'll go on bashing until you remove it for me. If the database becomes currupted, how do you know why this happened? Maybe it happened because parse-metadata segfaulted... And most of the slowness _clearly_ comes from the zypp backend. That's why you can find it in YaST, too, unless you deliberately don't look at it. This sarcasm is not serious and won't help improving the quality of the non-zmd based tools. It would be much more productive if we could agree on working together improving the quality of the overall situation instead of bashing one aspect of it. The non-zmd tools still have serious problems in many areas: - Why doesn't zypper ask for the CD if I request installing packages from it, - Why does opensuse-updater tell me since several hours that it's checking for updates without actually checking anything, - Why do patches don't disappear from the opensuse-updater summary window after installing them with YOU, - Why does opensuse-updater like to invoke yast2 as yast2 which is not in the PATH instead of /sbin/yast2, - Why has zypp forgotten about the LABEL field in the 'content' file of YaST2 channels? These things are interestingly all working with zmd, where I'm constantly being told that nothing works. Btw. right now I don't have zmd installed either and I don't miss it, but it's interesting because this way it's possible to see all the not yet finished/not yet working places in the other tools. Of course I will just file bugs for these issues instead of asking for removal of these tools from the distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Groan :-(
Basil Chupin schrieb: Anybody try executing 'make cloneconfig' in 10.2 GM? 10.2 GM is not factory, factory is what will become 10.3 next summer, so this is something for the [opensuse] list. But: Here is the sorry result: dhcppc0:/usr/src/linux # make cloneconfig /usr/src/linux-2.6.18.2-34/scripts/gcc-version.sh: line 11: gcc: command not found /usr/src/linux-2.6.18.2-34/scripts/gcc-version.sh: line 12: gcc: command not found HOSTCC scripts/basic/fixdep /bin/sh: gcc: command not found make[1]: *** [scripts/basic/fixdep] Error 127 make: *** [scripts_basic] Error 2 There result isn't sorry, it simply means that you don't have a compiler installed. The command /sbin/yast2 --install gcc will install a compiler for you. There's also a lot of documentation collected in various wikis, with the most important and most often repeated information being that you need kernel-source AND make AND gcc in order to build an external module. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] open-motif-devel package?
Mark Hounschell schrieb: #find //media/SU1020.001 -name *motif* //media/SU1020.001/suse/i586/openmotif-libs-2.3.0beta2-32.i586.rpm //media/SU1020.001/suse/i586/openmotif-2.3.0beta2-32.i586.rpm It's not on the i386 DVD I downloaded? I don't seem to find it anywhere? http://en.opensuse.org/Released_Version#Downloads From there, scroll down to openSUSE 10.2 Installation Repositories, and add the first one from that list to your YaST sources. Some day it should maybe be added to the opensuse.org front page: The distribution does not fit onto 1 DVD. That's what the HTTP/FTP tree is for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] open-motif-devel package?
Mark Hounschell schrieb: If they split the 32 and 64 bit versions and put each on a DL-DVD it would all fit. And who pays the bill for all the data that gets transfered just so that every user has everything on DVD without actually using most of it? The media layout is something that really a lot of work gets put into (of course users don't see it...). The easiest solution is to just install from the media as offered and fetch all further packages on an as-needed basis. The retail DVD 9 has everything. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Cannot mount volumes on desktop (HAL permission problem)
Juan Erbes schrieb: I mean that You are wrong, because they are any openSUSE version for IA-64. http://www.novell.com/products/opensuse/sysreqs.html For IA-64 they are only the commercial versions. Please verify. Only SUSE Linux Enterprise Server 10 is supported for IA-64: http://www.novell.com/products/server/sysreqs.html No, there is indeed an IA64 build of openSUSE, offered by SGI: http://en.opensuse.org/IA64_Installation_Issues ftp://oss.sgi.com/projects/opensuse/download/inst-source (Seems to be Factory only, no releases) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUE 10.3
jdd schrieb: give them some time to relax (10.2 is a really good job :-) and pass the christmas holidays and say we could go on by jan 2007? Actually the tree is already open for 10.3 development (and it has already started), but it won't be synced out in the next weeks to save mirror bandwidth for the 10.2 downloads. So you won't see the changes in factory for a while, but they are already happening. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST2 System Update not too bright
Felix Miata schrieb: I do as much as practical using several ttys. X is not my environment of choice, but necessary for graphics and normal web use. So, this bug hits me constantly. A year is just too much, and soon it will be a year. Switching from SUSE seems to be the only option I have to deal with it. But be sure not to run into this incredible, 2 years old, unfixed bug that kills kittens and drives people nuts: http://qa.mandriva.com/show_bug.cgi?id=5591 Of course it has the mandatory If ever this bug is not fixed I'll switch to Ubuntu comment in it. ;-) Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] SUSE KInfoCenter
Felix Miata schrieb: I thought I was imagining things. KInfoCenter is a 2 pane panel with various types of information selectable in the left pane that displays in the right pane. In various distros, those types take the form of applets that are separately selectable via the monitor section of the KDE system menu. My 10.0 is one that provides the separate applets. My upgrades of factory to RC3 or whatever is there now do not, providing only KInfoCenter in the monitor menu. When I made the report that led to this change, I couldn't imagine that showing these modules as individual applications is the intended behaviour. The modules are collected from .desktop files in $KDEDIR/share/applications/kde. Looking at this directory, I can find a lot of other .desktop files which are not shown either. E.g. xserver.desktop has: X-KDE-Library=info X-KDE-FactoryName=xserver X-KDE-ParentApp=kinfocenter Categories=Qt;KDE;X-KDE-information; This was shown in the menu. And now, e.g. language.desktop has: X-KDE-Library=locale X-KDE-FactoryName=locale X-KDE-ParentApp=kcontrol Categories=Qt;KDE;X-KDE-settings-accessibility; It sounded illogical to me that the former is shown as an individual item, but the latter is not. Both are modules that are usually accessed through a ParentApp, kinfocenter in the first case and kcontrol in the latter case. I was convinced that showing kinfocenter modules as applications while not showing kcontrol modules as applications is just an oversight, and I still think that this change is not the worst idea until someone clearly states that these modules are intended to be considered as applications on their own. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Still no config options for zmd log?
Anders Norrbring schrieb: Or is it just me, not finding the options? Try: rug get-prefs and consult the man page how to use set-prefs. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST2 System Update not too bright
Felix Miata schrieb: Prior to updating from about beta2 to current factory tree today, I downloaded and installed the 2.6.18.2-33-default kernel with rpm -ivh so that the previous 2.6.18.2-5 kernel would remain installed. I forgot to reboot prior to running System Update, which proceeded to install 2.6.18.2-33 again, and remove 2.6.18.2-5. :-( Don't take this as something evil, but I have wondered since quite some time what the purpose of these status report mails to the opensuse-factory list is. If you think that any of the involved software components - be it YaST, the kernel package, the bootloader config scripts - misbehaves, file a bug. That's what Bugzilla is for. If you need help setting up your system for a particular purpose, try to state as clearly as possible what you're trying to achieve. I read the text three times now and it's still not entirely clear to me what this is all about: - If you think that a part of the system misbehaves, file a bug including what has to change: YaST, the kernel, perl-bootloader, something else... And describe the difference between the actual and the desired behaviour in such a way that it's understandable without any knowledge beyond your report. - If you just want to update your system to something that resembles what will be openSUSE 10.2 GM, forget about factory now. There's nothing interesting to see in factory right now. - If you want to have a special setup, try to find out if it's possible at all. Last time I checked, the handling of multiple equally named kernel packages in YaST was just a vision. Don't know if something changed, but right now I'd say YaST doesn't support that. In addition, you might want to check whether the old kernel really disappeared or whether it's just the bootloader entry that was missing. Note that during a not quite correctly done system upgrade, the _old_ version of YaST and its libaries are running. This means that you might suffer from bugs that have been fixed long ago. perl-Bootloader and yast2-bootloader had lots of them. Beta2 is very old. That's why the recommended upgrade way is booting from the installation media and choosing the system upgrade option from there. Doing a system upgrade within the running system means that you'll see and report old, known and already fixed bugs. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST2 System Update not too bright
Felix Miata schrieb: The updater installed software that was already installed, a substantial unnecessary load on mirrors, and waste of my time waiting for the unnecessary download from an already slow mirror. Now I finally got what it's about: You installed the -33 kernel and YaST downloaded and installed the same kernel again. The only way I can imagine this not being a bug is that the rpm -i has been done while YaST was already running. That way YaST won't notice the change because it reads the rpmdb on startup and doesn't lock it. You might want to file a bug about this. Of course you will attach the logfiles. I don't care what's recommended. I used a method offered. If it's offered, it needs testing. It might be disabled at any time then ;-) (Already happened to other features where it turned out that offering them unsupported doesn't really work and resulted in more frustration than not offering it at all would) It's disappointing to find so much reported weeks or months or close to a year ago in bugzilla that didn't get fixed before 10.2 release state was achieved. There's one in particular I reported against 10.0 (and reproduced on at least 4 entirely different systems using 10.0, 10.1 factory) long before 10.1's first beta that remains unfixed now. I've lived with it on my 24/7 box nearly a year now. Likely that box will see 10.0 replaced with Mandriva 2007 soon in order that I can stop being constantly annoyed by it. A general hint: Posting that to this list without the Bugzilla ID doesn't really bring the community any further. Writing something like I'll switch to Mandriva is very demotivating because it basically means that the bug doesn't need to be fixed because the only user annoyed by it doesn't use the product anyway. This is very counter-productive. You might, instead, try to be cooperative, i.e. show that you're still interested in the bug being solved by moving it to the next product and/or trying to fix it yourself and attaching a patch or a pointer into the right direction. E.g. by looking at source packages of other distributions where it works, finding out the difference and telling the assignee about it. Without knowing the Bugzilla ID, I can unfortunately only guess that the engineer who is responsible for your bug has a long list of more important bugs to solve that affect more people and you can't see that list because the engineers responsible for openSUSE are responsible for other products as well which are not public. Might be considered frustrating, but at some point every community member has to learn that there are bugs which will never be fixed. This is common to all open source projects. I just tried to find a 2 years old, unfixed bug in Mandriva's Bugzilla and of course it was a piece of cake finding one. Btw. I know that it's about #141443 because it's the only one you have reported against 10.0 that is still open. In that case it's really unfortunate, but as long as an engineer is unable to reproduce it, it's simply impossible to get it fixed. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] File list for Yast YOU
Pascal Bleser schrieb: Let's have a look at some numbers ;) On my repository for 10.1: repo type | size (bytes) | MB| files --+--+---+--- yast2| 1831446 | 1.74 | packages, packages.en rpm-md | 1454322 | 1.37 | primary.xml.gz, filelists.xml.gz yast2 repositories make up a somewhat larger download (21%), actually. The yast2 metadata are not compressed. If you compress the yast2 metadata or uncompress the repomd XML files, you will see a significant difference. Not to mention that e.g. /var/lib/locatedb, compressed with gzip, is just 700 KB here - holding filelist information about a whole lot more of stuff. Is it really necessary to repeat the full path of every single file in the metadata and not just the difference to some sort of base path? Does the depsolver really need the full filelists? It doesn't even use them most of the time: - Seaching for files inside packages doesn't work with repomd although the information is available in the metadata - Detecting filesystem clashes doesn't work with repomd although the information is available in the metadata So I can only conclude that the information is most of the time not even used. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] File list for Yast YOU
Pascal Bleser schrieb: What about md5sum-ming the filelist, and use the md5sum as key? If a new version of a package is released with the same filelist only the md5sum needs to be transferred. For big packages the compression might be around 100% ;) Already done. No, that's not what was asked for. Just as an example for repomd: You have a repository with package A-1 and B-1. createrepo writes the filelists of both packages into filelists.xml. Now A gets upgraded to A-1.1. Which is a great thing, because the package manager has to download the whole filelists.xml again, even though package B has not been touched at all. What you describe covers only the fact that the metadata aren't downloaded again if nothing changed. But if even the slightest thing changed, everything is downloaded from scratch, even the parts that have not been changed. Solutions: - Use a smarter protocol that can fix this design problem, e.g. rsync instead of http/ftp. - Think about a smarter metadata format. SUSE had one (the old plain-text patchinfos) and threw it away in favour of repomd. - Extend the repomd format to suck less, e.g. by splitting filelists.xml into filelists-dec06.xml, filelists-jan07.xml, filelists-feb07.xml so that at least the unchanged filelists from previous months aren't downloaded over and over again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ludicrous software management
Marcus Meissner schrieb: Is there a bugreport for this? It's a combination of multiple things. (1) Installation sources in offline mode https://bugzilla.novell.com/show_bug.cgi?id=223600 (2) Metadata shouldn't be refreshed when starting yast2 inst_source Currently not reported (AFAIK). (3) download.opensuse.org often redirects to ftp.opensuse.org Currently not reported (AFAIK). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] update to RC1 with add on source fails
Carlos E. R. schrieb: I was told here that this type of add on source was working, last october, by Andreas Hanke (http://lists.opensuse.org/opensuse-factory/2006-10/msg00355.html). And it does still work, but would you please consider using a mirror? It will make life a lot easier for you (and not just you). http://en.opensuse.org/Mirrors_Development_Build - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] update to RC1 with add on source fails
Carlos E. R. schrieb: How on earth can I use a mirror, if the network is down, has not been configured? Please read again my email and explain. ping says unknown host, remember... Yeah, you're right. That was too fast. I don't know how to bring the network up because I don't know why it's down. But once it's up and running, don't even think of adding ftp.opensuse.org. Reading the previous mail again, it seems to be lacking some information: Does this happen during installation? Or in the installed system? What exactly are you doing, what happened until then etc. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] File list for Yast YOU
Keith Goggin schrieb: I've noticed that filelists.xml.gz is refreshed by Yast YOU if it has changed on the server. It takes me about 4 minutes to download from mirror.pacific.net.au and is currently 2.9MB in size. It's really insane. This XML stuff has made SUSE distros basically unusable without a broadband connection. 3MB before the distro is even released - crazy! I had a look at this compressed text file and observed that it contains a very large proportion of redundant data. /a/b/c/d/e/file1 /a/b/c/d/e/file2 etc If this file could be compressed further by omitting the redundant data the compressed version would download much faster and may improve the end users experience of updating their system. Yes, there are much more efficient ways to store these data than repomd does. But hey, XML is so much cooler. Maybe one of those talented persons who designed repomd should have a look at /var/lib/locatedb. It's able to store equivalent information about 2 Linuxes, 1 Windows system and a lot of user files in just 2.5MB. Thanks to not using XML. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Cyrus idled missing?
Anders Norrbring schrieb: In /etc/cyrus.conf, I have: idled cmd=idled But nowhere on the disk can I find the idled command.. Ideas anyone? This should be /usr/lib/cyrus/bin/idled and comes from package cyrus-imapd. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] the MS truetype fonts script has got problems
Frank-Michael Fischer schrieb: Extracting ... failed ... deleted! impact32.exe (http://puzzle.dl.sourceforge.net/sourceforge/corefonts/impact32.exe): Anybody any idea why this happens? Yes, it happens because this code failed: cabextract -l $file /dev/null if [ $? -ne 0 ]; then rm -f $file echo failed ... deleted! This can fail for different reasons, one of them could be that cabextract is not installed. Do you have cabextract installed? Try to do the cabextract manually, what does it print? Btw.: The script installs the fonts into /usr/X11R6/lib/X11/fonts/truetype. This should better be /usr/share/fonts/truetype. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] the MS truetype fonts script has got problems
Frank-Michael Fischer schrieb: And it's unlikely that cabextract stops working for a while and comes back again etc. Hm, with the information that is currently available it almost looks like exactly that. This is the script: http://ftp.suse.com/pub/suse/update/10.2/scripts/fetchmsttfonts.sh Download it, run it on its own (without YaST around it) and try to find out why it fails. I tend to blame the sourceforge servers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Possible powersave bugs in 10.2 RC1
Markus schrieb: 1. When kpowersave is running and a laptop power button is pressed, powersaved complains (and nothing else happens): Nov 27 07:52:05 vaio powersaved[31177]: Debug (handleHWEventRequest:170) type: button/power, dev_name: PWRB, port: 0080, count: 0015 Nov 27 07:52:05 vaio powersaved[31177]: Info (handleHWEventRequest:215) button.power event occured Nov 27 07:52:05 vaio powersaved[31177]: Debug (haveClient:313) We don't own the interface org.freedesktop.Policy.Power This part of the report is not a bug: Kpowersave does not use powersaved any more, it actually conflicts with powersaved now. powersaved detects that Kpowersave is running and becomes inactive in order to prevent any conflicts. This is working exactly as designed. The other things might be bugs, use Bugzilla to report them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Re: Istanbul
Hugo Costelha schrieb: Ok, I found which ones are needed: * gstreamer010-plugins-base-oil * gstreamer010-plugins-good OK, now please report a bug, in Bugzilla. It might be too late now, but maybe you're lucky. (gstreamer packing is a PITA because the plugins are constantly moving around between the sub-packages. It's nearly impossible to keep the packages working other than re-checking all of them each time a gstreamer package has been touched in any way.) For the records: I have verified this and Hugo's analysis is correct. Requires: gstreamer010-plugins-base-oil is needed for videoscale Requires: gstreamer010-plugins-good is needed for gconfaudiosrc - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Test-Kernel
Robby (M9.) schrieb: Subprocess failed. Error: RPM failed: installing package kernel-default-2.6.18.2-33 needs 8MB on the /boot filesystem This error message is not from YaST, but from rpm and therefore it is either correct or, if it were wrong, nearly impossible to fix. Please note: You always need *twice* as much space in /boot as the kernel needs. Reason: rpm unpacks the new package first and deletes the old package afterwards. This means that for a short timeframe, rpm needs double disk space. Whenever you set up a Linux system, reserve more space for /boot than one kernel needs; reserve at least four times as much. Or change the setup not to have a /boot filesystem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Call for testing: New kernel released for 10.2
Richard Bos schrieb: What's the url to use to test this update. Is it opensuse current, something else? Any mirror of ftp.suse.com/pub/suse/update/10.2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] discussion about re-naming library packages such as slang to libslang
Some clarifications: The current policy is that the RPM package names should be identical to the basename of the upstream tarball unless there is a technical reason why it cannot be named this way. Examples of technical reasons include: - Multiple versions of a package are shipped, in this case only the name of one version can match the upstream tarball, all other versions get a shortened form of the version number squeezed into the package name. - The upstream release name contains illegal characters. I'm _strongly_ against renaming existing packages for reasons other than a technical problem which requires the package to be renamed. This should read: Discussing new rules is of course interesting and fine, but if a new naming policy is agreed on as a result of this, it should be applied to new packages only. Existing packages should not be renamed unless they either change their meaning or there are packaging changes which force changing the name. The technical problems with renamed packages are: - The package manager somehow has to know that the new package replaces the old package. This is usually solved via Provides/Obsoletes, but it pollutes the namespace: An obsoleted package name can effectively never be re-introduced again, and even the slightest mistake in this area can have very interesting results. - YaST contains hardcoded package lists in several places which don't work with Provides, but only with the real package names, so renamed packages can only be handled by changing the code and nobody can guarantee that all occurances of obsolete packages are found and cought in time. - 3rd party developers use the existing package names to express dependencies (Requires/BuildRequires), changes in this area result in very ugly %if/%else blocks that make the spec files harder to read and maintain. These cannot be fixed as easily as the ones in the distribution. If the 3rd party developer doesn't notice the change, the package gets broken. Note that I do think your proposal has advantages, but in order to be really useful, it would require major packaging changes. As an example, how would you handle a package that contains both shared libraries and executables? Debian-derived distributions have a policy to split all such packages so that the executables are in a package named like the upstream release and a library package that gets a lib prefix and a suffix based on the interface version of the shared library. This is an advantage because it means you can have an arbitrary number of different library versions installed, but requires much more packaging work. You would have to update the BuildRequires of all packages all the time, and you would have to manually keep the package name in sync with the interface version with each upgrade. It's painful, I predict it won't work and for a centrally developed distribution it's not really necessary. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-packaging] Hint needed
Dominique Leuenberger schrieb: That's not exactly what Maximum RPM tells you: http://www.rpm.org/max-rpm/s1-rpm-pgp-signing-packages.html Maximum RPM is horribly outdated. Never trust any information from Maximum RPM without verifying first that things didn't change. (In this specific case, I don't know whether or not the information still applies, but in general I can say that basically everything on rpm.org has outdated information in it.) Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] default packages
jdd schrieb: and why so many gnome libraries? even icons! on a text install! This has been noticed very late ;-) Call the packages by name (not gnome libraries, but e.g. glib2), find out where the dependency comes from and try to find out whether the dependency is necessary. If it is, do nothing, if it is not, report a bug against the package where the dependency chain starts. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] default packages
jdd schrieb: there are a lot, and I did see gnome on the display :-( A lot is not enough, I need the exact package names in order to find out where the dependency chain starts and if it is legitimate. If the problem consists mainly of seeing the string gnome on the display, case closed there are also many documentation package that should not be here. on a minimal install, only man page should be there (is that even necessary?) Which documentation packages? Package names, please. Note that I know that many packages have problematic and partly plain wrong dependencies (which were added over the time as workarounds for other problems and never removed), but the number of packages (3000 source RPMs) is _far_ too large to even start working on it without a very specific example. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] default packages
jdd schrieb: 2006-11-24 20:02:03 gnome-filesystem-0.1-287.i586.rpm installed ok This is a fake package that contains mostly empty directories and is 1.3 kB in size. Ignore it and do as if it would not contain the string gnome in its name - it might vanish very soon. 2006-11-24 20:51:55 gnome-mime-data-2.4.2-41.noarch.rpm installed ok This is needed by gnome-vfs2 only, I'll try to find out whether the dependency is necessary. I think it is. For the rest: See MozillaFirefox. 2006-11-24 20:52:05 gnome-keyring-0.6.0-17.i586.rpm installed ok Legitimately needed by many packages, so the question is whether its consumers are legitimate. Some of them might be avoidable. 2006-11-24 20:52:54 gnome-icon-theme-2.16.0.1-11.noarch.rpm installed ok Needed by several packages, there are certainly illegitimate dependencies among them that have been added over the time and can be removed now. 2006-11-24 20:55:26 libgnomecups-0.2.2-45.i586.rpm installed ok Required by libgnomeprint and libgnomeprintui. Dependency might be bogus, should be investigated. The real question here is whether the consumers of libgnomeprint and libgnomeprintui are legitimate. 2006-11-24 20:59:41 gnome-vfs2-2.16.1-22.i586.rpm installed ok Required by MozillaFirefox, the dependency is correct. Possible solutions: (1) Split the GNOME integration parts out into something like MozillaFirefox-gnome (2) Hide the dependency from rpm, possible via hacks, but ugly (3) Remove MozillaFirefox from the default installation. 2006-11-24 20:59:49 libgnomecanvas-2.14.0-22.i586.rpm installed ok Legitimately needed by mozilla-xulrunner181 which has been added to the default installation. 2006-11-24 20:59:56 libgnomeprint-2.12.1-46.i586.rpm installed ok Should be avoidable, needs more investigation. 2006-11-24 21:01:41 libgnome-2.16.0-25.i586.rpm installed ok Needed by MozillaFirefox, see above. 2006-11-24 21:02:14 libgnomeui-2.16.1-17.i586.rpm installed ok Might be avoidable. 2006-11-24 21:02:21 libgnomesu-1.0.0-65.i586.rpm installed ok Probably pulled in by error-prone hand-written dependencies, there are certainly avoidable ones among them. 2006-11-24 21:02:30 libgnomeprintui-2.12.1-46.i586.rpm installed ok Might be avoidable, but I couldn't find wrong dependencies for now, so it must be a superfluous package that pulls this in. Hot candidates: librsvg, compiz May I ask if you happen to use gdm as display manager? That would explain a lot. But thanks, while investigating this list I already found out that anjuta has buggy-handwritten dependencies which is very error prone. Won't solve your problem (unless you're using anjuta, which I doubt), but is a starting point. This is a general problem with many GNOME packages, all hand-written dependencies should be reviewed because they are really old cruft and things have changed. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] default packages
Andreas Hanke schrieb: This is a general problem with many GNOME packages, all hand-written dependencies should be reviewed because they are really old cruft and things have changed. Note that I have another bug pending (#223387) that is partly responsible for excess dependencies among packages that use pkg-config in their build system. In short, pkg-config is configured to convert all private dependencies into public ones. This has been added years ago as a workaround for a pkg-config bug which is fixed now, so the workaround can be removed. No other major distribution still does this. It will be a hard job convincing the guys that this will not result in non-prelinkable libraries and that Linux and glibc don't need all deplibs to be linked in (seriously, they really don't need it), but I'll try it anyway ;-) Since most packages that use pkg-config happen to be GNOME packages, it should hopefully reduce the dependency problems in the GNOME area a little. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] sax2 files in /tmp
Felix Miata schrieb: There are also several YaST2*, sax2* and xorg.conf.* dated from previous boots. Not sure about sax2, but the files from YaST2 mean that YaST2 crashed or was killed abnormally. YaST2 does not leave stale tmp files around if it quit in the regular way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ext2
Kenneth Schneider schrieb: Please clarify: does the module ext2 belong to Novell or does it belong to linux? Do other distros show the same message module not supported by Novell or do they put their own distro name in the message. If I were the maintainer of the module I would be offended by this statement. This stuff isn't configured in the module itself, but in /lib/modules/`uname -r`/modules.unsupported and the module-init-tools. And yes, other distros/vendors don't support all modules either. reiserfs.ko for example isn't supported by a well-known other vendor. There is nothing offensive in this per se because it's not the maintainer, but the vendor which provides the support (and the costs implied by this). The supported flag doesn't have a real meaning for openSUSE, but has a meaning for enterprise products because customers can use it to prevent trashing their support contract by loading a module that the vendor does not offer support for. (Not offering support for a module simply means sorry, offering support for this would be more than what you paid for and not the module is bad or you shouldn't use it). ext2 being unsupported is simply a bug, of course it should be supported. Other modules will remain unsupported and users are free to use them anyway. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Yast security update installation failing
Volker Kuhlmann schrieb: [...] The patches are already installed. And yes, the user interface confusion that makes you think they were not installed is fixed for 10.2. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Yast security update installation failing
Volker Kuhlmann schrieb: Ehh, this is most certainly not true. rpm -qa --last and rpm -q are *VERY* reliable in telling exactly what is and isn't installed, and I am absolutely positive that aforementioned packages were NOT installed. Besides, after I deleted stuff under /var/lib/zypp and re-running YOU, all the missing .patch.rpm were installed by YOU. The same rpms YOU before detected as needing to be installed but then ignored to install. [...] This is not just a user interface problem! It seems to be more a problem with how YOU makes use of the /var/lib/zypp/.../patches/* information and assumptions based on them. Are you really sure these are fixed? Otherwise it becomes a security problem with 10.2 final (as it is with 10.1 final). I think that only a YaST/zypp expert can analyze what's going on here and only with logfiles: /var/log/YaST2/* Right now, this is the very first time I hear that YOU doesn't install patches. Most reports like this turned out to be misunderstandings (either people assumed that YOU would install the latest version of a package, but in fact it only tries to fulfill requirements defined in the patchinfo and does nothing if they are already fulfilled; or people interpreted the fact that patches don't disappear from the view as that they were never installed). Since I don't remember any similar bug report either, file a bug, of course with all logfiles attached. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 bug prioritization
Christoph Thiel schrieb: Therefore, I'd like to ask YOU to help identify those bugs, that are currently hiding under the radar (ie. aren't red) and should be elevated. Given that today is officially the last day where non-Blockers are allowed to be fixed, I'd like to point at the following two non-Blockers which are still annoying enough (and have fixes attached): https://bugzilla.novell.com/show_bug.cgi?id=221383 The gdm default configuration file (/opt/gnome/share/gdm/defaults.conf) is corrupted because it contains a comment that is not commented out: Willing script, none is shipped, X11's one is used by default. Should be: # Willing script, none is shipped, X11's one is used by default. This invalidates the file and causes all values below the corrupted line to be discarded, esp. the MinimalUID setting. I assume that the impact of this is higher than currently known and documented in the bug report. https://bugzilla.novell.com/show_bug.cgi?id=220300 Alacarte is untranslated although it installs many translations because it doesn't find them. I have a feeling that the bug is currently incorrectly assigned because of a misunderstanding (alacarte doesn't have anything to do with gnome-main-menu) - can you investigate? Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Cannot login in recue system
Hugo Costelha schrieb: Since openSUSE 10.2 beta 2 cannot install grub correctly on my laptop (with an empty disk all dor openSUSE 10.2), I was giving a try on running grub myself from the shell. I booted the rescur from CD1, but I cannot login. If I type root it asks for the login again. If I type anything else, it says login incorrect. Any ideas? I was really looking forward to test openSUSE 10.2 beta2 in this laptop. Continue doing so. What you describe is known (in fact even mentioned as a Most Annoying bug on http://en.opensuse.org/Bugs:Most_Annoying_Bugs) and already fixed (for RC1): https://bugzilla.novell.com/show_bug.cgi?id=219112 Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Cannot login in recue system
Hugo Costelha schrieb: Well, I finnally was able to login. Instead of booting from CD1 of beta2, I booted with the net installation CD, went to manual install, select Start Rescue System, provided with a URL of the Factory tree, then it booted the rescue system, and I was able to login. That's because this CD is either older than Beta2 (and therefore doesn't have the bug yet) or newer than Beta2 (and therefore has the bug already fixed). In general, try to search Bugzilla for FIXED bugs first or look at http://en.opensuse.org/Bugs:Most_Annoying_Bugs - obvious bugs are documented there so that everybody knows if/when they are resolved. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Ati 3D
Robby (M9.) schrieb: I found the file, but it is a sax generated file, which cannot be edited the way a script can be edited... Of course you can edit the file! Just ignore the comment and edit it anyway. (What you shouldn't do is editing xorg.conf and then filing a bug against SaX2 for a config file that hasn't been generated by SaX2. But otherwise, xorg.conf is yours and you can do with it whatever you want.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 bug prioritization
Juan Erbes schrieb: But for RC1 the grub installer related bugs will be resolved? Yes, they will be, or are already; search Bugzilla and include FIXED bugs in your search. Please, let's not make this thread off-topic; it is used to track bugs which are already in Bugzilla, known to be not yet fixed, and underestimated. If you have a particular Bug-ID that you know to be still unresolved and having a too low severity or too little attention, use this thread; if you do not have a Bug-ID or just want to ask questions about a bug, post a completely new thread. Especially, always watch this page: http://en.opensuse.org/Bugs:Most_Annoying_Bugs I can see stuff there that sounds very much like your issue and is striked. Did I already tell you to include FIXED bugs in the search settings when searching Bugzilla? Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Recommendation w.r.t. NetworkManager
Randall R Schulz schrieb: If it's relevant, this box has two NICs Yes, this is relevant because it means that you probably can't use NetworkManager. NetworkManager is not yet able to handle two NICs simultaneously. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Proposal on metadata fetching
Marcel Hilzinger schrieb: The big difference between Suse and Debian/Ubuntu is, that under Suse much more data get's fetched. So you can also search within package-descriptions etc, whereas under Ubuntu you have only package-names and files, but no description e.g. For a more detailed search you need apt-file. I think apt-file is compearable to the actual suse solution. As a starting point, the YaST2 metadata could be compressed. Debian does that since ever, but YaST2 metadata were never compressed. The packages file in Factory is currently at 16 MB, a good bzip2 compression reduces it to 1.8 MB - almost 90% gone. I think that this should really be considered first because it is possible entirely without functionality loss and without complicating the architecture too much. The thing with the patterns for unneeded architectures is more a cosmetic thing because the pattern files are very small. But many users notice it because YaST displays the filenames of the downloaded metadata. For YUM metadata, there is not much to do because they are already compressed and it's a standardized format - it can be extended, but not changed in incompatible ways. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] amarok-helix
Martin Schlander schrieb: Can as in Real will only allow.. or as in technical necessity? Look at banshee vs. helix-banshee and you'll see the reason. Without knowing the exact background information, I guess that SUSE would have been forced to rename Amarok to Helix Amarok, add a Helix EULA on startup and add Helix branding. The changelog of the amarok package cleary states that amarok-helix has been disabled on purpose. Certainly not in order to annoy the users. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] bluez-gnome not in a good shape, late upgrade exception possible?
Hi,
I stumbled across https://bugzilla.novell.com/show_bug.cgi?id=217073
which describes the following scenario:
- The bluetooth subsystem has heavily changed. Existing GNOME tools
don't work properly therefore:
https://bugzilla.novell.com/show_bug.cgi?id=214869
- There is a replacement for gnome-bluetooth available in the
bluez-gnome package. This package provides only very basic GUI
functionality. A configuration dialog is not present, but available in
the newer upstream version 0.6, released on Oct 22nd.
- https://bugzilla.novell.com/show_bug.cgi?id=217073, comment 7 suggests
an update, but it would need approval and someone would have to do it.
It is a leaf package, nothing else depends on it. There are no
translations to break because the package is untranslated.
- Independently of the update approval, the package currently has
degraded functionality because of missing libnotify-devel in BuildRequires.
What do you think, is an exception possible here? I used the following
patch against the existing spec file and it works for me:
##
--- bluez-gnome.spec
+++ bluez-gnome.spec
@@ -17,19 +17,18 @@
Name: bluez-gnome
-BuildRequires: bluez-libs bluez-utils dbus-1-glib-devel gconf2-devel
gtk2-devel intltool update-desktop-files
+BuildRequires: bluez-libs bluez-utils dbus-1-glib-devel gconf2-devel
gtk2-devel intltool libnotify-devel update-desktop-files
%define prefix /usr
%define sysconfdir /etc
License:GNU General Public License (GPL) - all versions
Group: System/GUI/GNOME
Autoreqprov:on
-Version:0.5
+Version:0.6
Release:11
Summary:Bluetooth helpers for GNOME
-Source: %{name}-%{version}.tar.bz2
+Source: %{name}-%{version}.tar.gz
URL:http://www.bluez.org
BuildRoot: %{_tmppath}/%{name}-%{version}-build
-Requires: cairo dbus-1 dbus-1-glib expat glitz pango
xorg-x11-libXau xorg-x11-libXdmcp
%description
Bluetooth helpers for GNOME
@@ -55,7 +54,7 @@
%install
rm -rf $RPM_BUILD_ROOT
make -i install DESTDIR=$RPM_BUILD_ROOT
-%suse_update_desktop_file bt-applet System
+%suse_update_desktop_file bluetooth-properties System
#%find_lang %{name}
%clean
@@ -67,8 +66,9 @@
%doc AUTHORS COPYING ChangeLog NEWS README
%defattr (-, root, root)
%dir /etc/xdg/autostart
-/etc/xdg/autostart/bt-applet.desktop
-/usr/bin/bt-applet
+/etc/xdg/autostart/bluetooth-applet.desktop
+/usr/share/applications/bluetooth-properties.desktop
+/usr/bin/bluetooth-*
%changelog -n bluez-gnome
* Tue Oct 17 2006 - [EMAIL PROTECTED]
##
(Should have suggested this earlier...)
Andreas Hanke
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] bluez-gnome not in a good shape, late upgrade exception possible?
Stanislav Brabec schrieb: At least 0.5 is not a replacement. bluez-gnome-0.6 is slightly better. It's still not a full replacement, but provides at least a basic configuration dialog to make the computer visible to other devices. What do you think, is an update to this version something to consider? Who would be able to do it? Would it get approved by the project management? I'll have to make a bugzilla about this because I think that the new version is clearly better, the current one not really useful and the risk very low. bluez-gnome provides PIN dialog, gnome-bluetooth provides OBEX server (and unuseful device browser). This is covered by: [Bug 219371] Bluetooth device GNOME support needs many icons in tray area https://bugzilla.novell.com/show_bug.cgi?id=219371 bluez-gnome will in the future provide much more functionality, among others an OBEX server and maybe even more. I have already filed https://bugzilla.novell.com/show_bug.cgi?id=220448 (against 10.3) to make sure that the needed infrastructure is in place. bluez-gnome might be able to replace one or even two other tray icons in the future. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Linux-Kernel-Headers outdated
Vahis schrieb: Everything is as It's says there. But the script keeps coming to this: The directory of kernel headers (version @@VMWARE@@ UTS_RELEASE) does not match your running kernel (version 2.6.18.2-4-default). Even if the module were to compile successfully, it would not load into the running kernel. Again: You need to install the kernel-source package. The linux-kernel-headers package is not usable to build external kernel modules; whether it matches the running kernel or not is if no importance. The important thing is that the commands rpm -q kernel-default rpm -q kernel-source return exactly the same version. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] lua50 not synced out
Hi, I have a problem with the following two bugs: https://bugzilla.novell.com/show_bug.cgi?id=217875 https://bugzilla.novell.com/show_bug.cgi?id=219773 The former is not properly fixed and needs to be reopened, but the latter prevents me from working on a solution. Would it be possible to get lua50 synced out on the next opportunity? It's missing since it exists (~4 weeks according to my crystal ball). Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 bug prioritization
Christoph Thiel schrieb: [...] I'd like to point at bug 210935: The istanbul package is completely broken. The current summary of this bug is just a tiny subset the brokenness: It also installs its gconf schemas into /etc/gconf which doesn't work at all and other ugly things. I will attach a fix for the packaging brokenness shortly. The bug is ugly because istanbul had already been broken (in a different way) in 10.1. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 bug prioritization
Anders Johansson schrieb: On Sunday 12 November 2006 17:42, Andreas Hanke wrote: And another one: https://bugzilla.novell.com/show_bug.cgi?id=220274 I have heard that very often. I think it's a problem with the native x86_64 build and a duplicate of bug 219982 which is already Critical, but a confirmation would be nice. I doubt it. Doesn't work at all with sun java 1.5 and starts slowly don't sound like duplicate bugs It's both specific to x86_64 and there was another report (don't have the # at hand) where the reporter said that completely removing Sun Java resolved the slowness. It doesn't really matter whether it's a duplicate, an OOo startup time of almost 2 minutes is certainly unacceptable and needs more attention than Normal, especially if it happens to many people. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] To Novell SUSE - Please include Windows Media Codecs after deal with Microsoft
Alexey Eremenko schrieb: Since we have made a deal with MS about patents, I would like to ask include MS-patented Windows Media Codecs (WMA/WMV) with both openSUSE 10.2 and future SUSE versions... (including Enterprise). The code exists (on packman sites - the only problem was patents, which is solved now). Yeah, it's really cool and funny. Again: Code that infringes patents will not be distributed, and the so-called deal does not allow anyone to infringe patents. The deal is not as simple as it has something to do with patents. The deal does not cover what you are asking for. But maybe you're lucky anyway: RealNetworks has a deal with MS that covers it and Novell in turn has a deal with RealNetworks. Having said that, saying the code exists about what you can find on rpm sites is a little bit out of place. These are Windows binaries. MS does actually license the source code to interested parties, but there are no flat fees. That's why you won't get the codecs legally for free: Whoever licenses them from MS has no other choice than charging for it, the lack of a flat fee makes it impossible. If you're seriously(!) interested in what the deal is about and especially in what it is not about, read the transcript of the last status meeting: http://en.opensuse.org/Meetings/Status_Meeting_2006-11-08/transcript The other funny jokes were already there often enough - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] To Novell SUSE - Please include Windows Media Codecs after deal with Microsoft
Anders Johansson schrieb: I don't think this is true though, RealPlayer will include the codecs in an upcoming version, and from what I hear it will be distributed free-of-charge just like before Yeah, that's because Real gets a flat fee for 0$ because of the lawsuit in Europe, but all others have to pay and there is no flat fee as for e.g. MP3. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] Changing Desktops in SUSE 10.1
Rob Fleetwood schrieb: When I installed SUSE 10.1, I was asked whether I wanted to use GNOME OR KDE as the desktop manager. I selected GNOME. Earlier versions of Mandrake (that I used to run) allowed you to run either GNOME or KDE or any of several windows managers. Can anyone tell me how I modify this installation so that I have a choice (in other words I am asked at boot time which one I want to run)? Disable autologin (in the YaST2 users module). The displaymanager will then ask you which session to start. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] Changing Desktops in SUSE 10.1
Rob Fleetwood schrieb: ...and where would I find the YaST2 'users' module? Run YaST2 and go to Security and Users - User Management - Expert Options - Display Manager Login Settings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] Handling Environment Variables
John schrieb: In order to run this app and read its manual, I need to add the relevant directories to PATH and MANPATH respectively, but if I use the 'export' command, it only adds them or the current session. How can I add these two paths permanently for all users? Use /etc/profile.local. This file does not exist in a default installation. Just create it, write your stuff into this file and it will be picked up for all subsequent logins of all users. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] 10.2Beta2
Kenneth Schneider schrieb: Anyone know the secret incantation to enter rescue mode from the 10.2B2 mini-install cd? I tried using root but it only kicks back to a login prompt. You can't. This is a known bug (#219112 with many duplicates). Should work OK in the next build. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] Changelogs in RPMs
Rick Friedman schrieb: I just installed the latest MozillaFirefox package (2.0-41.1). It occurred to me that I haven't really seen changelogs for these packages that I'm downloading. So, I checked the contents of the MozillaFirefox package and there doesn't seem to be a changelog in there. How can I go about finding the changes made from one package version to another? (not just for the Firefox package but for all of them) rpm -q --changelog PackageName | less Or use YaST2 Software Management (/sbin/yast2 sw_single). It is able to display the changelog of installed packages. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zen-updater failure..
Pavel Nemec schrieb: Look at Bug 210951 - Unhandled exception at startup https://bugzilla.novell.com/show_bug.cgi?id=210951 This is a different exception. Yours is: A null value was found where an object instance was required But Monkey 9's was: library routine called out of sequence These are different bugs, but both of them are already in Bugzilla. The latter is: https://bugzilla.novell.com/show_bug.cgi?id=217326 (correctly marked as Blocker because it happens very frequently) Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Zen-updater failure..
Andreas Hanke schrieb: These are different bugs, but both of them are already in Bugzilla. Forgot to give details: 210951 happens only if /var/lib/zmd/zmd.db is corrupted. It's still happening, but the root cause is better handled in new zmd versions. Restarting zmd makes it disappear because zmd detects the corrupt database and rebuilds it. 217326 is different because it happens all of a sudden for no apparent reason. One of the duplicates describes that this was seen even during an installation. Restarting zmd does not help here. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Robby (M9.) Verberne schrieb: What I am trying to prove with this, is that the app is useless at this time, (as it was in 101), and that we all need something like smart, and smart update checker, instead of this resources consuming monster, that is not productive at all You don't need to prove anything. If it's useless for you, just uninstall it and use another tool as so many other people do. That's why the other tools are there, some of them even on a first-class place on CD3. There are more things to consider for switching the tools and just posting copied and pasted top data to the list isn't much more productive either. It won't work this way. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Dominique Leuenberger schrieb: I think one problem we all experiance here (and I'm not even sure Smart would handle this different) is the fact, the a zmd refresh has to get the current catalog infos from a server (I think it's downloading primary.xml.gz and filelists.xml.gz and maybe even other.xml.gz, can a ZMD expert comment on this?) Almost true. ;-) zmd never downloads other.xml.gz. If it does, it's a bug. But I've never seen that. zmd and smart are downloading the same files for YUM repos: repomd.xml, primary.xml.gz and filelists.xml.gz. The difference is that zmd downloads it even if not explicitly asked to do so. But on the other hand, the files don't need to be downloaded later because they are already available. Especially in the Factory tree which is very unstable at the moment, these catalog files are changing regularly (several times a week) and thus have to be downloaded over and over again. Let's say that the tree is in flux and not unstable. Once the tree is considered stable, these catalogs get downloaded a single time and only the update tree is modified. AFAIK, zmd keeps the timestamps of the last update of these catalogs, and if not changed, decides not to download them. Correct, neither zmd nor smart are downloading metadata from unchanged sources again if they are already available. A short look on the files show, that it is downloading around 60MB at the moment. This might take a while. Here, probably the FTP/HTTP[S] Get method is not as cpu friendly as it could be, or maybe it's something completely different. There is a slight difference between zmd/YaST/zypp and smart for YaST sources: For this source type, smart does indeed download fewer files than libzypp does. But you get less functionality back: No translations, no disk usage information, no patterns. What Monkey 9 is experiencing here is probably just a bad mirror. I blame download.suse.com. Solution: Remove this source and add a good mirror directly. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Martin Schlander schrieb: On a 10.2 KDE install I believe Zmd only depends on rug. Maybe also libzypp-zmd-backend, can't remember. zmd does not depend on rug. rug depends on zmd. The claim that there are so many dependencies on zmd is just wrong. The following packages depend on zmd: rug zen-updater zmd-devel zmd-inventory zmd-debuginfo simias 4 out of these 6 are never installed by default and the other 2 are optional. Whoever has difficulties uninstalling zmd does something wrong. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Is there a reason inst-source-extra can not be added to yast?
Robby (M9.) Verberne schrieb: I understand, but when I notice an app that is just doing nothing, but consuming valuable resources, and that for this long time, i think should not go unnoticed. Why do you think that zmd is not doing anything? You can't know this because zmd does its work invisibly. You are, again, confusing zmd, zen-updater and rug which each other. These are three different programs: zen-uodater is the visible one, zmd is the invisible one and rug is another one. Just uninstall zmd, rug and zen-updater and be happy. Everything else in this discussion is already known and we really don't need to explain the Zenworks architecture yet again from the beginning. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Robby (M9.) Verberne schrieb: YaST2 conflicts list - generated 2006-11-06 15:31:47 [...] YaST2 conflicts list END ### These are also for when to uninstall every one of them seperate. Does this look like a free choice? No, this is simply a bug. These dependencies are wrong. = Bugzilla (with logfiles, please) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] ZMD consumes 70-85% cpu during more than 150 minutes...
Robby (M9.) Verberne schrieb: I am going to do this again, and never look back: 'bye bye zmd!' (go and fuck gnome.. Can you please keep your tone civil? I was seriously writing yet another explanation of how all these things depend on each other, but deleted it (not as a reaction to this, earlier already). What we really do not need in this very moment is yet another I don't like zmd, please change the distribution for me two weeks before the very last freeze thread. We are already offering a ridiculous amount of alternative package managers for users who share this opinion. You are very late in the game; consider getting involved earlier if you're interested in openSUSE 10.3 development. And such a noise because of 3 packages you can't manage to uninstall is plain inappropriate. If smart is really the perfect tool for you, then you should have noticed that it happily bypasses pattern dependencies without a single complaint. Just do smart remove zmd and you're all set. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Remove zen-installer from gnome-main-menu
Claes Bäckström schrieb: Yes it's possible to do in gconf. So it's simple to change. But for me it's a deeper question. What is the supported way to install software in openSUSE? YaST2 sw_single and Zen-Installer are equally supported. (Well, if you ask me, shipping two tools that do basically the same thing in fundamentally different ways isn't the smartest thing to do in the first place, but that's just a personal opinion.) That is what we should show the users primary. And if the recommended way is to use zen-installer then it should stay but if not we should change it. This is not so simple to decide. Zen-Installer supports the zmd permissions system so that people can use it without the root password on configured systems. This is a plus of Zen-Installer. So far no one have stepped up and said no to change this. So do that mean that everyone thinks we should change this? No. Not all involved people are subscribed to this list, and don't forget that it's Sunday and the request to change this was made on a Saturday. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] openSUSE 10.2 bug prioritization
Christoph Thiel schrieb: Therefore, I'd like to ask YOU to help identify those bugs, that are currently hiding under the radar (ie. aren't red) and should be elevated. I'd propose posting the bug numbers in this thread + giving a short rationale. Please keep in mind that we should try to focus on the bugs that really affect a majority of the users! OK, here we go: https://bugzilla.novell.com/show_bug.cgi?id=206954 There is still no audio player installed by default for GNOME users who decide not to use the AddOn product. https://bugzilla.novell.com/show_bug.cgi?id=216560 The author of cdrecord heavily dislikes it if other programs call themselves cdrecord. Even if it's just an oversight and might break translations, we should fix the wodim package description to avoid such trouble. https://bugzilla.novell.com/show_bug.cgi?id=217660 This package, part of the GNOME platform, is completely broken and the fix is easy. More and more packages from www.gnomefiles.org depend on it, users should be able to install them and not be blocked by a relatively stupid packaging bug. https://bugzilla.novell.com/show_bug.cgi?id=217326 This is happening to a lot of people and is really annoying. It makes zmd unusable and happens even during first installations, so people don't get their security update repos synced with zmd. https://bugzilla.novell.com/show_bug.cgi?id=218032 The gtk2ification of gnucash was impatiently awaited by many people, and now gnucash doesn't start up. There was a different bug where gnucash didn't start up that was marked critical. This one should be critical, too - because gnucash is installed by default. https://bugzilla.novell.com/show_bug.cgi?id=217875 Updating lua so extremely late was already wrong in the first place, but now at least the consequences should be minimized. File conflicts are a serious packaging bug, and users will see it if they try to install two games that need different lua versions. The packages should be split as suggested in comment 1 and the remaining conflicting parts marked as conflicting. https://bugzilla.novell.com/show_bug.cgi?id=216982 Don't know how to solve, but at least there should be an Xgl update for 10.1 that fixes the wrong %postun script so that at least those users who install patches regularly can update properly. https://bugzilla.novell.com/show_bug.cgi?id=214884 https://bugzilla.novell.com/show_bug.cgi?id=210922 https://bugzilla.novell.com/show_bug.cgi?id=216880 There should not be any unresolved dependencies in the final product. This looks very buggy. https://bugzilla.novell.com/show_bug.cgi?id=216155 If the report is correct, it seems to break the build of Xine, which is very bad because it's one of the first package many users are typically installing. https://bugzilla.novell.com/show_bug.cgi?id=215392 Gives the desktop an unfinished feeling and users are being told to use the eject context menu because of possible data loss. They should not run into an error message when doing that. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] SPAM: Novell MS Deal
Tony Pott schrieb: To all the people at SuSE, I know this isn't your fault, and I'm sorry I have to stop using your excellent work. I'm sad to have to change to another distro, I've been a fanboy since SuSE 8.0, but this deal is just disgusting. Ah, I see. Nobody gets what this deal is about, but you already know that it forces you to stop using the distribution. Highly interesting. Can you please read the announcement and point out which of the following prevents you from using the distribution: Patent coverage Virtualization Virtualization Management Office Open XML Collaboration Framework Mono, OpenOffice and Samba The mailinglist setup is right, this is SPAM. Use one of the existing I have been a SUSE fanboy since 231847941 years and now switching to [A-Z]Ubuntu threads. We already have enough of them. Just post me too into the other threads. ARGH! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
SPAM: Re: [opensuse] SPAM: Novell MS Deal
Miguel Angel Alvarez schrieb: [...] All this stuff resembles a similarly *censored* 1+1=2-style discussion we had recently, and it's similarly useful: We're just stuffing the mailing list archive with self-made junk here, that's it. If people want to go, do it: Go away, no problem ;-) Experience shows that most of the this is so disgusting, I'll go away-thinking users come back again when they realize that there was no reason to do so. And even if they don't, there are enough other users and there are new users every day. In the meantime, JBoss, acquired by Red Hat, has contracts with MS, and Zend has contracts with MS, and other OSS companies have contracts with MS and nobody cares, but this won't stop users from damaging their own community by filling the list archives with Oh my God, Novell + MS, it's so disgusting junk. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] SPAM: Re: Novell MS Deal
Tony Pott schrieb: You're missing the point. No, I am not, you are. Microsoft have been making war against the Linux community for years. Novell have elected to make a separate peace with Microsoft. This makes Novell no longer part of the community. Who defines who is part of the community or not? If you had an idea what all this stuff is about, you would know that people at SUSE are just in this very moment squashing the openSUSE 10.2 buglists in order to have a good openSUSE 10.2 release. openSUSE 10.2, a product that most users don't even pay for. And the people at SUSE are doing this on a Saturday, where normal people don't do any work at all. And they will continue tomorrow, on a Sunday, too. Did I forget that they stopped yesterday, Friday, after midnight, doing the same? And whom are they doing this for? For you. How many hours a day are you, the one who defines the community, contributing? But you have nothing better to do than repeatedly posting the same FUD bullshit about MS and betrayals and the community. The community are people who *contribute* to the project and not just talk about it. There are still people who prefer damaging the project by producing FUD, which is per se maybe understandable, but then please don't define who belongs to the community... And feel free to say goodbye if you don't want to belong to this community anymore. It's OK! It's a betrayal, and one which cannot easily be forgiven or forgotten. No, it is not a betrayal. The FUD which originates from within the community is a betrayal that cannot be forgiven or forgotten: It's enough now. No interest on your side in contributing to the project anymore = No problem, it will go on anyway, but don't go people on the nerves who neither have any influence on this nor anything to do with this. I appreciate you're unhappy that people are using this mailing list in a way that you regard as OT. Unfortunately, there is no better place to express our feelings, so you're going to have to live with it for a while. What I'm going to live with and for how long is something I'd like to decide myself; I have a problem unfairness, what you are practicing is unfairness because the claim to define who belongs to the community is just ridiculous and I complain about this. It can go on infinitely. In other words: Don't announce lengthily that you are going, just do it. Other will do the same, and many of them will come back. Who cares. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] opensuse-updater questions
Alex schrieb: As a KDE user I have now once more trashed zmd and rug and want to use opensuse-updater and libzypp direct. Version of opensuse-updater is 3.16, libzypp and zypper are installed. 1. When configuring the applet, I just have the option to choose between Novell ZENWorks and Default. Where is libzypp?? 2. There are quite some services available and active (as shown by zypper sl; these channels have been added in the past with rug, not with yast2). opensuse-updater seems to check for updates periodically, but never ever finds any updates on this channels, even if they are definitely there. What am I doing wrong? You are expecting things from opensuse-updater that it doesn't do. opensuse-updater does _not_ update every package to the most recent version; it installs patches only (like the old SUSEwatcher did), so new packages are pulled in only if they are part of a patch. The factory tree does not contain any patches. In order to have opensuse-updater update all packages to their most recent versions, you must configure it to use the ZENworks backend. Andreas Hanke (who is still not convinced that removing ZENworks from the default installation is a good idea) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse] So Long openSuSe
Michal Hlavac schrieb: When I leave M$ (3 years ago) and choose Suse, I felt free... Now I am confusing I am deciding to leave suse and choose something like kubuntu... I like to feel free... Yes, you need to switch to KUbuntu immediately. Because of a corporate agreement between Novell and Microsoft that nobody knows what it is about and that does most likely neither affect you nor the openSUSE project at all. *Sigh* - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] YaST question
Andras Mantia schrieb: Does YaST (sw_single) always download - on every run - the information from repodata if refresh is set to On for the respository or there is a check to see if it was really changed or not (using timestamp or filesize)? I'm have a feeling that it always downloads, but I might be wrong and packman is the one changing all the time. YaST downloads only a very small file in order to see if the repository changed. The rest is cached and only downloaded if necessary. For YaST repos, the small indicator file is /media.1/media. It contains a timestamp. For YUM repos, it's /repodata/repomd.xml. If you have a feeling that Packman is processed slower, there are multiple explanations: - The Packman repo does indeed change relatively frequently, and the repodata have to be downloaded from scratch. Incremental downloads are not possible right now. - The Packman repo is a YUM source. Parsing the metadata is notably slower for YUM sources than for YaST sources and the progress bar is inexact. Since the parsing needs to be done on every startup (other than zmd, YaST does not have its own database and needs to read the information from the original metadata), maybe it just looks like it downloads everything again. Whether it really does should be visible in /var/adm/mount. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] libstdc++.la library
Pascal Bleser schrieb: Only those from the PackMan repo and other non-SUSE repos have references to libstdc++.la, and only if they are build for distros 10.2. Once there is a 10.2 PackMan repo with packages specifically built for 10.2, you don't need to worry any more. What makes you think that ? I'm convinced that you're not re-using old binary packages, but rebuilding everything from scratch. That makes me think that. AFAIK no one at Packman (nor do I with my packages) removes the .la files from the -devel packages, not even if they are for = 10.2. You don't need to remove anything. Rebuilding everything is sufficient. I have just verified that rebuilding mpeg4ip on a clean 10.2 system with no old binary packages on it results in a libmp4v2.la that has no references to /usr/lib/libstdc++.la in it. Nothing had to be removed manually in order to achieve that. libtool asks for libstdc++.la only if one of the other .la files in the chain references it, and other .la files only reference it if libstdc++.la existed when the package was built. The conclusion is that cleanly rebuilding everything solves the problem. Given that libstdc++.la has been removed months ago and that there are 4000 source packages in the distribution which are all still building, and given that re-using old binary packages is broken anyway, I don't think that this breaks builds which wouldn't have been broken anyway until a build log shows it. If it is, it should be discussed with those package maintainers at Packman. I don't know what needs to be discussed here, re-using old binary packages is clearly broken, cannot work for all kinds of other reasons besides this one and we don't know if it has been discussed even with the package maintainers at SUSE. I doubt it, but don't know it. A package maintainer shouldn't even notice the absense of libstdc++.la. If I read and understand correctly what anyone can read on [opensuse-bugs] and [opensuse-commit], the usual practice is that a package maintainer changes whatever he likes and the others follow it by fixing their failed builds, if any. Maybe these discussions behind closed doors where the community is locked out don't exist at all. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] libstdc++.la library
Juan Erbes schrieb: I have downloaded the cinelerra sources, and building from zero, I got the same error: if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../common/faad -I../common/mp4ff -O2 -g -O2 -MT audio.o -MD -MP -MF .deps/audio.Tpo -c -o audio.o audio.c; \ then mv -f .deps/audio.Tpo .deps/audio.Po; else rm -f .deps/audio.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../common/faad -I../common/mp4ff -O2 -g -O2 -MT getopt.o -MD -MP -MF .deps/getopt.Tpo -c -o getopt.o `test -f '../common/faad/getopt.c' || echo './'`../common/faad/getopt.c; \ then mv -f .deps/getopt.Tpo .deps/getopt.Po; else rm -f .deps/getopt.Tpo; exit 1; fi /bin/sh ../libtool --mode=link g++ -O2 -g -O2 -o faad main.o audio.o getopt.o ../libfaad/libfaad.la ../common/mp4ff/libmp4ff.la -lmp4v2 -lmp4v2 mkdir .libs libtool: link: cannot find the library `/usr/lib/libstdc++.la' make[5]: *** [faad] Error 1 This means that one of libfaad.la libmp4ff.la libmp4v2.la still have /usr/lib/libstdc++.la in their dependency_libs line. You are sure that there are no precompiled 10.1 binary packages on your system, not even libmp4v2? The other option is that You include the cinelerra application in the building service, for include it in the distro. Opensuse do'nt has any acceptable video editor, and I mean cinelerra is the best opensource option. Cinelerra will never be distributed on any opensuse.org server because it depends on libraries that implement patented algorithms. As you can see above, there are libfaad and libmp4ff and libmp4v2 linked in = Sorry, not possible. There are video editors that depend only on free codecs in the distro. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] libstdc++.la library
Juan Erbes schrieb: Yes I have installed from the packman repo some binaries, and I have: /usr/lib/libfaad.la /usr/lib/libmp4v2.la But I do'nt remember from what packages they are. OK, then please do: rpm -qf /usr/lib/libfaad.la rpm -qf /usr/lib/libmp4v2.la This will tell you which packages they belong to. These packages need to be rebuilt. Alternatively, you can manually remove all references to libstdc++.la from them: sed -i 's/\/usr\/lib\/libstdc++.la//g' /usr/lib/libfaad.la sed -i 's/\/usr\/lib\/libstdc++.la//g' /usr/lib/libmp4v2.la In general, you can't take binary packages from distro X and install them on distro X+1. It's sometimes working, but fails often in rather obscure ways. Andreas Hanke - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] libstdc++.la library
Juan Erbes schrieb: I have in /usr/lib about 300 files of .la libraries. I mean that I need to format the system disk and installing from zero. What You mean? No, of course not. You need to identify which of these .la files come from old binary packages that have been built for an earlier distribution, and re-build them (but just these old packages and not all). Or remove the libstdc++.la references manually from these affected/old files. Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
