Re: KDE 4.4 Beta2 (4.3.85) tarballs available
On 12/18/2009 02:24 PM, Rex Dieter wrote: > Dirk Mueller wrote: >> On Friday 18 December 2009, Dirk Müller wrote: >> >>> I just finished uploading the first set of Beta2 tarballs, a bit later than >>> expected, sorry about that. >>> >>> I'll start testing them now, please report any issues you might find. >> >> Sebas suggested to release them earlier than scheduled on the release >> schedule, possibly even afternoon tomorrow. >> >> any opinions about that? it seems doable to me but I would like to have >> positive compile feedback until then from at least two sources (myself >> included). > > -1 here so far, kdebindings is failing somewhere in smoke/plasma for me. I think this should fix it, http://websvn.kde.org/?revision=1063597&view=revision Test builds going now. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Beta2 (4.3.85) tarballs available
Dirk Mueller wrote: > On Friday 18 December 2009, Dirk Müller wrote: > >> I just finished uploading the first set of Beta2 tarballs, a bit later than >> expected, sorry about that. >> >> I'll start testing them now, please report any issues you might find. > > Sebas suggested to release them earlier than scheduled on the release > schedule, possibly even afternoon tomorrow. > > any opinions about that? it seems doable to me but I would like to have > positive compile feedback until then from at least two sources (myself > included). -1 here so far, kdebindings is failing somewhere in smoke/plasma for me. Gory details, [ 28%] Building CXX object smoke/plasma/CMakeFiles/smokeplasma.dir/x_7.o cd /builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma && /usr/bin/c++ -DMAKE_SMOKEPLASMA_LIB -D_BSD_SOURCE ... -D_LARGEFILE64_SOURCE -o CMakeFiles/smokeplasma.dir/x_7.o -c /builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma/x_7.cpp ... CMakeFiles/smokeplasma.dir/x_7.o: In function `x_Plasma__ScrollWidget': /builddir/build/BUILD/kdebindings-4.3.85/x86_64-redhat-linux-gnu/smoke/plasma/x_7.cpp:1946: undefined reference to `Plasma::ScrollWidget::ScrollWidget(QGraphicsItem*)' collect2: ld returned 1 exit status Even more gory details, http://koji.fedoraproject.org/koji/taskinfo?taskID=1880201 http://koji.fedoraproject.org/koji/getfile?taskID=1880201&name=build.log -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Request for deprecation of KDESu::SshProcess and removal of kdesu_stub/kdessh
Hi,
KDESu::SshProcess (in kdelibs) and the commandline shell for it, kdessh (in
kdeutils) are horribly broken (as in: do not work and may be insecure) and (at
least for me) seem not easy to be fixed.
I guess most of you do not even know these things exist, so:
kdessh is a wrapper to ssh and, instead of executing the original remote
command, first (via KDESu::SshProcess) fires up kdesu_stub on the remote
computer to setup the environment variables as needed for a better integration
into the local session, only then executes the original command.
Additionally it also caches the passwords (but does not use KWallet).
It is not working at all currently, as this commit
"Move kdesu_stub to libexec"
http://websvn.kde.org/?view=revision&revision=666108
moved kdesu_stub out of the $PATH, so the ssh server will not find it.
Is there a chance somebody remembers why it was moved to ? And not
perhaps renamed kdesu_stub to kdesu_stub4? Or just have it conflict with the
KDE 3 version, like e.g. KWrite has a conflict, too.
The class KDESu::SshProcess/StubProcess itself has a wild mixtures of
undocumented return values, seems to forget about child processes in some
conditions, has password strings in unsecured memory, does not reuse the
running ssh connection after testing for password needs, does not do a proper
check for false passwords and whatelse.
From lxr.kde.org it seems kdessh is the only user of KDESu::SshProcess,
besides kvpnc in playground/network (no idea about its state). And with zero
reports about this problem on b.k.o kdessh also seems without any users.
As noone has ever had a closer look at kdessh until now (starting kdessh did
nothing, including no obvious harm, so it got ignored), including the kdeutils
coordinator (who is writing here) it was only now decided to move kdessh from
kdeutils to tags/unmaintained after the Beta2 release. Sorry for any
inconvenience.
Additionally the class KDESu::SshProcess in kdelibs should be marked as
deprecated. Perhaps it could be even removed, as I do not think anyone is
using this class/these symbols?
Also kdesu_stub does no longer needed to be built and installed, as long as it
ends in lib/kde4/libexec.
Still I think such a utility for the integrated execution of remote programs
is nice to have. But with X11-forwarding-enabled ssh client/servers and ssh-
agent/-add it should perhaps have another approach, including integration of
KWallet. I also wonder how much remote X clients can and should be integrated
in the local session at all, including the Session D-Bus?
Cheers
Friedrich
PS: In case you are interested find attached two patches which made kdessh at
least working again, until I found SshProcess too broken to continue to clean
up for all possible conditions. Patches do s/magic numbers/enums/g, renames
kdesu_stub to kdesu_stub4 and installes it to bin/ again, code style cleanup,
more caring for child processes.
--
Okteta - KDE Hex Editor - http://utils.kde.org/projects/okteta
Index: kdelibs/kdesu/ssh.h
===
--- kdelibs/kdesu/ssh.h (Revision 1063492)
+++ kdelibs/kdesu/ssh.h (Arbeitskopie)
@@ -29,8 +29,11 @@
const QByteArray &command = QByteArray());
~SshProcess();
-enum Errors { SshNotFound=1, SshNeedsPassword, SshIncorrectPassword };
+enum Errors { NoError=0, SshNeedsNoPassword=0, SshNotFound=1, SshNeedsPassword, SshIncorrectPassword };
+enum ExtendedErrors { GeneralError=-1 };
+enum ExecType { NormalExec=0, PasswordCorrectCheck=1, PasswordNeededCheck=2 };
+
/**
* Sets the target host.
*/
@@ -59,7 +62,7 @@
/**
* Executes the command.
*/
-int exec(const char *password, int check=0);
+int exec(const char *password, int check=NormalExec);
QByteArray prompt() const;
QByteArray error() const;
@@ -69,6 +72,7 @@
virtual QByteArray displayAuth();
private:
+enum SshResult { SshProtocolError=-1, SshNoError=0, StoppedAtPasswordPrompt=1, SshOtherError=255 };
int ConverseSsh(const char *password, int check);
protected:
Index: kdelibs/kdesu/stub.cpp
===
--- kdelibs/kdesu/stub.cpp (Revision 1063492)
+++ kdelibs/kdesu/stub.cpp (Arbeitskopie)
@@ -105,95 +105,101 @@
int StubProcess::ConverseStub(int check)
{
-QByteArray line, tmp;
-
+// stub header
while (1)
{
- line = readLine();
- if (line.isNull())
- return -1;
+QByteArray line = readLine();
+if (line.isNull()) {
+return StubProtocolError;
+}
- if (line == "kdesu_stub")
- {
- // This makes parsing a lot easier.
- enableLocalEcho(false);
- if (check) writeLine("stop");
- else writeLine("ok");
- break;
- }
+if (line == "kdesu_stub") {
+// This makes parsing a lot easier.
+enableLocalEcho(false);
+writeL
Re: KDE S.C 4.5, the version that will definitely be a milestone.
Hi Inas, Thanks for your kind email, glad you like the direction of development :) On Friday 18 December 2009 12:45:09 lnas90 lnas90 wrote: > I think many of us already believe that the series of kde 4 sc has much > more potential than the previous version, 3.5, but unfortunately not > everyone believe it yet. I have noticed that KDE sc depends on the quality > of the drive running, I'm not saying the video card on top of the line, > but the driver was and with good performance. The gnome on the contrary > does not suffer so much with this problem, compiz does some 'black magic' > to make work legal in most cases. When 4.4 is released we believe that we > are best served in relation to the video driver, see the recent advances > in the kernel with the drive nouveau being pulled into the main branch and > the constant improvements in the amd / ati, 3d promise that even by > default to very soon for most cards. Not to mention that the comparison is > kind of inevitable, for 3.5 X 4.5, understand? Whether or not people iram > make this comparison. My proposal is to extend the deadline for launch on > 1 or 2 months, and half that time would be to delay the freezing of funds > and the other half to stabilize the code. Not to mention that would be a > great marketing ploy, since the gnome 3 will be released in September and > the current forecast serguei we lançariamos the 4.5 of August, that when > the gnome 3 comes out 'eyes will be turned over to him. " I do not have > anything wrong with that, it is simply marketing. > I propose to help in way possible, remembering that I am not programmer and > Brazil, but if you need me I am available. Thank you all and please > comment on the matter. If you want to help, there's enough to do :) Just subscribe on the kde-promo list and watch it for a bit. There are regular offers for smaller (or larger, if you feel like that) jobs flying by. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Beta2 tagging tonight?
On Wed, Dec 16, 2009 at 02:47:00PM +0100, Dirk Mueller wrote: > are we good to go with Beta2? Any blockers? How are the tars doing? Jonathan ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Beta2 (4.3.85) tarballs available
On Friday 18 December 2009, Dirk Müller wrote: > I just finished uploading the first set of Beta2 tarballs, a bit later than > expected, sorry about that. > > I'll start testing them now, please report any issues you might find. Sebas suggested to release them earlier than scheduled on the release schedule, possibly even afternoon tomorrow. any opinions about that? it seems doable to me but I would like to have positive compile feedback until then from at least two sources (myself included). Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.4 Beta2 (4.3.85) tarballs available
Hi, I just finished uploading the first set of Beta2 tarballs, a bit later than expected, sorry about that. I'll start testing them now, please report any issues you might find. Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE S.C 4.5, the version that will definitely be a milestone.
I think many of us already believe that the series of kde 4 sc has much more potential than the previous version, 3.5, but unfortunately not everyone believe it yet. I have noticed that KDE sc depends on the quality of the drive running, I'm not saying the video card on top of the line, but the driver was and with good performance. The gnome on the contrary does not suffer so much with this problem, compiz does some 'black magic' to make work legal in most cases. When 4.4 is released we believe that we are best served in relation to the video driver, see the recent advances in the kernel with the drive nouveau being pulled into the main branch and the constant improvements in the amd / ati, 3d promise that even by default to very soon for most cards. Not to mention that the comparison is kind of inevitable, for 3.5 X 4.5, understand? Whether or not people iram make this comparison. My proposal is to extend the deadline for launch on 1 or 2 months, and half that time would be to delay the freezing of funds and the other half to stabilize the code. Not to mention that would be a great marketing ploy, since the gnome 3 will be released in September and the current forecast serguei we lançariamos the 4.5 of August, that when the gnome 3 comes out 'eyes will be turned over to him. " I do not have anything wrong with that, it is simply marketing. I propose to help in way possible, remembering that I am not programmer and Brazil, but if you need me I am available. Thank you all and please comment on the matter. -- Deus te abençoe ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
