February 2010 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] Cronie as default cron in Factory
by Michal Seben 07 Jun '11

07 Jun '11

Hi all! Next week I will move cronie[1] package to Factory, so it will replace old cron. If someone is against this step, please just write what's wrong. As I announced earlier, you could find Cronie in Base:System repo [2] there is also prepared wiki about known changes after switch to cronie [3] [1]https://fedorahosted.org/cronie/ [2]https://build.opensuse.org/package/show?package=cronie&project=Base%3ASys… [3]http://en.opensuse.org/Cron_replace#Differences_between_old_openSUSE.27s_… -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

12 28

[opensuse-factory] Is the upgrade from 32 bits to 64 bit supported? Question for devs O:-)
by Carlos E. R. 07 Oct '10

07 Oct '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm asking here a question not related to factory directly, because I want to reach the devs. You can reply on opensuse list instead if you prefer. To keep it short (longer post in the opensuse list), I'm attempting to upgrade from 11.0 to 11.2 (32 bits) using the retail DVD, wich turns out it has only the x64 version. It offers to upgrade to 64 bit the 32 bit install: The architecture of the system installed in the selected partition is different from the one of this product" [continue] [cancel] I said "continue", then I checked the package list. As far as I could see, it intended to replace all packages with those corresponding to the 64 bits version. If this works, fine... but I was afraid, and I cancelled. Not because risking data (it is a copy), but because of possible waste of time. I thought I'd better RFC. Has anybody done this, an upgrade from 32 to 64 bits? Does it work? Is it "supported"? - -- Cheers / Saludos, Carlos E. R. (from 11.2 x86_64 "Emerald" GM (Elessar)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAktvNHIACgkQU92UU+smfQVsTwCfSYFG8N7Owo/PWNu0ylYKGqmr fuQAoJQSLDrMlTDMYeRihU5SfBa0fVz8 =zvu9 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

9 22

[opensuse-factory] 11.2 Release Notes
by Karl Eichwalder 25 Jun '10

25 Jun '10

It would be good if we would start with collection release notes snippets for 11.2 now. Do not hesitate to provide input! Here is some background information: http://en.opensuse.org/Release_Notes -- Karl Eichwalder R&D / Documentation SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

1 1

[opensuse-factory] Kernel Mode Setting (KMS) for openSUSE.
by Egbert Eich 29 Mar '10

29 Mar '10

