All 25 entries tagged Opensuse

openSUSE 11.0 KDE4 inclusion

There seems to be a lot of misconceptions regarding the inclusion of KDE4 in openSUSE 11.0 that are leading to a great deal of anger on the mailing list.

KDE4.0 is the default in openSUSE 11.0. It is being forced upon users.

Not true. Both KDE3.5 and KDE4.0 (and GNOME) are offered when installing from the DVD or netinstall. There is no default. The KDE4.0 description is

KDE 4.0 is the most recent evolution of KDE. It comes with many new KDE technologies, but is less mature than the other desktops.

While KDE3 is described as

KDE 3.5 is the previous generation of the K Desktop Environment. It is mature and stable.

which I personally think is a fairly good description. This is only shown on new installs, if a user is upgrading an existing installation then he or she will remain with his or her existing desktop. Users are not forced or even suggested to change from KDE3 to KDE4.

Novell forced the inclusion of KDE4.0 was forced upon the openSUSE community for [insert conspiracy reason here]

There have been dozens of “Novell did not listen to the users” comments which are wrong for several reasons.

The topic was discussed at length in various media which are all open to everyone.

• Bugzilla
• IRC Project Meeting , and at the KDE team meetings too.
• Project mailing list, here, and several other threads.

The result of these discussions is what we have in openSUSE 11.0. They were not ignored, in fact they led to the inclusion of the KDE3 option clearly in the installer.

The second problem with these statements is they assume that everything that happens in openSUSE is a direct result of Novell policy. The openSUSE community is made up of many people including many who work for Novell. The decision to include KDE4.0 was made by the community and particularly the KDE team. There is no evidence that there was a Novell policy that KDE4.0 must be included in openSUSE 11.0. In fact, the descision was delayed until as late as possible when it could be made on technical merit.

KDE4 should not be included until it is ready.

How do you define ready? KDE4.0 is already ready for some users. Whether it is ready for you depends upon what featureset you use. I will not be switching myself until certain features are implemented.

There are good reasons to begin the move to KDE4.0 early.

• People can move over when KDE4 is ready for them.
• openSUSE specific tools and integrations can be ported to KDE4 gradually.

So far this process is something like this.

• openSUSE 10.3 : KDE3 the only prominent option in the installer. KDE4 was available for testing. The openSUSE tools are KDE3 based.
• openSUSE 11.0 : KDE3 and KDE4 are both prominent options in the installer, with a warning that 4.0 is not mature. Updater applet has been ported to KDE4. YaST has a Qt4 UI.
• Future : KDE3 may be dropped when KDE4 is good enough to replace KDE3 for the vast majority of users.

The current state of KDE4 migration is available on the wiki

There is no point filing bug reports against KDE4 because the developers know what is wrong with it.

• Few people will have exactly the same configuration as you, or use the same featureset, so will not run into the same bugs/missing features.
• Both upstream bug tracker, and the openSUSE bug tracker allow you to search for duplicate bug/enhancement reports before you file. You can find out for yourself whether anyone else has reported your issue.

This argument just seems to be “I’m too lazy to report issues, but quite willing to rant about them instead.”

Including KDE4.0 will lead to bad reviews.

This might happen. However, so far reviewer’s quibbles have been with entirely different issues. In fact there have been several positive reviews of the openSUSE shipped KDE 4.0.

There should be a KDE3.5 installable livecd.

This was not produced as there were insufficient resources to produce and test three installable livecds. Someone can always step up and help produce one.

Summary

• openSUSE is not forcing people to switch to KDE4. Users can switch to KDE4 when they wish. Both are included on openSUSE 11.0.
• If you find bugs in or are missing functionality in KDE4 please file bug reports so it can be fixed.
• If you have an opinion regarding when the timescale for moving to KDE4 you are free to get involved and influence the decisions. You do not have to resort to insulting developers on the mailing lists to be heard, in fact insulting developers so is a good way to ensure that people disregard your opinion.

: 24 Jun 2008 18:43 |  Tags: Kde4 Opensuse |  Comments (19) |  Close comments |  Report a problem

