Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Druid wrote: >> I think my proposal of >> - no automatic inter-vendor upgrades, only explicit >> - only explicit user locks (rules) >> >> is much more simple and consistent. IMO vendor is the wrong thing to attach this behaviour to. What would actually be needed is *repository* priority or not doing "inter-repository upgrades". Another aspect/solution/idea would be to differentiate the behaviour of YaST2 wrt install/upgrade/remove (sw_single) and "online update". Or, maybe the best solution, but arguably the one that needs the most thought: being able to configure a "profile" for YaST2's behaviour: - - conservative - - always upgrade > Its better, a little bit saner. I would prefer not to upgrade by default. That's your preference. Hence the "profile" option is the nicest way to accommodate (almost) everyone, but probably far from being trivial to implement. > You dont need to upgrade either when there is a new version of a > package in packman either. Specialy when there are some cvs builds, Wrong. Packages that are not present in the openSUSE distro or only as crippled versions also have security issues or important bugfixes. You definitely almost always want to upgrade to the latest version. > experimental stuff, that can break easily. And as people said, just > because you want codecs, doesnt mean you want to install alsa and lots > of other core packages available in packman for some reason. Splitting Packman (and Guru and ...) into "stable" and "experimental" repositories could be an option (but it's not as trivial as it might sound, because of dependencies). > Henne´s proposal will increase upgraditis. We dont need that. Its > enough clueless people breaking their sytems with xgl, compiz and > beryl. I don't think the behaviour of the package manager has much influence on that. If people want the latest Xgl/compiz/beryl/mplayer/..., they'll install it, whether the package manager makes things a pain in the ass or not (it's just going to be a pain in the ass, like now). cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> _\_v The more things change, the more they stay insane. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFGKTJqr3NMWliFcXcRAmtxAKCOI8u+bO42/silPrxLDj0AcctYKQCgqRvf HzD8EMkPMKnxeKc41JPxY/4= =WWPf -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Delta iso
you need to apply this iso to the old iso like this applydeltaiso oldiso.iso deltaiso.iso newiso.iso then burn newiso in k3b On 4/21/07, Edward Dunagin <[EMAIL PROTECTED]> wrote: I downloaded openSUSE-10.3-Alpha2_Alpha3-DVD-i386.delta.iso. but very unsure what it is. When I go to burn it, k3b tells me it is not an iso9660 file. Will this update my alpha2+ to alpha 3? -- Edward Dunagin-Dunigan-Dunnigan 4646 Glenwood Drive Bozeman, MT 59718 mobile 406-570-0992 Landline 406-556-7282 http://doas.montanalinux.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- with best regards from Russia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[opensuse-factory] Delta iso
I downloaded openSUSE-10.3-Alpha2_Alpha3-DVD-i386.delta.iso. but very unsure what it is. When I go to burn it, k3b tells me it is not an iso9660 file. Will this update my alpha2+ to alpha 3? -- Edward Dunagin-Dunigan-Dunnigan 4646 Glenwood Drive Bozeman, MT 59718 mobile 406-570-0992 Landline 406-556-7282 http://doas.montanalinux.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case.. You wouldnt call but it is. And who said all repositories contains tested packages? A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system... That of course is a non sense, as it depends on the repository, not on the lock method, package manager, or the user. If you are afraid of losing a good working system, you should isntall waht you want after installation, and never ever touch the package manager again. Thats the way you wont never lose a good working system. In fact, if people did this more often, they would break much much less their installations Marcio --- druid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Druid schreef: >> I think my proposal of >> - no automatic inter-vendor upgrades, only explicit >> - only explicit user locks (rules) >> >> is much more simple and consistant. > > Its better, a little bit saner. I would prefer not to upgrade by default. > > You dont need to upgrade either when there is a new version of a > package in packman either. Specialy when there are some cvs builds, > experimental stuff, that can break easily. And as people said, just > because you want codecs, doesnt mean you want to install alsa and lots > of other core packages available in packman for some reason. > > Henne´s proposal will increase upgraditis. We dont need that. Its > enough clueless people breaking their sytems with xgl, compiz and > beryl. This is not realy correct, if a system has to be improved, in this case the way to update/grade, this feature has to be tested vigourously, i would not want to call this behaviour 'upgraditis' ...in this case.. A way has to be found, to upgrade from url, without to have to be afraid to loose a goodworking system... > I guess that everyone has his/her own taste according the look and feel of > his/her Desktops. > > So am I liking one specific transparent sys-monitor, which comes with > caramba: i-cons-sysres. > > In the upper-right corner of the screen (you can hang it where-ever you > like..)it shows me CPU, RAM and swap load consumption, little things i want > to know if the sys slows down.(top open on another desktop to find the > cause..) > I do not need a dominant gui, just the figures is enough. > > But caramba's support stopped somehow, and as KDE loads all apps i have open > when i shut down,(very nice feature btw..) it now stopped to load the monitor > (and Also Amarok ( hand...shame..) > > As I have all the apps I use getting loaded on start-up, the start-up time is > a little longer, but everything should be ready when i come back... > > But now corn has to ask everytime for validating the mailserver-certificate, > and when i answer 'accept forever', every session this is asked, for 2 > mailboxes x 4 buttons to push? > These things make me dislike an ap, (might be a bug..), makes me decide to > shut it off..(or get an update..if there was one..) > > Also, still the time nessesary for reading the metadata is much too long, and > that way updating, or installing an app, takes too much time > > (What happened to the clever discussion about this subject some weeks ago?) > > (just little annoyances, making the experience a little less fun, that is > all..) I like SuSE very much, installed the 102 32Bits retailversion on a U-Buddy yesterday. (barebone) P4 2.66GHz, 1024MB Ram, 160GB 2,5 " IDE HDD, which has to gonna be my 'car-pc', for in the camper, USB GPS for the 'tomtom' and a 12" touchscreen (second-hand, has to be 'rubberized' open steel version), come to it, doing this all by myself, save me about 600,- euro, minimum. The idea to have lot of music, good movies, and all my apps while traveling makes me feel very 'complete'.. > > Marcio > --- > druid > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.8-01-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] Systeem: openSUSE 10.2 (X86-64) KDE: 3.5.5 "release 45.4" -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKQ6XX5/X5X6LpDgRAhmfAJ4/fJKf9O05zjRulpKK04zEvLnrMgCg3/+b 6x8e2YU0vAOFgBZEndqsicw= =Po9L -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jaeger schreef: > jdd <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. Its better, a little bit saner. I would prefer not to upgrade by default. You dont need to upgrade either when there is a new version of a package in packman either. Specialy when there are some cvs builds, experimental stuff, that can break easily. And as people said, just because you want codecs, doesnt mean you want to install alsa and lots of other core packages available in packman for some reason. Henne´s proposal will increase upgraditis. We dont need that. Its enough clueless people breaking their sytems with xgl, compiz and beryl. Marcio --- druid - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
Andreas Jaeger wrote: jdd <[EMAIL PROTECTED]> 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 sure, but if there is a question about localization, I only suggest localized keyboard is the most important, much more than langage (and the rescue system have no kind of localization) jdd -- http://www.dodin.net Cécile, esthéticienne à Montpellier (à domicile) http://gourmandises.orangeblog.fr/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
jdd <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], 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 pgpqlb8Wome1s.pgp Description: PGP signature
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
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. jdd -- http://www.dodin.net Lucien Dodin, inventeur http://lucien.dodin.net/index.shtml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Exactly, so for crippled packages, you want to switch vendor, and keep upgrading from the same vendor. If you lock them like now, you dont get upgrades If you allow inter vendor upgrades, if a crppled version from another vendor has a newer version, it will be replaced. I think my proposal of - no automatic inter-vendor upgrades, only explicit - only explicit user locks (rules) is much more simple and consistant. -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 M9. schreef: > > > Alberto Passalacqua schreef: >> Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: > >>> The user specifically requested newer unsupported packages by adding >> the >>> 3rd party repo. Why would the package manager hold back those packages >>> and install them only on request? >> In general, users add packman and other repositories to enable features >> not available in the default packages provided by SUSE. This doesn't >> mean that all more recent packages from packman have to be installed to >> replace the default ones. The decision should be left to the user and >> not by the package manager, because upgrading all default packages with >> 3rd party ones automatically might bring to a messed up system. > > > I am carefull now with other pkgs except the ones I realy need: Samba,(a > story on its own..) libxine, w32codec-all.. ..forgot libdvdcss, i allways have a tar lying around to compile > > Only factory upgrades? No problem at all... >> Regards, >> Alberto > >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] > > > - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] 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 iD8DBQFGKN1fX5/X5X6LpDgRAryVAJ90G6SlnPfQcF7fr1Fasz8tKlNYqgCgwJ5z hDllIDUtM21LVcL4A8eQwVQ= =Kdax -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alberto Passalacqua schreef: > Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: > >> The user specifically requested newer unsupported packages by adding > the >> 3rd party repo. Why would the package manager hold back those packages >> and install them only on request? > > In general, users add packman and other repositories to enable features > not available in the default packages provided by SUSE. This doesn't > mean that all more recent packages from packman have to be installed to > replace the default ones. The decision should be left to the user and > not by the package manager, because upgrading all default packages with > 3rd party ones automatically might bring to a messed up system. Here i agree, it happened to me on 100, which became useless,(had to reinstall, choose 101),on 101, which became instable, but still worked, and also on 102. the retailversion, which took about 3 hours to upgrade a few pkgs, and all kind of mysterious happenings flew over the screen and got me realy worried,(it costs a day to get everything back to normal after wrekking an OS..) and when it was done, I thought: this is the last time like this!, but after finishing, the system was and still is stable as a house( but i still do not know what realy happened there...a feeling i personaly don't like at all..) I am carefull now with other pkgs except the ones I realy need: Samba,(a story on its own..) libxine, w32codec-all.. Only factory upgrades? No problem at all... > > Regards, > Alberto > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] 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 iD8DBQFGKNjqX5/X5X6LpDgRAo+XAKCNn3YZ+uj4/6nMfNphGEvaocZHhQCeIibT JyRZFxOwLOo1FQtrBaSaVsk= =tuQb -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
Matthias Koenig <[EMAIL PROTECTED]> writes: > Andreas Jaeger <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED], 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 pgpbGz7Y8N67Y.pgp Description: PGP signature
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
Andreas Jaeger <[EMAIL PROTECTED]> writes: > * Autofs5 instead of autofs4? > > autofs5 is a complete rewrite, > moving autofs from kernel to userland. Uhm, I cannot remember having said that ;-) 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. > 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. Matthias - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
>>> On 20-04-2007 at 16:06, Martin Schlander <[EMAIL PROTECTED]> wrote: > I wonder, do kde-backports and kde-playground have same vendor? If not this > behaviour would also make it possible to have kde-playground enabled for > certain packages, without constantly having to be alert as to whether you're I think the whole thing is going in the right direction now: have upgrades happen only withing the same vendor. This would allow me to add packman again as a source (hmm. just wonder: do I need it? anyhow I can just copy thge required RPMs down). But this gives a new 'problem' for the BS repos: as far as I know, they're all by the same vendor. Maybe the repo name should be added there, so that 'inter-repo-updates' (so from one repo to another' don't happen. Example: I have GNOME:UNSTABLE in my source list. out of GNOME:UNSTABLE I link some to my home repo, with some patches. Both are in my source list. I most likely will want to keep the packages from where I installed them until further configuration. A notice, that another subscribed repo provides a newer version could thus be interesting... but that's another story. Dominique -- TMF is a global management and accounting outsourcing firm with 72 offices in 56 countries and over 2,000 professionals (February 2007). TMF is expanding rapidly throughout the world. Learn more about our unique network and our services and visit our website at www.tmf-group.com. The information contained in this e-mail communication is confidential and solely intended for the person to whom it is addressed. If someone other than the intended recipient should receive or come into possession of this e-mail communication, he/she will not be entitled to read, disseminate, disclose or duplicate it. If you are not the intended recipient, you are requested to notify the sender and to destroy the original e-mail communication. TMF is neither liable for the correct and complete transmission of the information contained in this e-mail communication nor for any delay in its receipt. This footnote also confirms that this email message has been checked for the presence of computer viruses. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 15:06:34, Martin Schlander wrote: > Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: > > > I like the suggestion a lot. The user will specifically want to > > > install the packman versions of crippled packages, but won't want > > > build service re-cripped newer versions to override them. > > > > This is is such a special usecase that you will only be able to solve > > this, without user knowledge, if you can mark repos as leading, > > authorative or whatever. I dont think you can (and should) solve these > > usecases on a package level. > > I think this is a quite common usecase actually. > > Many users will have KDE-backports, Packman and Guru and many packages exist > on two out of the three repos. And if you're not paying attention you'll be > playing 'ping-pong' as so elegantly put by Duncan. > > Amarok (most people will want Guru, BS version is crippled wrt. database > support I believe) > > [...] And you should decide these on a package basis (setting something to taboo if you definately dont want it). This however should have nothing to do with the general policy. Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Friday 20 April 2007 14:42:42 Henne Vogelsang wrote: > The user specifically requested newer unsupported packages by adding the > 3rd party repo. Why would the package manager hold back those packages > and install them only on request? No, especially with the build service, you never know what package will appear there (in a specific repo) you just dont want to use. The packages in a repo are not a "constant" you agree on. Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: > > I like the suggestion a lot. The user will specifically want to > > install the packman versions of crippled packages, but won't want > > build service re-cripped newer versions to override them. > > This is is such a special usecase that you will only be able to solve > this, without user knowledge, if you can mark repos as leading, > authorative or whatever. I dont think you can (and should) solve these > usecases on a package level. I think this is a quite common usecase actually. Many users will have KDE-backports, Packman and Guru and many packages exist on two out of the three repos. And if you're not paying attention you'll be playing 'ping-pong' as so elegantly put by Duncan. Amarok (most people will want Guru, BS version is crippled wrt. database support I believe) Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) Digikam (most people will want the backported version cuz the packman version causes problems with some libs) K3b (sometimes packman has had development builds, which not all will want) Alsa (if your sounds working nicely why would you want to do a risky upgrade automatically for something like that). To name a few very popular packages where I'm aware of problems (presently or in the past). I wonder, do kde-backports and kde-playground have same vendor? If not this behaviour would also make it possible to have kde-playground enabled for certain packages, without constantly having to be alert as to whether you're updating to something alphaish. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
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, [EMAIL PROTECTED], 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 pgpnCsoV9ALvW.pgp Description: PGP signature
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 14:24:53 skrev Benji Weber: > I like the suggestion a lot. The user will specifically want to > install the packman versions of crippled packages, but won't want > build service re-cripped newer versions to override them. Also it > would help discourage upgrade all mentality which would replace all > suse supported packages with the newer unsupported versions on packman > when the user doesn't require the newer version. > > > I see and i dont like it. Because that would mean that you never get > > anything updated from a 3rd party repo because there the vendor will > > always be != > User would still be able to request upgrade to a different vendor, but > automatic upgrades to different vendor are more likely to cause > problems than be useful imo. I agree. But Henne makes a good point too, and I have no doubt that many, many users will be very unhappy if "upgrade all"-behaviour is made more difficult for them - even if it is for their own good ;-) Many already want it to be even easier than now - for example by opensuseupdater supporting it. Maybe it could be possible to have two options. Only do semi-automatic updates from same vendor (default) and Do semi-automatic upgrade of any package where newer version is avaialable, (break-my-SUSE) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On 4/20/07, Henne Vogelsang <[EMAIL PROTECTED]> wrote: Hi, On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: > On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > > Is that not the same as we have now? > > No, now packages from other vendors are locked. Nothing should be locked > unless the user locks it. > > I am just saying the solver should not take a update from a _different_ > vendor (different from what you have right now, not != SUSE) in consideration > (unless the user explicitly do it) , that does not mean you lock it. I like the suggestion a lot. The user will specifically want to install the packman versions of crippled packages, but won't want build service re-cripped newer versions to override them. Also it would help discourage upgrade all mentality which would replace all suse supported packages with the newer unsupported versions on packman when the user doesn't require the newer version. I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != User would still be able to request upgrade to a different vendor, but automatic upgrades to different vendor are more likely to cause problems than be useful imo. _ Benjamin Weber - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Il giorno ven, 20/04/2007 alle 14.42 +0200, Henne Vogelsang ha scritto: > The user specifically requested newer unsupported packages by adding the > 3rd party repo. Why would the package manager hold back those packages > and install them only on request? In general, users add packman and other repositories to enable features not available in the default packages provided by SUSE. This doesn't mean that all more recent packages from packman have to be installed to replace the default ones. The decision should be left to the user and not by the package manager, because upgrading all default packages with 3rd party ones automatically might bring to a messed up system. Regards, Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Friday 20 April 2007 13:13:04 Henne Vogelsang wrote: > I see and i dont like it. Because that would mean that you never get > anything updated from a 3rd party repo because there the vendor will > always be != Of course not, because the package from a 3er party is seen as a replacement, not as an upgrade. You can always manually (click twice) "upgrade" (or "replace") one vendor to another, and then the semantics are the same, the packages will be automatically updated if newer versions from your new vendor are available. If it does not work like I say, it basically means cou could be playing ping pong across 2 or 3 vendors as newer packages come out, or you do it like now, which sucks. Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 13:24:53, Benji Weber wrote: > On 4/20/07, Henne Vogelsang <[EMAIL PROTECTED]> wrote: > > On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: > > > On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > > > > Is that not the same as we have now? > > > > > > No, now packages from other vendors are locked. Nothing should be > > > locked unless the user locks it. > > > > > > I am just saying the solver should not take a update from a > > > _different_ vendor (different from what you have right now, not != > > > SUSE) in consideration (unless the user explicitly do it) , that > > > does not mean you lock it. > > I like the suggestion a lot. The user will specifically want to > install the packman versions of crippled packages, but won't want > build service re-cripped newer versions to override them. This is is such a special usecase that you will only be able to solve this, without user knowledge, if you can mark repos as leading, authorative or whatever. I dont think you can (and should) solve these usecases on a package level. > Also it would help discourage upgrade all mentality which would replace all > suse supported packages with the newer unsupported versions on packman > when the user doesn't require the newer version. The user specifically requested newer unsupported packages by adding the 3rd party repo. Why would the package manager hold back those packages and install them only on request? > > I see and i dont like it. Because that would mean that you never get > > anything updated from a 3rd party repo because there the vendor will > > always be != > User would still be able to request upgrade to a different vendor, but > automatic upgrades to different vendor are more likely to cause > problems than be useful imo. Automatic inter-vendor updates are what people expect to happen. Its what we currently do not deliver with yast but with all other package managers. There it works fine since ages. Why would we prohibit it (again)? Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin Schlander schreef: > Den Friday 20 April 2007 14:42:42 skrev Henne Vogelsang: >>> I like the suggestion a lot. The user will specifically want to >>> install the packman versions of crippled packages, but won't want >>> build service re-cripped newer versions to override them. >> This is is such a special usecase that you will only be able to solve >> this, without user knowledge, if you can mark repos as leading, >> authorative or whatever. I dont think you can (and should) solve these >> usecases on a package level. > > I think this is a quite common usecase actually. > > Many users will have KDE-backports, Packman and Guru and many packages exist > on two out of the three repos. And if you're not paying attention you'll be > playing 'ping-pong' as so elegantly put by Duncan. > > Amarok (most people will want Guru, BS version is crippled wrt. database > support I believe) This is correct.. > > Ktorrent (most people will want Guru, BS-version crippled wrt. DHT) > > Digikam (most people will want the backported version cuz the packman version > causes problems with some libs) > > K3b (sometimes packman has had development builds, which not all will want) > > Alsa (if your sounds working nicely why would you want to do a risky upgrade > automatically for something like that). Agree.. > > To name a few very popular packages where I'm aware of problems (presently or > in the past). > Yes... > I wonder, do kde-backports and kde-playground have same vendor? If not this > behaviour would also make it possible to have kde-playground enabled for > certain packages, without constantly having to be alert as to whether you're > updating to something alphaish. You hit the nail on the head > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.18.2-34-default x86_64 Huidige gebruiker: [EMAIL PROTECTED] 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 iD8DBQFGKNnQX5/X5X6LpDgRAscaAJ4pV2ArqjT9j27Lf862sthlrD58bACgjmee 4e2eW13aSduu9cXHVvoLGFc= =h5Gz -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Hi, On Friday, April 20, 2007 at 12:00:25, Duncan Mac-Vicar Prett wrote: > On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > > Is that not the same as we have now? > > No, now packages from other vendors are locked. Nothing should be locked > unless the user locks it. > > I am just saying the solver should not take a update from a _different_ > vendor (different from what you have right now, not != SUSE) in consideration > (unless the user explicitly do it) , that does not mean you lock it. I see and i dont like it. Because that would mean that you never get anything updated from a 3rd party repo because there the vendor will always be != Henne -- Henne Vogelsang, Teamlead Core Services http://www.opensuse.org - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
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 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
Den Friday 20 April 2007 12:00:25 skrev Duncan Mac-Vicar Prett: > On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > > Is that not the same as we have now? > > Henne > > No, now packages from other vendors are locked. Nothing should be locked > unless the user locks it. > > I am just saying the solver should not take a update from a _different_ > vendor (different from what you have right now, not != SUSE) in > consideration (unless the user explicitly do it) , that does not mean you > lock it. > > For example, right now if you install MPlayer from packman, mplayer gets > locked, because vendor != "SUSE", and wont be changed even if there is an > updated from the same packman! I like this suggestion a lot. Especially if combined with an obvious way of showing that versions from more than one vendor are available - without requiring the user to actively go to "Versions" to check. Be that an '*', a [+] or whatever. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] Locking packages ...
On Thursday 19 April 2007 11:33:42 Henne Vogelsang wrote: > Is that not the same as we have now? > Henne No, now packages from other vendors are locked. Nothing should be locked unless the user locks it. I am just saying the solver should not take a update from a _different_ vendor (different from what you have right now, not != SUSE) in consideration (unless the user explicitly do it) , that does not mean you lock it. For example, right now if you install MPlayer from packman, mplayer gets locked, because vendor != "SUSE", and wont be changed even if there is an updated from the same packman! -- Duncan Mac-Vicar Prett Novell :: SUSE R&D, Maxfeldstr. 5, 90409 Nürnberg GF: Markus Rex, HRB 16746 (AG Nürnberg) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
On Friday 20 April 2007 10:26:29 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. Not even with a degree in computer science (ok so hacking > the source(TM) should do it). This is unsatisfactory. No wait, THIS > SUCKS. Can this be improved? right click in the icon of the device and select "properties..." there you can change mount path, and other stuff. Also, even if you can change the mount options, stuff like the mount path is not really worth to change, as you always have /dev/disk/by-id and /dev/disk/by-uuid to identify a device if you want to mount it yourself (from a backup script, for example ) Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] zypper
On Friday 20 April 2007 03:38:51 Edward Dunagin wrote: > On 4/19/07, Andreas Vetter <[EMAIL PROTECTED]> wrote: > > is any rpm process running? in 10.2 this is enough for that error > > message. zypp-checkpatches? is opensuseupdater in checking state? it is strange, in case a program crash, libzypp detects if the pid of the owner of the lock is still running, and if not, it takes new ownership of the lock. Duncan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
On Thu 19 Apr 2007 06:10:05 NZST +1200, Andreas Jaeger wrote: > > In tomorrow's meeting, we'd like to discuss the following topics. Note > these are just brief remarks, if you do not understand what I mean, ask > me. Please give me your input - and if you have stuff that we should > discuss, please tell us as well. > * Smaller systems - what can be done? The smallest hard disk in the shop is 40GB. Whether a base installs puts 200MB or 700MB on that disk is not something I care about. The problem is elsewhere. For a company I needed to organise automatic production installation of Linux on a mini-small PC used for control and monitoring purposes. Resources are limited, except for oodles of blanknesss on spinning metal. Specifically, there's 128MB RAM. I'd look a fool if I went to management to say I'd like to install opensuse instead of debian, would they pay for double the memory. The problem is the installer memory footprint, not the disk space. No I can NOT enable swap!! * Home environment, 1 fast machine, 1 old box used as X11 terminal with xdmcp login to the fast one. Now the user on slow has a USB stick. Plugging that into slowbox is pointless. Plugging it into fastbox might work - but depending on who logged in first and who knows what else, *all* USB devices plugged into fastbox are either all owned by slowuser or all owned by fastuser. Can this situation be improved? Would "you only need one new computer and a few old cheap ones for your family's computing needs" be a selling point? * 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. Not even with a degree in computer science (ok so hacking the source(TM) should do it). This is unsatisfactory. No wait, THIS SUCKS. Can this be improved? * 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. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] RFC: Topics for 2007-04-19 dist meeting
On Fri, Apr 20, 2007 at 10:53:50AM +0200, Ludwig Nussel wrote: > 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 think the problem that annoys most system administrators here is not using some fancy tools but understanding (and thus having control over) what really happens. Unfortunately the documentation situation with hal and related tools is pretty bad, although this is not a specific problem of openSUSE. The problem here is similar to the Windows registry problem. The reason why people many people don't like the Windows registry system is that they are frightened by seeing a large amount of information most of which they don't understand. Robert -- Robert Schiele Dipl.-Wirtsch.informatiker mailto:[EMAIL PROTECTED] "Quidquid latine dictum sit, altum sonatur." pgp5wswSDGZPl.pgp Description: PGP signature
