[kde-windows] [Bug 319407] Kate(part) changes filenames to lowercase
https://bugs.kde.org/show_bug.cgi?id=319407 Patrick Spendrin ps...@gmx.de changed: What|Removed |Added Status|CONFIRMED |ASSIGNED Assignee|kde-windows@kde.org |ps...@gmx.de -- You are receiving this mail because: You are the assignee for the bug. ___ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
Re: Snapshot of KDE 4.10 build environment (MinGW, 32bit)
Hi, On Sunday 05 May 2013 22:59:14 Patrick Spendrin wrote: Hm, the problem of these kind of setups is, as you noted, that you are restricted to a certain specific setup and you add the builds themselves. I propose a different solution for the future: well, as you will have guessed, my archive is mostly a by-product of setting up the build environment for myself. À la: Wow, I finally got it to work. Now let me make a backup, before I break it, again. I'm all for a clean and official solution. Basing that on a snapshot of sources, only, sounds reasonable(*). 1) we somehow store the source files make them downloadable as a complete package (e.g. winkde-tools-4.10.2.7z + winkde-win32libs-4.10.2.7z + ...) which you simply can unpack into your download directory. 2) using those packages, one can make up ones own distribution by simply making a csv file (like the ones in emerge\server\serverconfig): rkward-4.10.2.txt which contains only references to tarball targets. The (re-)build process would look like that: - - setup emerge (setting EMERGE_OFFLINE=True) - - get the source tool tarballs that were saved for that release. - - run 'emerge --list-file=rkward-4.10.2.txt' - - have the base for developing on top of KDE on Windows. Well, I am not sure I understand all implications. In this setup, would it be (easily) possible to go from such a base installation to a fully-functional emerge installation? I.e. will the sources end up in the same (relative) path as in a regular emerge setup? alternative solution: we make it possible that emerge can directly rebuild from the source packages made for the installer; this is not that easy since all patches are already applied, and some other packages simply move stuff around etc. and we only get the resulting packages. Just a thought: AFAICS, at this point of time, the main purpose of the source packages is to comply with distribution licence terms. Their practical value is rather limited (although with some determination, and willingness to apply dirty tricks, it is possible to use them as a basis for developing). So, would it make sense to re-think the source-packages, entirely? Suppose a source package would be modelled somewhat more along the lines of debian / rpm / etc. source packages. I.e. each package would contain: - a) the pristine sources in the exact same for as used by emerge - b) the portage file and patches - c) (optional) meta-data The source package would be entirely self-contained. It would simply be plugged into an existing emerge installation, and continue to work like any other port from that point onwards. (And to dream on a bit, emerge would later gain the ability to also install released binaries, mixing those with self-compiled packages all magically.) Well, point a) of the above sketch might be a bit of a problem for git- repositories due to size (modern compression tools like 7z should take care of that quite nicely, though), and read-write checkouts / clones. And of course I don't pretend to have the least idea on how difficult this scheme would be to implement, or what else it would break. Regards Thomas (*): I do think two or three pre-compiled variants (matching the settings used for creating the release binaries) would still be nice to have in the long run. But in fact, for starters, the most important point is conserving a stable snapshot that just works, and continues to work, indefinitely. signature.asc Description: This is a digitally signed message part. ___ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
Re: How do i get gettext dev for mingw
Thanks Patrick some notes below... On 06/05/2013 4:17 AM, Patrick Spendrin wrote: Am 05.05.2013 14:05, schrieb DeveloperChris: Hi When compiling mpir (my nemesis) I have run into YAP (yet another problem). My main issues are caused by an apparently buggy msys/sh.exe but not this time. I get undefined __printf__ errors when building the project, in particular when building yasm. Lol, I had those as well ;-) the gettext library (libintl) is provided by the gettext package. To make mpir compile, I edited the gettext package quite a lot and I thought I had submitted that fix: the problem is that libintl is not compiled completely, so the replacement functions for printf and vprintf are not compiled in. in one of the headers you will find that printf is redefined to __printf__ for certain cases. What I did, was simply keeping those two functions as is and modifying the ifdefs accordingly. The patch seems to have been submitted on 2nd of may, so maybe you might want to rebuild your gettext package: emerge -i gettext emerge mpir. Thanks that was successful The next problem I ran in to was not being able to find libstdc++.dll.a after much searching this link helped http://mingw.5.n7.nabble.com/libstdc-dll-a-does-not-exist-td20812.html It appears the fix is still unresolved. but as LRN advised changing library_names='libstdc++.dll.a' in libstdc++.la to library_names='' did the trick. using emerge --make mpir resulted in a completed build but not installed I tried emerge --install mpir but had no joy it obviously ran make install but that didn't seem to do anything else so mpir was not put into the db. I couldnt see how to restart a failed build. In the end I ran emerge mpir again which is still running and I hope this time completes the install. I still have issues with sh stalling, I manually have to kill the stalled sh process to get the process to continue. Out of curiosity what OS and service pack are you compiling on. I was thinking about setting up a clean xp install to see if this stall issue is something peculiar to my machine. UPDATE: it just completed - At last and only took a week! snip ... nope, that is something else. regards, Patrick Regards Developer Chris developerch...@rebel.com.au ___ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
[lokalize] [Bug 312384] Spellchecker doesn't work
Hi guys, could you try adding hunspell (+dictionaries) as a dependency for lokalize? Uninstalling it on Linux I got the same behavior. Thanks in advance. signature.asc Description: This is a digitally signed message part. ___ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
Re: How do i get gettext dev for mingw
Am 06.05.2013 15:14, schrieb DeveloperChris: Thanks Patrick some notes below... On 06/05/2013 4:17 AM, Patrick Spendrin wrote: Am 05.05.2013 14:05, schrieb DeveloperChris: Hi When compiling mpir (my nemesis) I have run into YAP (yet another problem). My main issues are caused by an apparently buggy msys/sh.exe but not this time. I get undefined __printf__ errors when building the project, in particular when building yasm. Lol, I had those as well ;-) the gettext library (libintl) is provided by the gettext package. To make mpir compile, I edited the gettext package quite a lot and I thought I had submitted that fix: the problem is that libintl is not compiled completely, so the replacement functions for printf and vprintf are not compiled in. in one of the headers you will find that printf is redefined to __printf__ for certain cases. What I did, was simply keeping those two functions as is and modifying the ifdefs accordingly. The patch seems to have been submitted on 2nd of may, so maybe you might want to rebuild your gettext package: emerge -i gettext emerge mpir. Thanks that was successful The next problem I ran in to was not being able to find libstdc++.dll.a after much searching this link helped http://mingw.5.n7.nabble.com/libstdc-dll-a-does-not-exist-td20812.html It appears the fix is still unresolved. but as LRN advised changing library_names='libstdc++.dll.a' in libstdc++.la to library_names='' did the trick. using emerge --make mpir resulted in a completed build but not installed I tried emerge --install mpir but had no joy it obviously ran make install but that didn't seem to do anything else so mpir was not put into the db. I couldnt see how to restart a failed build. there are several options from the point you were on: emerge does the following things (in that order): fetch == downloading archives, checking out git/svn repos. unpack == unpacking archives or doing nothing, depending on the sources. configure == running cmake or configure or qmake or ... make == running (n|mingw32-)make install == running (n|mingw32-)make install or moving around libraries so that they end up in a temporary install location (that is KDEROOT/build/category/package/image-) qmerge == merging the install location into the KDEROOT. so from your point, running emerge --install mpir emerge --qmerge mpir should have been enough. ;-) In the end I ran emerge mpir again which is still running and I hope this time completes the install. A second option would have been to run emerge --noclean --offline mpir which would have resulted in an uncomplete rebuild. I still have issues with sh stalling, I manually have to kill the stalled sh process to get the process to continue. Out of curiosity what OS and service pack are you compiling on. I was thinking about setting up a clean xp install to see if this stall issue is something peculiar to my machine. I am personally using win 7 pro 64bit with all three compilers (on my laptop only msvc2010). regards, Patrick ___ Kde-windows mailing list Kde-windows@kde.org https://mail.kde.org/mailman/listinfo/kde-windows
Re: Snapshot of KDE 4.10 build environment (MinGW, 32bit)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 06.05.2013 12:54, schrieb Thomas Friedrichsmeier: Hi, On Sunday 05 May 2013 22:59:14 Patrick Spendrin wrote: Hm, the problem of these kind of setups is, as you noted, that you are restricted to a certain specific setup and you add the builds themselves. I propose a different solution for the future: well, as you will have guessed, my archive is mostly a by-product of setting up the build environment for myself. À la: Wow, I finally got it to work. Now let me make a backup, before I break it, again. I'm all for a clean and official solution. Basing that on a snapshot of sources, only, sounds reasonable(*). 1) we somehow store the source files make them downloadable as a complete package (e.g. winkde-tools-4.10.2.7z + winkde-win32libs-4.10.2.7z + ...) which you simply can unpack into your download directory. 2) using those packages, one can make up ones own distribution by simply making a csv file (like the ones in emerge\server\serverconfig): rkward-4.10.2.txt which contains only references to tarball targets. The (re-)build process would look like that: - - setup emerge (setting EMERGE_OFFLINE=True) - - get the source tool tarballs that were saved for that release. - - run 'emerge --list-file=rkward-4.10.2.txt' - - have the base for developing on top of KDE on Windows. Well, I am not sure I understand all implications. In this setup, would it be (easily) possible to go from such a base installation to a fully-functional emerge installation? I.e. will the sources end up in the same (relative) path as in a regular emerge setup? Yes, they should be put simply into the download directory and are taken from that. the only difference is that they are not fetched (by switching to offline mode) and that special targets can be used (by using the --list-file option). To make this even more clear: the only things that don't exist yet, are the source+tools tarballs, the emerge side is fully functional already for that solution. alternative solution: we make it possible that emerge can directly rebuild from the source packages made for the installer; this is not that easy since all patches are already applied, and some other packages simply move stuff around etc. and we only get the resulting packages. Just a thought: AFAICS, at this point of time, the main purpose of the source packages is to comply with distribution licence terms. Their practical value is rather limited (although with some determination, and willingness to apply dirty tricks, it is possible to use them as a basis for developing). So, would it make sense to re-think the source-packages, entirely? Yes, that comes to my head from time to time. Suppose a source package would be modelled somewhat more along the lines of debian / rpm / etc. source packages. I.e. each package would contain: - a) the pristine sources in the exact same for as used by emerge - b) the portage file and patches - c) (optional) meta-data The source package would be entirely self-contained. It would simply be plugged into an existing emerge installation, and continue to work like any other port from that point onwards. Hm, a thing like that would probably need a new source type for emerge which could extract the instructions from the package, resetup the package and then the typical build instructions would happen. This should be easy to get this working for packages that do not do anything unusual, but at least for packages like Qt, this might be a problem (whenever a package overloads fetch or unpack methods). (And to dream on a bit, emerge would later gain the ability to also install released binaries, mixing those with self-compiled packages all magically.) That actually had been possible for quite a while, the problem is less about mixing those two binaries and more that our released packages are not suitable for building in a new environment because they have hardcoded paths in them. If you're curious about the occurances of these, search for paths: F:==msvc,G:==mingw32,H:==mingw64. The other point is regenerating the installation database of emerge (emerge and the kdewin-installer use different systems), but this can be handled too. Well, point a) of the above sketch might be a bit of a problem for git- repositories due to size (modern compression tools like 7z should take care of that quite nicely, though), and read-write checkouts / clones. And of course I don't pretend to have the least idea on how difficult this scheme would be to implement, or what else it would break. Well, my current goal is to have KDE releases on top of tarballed source packages, so that my builds are 100% reproduceable. Regards Thomas (*): I do think two or three pre-compiled variants (matching the settings used for creating the release binaries) would still be nice to have in the long run. But in fact, for starters, the most important point is