Upgrading openSUSE 10.3 –> 11.0 in a running system.

Upgrading openSUSE between releases while the system is running is not a currently supported method of upgrading. The supported method is to boot from an install medium and select the upgrade option. Nevertheless, it is possible to upgrade a running system. This is more difficult than normal with openSUSE 10.3 -> openSUSE 11.0 due to the change in RPM payload format from bz2 -> lzma which makes the RPM in 10.3 unable to install RPMs from 11.0.

Method

1. Upgrade RPM to the version in 11.0
2. Install the full package management stack from 11.0
3. Upgrade all packages.

Stages

The specific steps required to upgrade using the above method may vary from system to system, these are just those that I needed.

• Disable all the repositories I was using on 10.3.

  mv /etc/zypp/repos.d /etc/zypp/repos.d.old    

• Delete the repository cache.

  rm /var/cache/zypp/zypp.db        

• Add the main openSUSE 11.0 repository.

  zypper ar http://download.opensuse.org/distribution/11.0/repo/oss openSUSE110    

• Install the new RPM from openSUSE 11.0.

On 64bit:

rpm -Uhv 'http://download.opensuse.org/distribution/11.0/repo/oss/suse/x86_64/rpm-4.4.2-199.1.x86_64.rpm'

Or if you are on 32 bit:

rpm -Uhv 'http://download.opensuse.org/distribution/11.0/repo/oss/suse/i586/rpm-4.4.2-199.1.i586.rpm'

• Install the 11.0 package management stack.

  zypper in zypper    

• Add the 11.0 version of the nonoss and packman repositories, as I have several packages installed from these.

  zypper ar http://download.opensuse.org/distribution/11.0/repo/non-oss openSUSE110_NonFree
  zypper ar http://packman.iu-bremen.de/suse/11.0/ packman    

• Upgrade all packages. At this point I had to confirm several package vendor changes and removal of a few obsolete packages.

  zypper ref
  zypper dup    

• Reboot

Problems

I had only two significant problems after upgrading. Both turned out to be down to my having edited configuration files, so they were not automatically overwritten with the updated configuration files.

• Networkmanager would immediately disconnect after connecting. This turned out to be down to a stale dhclient configuration file. I solved this with:

  mv ./dhclient.conf.rpmnew ./dhclient.conf    

• openSUSE updater could not find any backends. This turned out to be down to a stale zypp configuration file. I solved this with:

  mv /etc/zypp/zypp.conf.rpmnew /etc/zypp/zypp.conf    

Since lack of a new configuration files can cause breakage in unexpected places it would be nice to offer users the chance of replacing or merging their configuration file changes, rather than requiring users to know about these files and merge them manually.

: 24 Jun 2008 13:49 |  Tags: Opensuse |  Comments (42) |  Close comments |  Report a problem

openSUSE IRC – call for participation

The #suse channel on the freenode IRC (Internet Relay Chat) network is one of the places users can go to get support with openSUSE. The channel has suffered a little over recent months from the loss of some regular participants. Since the opening of the openSUSE project many of the channel regulars have become involved in other areas of the openSUSE project, leaving less time for user support on IRC.

While the regular participants may have decreased, the throughput of users seeking help shows no sign of abating. There is a danger that with fewer people helping in the channel, users will either not get help or be put off by the attitude of a few in the channel.

There are regular complaints from a few about the state of the #suse IRC channel, often as an excuse for not participating. This does somewhat irritate me as it is one of the easiest things to fix yourself. Simply join the channel and participate, even a single person does make a big difference to the whole channel. Complaining helps nobody, and only serves to discourage those who are helping

So please join us in #suse. Help, be helped, and have a lot of fun! If you are using openSUSE You can probably just click here to join the channel .

Reasons for being in #suse

• Improve end user support

#suse is one of the places users may look for help. It is linked on http://help.opensuse.org, from the desktop, and the openSUSE IRC clients default to joining the channel. IRC, being interactive, gives the opportunity to arrive at a problem diagnosis much more quickly than possible with a mailing list. It also has the disadvantage that no-one may be available or able to answer your question. It supplements the other support fora such as mailing lists & web forums.

