April 2020 - openSUSE Packaging - openSUSE Mailing Lists

[opensuse-packaging] Bug or mystique with set_version
by Konstantin Voinov 08 Apr '20

08 Apr '20

Hi, I've made a package which is fine with rpmbuild -bb at least. But when I try to run "osc build" locally or in OBS the "Version:" string in .spec is changing to "512x512.png" instead of "v1.10.0+git30.3277b64" for example: https://build.opensuse.org/package/show/home:kill_it/geonkick Maybe I missed something obvious, but where? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

2 2

[opensuse-packaging] Applying a fuzz to a patch
by Axel Braun 04 Apr '20

04 Apr '20

Hi, How can I apply a --fuzz=2 to a %patch0 -p1 command in a specfile? (adding the parameter does obviously not work....) Thx Axel -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

3 4

[opensuse-packaging] Re: Weird "undefined reference" only for TW x64
by Stefan Brüns 02 Apr '20

02 Apr '20

On Donnerstag, 2. April 2020 09:33:06 CEST Martin Liška wrote: > On 4/2/20 12:34 AM, Aaron Puchert wrote: > > Am 01.04.20 um 20:14 schrieb Stefan Brüns: > >> On Mittwoch, 1. April 2020 19:44:04 CEST Jason Craig wrote: > >>> The reason for that being that store() is defined "inline" in > >>> binarystoragebuffer.c. Inline means to replace the function call with > >>> the body of the function wherever it is called. This means you need to > >>> have the body of the function in the header file > >>> (binarystoragebuffer.h), not a source file. By the time the source file > >>> is compiled and linking is happening, it is too late to inline a > >>> function. > >>> > >>> So I'd guess that in the other versions gcc has ignored the inline and > >>> treated it as a normal function, whereas the Tumbleweed x86_64 has > >>> honored the inline and dropped the function from the object file. > >>> > >>> To fix it, the simplest way is to remove "inline" from the function > >>> definition. You could also move the inline definition to the header > >>> file, but as demonstrated this function is fairly unlikely to actually > >>> be inlined by the compiler. > >> > >> This seems to be a regression, as it deviates from GCCs own > >> documentation: > >> https://gcc.gnu.org/onlinedocs/gcc/Inline.html > > > > I thought so too, but looking at the standard seems to indicate that GCC > > > > is allowed to do this (http://eel.is/c++draft/dcl.inline#5): > > If a function or variable with external or module linkage is > > declared inline in one definition domain, an inline declaration > > of it shall be reachable from the end of every definition domain > > in which it is declared; no diagnostic is required. > > > > "Definition domain" is what used to be a "translation unit", the latest > > published draft [1] still uses that term. > > > > Of course GCC can provide guarantees beyond the requirements of the > > standard, if the developers want to, since "no diagnostic is required." > > Hello. > > I can only confirm what Aaron says. More details can be seen here: > https://gcc.gnu.org/onlinedocs/gcc/Inline.html > > "" > When an inline function is not static, then the compiler must assume that > there may be calls from other source files; since a global symbol can be > defined only once in any program, the function must not be defined in the > other source files, so the calls therein cannot be integrated. Therefore, a > non-static inline function is always compiled on its own in the usual > fashion. "" In a single translation unit, the compiler is free to inline some instances of a function, and keep some invocations as function calls, correct? So what contradicts keeping exactly *one* definition (in this case in binarystoragebuffer.cpp) with external linkage? This does not contradict "not be defined in the other source files". There is exactly one instance of the symbol. Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019

2 1

[opensuse-packaging] Re: Weird "undefined reference" only for TW x64
by Stefan Brüns 02 Apr '20

02 Apr '20

On Thursday, April 2, 2020 1:19:49 PM CEST Martin Liška wrote: > > Ok, can you please send a simple reproducer which we can discuss? I haven't > caught the beginning of this discussion. > > Thank you, > Martin Sure, will try. Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019

1 1

[opensuse-packaging] Re: Weird "undefined reference" only for TW x64
by Stefan Brüns 02 Apr '20

