On Thu, May 29, 2014 at 8:08 AM, Marko Käning mk-li...@email.de wrote:
Hi Ben,
Hi Olivier,
Hi Marko,
On 28 May 2014, at 08:48 , Ben Cooksley bcooks...@kde.org wrote:
Hmm. What about Application Support which kdoctools appears to use?
as documented on [1] I have reconfigured the KDE/CI
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118366/
---
(Updated May 29, 2014, 7:53 a.m.)
Review request for kde-workspace, KDE
On May 28, 2014, 6:10 a.m., Martin Gräßlin wrote:
kcms/keyboard/kcmmisc.cpp, lines 77-78
https://git.reviewboard.kde.org/r/118366/diff/2/?file=275630#file275630line77
for new connects I would use the new compile time checked syntax.
I tried it but it was giving some error unable to
On 29/05/14 08:05, Ben Cooksley wrote:
On Thu, May 29, 2014 at 8:08 AM, Marko Käning mk-li...@email.de wrote:
Could not locate file kf5/kdoctools/customization in
(/Users/kdeci/Library/Application Support, /Library/Application Support)
---
which leaves me a little puzzled now.
It is
On May 12, 2014, 3:16 p.m., Kevin Ottens wrote:
examples/bzip2gzip/main.cpp, line 74
https://git.reviewboard.kde.org/r/117974/diff/1/?file=271400#file271400line74
Maybe a better idea to use a loop to avoid the readAll? I know that's
an example which needs to be kept simple, but
On May 5, 2014, 7:17 a.m., Kevin Ottens wrote:
IIRC that was intentional as to not have kjs depend on kdoctools.
Hrm. Distros like Debian aren't going to be super-happy about this. And KJS is
officially a porting aid, so I'm not sure bumping it to tier 3 is that big of
an issue (especially
On May 14, 2014, 2:24 p.m., David Faure wrote:
It is correct that this is about a string representation of the filesize,
to displaying in a column of the model.
For machine processing one can use KFileItem::size() after getting the
KFileItem out of the KDirModel.
However, do we
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118155/#review58704
---
Ship it!
Builds and tests pass for me on Linux. I think we
On April 11, 2014, 4:46 p.m., Commit Hook wrote:
This review has been submitted with commit
e898d13b430692e775060d49342181192e122fdf by Hrvoje Senjan to branch master.
Hrvoje Senjan wrote:
i've reverted the commit now. capabilities break LD_LIBRARY_PATH, so this
is a no-go.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117125/#review58706
---
What's the plan with this? Does Andreas' fix for the setuid
On May 16, 2014, 11:49 a.m., Alex Merry wrote:
This sounds like an issue that needs to be fixed in KArchive...
Where, exactly, were the files appearing? And which files were appearing there?
- Alex
---
This is an automatically
Ben Cooksley ha scritto:
On Thu, May 29, 2014 at 8:08 AM, Marko Käning mk-li...@email.de wrote:
Hi Ben,
Hi Olivier,
Hi Marko,
On 28 May 2014, at 08:48 , Ben Cooksley bcooks...@kde.org wrote:
Hmm. What about Application Support which kdoctools appears to use?
as documented on [1] I
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118389/
---
Review request for KDE Frameworks, David Faure and Mark Gaiser.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118389/
---
(Updated May 29, 2014, 12:52 p.m.)
Review request for KDE Frameworks,
On May 29, 2014, 2:11 p.m., Alex Merry wrote:
What's the plan with this? Does Andreas' fix for the setuid case also fix
the capabilities case?
Does Andreas' fix for the setuid case also fix the capabilities case?
yep. i was able to successfully start and use plasma next (with KF5 in /usr,
On April 11, 2014, 6:46 p.m., Commit Hook wrote:
This review has been submitted with commit
e898d13b430692e775060d49342181192e122fdf by Hrvoje Senjan to branch master.
Hrvoje Senjan wrote:
i've reverted the commit now. capabilities break LD_LIBRARY_PATH, so this
is a no-go.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117125/#review58714
---
Ship it!
Given that the original issue seems to be fixed, I
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117125/
---
(Updated May 29, 2014, 3:14 p.m.)
Review request for KDE Frameworks,
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118389/#review58716
---
src/core/udsentry.cpp
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118211/
---
(Updated May 29, 2014, 1:52 p.m.)
Review request for KDE Frameworks and
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118377/
---
(Updated May 29, 2014, 1:59 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118384/
---
(Updated May 29, 2014, 2:01 p.m.)
Review request for KDE Frameworks and
On Thu, May 29, 2014 at 12:21 AM, Aaron J. Seigo ase...@kde.org wrote:
On Wednesday, May 28, 2014 21:12:43 Mark Gaiser wrote:
You've written that with the assumption of backwards compatibility.
It's a nice idea, but why should we even try to remain backwards
compatible?
The question should
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118384/
---
(Updated May 29, 2014, 2:35 p.m.)
Review request for KDE Frameworks and
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118389/
---
(Updated May 29, 2014, 2:38 p.m.)
Status
--
This change has been
On May 26, 2014, 8:11 a.m., Àlex Fiestas wrote:
src/platformtheme/CMakeLists.txt, line 4
https://git.reviewboard.kde.org/r/118234/diff/1/?file=273903#file273903line4
This workaround is quite important for 5.3.0 and older at least, maybe
in those cases we should make it mandatory?
On May 26, 2014, 8:57 a.m., Alex Merry wrote:
Looks correct. I suggest running the validate_metainfo.rb script from
kde-dev-scripts/frameworks on it before pushing it, though.
I just did this, BTW, and it passes fine.
- Alex
---
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118340/#review58731
---
This doesn't look great to me.
We'd have to release another
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118340/#review58733
---
Did you try compiling this? Because that macro doesn't exist
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118362/#review58734
---
Ship it!
Ship It!
- Alex Merry
On May 27, 2014, 7:49
On May 29, 2014, 3:02 p.m., Alex Merry wrote:
Did you try compiling this? Because that macro doesn't exist any more -
there is an ecm_optional_add_subdirectory() in ECM if you
include(ECMOptionalAddSubdirectory), though.
However, I think an explicit option(), with a useful
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117125/#review58742
---
This review has been submitted with commit
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117125/
---
(Updated May 29, 2014, 3:55 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118403/
---
Review request for KDE Frameworks.
Repository: kdelibs4support
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118404/
---
Review request for KDE Frameworks.
Repository: kross
Description
On May 29, 2014, 10:57 a.m., David Edmundson wrote:
This doesn't look great to me.
We'd have to release another 4.x.
Is this too big for the KDE 4.13.x releases? It doesn't change the default
behaviour, and as discussed in: https://git.reviewboard.kde.org/r/115602/ ,
this is the only
On May 29, 2014, 11:02 a.m., Alex Merry wrote:
Did you try compiling this? Because that macro doesn't exist any more -
there is an ecm_optional_add_subdirectory() in ECM if you
include(ECMOptionalAddSubdirectory), though.
However, I think an explicit option(), with a useful
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/
---
(Updated May 29, 2014, 7 p.m.)
Review request for KDE Frameworks and
Hi Ben,
Hi Olivier,
On 28 May 2014, at 08:48 , Ben Cooksley bcooks...@kde.org wrote:
Hmm. What about Application Support which kdoctools appears to use?
as documented on [1] I have reconfigured the KDE/CI system along the lines of
the recent
discussion on this thread and rebuilt kconfig and
Hi Luigi,
I'm not sure about this. KDocTools relies on QStandardPaths to find resources
in common paths; our Windows developers hacked QStandardPaths.
You can take a look in the discussion of the RR I mentioned many times:
https://git.reviewboard.kde.org/r/115752/
yep, I know this one and
On 28 May 2014, at 13:09 , Alex Merry alex.me...@kde.org wrote:
configureExtraArgs=-DCMAKE_INSTALL_BUNDLEDIR=“Applications”
I have used
---
configurePlatformArgs=-DCMAKE_INSTALL_BUNDLEDIR=Applications/KF5”
---
since I wanted to keep all KF5 apps in another directory than the usual
applications.
Hi, I just noticed that Kross is marked as porting aid in
KF5. Since I am pondering to use Kross for a Qt5/KF5
app, I wonder if that would be a future-proof decision.
Is there a technical reason (like a successor or a
competing framework) why it got to the porting aids? Or
is it simply the
Hi Ben,
On 29 May 2014, at 09:05 , Ben Cooksley bcooks...@kde.org wrote:
It is nothing to do with the installation parameters now. What needs
to be adjusted is kdoctools - we'll need to help it find things within
the install prefix. Is there a environment variable which we can set
which the
On 27 May 2014, at 06:51 , Matthew Dawson matt...@mjdsystems.ca wrote:
I'd consider kconfig_compiler a developer tool, similar to Google's protocol
buffer compiler. Where do such tools belong in the OSX world?
I’m currently using
---
$ cat ~/scripts/config/build/kconfig/darwin-mavericks.cfg
Hi Ben,
On 29 May 2014, at 09:05 , Ben Cooksley bcooks...@kde.org wrote:
In terms of the value of DATA_INSTALL_DIR, I suggest you examine the
install jail (located at $WORKSPACE/install/) to determine where the
files are actually being placed and act accordingly.
Those files go into share/kf5
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/118128/#review58752
---
hehehe, that's quite a change.
This will keep sorting happy.
As far as I can tell, having seen kross grow up a decade ago, kross
basically has been unmaintained for, like, five years now. It's wonderful
technology, though.
On Tue, 27 May 2014, Andreas Cord-Landwehr wrote:
Hi, I just noticed that Kross is marked as porting aid in KF5. Since I am
On Tue, May 27, 2014 at 1:24 PM, Andreas Cord-Landwehr cordlandw...@kde.org
wrote:
Hi, I just noticed that Kross is marked as porting aid in KF5. Since I
am pondering to use Kross for a Qt5/KF5 app, I wonder if that would be a
future-proof decision.
Is there a technical reason (like a
Hi all,
Going to respond to everything in one email.
to kdoctools’ search path on the KDE/CI system.
Question is, how to achieve it?
Will we indeed have to patch its sources?
Patching of the sources by the CI system is considered unacceptable
for KDE projects. Particularly as these are
49 matches
Mail list logo
