gpick packaging - lemon and amalgamation

[GoogleCodeExporter]

Hi,

I'm packaging gpick for openSUSE (asked by one of our users), but I'm facing a 
tiny issue here with lemon. 

As I don't have the lemon parser available (the one built from lemon.c), I have 
2 possible ways:

1. Since lemon is only required at build time, I can attach the source and 
'hand-compile' it on the spec file. Then hack scons build process to use it 
from the local directory where I've built it.

2. Ask upstream to include the generated C files in the source tarball (like 
SQLite amalgamation[1]) does, which would make lemon only required to hack the 
grammar, but not for building the package. I believe this solution would bring 
much more value to downstreamers (ex: fedora, opensuse, gentoo, arch, etc), and 
make our life more easy. This is also the process that SQLite uses[2], in fact 
they don't really support the 'legacy' release.

Any way we can have option 2? That C generated files are included on the source 
tarball?

Nelson

[1] - http://sqlite.org/amalgamation.html
[2] - http://sqlite.org/download.html

Original issue reported on code.google.com by nmo.marques on 5 May 2011 at 5:36

[GoogleCodeExporter]

Original comment by thezbyg on 6 May 2011 at 11:22

• Changed state: Started

[GoogleCodeExporter]

Option 2 implemented (revision dd5dabd2ef)
Attached updated source tarball, if all is well I will release new Gpick 
version next week

Original comment by thezbyg on 7 May 2011 at 5:07

Attachments:

• gpick_0.2.3.tar.gz

[GoogleCodeExporter]

Hi,

The build process is perfect and works fine with this tarball. There's a tiny 
itch though, our build process runs a parser on the compiler output in the end 
and if something 'weird' happens it blocks the build process. This tarball 
poped an error:

I: Program returns random data in a function
E: gpick no-return-in-nonvoid-function source/uiListPalette.cpp:74

I can fix this by either entering the missing return or eventually by changing 
it to void (instead of boolean), though I'm not really sure on the impact as I 
haven't audited the code. I thought it was worth mentioning this to you for the 
next release :)

For the request change, it's working great, I look forward for the release, so 
I can submit then the package to Factory for openSUSE 12.1. On my test 
repository I've also made builds for Fedora 14. So if you want to point Fedora 
users to my test repo it's available. I've asked Nicu (Fedora design team 
member) to give it a ride and the feedback is positive, he even wrote a small 
article about it[1], and I've wrotten another for openSUSE News[2].

Thanks for your nice work on this and for caring with downstreamers :)

[1] - http://nicubunu.blogspot.com/2011/05/color-choosers.html
[2] - http://lizards.opensuse.org/2011/05/05/gpick-an-advanced-color-picker/

Looking forward for the next release,

Nelson

Original comment by nmo.marques on 7 May 2011 at 5:32

[GoogleCodeExporter]

Not sure if this is the right way to fix it (I really suck at coding) :)
But nothing strange seems to happen while using gpick.

Original comment by nmo.marques on 7 May 2011 at 5:47

Attachments:

• gpick-no-return-in-non-void.patch

[GoogleCodeExporter]

I was taking a look at the Ubuntu/Debian packaging and they have two minor 
patches to fix the expat linking. Since you are going to release a new update 
soon, it would probably be helpful to have this ones also included, please take 
a look at packaging on Ubuntu for this 2 patches:

* 01_expat_dependency.patch
* 02_dsolink_expat.patch

Also the licensing from this package should be: BSD, Expat and LUA Licence. If 
this is not correct please point me to the correct one.

[1] - https://launchpad.net/ubuntu/+source/gpick/0.2.3-1

Original comment by nmo.marques on 7 May 2011 at 6:14

[GoogleCodeExporter]

Fixed the no-return-in-nonvoid-function bug, the return value doesn't matter at 
the moment, but could in the future (thanks for the patch, it proves that you 
do not suck at coding :).

Made some changes based on the Ubuntu/Debian patches, a simple variable 
definition should now be enough to disable internal Expat library usage.

You missed one license, the color name list has it's own license, which looks 
like some kind of modified BSD license. The list of licenses can be found here 
http://packages.debian.org/changelogs/pool/main/g/gpick/gpick_0.2.3-1/copyright 

Original comment by thezbyg on 7 May 2011 at 7:14

[GoogleCodeExporter]

Awesome, I look forward for the next release. I've fixed the Licensing on my 
package and included the file you pointed on the documentation for gpick. Now 
everything should be in place!

By the way you can see my gpick project here where I will maintain it for 
openSUSE and Fedora (if you have someone looking for packages for RHEL, CentOS 
or Mandriva I don't mind enabling builds for them as well, just let me know).

https://build.opensuse.org/project/show?project=home:ketheriel:gpick

One more time, thanks,

Nelson

Original comment by nmo.marques on 7 May 2011 at 8:06

[GoogleCodeExporter]

Updated to new release... All went great... awesome job.
By the way if this is helpfull, tested with GCC4.6, no issues.

Feel free to close this ticket.

Original comment by nmo.marques on 16 May 2011 at 7:13

[GoogleCodeExporter]

Original comment by thezbyg on 17 May 2011 at 9:17

• Changed state: Fixed