September 2012 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Packaging Guideline enforcement
by Dominique Leuenberger a.k.a DimStar 13 Sep '12

13 Sep '12

Dear Factory contributors and packagers, As openSUSE 12.2 is frozen and Factory is 'open to go wild' again, I would like to announce that the packaging guidelines have some extensions (not really new) that will be stricter enforced than they used to be. Currently a common rule to be 'ignored' or packagers are not aware is around the topics of: - .Changes entries - Patches First, the .changes entry (rpm changelog) surves two purposes: - News for the user - History tracking of … [View More]packaging changes (often referenced in bugs to verify if a user has the latest packaging bugfixeS). A simple "Update to version x.y.z" is, as before, not accepted. There should be some buzz around the update for the user; some major reasons to the upgrade should be listed Changes on the package itself should be mentioned in a way that any other contributor to the same package can follow traces of why something is the way it is. Commonly, Added (build)dependencies are interesting to be seen, special hacks to make something work in a particular way [..]: Always consider that package maintenance is a distributed task and various contributors need to be able to step up at will. Patches: The rules about patches are listed at http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines . Most prominent is likely the mentioning of the patches life cycle, which forces you to mention additions and removals of patches in the changelog. As history shows, this can be helpful if a patch got removed, and later a regression is reported; finding out when a patch was removed can be crucial in reconstructing feature sets (including contacting the contributor that dropped it.. which is easily extracted from the .changes if listed) The main appeal is to the devel project maintainers / reviewers, to keep out for those rules, to live according to them, as it is frustrating for everybody if a package needs to be declined by the Factory Review team: - The dev prj maintainer is the one getting the 'decline' (as it was usually a forwarded request), which often leaves the 'fixing' to the devel project maintainers, where the 'originator' of the fix would have been willing to actually do that... And the Factory Review team also prefers to see complying submissions to having to reject SRs... reject is not fun for anybody! Looking forward to many more SRs to accept! Dominique / DimStar -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

19 44

[opensuse-factory] plan for 12.3 - multiple Python runtimes
by Jan Matejek 13 Sep '12

13 Sep '12

fellow openSUSErs, with the advent of Python 3 and still almost unnoticeable decline of Python 2, i have come to a realization that the way we separate them into "python" and "python3" is less than ideal. The granularity of this can be often too coarse (you can't run two apps requiring two different python2 versions, unless they are specifically packaged and bring their own python runtime package), and too fine at the same time (there are already packages that don't actually care whether … [View More]they run in python 2 or 3) In the spirit of fixing what ain't broken, I humbly propose a grand plan: let's turn "python" into "python2.7", "python3" into "python3.3", and tinker with Provides until it all works just fine. Then, as a last step, symlink /usr/bin/python into /etc/alternatives and let the users pick whichever runtime they like better. This would probably go better if broken into several phases. My current idea is this: Phase 1: - rename "python" to "python2.7", providing "python = 2.7" - rename "python3" to "python3.3", providing "python3 = 3.3" - install the update-alternatives symlink Impact: - Unsure of what would happen on package upgrade. Would we need Obsoletes/Provides combo for this? Perhaps we'd have to create the metapackages outlined in the following phases at this point already. Phase 2: - unify RPM macros - python3 will have %py_(something) macros as well as %py3_(something) macros, the %py3_ versions being aliases to the %py_ versions - make python2.7 provide "python2 = 2.7" instead of "python = 2.7" - make a "python" meta-package requiring, at this time, python2 - each pythonX.Y package now only installs /usr/bin/pythonX.Y binary, python2 and python3 are alternatives for python2.Y and python3.Y respectively, and python is an alternative for either python2, python3, or a specific version. I don't know update-alternatives too well - is this even viable? Impact: - this should mark a clear upgrade path for each of the python variants and for the systemwide "default python" as well - at this phase, i would like to make it possible to build a package for any python (2 or 3 or 50) from the same specfile. i'm not sure that these outlined steps are enough, though. Originally I thought that every python would provide "python = X.Y" and the packages could select which "Requires: python" to pick through package or project meta. But that would result in a horrible breakage, and we need "python" as a separate package for upgrading in any case. We could use "python(abi)" symbol for this, or do the same just with "python-devel"? Any other options? Phase 3A: - when python 3.4 comes out, introduce a new package "python3.4", new meta-package "python3" requiring "python3.4", and corresponding alternatives Impact: - This is the other difficult one. What about lifetime of the pythonX.Y packages? What happens with old systems on perpetual-upgrade? Such as tumbleweed - will the old python runtimes rot there forever-and-ever, or can we force uninstall at some point? Perhaps "Obsoletes: python3 < 3.x" in the "python3" metapackage? Which versions do we support? The newest and the most popular, probably? I know we do something similar with gcc, how does it work there? Phase 3B: - steal and improve Debian's python-central (or however they call it these days) - designate /usr/lib/python-central or something similar for packages that don't want to depend on a specific python runtime version - introduce %post/%postun scriptlet macros for packages that would compile bytecode in /usr/lib/python-central for all known python runtimes on the system, and for pythons so that they compile every package for their versions. This is now actually fully supported by upstream, we can have as many different versions of bytecode for the -same- .py file as we want. Impact: - package can specify "Requires: python" and Just Work(tm) from now until eternity, or until it runs into a deprecated API. Or specify a range of pythons it wants to support - by the time we get here, I'm sure RPM will allow that ;e) With a limited ABI in python3, this can even work for arch-based packages across python minor versions. Phase 4: - when we decide to switch to python3 system-wide, make "python" require "python3" instead of "python2", change default alternative, and be done with it Impact: - breakage of packages still incompatible at that time. that will help us see what needs fixing and what needs to explicitly specify that it wants python2. Somewhere in this is lurking a possibility of supporting different python runtimes such as Jython, Cython, PyPy and whatever else crops up. That's neat, too. Thanks for your attention. Comments, questions? regards m. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

