Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-08 Thread Flavio Castelli
On 11/07/2012 10:49 PM, Ralf Jung wrote: we just had some more discussion on this in IRC, and came to the conclusion that there is no point in making an upstream release specifically for this issue. Awesome! I'll delete the v0.7.2 branch then. All we need is a guarantee that the next major

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-08 Thread Ralf Jung
Hi, All we need is a guarantee that the next major release will do the cmake stuff the same way master does it currently - then we can go ahead and update our Debian-specific patches to do the same. I guarantee next release of qjson will ship with the cmake config files that are currently

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/05/2012 08:16 PM, Lisandro Damián Nicanor Pérez Meyer wrote: Now, before we start fixing Debian or patch KDE (which is bitten by this), I'd appreciate an official statement from the developers how the cmake config file installed by the next release will look like. I don't expect any

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/06/2012 09:52 PM, Lisandro Damián Nicanor Pérez Meyer wrote: - Do not apply the aforementioned patch and reopen http://bugs.debian.org/628981 I cannot find the patch in question on the page. - Somebody writes a patch for the current stable release (0.7.1) to define the same caps in the

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi, You would basically want a 0.7.2 version which brings only the cmake config files from master. Am I right? No, a 0.7.1 version with the cmake config file from master. Or did you mean, a 0.7.2 where the only difference to 0.7.1 is the cmake file? Yeah, that, too - except that I don't know

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/07/2012 04:51 PM, Ralf Jung wrote: Or did you mean, a 0.7.2 where the only difference to 0.7.1 is the cmake file? Yes. that's what I mean. I am busy this weekend, but I should be able to find some time now and then to help testing. That would be great. BTW my plan it to release a

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Lisandro Damián Nicanor Pérez Meyer
On Wed 07 Nov 2012 12:45:44 Flavio Castelli escribió: On 11/06/2012 09:52 PM, Lisandro Damián Nicanor Pérez Meyer wrote: - Do not apply the aforementioned patch and reopen http://bugs.debian.org/628981 I cannot find the patch in question on the page. Here it is: [0] http://patch-

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Lisandro Damián Nicanor Pérez Meyer
On Wed 07 Nov 2012 13:23:11 Flavio Castelli escribió: On 11/07/2012 04:51 PM, Ralf Jung wrote: Or did you mean, a 0.7.2 where the only difference to 0.7.1 is the cmake file? Yes. that's what I mean. I am busy this weekend, but I should be able to find some time now and then to help

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/07/2012 05:26 PM, Lisandro Damián Nicanor Pérez Meyer wrote: Here it is: [0] http://patch- tracker.debian.org/patch/series/view/qjson/0.7.1-6/install_cmake_config.patch Great, I branched version 0.7.1, applied the patch and increased the patch level. The code is inside of this branch:

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi, I'm a bit skeptical about overwriting the old 0.7.1 release, that's why I chose this approach. Sure, changing a release without changing the version number is a no-go. We could have done this in Debian, increasing the Debian revision so we'd be at version 0.7.1-7 (the current one is

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/07/2012 06:07 PM, Ralf Jung wrote: However, that branch doesn't actually build here... CMake Error: File /home/r/Desktop/qjson/qjson-config.cmake.in does not exist. CMake Error at CMakeLists.txt:84 (CONFIGURE_FILE): configure_file Problem configuring file The filenames are also not the

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Flavio Castelli
On 11/07/2012 06:07 PM, Ralf Jung wrote: However, that branch doesn't actually build here... CMake Error: File /home/r/Desktop/qjson/qjson-config.cmake.in does not exist. CMake Error at CMakeLists.txt:84 (CONFIGURE_FILE): configure_file Problem configuring file I forgot to add these files.

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi, My fault, I just applied your patch and I didn't try to build! I'll look into that. The patch also adds two new files, which you probably forgot to git add. However, these are exactly the files we do *not* want. I don't know who wrote them, but they are incompatible with current QJson

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi, Me neither, this whole situation puzzles me. I just applied your debian patch. I hope that's enough for you, right? Sorry, there seems to be a misunderstanding here: The problem is that the Debian patch installs files which have variable names different from the ones in master. The patch is

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi again, now we seem to have confused you entirely, sorry :( Attached is a quick hacked-together patch. I compiled qjson, but I didn't compile anything against it because it should be reviewed anyway (and that would require me somehow crafting a debian package for this version). It's essentially

Bug#687537: [Qjson-devel] Bug#687537: QJSON cmake configuration file

2012-11-07 Thread Ralf Jung
Hi again Flavio, we just had some more discussion on this in IRC, and came to the conclusion that there is no point in making an upstream release specifically for this issue. All we need is a guarantee that the next major release will do the cmake stuff the same way master does it currently -