Re: Setting up a Quality Team within KDE

[Alexander Neundorf]

On Saturday 14 April 2012, Laszlo Papp wrote:
> > Afterwards it runs cppcheck on the source code...
> 
> That is a really nice advantage, if it can be integrated with handy
> tools. Although, I would personally like to use much more advanced and
> useful tools than cppcheck.
> 
> [...]
> 
> > But overall these are two very useful solutions which do not compete with
> > each other and we should make use of them in a useful combined way, e.g.
> > by submitting build results from build.kde.org to CDash.
> 
> Fair enough, thanks.
> 
> One additional comment on my side is that, if I read these lines on
> the jenkins website, I have the impression Jenkins can cover the use
> case of CDash in the sense of running the build from cron jobs:

I think cdash can do more than you (and me) know.
I know there is the so called cdash@home feature, which can kind of trigger 
builds on machines.
It can also be integrated with gerrit.
Here Marcus explains the setup Kitware is using:
http://www.kitware.com/source/home/post/62

Alex

Re: Review Request: More kio_sftp login related fixes

[Dawit Alemayehu]

> On April 21, 2012, 9:05 a.m., Andreas Schneider wrote:
> > Did you also test if keyboard-interactive still works correctly?

No, because I do not even know how to enable that functionality in my ssh 
config and was lazy to search and find out. Just looking at the code though I 
immediately see a problem where it sets the error message in the first dialog 
box which will cause the retry dialog to be shown. I dunno if that was 
intentional, but it is wrong. The user will not only see the message sent from 
the ioslave, but also gets the question "Do you want to retry?".

BTW, I take back what I stated in the description of problem #1. It is not my 
last patch that caused the bug. It is there prior to my patch as well since I 
checked out and tested v4.8.0 to see if that was the case. Anyhow, I can try to 
see if I can figure out how to enable keyboard interactive mode and test that 
too. 

For the record I did not actually set out to fix these issues in kio_sftp. It 
resulted from my work on fixing problems in kpasswdserver. I needed someway to 
test those changes and the ssh server happens to be something that is already 
up and running on my system. Lucky kio_sftp. ;)


- Dawit


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104642/#review12748
---


On April 17, 2012, 7:16 a.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104642/
> ---
> 
> (Updated April 17, 2012, 7:16 a.m.)
> 
> 
> Review request for KDE Runtime and Andreas Schneider.
> 
> 
> Description
> ---
> 
> This is the last one of the sftp login fixes series and addresses the 
> following problems:
> 
> #1. Correctly handle login failure that results from a different username 
> being used when setting the 
> SSH_OPTIONS_USER option and calling ssh_userauth_password. I think this might 
> have been due to
> a regression caused by my previous patch. Nonetheless, this patch addresses 
> it.
> 
> #2. Changed public key authentication so that incorrect public key passwords 
> generate a retry dialog
> instead of simply continuing to the next available authentication method.
> 
> 
> Diffs
> -
> 
>   kioslave/sftp/kio_sftp.h f497c0b 
>   kioslave/sftp/kio_sftp.cpp e38c629 
> 
> Diff: http://git.reviewboard.kde.org/r/104642/diff/
> 
> 
> Testing
> ---
> 
> Testing for #1:
> ===
> 1.) Make sure a ssh server is running on your system.
> 2.) Attempt to login into your system: sftp://127.0.0.1.
> 3.) When prompted for credentials, enter a user name other than the currently 
> logged in user.
> 
> Current Behavior:
> Login attempt will simply fail eventually and and error page is displayed.
> 
> New (Fixed) Behavior:
> Successfully log into the server with the specified user name.
> 
> 
> Testing for #2:
> ===
> 1.) Create a ssh key with password protection and add it to the 
> authorized_keys file.
> 2.) Make sure the ssh public key is in your .ssh directory.
> 3.) Attempt to login into your system: sftp://127.0.0.1
> 4.) When prompted for the passpharse for the key, enter a bogus password. 
> 
> Current behavior:
> No retry dialog is ever shown for an invalid or improper ssh key passphrase 
> and the process simply moves on to the next authentication method.
> 
> New(Fixed) behavior:
> Show a retry dialog if the failure is due to invalid password. If the user 
> then presses cancel on the retry dialog, simply behave the same way as if the 
> cancel button is pressed on the password dialog. That is continue onto the 
> next authentication method.
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request: More kio_sftp login related fixes

