Klaus Kaempf escribió:

A lot of developers here do this, so its not a technical problem per se.

I have been upgrading my factory copy with zypper since early alphas and seems it can manage upgrades preyy much fine except for 1. it is slow ( well, that's a general problem) 2. it emits "scary"(for users) errors and then seems to try with --nodeps and continue anyway. 3. it emits equally "scary" "invalid object" messages (wth means in this context..dunno ;) ) 4. Y and N dialogs are still messed up horrible. 5. it failed to upgrade on the libbz2 split ( as well smart, yast do anyway..;) )

However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.

yes, it is probably very, very hard to get right.

Until now, we didn't get sufficient customer request for this to justify the effort.

I would like to see a) upgrade with zypper b) upgrade with CD fully supported.

Andreas Jaeger escribió:

...

2. it emits "scary"(for users) errors and then seems to try with --nodeps and continue anyway.

Please file a bugreport.

filled long way ago, noticed in https://bugzilla.novell.com/show_bug.cgi?id=216042

...

3. it emits equally "scary" "invalid object" messages (wth means in this context..dunno ;) )

Please file a bugreport.

idem filled 2006-10-27 https://bugzilla.novell.com/show_bug.cgi?id=216042

...

4. Y and N dialogs are still messed up horrible.

Please file a bugreport.

already filled, dont have the bug report number handly atm though.

Please report any problems with zypper,

doh.:) that's what im doing all the time :-)

it should really become a good

it is already good but slow and have some glitches and bad error messages, but it fully functional. ;-)

tool that does not scare anyone!

it dont scare me :-) but some users has asked me "WTF is this", hence we have a problem ;-)

Here're the minutes from the meeting. * log entries in .changes file Just a simple "Update to version x.y" is not valid but happens far too often. .NEWS file for major changes? Goal: present the changes done to packages to users in a good way We have not found any appropriate solution. We will continue with the current practice: - packages need to have valid changes entries - a version update should include the highlight of the changes and not just "Update to version x.y" * Autofs5 instead of autofs4? autofs5 is a complete rewrite, moving autofs from kernel to userland. It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work. We decided to move forward with the switch. * Smaller systems - what can be done? Goal: A system with 128 MB of space. Challenges are especially: * Languages and localization * documentation - > some packages have documentation split up already * theming -> some packages will be split up so that only one theme is in a package. For languages we discussed previously already the following and will implement this now: The idea is to add to spec file of packages a new rpm macro so that subpackages are created and then related subpackages are repacked for each language in our build system. This way we would get e.g. basesystem-$lang and gnome-$lang packages and those can then be installed. To be continued next time. * Updating openSUSE: What options do we have - what will we advocate? - Boot from CD? - zypper update? - System Update? "System Update" is more about bringing the system in a consistent state. It did not work for us with our SLE service packs. Many developers and the community like to have an easy way to update their system to the latest and greatest version of the distribution - without rebooting. Currently there's no algorithm in place that handles different repositories correctly, just consider what should happen in the case of kernel and kmp package update with different repositories: * Update new kmp but keep old kernel * Update kernel and keep old kmp * Update kmp and kernel We need to define as well which repository is upstream, e.g. for moving from 10.2 to 10.3. Officially supported is currently only the system update from the installation system (after booting from CD). Update from a running system would need extra QA (this is currently not supported and not tested). Users understand that this does not work from 10.2 to 10.3 but not if they update daily or from e.g. Alpha2 to Alpha3. But both scenario are the same challenge. The underlying problem is package splits, package renames and package drops. This might need further policies which would lead to e.g. two perl versions installed in parallel for the transition. The challenge is not the leaf package but the core system. Note: Patterns are not updated with a zypper update. To achieve updating in a running system, we would need to enforce better policies for package splits, renames and drops and need to fix zypper to handle all this properly. This would still be an expert option since it might need user interaction for some choices. AI: aj to discuss further in smaller round whether what needs to be done. * TeXLive switch We have TeXLive now in the distribution but packages still use the old teTeX packages for building. Every packager should change the requires of their packages so that we can soon obsolete the old teTeX packages. We also have to get packages like cjk-latex, jadetex and xmltex working with the new TeXLive system. AI: send email to opensuse-packaging to inform packager what needs to be done for their packages. Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Matthias Koenig writes:

Andreas Jaeger writes:

...

* Autofs5 instead of autofs4?

autofs5 is a complete rewrite,

...

moving autofs from kernel to userland.

Uhm, I cannot remember having said that ;-)

That's what I understood - which means I did not understand you completely ;-(

autofs5 of course keeps the two component structure: User space daemon and kernel module. The Version 5 is related only to the user space daemon, the autofs4 kernel module is still required.

Thanks for the clarification.

...

It complies with other technologies, e.g. automounter from Sun, and therefore solves many open feature requests. Existing setup will continue to work.

Default setup will work out of the box. I forgot to mention that current Suse quirks (separating maptype and map-name by space instead of colon) which do not comply with the official configuration syntax of master maps will not work. But this is minor and will be documented.

Hope that this will not cause problems, let's go ahead, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

jdd writes:

Andreas Jaeger wrote:

...

Challenges are especially: * Languages and localization

think at a small enhancement: langage is not as much a goal than keyboard.

I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters).

So having localized keyboard should be a premium, up to the rescue system.

What are you missing *today*? If you change at the linuxrc boot the language, your keyboard is setup correctly - isn't it? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Andreas Jaeger schreef:

jdd writes:

...

Andreas Jaeger wrote:

...

