Wengophone is GPL licensend, which requires to provide the sources of distributed binaries for at least three years. Clearly, we don't do this with only the binary version of this application in the repository. I propose scrapping it and add a wengophone package building it from source instead.
the upstream repository provides these sources and the binary tarballs. We only proide an ebuild and not the actual source/binary tarball. Go ahead and add a source version if you can get it to build with our current boost and gcc. It is known broken with those. This bug is rally childish of you, sorry .. be more mature please.
"Gcc 4.1 and Boost 1.33.x do not play nicely together, so if your version of Boost is 1.33.x you should not use gcc 4.1. See this mailing list post for more information. If gcc 4.0 is not available on your distro, you can use gcc 3.4." copied this from http://dev.openwengo.com/trac/openwengo/trac.cgi/wiki/HowToBuildFromSource Current gcc stable and ~arch is 4.1.2 and boost 1.33.1 The newer boost is still masked: <<<<<<< # Tiziano Müller <dev-zero@gentoo.org> (01 Nov 2006) # preparing for new versions, masking snapshot dev-util/boost-build =dev-libs/boost-1.34* =dev-python/pythonmagick-0.6 >>>>>>>> I for one dont want to use a gc older than 4.1 just for building wengophone. The lternative is to use an unstable p.masked boost. It might be doable and an ebuild would be great but I do not think it is for all portage users. So really we sadly still need a binary ebuild for now :( I dislike this as much as you but I dislike using an unstable boost more .. sorry.
(In reply to comment #1) > This bug is rally childish of you, sorry .. be more mature please. > Stefan, please don't call other people childish for submitting bugs about possible license problems. I'm sure the bug was filed with the best of intentions and there's absolutely nothing childish about license violations.
(In reply to comment #3) > I'm sure the bug was filed with the best of > intentions and there's absolutely nothing childish about license violations. Yeah I am sure it was in the best intentions too - in the first moment it just felt like he was only pointing fingers at others without a real reason and a well-thought solution. Sorry for answering so impulsively at first ..
just a comment here: considering boost 1.34 is out since march, would be possibile to bump it, and try to build wengo against it? amd64 has lots of problems with -bin. i'm ready to test
(In reply to comment #5) > considering boost 1.34 is out since march, would be possibile to bump it, and > try to build wengo against it? In bug 180224 I have created an ebuild for wengophone-2.1. It seems to work well when compiled with boost-1.34_pre20061214.
