June 2012 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] akonadi will not start :^(
by Patrick Shanahan 28 Jun '12

28 Jun '12

somehow akonadi is broken and will not start meaning no calendar, ... openSUSE 12.1+ Tumbleweed error messages at: http://wahoo.no-ip.org/~pat/akonadi-selftest-report-20120627.txt possible troubleshooting from google provides no solution route as I can determine, but .... tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 7

[opensuse-factory] Yast Grub2 Boot Loader missing title edit field
by Roman Bysh 28 Jun '12

28 Jun '12

Hello all, Beta 2 was when the new Grub2 Boot Loader first came out with more editing features - similar to Grub1. As in Grub1, we were able to edit the title. However,this field is missing. Is it up and coming? Or should I report it as a bug? Cheers! Roman --------------------------------------------------------------- openSUSE -- Get it! Discover it! Share it! --------------------------------------------------------------- http://linuxcounter.net/ #179293 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 6

[opensuse-factory] Repository GNOME:Contrib is dead
by Atri 28 Jun '12

28 Jun '12

Hi! Please note that the repository GNOME:Contrib [1] is now dead. Packages previously in this repository have all been pushed to Factory. If this is in the list of your subscribed repositories, please remove it (using zypper rr <reponame> or from YaST, etc.) Thanks and bye. -- Atri [1] This used to be the development branch of GNOME packages living in Contrib http://download.opensuse.org/repositories/GNOME:/Contrib/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Python for after 12.2
by todd rme 27 Jun '12

27 Jun '12

Considering all of the talk about improving openSUSE quality, and with 12.2 branched, I would like to discuss somewhat how to move forward with Python packaging in openSUSE. There are three big things happening right now with Python for openSUSE. First, and most prominently, is Python 3. Python 3 has been supported on openSUSE since at the latest 11.4. However, Python 2.x still remains the default, but it will no longer be getting upstream updates. At the present time I don't see that being quite ready to change, since some critical packages (like django, wxpython, and matplotlib) are still Python 2-only. Unless all of those, and probably some others, support Python 3 by the next openSUSE release, I don't think switching will work. We probably need a list of packages that need python 3 support before we switch to python 3 by default. That doesn't mean Python 3 doesn't matter. I and several others have been working to get Python 3 support for most critical Python packages available for openSUSE 12.2. I think we have largely succeeded. For the next openSUSE release, I think we should have a policy that, if a new python package is submitted that has upstream Python 3 support, it must be submitted with both Python 2 and Python 3 versions of the package. There might even be a policy that any packaging of a new version of a python package that supports Python 3 should also have the Python 3 version packaged, but that may be going too far. Further, I think we should have an embargo on any new Python packages that do not have Python 3 versions and don't appear to have been updated within the last couple of years, since it is unlikely such packages would ever get a Python 3 version. Of course exceptions can be made on a case-by-case basis, for instance if the package is a dependency of an important Python package. In the end I don't think we really want unmaintained software to begin with, but this is all the more serious when it is unmaintained software that depends on deprecated, unmaintained software. There is an issue that some Python packages install non-versions software, such as in /usr/bin. This makes installing Python 2 and 3 versions in parallel difficult. For the next openSUSE release I intend to implement update-alternatives for these files, so users can easily switch between running Python 2 and Python 3 versions. This also solves some issues where Python 3 versions of packages depend on the Python 2 versions. I know there is a Python Package Index Reader that scans pypi for updated packages. I don't know how it works myself, but is there a way to also scan to see if the package supports Python 3? They should have one or more of the following categories: "Programming Language :: Python :: 3", "Programming Language :: Python :: 3.0", "Programming Language :: Python :: 3.1", "Programming Language :: Python :: 3.2", or "Programming Language :: Python :: 3.3". Sending regular email alerts about such packages that do not yet have Python 3 versions would be nice. Also, currently most Python 3 packages that use the same tarballs as the Python 2 versions have the Python 3 version link to the Python 2 version, which has Python 2 and Python 3 spec files. I would like to turn this around for the next openSUSE release, so the Python 2 version links to the Python 3 version and the Python 3 version is the official factory devel package. The point of all of this is to ease the transition to having Python 3 as the default easier, which I expect will likely will happen wit2 release after 12.2, judging by the rate of progress of upstream Python 3 porting. Basically most or all of the tasks that are needed before we would be ready to switch the default Python version should be done for the next openSUSE release. There are 3 other issues, which are more openSUSE-specific. First is the new python autodeps system, which should allow the requires of Python 2 and 3 packages to be automatically detected. This will make packaging python easier and installing python packages more reliable. It still needs testing. I suggest a tiered approach: first, which I am doing now, I am testing it against all the python packages in devel:languages:python3. If that seems to work, I will then switch to implementing it directly in devel:languages:python3. If that works, I also implement it in devel:languages:python. If that works, it can be implemented globally (at least for Factory build targets). The second is --record-rpm. This allows python to automatically list files that are then used by rpm file lists. As far as I understand this is an openSUSE-specific hack whose use is now discouraged. It also leads to some problems, especially if the upstream package name changed. If this understanding is correct, I think this should be officially deprecated, with a plan to remove it for 2 releases after 12.2. For the release after 12.2, I think it should go through a few stages. First, add an rpmlint warning about the use of this build option. After a couple months, upgrade the badness of this warning so it causes an automatic package failure. A few months after that, change the warning to an error. No packages in Factory should use the option. Finally, there is the use of the common %{python_sitelib}/* and %{python_sitearch}/* items in the rpm files list. These have been used a lot because they make packaging easier. However, they have the disadvantage, in my opinion, that there can be (and are) major changes in the upstream package, even complete name changes, that go undetected because these commands essentially match every possible python file. I think we should discourage this in the wiki, reject new packages that use it, and add an rpmlint warning for it, with the goal of removing this entirely from the next openSUSE release. So does anyone have opinions on these proposals? I know this is a big wall of text, so I can break it up into individual messages with different issues you think that would simplify reading or discussion. -Todd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 8

[opensuse-factory] KDE and Gnome Live CD Builds broken
by Larry Finger 27 Jun '12

27 Jun '12

Coolo, I am not sure how long I should wait to report a broken build. Please give me some guidance. Since at least June 25 at 16:00 UTC, the KDE Live CD fails to build with buildinfo is broken... it says: unresolvable: nothing provides libqt4 = 4.8.1 needed by libqca2, nothing provides libqt4-sql = 4.8.1 needed by libqt4-sql-mysql, nothing provides libqt4 = 4.8.1 needed by qt4-qtscript Since the update of GCC4.7 on June 27, the Gnome Live CD fails with [364/1566] installing libquadmath47-4.7.1_20120615-4.3 file /usr/lib64/libquadmath.so.0.0.0 from install of libquadmath47-4.7.1_20120615-4.3.x86_64 conflicts with file from package libquadmath46-4.6.3_20120301-6.1.x86_64 Thanks, Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] 12.2 repo availability
by Felix Miata 27 Jun '12