02 Apr '20

On Thursday, April 2, 2020 1:00:31 PM CEST Martin Liška wrote: > On 4/2/20 11:52 AM, Stefan Brüns wrote: > > On Donnerstag, 2. April 2020 09:33:06 CEST Martin Liška wrote: > >> On 4/2/20 12:34 AM, Aaron Puchert wrote: > >>> Am 01.04.20 um 20:14 schrieb Stefan Brüns: > >>>> On Mittwoch, 1. April 2020 19:44:04 CEST Jason Craig wrote: > >>>>> The reason for that being that store() is defined "inline" in > >>>>> binarystoragebuffer.c. Inline means to replace the function call with > >>>>> the body of the function wherever it is called. This means you need to > >>>>> have the body of the function in the header file > >>>>> (binarystoragebuffer.h), not a source file. By the time the source > >>>>> file > >>>>> is compiled and linking is happening, it is too late to inline a > >>>>> function. > >>>>> > >>>>> So I'd guess that in the other versions gcc has ignored the inline and > >>>>> treated it as a normal function, whereas the Tumbleweed x86_64 has > >>>>> honored the inline and dropped the function from the object file. > >>>>> > >>>>> To fix it, the simplest way is to remove "inline" from the function > >>>>> definition. You could also move the inline definition to the header > >>>>> file, but as demonstrated this function is fairly unlikely to actually > >>>>> be inlined by the compiler. > >>>> > >>>> This seems to be a regression, as it deviates from GCCs own > >>>> documentation: > >>>> https://gcc.gnu.org/onlinedocs/gcc/Inline.html > >>> > >>> I thought so too, but looking at the standard seems to indicate that GCC > >>> > >>> is allowed to do this (http://eel.is/c++draft/dcl.inline#5): > >>> If a function or variable with external or module linkage is > >>> declared inline in one definition domain, an inline declaration > >>> of it shall be reachable from the end of every definition domain > >>> in which it is declared; no diagnostic is required. > >>> > >>> "Definition domain" is what used to be a "translation unit", the latest > >>> published draft [1] still uses that term. > >>> > >>> Of course GCC can provide guarantees beyond the requirements of the > >>> standard, if the developers want to, since "no diagnostic is required." > >> > >> Hello. > >> > >> I can only confirm what Aaron says. More details can be seen here: > >> https://gcc.gnu.org/onlinedocs/gcc/Inline.html > >> > >> "" > >> When an inline function is not static, then the compiler must assume that > >> there may be calls from other source files; since a global symbol can be > >> defined only once in any program, the function must not be defined in the > >> other source files, so the calls therein cannot be integrated. Therefore, > >> a > >> non-static inline function is always compiled on its own in the usual > >> fashion. "" > > > > In a single translation unit, the compiler is free to inline some > > instances of a function, and keep some invocations as function calls, > > correct? > > Yes. > > > So what contradicts keeping exactly *one* definition (in this case in > > binarystoragebuffer.cpp) with external linkage? > > How do you want to achieve that without a knowledge where else will be a > header files included for other compilation units? A compiler works on > CU-level (without LTO). Because the header file does not have a definition, just the the declaration? The declaration has no "inline", so the compiler can and must assume it has the only definition, and it must emit a global symbol. It is the same as if the definition had no "inline" keyword. The compiler should mostly behave if neither declaration nor definition had the "inline" keyword, just taking it as a hint to inline in the current CU. If the other CUs had a definition, this would be a violation of the ODR. But this is always the case, no matter if inline or not. Regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen phone: +49 241 53809034 mobile: +49 151 50412019

2 1

[opensuse-packaging] bring back removed package
by Jason Craig 01 Apr '20

01 Apr '20

What's the method to bring back a package that was removed from factory but still has a devel package (i.e. that package is broken because of the bad link)? Re-create it anew, or is there some way to bring it back from factory? thanks, -- Jason Craig -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-packaging+owner(a)opensuse.org

6 7