[build failure] package dmraid

RubenKelevra commented

2022-05-16 19:38:29 +02:00

Contributor

The dmraid package fails because of the flag "-Werror=format-security". While it is set by default, it doesn't build with it set.

Log part of the issue:

events/libdmraid-events-isw.c: In function ‘_log_either’:
events/libdmraid-events-isw.c:827:17: error: format not a string literal and no format arguments [-Werror=format-security]
  827 |                 syslog(LOG_ERR, msg[0]);
      |                 ^~~~~~
events/libdmraid-events-isw.c:833:17: error: format not a string literal and no format arguments [-Werror=format-security]
  833 |                 syslog(LOG_ERR, msg[1]);

Is this a thing we can work around or do we ask the maintainer/the project to fix it?

The dmraid package fails because of the flag "-Werror=format-security". While it is set by [default](https://gitlab.archlinux.org/archlinux/devtools/-/blob/master/makepkg-x86_64.conf), it doesn't build with it set. Log part of the issue: ``` events/libdmraid-events-isw.c: In function ‘_log_either’: events/libdmraid-events-isw.c:827:17: error: format not a string literal and no format arguments [-Werror=format-security] 827 | syslog(LOG_ERR, msg[0]); | ^~~~~~ events/libdmraid-events-isw.c:833:17: error: format not a string literal and no format arguments [-Werror=format-security] 833 | syslog(LOG_ERR, msg[1]); ``` Is this a thing we can work around or do we ask the maintainer/the project to fix it?

RubenKelevra commented

2022-05-16 19:42:41 +02:00

Author

Contributor

Also the GCC calls look extremly messy with -O2 set 4 times while we set -O3 one time. Not sure we're building really with -O3 in the end.

gcc -o register/dmreg.o -c -I. -I../include -I../lib -include ../include/config.h  -march=x86-64-v3 -O3 -falign-functions=32 -pipe -fno-plt -fexceptions         -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security         -fstack-clash-protection -fcf-protection -flto -O2 -fPIC -Wall -Wundef -Wcast-align -Wwrite-strings -Winline -DDMRAID_AUTOREGISTER -O2 -O2 -fPIC -Wall -Wundef -Wcast-align -Wwrite-strings -Winline -DDMRAID_AUTOREGISTER -O2 register/dmreg.c

Also the GCC calls look extremly messy with -O2 set 4 times while we set -O3 one time. Not sure we're building really with -O3 in the end. ``` gcc -o register/dmreg.o -c -I. -I../include -I../lib -include ../include/config.h -march=x86-64-v3 -O3 -falign-functions=32 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -flto -O2 -fPIC -Wall -Wundef -Wcast-align -Wwrite-strings -Winline -DDMRAID_AUTOREGISTER -O2 -O2 -fPIC -Wall -Wundef -Wcast-align -Wwrite-strings -Winline -DDMRAID_AUTOREGISTER -O2 register/dmreg.c ```

RubenKelevra commented

2022-05-16 19:52:02 +02:00

Author

Contributor

So this is kind of a general request for guidance. How can I help to improve this? Do we need to report this to the project? Is it normal to just "work around" it and remove the flag for this one package? I mean I don't think it can be build atm without removing the flag.

anonfunc commented

2022-05-20 17:22:59 +02:00

Owner

Some projects force a certain level of optimization, which we should not touch. About -Werror=format-security: That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end.

Some projects force a certain level of optimization, which we should not touch. About `-Werror=format-security`: That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end.

anonfunc added the

question

label 2022-05-20 17:23:09 +02:00

RubenKelevra commented

2022-05-21 19:30:33 +02:00

Author

Contributor

Some projects force a certain level of optimization, which we should not touch.

I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now.

If nobody tries, nobody will know that for sure :D

That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end.

No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss?

With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around?

So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch.

And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)?

> Some projects force a certain level of optimization, which we should not touch. I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now. If nobody tries, nobody will know that for sure :D > That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end. No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss? With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around? So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch. And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)?

anonfunc commented

2022-05-22 17:11:44 +02:00

Owner

Some projects force a certain level of optimization, which we should not touch.

I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now.

If nobody tries, nobody will know that for sure :D

Certainly, but I see no way to do this besides patching makefiles (or whatever the respective project is using). First we had to detect the buildsystem in use, then we would have to (in a brute-force variant) replace all -On? Well, certainly not very elegant. If you can came up with something more sophisticated I'm all ear. Even detecting the buildsystem would take some work, on the other hand this could play into #124.

That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end.

No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss?

With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around?

In an ideal world, yes. Some PKGBUILDs do not get touched for some time, and things change, new compiler versions come in, etc.

So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch.

And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)?