• Improve channel atmosphere

#suse, along with the mailing lists and forums, is one of the parts of the community that new users will come into contact with. Their experience here may dictate whether they continue using the distribution or not, or whether they participate in the project or not. If users do not get their problems solved they may be forced to look elsewhere. If users have a bad experience in the channel, they may be discouraged and look for another community. It is therefore critical that we provide the best possible experience for users in the channel. This is not a policy problem (we have rules and guidelines), but a people problem. The people in the channel define its atmosphere and quality.

• Learn new things about openSUSE

Even if you think you are a suse expert, you will likely be surprised at the things you will learn by simply watching other people helping in the channel. This will then help you to help others in the future.

• Get your questions answered

Nobody is an expert in all areas, in addition to helping others you can have your own questions answered as well.

• Get to know other openSUSE users.

IRC provides interactive chat. With IRC it is possible to socialise and live the suse motto “Have a lot of fun” much more than is possible with other media such as mailing lists.

• Learn what the user painpoints are.

If you are involved in the openSUSE project, being in #suse gives a special insight into the most common problems users experience. It helps make the problems that need to be addressed in the future clear.

Possible reasons for not joining #suse

• I don’t like the channel atmosphere / I’ve heard it’s unfriendly

An IRC channel is simply a venue. The atmosphere of the channel is defined by those who are in it and active at any given time. Since there is rarely more than a handful of people active at any time, if you are speaking in the channel then you are pretty much defining the atmosphere. Improving the channel friendliness is simply a matter of joining and occasionally talking. If you encounter someone in the channel being antisocial or in violation of one of the channel rules, then contact one of the ops [/msg susehelp ops], who can then take appropriate action.

• The channel is too busy. I don’t have time to spend in #suse

Just being in the channel does not obligate you to talk, help, or even read it. Most of those in the channel will be doing other things, occasionally glancing at the channel. If they happen to see something they can help with they will. If there are enough people doing this then it translates into quite good support coverage, and not much of a timesink.

• I don’t know enough to help others

This is rarely true. Not all questions are of equal difficulty. At least half of user questions are frequently asked questions which can usually be resolved by supplying a bot factoid or URL. As they are frequently asked you will see others answering these questions after spending a little time in the channel, you can then immediately start helping answer these questions in the future by repeating the solution. Of the more difficult questions, there is a scale of difficulty. If you have used openSUSE for any length of time you will probably be surprised how many questions you will be able to answer.

: 26 Mar 2008 12:13 |  Tags: IRC Opensuse |  Comments (3) |  Close comments |  Report a problem

Interactive Firewalls?

openSUSE comes with a firewall (SuSEfirewall2) which is enabled by default on desktop installation and drops all incoming traffic. There are often discussions as to whether this is a good thing or not, with strong opinions on either side. I won’t get into those.

The problem for users is that some things such as

• Samba share browsing
• File sharing
• Remote access
• Avahi

will fail to work, often silently. Some people just assume that the function is broken. A fewer think to disable the firewall and try again. Still fewer are able to open just the ports they require open in the firewall. One of the most frequently asked questions on IRC is why samba browsing does not work.

Obviously simply having the firewall disabled by default for internal networks would solve the problem. However, this is an unpopular option amongst some, and if the firewall is enabled it should still be possible to help the user know what to do.

I knocked up a little proof of concept application which

• Watches events in the firewall log
• Matches those events against predefined suggestions
• Proposes relevant suggestions to the user.
• If user approves, will open ports automatically using YaST

So, for example, if the user is trying to set up a webserver and the firewall is blocking access to it, it will suggest opening port 80.

Or if the user tries to browse samba shares and the firewall blocks the responses it will suggest opening high ports to allow these responses to get back.

More screenshots here

What do people think about this idea? Does anyone know of any other similar projects for interactive firewalls on linux? Mandriva has “mandi” but this seems more geared towards being an interactive fail2ban than offering suggestions.

My little demo source code is available if anyone is interested.

