December 2009 - openSUSE Factory - openSUSE Mailing Lists

[opensuse-factory] The Future of SaX2
by Egbert Eich 17 Dec '09

17 Dec '09

The Future of SaX2 ================== For many years now SUSE Linux came with a tool to configure the setup of the desktop which was second to none in the Linux and Free Software world: SaX2. It made it easy even for unexperienced users to configure video modes, screen layouts as well as keyboard and input devices for the X Window System. Meanwhile however the technology around the X Window System server as shipped by X.Org has evolved: hot pluggable input and output devices made a static configuration infeasible. Automatic configuration and dynamic reconfiguration mechanisms have been developed such that today most of the tasks that SaX2 was able to do are done fully automatically on the fly and can be modified from within a desktop session. Modern desktops like Gnome and KDE provide convenient user interfaces for that. A static configuration of the Xserver as done by SaX2 is still possible, yet it does not work well together with dynamic reconfiguration. The changes to SaX2 to improve this situation would be considerable and will require substantial changes in its design. Novell has decided to no longer invest in development maintenance of SaX2 but instead rely on the new automatic and dynamic configuration features and invest in desktop applets to perform dynamic changes. Federico Quintero for instance has created gnome-display-properties. The resources needed to keep SaX2 in sync with changes in X.Org will exceed what the people at Novell who have been maintaining SaX2 next to their normal work tasks in the past few years are able to spare. Thus starting with openSUSE 11.2 SaX2 will no longer be offered as a configuration option in YaST. It is still shipped and installed by default but it's likely to be deprecated further when it's usefulness diminishes further. People have raised objections to this decision by Novell's as they believe a static configuration is still crucial while auto configuration is still new and still fails in a few cases where SaX2 successfully produces a usable configuration. Yet, the decision was driven by what Novell sees its business needs and thus is not up for discussion. However the fate of SaX2 is not at all up to Novell: SaX2 has been Free Software all along and as with all Free Software it's up to each individual to help driving it in the direction they like to see it go - independently of corporate business needs and interests. All it needs is a dedicated bunch - a group of people who still believe in it's value and who are willing to drive it further - or the corollary to this: if there is no such community it's most likely not considered useful enough to warrant the effort. Thus if you think a configuration tool for X like SaX2 is still what the world and you need, it is now time to act: Don't sit there and complain about a decision you cannot influence, pick up and start driving SaX2 development yourself - the sky's the limit! Don't be shy altering even fundamental basics of the SaX2 code basis - the configuration system in X has vastly changed, so a configuration tool needs to change the same way. The resources to do so are there: The project is hosted at: http://developer.berlios.de/projects/sax/ The openSUSE Devel project is at: https://build.opensuse.org/package/show?package=sax2&project=X11%3AUtilities Please join the developers mailing list at https://lists.berlios.de/mailman/listinfo/sax-devel If you are interested to contribute to SaX2. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

32 147

[opensuse-factory] Hardware enablement in kernel updates
by Jeff Mahoney 16 Dec '09

16 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - Some of you have seen my posts on this list before, but it may not be clear what my involvement is with kernel development. I lead one of the kernel teams in SUSE Labs. I maintain the master branch of the SUSE kernel trees (both SLE and openSUSE) and have been the release manager for the kernel for the past few openSUSE releases (as well as a few enterprise releases). Historically, some decisions have been made that affect the openSUSE kernel collaboratively, but not entirely transparently, and I'd like to change that. One of our policies regarding kernel updates is that we'll fix bugs pertaining to usability until the next release. Otherwise, it's security, data loss/corruption, and system crash fixes until EOL. While it could be argued that hardware enablement falls under usability, we haven't treated it that way in the past. I'd like to revisit that. I was asked today about the possibility of adding a driver to the 11.2 kernel, and I started thinking about it. Strictly speaking, it's against our inclusion policy. However, the new longer release cycle means that users with new hardware may be forced to run a Factory kernel on 11.2, switch to a different distribution, or wait around until the next release. While I don't personally have a problem with option #1, I'm a kernel hacker and kernel bugs don't scare me. Not everyone wants to be a beta tester. Option #2 isn't in the long-term interests of the openSUSE community. Option #3 is painful because it means that you have this shiny new hardware for which you've paid your hard-earned money and can't use to its fullest potential. The particular driver I was asked about is completely standalone. I don't have a problem including it since it won't affect anything else. The issue was that I don't want to encourage the expectation that this would be a normal occurrence - unless we want to change the policy surrounding updates. I should be clear on what I have in mind and what the limitations are. I do not intend to open the door for every crap driver that's floating around out there. There are reasons that the drivers aren't in the mainline kernel and I have no interest in duplicating that debate on this list. Drivers up for post-release inclusion _must_ be already in the mainline kernel. The other limitation is that the changes be completely standalone or isolated such that it's apparent that the introduction of the change doesn't affect the stability of users who are using those drivers already. That part can get sticky since adding a PCI ID is easy, but adding handling that is needed to enable that PCI ID while potentially affecting other devices in a clean way is not. So with that, I'd like to open it up for discussion. I've cross-posted between opensuse-factory and opensuse-kernel since it's a policy that affects everyone, not just those interested in the kernel itself. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksm4ecACgkQLPWxlyuTD7LD7QCeK9lDtJo6h/LcRnfng93+i0Pc Hv0An2Wnb1N41xxLSQjB830w1SwGdiUQ =Fwo1 -----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 19