27 Jun '12

I keep seeing comments like "I changed my package list update script to point to openSUSE:12.2" & "branched 12.2", but on mirrors all I see that ID as 12.2 (as opposed to 12.2M5 or 12.2Beta2) when "installed" are: http://download.opensuse.org/factory/ http://download.opensuse.org/factory-snapshot/ http://download.opensuse.org/factory-tested/ Has 12.2 actually branched off of Factory, or am I just not finding the latest's secret hiding place(s) on the mirrors? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] JUNE 30 / JUL 1 GNOME Bug Squash Days
by Dominique Leuenberger a.k.a DimStar 27 Jun '12

27 Jun '12

Fellow Geekos, As we're running towards the end of the 12.2 release cycle, the gnome team is planning a openSUSE 12.2 GNOME Bug Squash weekend on Jun 30 / Jul 1. The goal is simple: no more gnome related bugs in the 12.2 release :) (ok, we ARE optimists). The current bug tracker for GNOME related bugs on 12.2 already is in rather good shape: https://bugzilla.novell.com/buglist.cgi?cmdtype=runnamed&namedcmd=GNOME%201… there are currently 26 open bugs on component GNOME registered for openSUSE 12.2, but this just is not good enough yet. We will gather on Saturday in our usual IRC Channel #opensuse-gnome @ irc.freenode.net. You're all welcome to help out making the best ever GNOME 3 experience available on the planet! We need help in: - Finding bugs - Validating bugs - FIXING bugs (that's the most crucial one! The goal is to have a lower bug count at the end, not a higher one... but it's important to have a realistic picture as well). Thanks for participating! We're looking forward to a fun weekend! Best regards, Dominique / DimStar -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 9

[opensuse-factory] Build cycles versus rebuild="local"
by Michal Vyskocil 27 Jun '12

27 Jun '12

Hallo all, as a Java package maintainer I did a lot of work to avoid bootstrapping issues (aka build cycles) in openSUSE. That ends in a situation we have been never able to submit maven into build service, because it creates a **huge** list of dependencies, so with rebuild="transitive" it will kill any cluster we will find a budget for ;-) However with a newly introduced Scheduling Strategies feature, collo have used rebuild="local" for Factory, so now we have the cycles in Factory [2]. But probably because of the changed scheduling strategy, coolo did not blame me as in a past for cycles I've introduced in a past. But maybe both are tiny comparing to acl->zlib. Did we changed the approach here? Especially Java packages, where cycles exists in upstream and no one other takes a care it will be a huge step forward. And in this case it even do not block the bootstrapping to an another architecture, as packages are mostly noarch, so can be used everywhere. BTW: for Java packages we can be even more relaxed and use rebuild="manual" and did it only on major jdk change as we did yet jdk6->jdk7. [1] http://enstage.opensuse.org/openSUSE:Build_Service_Concept_build_scheduling… [2] https://build.opensuse.org/project/repository_state?project=openSUSE%3AFact… Regards Michal Vyskocil

3 4

[opensuse-factory] WT*---isn't this a bit large and drastic for a weekly update?
by Linda Walsh 27 Jun '12

27 Jun '12