Challenges are especially: * Languages and localization think at a small enhancement: langage is not as much a goal than keyboard.

I'm french. I read english very well, but using QWERTY layout on AZERTY keyboard is always a problem (specially with punctuation characters).

So having localized keyboard should be a premium, up to the rescue system.

What are you missing *today*? If you change at the linuxrc boot the language, your keyboard is setup correctly - isn't it?

As I recal correct one can choose the keybord language at set-up.......(seperate from OS lang..)

Andreas

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.2" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKPoUX5/X5X6LpDgRAsB7AKCsnCTxNCPiHyaSUtvnLI395wZ6lgCglnHe vKxBkrSyOL+Ut1W+R6c+FEk= =ZfX/ -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hello, on Donnerstag, 19. April 2007, Klaus Kaempf wrote:

* Christian Boltz [Apr 19. 2007 01:13]:

...

If it isn't too difficult, I would like to have a supported way to upgrade a running system. Please offer both zypper (for command-line fans) and YaST2 System Update (for more mouse-orientated users).

A lot of developers here do this, so its not a technical problem per se.

However, the QA and testing effort is quite huge and getting it 'fool proof' might be a huge task.

Yes, understandable. However, I would happily test it instead of having to wait for every beta to install - which means at least 2 hours "downtime" on my full-blown system... (yes, maybe I should uninstall some stuff.)

Until now, we didn't get sufficient customer request for this to justify the effort.

Wrong answer ;-) It happened more than once that someone tried to update his system with "YaST2 System Update" which resulted in wrong YOU-sources (from the old system), so everybody was warned not to use this YaST module. IIRC, there's even a SDB article about it which states that you should never upgrade a running system, but always boot the install CD to upgrade the system. And now you are wondering that this is rarely used and/or requested... Regards, Christian Boltz -- Designpreise sind wie Modenschauen: Was da beklatscht wird, ist interessant, Neu, aufregend und definitiv nicht tragbar im Alltag. [Ratti in suse-linux] --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

"Cristian Rodriguez R." writes:

Andreas Jaeger escribió:

...

* log entries in .changes file

Just a simple "Update to version x.y" is not valid in the packages changelog but happens far too often.

Goal: present the changes done to packages to users in a good way and use that for e.g. Release Notes.

1. The average user does not read package changelogs at all, probably they only read "patches" changelog if at all.

2. software provides NEWS and Changelog either included in the package or on the internet by their own. so it is absolutely pointeless to duplicate effort already done.

3. we provides **packages** of certain software, so the package changelog should include changes to the package **itself**. as stated previously there are counteless ways to retrieve software changes.(some poeple is even subscribed to announce lists of several software they use)

4. I have been told this is proposed to make autobuild people 's life easier,I wonder if autobuild people does not have a internet connection or a terminal to look at the NEWS file, the package can contain a link to the changelog.

5. Thsi unnecesarilly clutter changelog files with information that users **wont read**.

6. this cause unnecesarry work for packagers with no gain to users.

In short, I would like to know the real rationale beahind this as I currently can see a single reason to do what is proposed.

I'm under the impression that end users want to know in an easy way why the version update happened - and not only that it happened. We currently copy some of that information also around, e.g. add it to some announcements in a distilled way. I would like to see this improved, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

* Cristian Rodriguez R. [Apr 19. 2007 10:55]:

Andreas Jaeger escribió:

...

I'm under the impression that end users want to know in an easy way why the version update happened - and not only that it happened.

1. for patches this is already done in the patch changelog or in the "suse security announce "newsletter" "

2. if you are thinking about an overall "opensuse proyect changelog" ..well. that can be done asking the mantainers for meaniful. short, revelant and concise changelog **ONCE** just after the feature and version freeze starts, providing this way good information to users without all the permanent hassle for packagers that IMHO makes very lilte sense.

There was also the idea of an RSS feed accompanying the update channel with human readable information when Novell started the customer center last year. Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Volker Kuhlmann wrote:

* USB, and pretty much all hotplug, device mount options suck hamsters with straws. In a galactically big way. That is, there's no way to change them.

Huh? With the hal based mount users can do that with just a few mouse clicks.

* I find that I need to share files with family members all the time. Dito in return. If someone forgets to explicitly set group ownership and permissions on a file (daddy, what's that anyway?), the others can't read it. Ok it's a basic *ix problem for the computer scientists. However, family doesn't care, they Just Want It To Work(TM). Are there solutions? This case must be pretty common. No I don't count "stick it on a stick, because it has M$oft semantics ie no owners or permissions" as a solution.

SUSE Linux uses a default umask of 0022 and creates home directories with mode 0755. So it does just work (TM). cu Ludwig -- (o_ Ludwig Nussel //\ SUSE Labs V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri 20 Apr 2007 20:53:50 NZST +1200, Ludwig Nussel wrote:

SUSE Linux uses a default umask of 0022 and creates home directories with mode 0755. So it does just work (TM).

No, I do not view no access control as solution either. What I had in mind was more like any files copied to or created in directory X would be accessible by all users belonging to group Y. Btw the desktop icons properties trick doesn't change the uid and therefore doesn't help if <whatsit> decided to mount it as user joe when it's my stick and I'm ben. The problem with the ambiguous uid also arises when switching desktops, ie when further users create gui logins on consoles 8, 9... Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Fri 20 Apr 2007 21:55:46 NZST +1200, Duncan Mac-Vicar Prett wrote:

right click in the icon of the device and select "properties..." there you can change mount path, and other stuff.

Thanks, didn't know that. And it remembers devices. Can't change gid though. Volker -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org