As discussed last week, I wanted to continue the discussion about the
package management changes - but not concentrating on the real bugs
we're fixing now but on general issues:
With SUSE Linux 10.1 we have redesigned the way we handle software. We
are proud to be able to announce our new software management backend
which is based on the so-called library "libzypp" and which also
integrates Novell's ZENworks technology. Also we decided to follow the
repomd standard (sometimes known as "YUM repository") for our new
In fact we are now able to manage more than packages only. We have
integrated flavors like patches, patterns and even products all of
which are defined and handled equivalently to packages. This new
framework allows for new ways to define system dependencies and to
build more complex application stacks also considering certain patch
levels, patterns or even products to depend on.
Also we were able to fix the well known issue where one could
compromise a system installation by installing outdated packages after
already having applied patches. Using the new technology the system is
now able to detect these kinds of package-patch dependency violations.
By integrating Novell's ZENworks technology we enriched our
distribution by a new command line tool called 'rug' and a daemon
called 'zmd' which are able to keep your system up-to-date. Also we
invented a new easy-to-use patch management user interface which is
called 'zen-updater'. These new tools are also able to tie into a
ZENworks Linux Management infrastructure in order to allow for
centralized remote management.
As these changes are also impacting the user experience regarding
package and patch management we'd very welcome to start a discussion
thread whether and how we still can further improve the current
One question we have is how the new tools rug, zen-updater and zmd
compare to what we had before with YaST Online Update and
suseWatcher. We are interested in every feedback ranging from
architecture, design or used standards and their enhancements.
As this topic is not a very easy one I guess we'll need several
iterations for this discussion. Therefore I'll try to summarize the
first discussion outcomes on http://en.opensuse.org/Libzypp/Design.
After a couple of weeks we can then continue the discussion after
everybody had the chance to work with - and love/hate - the new
Andreas Jaeger, aj(a)suse.de, http://www.suse.de/~aj/
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
With the supplied ZMD tools I was unable to connect to a ZENworks 7
host1-eth0:~ # rug sa https://server
Waking up ZMD...Done
ERROR: Could not add 'https://server': No suitable service types could
I suppose this happens because Suse 10.1 RC3 isn't listed in
https://server/zenworks-registration/ostargets.xml (and not supported at
As the ZMD tools are now part of the default install of Suse 10.1 I
suppose it's planned to support 10.1 in later releases of Zenworks?
Can anyone confirm this?
Ericsson Research, Corporate Unit
Ericsson GmbH, Eurolab
Ericsson Allee 1
Shuttle XPC, SB Audigy LS
If I make a Suspend-to-* and Resume, I have no sound as user, only as root.
After little work, I found out, that before Suspend permissions
under /dev/snd are set to
crw------ 1 marcel audio 116
After resume they are set to
crw-rw--- 1 root audio 116
Driver issue? Powersave problem?
Another problem is, that the output is alwasy set to the digital out. How to
tell the system, to use the analog output per default?
Mit freundlichen Grüßen,
Linux New Media AG
Tel: +49 (89) 99 34 11 0
Fax: +49 (89) 99 34 11 99
Can someone from SUSE tell me how bug handling is done there? I mean,
if there is a bug reported for some version and is not fixed in that
version, is it taken in account for upcoming versions or it is just
forgotten? An example:
- a bug (like #176249 and previously #148638) is reported for 10.0
- it was closed with WONTFIX as the change cannot be made to a released
- the bug is still present in 10.1 (somebody reports again)
- the bug is closed again as "it's too late and risky to do it"
- the bug is still present and will be possibly present in 10.2 (unless
it's "fixed" upstream)
(The upcoming possible scenario is:
- somebody reports "still present in 10.2" in a new bug
- it get's closed as "too late now for 10.2, maybe 10.3)
The problem I have is not the fact that is not fixed, but the fact that
the bug report is closed even if it is present (and gets forgotten).
In KDE we do the following: if a bug is reported for version X it is
considered to be present in all versions > X unless somebody says
otherwise, but in case of SUSE this doesn't seem to be the case.
Please enlighten me. ;-)
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
Would this list be the best place to post feedback regarding the test build of
the update stack packages you posted yesterday Andreas? Or is it better moved
to bugzilla...? If so I can move all this to bugzilla with logs etc.
Here are my observations so far anyway.
The 10.1 release update stack successfully installed the test builds after I
added the URL as a YUM service via zen-updater. However the whole upgrade
took an extremely long time ( 15 minutes approx ). I was unable to determine
why it was taking so long, i dont *think* it was the downloading...
Adding services via rug is just fine, and as per the 10.1 release builds ZYPP
services are synced with YaST, YUM services are not. Adding services via
zen-updater, same as rug, it works and the synching is the same.
2. Adding a larger service such as main online installation from
mirror( inst-sources ) is much smoother. The service itself was added to the
list in yast inst_sources almost instantaneously and unlilke the 10.1 release
the catalog was not immediately downloaded but was only fetched when the
finish button was pressed. At a rough guess I would say the whole process of
adding the main installation source is 50% quicker now.
ZMD scheduling seems to be a bit broken now. It appears that the service
refresh happens at the same time as the hourly maintenance, even though it is
scheduled for the next day. Once the full service refresh and maintenance has
run ( hourly by default it seems ) the schedule is reset with an updated time
for the service refresh 24 hours later and 1 hour later for the maintenance.
Of course the service refresh still happens one hour later and another new
time i scheduled for it.
This has the side effect of a full service refresh will run if my system is
booted outside of the hourly maintenance window, parse-metadata and
update-status hogging 100% CPU for a few minutes on boot. If i reboot my
system inside the hourly maintenance window this does not happen.
Forwarding to openSUSE(a)openSUSE.org and openSUSE-factory(a)openSUSE.org, as
this might be interesting for this forum as well ;) However, let's try to
have any kind of discussion on openSUSE-buildservice(a)openSUSE.org
---------- Forwarded message ----------
Date: Wed, 31 May 2006 20:45:13 +0200 (CEST)
From: Christoph Thiel <cthiel(a)suse.de>
Subject: [opensuse-buildservice] entering repoview
we have enabled repoview to make browsing the repositories more useable.
This also introduces RSS feeds for all repos. (Some repos might not have
the repoview browsing + rss feeds yet, as they are getting those once they
are pushed into software.openSUSE.org and it's mirrors.)
To get an idea of how it looks like, refer to  for the browsing part
and to  for the RSS feed.
I would like to theme the repoview pages a bit more openSUSE-like, but I'm
currently busy with other stuff. So, if there is anyone who would like to
work on the repoview template, please speak up now! The openSUSE.org wiki
or the brand-new build.openSUSE.org theming offer all the stuff that you
need, in terms of colors.
The repoview package is available from my home project in the openSUSE
Build Service (at ).
I'm sorry if i was perturbating this other thread with my
bugs remarks, but I'm very confused on this subject, and
-visibly- I'm not alone, so this must be addressed soon.
In short, what is really buggy in the update SUSE 10.1 sytem
and what is not?
reading opensuse list and suse-linux-e list, it seems that
nothing works on many hardware. The "I hate SUSE" game is
full of players.
the "most annoying bugs"
is itself buggy :-) say not very clear.
what can an ordinary user know about "zen-updater" (I myself
don't really understand what it's for);
"will crash YaST." is specially frightening.
all this makes me think "yast is not reliable" so my reaction.
all the threads about rug, zmd, smart... are also very
SO. we need a wiki page linked to "most annoying bugs" with
a clear statement like "In most situation you can safely use
YaST online update. More, you should use it for _all_ your
software work unless you are experienced with others
utilities." and more. And written with the normal user in
mind, not the debugger...
a page we could give as reference for any related question.
El Martes, 30 de Mayo de 2006 20:09, Alexei_Roudnev escribió:
> It is transparent for the user's processes, so why do you expect any
> changes in gcc?
Well, if Woodcrest is a new type of processor (even though it's based on
Xeon), it might have new registers, ... that have to be implemented in gcc.
If it's not implemented in gcc, you might not get all the performance you
might be looking for/expecting.
Just as you can, for example, specify:
Intel Pentium4 CPU with MMX, SSE and SSE2 instruction set support.
Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3
instruction set support.
Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE,
SSE2 and SSE3 instruction set support.
Maybe there's a:
The question would be: is there a -mtune=woodcrest?
> ----- Original Message -----
> Hi :)
> El Lunes, 29 de Mayo de 2006 11:59, Eberhard Moenkeberg escribió:
> > Hi,
> > On Mon, 29 May 2006, Rafa [iso-8859-15] Grimn wrote:
> > > Does anybody know whether Intel's Woodcrest processors will be
> > > It's a dual core Xeon processor.
> > >
> > > Would it be a x86-64?
> > >
> > > Any glitches, gotchas, advice regarding: kernel, glibc, gcc, ...?
> > I have some new Dell PE1850 with dual core Xeon CPUs (2 sockets, showing
> > 8 CPUs with HT enabled):
> > zim01:0 11:56:09 ~ # cat /etc/SuSE-release
> > SUSE LINUX 10.0 (X86-64)
> > VERSION = 10.0
> > zim01:0 11:56:26 ~ # uname -a
> > Linux zim01 2.6.13-15.8-smp #1 SMP Tue Feb 7 11:07:24 UTC 2006 x86_64
> > x86_64 x86_64 GNU/Linux
> > zim01:0 11:56:50 ~ #
> > /proc/cpuinfo says:
> Thanks, but do you know if there would be any modifications to glibc, gcc,
> kernel, ... ? I guess some registers have changed/been added to the CPU
> (chip) but haven't found any info regarding support by gcc.
50% of all statistics are inaccurate.
So I guess people are supposed to dig their way through opensuse.org before they install SuSE (or SUSE or whatsoever)? C'mon...please.
> -----Ursprüngliche Nachricht-----
> Von: opensuse-factory(a)opensuse.org
> Gesendet: 30.05.06 21:59:39
> An: suse(a)linuxin.dk
> Betreff: Re: [opensuse-factory] bugs or not bugs
> On Tue, May 30, 2006 at 09:43:17PM +0200, Martin Schlander wrote:
> > Check it out here:
> > http://en.opensuse.org/Using_10.1
> > I, or rather the wiki page, needs some information on the best way to disable
> > the beagle indexing stuff. And I also need some input on howto best recompile
> > the kernel module in case of kernel update when installing nvidia driver with
> > tiny-nvidia-installer. I think perhaps a paragraph on Updating
> > (configuration, ~suse/update/10.1, zen updater, YOU etc.) in 10.1 could be a
> > good idea.
> Nice. Perhaps also some ndiswrapper info and how to get your wireless
> online if you don't have any other connection.
> houghi http://houghi.orghttp://www.plainfaqs.org/linux/
> > Today I went outside. My pupils have never been tinier...
> To unsubscribe, e-mail: opensuse-factory-unsubscribe(a)opensuse.org
> For additional commands, e-mail: opensuse-factory-help(a)opensuse.org