Got this from a cron job: running weekly cronjob scripts SCRIPT: opensuse.org-online_update exited with RETURNCODE = 103. SCRIPT: output (stdout && stderr) follows The following NEW patch is going to be installed: openSUSE-2012-313 The following packages are going to be upgraded: libsolv-tools libzypp libzypp-testsuite-tools perl-zypp python-zypp zypper zypper-log 7 packages to upgrade. Overall download size: 4.5 MiB. After the operation, additional 99.0 KiB will be used. Continue? [y/n/?] (y): y Warning: One of installed patches affects the package manager itself. Run this command once more to install any other needed patches. SCRIPT: opensuse.org-online_update ------- END OF OUTPUT --- So being the naive idiot that I am, I find the script and run it again -- but this time: sudo /etc/cron.weekly/opensuse.org-online_update The following NEW packages are going to be installed: capi4linux-32bit python-virtinst The following NEW patches are going to be installed: openSUSE-2011-58 openSUSE-2011-98 openSUSE-2012-150 openSUSE-2012-152 openSUSE-2012-153 openSUSE-2012-154 openSUSE-2012-155 openSUSE-2012-156 openSUSE-2012-157 openSUSE-2012-158 openSUSE-2012-160 openSUSE-2012-163 openSUSE-2012-165 openSUSE-2012-166 openSUSE-2012-167 openSUSE-2012-170 openSUSE-2012-174 openSUSE-2012-175 openSUSE-2012-176 openSUSE-2012-179 openSUSE-2012-182 openSUSE-2012-183 openSUSE-2012-186 openSUSE-2012-188 openSUSE-2012-190 openSUSE-2012-192 openSUSE-2012-193 openSUSE-2012-195 openSUSE-2012-197 openSUSE-2012-198 openSUSE-2012-201 openSUSE-2012-203 openSUSE-2012-205 openSUSE-2012-206 openSUSE-2012-207 openSUSE-2012-208 openSUSE-2012-210 openSUSE-2012-212 openSUSE-2012-213 openSUSE-2012-214 openSUSE-2012-215 openSUSE-2012-217 openSUSE-2012-218 openSUSE-2012-220 openSUSE-2012-221 openSUSE-2012-222 openSUSE-2012-223 openSUSE-2012-225 openSUSE-2012-227 openSUSE-2012-228 openSUSE-2012-229 openSUSE-2012-230 openSUSE-2012-231 openSUSE-2012-232 openSUSE-2012-233 openSUSE-2012-234 openSUSE-2012-236 openSUSE-2012-237 openSUSE-2012-239 openSUSE-2012-241 openSUSE-2012-242 openSUSE-2012-244 openSUSE-2012-245 openSUSE-2012-248 openSUSE-2012-249 openSUSE-2012-252 openSUSE-2012-253 openSUSE-2012-254 openSUSE-2012-255 openSUSE-2012-257 openSUSE-2012-258 openSUSE-2012-259 openSUSE-2012-261 openSUSE-2012-264 openSUSE-2012-265 openSUSE-2012-268 openSUSE-2012-270 openSUSE-2012-271 openSUSE-2012-272 openSUSE-2012-273 openSUSE-2012-275 openSUSE-2012-277 openSUSE-2012-278 openSUSE-2012-279 openSUSE-2012-280 openSUSE-2012-282 openSUSE-2012-285 openSUSE-2012-286 openSUSE-2012-288 openSUSE-2012-289 openSUSE-2012-290 openSUSE-2012-293 openSUSE-2012-295 openSUSE-2012-297 openSUSE-2012-299 openSUSE-2012-300 openSUSE-2012-301 openSUSE-2012-302 openSUSE-2012-303 openSUSE-2012-304 openSUSE-2012-307 openSUSE-2012-308 openSUSE-2012-310 openSUSE-2012-311 openSUSE-2012-316 openSUSE-2012-317 openSUSE-2012-318 openSUSE-2012-320 openSUSE-2012-321 openSUSE-2012-82 The following package is going to be REMOVED: osc-source_validator The following packages are going to be upgraded: ImageMagick ImageMagick-devel ImageMagick-doc ImageMagick-extra Mesa Mesa-32bit Mesa-devel MozillaFirefox MozillaThunderbird MozillaThunderbird-translations-other NetworkManager-kde4-libs NetworkManager-pptp-kde4 NetworkManager-vpnc-kde4 aaa_base aaa_base-extras apache2-mod_php5 bash bash-devel bash-doc bash-loadables bind bind-chrootenv bind-devel bind-doc bind-libs bind-utils btrfsprogs build build-mkbaselibs chromium chromium-desktop-gnome chromium-suid-helper cifs-utils coreutils evolution evolution-data-server evolution-data-server-devel evolution-data-server-doc evolution-devel evolution-mono-plugins evolution-python-plugins expat fileshareset freetype2-devel glchess glibc-32bit glibc-devel-32bit glibc-i18ndata glibc-info glibc-locale glibc-locale-32bit glibc-utils gnome-games-recommended gnome-games-support gnome-panel-applet-tracker gnome-session gnome-session-core gnome-session-default-session gnome-shell gnome-sudoku gnomine gnutls gtkhtml-devel gvfs gvfs-backend-afc gvfs-backends gvfs-fuse gvfs-lang hwinfo hwinfo-devel iagno icecast icedtea-web iproute2 jakarta-commons-net kadu kdebase3-runtime kernel-firmware klogd krb5-debuginfo ldapsmb libMagick++5 libMagickCore5 libMagickWand5 libblkid-devel libblkid1 libblkid1-32bit libcamel-1_2-29 libebackend-1_2-1 libebook-1_2-12 libecal-1_2-10 libedata-book-1_2-11 libedata-cal-1_2-13 libedataserver-1_2-15 libedataserverui-3_0-1 libegroupwise-1_2-13 libexpat-devel libexpat-devel-32bit libexpat1 libexpat1-32bit libfreebl3 libfreebl3-32bit libfreetype6 libfreetype6-32bit libgnutls-devel libgnutls-extra-devel libgnutls-extra28 libgnutls28 libgnutls28-32bit libgtkhtml-4_0-0 libgtkhtml-editor-4_0-0 libgudev-1_0-0 libgudev-1_0-0-32bit libgvfscommon0 libgvfscommon0-32bit libldb1 liblightdm-qt-1-0 libmount1 libmount1-32bit libmtp9 libmysqlclient-devel libmysqlclient18 libmysqlclient_r18 libmysqld18 libopenssl-devel libopenssl1_0_0 libopenssl1_0_0-32bit libpng12-0 libpng12-0-32bit libpng12-devel libpng12-devel-32bit libpng14-14 libpng14-14-32bit libpng14-compat-devel libpng14-devel libpoppler-glib8 libpoppler-qt4-3 libpoppler18 libpq5 libpython2_7-1_0 libpython2_7-1_0-32bit libpython3_2mu1_0 libreadline6 libreadline6-32bit libreoffice libreoffice-help-en-US libreoffice-icon-theme-tango libreoffice-mailmerge libreoffice-pyuno libsensors4 libsensors4-32bit libsensors4-devel libsmbclient0 libsnmp30 libsoftokn3 libsoftokn3-32bit libtag1 libtag_c0 libtalloc-devel libtalloc2 libtalloc2-32bit libtdb-devel libtdb1 libtdb1-32bit libtevent0 libtevent0-32bit libtiff-devel libtiff3 libtiff3-32bit libtracker-extract-0_12-0 libtracker-miner-0_12-0 libtracker-sparql-0_12-0 libudev-devel libudev0 libudev0-32bit libupower-glib1 libuuid-devel libuuid1 libuuid1-32bit libv8-3 libwbclient-devel libwbclient0 libwbclient0-32bit libxml2 libxml2-32bit libxml2-devel libzip2 lightdm lightdm-qt-greeter lightsoff lxc mahjongg man-pages mdadm misc-console-font module-init-tools mozilla-js mozilla-js192 mozilla-js192-32bit mozilla-nspr mozilla-nspr-32bit mozilla-nspr-devel mozilla-nss mozilla-nss-32bit mozilla-nss-certs mozilla-nss-certs-32bit mozilla-nss-devel mozilla-nss-tools mozilla-xulrunner192 mozilla-xulrunner192-devel mysql-community-server mysql-community-server-client nautilus-extension-tracker-tags net-snmp net-snmp-devel nscd obs-service-download_files obs-service-format_spec_file obs-service-source_validator openssl opera opera-gtk opera-kde4 osc perl-Any-Moose perl-SNMP php5 php5-ctype php5-dom php5-gettext php5-iconv php5-json php5-ldap php5-openssl php5-pdo php5-sqlite php5-tokenizer php5-xmlreader php5-xmlwriter plasmoid-networkmanagement pm-utils pm-utils-ndiswrapper poppler-tools postgresql python python-base python-base-32bit python-curses python-devel python-magic python-pam python-tk python-wxWidgets python-wxWidgets-devel python-wxWidgets-lang python-xml python3-base python3-doc-pdf python3-xml quadrapassel readline-devel readline-doc release-notes-openSUSE resource-agents rpm rpm-devel rpm-python samba samba-32bit samba-client samba-devel samba-doc samba-krb-printing samba-winbind samba-winbind-32bit sane-backends sane-backends-devel seamonkey seamonkey-dom-inspector seamonkey-venkman sensord sensors snmp-mibs subversion subversion-perl subversion-python subversion-ruby subversion-tools sudo sudo-devel suspend swell-foop sysconfig syslog-ng syslog-service systemd systemd-devel systemd-gtk t1lib t1lib-devel taglib tiff timezone timezone-java tracker tracker-gui tracker-miner-evolution udev upower util-linux uuidd virt-manager w3m w3m-inline-image wine wine-32bit wine-devel wine-gecko wireshark wireshark-devel xfdesktop xfwm4 xulrunner yast2-iscsi-client The following package is going to change vendor: syslog-ng -> openSUSE 324 packages to upgrade, 2 new, 1 to remove, 1 to change vendor. Overall download size: 482.3 MiB. After the operation, additional 42.5 MiB will be used. Continue? [y/n/?] (y): y Digest verification failed for krb5-debuginfo-1.9.1-24.3.1.x86_64.rpm. Expected d2791100626cad305c3a7e7e707921b7cfdae85db51b89458f5b9f011035b805, found e72306e77025acdc28f8b1dc76368389259d9c53efd33017f4db75b100e04785. Continue? [yes/no] (no): no Failed to provide Package krb5-debuginfo-1.9.1-24.3.1. Do you want to retry retrieval? [12.1_update_debug|dir:///share/suse/debug/update/12.1] Can't provide file './x86_64/krb5-debuginfo-1.9.1-24.3.1.x86_64.rpm' from repository '12.1_update_debug' History: - krb5-debuginfo-1.9.1-24.3.1.x86_64.rpm has wrong checksum Abort, retry, ignore? [a/r/i] (a): a Problem occured during or after installation or removal of packages: Installation aborted by user -------------------------------- Thank Goddess it died and didn't actually try to do the update!!! 482.3MB? Sure looks suspicious....going from 1-2 packages update to what looks to be almost an entire new distro??? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 6

[opensuse-factory] New naming scheme for openjdk
by Michal Vyskocil 27 Jun '12

27 Jun '12

Hallo all, we are thinking about a new naming scheme for openjdk package. The old jpackage.org compatible way makes a sense in a past, where there was so sloooow release schedule, that you'd have to use more than one major version of java at the same time. With a new Oracle's approach, this will change and a major version will be increased much faster. We switched to jdk7 recently, but the EOL ends on July 2014 [1] and jdk8 is in pre-release phase atm. Thus there won't be so big need or a possibility to have more than one major version maintained in openSUSE. So the current jpackage.org compatible scheme is pointless and only complicate things. I see a need to drop it and create a new naming scheme for us (the compatibility can be maintain on a level of capabilities). 1.) have one $NAME for current version (openjdk7 in in 12.2) and if we will need add a newest major release, but don't want to switch, we can have $NAME-next with such major release. 2.) adapt gcc approach and have $NAME package, which will require the proper packages with a versions. The next question is what will be in a name? I've looked on what other distros are doing ... # RPM distributions Most rpm distribution adapt the jpackage.org naming, so java-1.$MAJOR_VERSION.0-$VENDOR (we used underscores instead of dots) java-1.7.0-openjdk - the JRE java-1.7.0-openjdk-devel - the JDK (java et all) java-1.7.0-openjdk-src, demo, ... the rest # Debian Debian use quite complex scheme, there are virtual packages default-jre, default-jdk points to proper version. Source package is named openjdk-$MAJOR_VERSION (openjdk-7) and number of binary packages is quite big openjdk-7-jre - JRE using Hotspot VM (the standard one) openjdk-7-jdk - JDK openjdk-7-jre-zero - JRE using Zero assembler VM (extremly slow, but extremly portable) openjdk-7-jre-headless - the headless version, which don't require X11, pulseaudio et all, but contains JIT openjdk-7-jre-lib - noarch package contains some jar files for JRE openjdk-7-demo, openjdk-7-doc, openjdk-7-source - unimportant files icedtea-7-jre-cacao, icedtea-7-jre-jamvm are alternative virtual machines (provides own jre/lib/amd64/cacao/libjvm.so files) # Arch Linux openjdk7-src - source package jre7-openjdk-headless - headless version of runtime jre7-openjdk - rest of the runtime jdk7-openjdk - JDK # Rest * FreeBSD uses openjdk6 name for their port * Gentoo have icedtea6/icedtea7 as a name I'm looking forward on your hints BTW: note that OpenJDK is trademark [3] of Oracle, so there is a reason why Debian calls their packages with alternative VM icedtea instead. [1] http://www.oracle.com/technetwork/java/eol-135779.html [2] http://wiki.debian.org/Java/ [3] http://openjdk.java.net/legal/openjdk-trademark-notice.html Regards Michal Vyskocil