[Andreas Schneider]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104642/#review12748
---


Did you also test if keyboard-interactive still works correctly?

- Andreas Schneider


On April 17, 2012, 7:16 a.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104642/
> ---
> 
> (Updated April 17, 2012, 7:16 a.m.)
> 
> 
> Review request for KDE Runtime and Andreas Schneider.
> 
> 
> Description
> ---
> 
> This is the last one of the sftp login fixes series and addresses the 
> following problems:
> 
> #1. Correctly handle login failure that results from a different username 
> being used when setting the 
> SSH_OPTIONS_USER option and calling ssh_userauth_password. I think this might 
> have been due to
> a regression caused by my previous patch. Nonetheless, this patch addresses 
> it.
> 
> #2. Changed public key authentication so that incorrect public key passwords 
> generate a retry dialog
> instead of simply continuing to the next available authentication method.
> 
> 
> Diffs
> -
> 
>   kioslave/sftp/kio_sftp.h f497c0b 
>   kioslave/sftp/kio_sftp.cpp e38c629 
> 
> Diff: http://git.reviewboard.kde.org/r/104642/diff/
> 
> 
> Testing
> ---
> 
> Testing for #1:
> ===
> 1.) Make sure a ssh server is running on your system.
> 2.) Attempt to login into your system: sftp://127.0.0.1.
> 3.) When prompted for credentials, enter a user name other than the currently 
> logged in user.
> 
> Current Behavior:
> Login attempt will simply fail eventually and and error page is displayed.
> 
> New (Fixed) Behavior:
> Successfully log into the server with the specified user name.
> 
> 
> Testing for #2:
> ===
> 1.) Create a ssh key with password protection and add it to the 
> authorized_keys file.
> 2.) Make sure the ssh public key is in your .ssh directory.
> 3.) Attempt to login into your system: sftp://127.0.0.1
> 4.) When prompted for the passpharse for the key, enter a bogus password. 
> 
> Current behavior:
> No retry dialog is ever shown for an invalid or improper ssh key passphrase 
> and the process simply moves on to the next authentication method.
> 
> New(Fixed) behavior:
> Show a retry dialog if the failure is due to invalid password. If the user 
> then presses cancel on the retry dialog, simply behave the same way as if the 
> cancel button is pressed on the password dialog. That is continue onto the 
> next authentication method.
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request: More kio_sftp login related fixes

[Andreas Schneider]

> On April 21, 2012, 9:05 a.m., Andreas Schneider wrote:
> > Did you also test if keyboard-interactive still works correctly?
> 
> Dawit Alemayehu wrote:
> No, because I do not even know how to enable that functionality in my ssh 
> config and was lazy to search and find out. Just looking at the code though I 
> immediately see a problem where it sets the error message in the first dialog 
> box which will cause the retry dialog to be shown. I dunno if that was 
> intentional, but it is wrong. The user will not only see the message sent 
> from the ioslave, but also gets the question "Do you want to retry?".
> 
> BTW, I take back what I stated in the description of problem #1. It is 
> not my last patch that caused the bug. It is there prior to my patch as well 
> since I checked out and tested v4.8.0 to see if that was the case. Anyhow, I 
> can try to see if I can figure out how to enable keyboard interactive mode 
> and test that too. 
> 
> For the record I did not actually set out to fix these issues in 
> kio_sftp. It resulted from my work on fixing problems in kpasswdserver. I 
> needed someway to test those changes and the ssh server happens to be 
> something that is already up and running on my system. Lucky kio_sftp. ;)

Normally password authentication is turned off in the ssh server (default for 
openssh) and keyboard interactive is used. There are some flaws in password 
authentication and keyboard-interactive is a much more flexible way. So if you 
have current Linux distribution then password authentication is turned of and 
you have keyboard-interactive authentication connecting to localhost.

Thanks for all the fixes. I don't have time for libssh and kio_sftp lately. 
There are other projects I need to drive forward right now :)


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104642/#review12748
---