10 19

[opensuse-factory] rpm .repo release files
by Damian Ivanov 13 Sep '12

13 Sep '12

Hi ppl, In openSUSE for adding a repo we do a zypper ar $repo, the repo files are not owned by any rpm package AFAIK. Fedora has $REPO_NAME-release rpm in each repository installing the gpg key and the .repo file. Is there any purpose openSUSE not doing so or has this other reasons? Best regards, Damian -- 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] 12.3 GOAL: GStreamer 1.0 instead of 0.10
by Dimstar / Dominique Leuenberger 13 Sep '12

13 Sep '12

Hi all, I have another suggestion as a goal to work on for openSUSE 12.3, driven by the GNOME Stack: * Switch to GStreamer 1.0 * Rationale: GNOME 3.6 (to be released end of Sept 2012) has mostly (few exceptions) been ported to GStreamer 1.0 (latest releases of GStreamer are 0.11.93). GStreamer 0.10 and GStreamer CAN be parallel installed; but it's expected that once 1.0 is out, the 0.10 tree will only get very limited care by upstream. So not having to maintain it is surely recommended. … [View More]There are a few critical components, that we have to take into account though, but having it as a goal is, in my opinion, still worthy. * 3rd party codecs (fluendo) Having contacted Fluendo, I was re-assured that work on the codec packs is in full progress and communication between Fluendo and GStreamer hackers is well established. The 'mp3 codec' for example is available in git trees hosted by fluendo (and could thus be packaged for our favorite 3rd party codec repo) * Applications depending on GStreamer: We will have to compile a list of applications that require GStreamer. I did several (easy) ports myself, and it *can* vary from simply changing configure, through simple API replaces (there is a rather exhaustive 'Port to GStreamer 0.11 How-To', through to 'half rewrites'. Once a of apps is compiled, work can start. * Automatic codec installer PackageKit integrates with GST to automatically install codecs. This works sometimes more, sometimes less reliable. Would be a good moment to work with PackageKit upstream to sort those issues out as well. == RELEASE GOAL == The goal should be to have only GStreamer 1.0 in the repositories. == Test Plan == * Switch apps that do support it to GStreamer 1.0 * Verify functionality of the switched applications + If needed, work with upstream on a port to GStreamer 1.0 * This is NOT ONLY limited to GNOME Stack! Whereas the GNOME Stack is surely the most dominant driver here, there are multiple other apps depending on it as well. == Backout plan == Ship GStreamer 1.0 and 0.10, and have them parallel installable; GST 1.0 is the recommended version of GStreamer for GNOME 3.6 and will likely be required for GNOME 3.8 (due March 2013) == 3rd Party Repos == As there is also a multitude of additional repositories with GStreamer based software, it might simply not be feasible in the short term to drop GStreamer 0.10 entirely. If we think catering for this usecase is a must for the distribution, then the goal for us should at least be to have GStreamer 0.10 not to be installed in a standard install; having additional packages pull it in could be an option, Any thoughts on this? Shall we add it as a goal to our 12.3 GOAL site? Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

