Re: Moving Baloo forward

[viv...@gmail.com]

On 01/21/14 11:50, Vishesh Handa wrote:
> On Tuesday 21 January 2014 02:24:01 Francesco R. wrote:
>> just always use an additional database, xattrs are not the way to go.
>> Managing xattrs require a conscious user, many programs by default don't
>> even copy xattrs.
>>
> I disagree. It'll be easier to backup / restore xattr than it would be with 
> that database. Additionally, a LOT of tools do respect extended attributes 
> (cp 
> with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt 
> I can implement it with the extra database as well.
>
> Plus, with extended attributes the metadata is never lost. With the 
> additional 
> database, if the file is moved to a place which is not tracked, then the data 
> will be lost.
So we agree to disagree ;)
especially on the never lost part, when moved with kio they will be
lost, when using unix command line programs, and without special
arguments they will be lost.
Most important of all they are normally hidden, more hidden than a .dot
file, an additional database, even a .dot file is much more easy to
remember.

$ echo "Hello" > a
$ attr -s simple.attibute -V "test for xattr"  ./a
Attribute "simple.attibute" set to a 14 byte value for ./a:
test for xattr

$ kioclient cp a b
$ attr -l b


$ cp a b
$ attr -l b


$ cp -a a b
$ attr -l b
Attribute "simple.attibute" has a 14 byte value for b

$ rm b
$ rsync a b
$ attr -l b


$ rsync -X a b
$ attr -l b
Attribute "simple.attibute" has a 14 byte value for b

add tar, zip to the list


>
>>> I still have to implement this.
>> maybe start without additional metadata, but xattrs must not reach user
>> systems
>>
> Nope. I really think extended attributes is the way to go. There is also an 
> XDG standard for extended attributes [1]
>

Re: Moving Baloo forward

[viv...@gmail.com]

On 01/21/14 13:22, Vishesh Handa wrote:
> On Tuesday 21 January 2014 13:06:40 viv...@gmail.com wrote:
>> On 01/21/14 11:50, Vishesh Handa wrote:
>>> On Tuesday 21 January 2014 02:24:01 Francesco R. wrote:
>>>> just always use an additional database, xattrs are not the way to go.
>>>> Managing xattrs require a conscious user, many programs by default don't
>>>> even copy xattrs.
>>> I disagree. It'll be easier to backup / restore xattr than it would be
>>> with
>>> that database. Additionally, a LOT of tools do respect extended attributes
>>> (cp with the -a flag), in contrast Nepomuk has never copied any metadata.
>>> I doubt I can implement it with the extra database as well.
>>>
>>> Plus, with extended attributes the metadata is never lost. With the
>>> additional database, if the file is moved to a place which is not
>>> tracked, then the data will be lost.
>> So we agree to disagree ;)
>> especially on the never lost part, when moved with kio they will be
>> lost, when using unix command line programs, and without special
>> arguments they will be lost.
> When copied not moved.
even when moved, try sftp://

Other than the comment at end mail this will be my last message, I
cannot add anything else to this discussion, you and the kde developer
have all the elements needed to make a choice.
Obviously I hope xattr will not be used or they will be backed up in
some way but it's entirely your (plural) choice.

>
>> Most important of all they are normally hidden, more hidden than a .dot
>> file, an additional database, even a .dot file is much more easy to
>> remember.
>>
>> $ echo "Hello" > a
>> $ attr -s simple.attibute -V "test for xattr"  ./a
>> Attribute "simple.attibute" set to a 14 byte value for ./a:
>> test for xattr
>>
>> $ kioclient cp a b
>> $ attr -l b
>> 
>>
> kio can be modified :)

most kio need to be modified (and indeed it would be good also for other
reasons)
>> $ cp a b
>> $ attr -l b
>> 
>>
>> $ cp -a a b
>> $ attr -l b
>> Attribute "simple.attibute" has a 14 byte value for b
>>
>> $ rm b
>> $ rsync a b
>> $ attr -l b
>> 
>>
>> $ rsync -X a b
>> $ attr -l b
>> Attribute "simple.attibute" has a 14 byte value for b
>>
> Maybe we could push distros to enable the -a flag by default? Mac does it by 
> default.
it's  not -a
it's -X for rsync
it's --xattrs for tar (no short option)
it's not supported by zip (who care?)

it's a mess
And windows?

Re: Moving Baloo forward

[viv...@gmail.com]

On 01/26/14 00:38, Matthew Dawson wrote:
> On January 25, 2014 10:02:09 PM Thomas Lübking wrote:
>> On Samstag, 25. Januar 2014 21:03:44 CEST, Matthew Dawson wrote:
>>> At least for ext4, xattrs are the default mode
>> Indeed - removed user_xattr and they're still there.
>>
>> Do you happen to know when this happened? (google got me a patch suggest
>> from mid 2011 but i found no "hey heads up: xattr now default on ext4")
>>
>> Sorry for the dated information and thanks for the info),
>> Thomas
> I have no idea when it happened, as I only found out when I tried to enable 
> xattr on one of my file systems.  I was surprised by it as well.

CONFIG_EXT4_FS_XATTR is now always enabled as of 3.7. See commit
939da1084458246d2e29dd921c2012c177000e96


Linux 3.7 has been released  on 10
Dec 2012.

I don't know if simply upgrade the kernel add xattr support of mkfs is
needed

Re: Updating our tools

[viv...@gmail.com]

Il 24/09/2014 16:13, Allen Winter ha scritto:
>
> Yes that's all on my plate.
> I have it on my todo list.
> Krazy should be kde5 ready , I just need to plug it in and turn it on.
>
> I don't recall if there were any blockers, or if I simply got distracted on 
> something else.
>
> The associated changes to the techbase documentation is not on my radar.
>
>
I'm updating the ebn.k.o and api.k.o boxes (after a backup) to make it
easier, gentoo only has qt-5.3.2, if a better version is needed or if
qt-5  is not needed at all in system let me know

Re: Facebook Flint vis-à-vis Krazy

[viv...@gmail.com]

Il 02/12/2014 21:40, Allen Winter ha scritto:
> Howdy,
>
> Today I was informed that Facebook has a tool similar in concept to Krazy, 
> called Flint [1]
>
> You might want to read [1] and let me know if there are any checkers listed 
> there that
> you'd like to see added to Krazy.  Krazy already does many of the Flint 
> checks,
> but I'm interested in new ideas.
>
> [1] 
> https://code.facebook.com/posts/729709347050548/under-the-hood-building-and-open-sourcing-flint/
>
> vis-à-vis
>  in relation to; with regard to
>  as compared with; as opposed to.
Dunno if it's already done, but checking the ABI mutations between
releases would be interesting:
alas http://ispras.linuxbase.org/index.php/ABI_compliance_checker

(I'm doing this with Gentoo but yet have to add a check when upgrading
packages)

regards,
Francesco Riosa

Re: Compiler version

[viv...@gmail.com]

Il 27/06/2012 23:41, Martin Gräßlin ha scritto:

On Wednesday 27 June 2012 23:28:30 Ivan Čukić wrote:

Hi all,

I've tested the waters some time ago [1] what would people say if we
started asking for more modern compilers. I've stated there I'll start
the discussion on k-c-d once we branch out 4.9, so I'm doing as
promised. The post was only about kactivities, but the same could be
applied to more stuff.

Thanks for bringing up the issue, I actually intended to write a similar mail
tomorrow to request that applications are allowed to require compilers
supporting C++11 features.
actually for stability and feature related to c++11 gcc-4.7 is nearly 
the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for 
gcc-4.6



So +1 for a minimum requirement of gcc 4.6 or clang 3.1



diff between
http://gcc.gnu.org/gcc-4.6/cxx0x_status.html
and
http://gcc.gnu.org/gcc-4.7/cxx0x_status.html


--- cxx0x-gcc-46.txt2012-06-28 14:33:15.058728078 +0200
+++ cxx0x-gcc-47.txt2012-06-28 14:33:16.198733511 +0200
@@ -1,27 +1,27 @@
-   Status of Experimental C++0x Support in GCC 4.6
+   Status of Experimental C++11 Support in GCC 4.7

-   GCC provides experimental support for the upcoming ISO C++
-   standard, C++0x. This support can be enabled with the -std=c++0x
-   or -std=gnu++0x compiler options; the former disables GNU
-   extensions.
+   GCC provides experimental support for the 2011 ISO C++ standard.
+   This support can be enabled with the -std=c++11 or -std=gnu++11
+   compiler options; the former disables GNU extensions.

-   GCC's C++0x mode tracks the C++0x working paper drafts produced
-   by the ISO C++ committee, available on the ISO C++ committee's
+   GCC's C++11 mode implements much of the C++11 standard produced
+   by the ISO C++ committee. The standard is available from various
+   national standards bodies; working papers from before the
+   release of the standard are available on the ISO C++ committee's
web site at [1]http://www.open-std.org/jtc1/sc22/wg21/. Since
-   this standard is still being extended and modified, the feature
-   set provided by the experimental C++0x mode may vary greatly
-   from one GCC version to another. No attempts will be made to
-   preserve backward compatibility with C++0x features whose
-   semantics have changed during the course of C++0x
-   standardization.
+   this standard has only recently been completed, the feature set
+   provided by the experimental C++11 mode may vary greatly from
+   one GCC version to another. No attempts will be made to preserve
+   backward compatibility with C++11 features whose semantics have
+   changed during the course of C++11 standardization.

