openSUSE Packaging January 2010

packaging@lists.opensuse.org

46 participants
40 discussions

[opensuse-packaging] Help packaging a new app using vala

by Luis Medinas

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

12 years, 5 months

[opensuse-packaging] using gcc-45 in building a package on factory in opensuse buildservice

by Paul Elliott

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

12 years, 5 months

Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Marcus Meissner

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

12 years, 5 months

Re: [opensuse-factory] Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Greg KH

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

12 years, 5 months

Re: [opensuse-factory] Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Juergen Weigert

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

12 years, 5 months

Re: [opensuse-factory] Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Juergen Weigert

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

12 years, 5 months

Re: [opensuse-factory] Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Petr Baudis

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

12 years, 5 months

[opensuse-packaging] Re: One step back with devel projects

by Stephan Kulow

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

12 years, 5 months

Re: [opensuse-factory] Re: [opensuse-packaging] is ghostscript able to be updated to 8.70 was GPL v3 question

by Dave Plater

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

12 years, 5 months

[opensuse-packaging] OSB - build crashes w/ mesa 64 but not with mesa 32bit

by Tobias Burnus

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

12 years, 5 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

openSUSE Packaging January 2010