Hi
I'm having some trouble building Tracker a desktop neutral application.
Build fails with the following message:
I: A function uses a 'return;' statement, but has actually a value
to return, like an integer ('return 42;') or similar.
W: tracker voidreturn tracker-turtle-reader.c:307
I: Program returns random data in a function
E: tracker no-return-in-nonvoid-function tracker-sparql-query.c:884,
4775, 5430, 8305, 1197
E: tracker no-return-in-nonvoid-function tracker-turtle-reader.c:460
But in fact these files are generated by valac, the vala -> C "compiler"
which means this files don't exist on the source tarball.
The spec file and the full build is available on home:lmedinas/tracker
Any guess how i can fix this ?
Thanks
Luis
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
I want to use gcc-4.5 that has been put into opensuse-factory
to build a package.
by changeing the line
BuildRequires: gcc-c++
to
BuildRequires: gcc45-c++
I was able to cause gcc45 to be loaded by opensuse-buildservice.
But the ./configure step says there is no c++ compiler:
checking for i686-pc-linux-gnu-g++... no
checking for i686-pc-linux-gnu-c++... no
checking for i686-pc-linux-gnu-gpp... no
checking for i686-pc-linux-gnu-aCC... no
checking for i686-pc-linux-gnu-CC... no
checking for i686-pc-linux-gnu-cxx... no
checking for i686-pc-linux-gnu-cc++... no
checking for i686-pc-linux-gnu-cl.exe... no
checking for i686-pc-linux-gnu-FCC... no
checking for i686-pc-linux-gnu-KCC... no
checking for i686-pc-linux-gnu-RCC... no
checking for i686-pc-linux-gnu-xlC_r... no
checking for i686-pc-linux-gnu-xlC... no
What envrionment variables or switches do I have to
put on the "./configure" and "make" lines to
make it use the alternate compiler?
I don't actually have the factory distro, I use the buildservice,
thats why I can't look at the docs.
--
Paul Elliott 1(512)837-1096
pelliott(a)BlackPatchPanel.com PMB 181, 11900 Metric Blvd Suite J
http://www.free.blackpatchpanel.com/pme/ Austin TX 78758-3117
On Mon, Jan 18, 2010 at 07:17:17AM +0200, Dave Plater wrote:
> On 01/16/2010 03:48 PM, Marcus Meissner wrote:
> > On Sat, Jan 16, 2010 at 03:33:28PM +0200, Dave Plater wrote:
> >
> >> On Fri, Jan 15, 2010 at 02:20:13PM +0200, Dave Plater wrote:
> >>
> >>
> >>>> Hi, I've come across my first license problem with ghostscript-8.70, it
> >>>> has switched to GPL v3. There are a lot of packages that depend on
> >>>> ghostscript, lilypond being one and apparently TeXLive sub packages. How
> >>>> are problems like this resolved. Having an old ghostscript version isn't
> >>>> good for attracting people to the distro. I'm totally in the dark about
> >>>> these things but as a packager I need to know about them.
> >>>>
> >>>
> >>>
> >> As long as the program calls "gs" via system it is just use and does
> >> not impose license requirements the calling programs.
> >>
> >> Most of those programs do it that way.
> >>
> >> I am not aware that ghostscript exposes libraries?
> >>
> >>
> >>>> I am not aware that ghostscript exposes libraries?
> >>>>
> >>>
> >>>
> >> Yes, it does -lgs and -lijs, package ghostscript-library
> >>
> >> The above is added for the factory list
> >>
> >> This post follows :-
> >>
> >> I have a complete gs-8.70 package waiting to be submitted but what
> >> happens in a case like this? Is ghostscript doomed to packman or even
> >> worse out of linux altogether or is there a way of sorting this issue
> >> out. Fedora already has gs-8.70, maybe they overlooked the fact that the
> >> license had changed. It would take a few linux distros to make the
> >> ghostscript people change back to v2.
> >> List of affected files, I can find :-
> >> Uses gs_lib : capi4hylafax, hylafax
> >>
> > Those will just call the binary, so it is "use".
> >
> >
> >> Uses pstoraster : gutenprint
> >>
> > same.
> >
> >
> >> Uses libgs.so : foomatic-filters, libspectre1
> >> Uses libijs.so: gutenprint
> >>
> > foomatic-filters is GPLv2 or later (so I think it can use GPLv3 libraries).
> > libspectre same.
> > gutenprint same.
> >
> > I will try to find a verbal statement from our license guys next week, but
> > to my not so trained eyes it looks fine to do.
> >
> > Ciao, Marcus
> >
> >
> I've done some research and gnu.org has a chart which states that GPLv2
> only, take note they specify only so I'm not sure if the license needs
> to state only, is incompatible with any GPLv3 or LGPLv3 license.
> Libspectre is fine because it has a statement in it's README that says
> "GPLv2 or later" which is compatible. Foomatic-filters on the other hand
> doesn't state anything other than "copyright (C) 1994, 1995, 1996, 1999,
> 2000, 2001, 2002, 2004, 2005 Free Software Foundation, Inc." and has a
> copy of GPLv2, so whether this implies later or only is something for
> the legal department. Looking at the chart GPLv2 only isn't 100%
> compatible with any other license. Foomatic-filters cannot exist without
> libgs so if there is a problem they need to address it.
> Regards
> Dave P
The sources of foomatic-filters have a copy of COPYING as only indication of
its license. This COPYING file suggests "GPL v2 or later" and as the
individual sources files do not have copyright headers this mentioning
applies. The author should put COPYING headers as suggested in his .c and .h
files of course.
foomatic-filters has:
License: GPL v2 or later
in its RPM header. This also matches the internal license scan results.
I talked to our license guys and for "GPL v2 or later" using gs in GPL
v3 mode is fine. If those in turn provide libraries, they are however
GPL v3 after compilation.
So foomatic-filters is fine to use with the libgs library.
Ciao, Marcus
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Tue, Jan 19, 2010 at 03:07:06PM +0100, Joerg Schilling wrote:
> Juergen Weigert <jw(a)suse.de> wrote:
>
> > The cases where upstream exploited GPLv2 / GPLv3 incompatibilities on
> > purpose are very rare, luckily.
> > The incompatibility is often avoided by licensing under "GPLv2 or GPLv3 at
> > your choice", which is perfect for the needs of a distributor.
>
> There are a lot of project that use "GPLv2 onnly" and there are a lot of
> projects that use GNU libreadline. This is where I expect the highest
> probability for a problem.
Almost all of these types of projects have already been notified by the
distros, and there are a number of easy solutions for it, shipping
readline-5 being the most obvious.
If you know of any that have not been notified, please let me know.
thanks,
greg k-h
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Jan 19, 10 11:51:45 +0100, Joerg Schilling wrote:
> Dave Plater <dplater(a)webafrica.org.za> wrote:
> > There's one aspect of ghostscript-8.70 that I don't quite know what to
> > put in the License: part ghostscript-omni is built from Omni which is
> > LGPLv2.1 or later. The gnu chart states that one is allowed to convert
> > LGPLv2.1 or later into GPLv3 and from that I would understand that
> > either all references to LGPLv2.1 must be removed or it's alright to
> > simply put the licence in as GNUv3.
>
> The LGPL is very obvious with claiming that such a change is unrevocable for the
> master copy of a distributor. So if a distributor _really_ makes such a change,
> it cannot ship at the same time any software that needs the library under LGPL.
I don't follow down that road. We don't need to have the concept of a
master copy. A distributor can have identical copies of code in different
packages with different license tags on it. Not very helpful, but perfectly
legal.
And: Whatever a packager says about the license, may not even be be the
ultimate truth from an end-users perspective. Packager cannot revoke
end-users rights either.
cheers,
JW-
--
o \ Juergen Weigert paint it green! __/ _=======.=======_
<V> | jw(a)suse.de back to ascii! __/ _---|____________\/
\ | 0911 74053-508 __/ (____/ /\
(/) | _____________________________/ _/ \_ vim:set sw=2 wm=8
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Jan 19, 10 11:30:00 +0100, Joerg Schilling wrote:
> Dave Plater <davejplater(a)gmail.com> wrote:
>
> > the legal department. Looking at the chart GPLv2 only isn't 100%
> > compatible with any other license. Foomatic-filters cannot exist without
> > libgs so if there is a problem they need to address it.
>
> Not only GPLv2 is incompatible with any other licenses, GPLv3 is also
> incompatible even with GPLv2. I expect a lot of trouble for distributors
> in the near future because of this fact....
The cases where upstream exploited GPLv2 / GPLv3 incompatibilities on
purpose are very rare, luckily.
The incompatibility is often avoided by licensing under "GPLv2 or GPLv3 at
your choice", which is perfect for the needs of a distributor.
I don't share that kind of fear.
cheers,
JW-
--
o \ Juergen Weigert paint it green! __/ _=======.=======_
<V> | jw(a)suse.de back to ascii! __/ _---|____________\/
\ | 0911 74053-508 __/ (____/ /\
(/) | _____________________________/ _/ \_ vim:set sw=2 wm=8
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On Tue, Jan 19, 2010 at 12:19:50PM +0100, Joerg Schilling wrote:
> Dave Plater <davejplater(a)gmail.com> wrote:
>
> > If they add "or later" to their licensing statement their problem dissapears, I've noticed that the top of the chart in gnu.orgs faq only
> > has a column for GPLv3 or later and LGPLv3 or later. Omni's license is LGPLv2.1 or later and it is included in the build of the ghostscript
> > (GPLv3) package's ghostscript-omni, what do I put in the spec file under License:, "GPLv3" or "LGPLv2.1 or later"
>
> The problem is that the German law (and probably all European law systems as
> well) forbid you to sign a contract where you don't know the conditions at the
> time you sign.
But GPL is a licence, not a contract. Does this still apply? I wonder
if the distinction is even meaningful in European law.
It would be great to read some article by a lawyer on this, it's an
interesting aspect I've never thought of before.
Petr "Pasky" Baudis
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hi,
As I no longer have the original thread in my mail folder, I'm
hoping you take a link to the archive :)
http://lists.opensuse.org/opensuse-packaging/2009-09/msg00156.html
As discussed last year, openSUSE: is reserved for "official" repos,
so adrian created devel:openSUSE:Factory and it's free for all
packages whose maintainers do not feel their package as fit into
any of the other devel projects.
This project is different to the other devel projects:
- it has no topic, the only thing the packages in there have
in common are that they are branches of openSUSE:Factory packages
- if you have a package in there, you can add as many co-maintainers
as you wanted, but only on a package level, the project itself
will be maintained by me (and hopefully some other brave souls).
I only created one repository: the snapshot repo of O:F - if that's
not enough for your package, its clearly not a candidate.
So feel free to send the submit requests.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
On 01/19/2010 12:30 PM, Joerg Schilling wrote:
> Dave Plater <davejplater(a)gmail.com> wrote:
>
>> the legal department. Looking at the chart GPLv2 only isn't 100%
>> compatible with any other license. Foomatic-filters cannot exist without
>> libgs so if there is a problem they need to address it.
>
> Not only GPLv2 is incompatible with any other licenses, GPLv3 is also
> incompatible even with GPLv2. I expect a lot of trouble for distributors
> in the near future because of this fact....
>
> Jörg
>
If they add "or later" to their licensing statement their problem dissapears, I've noticed that the top of the chart in gnu.orgs faq only
has a column for GPLv3 or later and LGPLv3 or later. Omni's license is LGPLv2.1 or later and it is included in the build of the ghostscript
(GPLv3) package's ghostscript-omni, what do I put in the spec file under License:, "GPLv3" or "LGPLv2.1 or later"
Regards
Dave P
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org
Hello all,
I have a problem with using Mesa's glLightfv with the 64bit version of
Mesa, it works with mesa-32bit on x86-64. It happens with XCrySDen (
http://software.opensuse.org/search?baseproject=ALL&p=1&q=xcrysden )
which crashes with the x86_64 rpm but works with the i586 one.
I am seeking an opinion to whom (xcrysden, mesa, mesa@ bugzilla.n.c) I
should report the bug and how to diagnose it further.
The code in question fails on x86-64 openSUSE Factory with
/usr/bin/xcrysden: line 217: 7177 Segmentation fault
The dump (running "xcrysden -d" and calling "bt" in gdb) gives:
#0 0x0000000000000000 in ?? ()
#1 0x000000000043e693 in LoadLights () at lighting.c:408
The line in question is
408 glLightfv(_LIGHT[il], GL_AMBIENT, light[il].ambient);
and the values look OK:
(gdb) p il
$1 = 0
(gdb) p _LIGHT[0]
$2 = 16384
(gdb) p light[il].ambient
$4 = {0.00999999978, 0.00999999978, 0.00999999978, 1}
Which also seems to match the specs at
http://www.opengl.org/sdk/docs/man/xhtml/glLight.xml
Thanks for suggestions!
Tobias
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org