[opensuse-factory] RFC: Announcing important changes in the distribution
by Lubos Lunak 16 Dec '09

16 Dec '09

Hello, it repeatedly happens that there is a change introduced in the distribution that affects others yet those are not told at all or too late to do something about it. Examples would be the removal of X configuration including keyboard layout from YaST as a consequence of deprecating Sax2, meaning that it is now not possible to change keyboard layout for KDM/XDM, or the upgrade of PackageKit to a newer version that no longer had PolicyKit as a dependency but instead started requiring its newer and backwards incompatible version polkit-1, requiring rewritting KDE support from scratch (which is the reason why KDE in 11.2 uses polkit-gnome). In the first case, I don't remember that mentioned anywhere, in the latter case, the kupdateapplet maintainer was notified (where it didn't really matter) but not the KDE maintainers. Others could probably come up with their own examples. I'd prefer if such things didn't happen again, or at least if they were known in advance. And it even seems doable, because some changes already are announced, e.g. new gcc version, the switch to linking with --as-needed, etc. Therefore I want to suggest that announcing important changes in the distribution that affect other components of the distribution becomes mandatory. What would qualify for such a change is somewhat hard to specify exactly, but I'd hope using common sense to judge would do. For example "we remove support for X settings from YaST and require desktops to take care of these settings if necessary" or "we introduce new polkit-1, which is not backwards compatible to the old PolicyKit, and deprecate the old one" are clearly changes that should be announced. Something like "DHT support in KTorrent is now enabled/disabled" or "libjpeg is going to be upgraded from 6.2.0 to 6.2.1" is clearly of no interest, as long as it is not known to break other parts of the distribution - that would just create an unnecessary flood that nobody would follow. The place for such announcements would be this list, with some specific subject to make it easier to spot them (and perhaps some more firm pointing to the right list would be needed for those who create noise, or something from http://lists.opensuse.org/opensuse-factory/2009-09/msg00354.html would be needed). Comments? -- Lubos Lunak KDE developer -------------------------------------------------------------- SUSE LINUX, s.r.o. e-mail: l.lunak(a)suse.cz , l.lunak(a)kde.org Lihovarska 1060/12 tel: +420 284 084 672 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

23 44

[opensuse-factory] repocache
by Hans Witvliet 16 Dec '09

16 Dec '09

Hi all, During my rsync i noticed the last couple of daay an increasing number files with the name "package.rpm-largehexnumber-number-number. For instance: ./KDE:/43/openSUSE_11.0/repocache/mono-kde4-4.3.4-3.7.i586.rpm-8f2ae283e855363e5ad51ce94f131fdc0f685273-597390-1260582155 As all of these files reside under a subdirectory "repocache" i wonder what its purpose is, And if it's none, why are they mirrored outside? I've been syncing 323229 of these files, while there are 156582 waiting to be downloaded. I don't mind burning cpu-cycles, or spending diskspace, but i rather like to know why..... Somehow i have a vague feeling that these are obs-internal-directories only, and not meant for the general public. Hans -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 2

Re: [opensuse-factory] New pm-utils-1.2.6.1
by Michal Vyskocil 15 Dec '09

15 Dec '09

On Tuesday 15 of December 2009 11:53:30 Stefan Quandt wrote: > > This release also removed powersave command. > > I'm using this all the time. > Will there be an alternative command? > I don't have such plans. But it'd be suitable to move it to the separate package (like powersave-legacy), which will be maintained by someone else. I offer a help with a packaging. BTW: in this case those two lines echo -e "ATTENTION:\tThis is a legacy tool to provide basic functionality of the obsolete" echo -e "\t\tpowersave daemon. It will vanish in future." should be removed from script ;-) Best regards Michal Vyskocil

2 2

[opensuse-factory] New pm-utils-1.2.6.1
by Michal Vyskocil 15 Dec '09

15 Dec '09

