[kde-freebsd] [SVN Commit] area51/KDE/x11/kdebase4-runtime
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
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 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
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
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
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
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 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
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 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
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] Re: From a request at the Forums 2
Schaich Alonso writes: > 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. Hi there, You don't need a lot of bandwidth to help with the KDE-related ports -- you download the distfiles once and then just work on them. Documentation and user helping is something important we tend to neglect. However, since you seem to want to help with development, I can think of some other ways we could use some new blood: * Making sure upstream works fine on FreeBSD -- you can run KDE trunk and make sure it works (ie builds and runs) fine on FreeBSD; * Go through the PRs and mails in this mailing list to see if anything needs to be done on the KDE side or on the FreeBSD side. As always, you can just watch the environment for a while and pick up what you find most interesting. ___ 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
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
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
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
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 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
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
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