On April 17, 2012, 7:16 a.m., Dawit Alemayehu wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104642/
> ---
> 
> (Updated April 17, 2012, 7:16 a.m.)
> 
> 
> Review request for KDE Runtime and Andreas Schneider.
> 
> 
> Description
> ---
> 
> This is the last one of the sftp login fixes series and addresses the 
> following problems:
> 
> #1. Correctly handle login failure that results from a different username 
> being used when setting the 
> SSH_OPTIONS_USER option and calling ssh_userauth_password. I think this might 
> have been due to
> a regression caused by my previous patch. Nonetheless, this patch addresses 
> it.
> 
> #2. Changed public key authentication so that incorrect public key passwords 
> generate a retry dialog
> instead of simply continuing to the next available authentication method.
> 
> 
> Diffs
> -
> 
>   kioslave/sftp/kio_sftp.h f497c0b 
>   kioslave/sftp/kio_sftp.cpp e38c629 
> 
> Diff: http://git.reviewboard.kde.org/r/104642/diff/
> 
> 
> Testing
> ---
> 
> Testing for #1:
> ===
> 1.) Make sure a ssh server is running on your system.
> 2.) Attempt to login into your system: sftp://127.0.0.1.
> 3.) When prompted for credentials, enter a user name other than the currently 
> logged in user.
> 
> Current Behavior:
> Login attempt will simply fail eventually and and error page is displayed.
> 
> New (Fixed) Behavior:
> Successfully log into the server with the specified user name.
> 
> 
> Testing for #2:
> ===
> 1.) Create a ssh key with password protection and add it to the 
> authorized_keys file.
> 2.) Make sure the ssh public key is in your .ssh directory.
> 3.) Attempt to login into your system: sftp://127.0.0.1
> 4.) When prompted for the passpharse for the key, enter a bogus password. 
> 
> Current behavior:
> No retry dialog is ever shown for an invalid or improper ssh key passphrase 
> and the process simply moves on to the next authentication method.
> 
> New(Fixed) behavior:
> Show a retry dialog if the failure is due to invalid password. If the user 
> then presses cancel on the retry dialog, simply behave the same way as if the 
> cancel button is pressed on the password dialog. That is continue onto the 
> next authentication method.
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

Re: Review Request: kjs: All prototype constructor should be [[Writable]]: true, [[Enumerable]]: false, [[Configurable]]: true

[Maks Orlovich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104680/#review12762
---

Ship it!



kjs/interpreter.cpp


These are not properties of the global object, though. These are the 
.constructor properties of the prototypes --- that is, these are not thing like 
"SyntaxError" (which is set above, in line 424), but rather 
"SyntaxError.prototype.constructor". Yes, those properties refer to the same 
object, but they're set on different things 
(global/[Window] vs. SyntaxError.prototype).

I think the rule that can justify this is actually in 15 (without any dot):
"Every other property described in this 
clause has the attributes { [[Writable]]: true, [[Enumerable]]: false, 
[[Configurable]]: true } unless otherwise specified"

Looks good other than, so please just fix your changelog :)



- Maks Orlovich