Hi all, I updated pm-utils to 1.2.6.1. The new version no longer supports HIBERNATE_METHOD={userspace,kernel} [1], because there's an upstream equivalent SLEEP_MODULE which selects one of available implementation (see /usr/lib/modules.d/ for details) # The default sleep/wake system to use. Valid values are: # kernel The built-in kernel suspend/resume support. # Use this if nothing else is supported on your system. # uswsusp If your system has support for the userspace # suspend programs (s2ram/s2disk/s2both), then use this. # tuxonice If your system has support for tuxonice, use this. # # The system defaults to "kernel" if this is commented out. SLEEP_MODULE="uswsusp" The SUSE default is uswsusp. This release also removed powersave command. BTW: development of suse addons to pm-utils is now on gitorious.org [2] [1] http://en.opensuse.org/Pm-utils#SUSE-specific_variables [2] http://gitorious.org/opensuse/pm-utils-suse Best regards Michal Vyskocil

1 0

Re: [Lxde-list] [opensuse-factory] submitreq #26939 and #26940 : xmms2 and LXMusic (LXDE Music player)
by Andrea Florio 14 Dec '09

14 Dec '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 14/12/2009 17:57, Jürgen Hötzel ha scritto: > 2009/12/11 Marcus Meissner <meissner(a)suse.de> > >> On Fri, Dec 11, 2009 at 02:27:09PM +0100, Marcus Meissner wrote: >>> On Fri, Dec 11, 2009 at 12:17:18PM +0100, Andrea Florio wrote: >>>> Hi guys, this two are my next LXDE submitreq. >>>> >>>> here some infos: >>>> >>>> (submit req #26940) >>>> (submit req #26939) >>> >>> I do not see either of them. >>> >>> There is 26240 though and 29239. >>> >>> Packaging wise I see no immediate issue with them. >> >> Except xmms2 seems to contain a MP3 decoder, which is not allowed >> in openSUSE. >> >> > MAD MP3 decoder plugin can be disabled at build time. > > Jürgen > that has been already done, and the source tarball has neem purged to have no more headers that includes problematic headers Andrea - -- - ------------------------------------------ Andrea Florio QSI International School of Brindisi Sys Admin openSUSE-Education Administrator openSUSE Official Member (anubisg1) Email: andrea(a)opensuse.org Packman Packaging Team Email: andrea(a)links2linux.de Web: http://packman.links2linux.org/ Cell: +39-328-7365667 - ------------------------------------------ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEYEARECAAYFAksmer0ACgkQyCZT87TFPuh49wCgmlo7sYCOLEOkMtatgfgNXxvl ytAAoMEiJ9HuS1XOVFnC/16j35YF/0cn =uxBS -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

1 0

[opensuse-factory] Security problem with mISDN?
by Joerg Mayer 14 Dec '09

14 Dec '09

Hello, I just stumbled on the following mail: http://www.isdn4linux.de/pipermail/isdn4linux/2009-December/004487.html As opensuse contains misdn here's my question: Is it possible for any user to dial any number in a system with default configuration? thanks Joerg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 1

[opensuse-factory] http://en.opensuse.org/Roadmap
by Hans-Peter Holler 14 Dec '09

14 Dec '09

says: openSUSE 11.3 Schedule (preliminary) * Thu, Dec 12 openSUSE 11.3 Milestone 1 release seems this date is gone twice: December the 12# was yesterday (Saturday), last thursday was Dec 10. And yes I see "preliminary". Is there any news? Hans-Peter -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

2 1

[opensuse-factory] Kernel oops 11.2
by Robert Schweikert 13 Dec '09

13 Dec '09

Does this have any meaning to anyone? This happens on openSUSE 11.2 (twice over the last 24 hours), when I was trying to load multiple web sites at the same time. One of the connections is trying to establish a VPN tunnel via SSL. Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.498896] Oops: 0002 [#2] PREEMPT SMP Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.498906] last sysfs file: /sys/devices/pci0000:00/0000:00:12.0/net/eth1/statistics/collisions Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.499128] Stack: Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.499128] Call Trace: Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.499128] Code: df 4c 0f 45 f8 49 83 e7 df 4c 89 fa 4c 89 fb e8 fb fc ff ff 48 85 c0 74 31 48 8b 10 f7 c2 00 00 02 00 0f 85 59 02 00 00 48 89 c2 <f0> ff 42 08 f0 ff 40 0c f6 40 18 01 48 8d 55 c0 74 07 48 8b 95 Message from syslogd@triumph at Dec 12 06:06:06 ... kernel:[563299.499128] CR2: 0000000000000008 Linux triumph 2.6.31.5-0.1-desktop #1 SMP PREEMPT 2009-10-26 15:49:03 +0100 x86_64 x86_64 x86_64 GNU/Linux I am going to switch to the default kernel and see if that helps. There are two ethernet controllers on the machine. 00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) Subsystem: nVidia Corporation Device c73e Kernel driver in use: forcedeth 00:12.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a3) Subsystem: nVidia Corporation Device c73e Kernel driver in use: forcedeth Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Software Engineer Consultant LINUX rschweikert(a)novell.com 781-464-8147 Novell Making IT Work As One -- To unsubscribe, e-mail: opensuse-factory+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-factory+help(a)opensuse.org

3 4