VERSION=“20150630 (Tumbleweed)”/KDE plasma5 i586
I updated yesterday with zypper up - it took nearly 5 hours so I just checked quickly a few functions and everything looked OK. Today I tried again zypper up with the response “nothing to do”. However apper showed several packages - mainly multimedia. So my first question why didn’t they show with zypper up?
However now apper crashes each time with the message “The PackageKit daemon has crashed”.
Now I don’t mind if apper crashes if I can update the MM packages with zypper. What would be the command there?
Thanks in advance
Uli
On 2015-07-04 00:56, fuerstu wrote:
>
> VERSION=“20150630 (Tumbleweed)”/KDE plasma5 i586
> I updated yesterday with zypper up - it took nearly 5 hours so I just
> checked quickly a few functions and everything looked OK. Today I tried
> again zypper up with the response “nothing to do”. However apper showed
> several packages - mainly multimedia. So my first question why didn’t
> they show with zypper up?
Well… the documented manner to update Tumbleweed or factory is using
“zypper dup” only. Of course, this has the problem that it does not
support vendor stickiness, but this was solved recently with a new
command line option.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
What gets proposed if you run “zypper -v dup” now? You can answer “n” for no to the confirmation request if you don’t want to proceed with the upgrade.
Thank you, robin_listas and consused, for the quick replies. I did a zypper -v dup and got amongst other answers the following:
25 packages to upgrade, 9 to downgrade, 2 new, 7 to remove, 11 to change vendor.
Overall download size: 77.1 MiB. Already cached: 0 B After the operation, 12.2 MiB will be
freed.
**Continue? [y/n/? shows all options] (y):**
The vendor changes are all from Packman to openSUSE and I want to avoid this since it may effect the functioning of the MM packages. Is there a way to proceed with upgrades without vendor changes? In the list of updates is e.g. dolphin and gnumeric and they should have nothing to do with MM.
Yes, you can use “zypper up” to avoid vendor changes (and also to avoid tricky conflicts). Otherwise I use zypper -v dup.
Thank you, consused, but that means I am back to where I was. zypper up does not update everything, apper crashes and zypper dup would change some vendors and I cannot select an option to update without vendor changes. As long as everything is working that is fine with me but it seems a little unsatisfactory.
Ok, surprised the vendor changes are from packman to openSUSE, without seeing them!
After new Tumbleweed started, I returned to using higher priorities for packman repos (i.e. lower numbers) e.g. 85, with the two main Tumbleweed repos at default priority 99 (I don’t have Update repos enabled yet, since they are for a rare emergency). You could try that priority change and use zypper dup.
Even so, after the big recent update, Audacity had switched back to openSUSE. On opening it failed trying to configure from ffmpeg (installed), so I used YaST to install the available update from packman, now it opens and works correctly again.
PS. not surprised about Apper, since it wasn’t rewritten for Plasma 5.
On 2015-07-04 01:26, fuerstu wrote:
> The vendor changes are all from Packman to openSUSE and I want to avoid
> this since it may effect the MM packages. Is there a way to proceed with
> upgrades without vendor changes? In the list of updates is e.g. dolphin
> and gnumeric and they should have nothing to do with MM.
As I said, there is a new (experimental) option to tell dup to respect
vendor stickiness. I’ll try to find it, I don’t know if it is
documented, but have a read now on man zypper.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
On 2015-07-04 02:07, Carlos E. R. wrote:
> As I said, there is a new (experimental) option to tell dup to respect
> vendor stickiness. I’ll try to find it, I don’t know if it is
> documented, but have a read now on man zypper.
>
Try:
export SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0
Some info:
https://bugzilla.opensuse.org/show_bug.cgi?id=893807
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Thank you, robin_listas, for that info. I didn’t find anything in the man pages - but that could be me… I did the export command - is that “SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0” now set or would I have to do this next time after a reboot before zupper -v dup? Although if you look at the output below I am not sure what to do except cancel out.
Thank you too, consused, I will change the priorities and see what happens then. Here you can see the vendor changes to openSUSE.
Computing upgrade...
8 Problems:
Problem: problem with installed package gstreamer-0_10-plugin-gnomevfs-0.10.36-14.12.i586
Problem: problem with installed package gstreamer-0_10-plugins-base-0.10.36-14.12.i586
Problem: problem with installed package libgstapp-0_10-0-0.10.36-14.12.i586
Problem: problem with installed package libgstinterfaces-0_10-0-0.10.36-14.12.i586
Problem: problem with installed package libxmmsclient-glib1-0.8-2.124.i586
Problem: problem with installed package libxmmsclient6-0.8-2.124.i586
Problem: problem with installed package xmms2-0.8-2.124.i586
Problem: problem with installed package xmms2-plugin-base-0.8-2.124.i586
Problem: problem with installed package gstreamer-0_10-plugin-gnomevfs-0.10.36-14.12.i586
Solution 1: install gstreamer-0_10-plugin-gnomevfs-0.10.36-12.3.i586 (with vendor change)
http://packman.links2linux.de --> openSUSE
**Choose the above solution using '1' or skip, retry or cancel [1/s/r/c] (c): c**
**linux-top:~ #**
I have now changed the priority of Packman:
**linux-top:~ #** zypper lr -p
# | Alias | Name | Enabled | GPG Check | Refresh | Priority
--+--------------+--------------+---------+-----------+---------+---------
1 | Mozilla | Mozilla | Yes | (r ) Yes | Yes | 99
2 | packman | packman | Yes | (r ) Yes | Yes | 85
3 | repo-debug | repo-debug | Yes | (r ) Yes | Yes | 99
4 | repo-non-oss | repo-non-oss | Yes | ( p) Yes | Yes | 99
5 | repo-oss | repo-oss | Yes | (r ) Yes | Yes | 99
6 | repo-update | repo-update | Yes | ( p) Yes | Yes | 99
**linux-top:~ #**
The result of zypper -v dup is the same as before.
Cheers
uli
Well the resolver probably needs to make the vendor changes as a result of an underlying problem with one or more of the (packman?) dependencies. So changing priorities won’t fix this. I notice it from your previous post now showing conflicts when vendor change is inhibited for zypper dup (and zypper up would ignore such conflict anyway). Also these are i586 (32bit) packages, so I’m not seeing your problem on my 64bit installation anyway.
It’s far too late here, so I cannot look at it further, zzzzz…, maybe someone on the night-shift can, or some more eyes on it tomorrow.:).
“zypper up” should be ok.
But if “zypper up” doesn’t list any updates, maybe there just are none (without vendor change)?
Apper might still show the result of the last check, if PackageKit crashes. At least that’s what I suspect, because otherwise it should show the same updates as “zypper up”…
I would use YaST->Software Management to check whether there are updates (with dependency problems probably) or not.
Apper (the application) should still work. But here PackageKit crashes apparently, not really a problem with Apper.
On 2015-07-04 03:06, fuerstu wrote:
>
> Thank you, robin_listas, for that info. I didn’t find anything in the
> man pages - but that could be me…
The feature is new and “hidden”, else it would be a command line option.
> I did the export command - is that
> “SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0” now set or would I have to do
> this next time after a reboot before zupper -v dup?
You have to do it every time you run a dup, and in the same session and
terminal, obviously:
export SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0
zypper dup
The feature is brand new and experimental. That’s what Tumbleweed is
for, after all 
If you have questions about it, ask in the factory mail list, please.
There you have some hope of reaching the people that created it. And
they expect to read from experiences.
Otherwise, just paste the output here, and we’ll try to think 
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Running “zypper up” to avoid vendor change seems straightforward, easier, not experimental, and documented.
You should probably also add the disclaimer: Avoiding vendor change can prevent updates to [multimedia] packages where dependency can only be satisfied by a third party vendor e.g. Packman. This may cause your [multimedia] application to fail.
On 2015-07-04 14:36, consused wrote:
>> The feature is brand new and experimental.
> Running “zypper up” to avoid vendor change seems straightforward,
> easier, not experimental, and documented.
However, the only recommended method by the factory/tumbleweed
developers to update F/TW is “zypper dup”. A zypper up is specifically
not recommended, although they recognize that it may work.
And in the case of the OP, it does not work.
And, as TW is experimental itself , I would not hesitate to try this
wonderful and long waited for new feature myself — if I had a system on
which to try, which I don’t.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Do you have a copy signed by the Tumbleweed developers to present here? You may find some of them using zypper up.
And in the case of the OP, it does not work.
That’s your interpretation, not mine. It worked, but failed to meet the OP’s requirement, which doesn’t seem to include wanting all working multimedia packages from Packman. The only evidence I saw was after your advice to inhibit zypper dup from vendor change, which failed with conflict and had to be cancelled!
And, as TW is experimental itself
No, openSUSE has published Tumbleweed as its Rolling Release. The experiment was the old service run successfully by GK-H. Where did you get that idea from anyway, perhaps it’s related to the habit of conflating factory with Tumbleweed. The developers’ factory is not published. Why not support your openSUSE Board in their efforts to make things clearer to its users ?
On 2015-07-04 21:36, consused wrote:
> robin_listas;2718134 Wrote:
>> A zypper up is specifically
>> not recommended, although they recognize that it may work.
> Do you have a copy signed by the Tumbleweed developers to present here?
Actually, yes. Somewhere. But very difficult to locate.
> You may find some of them using zypper up.
I know. But they aware of what they are doing and that it may not work
some times, and that then they need to use dup instead.
>> And in the case of the OP, it does not work.
> That’s your interpretation, not mine.
That’s right, it is my interpretation, and his.
> It worked, but failed to meet the
> OP’s requirement, which doesn’t seem to include wanting all working
> multimedia packages from Packman. The only evidence I saw was after your
> advice to inhibit zypper dup from vendor change, which failed with
> conflict and had to be cancelled!
No, I have not seen a proper zypper dup full result text with the export
in place.
>> And, as TW is experimental itself
> No, openSUSE has published Tumbleweed as its Rolling Release. The
> experiment was the old service run successfully by GK-H. Where did you
> get that idea from anyway, perhaps it’s related to the habit of
> conflating factory with Tumbleweed. The developers’ factory is not
> published. Why not support your openSUSE Board in their efforts to make
> things clearer to its users ?
By stating clearly that it is experimental, despite some people saying
it is not. Just ask the people doing it. Some of us did, and we got that
answer.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Finally back now - its Sunday just after lunch and I have plenty of answers - thanks a lot.
wolfi323 - But if “zypper up” doesn’t list any updates, maybe there just are none (without vendor change)?
That seems to be correct - at least with some I have checked with YAST:
dolphin
15.04.2-1.1-i586 from vendor openSUSE (installed)
15.04.2-3.2-i586 from repo-oss with priority 99 and vendor openSUSE
apper
0.9.2-1.1-i586 from vendor openSUSE (installed)
0.9.2-1.2–i586 from repo-oss with priority 99 and vendor openSUSE
The first seems from the repo-update, strange that there are the the same packages with different versions.
Both of these repos were created according to the instruction on your website (https://en.opensuse.org/openSUSE:Tumbleweed_installation).
consused - I don’t have Update repos enabled yet, since they are for a rare emergency
Is this the way to avoid these problems? I have not seen this anywhere and I am surprised that the update repository has not got the updated from the oss repository.
I have seen that several here use zypper up that’s why I used it and I presume these are those who have many repos from Packman. Hopefully there will be a version of zypper dup out soon which does not do vendor changes (or where you can select no vendor changes instead of having to cancel out)
Thank you robin-listas for clarifying the use of
export SOLVER_FLAG_DUP_ALLOW_VENDORCHANGE=0
Regarding my use of Tubleweed - I see it as something between development and official release and I would not put it on a mission-critical computer. However I expect to have some problems and that I can learn more from it. After all most of what I know about Linux is from using it and running into problems. And since I am no computer expert this always will be a patch work of knowledge. And having waited for hours on a phone for Microsoft help in 2000 without getting a satisfying solution to a Windows2000 problem I am glad I switched to Linux then. Here I can only recommend the help I received in the forums.
Now I am a bit confused. I noticed that there is no package from update but YAST shows when I select software management -> repositories something called @System. This is not listed when I go to repositories or do a zypper lr. The packages which need a vendor change are there (with many others) and the newer ones are at repo-oss. A list of all these packages is here:
**linux-top:~ #** zypper up
Loading repository data...
Reading installed packages...
The following 24 package updates will NOT be installed:
abiword apper ark banshee brasero cheese cpp48 digikam dolphin empathy gcc48 gcc48-c++ gimp
gnome-color-manager gnome-contacts gnome-control-center gnome-control-center-color
gnome-packagekit gnumeric hexchat hugin libgstwayland-1_0-0 libstdc++48-devel linphone
Nothing to do.
I presume the best way to solve is do a zypper -v dup and skip all the vendor changes from packman to something else.
Cheers
uli