On April 19, 2012, 7:41 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104680/
> ---
> 
> (Updated April 19, 2012, 7:41 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: All prototype constructor should be [[Writable]]: true, [[Enumerable]]: 
> false, [[Configurable]]: true
> 
> 
> As said in ECMA Edition 5.1r6 - 15.1:
> 
> "Unless otherwise specified, the standard built-in properties of the global 
> object have attributes {[[Writable]]: true, [[Enumerable]]: false, 
> [[Configurable]]: true}."
> 
> And it is not otherwise specified.
> 
> 
> Diffs
> -
> 
>   kjs/interpreter.cpp cf1acf1 
> 
> Diff: http://git.reviewboard.kde.org/r/104680/diff/
> 
> 
> Testing
> ---
> 
> Confirmed by ecmascript tests checking the attributes of 
> *.prototype.constrictor with Object.getOwnPropertyDescriptor
> like
> Object.getOwnPropertyDescriptor(Date.prototype, "constructor");
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Global NaN, undefined and Infinity should be [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false

[Maks Orlovich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104678/#review12763
---

Ship it!


Ship It!

- Maks Orlovich


On April 19, 2012, 7:41 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104678/
> ---
> 
> (Updated April 19, 2012, 7:41 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Global NaN, undefined and Infinity should be [[Writable]]: false, 
> [[Enumerable]]: false, [[Configurable]]: false as defined by ecmascript 
> Edition 5.1r6 in 15.1.1.1-3
> 
> 
> Diffs
> -
> 
>   kjs/interpreter.cpp cf1acf1 
> 
> Diff: http://git.reviewboard.kde.org/r/104678/diff/
> 
> 
> Testing
> ---
> 
> Confirmed by ecmascript Object.getOwnPropertyDescriptor tests von Global NaN, 
> undefined and Infinity
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames

[Maks Orlovich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104511/#review12764
---

Ship it!


Please fix the inlining thing.

I am also not sure about the repetition of the default value for 3rd argument 
for getOwnPropertyNames all over the place. May be just drop the default 
argument entirely? That would have the bonus of making sure that the call is it 
right everywhere. (For example for the call inside the debugger it might 
actually be handy to include DontEnum properties as well..)



kjs/property_map.cpp


This needs to be inline in the header file.



- Maks Orlovich


On April 20, 2012, 11:48 a.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104511/
> ---
> 
> (Updated April 20, 2012, 11:48 a.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> KJS: Implement Object.prototypeOf, Object.keys, Object.getOwnPropertyNames
> 
> NOTE: Array was left out on purpose, as currentl imeplementation does not 
> save attributes (next patch will fix this)
> 
> keys&GetOwnPropertyNames requieres to change the 
> JSObject::getOwnPropertyNames implementation,
> for future use a enum is better than than a bool, maybe there will be more 
> ways to include/exclude properties.
> 
> All changes for khtml/ecma/ are to silense the -Woverloaded-virtual warnings
> 
> 
> Diffs
> -
> 
>   khtml/ecma/kjs_css.h aba44b8 
>   khtml/ecma/kjs_css.cpp e3e7417 
>   khtml/ecma/kjs_dom.h d0433c3 
>   khtml/ecma/kjs_dom.cpp 5fff7e3 
>   khtml/ecma/kjs_html.h 0f3f544c 
>   khtml/ecma/kjs_html.cpp e3da95c 
>   khtml/ecma/kjs_scriptable.h af5343c 
>   khtml/ecma/kjs_scriptable.cpp 5d4ea68 
>   kjs/JSVariableObject.h a8f01eb 
>   kjs/JSVariableObject.cpp b00ef76 
>   kjs/array_instance.h 3f2b630 
>   kjs/array_instance.cpp fe9b8b4 
>   kjs/function.h 3757fe8 
>   kjs/function.cpp 5f39ae6 
>   kjs/object.h 047c242 
>   kjs/object.cpp c19122f 
>   kjs/object_object.cpp 986f03f 
>   kjs/property_map.h 6b127ff 
>   kjs/property_map.cpp b2ff08e 
>   kjs/string_object.h e890d52 
>   kjs/string_object.cpp 170e2f7 
> 
> Diff: http://git.reviewboard.kde.org/r/104511/diff/
> 
> 
> Testing
> ---
> 
> ecma script & daily surfing
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: KJS/Grammar: Introduce new non-terminal IdentifierName, to handle keywords as PropertyName, in Memberexps and CallExpr

[Maks Orlovich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104243/#review12765
---


Hmm, you may have missed my reply on IRC, making this languish in the ether: I 
meant number of shift/reduce conflicts in the parser, as reported 
by bison. I am ashamed to admit that I am not able to detect LALR parsing 
ambiguities by inspection..

- Maks Orlovich


On March 12, 2012, 9:03 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104243/
> ---
> 
> (Updated March 12, 2012, 9:03 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> KJS/Grammar: Introduce new non-terminal IdentifierName,
> which allows keywords to be used as PropertyName, in Memberexps and CallExpr.
> (but not yet enum,export,extends, super, because they have the same value 
> RESERVED)
> 
> 
> Diffs
> -
> 
>   kjs/grammar.h 2a006df 
>   kjs/grammar.cpp 32dbeae 
>   kjs/grammar.y d5e835f 
> 
> Diff: http://git.reviewboard.kde.org/r/104243/diff/
> 
> 
> Testing
> ---
> 
> Tested with ecmascript262, all keyword cases pass now, except the reserved 
> ones
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Re: Review Request: kjs: Implement Array.isArray

[Maks Orlovich]

---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/104676/#review12766
---

Ship it!



kjs/array_object.cpp


Again, can just call getObject and check is vs. NULL to make this 
marginally faster.


- Maks Orlovich


On April 19, 2012, 7:41 p.m., Bernd Buschinski wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/104676/
> ---
> 
> (Updated April 19, 2012, 7:41 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Description
> ---
> 
> kjs: Implement Array.isArray
> 
> strictly to ECMA Edition 5.1 r6 - 15.4.3.2
> 
> 
> Diffs
> -
> 
>   kjs/array_object.cpp 7538ba1 
> 
> Diff: http://git.reviewboard.kde.org/r/104676/diff/
> 
> 
> Testing
> ---
> 
> ecmascript 15.4.3.2 tests
> 
> 
> Thanks,
> 
> Bernd Buschinski
> 
>

Moving libsolid-hal to unmaintained?

[Alex Fiestas]

Hello everybody!

I'm doing some bug triage on libsolid (as well of some bug fixing) and I'm 
finding that most "nasty" bugs are fault of our HAL backend (or HAL itself).

I tried to build HAL and failed on it (easy fix though) but that made me 
realize that there is no point of me fixing HAL issues on Linux because nobody 
will actually use my fixes since I will be fixing bugs using HAL-Linux not 
HAL-bsd or HAL-XXX (where we have actual users of this backend).

So real question is, who is using libsolid-hal nowdays? 

Once we know the answer to that question I will:
-Make HAL backend option only available on those platforms.
-Move libsolid-hal either to unmaintained or to a new maintainer.

Even though I will be having more KDE time from now on, I don't see a reason 
why I shuold maintain this backend, I know how it works (ervin does as well) 
so if a new maintainer step up we can mentor and help him/her.

If nobody replies in a few days I will go ahead and move libsolid-hal to 
unmantained.

Also, in the extreme case that nobody cares about it (no platforms interested 
on HAL) I will remove the backend on frameworks branch and the backend will 
not be ported to libsolid2.

Cheers !

Re: Moving libsolid-hal to unmaintained?

[Raphael Kubo da Costa]

Alex Fiestas  writes:

> So real question is, who is using libsolid-hal nowdays?

At least the BSD people are; nobody came up with a BSD implementation of
the *kit/u* stuff from Linux, so we're still using Hal.

> Once we know the answer to that question I will:
> -Make HAL backend option only available on those platforms.

Considering Linux distributions don't even ship Hal these days, doesn't
it make sense to just build it depending on whether it is present on the
system where solid is being built?

> -Move libsolid-hal either to unmaintained or to a new maintainer.

Wasn't Alberto Villa made responsible for libsolid-hal some time ago?

Re: [kde-freebsd] Moving libsolid-hal to unmaintained?

[Alberto Villa]

On Sun, Apr 22, 2012 at 4:18 AM, Raphael Kubo da Costa
 wrote:
> Wasn't Alberto Villa made responsible for libsolid-hal some time ago?

I'm not sure that was an official investiture (it was late in the
night - at Randa, do you remember Alex?)... :)

Anyway, what would maintaining mean? I can step in if it's not a big task.
Of course, I'd prefer not to have to port it to libsolid2 myself. That
would be too much given my current - and future - schedule. ;)
-- 
Alberto Villa, FreeBSD committer 
http://people.FreeBSD.org/~avilla

Re: Re: [kde-freebsd] Moving libsolid-hal to unmaintained?

[Alex Fiestas]

On Sunday, April 22, 2012 04:40:30 AM Alberto Villa wrote:
> I'm not sure that was an official investiture (it was late in the
> night - at Randa, do you remember Alex?)... :)
I do remember! but I left thinking that it was not worth because freebsd 
people were working on something new to replace hal, I guess I understood it 
wrong :/

> Anyway, what would maintaining mean? I can step in if it's not a big task.
Well, you will have to triage each libsolid-hal bug (50) see if they are still 
valid and if possible fix them. I think this will be good for kde-freebsd 
since it will give you the chance to know what is broken in hal and fix it.

> Of course, I'd prefer not to have to port it to libsolid2 myself. That
> would be too much given my current - and future - schedule. ;)
Well, if you are keeping it in good shape I will port it to libsolid2, we are 
not expecting that big change so won't be a huge task anyway.

It is offical then ! I will re-assign the bugs to you tomorrow :p