: 24 Mar 2008 14:34 |  Tags: Firewall Opensuse |  Comments (24) |  Close comments |  Report a problem

One–Click–Install improvements

I fixed a few bugs/wishes in the openSUSE “one click install” handler last week.

Amongst potentially interesting changes are

• Addition of command line support as I previously mentioned

• Tidied up the UI a little removed the somewhat cryptic “advanced mode” checkbox in favour of an editable proposal, as used elsewhere in YaST.

• Don’t show this again support for nag warning

Clicking customise gives the equivalent of the old advanced mode

Click here to install on 10.3

: 24 Mar 2008 14:27 |  Tags: One-Click-Install Opensuse |  Comments (7) |  Close comments |  Report a problem

Easier YMP Creation

Some people have requested a GUI for creating YMP (One Click Install) files (It seems some people have an aversion to XML) .This is something I had looked at in the past, but decided that it the resulting UI would be at least as complex as the generated XML.

I had another go at this today, and the resulting form really doesn’t seem to be much easier to use than writing the XML manually.

All you save is typing out the tags, which an XML editor would help you with anyway.

Perhaps a better approach for simple YMPs would be to convert user selections within the package management into a one click install file.

YaST software management (at least the Qt version) does provide a mechanism to export user selections to a file:

Which generates a file like

[Update]             MozillaSunbird                 |   21.0 M   | 0.7-6.3          | 0.7-6.3         
[Install]            MozillaSunbird-debuginfo       |    5.7 M   | 0.7-6.3          | ---             
[Install]            MozillaSunbird-translations    |   11.6 M   | 0.7-6.3          | ---             

It might be possible to convert this file into a YMP automatically, which would make generating simple YMPs easy. I might have a go at this sometime. However, it will not help creating complex YMPs with support for multiple distributions/versions, and translations.

Does anyone have any other suggestions for approaches to ease creation of YMP files for one click install links?

: 26 Feb 2008 21:14 |  Tags: Opensuse |  Comments (1) |  Close comments |  Report a problem

Third party updates

James since your blog doesn’t appear to support comments I’ll stoop to “discussion by blog”.

You state that third party repositories are not considered by the updater tools (YaST Online Update,Updater applet, zypper). This is not really true. In fact, by default the tools will only notify you of updates that are patches (higher priority than newer versions of packages). These patches could be in any repository, in practice they are only used in the official update repository. There is some more information about how patches are specified on the wiki .

Now, while only these “patches” are considered important enough to notify the user of, and apply automatically, other repositories are considered while performing the updates. This means that in the case of a new kernel patch being released which is incompatable with the currently installed nvidia driver, the kernel patch will not be installed until there are updated nvidia drivers available in the nvidia repository that will work with the new kernel. Once there is a new nvidia driver available the update will install and will pull in the updated nvidia driver from the other repository as a dependency automatically. The same should happen with madwifi, though they were quite slow in making new drivers available for the recent kernel updates, if it does not then it’s probably a packaging issue. There is more information about kernel module dependencies in this paper.

Furthermore, if you wish to be notified of new versions of packages in any repository, as well as patches, you can be. Simply tick the “Show upgrades” tickbox in the updater.

You can also do this with zypper

zypper up -t package

(That’s a literal “package” , not a package name)

This is not enabled by default as just because a user has a repository available in his or her package manager it does not mean that he or she necessarily wishes to install newer versions of packages just because they are there. For example packman repository has had problematic alsa upgrades in the not too distant past, which most people do not want. There is also the issue of “vendor bouncing” where a newer version of a package becomes available in one repository, and then in another, and so on. There are other ways to resolve that though, such as vendor sticky (Assuming the user wishes to stay with upgrades & updates from the same vendor, unless he or she specifically installs one from another vendor).

: 19 Feb 2008 20:13 |  Tags: Opensuse |  Comments (3) |  Close comments |  Report a problem

Command–Not–Found on openSUSE

Ubuntu ships with a programme called command-not-found which will suggest a package to install when the user types a command at the terminal which can’t be found. It seems this makes use of a hook called command_not_found_handler() which is not available in SUSE.

