Re: [opensuse-factory] Leap 15 status update 20171110
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)?
Zypper is working perfectly for me.
On a freshly made upgrade from 42.x like I tried to do? If yes, with which DE(s)? I had to remove a number of packages to be able to get past unresolvable deps, and allow more than one to be "broken". -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/11/17 13:34, mrmazda@earthlink.net wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)?
Zypper is working perfectly for me.
On a freshly made upgrade from 42.x like I tried to do?
But why are you doing it like that? its not meant to work zypper isn't built against static libs instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd /usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
If yes, with which DE(s)? I had to remove a number of packages to be able to get past unresolvable deps, and allow more than one to be "broken".
Ludwig also said that currently its for the most part only the core packages from SLE + KDE and that all the other packages that come from factory / Leap haven't been imported yet so if you use lots of openSUSE specific apps and a desktop other then Gnome / KDE / icewm you will be missing things (but you were warned) if you want to see where your packages come from look for them here "osc -A https://api.opensuse.org cat openSUSE:Leap:42.3:Update 00Meta lookup.yml" -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)?
Zypper is working perfectly for me.
On a freshly made upgrade from 42.x like I tried to do?
But why are you doing it like that?
Long before I discovered SuSE, urpmi would upgrade itself and its deps, then restart before installing everything unrelated to package management. It made sense then, and still did when I learned how to use zypper many moons ago. I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW. Why it makes sense is pretty simple, bad stuff happens, so avoid whatever avoidable bad stuff you can. For these situations, I've been counting on rpm's dependency competence. If everything package management related isn't completely installed prior to an unplanned interrupting reboot, then restarting is likely to irrecoverably fail. Where I live, power outages that outlast the UPS batteries are almost as common as extended Internet interruptions, which is to say too common.
its not meant to work zypper isn't built against static libs
Package management first is a safety feature built into urpmi that's apparently been found unnecessary by zypper devs, at least, not yet. :-(
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd /usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
So I guess my two line script could benefit from a study of ldd's 43 line output, if I were capable of digesting it. Thanks for your reply! -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)?
Zypper is working perfectly for me.
On a freshly made upgrade from 42.x like I tried to do?
But why are you doing it like that?
Long before I discovered SuSE, urpmi would upgrade itself and its deps, then restart before installing everything unrelated to package management. It made sense then, and still did when I learned how to use zypper many moons ago.
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens, so avoid whatever avoidable bad stuff you can. For these situations, I've been counting on rpm's dependency competence. If everything package management related isn't completely installed prior to an unplanned interrupting reboot, then restarting is likely to irrecoverably fail. Where I live, power outages that outlast the UPS batteries are almost as common as extended Internet interruptions, which is to say too common.
its not meant to work zypper isn't built against static libs
Package management first is a safety feature built into urpmi that's apparently been found unnecessary by zypper devs, at least, not yet. :-(
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd /usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
So I guess my two line script could benefit from a study of ldd's 43 line output, if I were capable of digesting it.
Note this may not be the complete list, you also need to check the zypper and rpm binaries as well, once the list gets long enough you might find things that are pre install requirements as well. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
/usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
So I guess my two line script could benefit from a study of ldd's 43 line output, if I were capable of digesting it.
Note this may not be the complete list, you also need to check the zypper and rpm binaries as well, once the list gets long enough you might find things that are pre install requirements as well.
"zypper up zypper" will just handle all that. Afterwards, "zypper -v dup --no-r" should upgrade everything else. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files. Having said that I don't think we are going to guarantee that the zypper in openSUSE 10.3 is capable of directly updating to 15.0 (you will hit many other non zypper issues anyway)
/usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
So I guess my two line script could benefit from a study of ldd's 43 line output, if I were capable of digesting it.
Note this may not be the complete list, you also need to check the zypper and rpm binaries as well, once the list gets long enough you might find things that are pre install requirements as well.
"zypper up zypper" will just handle all that.
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
Afterwards, "zypper -v dup --no-r" should upgrade everything else.
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2017-11-14 at 09:31 +1030, Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
Having said that I don't think we are going to guarantee that the zypper in openSUSE 10.3 is capable of directly updating to 15.0 (you will hit many other non zypper issues anyway)
Of course! :-) Maybe a metapackage or a new command line option could be designed to upgrade the installed zypper stack to the next level when needed. Maybe requiring to add the next version repo first, or maybe doing that automatically, which would be nice. But such a process would know what exactly to upgrade.
/usr/lib64/libzypp.so.1600 will give you a list of some of the other libraries that zypper requires you'd have to update all these as well.
So I guess my two line script could benefit from a study of ldd's 43 line output, if I were capable of digesting it.
Note this may not be the complete list, you also need to check the zypper and rpm binaries as well, once the list gets long enough you might find things that are pre install requirements as well.
"zypper up zypper" will just handle all that.
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
I think he means after changing the repos. The process, as published somewhere, is to first do "zypper patch", then change the repos, then run "zypper up zypper", perhaps adding rpm there, and finally do "zypper dup". - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloKKOUACgkQtTMYHG2NR9WfCQCggxw7If83TESpfxfgU8r3T/r1 1tAAoIj3TwbVFG+nG+rIQYjz6F+nbILw =3RXR -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-11-14 at 00:21 +0100, Carlos E. R. wrote:
"zypper up zypper" will just handle all that.
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
I think he means after changing the repos. The process, as published somewhere, is to first do "zypper patch", then change the repos, then run "zypper up zypper", perhaps adding rpm there, and finally do "zypper dup".
Not exactly, zypper patch must be the last call you do on your 42.x installation to ensure you get all updates for 42.x on your machine. Next step is to adjust the repos to 15.0 and then call zypper dup. Anything else is untested and my eat your kittens (or something along those lines) Cheers Dominique
On 2017-11-14 09:25, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-11-14 at 00:21 +0100, Carlos E. R. wrote:
"zypper up zypper" will just handle all that.
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
I think he means after changing the repos. The process, as published somewhere, is to first do "zypper patch", then change the repos, then run "zypper up zypper", perhaps adding rpm there, and finally do "zypper dup".
Not exactly,
zypper patch must be the last call you do on your 42.x installation to ensure you get all updates for 42.x on your machine.
Yes, exactly. That is what I wrote :-) «first do "zypper patch", then change the repos»
Next step is to adjust the repos to 15.0 and then call zypper dup.
Anything else is untested and my eat your kittens (or something along those lines)
Yes. See my other post detailing both methods and the reasonings I can think of :-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 2017-11-14 at 12:49 +0100, Carlos E. R. wrote:
On 2017-11-14 09:25, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-11-14 at 00:21 +0100, Carlos E. R. wrote:
"zypper up zypper" will just handle all that.
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
I think he means after changing the repos. The process, as published somewhere, is to first do "zypper patch", then change the repos, then run "zypper up zypper", perhaps adding rpm there, and finally do "zypper dup".
Not exactly,
zypper patch must be the last call you do on your 42.x installation to ensure you get all updates for 42.x on your machine.
Yes, exactly. That is what I wrote :-)
eh, right - so we agree :) I misread this sentence of yours:
I think he means after changing the repos. The process, as published somewhere, is to first do "zypper patch",
sequentially there was change repo / zypper patch mentioned and I did not process it clearly enough to make sense of it. My bad. Cheers, Dominique
14.11.2017 02:01, Simon Lees пишет:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
...
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
Are %pre %post etc aware of "zypper up" vs. "zypper dup"?
On 14/11/17 14:01, Andrei Borzenkov wrote:
14.11.2017 02:01, Simon Lees пишет:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
...
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
Are %pre %post etc aware of "zypper up" vs. "zypper dup"?
No, why would they be? they shouldn't need to know the difference packages behave the same when they are updated regardless all zypper up vs dup does is specify where zypper should look for new packages -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
14.11.2017 07:22, Simon Lees пишет:
On 14/11/17 14:01, Andrei Borzenkov wrote:
14.11.2017 02:01, Simon Lees пишет:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
> instead we make sure the old one is perfectly > capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
...
No it won't really because zypper up won't change repo's it will make sure you have the latest version of zypper shipped in 42.3 which is probably good practice anyway.
Are %pre %post etc aware of "zypper up" vs. "zypper dup"?
No, why would they be?
Your answer sounded like scripts do something different during "dup" than during "up". Probably I misinterpreted that.
On Tuesday, 14 November 2017 0:01 Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
Having said that I don't think we are going to guarantee that the zypper in openSUSE 10.3 is capable of directly updating to 15.0 (you will hit many other non zypper issues anyway)
In the old times (before zypper and also before zmd/rug), if the updater found there is an update for it, it updated itself first (with dependencies if necessary) and then started the updated updater which updated the rest as second pass. Maybe this is something worth considering as it might improve the chances for an upgrade to succeed. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-11-14 at 07:26 +0100, Michal Kubecek wrote:
On Tuesday, 14 November 2017 0:01 Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
instead we make sure the old one is perfectly capable of upgrading to a new version. Running "ldd
Would be interesting to know how you handle today that zypper will always work with future versions. A built-in DeLorean?
Well thats not quite what I said, but if new features have been added to zypper between 42.3 and 15.0 we will make sure that packages don't need / use them for an upgrade but really zypper doesn't have most of the upgrade magic, its all in the %pre %post etc of the spec files.
Having said that I don't think we are going to guarantee that the zypper in openSUSE 10.3 is capable of directly updating to 15.0 (you will hit many other non zypper issues anyway)
In the old times (before zypper and also before zmd/rug), if the updater found there is an update for it, it updated itself first (with dependencies if necessary) and then started the updated updater which updated the rest as second pass.
Maybe this is something worth considering as it might improve the chances for an upgrade to succeed.
Michal Kubeček
Heck pepole! Until just recently we did upgrade tests in openQA from openSUSE 12.x to Tumbleweed and no such weird requirements were needed. If we could upgrade openSUSE 12.x by skipping all of 13.x and Leap to TW, what makes you believe we won't be able to handle an upgrade from Leap 42.3 to Leap 15.0? Stop spreading rumours just because you have to jump through hoops on other platforms. For openSUSE it is rather simple: * fully patch your running system (get all the updates) * Change the repos to Leap 15.0 * zypper dup Cheers Dominique
On 2017-11-14 09:28, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-11-14 at 07:26 +0100, Michal Kubecek wrote:
On Tuesday, 14 November 2017 0:01 Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Heck pepole! Until just recently we did upgrade tests in openQA from openSUSE 12.x to Tumbleweed and no such weird requirements were needed.
If we could upgrade openSUSE 12.x by skipping all of 13.x and Leap to TW, what makes you believe we won't be able to handle an upgrade from Leap 42.3 to Leap 15.0?
Wonderful! :-) I did not know that. Maybe a line in <https://en.opensuse.org/SDB:System_upgrade> and the page somewhere on how to upgrade to TW should mention this. Mention which was the last version that openQA tested to upgrade from. Maybe I can add it myself. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On mardi, 14 novembre 2017 12.54:15 h CET Carlos E. R. wrote:
On 2017-11-14 09:28, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-11-14 at 07:26 +0100, Michal Kubecek wrote:
On Tuesday, 14 November 2017 0:01 Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote:
On 13/11/17 15:04, Felix Miata wrote: > Simon Lees composed on 2017-11-13 14:04 (UTC+1030): Heck pepole! Until just recently we did upgrade tests in openQA from openSUSE 12.x to Tumbleweed and no such weird requirements were needed.
If we could upgrade openSUSE 12.x by skipping all of 13.x and Leap to TW, what makes you believe we won't be able to handle an upgrade from Leap 42.3 to Leap 15.0?
Wonderful! :-)
I did not know that.
Maybe a line in <https://en.opensuse.org/SDB:System_upgrade> and the page somewhere on how to upgrade to TW should mention this. Mention which was the last version that openQA tested to upgrade from. Maybe I can add it myself.
Of course you know also that the page you mentionned is a wiki page and you can start contributing to make it better by editing yourself the page. And no it is not rocket science. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2017-11-14 at 13:21 +0100, Bruno Friedmann wrote:
On mardi, 14 novembre 2017 12.54:15 h CET Carlos E. R. wrote:
On 2017-11-14 09:28, Dominique Leuenberger / DimStar wrote:
On Tue, 2017-11-14 at 07:26 +0100, Michal Kubecek wrote:
On Tuesday, 14 November 2017 0:01 Simon Lees wrote:
On 13/11/17 23:48, Stefan Seyfried wrote:
On 13.11.2017 06:50, Simon Lees wrote: > On 13/11/17 15:04, Felix Miata wrote: >> Simon Lees composed on 2017-11-13 14:04 (UTC+1030): Heck pepole! Until just recently we did upgrade tests in openQA from openSUSE 12.x to Tumbleweed and no such weird requirements were needed.
If we could upgrade openSUSE 12.x by skipping all of 13.x and Leap to TW, what makes you believe we won't be able to handle an upgrade from Leap 42.3 to Leap 15.0?
Wonderful! :-)
I did not know that.
Maybe a line in <https://en.opensuse.org/SDB:System_upgrade> and the page somewhere on how to upgrade to TW should mention this. Mention which was the last version that openQA tested to upgrade from. Maybe I can add it myself.
Of course you know also that the page you mentionned is a wiki page and you can start contributing to make it better by editing yourself the page. And no it is not rocket science.
Hey, it is not the first page I contribute on ;-) However, the section where it should go, "Tested on openSUSE" and a list of versions, is blocked to contributors. I had to add it as a comment elsewhere. Also, this info is new to the writers of the upgrade documentation, because we wrote: * You must only zypper dup to the next release. Hopping over a release, e.g., going from 13.1 -> 42.1, is not supported. Not only is new to us, but will also change and we probably will not know about it. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloLOGYACgkQtTMYHG2NR9XmyQCdGjvjCazlLg99udWz2yL+kpYm xFIAn2fIbtTOOasaT+fInwJwbckSEC6c =X4HA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-11-14 at 19:39 +0100, Carlos E. R. wrote:
Of course you know also that the page you mentionned is a wiki page and you can start contributing to make it better by editing yourself the page. And no it is not rocket science.
Hey, it is not the first page I contribute on ;-)
However, the section where it should go, "Tested on openSUSE" and a list of versions, is blocked to contributors. I had to add it as a comment elsewhere.
Also, this info is new to the writers of the upgrade documentation, because we wrote:
* You must only zypper dup to the next release. Hopping over a release, e.g., going from 13.1 -> 42.1, is not supported.
The fact that we test it and act upon breakage does not mean we should advertise it and request fixes if one skips releases. Of course we try to keep things going (as explained in my other mails) - but the text as is, that skipping releases is not supported (whatever 'supported' means for openSUSE( is true. Cheers Dominique
Hello,, Am Dienstag, 14. November 2017, 19:39:34 CET schrieb Carlos E. R.:
Maybe a line in <https://en.opensuse.org/SDB:System_upgrade> and
However, the section where it should go, "Tested on openSUSE" and a list of versions, is blocked to contributors.
No, it's not blocked ;-) but the text "Tested on openSUSE" comes from a template, so it isn't directly visible in the page source. This section: {{Knowledge| *[[Portal:42.3|42.3]] *[[Portal:42.2|42.2]] *[[Portal:42.1|42.1]] *[[Portal:13.2|13.2]] *[[Portal:13.1|13.1]] *[...] is what appears as "Tested on openSUSE" You could even edit the Knowledge template to change the text "Tested on openSUSE" - but be aware that this will affect all pages that use this template. Regards, Christian Boltz -- Aeh, ja. Ich gehe nicht davon aus, dass Du Deinen Brief direkt in Postscript verfasst :-) [Thomas Hertweck in suse-linux] -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2017-11-16 at 00:32 +0100, Christian Boltz wrote:
Hello,,
Am Dienstag, 14. November 2017, 19:39:34 CET schrieb Carlos E. R.:
Maybe a line in <https://en.opensuse.org/SDB:System_upgrade> and
However, the section where it should go, "Tested on openSUSE" and a list of versions, is blocked to contributors.
No, it's not blocked ;-) but the text "Tested on openSUSE" comes from a template, so it isn't directly visible in the page source.
This section:
{{Knowledge| *[[Portal:42.3|42.3]] *[[Portal:42.2|42.2]] *[[Portal:42.1|42.1]] *[[Portal:13.2|13.2]] *[[Portal:13.1|13.1]] *[...]
is what appears as "Tested on openSUSE"
You could even edit the Knowledge template to change the text "Tested on openSUSE" - but be aware that this will affect all pages that use this template.
Mmm... Then I'll leave it alone :-) I already wrote a comment, that should be enough. - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloNhKgACgkQtTMYHG2NR9W9YACdEtq8z2vYNfAeDx/Qp6553jAx eq8An0vAQlQQ5x7VTjpSPuoMbpZZcZ8/ =nLEw -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-11-14 at 09:28 +0100, Dominique Leuenberger / DimStar wrote:
Heck pepole! Until just recently we did upgrade tests in openQA from openSUSE 12.x to Tumbleweed and no such weird requirements were needed.
Oh, forgot to mention that: but we did not stop the tests because they would no longer work (technically seen); Just due to the increased size of kernel and plasma, we ran into the issue that the original disk with openSUSE 12.1 started to 'run out of space' for the upgrade. And it was really not worth the effort to produce larger disks with 12.x on them. But for the curious ones, openQA still has the old tests for you (Until Snapshot 1101 it was tested 12.1 -> TW https://openqa.opensuse.org/tests/520546 (actually still passed here) 12.2 -> TW https://openqa.opensuse.org/tests/520547 12.3 -> TW https://openqa.opensuse.org/tests/520919 At the moment, upgrades to TW are tested from: Using the DVD (offline update) 13.1 (GNOME install) 13.2 (KDE/Plasma) 42.1 (GNOME) 42.1 (KDE/Plasma) 42.2 (GNOME) 42.2 (KDE/Plasma) Using zypper dup: 13.1 (GNOME) 13.2 (KDE) 42.1 (GNOME) 42.1 (KDE) 42.2 (GNOME) 42.2 (KDE) 42.3 (GNOME) 'Published TW snapshot to next TW snapshot to be published' The 'old' ones are kept around 'for as long as I can reasonably keep them without them hurting me'; that can be like for 12.x disk space issues or other technical issues. Needless to say: us testing this stuff does not mean people should do it - but it does sometimes help in uncovering fun packaging bugs; As you can imagine, a 13.1 -> TW update failing is considered less critical than a TW snapshot to next TW snapshot test failure Cheers, Dominique
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)? Zypper is working perfectly for me. On a freshly made upgrade from 42.x like I tried to do? But why are you doing it like that?
Long before I discovered SuSE, urpmi would upgrade itself and its deps, then restart before installing everything unrelated to package management. It made sense then, and still did when I learned how to use zypper many moons ago.
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens, Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display. Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution. Good luck with shooting yourself in leg (and I hope that you will keep us updated) Martin
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LSU.2.21.1711131511570.26359@minas-tirith.valinor> El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)? Zypper is working perfectly for me. On a freshly made upgrade from 42.x like I tried to do? But why are you doing it like that?
Long before I discovered SuSE, urpmi would upgrade itself and its deps, then restart before installing everything unrelated to package management. It made sense then, and still did when I learned how to use zypper many moons ago.
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens, Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box. There is, of course, another method using the DVD, which I personally prefer. - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloJqH8ACgkQja8UbcUWM1w2KAEAkNrRaRfqrLJzlp4kbchM71Qu 2LWDcU2x4RY/71h1eTABAJ42frvLmYrThAb3Vc1HCw6ayVkRsdcsfNl1c1lBWpb8 =gosj -----END PGP SIGNATURE-----
On 13 November 2017 at 15:13, Carlos E. R. <robin.listas@telefonica.net> wrote:
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer.
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid. If you run into problems and do not file bug reports, then you are quite frankly useless If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Il giorno Mon, 13 Nov 2017 16:04:47 +0100 Richard Brown <RBrownCCB@opensuse.org> ha scritto:
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
Let's not get personal. Disagreements, even strong ones, always occur (people can get in heated debates on indentation, their favorite DE, or favorite editor). This doesn't mean you (or anyone else, for that matter) can call out other people as "stupid". I would argue that this is even more true for Board members. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
On Tue, Nov 14, 2017 at 12:15 AM, Luca Beltrame <lbeltrame@kde.org> wrote:
Il giorno Mon, 13 Nov 2017 16:04:47 +0100 Richard Brown <RBrownCCB@opensuse.org> ha scritto:
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
Let's not get personal. Disagreements, even strong ones, always occur (people can get in heated debates on indentation, their favorite DE, or favorite editor).
This doesn't mean you (or anyone else, for that matter) can call out other people as "stupid". I would argue that this is even more true for Board members.
+1 Thank you for putting it more eloquently and more calmly than I could have. Robert -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday, 2017-11-13 at 16:04 +0100, Richard Brown wrote:
On 13 November 2017 at 15:13, Carlos E. R. <> wrote:
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer.
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
Richard, please, are you really calling me stupid in public? Do you really think that I know nothing about system upgrades? I contributed the wiki page on offline upgrades, so I should know a think or two.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
Please, Richard, I do fill bugzillas. But Martin accussed Felix of user error, not bug. I was answering to him, doubting his claims. I suggest you retract, in public. Here. :-/ - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloKHHcACgkQtTMYHG2NR9X5kACeNOoaFDTDI2dASJkl0nfYwfgl jE8AnRzJFfRhfCCb5bVen5s2yYXlD/FN =jIy7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13 November 2017 at 23:28, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday, 2017-11-13 at 16:04 +0100, Richard Brown wrote:
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
Richard, please, are you really calling me stupid in public?
Do you really think that I know nothing about system upgrades? I contributed the wiki page on offline upgrades, so I should know a think or two.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
Please, Richard, I do fill bugzillas.
But Martin accussed Felix of user error, not bug. I was answering to him, doubting his claims.
I suggest you retract, in public. Here. :-/
Carlos, I absolutely was not intending to suggest or reference you in any way. I do not think you are stupid, I appreciate every bug you file, and I unreservedly apologise. To everyone else, I also apologise for lowering the tone of the list. I let my frustrations at seeing the start of yet another unhelpful thread in -factory spill into my words. I will try to improve in the future. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2017-11-14 08:52, Richard Brown wrote:
On 13 November 2017 at 23:28, Carlos E. R. <> wrote:
On Monday, 2017-11-13 at 16:04 +0100, Richard Brown wrote:
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
Richard, please, are you really calling me stupid in public?
Do you really think that I know nothing about system upgrades? I contributed the wiki page on offline upgrades, so I should know a think or two.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
Please, Richard, I do fill bugzillas.
But Martin accussed Felix of user error, not bug. I was answering to him, doubting his claims.
I suggest you retract, in public. Here. :-/
Carlos,
I absolutely was not intending to suggest or reference you in any way. I do not think you are stupid, I appreciate every bug you file, and I unreservedly apologise.
To everyone else, I also apologise for lowering the tone of the list. I let my frustrations at seeing the start of yet another unhelpful thread in -factory spill into my words. I will try to improve in the future.
Apologies accepted. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Monday, 13 November 2017 16:04 Richard Brown wrote:
On 13 November 2017 at 15:13, Carlos E. R. <robin.listas@telefonica.net> wrote:
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer.
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
From technical point of view: 42.3 is the latest released version, 15.0 is the next. What else should the upgrade work from if not from 42.3? Sure, things may be broken at this stage but two things are more crucial than anything else: installation from scratch and upgrade from previous version. So saying "if you expect it to work you are stupid" is not an appropriate response. From social point of view, it's even worse. I can't believe my eyes I'm reading these words from a board chairman who recently kicked few people out of all lists for what he calls "toxic behaviour" (yeah, I know, "not your decision", "board unanimously", etc., whatever). I understand that you feel annoyed by some people and maybe even believe that if you can get rid of them, everything will be nice and everyone happy (those who are left, anyway). That's human. But part of being a good leader is being able to swallow that, suppress one's ego, and accept that some people keep saying things you don't like. If you can't, please do something else. I'm saying this as simply as I can: please apologize. This was way over the line. Please apologize so that I can believe you are not completely lost. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 14/11/17 02:04, Richard Brown wrote:
On 13 November 2017 at 15:13, Carlos E. R. <robin.listas@telefonica.net> wrote:
Why it makes sense is pretty simple, bad stuff happens, Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer. If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
I think that it is time for you to move on and make way for someone who has the appropriate qualities to not only be an Ordinary Member of the openSUSE Board but, more importantly, to be the Chairman, who is also SUSE owners' representative, of this Board. Not only do you first publicly declare that you consider users of the opensuse mail list to be 'scum and [villains]' but you now further reduce your claim to any professional integrity, and the integrity of the openSUSE Board itself, by insulting Carlos by calling him 'stupid' and 'useless'. Such obnoxious slurring of the general users of openSUSE by calling them 'scum and [villains]' in the opensuse mail list and now insulting one particular member of the Community by calling him 'stupid' and 'useless' is not what people expect from an Ordinary Member of the openSUSE Board let alone its Chairman. Move on. You have been Chairman of the Board for several years now and even you must realise that you deserve a well earned rest -- and we won't have to be called 'scum and [villains]' and individuals won't have to be called 'stupid' and 'useless'. At the very least, bearing in mind recent history of the Board's decisions, the Board should ban you for life from posting in any of the openSUSE mail lists. Basil Chupin B.Com.(Ec.) -- "You should never argue about politics or religion. Or anything else if you're going to come out with crap like that." Anonymous circa 2013 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Basil Chupin wrote:
On 14/11/17 02:04, Richard Brown wrote:
On 13 November 2017 at 15:13, Carlos E. R. <robin.listas@telefonica.net> wrote:
Why it makes sense is pretty simple, bad stuff happens, Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer. If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
I think that it is time for you to move on and make way for someone who has the appropriate qualities to not only be an Ordinary Member of the openSUSE Board but, more importantly, to be the Chairman, who is also SUSE owners' representative, of this Board.
Not only do you first publicly declare that you consider users of the opensuse mail list to be 'scum and [villains]' but you now further reduce your claim to any professional integrity, and the integrity of the openSUSE Board itself, by insulting Carlos by calling him 'stupid' and 'useless'.
Such obnoxious slurring of the general users of openSUSE by calling them 'scum and [villains]' in the opensuse mail list and now insulting one particular member of the Community by calling him 'stupid' and 'useless' is not what people expect from an Ordinary Member of the openSUSE Board let alone its Chairman.
Move on. You have been Chairman of the Board for several years now and even you must realise that you deserve a well earned rest -- and we won't have to be called 'scum and [villains]' and individuals won't have to be called 'stupid' and 'useless'.
At the very least, bearing in mind recent history of the Board's decisions, the Board should ban you for life from posting in any of the openSUSE mail lists.
Given Richards most inappropriate choice of words, I second that motion. I'll suggest so to the Board. -- Per Jessen, Zürich (0.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op dinsdag 14 november 2017 21:42:26 CET schreef Per Jessen:
Basil Chupin wrote:
On 14/11/17 02:04, Richard Brown wrote:
On 13 November 2017 at 15:13, Carlos E. R.
<robin.listas@telefonica.net> wrote:
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
There is, of course, another method using the DVD, which I personally prefer.
If you expect migrations to work perfectly between a released product and the earliest development versions of a brand new codebase, then you are quite frankly stupid.
If you run into problems and do not file bug reports, then you are quite frankly useless
If you don't file bug reports and instead wax lyrical about how other distributions from a bygone age managed things on the -factory mailinglist, then you are both useless and wasting everybodies time.
I think that it is time for you to move on and make way for someone who has the appropriate qualities to not only be an Ordinary Member of the openSUSE Board but, more importantly, to be the Chairman, who is also SUSE owners' representative, of this Board.
Not only do you first publicly declare that you consider users of the opensuse mail list to be 'scum and [villains]' but you now further reduce your claim to any professional integrity, and the integrity of the openSUSE Board itself, by insulting Carlos by calling him 'stupid' and 'useless'.
Such obnoxious slurring of the general users of openSUSE by calling them 'scum and [villains]' in the opensuse mail list and now insulting one particular member of the Community by calling him 'stupid' and 'useless' is not what people expect from an Ordinary Member of the openSUSE Board let alone its Chairman.
Move on. You have been Chairman of the Board for several years now and even you must realise that you deserve a well earned rest -- and we won't have to be called 'scum and [villains]' and individuals won't have to be called 'stupid' and 'useless'.
At the very least, bearing in mind recent history of the Board's decisions, the Board should ban you for life from posting in any of the openSUSE mail lists.
Given Richards most inappropriate choice of words, I second that motion. I'll suggest so to the Board. Read the previous messages in this thread, Per, and you'll find Richard's apologies, incl. acceptance by Carlos. Let's please take this for what it was now, and move on.
-- Gertjan Lettink, a.k.a. Knurpht openSUSE Board Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, Am 14.11.2017 um 21:42 schrieb Per Jessen:
Basil Chupin wrote>> At the very least, bearing in mind recent history of the Board's
decisions, the Board should ban you for life from posting in any of the openSUSE mail lists.
Given Richards most inappropriate choice of words, I second that motion. I'll suggest so to the Board.
I think it is clear from previous exchanges on this and other lists, that I am not Richards biggest fan. But people are overreating here IMVHO. Richard chose the wrong words. He apologized. Felix did not complain, maybe he is not that thin-skinned. Move on. Nothing to see here. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
Content-ID: <alpine.LSU.2.21.1711131511570.26359@minas-tirith.valinor
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote: > Very broken for me. No zypper is very bad: > https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 > Is there any possibility to fix what I have rather than > starting all over (and > arriving in the same place unless first something is > fixed)?
Zypper is working perfectly for me.
On a freshly made upgrade from 42.x like I tried to do?
But why are you doing it like that?
Long before I discovered SuSE, urpmi would upgrade itself and its deps, then restart before installing everything unrelated to package management. It made sense then, and still did when I learned how to use zypper many moons ago.
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box. And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
M
martin@pluskal.org composed on 2017-11-14 10:58 (UTC+0100):
And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
What I see is that it broke because zypper depends on something that its real world dependency chain does not require be installed/upgraded along with it, one potential brokenness my (upgrade package management system first, then everything else) process used was intended to avoid. Broken zypper has never happened here in over three years of consistently using the (package management first script) process for both ordinary updates and distribution upgrades. August 2014 is earliest version I've been able to locate without unretiring old machines: #!/bin/sh zypper -v in zypper libzypp libsolv-tools rpm openSUSE-release zypper -v in device-mapper dmraid glibc lvm2 multipath-tools mdadm systemd udev -- "Wisdom is supreme; therefore get wisdom. Whatever else you get, get wisdom." Proverbs 4:7 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Tue, 2017-11-14 at 05:25 -0500, Felix Miata wrote:
martin@pluskal.org composed on 2017-11-14 10:58 (UTC+0100):
And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
What I see is that it broke because zypper depends on something that its real world dependency chain does not require be installed/upgraded along with it, one potential brokenness my (upgrade package management system first, then everything else) process used was intended to avoid. Broken zypper has never happened here in over three years of consistently using the (package management first script) process for both ordinary updates and distribution upgrades. Well according to [1] zypper correctly states that action that you want it to perform is not possible to procees while maitnaining fulfilled dependencies. You can of course force zypper to proceed, which is what I assume happened in attempts before. I still fail to see error on side of openSUSE/zypper.
Regards Martin 1. https://bugzilla.opensuse.org/show_bug.cgi?id=1067737#c2
On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): > Felix Miata wrote:
I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point. One of the "recommended" procedures to do a distribution upgrade is to do (method (a)): zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance zypper dup The idea is to avoid problems with zypper itself during the upgrade. You say that doing that will cause zypper to fail because it will use incompatible binaries with the existing libraries from the existing system. The "zypper patch" phase of the existing system should be enough, because the last published patches to that distribution will be made precisely to avoid problems with zypper during the upgrade, and thus installing the next zypper version is not necessary (say, method (b)). I find the issue interesting. :-) I see points in both strategies. I see a problem. Assume method b. During the "zypper dup" at some point zypper, rpm, and all dependencies will be updated. All loaded libraries will remain loaded and working, so the process should continue with the "old" libraries. Ok, good. What happens if for some reason the process crashes (it does happen now and then), and the resulting "zypper stack" on restart is half upgraded, inconsistent? I suggest that zypper should be aware of this, and upgrade itself and all needed libraries as one operation somehow. I'm thinking of this or similar: ## DownloadInHeaps, Similar to DownloadInAdvance, but try to split ## the transaction into heaps, where at the end of ## each heap a consistent system state is reached. (/etc/zypp/zypp.conf). Another problem. People may try to upgrade from 42.3 to 15.0 right now, before 15.0 is finished (to try it and the upgrade process), but the "final patch" to zypper in 42.3 has not been published yet. Thus this upgrade method (b) may (or is it might?) not work, right? So people may think that method (a) is more appropriate during this phase. I think this is Felix reasoning. Just thinking! Not trying to criticize anybody ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Tue, 2017-11-14 at 12:44 +0100, Carlos E. R. wrote:
On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030):
Felix Miata wrote: > Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): > > Felix Miata wrote: I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box. And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point.
One of the "recommended" procedures to do a distribution upgrade is to do (method (a)):
zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance That is not reccomended ways to do distribution upgrade! Please stop spreading such misleading "reccomendations".
M
On mardi, 14 novembre 2017 13.20:19 h CET martin@pluskal.org wrote:
On Tue, 2017-11-14 at 12:44 +0100, Carlos E. R. wrote:
On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030): > Felix Miata wrote: > > Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): > > > Felix Miata wrote: I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box.
And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point.
One of the "recommended" procedures to do a distribution upgrade is to do (method (a)):
zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance
That is not reccomended ways to do distribution upgrade! Please stop spreading such misleading "reccomendations".
M
oh yeap, the way C was talking was useful ONE time (and if my memory digesting such thread doesn't bug) it was during 11x to 12x if you don't want to do a cold upgrade (which was the recommendend way) and this method was for adventurous, or professional who know what they are doing. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2017-11-14 at 13:20 +0100, martin@pluskal.org wrote:
On Tue, 2017-11-14 at 12:44 +0100, Carlos E. R. wrote:
On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030): > Felix Miata wrote: >> Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): >>> Felix Miata wrote: I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box. And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point.
One of the "recommended" procedures to do a distribution upgrade is to do (method (a)):
zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance That is not reccomended ways to do distribution upgrade! Please stop spreading such misleading "reccomendations".
Sorry, but AFAIR it was a documented and reccomended procedure to do it years ago. You say that this is wrong; well, this is new to me, and I'm one of the people that contributed the wiki pages on upgrading. If you know better, then it should be you who writes that documentation. The currently documented method is (short version): zypper update change repos zypper dup --download-in-advance zypper dup - -- Cheers, Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAloLPNUACgkQtTMYHG2NR9UfTACfcUH5ER2MD8MSfdHYvg93R9sc kCIAn2YdgdBE0JkIo8LHn5MJw07921Q2 =bQzK -----END PGP SIGNATURE-----
On 14/11/17 07:20 AM, martin@pluskal.org wrote:
On Tue, 2017-11-14 at 12:44 +0100, Carlos E. R. wrote:
On 2017-11-14 10:58, martin@pluskal.org wrote:
On Mon, 2017-11-13 at 15:13 +0100, Carlos E. R. wrote:
El 2017-11-13 a las 15:04 +0100, martin@pluskal.org escribió:
On Sun, 2017-11-12 at 23:34 -0500, Felix Miata wrote:
Simon Lees composed on 2017-11-13 14:04 (UTC+1030): > Felix Miata wrote: >> Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100): >>> Felix Miata wrote: I thought I was emulating this urpmi safety feature via an emulating script. This was the first time it failed me after too many years to remember of working as expected with distribution releases, Factory, and TW.
Why it makes sense is pretty simple, bad stuff happens,
Hi
It seems that bad stuff that happened here is triggered somewhere between chair and display.
Also note that for regulary maintained releases, zypper patch will update package management stack (zypper, libzypp, rpm) befor installing other updates. This does not make sense for dist upgrade where exactly stuff that happened to you would happen - but hey I guess you know better then developers of distribution.
But "zypper dup" is the reccomended method to upgrade from, say, Leap 42.3 to 15.0. It is supposed to work out of the box. And "zypper dup" works - installing zypper from Leap 15 on Leap 42.3 does not work - my understatnding from boo#1067737 and from current discussion is that breakage is not result of upgrading while using zypper but consequence of user meddling with upgrade process and trying to use binary from future release on old one.
Ah! This is an interesting point.
One of the "recommended" procedures to do a distribution upgrade is to do (method (a)):
zypper patch change repos zypper update zypper rpm zypper dup --download-in-advance That is not reccomended ways to do distribution upgrade! Please stop spreading such misleading "reccomendations".
M
I prefer a fresh install for Leap 15.0 than the upgrade. -- Cheers! Roman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2017-11-14 a las 19:47 -0500, Roman Bysh escribió:
On 14/11/17 07:20 AM, martin@pluskal.org wrote:
On Tue, 2017-11-14 at 12:44 +0100, Carlos E. R. wrote:
I prefer a fresh install for Leap 15.0 than the upgrade.
My main machine has been upgraded all the way from 5.3 and I expect to do the same to 15.0 and beyond :-) - -- Cheers Carlos E. R. (from openSUSE 42.2 x86_64 "Malachite" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAloLm1oACgkQja8UbcUWM1zHjwD+KML/ExjvY/5sYJdzSSL989WS IUMyYZ5l1x8YgAlxgBEA/29HvrlNm2b5yGG2TbspinQ7fsqUNc8NpFROGiKhdZvk =JLLu -----END PGP SIGNATURE-----
On 13/11/17 14:04, mrmazda@earthlink.net wrote:
Basil Chupin composed on 12 Nov 2017 09:01:45 (+1100):
Felix Miata wrote:
Very broken for me. No zypper is very bad: https://bugzilla.opensuse.org/show_bug.cgi?id=1067737 Is there any possibility to fix what I have rather than starting all over (and arriving in the same place unless first something is fixed)? Zypper is working perfectly for me. On a freshly made upgrade from 42.x like I tried to do? If yes, with which DE(s)? I had to remove a number of packages to be able to get past unresolvable deps, and allow more than one to be "broken".
I never do upgrades -- I always do a 'clean, fresh' installation. And the DE is (always) KDE. BC -- "You should never argue about politics or religion. Or anything else if you're going to come out with crap like that." Anonymous circa 2013 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (18)
-
Andrei Borzenkov -
Basil Chupin -
Bruno Friedmann -
Carlos E. R. -
Christian Boltz -
Dominique Leuenberger / DimStar -
Felix Miata -
Knurpht - Gertjan Lettink -
Luca Beltrame -
martin＠pluskal.org -
Michal Kubecek -
mrmazda＠earthlink.net
-
Per Jessen -
Richard Brown -
Robert Munteanu -
Roman Bysh -
Simon Lees -
Stefan Seyfried