Re: STklos packaging -- status and a question
Hello,
Göran Weinholt <goran@weinholt.se> writes:
> Jeronimo Pellegrini <j_p@aleph0.info> writes:
>
>> * stklos-config embeds CFLAGS from the package build, which contains the
>> build directory
>>
>> I'm not sure what to do. stklos-config is supposed to do exactly
>> that -- return the CFLAGS used when compiling. Maybe we should not
>> include it?
>
> Hmm. It's embedded in stklos-config, which is a "pkg-config"-alike
> script that I surmise is for building applications that use stklos. And
> the problem is that it embeds this:
>
> --cflags)
> echo -g -O2 -fdebug-prefix-map=/home/weinholt/debian/scheme/stklos=. -fstack-protector-strong -Wformat -Werror=format-security
>
> I actually wouldn't think that applications want to use the C compiler
> flags that were used to build stklos itself. Try this: "grep Cflags
> /usr/share/pkgconfig/*". The most common use of Cflags on my system is
> to add an include directory (-I). The second most common is to add C
> preprocessor defines (-D). I think it makes sense to either empty out
> the response to --cflags, or possibly return just
> -I${prefix}/include/stklos.
I believe Erick Gallesio is on this mailing list. Erick, what do you think?
>> * licensing:
>>
>> should be fine, but there is a mix of GPLv3, GPLv2 and
>> SRFI (BSD-like) licensing. STklos itself is GPLv2, but SRFIs and
>> some modules have different licenses.
>> I'll be working on that.
>
> If parts are "version 2 or later" and other parts are "version 3 or
> later" it should be fine, we will then be distributing it under version
> 3. If some parts are only "version 2" then we might have a problem.
> Thanks for working on this!
It is "2 or later" and "3 or later", so there hsouldbe no problems.
Now some questions -- suppose I have a file that is released onder the
usual SRFI license, and I change parts of it and claim that I am
redistributing my changes under GPLv3 (this is actually the case).
What license may we distribute it under?
And how many lines of modifications to a prorgam would it be necessary
to say that the authorship of the modification is relevant?
>> How should we keep track of packaging issues? I see that the Gitlab
>> installation on salsa does not have the issue tracker enabled.
>> Just use the mailing list for that?
>
> We can coordinate on the list and handle the nitty-gritty in Salsa merge
> requests. Later when it's uploaded to Debian we can use the BTS, but
> I've also set the list as Maintainer:, so the list will receive
> notifications about bugs and uploads.
Okay, that's fine!
J.
Reply to: