On Tuesday 12 February 2013 14:10:23 Aurélien Gâteau wrote:
> Le Wednesday 06 February 2013 23:14:59 Valentin Rusu a écrit :
> > > Thanks, I understand it better now. Assuming it was also possible to
> > > get
> > > a list of the authorized applications, I created a new revision of the
> > > mockup
On Sunday 03 February 2013 17:50:05 Andrei Sebastian Cîmpean wrote:
On Sunday 03 February 2013 16:40:04 Anders Lund wrote:
> Søndag den 3. februar 2013 14:50:33 skrev Valentin Rusu:
> Great to get rid of that extra window! What I think is why even the
> graphical representation of it? How many p
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107716/
---
(Updated March 11, 2013, 6:42 p.m.)
Status
--
This change has been ma
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107716/#review29014
---
This review has been submitted with commit
e02018941445df73187
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/107716/#review29012
---
Ship it!
Ship It!
- Albert Astals Cid
On March 11, 2013, 3:
> On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109421/
---
Review request for kdelibs.
Description
---
The download dialog corre
> On March 11, 2013, 6:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
> On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
> On March 11, 2013, 6:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/109404/#review28931
---
"I was quite clear: "qmake" must point by default to Qt 4 if Qt
> On March 11, 2013, 5:19 a.m., Andrea Scarpino wrote:
> > "I was quite clear: "qmake" must point by default to Qt 4 if Qt 4 present."
> > While qtchooser sounds like a great solution to handle this, it only adds
> > more confusion from a packager view: we cannot have N differents
> > configura
> Other alternatives include splitting kate up in the various
> library/runtime-
> support/application components but that's a lot of extra work for
> what is
> really just a kde-projects problem.
>
> Does anyone have objections to the sysadmins realigning the 3 git
> modules in
> question? (And i
13 matches
Mail list logo
