First, let me say thanks to everyone that contributes to the list. Though I don't often write, as this has been a busy year for me, I do try and keep up with the threads. The recent ones on the problems with nvidia and upgrading to 42.3 really helped me get through my upgrade when 42.2 support was over. I just upgraded to 42.3 by means of zypper dup. After fixing the nvidia issue, my system is running well again. However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out? All my repos are now 42.3 repos. I tried this command: # zypper se -i -s * | grep System i+ | Desktop | application | | noarch | (System Packages) i+ | Desktop Containment | application | | noarch | (System Packages) i+ | KDE Plasma Desktop | application | | noarch | (System Packages) i+ | Kdenlive | application | | noarch | (System Packages) i+ | Show Desktop | application | | noarch | (System Packages) i | libwx_baseu-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_net-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_xml-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_adv-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_core-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_html-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_qa-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | openSUSE-release-dvd | package | 42.3-1.202 | x86_64 | (System Packages) I am just guessing on this one, that maybe things that are flagged as "System Packages" are items that are installed but are not registered as having come from any repository on my system. Any other ideas? -- George Box: 42.3 | KDE Plasma 5 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | KDE Plasma 5 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | KDE Plasma 5 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/02/18 15:57, George from the tribe wrote:
i | libwx_baseu-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_net-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_xml-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_adv-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_core-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_html-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_qa-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages)
You've maybe installed audacity from Packman in the past, I've deleted the Packman package that these came from, you can safely remove them. Dave P -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Saturday, February 17, 2018 8:57:02 AM EST George from the tribe wrote:
However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out? All my repos are now 42.3 repos. I tried this command:
# zypper se -i -s * | grep System i+ | Desktop | application
| | noarch | (System Packages)
i+ | Desktop Containment | application
| | noarch | (System Packages)
i+ | KDE Plasma Desktop | application
| | noarch | (System Packages)
i+ | Kdenlive | application
| | noarch | (System Packages)
i+ | Show Desktop | application
| | noarch | (System Packages)
i | libwx_baseu-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_net-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_xml-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_adv-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_core-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_html-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_qa-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | openSUSE-release-dvd | package | 42.3-1.202 | x86_64 | (System Packages)
I am just guessing on this one, that maybe things that are flagged as "System Packages" are items that are installed but are not registered as having come from any repository on my system.
Any other ideas?
Dave P has given you the answer for the specific packages you listed. From a process perspective though, I'm not sure your command gets what you're after (the last package in the list is legal, from the install media). Fwiw, after an upgrade I always find orphaned packages. It seems this mostly happens with 3rd-party repo's like Packman, but I've seen it with OSS packages, too. So after I have added back in 3rd-party repo's and updated packages owned by those vendors, I go into YaST and list the @System repo. Perusing this list looking for any in red, some of those will be OK (probably 3rd-party not in the current release but still may work) but some will be OSS or replaced 3rd-party packages. Marking the OSS packages for Delete (or searching on "Requires") will cause YaST to check dependencies; typically there are none and they can/should be deleted. Of course this process won't flush all files no longer used (I'm not sure that's even possible except with a clean install), but it does help keep the packages clean. --dg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.1802171930150.13255@Telcontar.valinor> On Saturday, 2018-02-17 at 21:57 +0800, George from the tribe wrote:
First, let me say thanks to everyone that contributes to the list. Though I don't often write, as this has been a busy year for me, I do try and keep up with the threads. The recent ones on the problems with nvidia and upgrading to 42.3 really helped me get through my upgrade when 42.2 support was over.
I just upgraded to 42.3 by means of zypper dup. After fixing the nvidia issue, my system is running well again.
However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out?
Yes - it is on some post of that thread, I think.
All my repos are now 42.3 repos. I tried this command:
# zypper se -i -s * | grep System i+ | Desktop | application | | noarch | (System Packages) i+ | Desktop Containment | application | | noarch | (System Packages) i+ | KDE Plasma Desktop | application | | noarch | (System Packages) i+ | Kdenlive | application | | noarch | (System Packages) i+ | Show Desktop | application | | noarch | (System Packages) i | libwx_baseu-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_net-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_baseu_xml-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_adv-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_core-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_html-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | libwx_gtk2u_qa-suse-nostl3 | package | 3.0.2-25.7 | x86_64 | (System Packages) i | openSUSE-release-dvd | package | 42.3-1.202 | x86_64 | (System Packages)
I am just guessing on this one, that maybe things that are flagged as "System Packages" are items that are installed but are not registered as having come from any repository on my system.
Yeeess... but... Not quite. Not everything listed as "system package" is incorrect. For instance: you have (pseudo?) package "openSUSE-release-dvd", amrked as version "42.3-1.202", so it clearly is a 42.3 package. As the DVD is no longer an active repo in your system, that package is officially orphan and listed as "system package".
Any other ideas?
Yes. Run this: rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE\ Leap\ 42\.3|openSUSE_Leap_42\.3" | less -S It will generate a list (saved also as file "rpmlist") with any package that was not created for 42.3 specifically. But I doubt you will find many, as you used "zypper dup". The online upgrade method is not as prone to that problem as the offline method is. Another method: Fire "yast2 --qt sw_single &" View: repositories tab. Select the @System repo. Secondary filter: unmaintained packages. Now slowly review the produced list. When you find a suspect, select it, and click on the "versions" tab. There you will see from what repository it came initially. Then you may decide to keep the package, delete it, or perhaps add the current version of the repo that contains it, to update that package. For instance, that list rpoduces in my machine now: libHalf12 - 16-bit floating-point encapsulation class for OpenEXR 16-bit floating-point encapsulation class for OpenEXR. and it came from packman, but it is no longer there. I click "delete", yast doesn't complain, so I go ahead and select another: libIex-2_2-12 - Exception handling library for OpenEXR Exception handling library for OpenEXR. This time YaST complain and says it wants to delete others because of dependencies. Ok, fine. That way I clean some orphaned packages (they happen all the time, not only after a system upgrade; typically with pacman). I see another: misfortune. But this one I keep, because I installed it manually without adding the repo. I want it. I can see in the "Installation Summary" what it is going to delete, and in this case, also to update automatically: libHalf23, libIex-2_2-23... Then I also click on every repo to see the "unmaintained packages" that might be. Sometimes there are some more. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqId7kACgkQtTMYHG2NR9U8pACaAzvubNcyrpnyjWzcGQv8Iei2 RZgAnjRLbE9xw04QA4fcRhaUl8iFdoK1 =xXZZ -----END PGP SIGNATURE-----
Hmm ... So I tried looking for packages no longer available that are on my system. One I just found worries me: ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update (and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR) but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
That's the only one I see in search: https://software.opensuse.org/package/ucode-intel
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
Huh? I can - but not from every field, unless I use the ncurses version: ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs This package contains the microcode update blobs for Intel x86 and x86-64 CPUs.
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-? -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On Sat, 17 Feb 2018 21:50:38 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
That's the only one I see in search:
https://software.opensuse.org/package/ucode-intel
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
Huh?
I can - but not from every field, unless I use the ncurses version:
Qt version
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs
This package contains the microcode update blobs for Intel x86 and x86-64 CPUs.
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
Well, again, obviously. But why? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed.... Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 17 Feb 2018 22:09:43 +0100 Peter Suetterlin <pit@astro.su.se> wrote:
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed....
I use YaST Online Update. That's supposed to keep my system sane. It apparently hasn't, though I'd like to have that confirmed.
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
There's no way I would run a dup for this (or should have to even contemplate such an idea). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-17 at 23:01 -0000, Dave Howorth wrote:
On Sat, 17 Feb 2018 22:09:43 +0100 Peter Suetterlin <> wrote:
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed....
I use YaST Online Update. That's supposed to keep my system sane. It apparently hasn't, though I'd like to have that confirmed.
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
There's no way I would run a dup for this (or should have to even contemplate such an idea).
YaST online is the correct thing for Leap, but it does not handle downgrades. Maybe there is no way to handle it except by reading mail and downgrading the package manually. IMO, you have to report this in Bugzilla. You were hit by the bug, we were not. We can not report it. You can, you have the logs. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqI49cACgkQtTMYHG2NR9WXIwCeID1yCn38lm+ky5aPSy3dbFLH 9swAn2GW6OPpib6jKuzQYzyXMPn402Rw =J3Ll -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/02/18 13:24, Carlos E. R. wrote:
On Saturday, 2018-02-17 at 23:01 -0000, Dave Howorth wrote:
On Sat, 17 Feb 2018 22:09:43 +0100 Peter Suetterlin <> wrote:
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed....
I use YaST Online Update. That's supposed to keep my system sane. It apparently hasn't, though I'd like to have that confirmed.
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
There's no way I would run a dup for this (or should have to even contemplate such an idea).
YaST online is the correct thing for Leap, but it does not handle downgrades.
Maybe there is no way to handle it except by reading mail and downgrading the package manually.
IMO, you have to report this in Bugzilla. You were hit by the bug, we were not. We can not report it. You can, you have the logs.
Oh, look, go easy with bug reports. If one looks in Yast in the Change Log tab you will clearly see which is the latest version of that ucode file. Heavens above, surely 20180108 is younger than 21070707, no? BC -- Always be nice to people on your way up -- you'll see the same people on your way down. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-18 03:55, Basil Chupin wrote:
On 18/02/18 13:24, Carlos E. R. wrote:
...
IMO, you have to report this in Bugzilla. You were hit by the bug, we were not. We can not report it. You can, you have the logs.
Oh, look, go easy with bug reports. If one looks in Yast in the Change Log tab you will clearly see which is the latest version of that ucode file. Heavens above, surely 20180108 is younger than 21070707, no?
But it was removed, it has problems. The only update available now is "21070707": See: +++.-.-.-.-.-.-.-. From Marcus Meissner https://lists.opensuse.org/opensuse-factory/2018-01/msg00578.html and two followups later Yes. I just submitted a revert. ... n Leap I only removed it from the update servers. .-.-.-.-.-.-.-.++- And today Marcus has confirmed: +++.-.-.-.-.-.-.-. Thanks for generating a 20 email thread and 0 bugzilla entries... I just submitted a revert update for ucode-intel, so zypper -f is not needed. My original hope that Intel would be quick to release new firmware, but that has not manifested. .-.-.-.-.-.-.-.++- See? Bugzilla Bugzilla Bugzilla... :-) Well, not now, yesterday. Now it is not needed. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Dave Howorth wrote:
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
There's no way I would run a dup for this (or should have to even contemplate such an idea).
I think a 'zypper in -f ucode-intel' should get you the proper one. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
18.02.2018 00:09, Peter Suetterlin пишет:
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed....
Well, Ubuntu did it correctly intel-microcode/xenial-updates,xenial-security 3.20180108.0+really20170707ubuntu16.04.1 amd64 So no reverting back to older version.
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
Could be topic for discussion. Probably "remove from update repository" is not an option here. Although I'm currently in the same position with BIOS update - I was too fast and installed update published in January which is now silently removed. I actually verified that I do have microcode version that was removed by Intel: [ 2.115340] microcode: sig=0x306d4, pf=0x40, revision=0x28 bor@bor-Latitude-E5450:~/Загрузки$ ./usr/sbin/iucode_tool -td -Sl microcode.dat-20171117 ./usr/sbin/iucode_tool: system has processor(s) with signature 0x000306d4 selected microcodes: 001: sig 0x000306d4, pf mask 0xc0, 2017-01-27, rev 0x0025, size 17408 bor@bor-Latitude-E5450:~/Загрузки$ ./usr/sbin/iucode_tool -td -Sl microcode.dat-20180108 ./usr/sbin/iucode_tool: system has processor(s) with signature 0x000306d4 selected microcodes: 001: sig 0x000306d4, pf mask 0xc0, 2017-11-17, rev 0x0028, size 18432 Of course there is no real information what exactly is broken, although there are rumors about potential data loss. I can only be happy that this microcode actually boots (how you revert microcode that comes with BIOS? And Linux kernel won't downgrade it, I do not even see any option) Waiting for Dell support to answer whether I should (and can) downgrade BIOS ... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrei Borzenkov wrote:
18.02.2018 00:09, Peter Suetterlin пишет:
Dave Howorth wrote:
Well, obviously I can't get it since it is now not available, which is the whole point of my message?
But if you have it installed, and only use 'zypper up', the newer one won't get removed....
Well, Ubuntu did it correctly
intel-microcode/xenial-updates,xenial-security 3.20180108.0+really20170707ubuntu16.04.1 amd64
Well, lets say they *could* do it correctly because they have a different naming scheme, is it?
So no reverting back to older version.
Only on paper. In reality it is the old version.
Not sure how this is handled in Leap, in TW the 'dup' makes sure also downgrades take place...
Could be topic for discussion. Probably "remove from update repository" is not an option here.
TBH I do trust Marcus and the security team in that respect. If there had been a major problem with this, I think they would have taken other steps to make sure the version gets downgraded for those that got the update. Of course I might be wrong there.
Although I'm currently in the same position with BIOS update - I was too fast and installed update published in January which is now silently removed. I actually verified that I do have microcode version that was removed by Intel:
[ 2.115340] microcode: sig=0x306d4, pf=0x40, revision=0x28
...and most BIOS won't let you downgrade, is it? At least there we are in a better position with the separate MC updates...
Waiting for Dell support to answer whether I should (and can) downgrade BIOS ...
Good luck! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
Wasn't that the first 'fix' from intel that was pulled back? I had just upgraded an older 42.2 to 42.3, that one does also have the 20170707 version.
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
See above, at least on TW it had been revoked, and ISTR for Leap, too. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Peter Suetterlin wrote:
Carlos E. R. wrote:
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
Wasn't that the first 'fix' from intel that was pulled back?
I had just upgraded an older 42.2 to 42.3, that one does also have the 20170707 version.
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
See above, at least on TW it had been revoked, and ISTR for Leap, too.
From Marcus Meissner https://lists.opensuse.org/opensuse-factory/2018-01/msg00578.html and two followups later
Yes. I just submitted a revert. ... n Leap I only removed it from the update servers. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-17 at 22:14 +0100, Peter Suetterlin wrote:
Peter Suetterlin wrote:
Carlos E. R. wrote:
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
Wasn't that the first 'fix' from intel that was pulled back?
I had just upgraded an older 42.2 to 42.3, that one does also have the 20170707 version.
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
See above, at least on TW it had been revoked, and ISTR for Leap, too.
From Marcus Meissner https://lists.opensuse.org/opensuse-factory/2018-01/msg00578.html and two followups later
Yes. I just submitted a revert. ... n Leap I only removed it from the update servers.
So in Leap some people may have the bad package installed. Is that a bug? - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqIn68ACgkQtTMYHG2NR9WzigCfb5Cs3wnD3AYyNt1wwvZop8FY t/4AnjvKZmR3Or1ZAWSM17y65He1ES4p =QiIJ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 17 Feb 2018 22:06:33 +0100 Peter Suetterlin <pit@astro.su.se> wrote:
Carlos E. R. wrote:
On 2018-02-17 21:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
I don't see where you could get that one.
Wasn't that the first 'fix' from intel that was pulled back?
Could be; I don't know.
I had just upgraded an older 42.2 to 42.3, that one does also have the 20170707 version.
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
Well, yes, but why won't the 'regular' Qt version let me do it?
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
See above, at least on TW it had been revoked, and ISTR for Leap, too.
Well, yes, maybe, but why is it still on my machine then? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-17 at 21:34 -0000, Dave Howorth wrote:
Carlos E. R. wrote:
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
Well, yes, but why won't the 'regular' Qt version let me do it?
But the sample text I pasted was the Qt version.
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Maybe you have a version that was removed :-?
See above, at least on TW it had been revoked, and ISTR for Leap, too.
Well, yes, maybe, but why is it still on my machine then?
That's what I think may be a bug. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqIq9sACgkQtTMYHG2NR9W2DACfQVs6IIPxFSjxYjfBe2m9mFCI +foAn1Cgs26bCjltX7Xwhc40HxYsmCgS =dQcA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 17 Feb 2018 23:25:31 +0100 (CET) "Carlos E. R." <robin.listas@telefonica.net> wrote:
On Saturday, 2018-02-17 at 21:34 -0000, Dave Howorth wrote:
Carlos E. R. wrote:
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
Well, yes, but why won't the 'regular' Qt version let me do it?
But the sample text I pasted was the Qt version.
It's specifically the version info that I had to type into my message that I am concerned about.
Well, yes, maybe, but why is it still on my machine then?
That's what I think may be a bug.
Well, hopefully somebody who actually knows one way or the other will chime in, or perhaps anybody else who has the same version as me? (why doesn't everybody have the same version as me?) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday, 2018-02-17 at 22:59 -0000, Dave Howorth wrote:
On Sat, 17 Feb 2018 23:25:31 +0100 (CET) "Carlos E. R." <> wrote:
On Saturday, 2018-02-17 at 21:34 -0000, Dave Howorth wrote:
Carlos E. R. wrote:
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
:) run the ncurses version in a terminal :)
Well, yes, but why won't the 'regular' Qt version let me do it?
But the sample text I pasted was the Qt version.
It's specifically the version info that I had to type into my message that I am concerned about.
Ah, ok, that part copypaste does not work.
Well, yes, maybe, but why is it still on my machine then?
That's what I think may be a bug.
Well, hopefully somebody who actually knows one way or the other will chime in, or perhaps anybody else who has the same version as me? (why doesn't everybody have the same version as me?)
Maybe because we did not update that day. Maybe those who did haven't noticed anything wrong, yet. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqI4wIACgkQtTMYHG2NR9WmVgCePWcqa1AknS2F6q+5iFSuznSc ZwIAoJYdgYhvl2cvLHvkudNjPUH3gSsP =8EuB -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
Well, hopefully somebody who actually knows one way or the other will chime in, or perhaps anybody else who has the same version as me? (why doesn't everybody have the same version as me?)
Maybe because we did not update that day.
Yes, of course only those that ran an update during the time it had been on the update server have the newer version.
Maybe those who did haven't noticed anything wrong, yet.
I had followed that only losely (I had that version on my computer for a while, too, and did not notice issues), but I think there were problems with various (older?) CPUs after that update. A first guess could be that if you don't notice a problem, it's not an issue for you. If you are concerned, the first thing to check is looking at 'journalctl -b' and look for an 'early microcode update' in the first few lines. Only if it's there the MC for your CPU had actually been changed in that release. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-18 10:12, Peter Suetterlin wrote:
Carlos E. R. wrote:
If you are concerned, the first thing to check is looking at 'journalctl -b' and look for an 'early microcode update' in the first few lines. Only if it's there the MC for your CPU had actually been changed in that release.
I am curious, so I checked. The string seems to be a bit different, though: "microcode updated early". And seems to be applied on every boot: zgrep -i "microcode updated early to" /var/log/messages*z | cut --fields="2-" -d: ... <0.6> 2018-02-05 02:23:11 Telcontar kernel - - - [ 0.000000] microcode: CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 02:23:11 Telcontar kernel - - - [ 0.008000] microcode: CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.4> 2018-02-05 02:23:11 Telcontar kernel - - - [ 0.076160] smpboot: #2<6>[ 0.008000] microcode: CPU2 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 02:23:11 Telcontar kernel - - - [ 0.008000] microcode: CPU3 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 05:22:36 Telcontar kernel - - - [ 0.000000] microcode: CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 05:22:36 Telcontar kernel - - - [ 0.008000] microcode: CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.4> 2018-02-05 05:22:36 Telcontar kernel - - - [ 0.076160] smpboot: #2<6>[ 0.008000] microcode: CPU2 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 05:22:36 Telcontar kernel - - - [ 0.008000] microcode: CPU3 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 13:26:18 Telcontar kernel - - - [ 0.000000] microcode: CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 13:26:18 Telcontar kernel - - - [ 0.008000] microcode: CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.4> 2018-02-05 13:26:18 Telcontar kernel - - - [ 0.080161] smpboot: #2<6>[ 0.008000] microcode: CPU2 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-05 13:26:18 Telcontar kernel - - - [ 0.008000] microcode: CPU3 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-10 20:20:14 Telcontar kernel - - - [ 0.000000] microcode: CPU0 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-10 20:20:14 Telcontar kernel - - - [ 0.008000] microcode: CPU1 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.4> 2018-02-10 20:20:14 Telcontar kernel - - - [ 0.088175] smpboot: #2<6>[ 0.008000] microcode: CPU2 microcode updated early to revision 0xa0b, date = 2010-09-28 <0.6> 2018-02-10 20:20:14 Telcontar kernel - - - [ 0.008000] microcode: CPU3 microcode updated early to revision 0xa0b, date = 2010-09-28 -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
Carlos E. R. wrote:
On 2018-02-18 10:12, Peter Suetterlin wrote:
Carlos E. R. wrote:
If you are concerned, the first thing to check is looking at 'journalctl -b' and look for an 'early microcode update' in the first few lines. Only if it's there the MC for your CPU had actually been changed in that release.
I am curious, so I checked. The string seems to be a bit different, though: "microcode updated early". And seems to be applied on every boot:
Ah, my bad. My computer doesn't do them, so I had to type from memory (which of course served me wrong :o ) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, 17 Feb 2018 22:59:07 +0000 Dave Howorth <dave@howorth.org.uk> wrote:
Well, yes, maybe, but why is it still on my machine then?
That's what I think may be a bug.
Well, hopefully somebody who actually knows one way or the other will chime in, or perhaps anybody else who has the same version as me? (why doesn't everybody have the same version as me?)
Well, I can be your "anybody else who has the same version". I've also got 20180108-16.1 installed on an i5-7500 but on no other machines. Your message had me check. And I also use the automated yast2 online_update module so that's where it came from. It was installed on "Thu 11 Jan 2018 08:04:52 PM CST" In yast2 gui itself the 20170707-10.1 version is shown as an available "update" but it doesn't / didn't get automatically installed obviously. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/02/18 07:38, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
I have same when I look in Yast2: I have installed (even though I don't have Intel anywhere close to me -- I am an AMD man :-)) the 20180108-16.1 version and have -- now here comes the possible confusion -- *AVAILABLE* v20170707-10.1 (if you look in the Version list you will find a third version available). When I say that there is a possible reason for confusion is that the "(Available)" entry against a file in Yast is usually indicative that there is a NEWER, later, version available for installation -- but, in fact, the word "Available" simply means that there is another version available which need not be the latest copy.
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
Use Spectacle.
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
You have the correct version installed. BC -- Always be nice to people on your way up -- you'll see the same people on your way down. ecal -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2018 04:38 AM, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
Ok, this makes me curious - how did you go about searching for packages installed on your system that are no longer available in the repos? Did you just check one by one? -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-02-18 at 16:14 +0800, George from the tribe wrote:
Ok, this makes me curious - how did you go about searching for packages installed on your system that are no longer available in the repos? Did you just check one by one?
They show in red. I posted the full procedure yesterday, I'll repost: - ---------------------------- On Saturday, 2018-02-17 at 21:57 +0800, George from the tribe wrote: ... ... trimming ... ... Another method: Fire "yast2 --qt sw_single &" View: repositories tab. Select the @System repo. Secondary filter: unmaintained packages. Now slowly review the produced list. When you find a suspect, select it, and click on the "versions" tab. There you will see from what repository it came initially. Then you may decide to keep the package, delete it, or perhaps add the current version of the repo that contains it, to update that package. For instance, that list rpoduces in my machine now: libHalf12 - 16-bit floating-point encapsulation class for OpenEXR 16-bit floating-point encapsulation class for OpenEXR. and it came from packman, but it is no longer there. I click "delete", yast doesn't complain, so I go ahead and select another: libIex-2_2-12 - Exception handling library for OpenEXR Exception handling library for OpenEXR. This time YaST complain and says it wants to delete others because of dependencies. Ok, fine. That way I clean some orphaned packages (they happen all the time, not only after a system upgrade; typically with pacman). I see another: misfortune. But this one I keep, because I installed it manually without adding the repo. I want it. I can see in the "Installation Summary" what it is going to delete, and in this case, also to update automatically: libHalf23, libIex-2_2-23... Then I also click on every repo to see the "unmaintained packages" that might be. Sometimes there are some more. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) - ------------ End PGP Signed Message Verified 2018-02-18 12:57:10 ----------- - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqJarsACgkQtTMYHG2NR9VjEwCfYtP7yxDnrP/veC9sJ756Mq93 jt8An2UtdDe4bpYyQ2EO0/3PCP/Hxihv =/tRA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2018 07:59 PM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Sunday, 2018-02-18 at 16:14 +0800, George from the tribe wrote:
Ok, this makes me curious - how did you go about searching for packages installed on your system that are no longer available in the repos? Did you just check one by one?
They show in red.
I posted the full procedure yesterday, I'll repost:
- ----------------------------
On Saturday, 2018-02-17 at 21:57 +0800, George from the tribe wrote:
... ... trimming ... ...
Another method:
Fire "yast2 --qt sw_single &"
View: repositories tab.
Select the @System repo.
Secondary filter: unmaintained packages.
Yes, that is good, and I followed that. I guess what I mean is, after seeing that list, how did he determine that the package in question is not offered in any repositories, as in, not even other repositories that he is not using? Did he have to check each individual package on the list in the procedure you mentioned against the opensuse package search from the opensuse website? Seems like that would take a long time. Of course, sometimes that is necessary. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2018-02-19 02:48, George from the tribe wrote:
On 02/18/2018 07:59 PM, Carlos E. R. wrote:
On Sunday, 2018-02-18 at 16:14 +0800, George from the tribe wrote:
Ok, this makes me curious - how did you go about searching for packages installed on your system that are no longer available in the repos? Did you just check one by one?
They show in red.
I posted the full procedure yesterday, I'll repost:
- ----------------------------
On Saturday, 2018-02-17 at 21:57 +0800, George from the tribe wrote:
... ... trimming ... ...
Another method:
Fire "yast2 --qt sw_single &"
View: repositories tab.
Select the @System repo.
Secondary filter: unmaintained packages.
Yes, that is good, and I followed that. I guess what I mean is, after seeing that list, how did he determine that the package in question is not offered in any repositories, as in, not even other repositories that he is not using? Did he have to check each individual package on the list in the procedure you mentioned against the opensuse package search from the opensuse website? Seems like that would take a long time. Of course, sometimes that is necessary.
No, that is not possible. The check is only against the locally configured and enabled repositories. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 02/17/2018 02:38 PM, Dave Howorth wrote:
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
Old Qt3 version will :) Looks like I'm still good: sudo dmesg | grep microcode [ 0.000000] microcode: CPU0 microcode updated early to revision 0x29, date = 2013-06-12 [ 0.078888] microcode: CPU2 microcode updated early to revision 0x29, date = 2013-06-12 [ 3.774680] microcode: CPU0 sig=0x206a7, pf=0x10, revision=0x29 [ 3.774707] microcode: CPU1 sig=0x206a7, pf=0x10, revision=0x29 [ 3.774725] microcode: CPU2 sig=0x206a7, pf=0x10, revision=0x29 [ 3.774748] microcode: CPU3 sig=0x206a7, pf=0x10, revision=0x29 [ 3.774881] microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba Old, but good. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi, Thanks for generating a 20 email thread and 0 bugzilla entries... I just submitted a revert update for ucode-intel, so zypper -f is not needed. My original hope that Intel would be quick to release new firmware, but that has not manifested. Ciao, Marcus On Sat, Feb 17, 2018 at 08:38:47PM +0000, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real <meissner@suse.de> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 18 Feb 2018 11:23:13 +0100 Marcus Meissner <meissner@suse.de> wrote:
Hi,
Thanks for generating a 20 email thread and 0 bugzilla entries...
That sounds a bit snarky, but maybe I'm misunderstanding. I will generate a bugzilla if and when I understand whether there is a bug and if so, what it is. At the moment, I see lots of different opinions.
I just submitted a revert update for ucode-intel, so zypper -f is not needed.
My original hope that Intel would be quick to release new firmware, but that has not manifested.
From that, I infer that there is indeed a bug and that the ucode-intel I have is wrong and that you have now done something so it will 'update' to the correct, older, version next time I run Online Update. Is that correct? In which case, no bugzilla is needed? Having said that, I just tried Online Update and there are no updates available. But I presume that is simply time delay whilst servers update. In the meantime and in advance, thank you for fixing the problem :) Cheers, Dave
Ciao, Marcus On Sat, Feb 17, 2018 at 08:38:47PM +0000, Dave Howorth wrote:
Hmm ...
So I tried looking for packages no longer available that are on my system. One I just found worries me:
ucode-intel - Microcode Updates for Intel x86/x86-64 CPUs I have 20180108-16.1-x86_64 from vendor openSUSE
but what I see is the latest available is 20170707-10.1-x86_64 from openSUSE-Leap-42.3-update
(and yet again, I'm severely annoyed that YaST won't let me cut and paste text!!!! GRR)
but what I'm worried about is what is the correct version to have? And why hasn't YaST given me the correct version, and/or indicated that I do have the correct version?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Feb 18, 2018 at 12:09:10PM +0000, Dave Howorth wrote:
On Sun, 18 Feb 2018 11:23:13 +0100 Marcus Meissner <meissner@suse.de> wrote:
Hi,
Thanks for generating a 20 email thread and 0 bugzilla entries...
That sounds a bit snarky, but maybe I'm misunderstanding. I will generate a bugzilla if and when I understand whether there is a bug and if so, what it is. At the moment, I see lots of different opinions.
Sorry, I was a bit harsh here. I should have triggered this myself a week ago, same as I did for SLES.
I just submitted a revert update for ucode-intel, so zypper -f is not needed.
My original hope that Intel would be quick to release new firmware, but that has not manifested.
From that, I infer that there is indeed a bug and that the ucode-intel I have is wrong and that you have now done something so it will 'update' to the correct, older, version next time I run Online Update. Is that correct? In which case, no bugzilla is needed?
Having said that, I just tried Online Update and there are no updates available. But I presume that is simply time delay whilst servers update.
In the meantime and in advance, thank you for fixing the problem :)
The update is queued, we will likely release it Monday. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Marcus Meissner wrote:
Hi,
Thanks for generating a 20 email thread and 0 bugzilla entries...
Well, no one in this discussion was sure if this is a bug, an oversight, or intended. Even more as no one seems to know what the problem of that version had been, and why it was taken back... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, Feb 18, 2018 at 01:28:32PM +0100, Peter Suetterlin wrote:
Marcus Meissner wrote:
Hi,
Thanks for generating a 20 email thread and 0 bugzilla entries...
Well, no one in this discussion was sure if this is a bug, an oversight, or intended. Even more as no one seems to know what the problem of that version had been, and why it was taken back...
It was an oversight by me as responsible coordinator and my hope that it would not affect anyone. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 18 Feb 2018 11:23:13 +0100 Marcus Meissner <meissner@suse.de> wrote:
I just submitted a revert update for ucode-intel, so zypper -f is not needed.
My original hope that Intel would be quick to release new firmware, but that has not manifested.
I've had 20180108-16.1 ucode-intel on kaby lake under 42.3 since 11-Jan and nothing has seemed out of place. Dell today (18-Feb) released a new BIOS for my T3620 for "Update to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue." I haven't installed this yet (the package self-installs itself through the existing BIOS boot menu so the OS is not relevant to the install). Sorry if this is a dumb question but: am I safe to assume that your rollback from 20180108-16.1 ucode-intel to 20170707-10.1 tomorrow will have no effect on this new Dell burn under 42.3? http://www.dell.com/support/Home/us/en/04/Drivers/DriversDetails?driverId=J7... Thanks. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sun, 18 Feb 2018 23:34:07 -0600 listreader <suselist@cableone.net> wrote:
I've had 20180108-16.1 ucode-intel on kaby lake under 42.3 since 11-Jan and nothing has seemed out of place. Dell today (18-Feb) released a new BIOS for my T3620 for "Update to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue." I haven't installed this yet (the package self-installs itself through the existing BIOS boot menu so the OS is not relevant to the install).
Sorry if this is a dumb question but: am I safe to assume that your rollback from 20180108-16.1 ucode-intel to 20170707-10.1 tomorrow will have no effect on this new Dell burn under 42.3?
I burned the new Dell BIOS which gives me microcode: sig=0x906e9, pf=0x2, revision=0x84 and the 'early microcode' load doesn't happen now under 42.3 so my question is moot, I suppose. 0x84 is so new that it's not even in the Intel 12-Feb "Microcode Revision Guidance" pdf. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Feb 19, 2018 at 01:18:59AM -0600, listreader wrote:
On Sun, 18 Feb 2018 23:34:07 -0600 listreader <suselist@cableone.net> wrote:
I've had 20180108-16.1 ucode-intel on kaby lake under 42.3 since 11-Jan and nothing has seemed out of place. Dell today (18-Feb) released a new BIOS for my T3620 for "Update to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue." I haven't installed this yet (the package self-installs itself through the existing BIOS boot menu so the OS is not relevant to the install).
Sorry if this is a dumb question but: am I safe to assume that your rollback from 20180108-16.1 ucode-intel to 20170707-10.1 tomorrow will have no effect on this new Dell burn under 42.3?
I burned the new Dell BIOS which gives me microcode:
sig=0x906e9, pf=0x2, revision=0x84
and the 'early microcode' load doesn't happen now under 42.3 so my question is moot, I suppose. 0x84 is so new that it's not even in the Intel 12-Feb "Microcode Revision Guidance" pdf.
The rollback and generally the ucode-intel package microcode loading does not override what the BIOS has already done. ucode-intel will also only upgrade the version and not downgrade if the BIOS has a newer ucode version embedded. Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 19 Feb 2018 08:21:18 +0100 Marcus Meissner <meissner@suse.de> wrote:
Sorry if this is a dumb question but: am I safe to assume that your rollback from 20180108-16.1 ucode-intel to 20170707-10.1 tomorrow will have no effect on this new Dell burn under 42.3?
I burned the new Dell BIOS which gives me microcode:
sig=0x906e9, pf=0x2, revision=0x84
The rollback and generally the ucode-intel package microcode loading does not override what the BIOS has already done.
ucode-intel will also only upgrade the version and not downgrade if the BIOS has a newer ucode version embedded.
Thank you for the confirm. Ralph -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/18/2018 02:43 AM, Carlos E. R. wrote:
Any other ideas?
Yes. Run this:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE\ Leap\ 42\.3|openSUSE_Leap_42\.3" | less -S
It will generate a list (saved also as file "rpmlist") with any package that was not created for 42.3 specifically.
But I doubt you will find many, as you used "zypper dup". The online upgrade method is not as prone to that problem as the offline method is.
Another method:
Fire "yast2 --qt sw_single &"
View: repositories tab.
Select the @System repo.
Secondary filter: unmaintained packages.
Now slowly review the produced list. When you find a suspect, select it, and click on the "versions" tab. There you will see from what repository it came initially.
Then you may decide to keep the package, delete it, or perhaps add the current version of the repo that contains it, to update that package.
For instance, that list rpoduces in my machine now:
libHalf12 - 16-bit floating-point encapsulation class for OpenEXR
16-bit floating-point encapsulation class for OpenEXR.
and it came from packman, but it is no longer there. I click "delete", yast doesn't complain, so I go ahead and select another:
libIex-2_2-12 - Exception handling library for OpenEXR
Exception handling library for OpenEXR.
This time YaST complain and says it wants to delete others because of dependencies. Ok, fine. That way I clean some orphaned packages (they happen all the time, not only after a system upgrade; typically with pacman).
I see another: misfortune. But this one I keep, because I installed it manually without adding the repo. I want it.
I can see in the "Installation Summary" what it is going to delete, and in this case, also to update automatically: libHalf23, libIex-2_2-23...
Then I also click on every repo to see the "unmaintained packages" that might be. Sometimes there are some more.
Ok, great, that is really helpful. I actually did both, and compared the rpm query with what I was seeing in yast. It seems that there are several packages in the rpm query that are listed as having been installed under packman when I had the packman 42.2 repository on there, but they are not showing up as unmaintained packages in yast. For example, the package libtxc_dxtn-1.0.1-4.2 shows up in the rpm query, but it is not listed as unmaintained in yast. I went into the packman repo for 42.3, and this package is not available there. Why would that be? An earlier version is available for 42.3, libtxc_dxtn-1.0.1-4.1. But then there are others, like libbctoolbox0-0.2.0-4.1.x86_64.rpm, that the same version is available in both the 42.2 packman repo and the 42.3 packman repo. So, for these packages, what should I do? Should I just try deleting them and see what happens? I expect they were installed as dependencies with the 42.2 multimedia installation guide, which I did over a year ago. Here is the list of my extra packages: Sat Nov 26 2016 Sat Oct 29 2016 libbctoolbox0 0.2.0-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Multimedia / openSUSE_Leap_42.2 (none) Sat Dec 17 2016 Thu Dec 15 2016 libtxc_dxtn 1.0.1-4.2 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Mon Apr 24 2017 Tue Mar 28 2017 libmovit6 1.5.0-2.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Fri Jul 21 2017 Mon Jul 17 2017 liba52-0 0.7.5+svn613-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 13 2017 libmad0 0.15.1b-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 libmp3lame0 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 06 2017 libtwolame0 0.3.13-5.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 lame 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Sun Dec 10 2017 Sat Dec 02 2017 movit-data 1.5.3-2.2 noarch http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-devel 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-source 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default-devel 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-syms 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Sun Jan 28 2018 Sat Dec 02 2017 libshine3 3.1.0-5.2 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/02/18 10:13, George from the tribe wrote:
Ok, great, that is really helpful. I actually did both, and compared the rpm query with what I was seeing in yast. It seems that there are several packages in the rpm query that are listed as having been installed under packman when I had the packman 42.2 repository on there, but they are not showing up as unmaintained packages in yast.
For example, the package libtxc_dxtn-1.0.1-4.2 shows up in the rpm query, but it is not listed as unmaintained in yast. I went into the packman repo for 42.3, and this package is not available there. Why would that be? An earlier version is available for 42.3, libtxc_dxtn-1.0.1-4.1.
But then there are others, like libbctoolbox0-0.2.0-4.1.x86_64.rpm, that the same version is available in both the 42.2 packman repo and the 42.3 packman repo.
So, for these packages, what should I do? Should I just try deleting them and see what happens? I expect they were installed as dependencies with the 42.2 multimedia installation guide, which I did over a year ago.
Here is the list of my extra packages:
Sat Nov 26 2016 Sat Oct 29 2016 libbctoolbox0 0.2.0-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Multimedia / openSUSE_Leap_42.2 (none) Sat Dec 17 2016 Thu Dec 15 2016 libtxc_dxtn 1.0.1-4.2 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Mon Apr 24 2017 Tue Mar 28 2017 libmovit6 1.5.0-2.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Fri Jul 21 2017 Mon Jul 17 2017 liba52-0 0.7.5+svn613-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 13 2017 libmad0 0.15.1b-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 libmp3lame0 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 06 2017 libtwolame0 0.3.13-5.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 lame 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Sun Dec 10 2017 Sat Dec 02 2017 movit-data 1.5.3-2.2 noarch http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none)
There is a ongoing drive to move packages that no longer need to be in Packman to openSUSE proper. This applies to the above packages. Accept the openSUSE versions of these packages and you won't lose any functionality. Mp3's patents expired last year and the relative libraries made it into 42.3. There will also be mpeg2 video support out of the box in Leap:15.0 as the last patent expired on the 14th of this month.
Wed Jan 17 2018 Thu Jan 04 2018 kernel-devel 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-source 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default-devel 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-syms 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Sun Jan 28 2018 Sat Dec 02 2017 libshine3
Also mp3 related. 3.1.0-5.2 x86_64
http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none)
As for the kernels, the latest from update is 4.4.114, there are various ways of purging kernels, I use a non standard one, maybe someone else can explain purge-kernels. Hope this helps Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday, 2018-02-18 at 16:13 +0800, George from the tribe wrote:
On 02/18/2018 02:43 AM, Carlos E. R. wrote:
Any other ideas?
Yes. Run this:
rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE}\t%{arch} \ %25{VENDOR}%25{PACKAGER} == %{DISTRIBUTION} %{DISTTAG}\n" \ | sort | cut --fields="2-" | tee rpmlist \ | egrep -v "openSUSE\ Leap\ 42\.3|openSUSE_Leap_42\.3" | less -S
...
Another method:
Fire "yast2 --qt sw_single &"
View: repositories tab.
Select the @System repo.
Secondary filter: unmaintained packages.
...
Ok, great, that is really helpful. I actually did both, and compared the rpm query with what I was seeing in yast. It seems that there are several packages in the rpm query that are listed as having been installed under packman when I had the packman 42.2 repository on there, but they are not showing up as unmaintained packages in yast.
It is possible, yes...
For example, the package libtxc_dxtn-1.0.1-4.2 shows up in the rpm query, but it is not listed as unmaintained in yast. I went into the packman repo for 42.3, and this package is not available there. Why would that be? An earlier version is available for 42.3, libtxc_dxtn-1.0.1-4.1.
I'm not sure why YaST doesn't mark this one.
But then there are others, like libbctoolbox0-0.2.0-4.1.x86_64.rpm, that the same version is available in both the 42.2 packman repo and the 42.3 packman repo.
Right, those are typical.
So, for these packages, what should I do? Should I just try deleting them and see what happens? I expect they were installed as dependencies with the 42.2 multimedia installation guide, which I did over a year ago.
Delete "libtxc_dxtn-1.0.1-4.2". If it is needed, YaST will tell you. In that case, the decision depends on what needs it: sometimes the answer is to delete all, maybe find that the name of some library changed slightly, maybe keep. On "libbctoolbox0-0.2.0-4.1.x86_64.rpm" click on "update unconditionally" (right click, context menu).
Here is the list of my extra packages:
Sat Nov 26 2016 Sat Oct 29 2016 libbctoolbox0 0.2.0-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Multimedia / openSUSE_Leap_42.2 (none) Sat Dec 17 2016 Thu Dec 15 2016 libtxc_dxtn 1.0.1-4.2 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Mon Apr 24 2017 Tue Mar 28 2017 libmovit6 1.5.0-2.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Fri Jul 21 2017 Mon Jul 17 2017 liba52-0 0.7.5+svn613-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 13 2017 libmad0 0.15.1b-4.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 libmp3lame0 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Wed Sep 06 2017 libtwolame0 0.3.13-5.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Thu Oct 05 2017 Fri Aug 25 2017 lame 3.99.5-1018.1 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Sun Dec 10 2017 Sat Dec 02 2017 movit-data 1.5.3-2.2 noarch http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-devel 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-source 4.4.104-18.44.1 noarch openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default-devel 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-syms 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Wed Jan 17 2018 Thu Jan 04 2018 kernel-default 4.4.104-18.44.1 x86_64 openSUSE http://bugs.opensuse.org == openSUSE Leap 42.2 (none) Sun Jan 28 2018 Sat Dec 02 2017 libshine3 3.1.0-5.2 x86_64 http://packman.links2linux.de packman@links2linux.de == Essentials / openSUSE_Leap_42.2 (none)
Packman ones: force upgrade as above, one by one, if upgrade available; even if it seems a downgrade. If not available, try remove. Kernel: ignore. It will be rotated out automatically when the next kernel update comes. The case of the kernel is different: it marked "multiversion" in the packager, so it tries to keep at least the previous version installed. There is a script that runs on boot that purges too old versions, so it is safer to forget. - -- Cheers, Carlos E. R. (from openSUSE 42.3 x86_64 "Malachite" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlqJbZUACgkQtTMYHG2NR9U4/gCdG0IensddMJaXW/ROuEY4Z6oX NVMAn3rJyS1yYF0KqG4Q78Tk2uIZdh0z =fuH5 -----END PGP SIGNATURE-----
On 17.02.2018 14:57, George from the tribe wrote:
I just upgraded to 42.3 by means of zypper dup. After fixing the nvidia issue, my system is running well again.
However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out? All my repos are now 42.3 repos. I tried this command:
# zypper se -i -s * | grep System
There is a command that is intended to find this kind of packages: zypper packages --orphaned
On Sunday, February 18, 2018 2:06:12 PM EST Florian Gleixner wrote:
On 17.02.2018 14:57, George from the tribe wrote:
I just upgraded to 42.3 by means of zypper dup. After fixing the nvidia issue, my system is running well again.
However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out? All my repos are now 42.3 repos. I tried this command:
# zypper se -i -s * | grep System
There is a command that is intended to find this kind of packages:
zypper packages --orphaned
Thanks! I'm going to use this regularly. Just tried it and, despite my having purged all orphans only 2 weeks ago (using the long way in YaST), it already found a new orphaned package from Packman. Very helpful. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/19/2018 03:06 AM, Florian Gleixner wrote:
On 17.02.2018 14:57, George from the tribe wrote:
I just upgraded to 42.3 by means of zypper dup. After fixing the nvidia issue, my system is running well again.
However, something on one of the threads made me think that I might have some old packages that have been held over from 42.2? I don't know for sure. So this is my question - is there a way to find out? All my repos are now 42.3 repos. I tried this command:
# zypper se -i -s * | grep System
There is a command that is intended to find this kind of packages:
zypper packages --orphaned
A pretty simple solution there, thanks. Seems to give the exact same readout in zypper that the yast solution posted by Carlos gives. Always good to know how to do it in both programs. -- George Box: 42.3 | KDE Plasma 5.8 | AMD Phenom IIX4 | 64 | 32GB Laptop #1: 42.3 | Gnome 3.20 | AMD FX 7TH GEN | 64 | 32GB Laptop #2: 42.3 | Gnome 3.20 | Core i5 | 64 | 8GB -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (12)
-
Andrei Borzenkov -
Basil Chupin -
Carlos E. R. -
Dave Howorth -
Dave Plater -
David C. Rankin -
Dennis Gallien -
Florian Gleixner -
George from the tribe -
listreader -
Marcus Meissner -
Peter Suetterlin