Here’s a lesson for new or distracted users: I tried to fix a small issue in Tumbleweed where I didn’t watch carefully during a run of zypper dup, overlooked something. Then I decided to take it back to 13.1 openSUSE again and then run it back to Tw with a couple of zypper dup operations.
Well now I’m reinstalling the whole OS and it serves me right! LOL
If the latter, this might be caused by that branding package problem (i.e. openSUSE-Current-Updates has higher versioned branding packages that prevent cerain other packages from being upgraded which results in an incompatible mix) that already appeared one year ago, and seems to be back now.
Try to give the Tumbleweed repo a higher priority (i.e. lower priority number) in YaST->Software Repositories f.e. and run “zypper dup”. That should fix it. kdebase4-workspace and related packages will get downgraded to 4.11.8 but that shouldn’t matter as the most important fixes of 4.11.9 are included in those (openSUSE’s) 4.11.8 packages already.
In any case, it would be good to see your repo list I suppose:
PS. I vaguely remember a mailing list discussion involving Greg K-H about this or similar issue. It wasn’t going to be fully resolved. However I think there was a change leading to a “best available” outcome where the problematic updates coming from the 13.1 repo would only get reversed at the next zypper dup. That has now worked here several times over the last few weeks.
Thank you all for your advice. I can’t “fix” the problem I stared with because I in trying to fix it I irretrievably wrecked the dependencies. Now I see that it was quite probable that I was a victim of the systemic flaw you guys just similarly pointed to. So now I’m aware.
So yesterday I got impatient again and saved directories for the likes of samba and apache and other stuff I needed like tricky *.conf files and then formatted root and reinstalled 13.1 and then put the saved stuff back in. Now I’m going to dup back to Tumbleweed again but I’ll be very careful in future to look carefully at the proposal from zypper before I pull the trigger. (and I’ll use the -v too thanks and set a 98 on the Tw repos [maybe]).
(It takes a while to get back in to the Tw rhythm).
If you use -v for the larger [initial] upgrade, you may not be able to scroll back far enough to view the whole report in terminal. In that case you would need to direct the output to a file (~/file), to catch all of it.
Another useful method, and one new to me. I tried it successfully with a non-root terminal and command, but without using another terminal to view the file.
With the terminal still open, I tried to view “typescript” via dolphin, but an editor failed to open. The file was there but not yet showing as “plain text”. Unsurprisingly, on closing the terminal the file became “plain text” and was then viewable. So what did you actually do to be able to view “typescript” in the other terminal?
I also noticed a couple of strange lines of repetitive [control?] characters, before it added the command(s) I used. In fact I had used the up-arrow key to reach a previous command, and it also included the preceding two commands that had passed through the command-line (but not entered). It’s no big deal, but I would be interested in any comment you could make about all those additional entries in the file as they seem a bit unnecessary.
I used the “less” command from another terminal (the universal text file browser).
Yes, there are control sequences there, but usually not a big problem.
What you probably saw, was the effect of buffering. The full transcript had not yet made it to the file. It was partly in buffers.
In practice, what has not made it to the “typescript” file due to buffering, is part of what you can still see in the scroll back for the terminal where you did the “zypper -v dup”.
The “script” command is useful where there is a possibility that you might want to look at the transcript later. It is easy enough to delete the “typescript” file, if you later decide that it has nothing of interest.
> If you use -v for the larger [initial] upgrade, you may not be able to
> scroll back far enough to view the whole report in terminal. In that
> case you would need to direct the output to a file (~/file), to catch
> all of it.
I suggest “zypper … | tee somefile”
The terminal works, yet you get a log
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Yes, its purpose is to provide hard copy of the terminal session (post exit), and “typescript” did delete easily enough.
I’m still surprised that it also logged those commands displayed from .bash_history but not executed. They really don’t qualify as part of the current terminal session being recorded.
I haven’t seen that happen. But then I use “csh”, so I guess I wouldn’t. The “typescript” file should contain a replica of what is sent to the terminal (including control characters).
That one gives a nice clean file of terminal output, for a single command. I tested it with “zypper lr -d …”, and its wide report lined up perfectly.
As expected, a second command directed to the same file isn’t appended and overwrites the previous result. In this case it’s important to view the results before repeating “zypper dup”, or just remember to use a different file name if a second run is needed.
On 2014-06-16 01:36, consused wrote:
>
> robin_listas;2649097 Wrote:
>> I suggest “zypper … | tee somefile”
>>
>> The terminal works, yet you get a log
> That one gives a nice clean file of terminal output, for a single
> command. I tested it with “zypper lr -d …”, and its wide report lined
> up perfectly.
>
> As expected, a second command directed to the same file isn’t appended
> and overwrites the previous result.
Then use “tee -a somefile”
You can separate entries like this:
first command | tee somefile
echo -e "
" >> somefile
next command | tee -a somefile
If you are using multiple commands, then “script” seems more
appropriate. The man page says:
script makes a typescript of everything printed on your
terminal. It is useful for students who need a hardcopy
record of an interactive session as proof of an assignment,
as the typescript file can be printed out later with lpr(1).
Or you can use “tmux -v”, for instance.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
On 2014-06-16 00:06, nrickert wrote:
>
> consused;2649098 Wrote:
>> I’m still surprised that it also logged those commands displayed from
>> .bash_history but not executed. They really don’t qualify as part of the
>> current terminal session being recorded.
>
> I haven’t seen that happen. But then I use “csh”, so I guess I
> wouldn’t. The “typescript” file should contain a replica of what is
> sent to the terminal (including control characters).
Even passwords, I believe, so beware.
And… root can capture any terminal without telling anyone, I read
somewhere. I mean, I have not tried hard to do it, so I don’t know how
exactly to do it, but I think it is done by reading from the device file
associated to the terminal.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)
Only if the password is echoed to the terminal. It usually isn’t.
The “typescript” file does not get your input. It only gets the output. It has the appearance of getting your input, only because your input is echoed back as output. But that normally does not happen when you input a password.
