Re: Konqueror und SFTP
2015-08-25 15:45 GMT+02:00 Volker Wysk : > Hi! > > I've installed SSH, on my desktop and my laptop, and in the command > line it works very good. > > I can log in to extensa (my laptop) from the remote command line with > "sftp v@extensa". When, howeve, I use Konqueror as a GUI für SFTP, it > aborts with the following error message: > > --schnipp--- > The requested operation could not be completed > > Details of the Request: > > URL: sftp://v@extensa > Protocol: sftp > Date and Time: Tuesday 25 August 2015 15:33 > Additional Information: (1)Der Host-Schlüssel für diesen Rechner kann > nicht gefunden werden, es existiert aber ein anderer Schlüsseltyp. > Möglicherweise versucht ein Angreifer, den Server-Schlüssel zu tauschen > um Ihrem Client vorzutäuschen, dass der Schlüssel nicht existiert. Sie > sollten den Systemverwalter darüber informieren. > Description: > > (2)Der Host-Schlüssel für diesen Rechner kann nicht gefunden werden, es > existiert aber ein anderer Schlüsseltyp. Möglicherweise versucht ein > Angreifer, den Server-Schlüssel zu tauschen um Ihrem Client > vorzutäuschen, dass der Schlüssel nicht existiert. Sie sollten den > Systemverwalter darüber informieren. > --schnapp--- > > The two German parts (1) and (2), are identical. Here's my translation: > > "The host key for this computer can't be found, but there exists > another key type. Possibly, an attacker tries to transpose the server > key in order to pretend the key doesn't exist. You should inform the > system administrator." > > When I use the Gnome File Manager instead of konqueror, then it works. > > Many thanks for any hints! > > Volker > > I don't know wich version of KDE you are running, I had a similar problem in wheezy (KDE 4.8.4) and I found [0] helpful, especially comment #10. Regards BZ [0] https://bugs.kde.org/show_bug.cgi?id=270322
Re: Icons and screensavers
firefox-esr is not yet in testing. Please wait another 2-3 days [1] then dist-upgrade and you should have firefox-esr replacing iceweasel and fixing the icons issue. bz [1]https://qa.debian.org/excuses.php?package=firefox-esr 2016-03-17 20:56 GMT+01:00 Carlos Kosloff : > Thanks for answer, it does not work that way in KDE. > > -- > On 03/17/2016 03:51 PM, Alex DEKKER wrote: > > On 17/03/16 17:26, Carlos Kosloff wrote: > > Thanks for answer but I don't see that it is possible to launch iceweasel > with a firefox icon, there is no firefox in the repo. > Please elaborate. > > On my system the package is called firefox-esr. Iceweasel is now a > transitional package. When I click on the Firefox icon [ahem, I'm using > razor-qt, not KDE] I get Firefox not Iceweasel. > > alexd > > >
Re: KUser & KDE Print settings prompt root password
Hi! 2016-09-26 23:25 GMT+02:00 Borden Rhodes : > As the subject says, on my Debian Stretch laptop, attempting to use > the KDE print settings or KUser prompts me to login with the root > account. This is a problem because I installed Debian with the root > account locked out. I thought Polkit was supposed to have taken care > of all of this. Perhaps I'm missing a package? I also reinstalled > kdesudo to no joy. > > I'm sure other K settings apps are broken like this, too, but I > haven't found them yet. > > I was able to avoid the root password prompt from the KDE printer settings module by just adding my user to the lpadmin group: $ sudo adduser lpadmin (logout - login afterwards) Other programs like KUser (KSystemLog is another one) seem a different issue. Apparently kuser, when launched from plasmashell, gains root privileges through kdesu (not Polkit). After you install kdesudo you *can* invoke it explicitly to start programs with sudo, but applications configured to be executed as root in the kde menu will still get root privileges through kdesu which requires the root password. If you want kdesudo to replace kdesu by default, you have to 'dpkg-reconfigure kdesudo' and select 'Yes' to divert kdesu: # dpkg-reconfigure kdesudo (select Yes, output:) Adding 'diversion of /usr/lib/kde4/libexec/kdesu to /usr/lib/kde4/libexec/kdesu.kde by kdesudo' Adding 'diversion of /usr/share/man/man1/kdesu.1.gz to /usr/share/man/man1/kdesu.kde.1.gz by kdesudo' This used to work in kde4 (wheezy, jessie). It seems that those diversions have no effect In kf5 because kdesu is loaded from a different location: $ pgrep -ax kdesu 5676 /usr/lib/x86_64-linux-gnu/libexec/kf5/kdesu -u root -c /usr/bin/kuser --icon kuser -caption KUser So, in fact applications launched through the multiarch /usr/lib//libexec/kf5/kdesu will never use kdesudo even if the latter is installed and configured to replace kdesu, this way you are always asked to provide the root password, not the user one. As a workaround you can open kmenuedit, navigate to System->KUser (or any other affected command), prepend 'kdesudo' to the command string and uncheck 'run as a different user' in the Advanced tab. Probably it's worth to file a bug against kdesudo even though the double location of kdesu is also playing a role in this issue. Regards BZ
Re: Is anyone else experiencing intermittent Plasma freezes as of very recently?
It's likely https://bugs.kde.org/show_bug.cgi?id=373131 As a workaround, switching to a VT (i.e Ctlr-Alt-F1) and back (Ctrl-Alt-F7) temporarily restores the correct behaviour. Greetings BZ 2016-12-14 11:55 GMT+01:00 Gard Spreemann : > Hello, > > Some recent package upgrade in Stretch (I'm trying to pin down which) > has caused parts of my Plasma desktop to freeze at seemingly random > intervals. When it happens (every few minutes), all windows continue > to behave normally, and new programs can be started with > alt-F2. However, the desktop area itself, the taskbar and any > notifications become unresponsive. Switching to a console and then > back to X, without doing anything else, makes everything work again > for a while. > > This seems to be exactly what is described in a recent Fedora bug [1]. > > Before I file a bug and investigate further: is anyone else > experiencing the same thing? Does anyone have any idea as to which > upgrade may have caused the problem? I can't believe the update > happened more than a week ago. > > Thanks. > > (I'm not subscribed to the list). > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1399396 > > > Best, > Gard > >
Re: Able to write to read-only pdf files
Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa < adriano.vil...@gmail.com> ha scritto: > Hello, > > Yesterday I came across a very weird behavior while annotating a pdf > file in Okular. Long story short: I opened a read-only pdf file > (permissions: 400), inserted some comments and hit the save button. At > this point, I thought I had been working on a write-enabled copy of > the file. After a while, I realized that I was actually working on the > read-only version of the file, that somehow got saved to disk when I > hit the save icon. Okular was not only able to save the file to disk, > but the file permissions were changed to 644. > > I initially thought this was an Okular problem. However, after some > more testing, I was able to reproduce the problem with Xournal. This > makes me think that the problem is not with Okular or Xournal, but > with some common library used by both of these packages (maybe > libpoppler?). > > Has anybody had this problem? Can anybody reproduce it? > > I'm using Debian testing. > > Thanks a lot, > > Adriano > Hi Adriano, the read-only permission on the pdf file just prevents it's contents to be changed. It still can be deleted if the directory it belongs to is not write protected. Editor programs usually do not directly change the contents of a file but rather save them to a temporary new one (with default permissions), delete the original and then rename the new file replacing the original one. I don't know if Okular works this way, but I think it quite likely does. Have a good release day! Bruno
Re: Able to write to read-only pdf files
Il giorno sab 14 ago 2021 alle ore 20:20 Adriano Vilela Barbosa < adriano.vil...@gmail.com> ha scritto: > On Sat, 14 Aug 2021 at 12:54, bruno zanetti wrote: > > > > Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa < > adriano.vil...@gmail.com> ha scritto: > >> > >> Hello, > >> > >> Yesterday I came across a very weird behavior while annotating a pdf > >> file in Okular. Long story short: I opened a read-only pdf file > >> (permissions: 400), inserted some comments and hit the save button. At > >> this point, I thought I had been working on a write-enabled copy of > >> the file. After a while, I realized that I was actually working on the > >> read-only version of the file, that somehow got saved to disk when I > >> hit the save icon. Okular was not only able to save the file to disk, > >> but the file permissions were changed to 644. > >> > >> I initially thought this was an Okular problem. However, after some > >> more testing, I was able to reproduce the problem with Xournal. This > >> makes me think that the problem is not with Okular or Xournal, but > >> with some common library used by both of these packages (maybe > >> libpoppler?). > >> > >> Has anybody had this problem? Can anybody reproduce it? > >> > >> I'm using Debian testing. > >> > >> Thanks a lot, > >> > >> Adriano > > > > > > Hi Adriano, > > the read-only permission on the pdf file just prevents it's contents to > be changed. It still can be deleted if the directory it belongs to is not > write protected. > > Editor programs usually do not directly change the contents of a file > but rather save them to a temporary new one (with default permissions), > delete the original and then rename the new file replacing the original > one. I don't know if Okular works this way, but I think it quite likely > does. > > > > Have a good release day! > > > > Bruno > > > > > > Hi Bruno, > > Thanks for your reply. > > Indeed, what you describe may be what's happening. If I change the > permissions of the directory where the file is to read-only, I get an > error message when trying to save the file. The error message says the > file could not be saved (error: access denied), and also says that it > could not write to file.pdf.part (this .part file must be temporary > file you mentioned). > > I understand this mechanism, but I think this is quite controversial > and problematic. I mean, as an end user I don't care what the editor > is doing behind the scenes; it just shouldn't be able to modify a file > marked as read-only. > > This is the first time I came across this behavior. No text editor I > ever used does this; LibreOffice doesn't do it either (rather, it > shows a message saying the document is open in read-only and shows an > "Edit Document" button, which allows you to edit the document and then > save it under a different name). > > The question is: should I file a bug report somewhere? I really don't > want editors overwriting my read-only documents... > > Thanks again, > > Adriano Well, some editors take care of not overwriting read-only files, some others (like kate, kwite) don't... But I second your reasoning, the right behaviour IMHO would be to respect the file permissions, regardless of the mechanism of the underlying filesystem. I'd suggest you report the issue on bugs.kde.org since it doesn't seem to be a debian specific issue. Best Bruno
Re: Able to write to read-only pdf files
Il giorno sab 14 ago 2021 alle ore 21:01 Marco Möller < ta...@debianlists.mobilxpress.net> ha scritto: > On 14.08.21 20:19, Adriano Vilela Barbosa wrote: > > On Sat, 14 Aug 2021 at 12:54, bruno zanetti > wrote: > >> > >> Il giorno sab 14 ago 2021 alle ore 15:39 Adriano Vilela Barbosa < > adriano.vil...@gmail.com> ha scritto: > >>> > >>> Hello, > >>> > >>> Yesterday I came across a very weird behavior while annotating a pdf > >>> file in Okular. Long story short: I opened a read-only pdf file > >>> (permissions: 400), inserted some comments and hit the save button. At > >>> this point, I thought I had been working on a write-enabled copy of > >>> the file. After a while, I realized that I was actually working on the > >>> read-only version of the file, that somehow got saved to disk when I > >>> hit the save icon. Okular was not only able to save the file to disk, > >>> but the file permissions were changed to 644. > >>> > >>> I initially thought this was an Okular problem. However, after some > >>> more testing, I was able to reproduce the problem with Xournal. This > >>> makes me think that the problem is not with Okular or Xournal, but > >>> with some common library used by both of these packages (maybe > >>> libpoppler?). > >>> > >>> Has anybody had this problem? Can anybody reproduce it? > >>> > >>> I'm using Debian testing. > >>> > >>> Thanks a lot, > >>> > >>> Adriano > >> > >> > >> Hi Adriano, > >> the read-only permission on the pdf file just prevents it's contents to > be changed. It still can be deleted if the directory it belongs to is not > write protected. > >> Editor programs usually do not directly change the contents of a file > but rather save them to a temporary new one (with default permissions), > delete the original and then rename the new file replacing the original > one. I don't know if Okular works this way, but I think it quite likely > does. > >> > >> Have a good release day! > >> > >> Bruno > >> > >> > > > > Hi Bruno, > > > > Thanks for your reply. > > > > Indeed, what you describe may be what's happening. If I change the > > permissions of the directory where the file is to read-only, I get an > > error message when trying to save the file. The error message says the > > file could not be saved (error: access denied), and also says that it > > could not write to file.pdf.part (this .part file must be temporary > > file you mentioned). > > > > I understand this mechanism, but I think this is quite controversial > > and problematic. I mean, as an end user I don't care what the editor > > is doing behind the scenes; it just shouldn't be able to modify a file > > marked as read-only. > > > > This is the first time I came across this behavior. No text editor I > > ever used does this; LibreOffice doesn't do it either (rather, it > > shows a message saying the document is open in read-only and shows an > > "Edit Document" button, which allows you to edit the document and then > > save it under a different name). > > > > The question is: should I file a bug report somewhere? I really don't > > want editors overwriting my read-only documents... > > > > Thanks again, > > > > Adriano > > > > Adriano, I am simply a user, not a developer. I fully agree with you and > suggest to file a bug report. In 30 years computing I have never noticed > and assumed something like this, and although the explanation of Bruno > sounds reasonable, the behavior is not reasonable at all from the point > of view of a user! Until you and Bruno mentioned this behavior, I would > not even have expected this to be possible by the filesystem's policy > and initially reading your original post suspect this even to be a > filesystem bug! If data represented by a file name is marked read-only > on the filesystem level, then for this file name the data should not be > replaceable. If this technically would be possible, like Bruno suspects > it, then this still doesn't make it right from the users point of view. > > --- > Just my thoughts! > Marco. > Another subtle effect to pay attention to is that saving that way a file 'a' hard-linked to a file 'b', it will break the link and only 'a' gets updated because the original linked file is actually deleted! This behaviour can be desired in some cases, but if it's not, it's quite hard to track down the reason. Bye Bruno
Re: Broken KDE in Sid/Unstable
Hi Miguel,
I assume you are on sid/testing and you did a dist-upgrade (or
full-upgrade).
This morning I tried to dist-upgrade sid but I eventually gave up since apt
asked to remove plasma-desktop and other stuff I didn't think it was good
to remove.
Look at the logfiles in /var/log/apt and see if something got removed along
with the upgrade.
Just guessing.
Best
bz
Il giorno dom 19 set 2021 alle ore 14:28 Miguel A. Vallejo
ha scritto:
> Hi!
>
> This morning an apt update broke my kde. I can log in, but only to get
> into a black screen with the mouse's cursor, even using a newly created
> user.
>
> I can't see any obvious error in syslog, but there is something in
> .xsession-errors :
>
> Kapplymousetheme ("breeze_cursors","24") exited with user code 255
>
> And some lines below a lot of unrecognized keysims from kwin_xkbcommon, a
> NULL argument for networkIdsList, a failed to parse kaccess.desktop, many
> other errors ( sorry, I'm typing on phone) until a broken connection to the
> X11 server brings back the login screen.
>
> Any ideas?
>
> Thanks in advance.
>
>
>
Re: Broken KDE in Sid/Unstable
Il giorno lun 20 set 2021 alle ore 01:30 chris ha scritto: > On Sunday, 19 September 2021 16:19:09 CEST bruno zanetti wrote: > > Hi Miguel, > > > > I assume you are on sid/testing and you did a dist-upgrade (or > > full-upgrade). > > This morning I tried to dist-upgrade sid but I eventually gave up since > apt > > asked to remove plasma-desktop and other stuff I didn't think it was good > > to remove. > > There is a small difficulty around `libqalculate22`, with `dist-upgrade`. > And > you might have to manually fix it. (It was the 16th, and `dist-upgrade` > was > removing a large part of kde). > > I did: > `aptitude full-upgrade libqalculate20-` > and then: > `aptitude full-upgrade` > > On `#debian-next`, someone did suggest: > `apt full-upgrade task-kde-desktop plasma-workspace kwin-x11` > > (I use wayland, not sure it would have worked). You're right, I did the same, but in my case 'aptitude full-upgrade' alone did it right with no need for any hint. It seems there are some missing break/replace in libqalculate22 that would have eased the upgrade. Anyway, aptitude proved to be smarter than apt and gave the right solution. Best bz
Re: Plasma 5.24 coming to unstable
Il giorno lun 28 feb 2022 alle ore 14:50 Miguel A. Vallejo ha scritto: > The question is: > > Why is APT not smart enough to see that the proposed upgrade will fail? > > It always starts to install packages and at some point fails because > some package needs another package with a specific version. Why does > it not detect these cases after starting upgrading packages? It knows > the versions available for every package so it should prevent these > problems. > > Is it a bug or a missing APT feature? > I think the problem in which you incurred is not related to an APT bug or (missing) feature but rather a packaging bug ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006538) that has been catched (and fixed) in sid. After all this is just the purpose of sid. BZ