3 7

[opensuse-factory] Fwd: commit libavutil for openSUSE:Factory
by Dominique Leuenberger a.k.a DimStar 27 Jun '12

27 Jun '12

Hi everybody! Small topic I would like to raise awareness for (in best case it's only to have it documented): ----- Forwarded message from root(a)suse.de ----- Date: Fri, 15 Jun 2012 16:31:34 +0200 From: root(a)suse.de Subject: commit libavutil for openSUSE:Factory To: opensuse-commit(a)opensuse.org Hello community, here is the log from the commit of package libavutil for openSUSE:Factory checked in at 2012-06-15 15:41:42 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Comparing /work/SRC/openSUSE:Factory/libavutil (Old) and /work/SRC/openSUSE:Factory/.libavutil.new (New) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Package is "libavutil", Maintainer is "" Changes: -------- --- /work/SRC/openSUSE:Factory/libavutil/libavutil.changes 2012-06-13 13:31:48.000000000 +0200 +++ /work/SRC/openSUSE:Factory/.libavutil.new/libavutil.changes 2012-06-15 16:31:33.000000000 +0200 @@ -1,0 +2,5 @@ +Fri Jun 15 04:03:15 UTC 2012 - factory-maintainer(a)kulow.org + +- add -32bit library for xine to use + +------------------------------------------------------------------- So, that means we now do have libavutil in Factory? Has this be well planned and the side effects are well known? Especially be aware that PackMan and VLC Repo both carry this library as part of the ffmpeg builds. frankly, I'm *scared* of side effects being introduced here: PM / VLC will likely move to 'more recent' (or just 'different') versions of ffmpeg in no time. having libavutil now part of Factory will make it VERY likely to cause issues on all kind of applications coming from those repos; an updated ffmpeg in any of those repos will need to be SURE it gets libavutil51 ALSO from that repo. Was this addition a real NEED or just a 'nice to have without gain'? I mean: xine-lib STAYS crippled, there is nothing we can do. Adding libavutil does not change that. A user wanting full 'fun' still needs to replace parts of the dist... 'Adding' new software now might start to replace libs as well (VLC Repo for example used to have the rule to NOT carry libs that are part of the distribution, in order to never have to replace them... ) Or am I just seeing issues where there are none and all of the packman / vlc issues will not happen? Then I'm happy to hear that this will not introduce more trouble. Best regards, Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 5

[opensuse-factory] preliminary release notes update for 12.2
by Karl Eichwalder 27 Jun '12

27 Jun '12

Please, check the release notes and provide feedback (via bugzilla preferred). I just submitted a small update to Factory. These are basically the old release notes with checkit markers; many of them are systemd related. I still maintain the document at Berlios: https://svn.berlios.de/svnroot/repos/opensuse/trunk/documentation/release-n… Editor accounts are available on request ;) -- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 16

[opensuse-factory] Status: Beta2
by Stephan Kulow 27 Jun '12

27 Jun '12

Hi, I'll upload Beta2 any time soon (build451 basically) and after that create and bootstrap openSUSE:12.2 I'm not yet sure where to put the resulting FTP tree, but we'll find a place :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

11 16

[opensuse-factory] Google Earth crashes Xorg/KDE in Opensuse 12.2 X86-64 Factory
by Juan Erbes 26 Jun '12

26 Jun '12

>From 2 weeks I tryed to make to work Google Earth, and I got many errors relating to many libraries. The package is google-earth-stable_current_x86_64.rpm But it need many 32 libraries like this: libfontconfig.so.1 libfreetype.so.6 libX11.so.6 libXrender.so.1 libXext.so.6 libGL.so.1 After installing all the 32 bits libraries, Google Earth loads, but befofore it completes the loading process, Xorg/KDE crashes and falls back to the kdm login screen. I do'nt registered a bug in Bugzilla, because Google Earth not depends on opensuse. The Backtrace of the /var/log/Xorg.0.log is this: [ 6277.754] [ 6277.755] Backtrace: [ 6277.763] 0: /usr/bin/Xorg (xorg_backtrace+0x36) [0x564306] [ 6277.763] 1: /usr/bin/Xorg (0x400000+0x168039) [0x568039] [ 6277.763] 2: /lib64/libpthread.so.0 (0x7f67cc379000+0xf140) [0x7f67cc388140] [ 6277.763] 3: /usr/lib64/dri/r600_dri.so (0x7f67c53b9000+0x2e6509) [0x7f67c569f509] [ 6277.763] 4: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f67c7c3b000+0x39cb4) [0x7f67c7c74cb4] [ 6277.763] 5: /usr/lib64/xorg/modules/extensions/libglx.so (0x7f67c7c3b000+0x3c703) [0x7f67c7c77703] [ 6277.763] 6: /usr/bin/Xorg (0x400000+0x388a1) [0x4388a1] [ 6277.763] 7: /usr/bin/Xorg (0x400000+0x27965) [0x427965] [ 6277.763] 8: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f67cb228455] [ 6277.763] 9: /usr/bin/Xorg (0x400000+0x27c3d) [0x427c3d] [ 6277.763] [ 6277.763] Segmentation fault at address 0xffa7423c [ 6277.763] Fatal server error: [ 6277.763] Caught signal 11 (Segmentation fault). Server aborting [ 6277.763] [ 6277.763] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 6277.763] Please also check the log file at "/var/log/Xorg.0.log" for additional information. [ 6277.763] [ 6277.764] (II) evdev: Power Button: Close [ 6277.764] (II) UnloadModule: "evdev" [ 6277.764] (II) evdev: Power Button: Close [ 6277.764] (II) UnloadModule: "evdev" [ 6277.765] (II) evdev: Genius Optical Mouse: Close [ 6277.765] (II) UnloadModule: "evdev" [ 6277.766] (II) evdev: AT Translated Set 2 keyboard: Close [ 6277.766] (II) UnloadModule: "evdev" [ 6277.766] (II) AIGLX: Suspending AIGLX clients for VT switch [ 6277.775] Server terminated with error (1). Closing log file. I use the open source radeon driver (from "/var/log/Xorg.0.log": [ 41.464] (II) RADEON(0): EDID vendor "SAM", prod id 439 [ 41.464] (II) RADEON(0): Using EDID range info for horizontal sync [ 41.464] (II) RADEON(0): Using EDID range info for vertical refresh [ 41.464] (II) RADEON(0): Printing DDC gathered Modelines: [ 41.464] (II) RADEON(0): Modeline "1280x1024"x0.0 108.00 1280 1328 1440 1688 1024 1025 1028 1066 +hsync +vsync (64.0 kHz eP) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Bug 768929 entered for segfaulting firefox
by Jogchum Reitsma 26 Jun '12

26 Jun '12

Hi, I entered bug nr. 768929 for Firefox segfaulting after installing M4, and after zypper up'ing until today Jogchum -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

1 0

[opensuse-factory] Is there a chance that this problem will be fixed?
by Ilya Chernykh 26 Jun '12

26 Jun '12

I was waiting for the promised in the changelog "separate packages" for several months, but now we face the release and there is no indication that the C++ API package is going to be submitted. I very much urge everybody not to break things if you are not going to fix it. https://bugzilla.novell.com/show_bug.cgi?id=768819 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] EOG issue in 12.1 Tumbleweed
by Carl Fletcher 25 Jun '12

25 Jun '12

Eye of Gnome fails to start. Issue eog in a terminal, results in (eog:5956): GLib-GIO-CRITICAL **: Timeout was reached rpm -qi eog Name : eog Version : 3.2.2 Release : 2.4 Architecture: x86_64 Install Date: Sat 23 Jun 2012 04:47:17 BST Group : Productivity/Graphics/Viewers Size : 1965107 License : GPLv2+ ; LGPLv2.1+ Signature : DSA/SHA1, Thu 21 Jun 2012 23:13:42 BST, Key ID 01a7de5aa840f92c Source RPM : eog-3.2.2-2.4.src.rpm Build Date : Thu 21 Jun 2012 23:11:57 BST Build Host : build24 Relocations : (not relocatable) Vendor : obs://build.opensuse.org/openSUSE:Tumbleweed URL : http://www.gnome.org/ Summary : Image Viewer for GNOME -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] Motivation of community maintainers(Was: Calling for a new development model by coolo)
by Marguerite Su 25 Jun '12

25 Jun '12

Hi, all, I don't know much on the infrastructure thing like being talked in the original topic. I did notice some projects of our current development model didn't response well. According to coolo, some factory packages didn't got fixed in two weeks or more, even if we have email notification and a factory repository enabled in all devel projects. It means if you login b.o.o every day, you must be able to notice that your package fails. But some projects of our current development model responses very well. (like auto-build team) Those two apparently different situations both happened under the same development model. So personally I think it's not because we have faults or bias on the design part of current development model. So why everyone of us are so _hurry_ to design a new model for one of our major release? It requires many collaborations. For instance, if we want to raise the priority of Tumbleweed, we have to adjust a lot of things like OBS, tumbleweed team and almost every other teams' focuses. I think it's foreseeable that we won't finish it in a short time. Especially we are under such a tough situation that many repository maintainers are not available right now. (everyone knows they are absent, but no one knows where they are absent for/to.) They can't be awaken under a very short time like two or three months. So I think the temporary solution to 12.2 is that we existing active maintainers have to contribute more. Instead of blaming and marking invalid or "won't fix", we have to fix every bug we met and are able to fix. Actually personally I think it's not because current development model are not "good", but we lack of a supervisor system to push it to be good. We didn't educate our maintainers so well to let them know their responsibilities. (eg: they have to test the package in his maintaining repository for stability, to make them build for factory, to answer bug reports, instead of just accept and forward. Because they have super permissions than ordinary packagers, they have to take the related responsibilities) Every existed and to-be-designed development model is based on one simple hypothesis, that is, every( or most of, majority of) maintainer is active, especially repository maintainers. But it's not the case right now. we have almost 30000 packagers on b.o.o, but anyone ever calculate the active ratio? It must be very regretful. Imagine now we have 30000 email senders to this mailing list, it must be a huge traffic. but it's not the case right now. I guess we have an active ratio even lower than packman. (they have only 100+ maintainers, but their mailing list is as busy as ours) So now the case is: we are not lacking of maintainers and bug fixers, but lacking of active ones. you know, we're a big FOSS empire as big as Debian! So personally I think what we need to do is find a way to wake up our sleeping maintainers and packagers, instead of designing a new development model or something ASAP. (personally I think coolo mistakes one thing: it's not because we have too many maintainers so the current development model can't fulfill the needs, but we lack of enough active maintainers to make our engine running! the OBS traffic and infrastructure pressure mostly comes from those who builds but not builds for factory.) If there's anyone doesn't believe it, let's make a test(or ping, which is famous in accent Chinese kingdom, to hand out a report to every majors in his empire, and ask them to reply.), create a new account, to require "add role" permission from every devel project, then coolo will know which ones are active and which ones are silent. To solve this problem, personally I have a few ideas: 1. We have to kindly warn those silent repository and package maintainers two or three times, then do a clean. 2. Then we have promote some active packagers who are not maintainers yet. 3. Do it regularly. 4. we have to enable build failure notifications of devel repository/factory on hermes.o.o by default, and it can't be shutdown by yourself. you can mark it spam, but you can't shut it down. (I am the maintainer of M17N, and we have 3 sub projects and 320 packages. many of the package maintainers are promoted in 2007 or even earlier, I might be wrong about it, since I am fresh and don't know when we have OBS. but they didn't submit any single SR since then. many of them are even SuSE staff. they may even work for Windows now, girl! what if they didn't maintain their packages? oh others don't even know what his package is for.) 5. We need a check-in system. Not every package needs to be modified regularly. But we have to have the information that how many maintainers we still have. 6. We need a karma system. At first I want to be clear, everyone is born equal, but hard workers need to be encouraged. And a ranking system is not against our guiding principle, because we already have ranking systems like members and the board. But we're lacking of a quantified one. Nowadays if once you're an repository maintainer, you're still repository maintainer when you're died. We kept adding new ones, but then maintainers can shirk, "oh he will update that package". If everyone thinks so, then no one will update that package or fix that bug. Of course those karma doesn't mean anything, because no one here is payed to work except SuSE people. (But they do the works far beyond their salaries.) = For packagers: = Those karma can "exchange" build power on OBS. Today our OBS can build most of the packages in a short time (if OBS is not broken). But what if you're working on an important package? buy it. Those karma can "exchange" openSUSE member position. Today we're using manual selection, which requires a lot of work so reacts slow. And some losers might be question it. A quantified high karma which can't be earned in one or two years solves that problem. Those karma can "exchange" openSUSE gifts, like our lizard doll. Actually I was so active because last Xmas SuSE China sent me a lizard doll and a novell cup, I want a larger one this year. Gifts will be very valuable to newbies. If you have 30000 karma, why not deliver you a real lizard? XD. = For repositories: = The devel repositories' karma equals to the sum of their maintainers plus an adjustable amount from coolo, according to their recent busy hours and importance to our factory. Then no one will carelessly add those who will be certainly silent after a while.( because one's karma can be negative!) = How to earn karma? = By creating packages which are not in factory yet, by adopting existing unmaintained packages(no package will be dropped sadly), by developing features on f.o.o, by fix bugs on b.n.c, by answering question on mailing lists...... ( a high karma person's answer might be more useful. after we have a karma system, I personally no longer need to get the first impression by name or email address, it's pure guess who to trust nowadays, you know, to a fresh woman and a so called foreigner like me, every foreign nickname looks the same to me) Things like that, and by check-in every day (a check-in means 1 point. And since you're on b.o.o every day, why not fix some minor bugs?). If you're not active, those karma will fade. drop 1 point per day. or you didn't claim to fix your bug, it will drop some amount. If you got a negative karma, you have to work a lot to make it positive. after you got a certain negative number of karma like -30, sorry, you build power is limited. like lauchpad, you have to wait certain hours to queue your builds. Some of the karma are forever. like contributing to 12.2 will +3 golden points. it will not fade and is commemorate. But such karma can't let you be in a repository maintainer status forever, because repository maintainership will require 30 points. This karma system is ported from plurk, launchpad, foursquare and many existing social networks. It's been tested for a long time and useful to maintain active ratio. And it can be port to almost everywhere like our connect.o.o, our planet, our forums and more, even to board election( without 100 points? sorry, you can't be a candidate; love coolo? give him 3000 points and buy him a chairman!). Those are just thoughts and personal ideas I think we should have. If interested, we can improve them; if not, it will not weaken the faith I hold on openSUSE. Greetings, Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 1