Folks - In yesterday's discussion about the future of SaX2 it has been requested that changes that will affect users in the future are communicated to the openSUSE community early. KMS (kernel mode setting) integration would be such a feature, thus I would like to announce this here and one step further dive into a technical discussion about a possible solution. Furthermore test packages are available to try things out on Factory. I would like to encourage people interested in development and technical discussions in general to participate in the discussion and the development efforts. Kernel Modesetting (KMS) ======================== All of you who are using a graphical desktop on Linux have been using the X Window Sytem. The X Window System Server (XServer) is the instance which receives requests from your desktop applications to draw all the widgets (windows, buttons, images etc.) you see on your desktop. It also processes input from your keyboard and mouse and sends them to applications as events. Traditionally on Linux the XServer does not only draw images to the screen (ie writes them to some sort of frame buffer) but it is in charge of initializing, setting up and driving the graphics hardware. This paradigm which has been true since the X Window System has been ported to Linux is about to change: Much of the initialization, set up (video mode setting) and control of the graphics hardware is about to move to the Linux kernel. There are a number of advantages to this: - A central instance is in charge of the graphics hardware, other user mode applications (not just the Xserver) can take advantage of mode setting. - The Xserver will no longer require full root privileges as it doesn't talk to the hardware directly any more. - Faster boot process: The Xserver doesn't need to (re)initialize the graphics hardware any more, this is all done by the kernel very early in the boot cycle. - Smoother (flicker free) boot experience: The screen doesn't flicker and changes resolution any more when the Xserver starts. - One central entity is in charge and manages the resources of the graphics hardware - like the video memory which makes sharing of these resources between several applications (like Xserver and several DRI (Direct Rendering 3D) applications much easier. KMS is integrated in the DRM drivers. In the near future most graphics driver will switch to KMS: - Intel already ships a fully working KMS driver. Future Intel chipsets will be supported by the KMS driver only. - KMS in the Radeon DRM driver is still work in progress but it is already working well on some chipsets. - Noveau is relying heavily on KMS for their free 3D driver for NVIDIA chipsets. The proprietary ATI and NVIDIA drivers are unlikely to switch to KMS in the near future. Integration in openSUSE ======================= Now this begs the question what we have to do to integrate it into openSUSE. Originall I had plans to look into this for openSUSE 11.2 already - but then I got side tracked by other stuff it fell on the floor and noone else beat me to it either ... oh well. Now I had the chance to play around with KMS a little and came up with some ideas and a proof of concept. It turned out that the changes to openSUSE needed to fully support KMS are quite small. Key is to load the KMS aware DRM driver as early as possible in the boot process to avoid video mode changes later in the boot cycle - preferrably in the initrd. The Boot Process ---------------- On openSUSE the boot loader is configured for two boot scenarios: default and failsafe. The user can select the failsafe boot scenario in case the default scenario does not work for him. In the failsafe scenario certain features are deactivated which have shown to cause problems on some systems. Since KMS is a new feature it is a candidate for deactivation during a failsafe boot. Instead the system should then boot into the VESA framebuffer mode. Should this also fail the kernel will automatically fall back to a VGA text mode. To disable KMS on boot a new boot parameter is introduced: 'nomodeset'. This parameter is to the boot command line for the failsafe mode. The user may add this parameter by hand for any other boot mode. The kernel command line is parsed in initrd and an appropriate entry is created in /etc/modprobe.d/options. Furthermore the graphics driver module and - if required - the agp module(s) are added in the correct order (agp modules first) to the list of modules to be loaded initially. Changes to individual packages ============================== 1. yast2-bootloader & perl-Bootloader ------------------------------------- The boot parameter 'nomodeset' is added to the failsafe boot paramter lists in each of the modules. (I have not been able to find out which module provides the entry relevant for which situation, therefore I've whacked both.) yast2-bootloader updates the variable FAILSAFE_APPEND in /etc/sysconfig/bootloader appropriately. 2. kernel-source ---------------- To use KMS for a certain DRM driver the kernel config option CONFIG_DRM_<driver_name>_KMS needs to be set to 'y'. At the moment we will support KMS only for Intel hardware, thus only the variable CONFIG_DRM_I915_KMS needs to be changed. In the sample build this has been enabled for the -default, -desktop, -pae, -debug, -trace and -vanilla kernels for the i386 and x86_64 platforms. The kernel boot splash has already been fixed for KMS for openSUSE 11.2. 3. mkinitrd ----------- This package writes the initrd file. To add KMS support to the initrd mkinitrd needs to perform the following tasks: 1. Check the sysconfig variable NO_KMS_IN_INITRD, if set, don't attempt to install a KMS DRM capable driver. 2. Obtain a list of PCI devices installed on the system. 3. a. In the list of PCI devices identify those devices which are of class VGA and look for a matching driver. b. Before a driver is matched check the PCI vendor, device, subvendor and subdevice ids against a blacklist in /etc/kms/blacklist should this file exist. This file contains one vendor, device, subvendor and subdevice id per line, '*' serves as a wildchar, trailing wildchars may be ommitted, '#' at the beginning of a line serves as a comment. c. Use the standard modprobe alias mechanism to find a matching DRM driver module. This way standard blacklistings of kernel modules will be honored and update modules will be searched if they are available. KMS capable DRM drivers provide an alias list (in contrast to non-KMS capable DRM drivers which are to be loaded explicitely by the Xserver). d. If a driver is found check for a black listing in /etc/kms/<driver_name>.blacklist. The same rules as in 3 b. apply. 4. If a KMS capable DRM driver is found search for an agp driver: a. Obtain a list of all known agp drivers for the specific kernel and collect their alias lists. b. Match all installed PCI devices against the alias lists of each agp driver. If a match is found add the driver to the lists of modules to be loaded. Make sure that this driver is loaded prior the the DRM driver. Two scripts setup-kms.sh and boot-kms.sh are added to mkinitrd. The former performs the tasks listed above, the latter provides the required module dependencies in the required order, parses the boot command line for the 'nomodeset' option and adds the apropriate entry to /etc/modprobe.d/options. The linuxrc script is extended to search the boot command line for <drivername>.<option>=* strings for each driver loaded in initrd and add the <option>=* part to /etc/modprobe.d/options. 4. udev ------- Udev loads any modules which are not loaded by linuxrc scripts directly. It is possible to let udev load the required DRM and AGP modules provided it is made sure that this happens in the correct order. Since there is no explicit dependency of DRM modules to AGP drivers as there is no general one to one match between the two drivers a udev rule must exist to enforce the correct order for all cases where a AGP module is required. This is true for Intel DRM drivers and any other driver for an AGP graphics chip. For this a rule file 79-waitfor-agp.rules is added which is run before 80-drivers.rules. It checks if either an Intel graphics (class VGA) device is processed or if the graphics device is an AGP device. The latter condition is tested by an auxiliary tool (is_agp) which is passed the kernel name of the event device. If either condition is true udev will wait for /dev/agpgart to appear before proceeding to load a DRM driver module. 'is_agp' checks the capabilities flags in the PCI config space of this device for AGP. The changes to udev are not strictly required to make KMS work, still they augment the default module load process Installation ============ Modified packages for Factory of - kernel-source, - mkinitrd, - yast2-bootloader, - perl-Bootloader, - mkinitrd - udev can be found in my build service home on OBS under home:eeich:Factory-KMS. For installation add http://download.opensuse.org/repositories/home://eeich://Factory-KMS/openSU… to your installation repository and update the packages in question (going thru the usual vendor change hassle). It is advisable to update mkinitrd before updating the kernel. Then when the kernel is installed the modified mkinitrd will be used and all steps required to install KMS will be performed. TODO ==== - The kernel bootsplash sometimes produces wrong colors (WIP). Add KMS - Add KMS support to the RadeonHD driver. Cheers, Egbert. -- Egbert Eich (Res. & Dev.) SUSE LINUX Products GmbH X Window System Development Tel: +49 911-740 53 0 http://www.suse.de ----------------------------------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

18 68

[opensuse-factory] [ANNOUNCE] Will update PackageKit to 0.6.1 in Factory next week
by Vincent Untz 25 Mar '10

25 Mar '10

Hi, Looking at the git log from PackageKit, it looks like Scott managed to fix the build of the zypp backend -- which was the reason we were stuck with an old PackageKit (0.5.1). So we'll put the next release of PackageKit in Factory (0.6.1, due next week, I think). Note that this changes the API (at least deprecated API were removed) and therefore will possibly break tools using PackageKit that were not prepared for this. You can take a look at the NEWS file for more details: http://cgit.freedesktop.org/packagekit/tree/NEWS As far as I know, there are two major consumers of PackageKit: gnome-packagekit (which should be fine) and the KDE update applet (no idea what the status is here). Is it an option to not update PackageKit? Not really: the version we have is old, not really maintained, and my guess is that we'll soon have tools that will require the new stuff there. Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 3

[opensuse-factory] new package: upstart
by Stephan Kulow 24 Mar '10

24 Mar '10

Hi, I submitted a new package to openSUSE:Factory: upstart. Mainly because of https://features.opensuse.org/305690 - the biggest gain of having it is clearly that everyone else has it, it doesn't get openSUSE a win right away. But not having it, may become a disadventage shortly - who knows. For now we will support sysvinit and upstart as alternatives, but my preference would be not for long. The package I submitted is pretty much only a start and adopting our scripts to upstart will be less of a pain if we do not have to support alternatives. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

9 27

[opensuse-factory] status: distribution
by Stephan Kulow 06 Mar '10

06 Mar '10

Hi, Milestone2 looks good and I'm just uploading it to the mirrors. After that's done, we'll switch to gcc 4.5 and after that the real fun starts - so I hope everyone who can, helps fixing packages here and there. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

19 30

[opensuse-factory] opensuse-factory isos
by doiggl＠velocitynet.com.au 03 Mar '10

03 Mar '10

Hello, The isos look like their out of sync (You may know this already) one shows Build0449 and the other Build0461 Has the one building openSUSE-KDE-LiveCD.... stopped building the images ? >From http://download.opensuse.org/factory/iso/ - openSUSE-KDE-LiveCD-x86_64-Build0449-Media.iso 16-Feb-2010 11:47 691M - openSUSE-NET-x86_64-Build0461-Media.iso 24-Feb-2010 17:42 156M Glenn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 5

[opensuse-factory] patches for PulseAudio?
by Werner LEMBERG 02 Mar '10

02 Mar '10

I wrote this on the PulseAudio list: On openSuSE, I use these packages, mostly from the factory repository: alsa-1.0.22-2.5.i586 pulseaudio-0.9.21-2.4.i586 skype-2.1.0.81-suse111.i586 phonon-4.3.80-4.2.i586 (everything else from KDE is 4.3.95) I experience a big delay (more than a second), especially problematic while using Skype. I've configured KDE to use `PulseAudio' as the output device for everything. And I got this answer: Please ask your distribution to include the patches from the "stable-queue" git branch in PA git. Most other distributions now regularly apply those patches. And so should yours. The Skype issue is fixed there. My question: Does this happen for OpenSuSE too? Werner -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 2

[opensuse-factory] /usr/bin/hostid?
by Ludwig Nussel 01 Mar '10

01 Mar '10

Hi, Does anyone know any users of /usr/bin/hostid? We have a custom one in the util-linux package but upstream coreutils contains a different implementation. Ours prints '0xnumber' while upstream only prints 'number'. Also ours allows to set the hostid and the man page refers to /etc/hostid. However, hostid doesn't actually read that file and there also doesn't seem to be an init script for it either. So I wonder whether we could safely switch to the coreutils version. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 4