[kde-freebsd] [SVN Commit] area51/KDE/x11/kdebase4-runtime

2011-03-09 Thread Max Brazhnikov
SVN commit 7028 by makc:

Fix plist by reverting partly previous commit

 M  +1 -0  pkg-plist  


___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: [SVN Commit] area51/KDE/x11/kdebase4-runtime

2011-03-09 Thread Alberto Villa
On Wednesday 09 March 2011 13:48:33 Max Brazhnikov wrote:
 SVN commit 7028 by makc:
 
 Fix plist by reverting partly previous commit

yes, i've yet to run it in tinderbox, these were only local builds. expect 
some more...
-- 
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla

Your son still sliding down the banisters?
We wound barbed wire around them.
That stop him?
No, but it sure slowed him up.


signature.asc
Description: This is a digitally signed message part.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: [SVN Commit] area51/QT

2011-03-09 Thread Max Brazhnikov
On Tue,  8 Mar 2011 16:28:11 -0800 (PST), Alberto Villa wrote:
 SVN commit 7025 by xzhayon:
 
 - Revert QT4_OPTIONS removal.
 - Add a comment to better explain why they're there.
 
 It's been a nice adventure, but I was wrong. `svn log` and KDE 4
 failing to build, plus some debugging, revealed that my solution was
 not good. But this one isn't, as well. A new one is about to be
 tested. Sorry to makc for messing his original work. :)
 
 No cookies to:me

It seems to me Gentoo has something similar to your solution. You can look 
what they do. Of course the ideal solution would be split Qt4 upstream. While 
not, I'm pretty satisfied with my workarounds :)

Max
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] [SVN Commit] area51/KDE/x11/kdebase4-workspace

2011-03-09 Thread Max Brazhnikov
SVN commit 7029 by makc:

Fix plist by reverting partly previous commit

 M  +5 -0  pkg-plist  


___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: [SVN Commit] area51/KDE/x11/kdebase4-runtime

2011-03-09 Thread Max Brazhnikov
On Wed, 9 Mar 2011 13:53:52 +0100, Alberto Villa wrote:
 On Wednesday 09 March 2011 13:48:33 Max Brazhnikov wrote:
  SVN commit 7028 by makc:
  
  Fix plist by reverting partly previous commit
 
 yes, i've yet to run it in tinderbox, these were only local builds. expect
 some more...

Some entries from kdehier4 are linked to directories under LOCALBASE, and this 
may confuse plist generators.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: [SVN Commit] area51/QT

2011-03-09 Thread Alberto Villa
On Wednesday 09 March 2011 14:28:31 Max Brazhnikov wrote:
 It seems to me Gentoo has something similar to your solution. You can 
look
 what they do.

i'll have a look, thanks!

 Of course the ideal solution would be split Qt4 upstream.

indeed i wanted to add No cookies to: Qt developers :)

 While not, I'm pretty satisfied with my workarounds :)

well, i agree, it just works for our needs
-- 
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla

There's a fine line between courage and foolishness.  Too bad it's not
a fence.


signature.asc
Description: This is a digitally signed message part.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: [SVN Commit] area51/QT

2011-03-09 Thread Alberto Villa
On Wednesday 09 March 2011 14:28:31 Max Brazhnikov wrote:
 It seems to me Gentoo has something similar to your solution.

ok, they do the very same thing. if miwi says that it's acceptable for 
portmgr to have a file which keeps changing in include/, i'll implement the 
solution (but after qt 4.7.2 commit)
-- 
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla

I never take work home with me; I always leave it in some bar along the 
way.


signature.asc
Description: This is a digitally signed message part.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] From a request at the Forums 2

2011-03-09 Thread Schaich Alonso
Hello

I've also readt the request for contributors to kde@ in the Forums. I don't 
have much bandwidth so I disqualify as packager I guess, but since I've been 
programming C/C++ for more then a decade and also frequently used Qt-4 over 
the last few years ( though, I never made own ports or kde based apps ) maybe 
there's other ways I could help.

Yours,
Schaich Alonso
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] [SVN Commit] area51/PORTS/misc/konq-plugins-kde4

2011-03-09 Thread Alberto Villa
SVN commit 7030 by xzhayon:

- Update to 4.6.1.



 M  +2 -3  Makefile  
 M  +2 -3  distinfo  
 D files (directory)  
 M  +6 -1863   pkg-plist  


___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] [SVN Commit] area51/KDE/x11/kdebase4-workspace/files