[opensuse-factory] Please help with lilypond
by Dave Plater 25 Jun '12

25 Jun '12

Reading another thread on the factory list has prompted this request. I'm currently computerless and am unable to finish lilypond which currently has two problems : 1) It currently requires gnutls-extra for it's build, this is easy to fix and if this stupid phone could download spec (text) files I could have fixed it myself. 2) The documentation part of the build takes far too long. This I started to fix on by putting the doc build in a linked package and not building the "lilypond snippets". This is still WIP. The documentation used to be available as a large separate tarball but I couldn't find it in my last moments at the pc so my plan is to leave it out as the docs are duplicated online at lilypond.org. Dave -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

2 2

[opensuse-factory] The languished meaning of "maintainer" (was: Calling for a new openSUSE development model)
by Jan Engelhardt 25 Jun '12

25 Jun '12

Robert Schweikert wrote in http://lists.opensuse.org/opensuse-factory/2012-06/msg00489.html : > >I believe that an underlying issue to the overall state is the package >maintenance model. Look at any perl or python package in the devel >projects and you'll find tons of people listed as "maintainers" but >almost non of them is a "true" maintainer. Everyone of the listed >"maintainers" is inherited from some parent project and in the end no >one really feels responsible. Indeed - but: it is the way it is represented in the webui that is misleading. If you use the command line client, `osc meta pkg`, you get a *much* more useful and concise set of people - and usually the people who *really are* responsible. If the so-obtained list is empty, you can consider the package abandoned already. >That this is an issue is also evident in the increased mail traffic on >the list about lingering SRs. The problem with lingering SRs has more to do with the "maintainer"-called role being overloaded - *in prj context*. I concur with your observation. 22 "maintainers" in games, 42 in devel:libraries:c_c++ don't paint a good picture. But server:irc's list of 8 also sports the linger problem. There are a handful of prj-level actions: - the true maintainer, IOW, "I maintain indeed all packages in here". This only makes sense for a limited set of develprjs, predominantly those that deal with a single "software stack" (a group of obviously related packages). Examples are network:mail:zarafa, network:telephony:asterisk*. But not games, not d:l:c_c++. - fallback maintainer: responsibility to accept lingering SRs not having been accepted by the bspkg maintainer in a handful of days (3/5/7? maybe settable within the pkgmeta?), provided they meet best judgment. - mentor: responsibility to 1. decline *new* packages - sorting out unsuitable license, ...; 2. approve new packages and perhaps send corrections immediately afterwards, ...; These extra roles are merely for self-description of users, and should simply have the same commit permissions as the current "maintainer" role do now. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 4