Pavol Rusnak is working on porting this programme to openSUSE, so it might be available for 11.0. But is it possible to get this behaviour on a vanilla openSUSE 10.3 without installing any other packages?

It does seem possible to do something hacky to get such behaviour:

export PROMPT_COMMAND='
if [ $? -eq 127 ]; then 
    history -a; 
    COMMAND=$(tail -n 1 $HISTFILE); 
    SQL="SELECT name from resolvables WHERE id IN (SELECT resolvable_id FROM named_capabilities WHERE name_id IN (SELECT id FROM names WHERE name LIKE \"$COMMAND\")) LIMIT 1;" 
    PACKAGE=$(echo $SQL | sqlite3 /var/cache/zypp/zypp.db); 
    PACKAGE=${PACKAGE:="-"};
    if [ $PACKAGE != "-" ]; then 
    echo $COMMAND is not installed\; Try \"sudo zypper install $PACKAGE\" to install it.; 
    fi; 
fi'

Then you get similar behaviour:

benji@lcars:~> kopete
bash: kopete: command not found
kopete is not installed; Try "sudo zypper install kdenetwork3-InstantMessenger" to install it.

benji@lcars:~> amarok
bash: /usr/bin/amarok: No such file or directory
amarok is not installed; Try "sudo zypper install amarok" to install it.

benji@lcars:~> nothingprovidesthis
bash: nothingprovidesthis: command not found

benji@lcars:~>

However, the whole adding command to history and then re-reading seems like a really bad idea. Possibly a security hole if someone adds something malicious to .bash_history so it’s probably not a good idea to use this ^_. If anyone knows how to get the previous command in a better way please let me know. “fc” will return it, but not until after PROMPT_COMMAND has been executed it seems.

It also assumes that anything with exit status 127 is a command not found, which is probably not always true.

Also it doesn’t seem to work in other shells that are not bash.

Any better way to do this without command_not_found_handler() ?

: 11 Feb 2008 14:41 |  Tags: Command-Not-Found Opensuse |  Comments (2) |  Close comments |  Report a problem

One Click Install links from the command line.

I get asked occasionally whether it is possible to install some software from a “one click install” link from the command line. Well now it is.

I’m not entirely sure what peoples’ usecase for this is, but up until now the only answer has been to download the .ymp file, read it and follow the instructions manually.

Fortunately the one click install handler is implemented using YaST, and YaST not only makes it easy to make your interfaces display with Qt/GTK/Ncurses⁰, but also to add command line interfaces.

Several YaST modules already have command line interfaces. For example try running

  yast2 lan help

This made it quite easy to add command line support to the one click install handler.

Here’s a screenshot of it in action:

There is no support for doing anything interactive, like selecting optional software yet, but it should be functional.

If you want to try it out on openSUSE 10.3 simply

1. Copy http://bw.uwcs.co.uk/OCI/CLI/OneClickInstallCLI.ycp to /usr/share/YaST2/clients
2. Copy http://bw.uwcs.co.uk/OCI/CLI/OCICLI to somewhere in your $PATH.
3. Then run

     OCICLI <url>    

I need to remove some duplication of code with the existing graphical handler before committing to SVN, but it should be possible to include in future openSUSE versions if people want it.

[0] There’s a bug with the version in 10.3 that prevents it from functioning in ncurses mode, this should be fixed before 11.0

: 09 Feb 2008 21:27 |  Tags: Opensuse |  Comments (4) |  Close comments |  Report a problem

openSUSE presentations

While thinking about content for my talk at FOSDEM I was reminded that I never uploaded the slides for the talks I did at my local GNU Linux user group . I have now uploaded the slides, and they are also available here:

• Build Service Talk

• YaST Talk

Also check out some of the other interesting talks that members of WUGLUG have given this year.

The description for my FOSDEM talk is at http://fosdem.org/2008/schedule/events/opensuse_one_click_install . If anyone has anything in particular they would like me to cover then please let me know.

: 09 Feb 2008 17:52 |  Tags: Opensuse Wuglug |  Comments (3) |  Close comments |  Report a problem