The correct way would be to use the bugtracker, at least if it's fixable by the Arch maintainer. If this needs to be fixed in the upstream project itself, then the upstream bugtracker it is. You can certainly open a bug in both if you want (linking to upstream issue).

> > Some projects force a certain level of optimization, which we should not touch. > > I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now. > > If nobody tries, nobody will know that for sure :D > Certainly, but I see no way to do this besides patching makefiles (or whatever the respective project is using). First we had to detect the buildsystem in use, then we would have to (in a brute-force variant) replace all `-On`? Well, certainly not very elegant. If you can came up with something more sophisticated I'm all ear. Even detecting the buildsystem would take some work, on the other hand this could play into #124. > > That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end. > > No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss? > > With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around? > In an ideal world, yes. Some PKGBUILDs do not get touched for some time, and things change, new compiler versions come in, etc. > So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch. > > And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)? The correct way would be to use the bugtracker, at least if it's fixable by the Arch maintainer. If this needs to be fixed in the upstream project itself, then the upstream bugtracker it is. You can certainly open a bug in both if you want (linking to upstream issue).

RubenKelevra commented

2022-05-22 19:02:10 +02:00

Author

Contributor

Some projects force a certain level of optimization, which we should not touch.

I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now.

If nobody tries, nobody will know that for sure :D

Certainly, but I see no way to do this besides patching makefiles (or whatever the respective project is using). First we had to detect the buildsystem in use, then we would have to (in a brute-force variant) replace all -On? Well, certainly not very elegant. If you can came up with something more sophisticated I'm all ear. Even detecting the buildsystem would take some work, on the other hand this could play into #124.

Yeah the shim would see all flags beeing send to the compiler and could modify all of them. So we could filter out all "-O2"s and set a single -O3 for example. There's no need to know or understand the build system, as it would just modify the calls at the end of the line going to the compiler.

Here's an example how this looks like (the code is from the yaourt project). :)

https://github.com/RubenKelevra/pacman.store/blob/master/pacman%20wrapper/for-bashrc.sh

That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end.

No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss?

With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around?

In an ideal world, yes. Some PKGBUILDs do not get touched for some time, and things change, new compiler version come in, etc.

Ah okay. I thought they would get a new pkgrel if one of the dependencies/build tools is upgraded.

So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch.

And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)?

The correct way would be to use the bugtracker, at least if it's fixable by the Arch maintainer. If this needs to be fixed in the upstream project itself, then the upstream bugtracker it is. You can certainly open a bug in both if you so want to (linking to upstream issue).

Okay, good to know :)

> > > Some projects force a certain level of optimization, which we should not touch. > > > > I feel like that might just be historic, like forcing a higher optimizasion but GCC instroduced a more stable -O3 so it could in theory be build with a higher optimization now. > > > > If nobody tries, nobody will know that for sure :D > > > > Certainly, but I see no way to do this besides patching makefiles (or whatever the respective project is using). First we had to detect the buildsystem in use, then we would have to (in a brute-force variant) replace all `-On`? Well, certainly not very elegant. If you can came up with something more sophisticated I'm all ear. Even detecting the buildsystem would take some work, on the other hand this could play into #124. Yeah the shim would see all flags beeing send to the compiler and could modify all of them. So we could filter out all "-O2"s and set a single -O3 for example. There's no need to know or understand the build system, as it would just modify the calls at the end of the line going to the compiler. Here's an example how this looks like (the code is from the yaourt project). :) https://github.com/RubenKelevra/pacman.store/blob/master/pacman%20wrapper/for-bashrc.sh > > > That should be handled by upstream Arch. If we begin to modify PKGBUILDS for something like that we'll never see the end. > > > > No, I didn't want to ask if we should introduce a patchset locally. It's more a: What did I miss? > > > > With a standard arch installation, shouldn't then all PKGBUILDs of Arch "just build" without tinkering around? > > > > In an ideal world, yes. Some PKGBUILDs do not get touched for some time, and things change, new compiler version come in, etc. Ah okay. I thought they would get a new pkgrel if one of the dependencies/build tools is upgraded. > > So yes, this seems to be handled by the maintainer, but isn't documented in the PKGBUILD of Arch. > > > > And the question was: Should we create bugreports for the maintainers to fix this documentation issue - or go to the project itself and fix the cause of this issue (or at least ask for a fix)? > > The correct way would be to use the bugtracker, at least if it's fixable by the Arch maintainer. If this needs to be fixed in the upstream project itself, then the upstream bugtracker it is. You can certainly open a bug in both if you so want to (linking to upstream issue). Okay, good to know :)

anonfunc commented

2022-07-09 02:28:39 +02:00

Owner

I think this can be closed. The original request is answered (as in: we can't do anything about it), and the shim is tracked in #124.

anonfunc closed this issue

2022-07-09 02:28:40 +02:00

[build failure] package dmraid #119