[opensuse-factory] Calling for a new openSUSE development model
by Stephan Kulow 25 Jun '12

25 Jun '12

Hi, It's time we realize delaying milestones is not a solution. Instead, let's use the delay of 12.2 as a reason to challenge our current development model and look at new ways. Rather than continue to delay milestones, let's re-think how we work. openSUSE has grown. We have many interdependent packages in Factory. The problems are usually not in the packages touched, so the package updates work. What's often missing though is the work to fix the other packages that rely on the updated package. We need to do a better job making sure bugs caused by updates of "random packages" generate a working system. Very fortunately we have an increasing number of contributors that update versions or fix bugs in packages, but lately, the end result has been getting worse, not better. And IMO it's because we can’t keep up in the current model. I don't remember a time during 12.2 development when we had less than 100 "red" packages in Factory. And we have packages that fail for almost five months without anyone picking up a fix. Or packages that have unsubmitted changes in their devel project for six months without anyone caring to submit it (even ignoring newly introduced reminder mails). So I would like to throw in some ideas to discuss (and you are welcome to throw in yours as well - but please try to limit yourself to things you have knowledge about - pretty please): 1. We need to have more people that do the integration work - this partly means fixing build failures and partly debugging and fixing bugs that have unknown origin. Those will get maintainer power of all of factory devel projects, so they can actually work on packages that current maintainers are unable to. 2. We should work way more in pure staging projects and less in develop projects. Having apache in Apache and apache modules in Apache:Modules and ruby and rubygems in different projects may have appeared like a clever plan when set up, but it's a nightmare when it comes to factory development - an apache or ruby update are a pure game of luck. The same of course applies to all libraries - they never can have all their dependencies in one project. But this needs some kind of tooling support - but I'm willing to invest there, so we can more easily pick "green stacks". My goal (a pretty radical change to now) is a no-tolerance strategy about packages breaking other packages. 3. As working more strictly will require more time, I would like to either ditch release schedules all together or release only once a year and then rebase Tumbleweed - as already discussed in the RC1 thread. Let's discuss things very openly - I think we learned enough about where the current model works and where it doesn't so we can develop a new one together. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