-   The following table lists which C++0x features are supported in
-   this release of GCC. For more information about C++0x support in
-   GCC, please see the [2]C++0x in GCC project page.
+   The following table lists which C++11 features are supported in
+   this release of GCC. For more information about C++11 support in
+   GCC, please see the [2]C++11 in GCC project page.

+--+
|Language Feature | Proposal  |  Available in  |
-   | |   |GCC 4.6?|
+   | |   |GCC 4.7?|
|-+---+|
| Rvalue references   | [3]N2118  |  Yes   |
|-+---+|
@@ -30,7 +30,7 @@
| Initialization of class objects | [5]N1610  |  Yes   |
| by rvalues  |   ||
|-+---+|
-   | Non-static data member  | [6]N2756  |   No   |
+   | Non-static data member  | [6]N2756  |  Yes   |
| initializers|   ||
|-+---+|
| Variadic templates  | [7]N2242  |  Yes   |
@@ -52,7 +52,7 @@
| New function declarator | [14]N2541 |  Yes   |
| syntax  |   ||
|-+---+|
-   | New wording for C++0x lambdas   | [15]N2927 |  Yes   |
+   | New wording for C++11 lambdas   | [15]N2927 |  Yes   |
|-+---+|
| Declared type of an expression  | [16]N2343 |  Yes   |
|-+---+|
@@ -64,7 +64,7 @@
| Solving the SFINAE problem for  | [19]DR339 |  Yes   |
| expressions |   ||
|-+---+|
-   | Template aliases| [20]N2258 |   No 

Re: Compiler version

[viv...@gmail.com]

Il 28/06/2012 16:31, Thiago Macieira ha scritto:

On quinta-feira, 28 de junho de 2012 14.38.37, viv...@gmail.com wrote:

actually for stability and feature related to c++11 gcc-4.7 is nearly
the minimum, but in my experience gcc-4.7 is still a bit rough so +1 for
gcc-4.6

That's nonsense. C++11 support in GCC 4.5 and 4.6 is just fine.



Thiago you work to qt5 which include the c++11 stuff, so probably you 
know better than rumors around, must admit that I've spoken by those 
rather than an extended experience in the field.


What made me think the rumors were true is:
a) many programs which support to be compiled with c++11 syntax require 
gcc-4.7

b) that the resolved/fixed bug list is rather long:

A search for resolved/fixed bugs with 'C++0x' or 'C++11' in the summary
580 bugs found [1]

the same search with gcc-4.7.{0,1,2} as "known to fail" is much shorter:
22 bugs found [2]

feature wise instead the increment in 4.7 seem to be short (there was a 
diff in the first mail):


Non-static data member
New wording for C++11 lambdas
Template aliases
Delegating constructors
User-defined literals
Extended friend declarations
Explicit virtual overrides

[1] 
http://gcc.gnu.org/bugzilla/buglist.cgi?order=Bug%20Number&short_desc=C%2B%2B0x%20C%2B%2B11&resolution=FIXED&cf_known_to_fail_type=anywords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=anywordssubstr&product=gcc


[2] 
http://gcc.gnu.org/bugzilla/buglist.cgi?order=Bug%20Number&short_desc=C%2B%2B0x%20C%2B%2B11&resolution=FIXED&cf_known_to_fail_type=anywords&cf_known_to_work_type=allwords&query_format=advanced&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&short_desc_type=anywordssubstr&product=gcc&cf_known_to_fail=4.7.0&cf_known_to_fail=4.7.1&cf_known_to_fail=4.7.2

Re: New lockscreen

[viv...@gmail.com]

Il 10/01/2013 21:57, Aaron J. Seigo ha scritto:
[...]

disclaimer: i am not the maintainer of this component. i have contributed some
minor things to its development. however, i'm obviously vested in the
workspace in general.

reverting is not going to happen at this point. but what i will do is spend
tomorrow (and if necessary the next day) going through the various bug reports
and fixing as many as is possible. none of them look attrociously difficult.


[...]

Aaron may I suggest to to start from Bug 310871, you already commented 
on that,

Marco do you have idea when it started to behave this way?

On my system I've had it automatically enabled (no need for a 
screenlocker here) and there is no way I can disable it.
Pay attention that it lock screen only after some time that could be 
different from the screensaver activation time.


Rationale is that user that don't need it will really hate it if forced 
to use it.



# Bug 310871 "Screen always locks (requires password) even if not 
supposed to"


Best regards and thanks for giving us the best desktop and applications 
out there.

Francesco R.