Re: All KDE ports need a major revbump, due to recent changes to qt4-mac

Hello, >> >> No. All ports need to be revbumped (preferrably as soon as possible). >> It's just that there were sooo many ports that revbumping all >> could not be easily done by a single person. > > OK, thanks for reassuring me here. Yes, I had started listing all the KDE ports which need

Re: [140759] trunk/dports/math/OpenBLAS

Hello, You’re right, I just updated it without thinking much, but we can get just rid of it. Fixed in r140768. Cheers, Nicolas > On Oct2, 2015, at 18:51, Ryan Schmidt wrote: > > >> On Oct 2, 2015, at 4:44 AM, ni...@macports.org wrote: >> >> Revision >> 140759 >> Author >> ni...@macports.

Re: [135592] trunk/dports/kde

Hello, Thanks for the comments. Corrected in r136059 and r136060. Cheers, Nicolas > On May6, 2015, at 17:47, Ryan Schmidt wrote: > > >> On Apr 27, 2015, at 11:55 AM, ni...@macports.org wrote: >> >> Revision >> 135592 >> Author >> ni...@macports.org >> Date >> 2015-04-27 09:55:07 -0700 (M

Re: [135138] trunk/dports/kde/kde4-workspace

I see. Corrected in r135270. Cheers, Nicolas > On Apr20, 2015, at 23:51, Joshua Root wrote: > > On 2015-4-20 20:25 , Nicolas Pavillon wrote: >> Hello, >> >>>> +#Variant made obsolete on 2015/04/16 >>>> +variant nostrip description {obsolet

Re: [135138] trunk/dports/kde/kde4-workspace

Hello, >> +#Variant made obsolete on 2015/04/16 >> +variant nostrip description {obsolete} { >> +ui_warn "You have requested an obsolete variant for a build mode that >> is now the default" >> } > > Why not just remove the variant then? What's the point of showing a warning? I agree with t

Re: [127391] trunk/dports/kde

Hello, On 27/10/2014 15:34, Ian Wadham wrote: If it will not break anything in MacPorts, let's remove the requirement for debug in Qt4. Then we will all be able to build debugging versions of KDE apps, libraries and utilities, to any required depth, using the principle Ryan has explained so well

Issue with c++11 support

Hello, When trying to upgrade akonadi, I realised that it fails on 10.8 and earlier, as it seems to require in the latest versions a full c++11 support, so that it fails with errors of the type: /opt/local/var/macports/build/_opt_mports_dports_devel_akonadi/akonadi/work/akonadi-1.13.0/server/te

Re: Calligra and Koffice [was: imake]

Hello, > As Ryan said, it is not really the duty of MacPorts developers to keep > ports alive if they are not supported upstream. KDE 3 is long since > "dead" (unmaintained) and all KDE apps dependent on KDE 3 with it. > So, do not worry about KOffice… :-( You have a fair point here. I’ll proce

Re: imake

Hello, On 29/09/2014 13:03, Brandon Allbery wrote: On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery > wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's bein

Re: KDE3

Hello, On Jun5, 2014, at 21:34, Eric Gallager wrote: > Of those ports you mention, I currently only have kchmviewer installed > on my current machine, which I installed while testing different > chm-viewing applications. I generally use the Chmox port for those > purposes now though. Are you

KDE3

Hello, This topic has been discussed some time ago on this mailing list without a real conclusion, but I am again considering the status of KDE3 on Macports. Considering that Qt5 is out and KDEF5 is soon to be released, it makes KDE3 more and more obsolete. Furthermore, it seems to not build p

Re: Why oxygen-icons port requires qt4-mac & phonon?

Hello, If I remember correctly, oxygen-icons was also using some dependencies during configurations, but I am not fully sure, and it appears that it is not the case presently. One thing is that since oxygen-icons is used in practice by ports such as kde4-baseapps, these dependencies are pulled

Re: [119727] trunk/dports/math/OpenBLAS-devel/Portfile

Hello, Thanks for the tip, I corrected it in r119753. Thankfully the hashes I encountered up to now were below the date-type version, so that I could even avoid increasing the epoch. Cheers, Nicolas On May5, 2014, at 13:55, Ryan Schmidt wrote: > > On May 4, 2014, at 21:27, ni...@macport

Re: [119433] trunk/dports/devel/akonadi/Portfile

Hello, I think there is a small misunderstanding about what I committed. You have a fully valid point, which has been discussed briefly in the ticket, but users will not be forced to change database at this stage with this commit. While the new default variant is mariadb (so that new installs

Re: [118081] trunk/dports/textproc/kakasi/Portfile

Thanks for the reminder, committed in r118095. Cheers, Nicolas On Mar22, 2014, at 8:08, Ryan Schmidt wrote: > > On Mar 21, 2014, at 04:48, ni...@macports.org wrote: > >> Revision >> 118081 >> Author >> ni...@macports.org >> Date >> 2014-03-21 02:48:58 -0700 (Fri, 21 Mar 2014) >> Log Message

Re: reinplace instruction and automatic line feeds

> Don’t do this reinplacement on binary files. > > https://trac.macports.org/ticket/35581 > Sure, that was my intent when noticing it, but I was still wondering about the best way of doing it, as filtering by file extension could have been cumbersome and possibly not reliable. I was however no

Re: reinplace instruction and automatic line feeds

On Jan6, 2014, at 1:03, Joshua Root wrote: > The reinplace proc is just a front-end to sed(1), which is a > line-oriented tool and thus the wrong choice for modifying binaries. So > yes, I'd say you need to not run it on the binaries, one way or another. All right, thanks for the info. > > A

reinplace instruction and automatic line feeds

Hello, I noticed that the “reinplace” instruction is automatically adding a line feed to files, which is causing problems with some binary files which should have a predefined length. In particular, there is a set of instructions in the kde4-1.1 portgroup which scans all files to replace an

Re: [114154] trunk/dports/math/gsl/Portfile

Thanks for the reminder. This should have been corrected in r114186 along with a forgotten test case. Cheers, Nicolas On Dec 1, 2013, at 11:51, Ryan Schmidt wrote: > > On Nov 30, 2013, at 08:50, ni...@macports.org wrote: > >> Revision >> 114154 >> Author >> ni...@macports.org >> Date >> 20

Re: [113829] trunk/dports/kde/kmix

On Nov 25, 2013, at 11:28, Ryan Schmidt wrote: > > On Nov 24, 2013, at 09:37, ni...@macports.org wrote: > >> Revision >> 113829 >> Author >> ni...@macports.org >> Date >> 2013-11-24 07:37:01 -0800 (Sun, 24 Nov 2013) >> Log Message >> >> kmix: fix build on Mavericks >> Modified Paths >> >>

Re: [113830] trunk/dports/kde/kstars

Sorry, I forgot to correct these ones after my first tests. It should be corrected in r113898 and r113899. Cheers, Nicolas > On Nov 24, 2013, at 09:39, ni...@macports.org wrote: > >> Revision >> 113830 >> Author >> ni...@macports.org >> Date >> 2013-11-24 07:39:10 -0800 (Sun, 24 Nov 2013) >>

Re: [111903] trunk/dports/kde

Hello, >> +#Clang of XCode 5 presently fails with a boost error >> +#(fatal error: recursive template instantiation exceeded maximum depth of >> 128) >> +#XCode 5.0.0 is 500.2.75 >> +compiler.blacklist {clang > 500} > > We recently fixed this same error in vigra using: > > configure.cxxflags

Re: [111442] trunk/dports/math

Hello, >> + >> +version 0.2.8 >> +github.setupxianyi OpenBLAS ${version} v > > You're meant to just put the version number into the github.setup line, i.e.: > > github.setupxianyi OpenBLAS 0.2.8 v > > This sets the name and version variables for you, as well as seve

Re: [106995] trunk/dports/aqua/qtiplot/Portfile

Hello, On Jun 14, 2013, at 3:51 PM, Ryan Schmidt wrote: > > Does this commit cause any changes in the files the port installs? If not, > the revision should not have been increased (but don't change it now). There was a ticket mentioning that qtiplot was not necessarily employing the right c

Re: Compilation issue with qt

Hello, Thank you for the patch information, it indeed seems to be exactly the same issue. However, it still seems a lot to patch qt for only one port, as also there may other unforeseen consequences, as also mentioned before. It other cases rise, then it would probably be worth. I was not aw

Compilation issue with qt

Hello, I have an issue with upgrading a port, about which I would like to ask for advice. I looked into upgrading kdevelop and its dependency kdevplatform, and ran into an issue which finally relates to Qt, apparently. In details, kdevplatform links to grantlee, which appears to have issues wi

Re: Promote octave-devel to octave?

Hello, I had taken a quick look at the octave extension, and it seems that the main issue is that most of them were not updated, as the installation way changed, so that they were kept to old versions, still compatible with the installation way provided in octave-1.0 port group. For this reas

Re: [104387] trunk/dports/kde/kde4-runtime/Portfile

> Should macports-llvm-gcc-4.2 also be blacklisted? Indeed, added in 104548. There may be others too, but I focused on the classical fallback ones. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/lis

Re: Submission: klusters

> From what I can remember, what made this possible was: >- Separate and unique naming of KDE and Qt libraries, with links such as > qt3.so > to the latest versions of the basic XXX 3 and XXX 4 libraries and > binaries. >- Separate areas in $HOME (equivalent to $HOME/Libraries/Prefe

Re: [104033] trunk/dports/kde/kdepim4-runtime/Portfile

> +if {${configure.compiler} != "clang" && ${os.platform} == "darwin"} { > +depends_build-appendport:clang-3.1 > +configure.compiler macports-clang-3.1 > +} > So... if the user asks for clang-3.2, you give them clang-3.1 instead? > > You should probably use compiler.blacklist ins

Re: KDE instructions

On Mar 6, 2013, at 2:38 AM, Joshua Root wrote: > On 2013-3-6 01:27 , Nicolas Pavillon wrote: >> Adding a mention of the +docs variant in the Wiki would anyway be an >> excellent idea. >> It is missed by many users, as it is defined in the portgroup, and thus does

Re: KDE instructions

Hello, > 1. Do we need the kde-i18n- ports? As these ports are from the kde3 suite, I would say they are as relevant as any KDE 3 port. > 2. Do we need the KDE 3 ports? > >KDE 3 is now obsolete and no longer supported by KDE. MacPorts says that >KDE 3 and KDE 4 ports "conflict". I

Re: [MacPorts] KDE modified

Hello, I wrote it a certain way to try to emphasize the necessity of performing these steps, even though it may not have been the best choice of words. I corrected it to hopefully avoid confusion. Cheers, Nicolas On Mar 5, 2013, at 1:21 PM, Jeremy Lavergne wrote: >> I think they convey t

Re: KDE instructions

, instead of repeating the same answers several times, or receive complaints because the information was not out there. Cheers, Nicolas On Mar 2, 2013, at 8:54 PM, Ian Wadham wrote: > On 02/03/2013, at 6:25 PM, Ryan Schmidt wrote: >> On Mar 2, 2013, at 01:23, Nicolas Pavil

KDE instructions

Hello, Following the discussion concerning the improvement of the display of port notes, I was also considering gathering the information for installing KDE ports somewhere. I noticed that while we have an extensive page in the wiki concerning gnome (https://trac.macports.org/wiki/GNOME), KDE

Re: [103391] trunk/dports/aqua/qtiplot/Portfile

On Feb 28, 2013, at 3:03 PM, Ryan Schmidt wrote: > > On Feb 27, 2013, at 22:03, Nicolas Pavillon wrote: >> On 28/02/2013 11:25, Ryan Schmidt wrote: >>> #Workaround as qtiplot build-phase hangs indefinitely on >>> -#Lion and higher (ticket #30761) >>&g

Re: [103391] trunk/dports/aqua/qtiplot/Portfile

On 28/02/2013 11:25, Ryan Schmidt wrote: #Workaround as qtiplot build-phase hangs indefinitely on -#Lion and higher (ticket #30761) -if {${os.major} >= 11} { +#Lion (ticket #30761) +if {${os.major} == 11} { patchfiles-append patch-disable-O2.diff } Are you sure this is based on the OS vers

Re: [103156] trunk/dports/textproc/libxls/Portfile

Hello, > This overwrites the default cflags. Is that what you want? The default for > configure.cflags is configure.optflags, whose default is -O2. So by > overwriting, you're no longer getting optimizations. You might want to append > to cflags to retain them instead. You are totally right,

Re: [102239] trunk/dports/kde/pairs/Portfile

> I'd say it's actually {GPL-2 GPL-3} at present: This seems indeed more correct than what I did. It would be also good to have a consensus on it, as it is one of the licenses now recommended for KDE softwares, even though the guidelines do not seem to be really followed in practice. > > #

Re: [102239] trunk/dports/kde/pairs/Portfile

On Jan 30, 2013, at 6:23 AM, Ryan Schmidt wrote: > > On Jan 29, 2013, at 09:50, ni...@macports.org wrote: > >> Revision: 102239 >> https://trac.macports.org/changeset/102239 >> Author: ni...@macports.org >> Date: 2013-01-29 07:50:15 -0800 (Tue, 29 Jan 2013) >> Log Message: >> ---

Re: [102036] trunk/dports/kde/kde4-baseapps/Portfile

I think it does. At least, builds are now completing without errors on the SL buildbot, and this by clearly employing the requested compiler. Here is the output of the bot: ---> Configuring kde4-baseapps [snip] -- The C compiler identification is Clang 3.1.0 -- The CXX compiler identification i

Re: [101949] trunk/dports/kde/kde4-runtime

> > Why use an old version of clang—why not clang-3.2, the latest stable version? > > It is possibly not a very good reason, but just the fact that it had been confirmed that it was working with this compiler on the ticket, while I cannot test on SL since I am not on this version anymore. Fur

Re: [101455] trunk/dports/kde/kde4-runtime

Hello, No, I don't really know. The issue seems to be limited to gcc (https://trac.macports.org/ticket/37574). Furthermore, even trying to compile the previous version (4.9.3) fails now with the same error, so that the issue may be deeper in the dependencies. The revision 1 is basically a mi

Re: [101455] trunk/dports/kde/kde4-runtime

Hello, > Is it really a typo? Q_WS_MACX used to be a valid thing. Is it not anymore? Is it ? I always encountered Q_WS_MAC and it was the first time I saw Q_WS_MACX. To be honest, there is a linking problem with the new kde-runtime that I have issues sorting out, and I strongly suspected it wa

Re: [101455] trunk/dports/kde/kde4-runtime

Hello, > Is it really a typo? Q_WS_MACX used to be a valid thing. Is it not anymore? Is it ? I always encountered Q_WS_MAC and it was the first time I saw Q_WS_MACX. To be honest, there is a linking problem with the new ode-runtime that I have issues sorting out, and I strongly suspected it wa

Make kde ports distributable

Hello, I ask again about license issues, but since it is a pretty borderline case, I prefer having other opinions. I have been looking at how to make kde ports distributable, as for now all are blocked due to a conflict between GPL and openssl license, even though packages are commonly distrib

Re: Way of determining license

Hello, Thanks for the clarification. This makes it pretty clear. Cheers, Nicolas On Dec 15, 2012, at 4:13 AM, Joshua Root wrote: > On 2012-12-15 05:29 , Nicolas Pavillon wrote: >> Hello, >> >> I was just checking some licenses on some ports, and I realised the o

Re: Way of determining license

Hello, Thanks for the clarification. This makes it pretty clear. Cheers, Nicolas On Dec 15, 2012, at 4:13 AM, Joshua Root wrote: > On 2012-12-15 05:29 , Nicolas Pavillon wrote: >> Hello, >> >> I was just checking some licenses on some ports, and I realised the o

Way of determining license

Hello, I was just checking some licenses on some ports, and I realised the one of kdelibs4 is wrong at the present time. However, I am a bit confused about determining the proper license. For now, it is set to GPL-2+, which is the most restrictive of what is contained in the codes, but it shou

Re: akonadi port needs an update!!! WAS Re: Strange mix of mysql versions during qt4-mac install

Nicolas On Dec 8, 2012, at 8:54 AM, Bradley Giesbrecht wrote: > On Dec 7, 2012, at 5:17 AM, Nicolas Pavillon wrote: > >> Hello, >> >> I just took maintainership of akonadi, so I did not yet take the time to >> look much at the port. >> >>> The akon

Re: akonadi port needs an update!!! WAS Re: Strange mix of mysql versions during qt4-mac install

Hello, I just took maintainership of akonadi, so I did not yet take the time to look much at the port. > The akonadi port should provide variants to let the user choose which of the > many mysql ports should be used to satisfy the mysql dependency—as should any > other ports depending on mysq

Re: [100228] trunk/dports/comms/telepathy-qt/Portfile

Hello, Yes, it is what it should be. Before 0.9, telepathy-qt was called telepathy-qt4, so that 0.9 is the only version for now. It is thus not a fully stable version, but it is the one required by kdenetwork4, for which I made the port. Cheers, Nicolas On Dec 6, 2012, at 10:35 AM, Ryan

Re: [99709] trunk/dports/kde

> >> +PortGroup kde4 1.1 > >> +if {![variant_isset doc]} { >> +patchfiles-append patch-CMakeLists.txt.diff >> +} > > The variant defined by the kde4-1.1 portgroup is called docs, not doc. I thought all ports were ok about this typo which was around for some time, but obviousl

Re: problem with kdecache when having muliple macports installations

Thank you for spotting that. I had indeed fully missed this part when looking up the code of dbus for making something similar. I just committed the patch given in ticket to solve this. On Oct 27, 2012, at 8:08 AM, Bradley Giesbrecht wrote: > > On Oct 26, 2012, at 3:08 PM, mk-macpo...@techno.

Re: problem with kdecache when having muliple macports installations

Thank you for spotting that. I had indeed fully missed this part when looking up the code of dbus for making something similar. I just committed the patch given in ticket to solve this. On Oct 27, 2012, at 6:18 AM, mk-macpo...@techno.ms wrote: > I am running multiple MacPorts install at the s

Re: SyCoCa - Fixing broken KDE apps

> > Shouldn't it be ${applications_dir}/KDE4? That's what the kde4-1.1 portgroup > sets the BUNDLE_INSTALL_DIR to. Exactly. I am indeed missing the final /KDE4 in the path. The version provided in the ticket https://trac.macports.org/ticket/36552 is also missing consideration for the case of

Re: SyCoCa - Fixing broken KDE apps

> > Shouldn't it be ${applications_dir}/KDE4? That's what the kde4-1.1 portgroup > sets the BUNDLE_INSTALL_DIR to. Exactly. I am indeed missing the final /KDE4 in the path. The version provided in the ticket https://trac.macports.org/ticket/36552 is also missing consideration for the case of

Re: No kdepim4 include files (.h)

> The port kdepimlibs4 contains several .h files. Are those the ones you're > looking for? This would be supposed to be the case, at least according to http://techbase.kde.org/Projects/PIM: > Much of the infrastructure of KDE PIM has been moved to kdepimlibs module as > a framework for all KDE

Re: [98693] trunk/dports/tex/kde4-kile/Portfile

It depends on how the exception is understood. As the texlive distribution on Mac comes with its own distribution of ghostcript and ImageMagick, I considered that the exception was applied to the whole package, and not only to the pure tex binaries. However, after checking, I realised that the

Re: [98044] trunk/dports/graphics/pdf2djvu

Alright, thanks for the notification, I was not aware of this subtlety. Corrected (reverted) in r98063. Cheers, Nicolas On Sep 24, 2012, at 2:51 PM, Ryan Schmidt wrote: > On Sep 23, 2012, at 21:45, ni...@macports.org wrote: > >> Revision: 98044 >> http://trac.macports.org//changeset/

Re: [95512] trunk/dports/kde

Hello, Ah, ok. Since the mismatch of variants were making a "hidden" variant doc in these ports, with the fact that users having selected the +docs variant would not get what they asked, I considered that it was worth a revbump. Sorry if that was wrong. Cheers, Nicolas On Jul 15, 2012, at

Re: [94304] trunk/dports/kde/kdevplatform

Well, there may very well be issues in what I did, as quite some issues occurred. I am also on SL with XCode 3.2, so that my testing possibilities are limited, and the changes in the Portfile are the result of the reports listed in the cited tickets. Some changes are dependent on the OS, since

Re: qt4-mac ...

n out for a few months now, so maybe that's > the correct upgrade path for Phonon to be compatible with the latest > release of Qt? I'll try to add this to my testing, once I get to that > point; I'm still fighting with Qt patches right now. - MLD > > On Apr 15,

Re: qt4-mac ...

problems during users' upgrades. Cheers, Nicolas On Apr 15, 2012, at 9:35 PM, Marko Käning wrote: > Hi Nicolas, > > On Apr 15, 2012, at 12:33 PM, Nicolas Pavillon wrote: >> When testing my different ports for compatibility with qt4.8, I noticed one >> issue when compi

Re: qt4-mac ...

Hello, When testing my different ports for compatibility with qt4.8, I noticed one issue when compiling from source. It seems that the current phonon that we have in macports does not compile with qt 4.8 and breaks during backends compilation. I could go around it for my tests by using version

Re: Modified Portfile for Octave 3.5.90 attached

Hello, If that is the path taken, I could take care of upgrade most of the octave-foo packages, as I had started a PortGroup for more recent octave packages, and thus have most of the work done already. Cheers, Nicolas > I'd suggest making an octave32 port copied from the current octave and

Re: Setting compilation parameter for qt within portfile

Hello, On Dec 3, 2011, at 6:12 AM, Ryan Schmidt wrote: > On Dec 2, 2011, at 09:33, Nicolas Pavillon wrote: > >>>> Usually you would set the optimization level using: >>>> >>>> configure.optflags -O0 >> >> I can confirm that qmake ign

Re: Setting compilation parameter for qt within portfile

Hello, Thank you a lot for the answers. >> Usually you would set the optimization level using: >> >> configure.optflags -O0 I can confirm that qmake ignores this option. In fact, I tried standard to set within the portfile (and thus through environement/configure args) cflags, cmake cflags

Setting compilation parameter for qt within portfile

Hello, The question I would like to ask is related to ticket #30761 (https://trac.macports.org/ticket/30761), in which it appears that compilation of qtiplot hangs on Lion, and that changing optimizations options from -O2 to -O0 solves the problem. The issue is that I tried to change this op

Re: Upgrade phonon

group will search for it, but I doubt that matters much). Thanks for looking into this. - MLD > > On Nov 3, 2011, at 1:12 PM, Nicolas Pavillon wrote: >> I noticed that phonon was quite behind in terms of version (4.4.2, from more >> than one year). I looked into in order to u

Upgrade phonon

Hello, I noticed that phonon was quite behind in terms of version (4.4.2, from more than one year). I looked into in order to upgrade it, but as it implies a lot of changes in the Portfile, I would prefer to have it reviewed before committing it (cf. diff file attached). It is now possible to

Re: [86145] trunk/dports/kde/kstars/Portfile

Hello, > Just deleting the dependency is probably not sufficient. You also need to > ensure that the dependency doesn't get used, even if it is already installed. Ah, ok. I was not aware of this nuance about variants, where I understood them as "I don't want the full dependencies to be install

Re: [85339] trunk/dports/aqua/qtiplot/Portfile

You are absolutely right. Sorry for the negligence. Reverted to zip distfile in r85350, as QTeXEngine is only available as zip. Cheers, Nicolas On Oct 13, 2011, at 1:10 AM, Ryan Schmidt wrote: > > On Oct 12, 2011, at 17:39, ni...@macports.org wrote: > >> Revision: 85339 >> http://

Re: Execution of shell instruction in Portfile

Thank you all for the information. I guess it shows that I should stick with the message to the user. On Oct 2, 2011, at 6:06 PM, Jeremy Lavergne wrote: >> ui_msg > > I'd recommend using `notes` instead of ui_msg, allowing the user to view the > message at any time through `port notes foo` >

Execution of shell instruction in Portfile

Hello, While preparing a new Portfile for kdevelop (ticket #14890, https://trac.macports.org/ticket/14890), I realized that it is required to run kbuildsycoca4 after installation to enable kdevelop to find the components it requires for running. Ideally, I would have wanted to run this comman

Ticket #30214

Hello, May I ask to someone with commit rights to take a look at ticket #30214 (http://trac.macports.org/ticket/30214) ? The concerned port (kile-devel) is presently broken due to missing dependencies anyway, so that it seems to me that upgrading to ensure proper use would be appropriate. Pl

Re: [81769] trunk/dports/kde/digikam/Portfile

Hello, I am probably the one who added it when listing the new ports required by digikam with the disappearance of kdegraphics4. I based the addition of dependencies on the configure log, where I saw that digikam was searching for mysql and mysql-server. Then, if a better knowledge of digika

Re: kile-devel to stable version

ticket, in order to enable a name change according to discussion if necessary. Cheers, Nicolas On Jul 7, 2011, at 1:15 AM, Ryan Schmidt wrote: > > On Jul 5, 2011, at 19:34, Nicolas Pavillon wrote: > >>> KDE4 is there and works. Yes. >>> But sometimes it doesn'

Re: kile-devel to stable version

Hello, > KDE4 is there and works. Yes. > But sometimes it doesn't. Like just now. I can't get it going anymore. > Looks like we're still in a transition phase. > There are still many people using KDE3 applications. > Since KDE3 and KDE4 can't coexist, I wouldn't like to see a KDE3 port > intenti

kile-devel to stable version

Hello, Currently, Macports holds kile in two versions, being kile for KDE3 (ver. 2.0.1), and kile-devel for KDE4 (ver. 2.1b5). Recently, kile 2.1 for KDE4 has been released as a stable package. I would thus to transfer kile to a stable port, and if I understand correctly Macports policy, I sho

Re: KDE's application path

Thanks for the answer. > Yes, as Mac OS X is a multi-user system we cannot write to the home > directory of the user as this would not make it work for all users. > > Is there no global equivalent of this preferences file? It is true that this is a problem. However, this seems to be specific to

Fwd: KDE's application path

Hello, This mail refers to ticket 28400 (http://trac.macports.org/ticket/28400), where kile does not find other KDE applications by itself, essentially for two reasons. First, KDE's applications are installed in /Applications/MacPorts/KDE4/ without any link or executable in /opt/local/bin, so

KDE's application path

Hello, This mail refers to ticket 28400 (http://trac.macports.org/ticket/28400), where kile does not find other KDE applications by itself, essentially for two reasons. First, KDE's applications are installed in /Applications/MacPorts/KDE4/ without any link or executable in /opt/local/bin, so