6 5

[opensuse-factory] Serious problem with Tumbleweed upgrade to 12.2
by superandrzej＠epf.pl 12 Sep '12

12 Sep '12

Hi, There is something seriously wrong with upgrade of Tumbleweed to 12.2 My Tumbleweed based on 12.1 was up to date day before 12.2 was announced. Yesterday I run actualization and now I'm not able to run X sever. First I thought that there was some bug in new version of X server related to my video card, but today my cousin with completely different hardware informed me about the same problem. I also googled out similar problems in opensuse forums e.g.: http://forums.opensuse.org/… [View More]

3 3

[opensuse-factory] RFC: MATE Desktop
by Nelson Marques 12 Sep '12

12 Sep '12

Dear all, During the last weeks I've been working in the MATE Desktop and finally I've reached a state that MATE installs and works pretty much OK. MATE repository is X11:MATE and there's a X11:MATE:Factory which I hoped it could become openSUSE:Factory development project for MATE. For this to happen, a few task are required: - Review the MATE packages (I have help from Dimstar in 'no-prisioners' mode, for the best packaging/integration possible); - A few packages need to go through SUSE … [View More]

1 0

[opensuse-factory] odd problem with Emacs after upgrading Tumbleweed to 12.2
by Achim Gratz 12 Sep '12

12 Sep '12