40 173

[opensuse-factory] Live CD/DVD Distro For Japanese
by Kiyomi Kakitsubata 25 Jun '12

25 Jun '12

How can I chenge my project like Live DVD(such as Japanese Localized openSUSE) unofficial to official? In Japan,Ubunts has onofficial Japanese remix distribution,so I want make like this whitch use openSUSE. However,I do not know where could I send e-mail and problem of trademark. What can I do ? Thanks ================================== Kazufumi Watanabe 　kikyo.kakitsubata(a)gmail.com ==2.71828182845904523536028747135== -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 3

[opensuse-factory] repository priorities with Tumbleweed
by Thomas Langkamp 23 Jun '12

23 Jun '12

Hi, what is the current suggestion of Greg KH to repository priorities running Tumbleweed? In the early days he suggested flat ones, over time more and more users reported (in forums) that a higher one for Tumbleweed (or even a complicated priority-hierarchy) works better. I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start. So I gave Tumbleweed a higher priority, but that did not help. Maybe I am doing something wrong? But even if my problem has nothing to do with the priorities, please think about my request: - add info on how to handle priorities on the SDB:Tumbleweed - Or even better: Add an automatism to zypper/yast that automagically sets the "right" priorities, while advanced users are still able to customize it Thanks vor Tumbleweed so far - it is great and I love it :D Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