2011-03-09 Thread Alberto Villa
SVN commit 7031 by xzhayon:

- Make the wait for HAL conditional.



 M  +15 -13kdm4.in  


___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] [SVN Commit] area51/KDE/x11/kdebase4-workspace/files

2011-03-09 Thread Alberto Villa
SVN commit 7032 by xzhayon:

- Cleanup a bit.



 M  +5 -6  kdm.in  


___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: KDE 4.6.0

2011-03-09 Thread Alberto Villa
On Monday 07 March 2011 16:20:31 Olivier Smedts wrote:
 The only thing I had to do was to edit
 /usr/local/kde4/etc/rc.d/kdm4 in order to remove the recently
 introduced hal-waiting loop. I don't use hal...

i've committed a fix (yet to be tested, as i need to reinstall kde, but it 
should work fine). if you want to have a try...
-- 
Alberto Villa, FreeBSD committer avi...@freebsd.org
http://people.FreeBSD.org/~avilla

Signs of crime: screaming or cries for help.
-- The Brown University Security Crime Prevention Pamphlet


signature.asc
Description: This is a digitally signed message part.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: icon for optical disk

2011-03-09 Thread Andriy Gapon
on 26/02/2011 18:33 Andriy Gapon said the following:
 
 Very minor issue really.
 Whatever kind of optical disk I insert KDE 4 just shows its label, but never a
 nice-looking icon.
 Examples with a CD-RW disk:
 http://people.freebsd.org/~avg/cd-noicon.png
 http://people.freebsd.org/~avg/cd-noicon1.png
 TRANT r is a label of an ISO filesystem on the disk.
 
 Am I alone with this issue?

I guess that I wasn't but everyone is too busy (embarassed?) to discuss this
issue :)

So it seems that the problem is between the solid library and our hal.
In kdelibs4, in the file solid/solid/backends/hal/haldevice.cpp, there is the
function 'QString HalDevice::icon() const' that returns an icon name based on
information that hal provides about a device.
The function expects that for optical disks info.category would be volume
and info.capabilities would contain volume.disc.
But our hal gives volume.disc value in the info.category property as I can see
with lshal.  And thus the match fails and an empty icon name is returned from
the function.
I've just double-checked with OpenSUSE installation that I have and their hal
supplies the values that the solid code expects.

BTW, the similar mismatch exists also for an optical drive itself.  With linux
hal info.category is storage and info.capabilities contains storage.cdrom,
but with our hal info.category is storage.cdrom.

Not sure if the upcoming KDE 4.6.1 will be affected (i.e. if it still uses hal
backend).  But I think that our hal is still worth fixing.

Thanks!
-- 
Andriy Gapon
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information


[kde-freebsd] Re: icon for optical disk

2011-03-09 Thread Max Brazhnikov
On Thu, 10 Mar 2011 09:07:41 +0200, Andriy Gapon wrote:
 on 26/02/2011 18:33 Andriy Gapon said the following:
  Very minor issue really.
  Whatever kind of optical disk I insert KDE 4 just shows its label, but
  never a nice-looking icon.
  Examples with a CD-RW disk:
  http://people.freebsd.org/~avg/cd-noicon.png
  http://people.freebsd.org/~avg/cd-noicon1.png
  TRANT r is a label of an ISO filesystem on the disk.
  
  Am I alone with this issue?
 
 I guess that I wasn't but everyone is too busy (embarassed?) to discuss
 this issue :)

I can't remember when I used cd last time, so I just don't bother about this.

 So it seems that the problem is between the solid library and our hal.
 In kdelibs4, in the file solid/solid/backends/hal/haldevice.cpp, there is
 the function 'QString HalDevice::icon() const' that returns an icon name
 based on information that hal provides about a device.
 The function expects that for optical disks info.category would be
 volume and info.capabilities would contain volume.disc.
 But our hal gives volume.disc value in the info.category property as I
 can see with lshal.  And thus the match fails and an empty icon name is
 returned from the function.
 I've just double-checked with OpenSUSE installation that I have and their
 hal supplies the values that the solid code expects.
 
 BTW, the similar mismatch exists also for an optical drive itself.  With
 linux hal info.category is storage and info.capabilities contains
 storage.cdrom, but with our hal info.category is storage.cdrom.
 
 Not sure if the upcoming KDE 4.6.1 will be affected (i.e. if it still uses
 hal backend).  But I think that our hal is still worth fixing.

yes, Solid will continue to use hal backend on FreeBSD.
___
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information