I've just done the upgrade to 12.2. There were a few hiccups with some branding packages that did install upstream instead of openSUSE and a lot of cruft that the system collected over the years, but that's all solved now. The one application that makes problems is emacs, more specifically emacs-gtk: it stopped displaying the toolbar icons (I normally have the toolbar switched off, so I didn't notice immediately). (emacs:23736): GdkPixbuf-WARNING **: Error loading XPM image loader: Bildtyp »… [View More]xpm« wird nicht unterstützt (emacs:23736): GdkPixbuf-CRITICAL **: gdk_pixbuf_new_from_data: assertion `bits_per_sample == 8' failed (emacs:23736): GdkPixbuf-CRITICAL **: gdk_pixbuf_add_alpha: assertion `GDK_IS_PIXBUF (pixbuf)' failed (emacs:23736): GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT (object)' failed (emacs:23736): Gtk-WARNING **: Error loading theme icon 'document-new' for stock: Format der Bilddatei unbekannt One of the other symptoms is that eLisp can't read floating point literals: '(bla 0.25 fasel) => (bla 0.0 fasel) Emacs-nox, emacs-x11, and "emacs-gtk -nw" correctly interpret this as '(bla 0.25 fasel) => (bla 0.25 fasel) Emacs-gtk needs LC_ALL=C to function correctly (but that has other undesired side-effects). Ldd doesn't seem to find any problems: > ldd `which emacs-gtk` linux-gate.so.1 (0xb7702000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7274000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb71c3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb71a1000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7117000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb70e0000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb7091000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb6f95000) libpthread.so.0 => /lib/libpthread.so.0 (0xb6f7a000) libSM.so.6 => /usr/lib/libSM.so.6 (0xb6f71000) libICE.so.6 => /usr/lib/libICE.so.6 (0xb6f56000) libtiff.so.5 => /usr/lib/libtiff.so.5 (0xb6ee1000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb6e8f000) libpng14.so.14 => /usr/lib/libpng14.so.14 (0xb6e64000) libm.so.6 => /lib/libm.so.6 (0xb6e38000) libgif.so.4 => /usr/lib/libgif.so.4 (0xb6e2e000) libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb6e1b000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb6ce0000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb6cd5000) libXft.so.2 => /usr/lib/libXft.so.2 (0xb6cbf000) libasound.so.2 => /usr/lib/libasound.so.2 (0xb6bda000) librsvg-2.so.2 => /usr/lib/librsvg-2.so.2 (0xb6ba1000) libdbus-1.so.3 => /lib/libdbus-1.so.3 (0xb6b56000) libtinfo.so.5 => /lib/libtinfo.so.5 (0xb6b2e000) libgconf-2.so.4 => /usr/lib/libgconf-2.so.4 (0xb6afe000) libotf.so.0 => /usr/lib/libotf.so.0 (0xb6ae8000) libm17n-flt.so.0 => /usr/lib/libm17n-flt.so.0 (0xb6adc000) libm17n-core.so.0 => /usr/lib/libm17n-core.so.0 (0xb6ab3000) libc.so.6 => /lib/libc.so.6 (0xb690c000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb68ff000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb68f9000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb68d8000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb67cc000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb666f000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb6640000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb65f5000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb65e2000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb65de000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb65ce000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb65c4000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb65b9000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb65b5000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb65b1000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb65ac000) libz.so.1 => /lib/libz.so.1 (0xb6594000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0xb656b000) libffi.so.4 => /usr/lib/libffi.so.4 (0xb6563000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0xb6504000) librt.so.1 => /lib/librt.so.1 (0xb64fb000) /lib/ld-linux.so.2 (0xb7703000) libuuid.so.1 => /usr/lib/libuuid.so.1 (0xb64f4000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0xb64ca000) libjbig.so.2 => /usr/lib/libjbig.so.2 (0xb64bd000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb649a000) libdl.so.2 => /lib/libdl.so.2 (0xb6495000) libcroco-0.6.so.3 => /usr/lib/libcroco-0.6.so.3 (0xb6458000) libxml2.so.2 => /usr/lib/libxml2.so.2 (0xb6306000) libdbus-glib-1.so.2 => /usr/lib/libdbus-glib-1.so.2 (0xb62df000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb6246000) libxcb-shm.so.0 => /usr/lib/libxcb-shm.so.0 (0xb6242000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb6236000) libselinux.so.1 => /lib/libselinux.so.1 (0xb6218000) libresolv.so.2 => /lib/libresolv.so.2 (0xb6201000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb61fd000) I hope that rings a bell with somebody… Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org [View Less]

4 12

Re: [opensuse-factory] question about lightdm status on openSUSE
by Saulo Moraes 12 Sep '12

12 Sep '12

XDM package is always installed as it is a dependency from xorg-x11 and is used by default but when we add GDM or KDM the XDM is replaced by then as the default display manager. It is the best behavior... So my question is, can we have the same behavior with lightDM? When we have just XDM installed and we add lightDM the default display manager should be lightDM. I know it can be easily configured but when creating an appliance with susestudio we need to change the display manager … [View More]

6 10

[opensuse-factory] CDE goes Open Source
by Ilya Chernykh 12 Sep '12

12 Sep '12

Does anybody mean to package it? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

13 21

[opensuse-factory] lsb-release: Distributor change
by Dimstar / Dominique Leuenberger 11 Sep '12

11 Sep '12

Hi everybody, This is a heads-up, in case any of your packages makes direct use of lsb-release information, specifically the 'Distributor ID'. Up to now, the distributor ID is set to "SUSE LINUX". There is currently a request pending to Factory to change this, more correctly, to "openSUSE project". Whereas this is certainly correct, there might be some fallouts of packages relying on this (I had seen packages trying to guess the distribution in several ways.. so this is one of them). Hope … [View More]

2 3

[opensuse-factory] Checking Release Notes
by Karl Eichwalder 11 Sep '12

11 Sep '12

Approaching the release date it would be good if more eyes would take a look at the release notes and provide feedback. Find the sources of the release notes in the berlios SVN: https://svn.berlios.de/svnroot/repos/opensuse/trunk/documentation/release-n… I'd prefer patches against the XML file, but general feedback based on the HTML or YaST output format is also fine. We especially must make sure to eliminate all CHECKIT remarks ;) I added most of these CHECKIT remarks to old systemd … [View More]

2 4

[opensuse-factory] RC2 zypper dup What are the new packages?
by lynn 11 Sep '12

11 Sep '12

12.2 RC2 I ran zypper DUP yesterday and it updated around 190 packages. I did it again just now and there are another 174 today including having to accept a 12.2 licence agreement that includes a typo. Today's stuff includes new packages such as samba 3.6.7 and a new kernel 3.4.6-1.10.1 Is this the GM? Thanks, L x -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

6 14

[opensuse-factory] What is it?
by Ilya Chernykh 11 Sep '12

11 Sep '12

These error messages appear at any boot and take 2-3 minutes: http://storage5.static.itmages.ru/i/12/0905/h_1346870772_2923270_15cbb49293… -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 9

[opensuse-factory] Postgresql downgrade in 12.2?
by Marcel Witte 10 Sep '12

10 Sep '12

Hi, While upgrading my server to 12.2 I noticed that postgresql will be downgraded from 9.1.3 to 9.1.1. Is this intended? Will there be an update to 9.1.3 again soon? Regards, Marcel -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

5 5

[opensuse-factory] Firefox 15
by Ilya Chernykh 10 Sep '12

10 Sep '12

Hi! I want to rise the issue about stability of Firefox 15. For me it crashges every time upon exit. Reversal to Firefox 14 fixes the issue. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

4 5

[opensuse-factory] mkinitrd failure with grub2-
by Alin M Elena 10 Sep '12

10 Sep '12

Hi, this is on a factory system... mkinitrd Kernel image: /boot/vmlinuz-3.6.0-rc4-3-desktop Initrd image: /boot/initrd-3.6.0-rc4-3-desktop Root device: UUID=2348b6ab-f8ea-486c-8556- f40036e1eae4 (/dev/sda5) (mounted on / as btrfs) Kernel Modules: thermal_sys thermal processor fan ata_generic scsi_dh scsi_dh_alua scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac libcrc32c zlib_deflate btrfs xhci-hcd hid-logitech-dj crc32c-intel Features: acpi plymouth block usb btrfs resume.userspace … [View More]

2 2

[opensuse-factory] Beautiful Soup python module
by Nelson Marques 10 Sep '12

10 Sep '12

Guys, Anyway the python gurus consider to include Beautiful Soup in openSUSE distribution? This is really a kick ass module... - http://www.crummy.com/software/BeautifulSoup/ NM -- 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] the latest nss-pam-ldapd package for 12.2?
by lynn 10 Sep '12

10 Sep '12

Hi Is it too late to ask for the latest nss-pam-ldapd package to be included in 12.2? The latest stable version is 0.8.10 whilst 12.1 and 12.2 are stuck with the older 0.7.x series. Thanks L x -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-factory+owner(a)opensuse.org

8 15

[opensuse-factory] 68 new mostly 32 bit packages on 64 bit 12.2
by Felix Miata 10 Sep '12

10 Sep '12

Last zypper dup on this 64 bit system belonging to Bob Stia was less than a week ago. None of my own systems have anything 64 bit. Today I tried again, after 'zypper dup -r KDE49'. Now it wants to downgrade 23 packages including Firefox and SeaMonkey, and install 68 new packages, most of which are lib*32bit. There are only 5 to upgrade, 4 of which are qt3/kde3. Should I try again some other time? Something else? -- "The wise are known for their understanding, and pleasant words are … [View More]

4 6

[opensuse-factory] basedonopensuse
by Wolfgang Rosenauer 10 Sep '12

10 Sep '12

Hi, I just had a case where someone had issues with Firefox because he was using MozillaFirefox-branding-basedonopensuse Could someone give me some pointers what the purpose of these -basedonopensuse packages is and who is responsible for them? I'm only maintaining -branding-openSUSE at the moment and we just released an update for that for compatibility with Firefox 14 but I guess nobody touches basedonopensuse and therefore people are a bit stuck with bugs probably. Thanks, Wolfgang -- … [View More]

8 9

[opensuse-factory] 12.2 beta VirtualBox problem
by lynn 10 Sep '12

10 Sep '12

12.2 beta2 updated with Yast Online Update yesterday Hi everyone I have a problem with 12.2 on VirtualBox. The 4.1.16 that came with 12.2 gave a very large virtual text screen (the ones that have to have scrollbars) which is really annoying when working in a console in text mode. I removed 4.1.16 and installed 4.1.18. Same problem. The graphics modes are fine, it's just the cli. I have tried with and without the guest additions. Both versions of vbox work as expected on 12.1 Any ideas … [View More]

3 6

[opensuse-factory] question about lightdm status on openSUSE
by Nelson Marques 09 Sep '12

09 Sep '12

Hi all, I'm remastering a small iso of openSUSE 12.2 with X11:MATE and I'm trying to dodge all the stuff from GNOME3 to minimize dependencies; Currently we have GDM and KDM supported; I've also seen some lightdm packages around, and I'm wondering if anyone knows their state, if they are integrated with openSUSE and ready for usage (otherwise, I must fall to GNOME GDM, which I have no issues with). NM -- 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] RC2 very slow to boot after upgrade from RC1
by lynn 09 Sep '12

09 Sep '12

Hi I did an upgrade from RC1 which was on vbox, to RC2. The upgrade went OK but the system now takes 4 minutes to boot: I see the Welcome to GRUB message and then a fleeting glimpse of an error message. Then a black screen for a long time before the splash appears, then everything is back to normal Any ideas for 1. Where I could get to see the error message (in a log somewhere? I can't find anything like it under /var/log) 2. How to get the boot time down. Thanks L x -- To unsubscribe, … [View More]

5 16

[opensuse-factory] Shutting Down system in 12.2
by Basil Chupin 09 Sep '12

09 Sep '12

Something has happened at my end (or is this also occurring with others?). When I am shutting down my computer, by right-clicking on desktop and selecting Logout, I get a small drop-down menu asking if I wanted to Suspend to RAM or Suspend to Disk and then a count down starts telling me that the computer will be shutdown in (?)30 seconds; and after the 30 seconds are up, I get the green gecko on the screen and have to wait until something finally decides to shut down the computer. This … [View More]

6 5

[opensuse-factory] Tumbleweed: VirtualBox crashes X
by Patrick Shanahan 09 Sep '12

09 Sep '12

*Some* recent upgrade, within last week, causes VirtualBox to crash X. openSUSE Tumbleweed (12.2) (current) NVidia-Linux-x86_64-304.32 upgraded VirtualBox to VirtualBox-4.1-4.1.22_80657_openSUSE114-1.x86_64.rpm kernel is kernel-desktop-3.5.3-40.1.x86_64 gcc is gcc-4.7-2.1.1.x86_64 Suspecting a problem with the NVidia package, I tried to reinstall the current 304.32 and got: ========================================================================= nvidia-installer log file '/var/log/… [View More]nvidia-installer.log' creation time: Sat Sep 8 10:08:08 2012 installer version: 304.32 PATH: /sbin:/usr/sbin:/usr/local/sbin:/root/bin:/usr/local/bin: |\ /usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/usr/bin/X11: |\ /usr/X11R6/bin:/usr/games:/opt/kde3/bin:/usr/sbin nvidia-installer command line: ./nvidia-installer -a Using: nvidia-installer ncurses user interface -> License accepted by command line option. -> Installing NVIDIA driver version 304.32. -> There appears to already be a driver installed on your system (version: -> 304.32). As part of installing this driver (version: 304.32), the -> existing driver will be uninstalled. Are you sure you want to -> continue? ('no' will abort installation) (Answer: Yes) -> Running distribution scripts executing: '/usr/lib/nvidia/pre-install'... -> done. -> Performing CC sanity check with CC="cc". -> Performing CC version check with CC="cc". -> The CC version check failed: The compiler used to compile the kernel (gcc 4.6) does not exactly match the current compiler (gcc 4.7). The Linux 2.6 kernel module loader rejects kernel modules built with a version of gcc that does not exactly match that of the compiler used to build the running kernel. If you know what you are doing and want to ignore the gcc version check, select "No" to continue installation. Otherwise, select "Yes" to abort installation, set the CC environment variable to the name of the compiler used to compile your kernel, and restart installation. Abort now? (Answer: Yes) ERROR: Installation has failed. Please see the file '/var/log/nvidia-installer.log' for details. You may find suggestions on fixing installation problems in the README available on the Linux driver download page at www.nvidia.com. ========================================================================= What to do? Bug? 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 [View Less]

2 3