7 9

Re: [opensuse-factory] repository priorities with Tumbleweed
by Cristian Morales Vega 23 Jun '12

23 Jun '12

On 22 June 2012 15:42, Thomas Langkamp <langkamp(a)tomblog.de> wrote: >> It's not like settings priorities was a big mystery. > > > If this would be the case, why would you write such a lengthy post about > explaining priorities: > http://forums.opensuse.org/english/get-technical-help-here/how-faq-forums/u… Because forums users don't read man pages. And it's so long because: a) I explain dist-upgrade, not just priorities. b) I adapted the text to the public: I repeat the same thing multiple times in different ways. > You do not say here: do not zypper dup with priorities on tumbleweed > But to me you imply the opposite: use zypper dup + priorities if you like > also with TW. > Now Greg K-H in contrary just again said not to give priorities with TW. I already explained why I think I "know better than Greg does" ;-) -> http://lists.opensuse.org/opensuse-factory/2011-11/msg00942.html In any case if you read http://en.opensuse.org/Portal:Tumbleweed you can see Greg only supports a basic repo configuration. If you use Packman you are already outside Greg recommendations (and the "zypper dup --from Tumbleweed" suggestion is biased towards Tumbleweed, doesn't really help with Packman). > So if you both do not agree each other - how could the common user not be > confused. This is why I asked to give an official statement on > SDB:Tumbleweed after the community reached an agreement on what is best and > then not to bother the user with it, but to let Tumblewee automaticaly > select the best priority. You can't set it automatically because priorities are *relative*. Settings a repository with priority 20 will have a different result if there is another repository with a higher priority or if all the other repos have priority 99. But since you read my post in the forum you already understand priorities, don't you? Please, answer these: - What will happen if you set Tumbleweed with a higher priority than the main repo? - What will happen if you set Tumbleweed with the same priority than the main repo? - What will happen if you set Tumbleweed with a lower priority than the main repo? After reading that post you should know the answers. So just decide what behaviour do you want. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

3 2

RE: [opensuse-factory] Re: Tumbleweed / python-kdebase4
by Will Stephenson 22 Jun '12

22 Jun '12

Calligra Replaces koffice2, will check the rest.

2 1