[Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

Lone_Wolf · 2020-05-20 12:48:24

https://aur.archlinux.org/packages/cnrdrvcups-lb version 5.10-1 currently fails to build with gcc 10.1.x .
This is not surprising, but the error message both local build (makepkg -Crs ) and extra-x86_64-build give IS.

==> ERROR: A failure occurred in build().
/usr/share/makepkg/util/message.sh: line 47: QUIET: unbound variable
==> ERROR: Build failed, check /var/lib/archbuild/extra-x86_64/panoramix/build

full log at https://pastebin.com/8Vrjn6pe

Is this error due to the sourcecode/PGBUILD or should I file a bug for makepkg ?

[Edit]

Not a makepkg bug, caused by using set -u in PKGBUILD,
check http://mywiki.wooledge.org/BashFAQ/112 for an overview of what set -u does.

Last edited by Lone_Wolf (2020-05-21 10:57:30)

loqs · 2020-05-20 13:24:52

If you disable set -u on line 136 of the PKGBUILD does that stop the warning being produced?

Lone_Wolf · 2020-05-20 14:10:48

Yes, with that disabled makepkg and extra-x86_64-build both fail gracefully as intended on build errors.

If I understood the explanation from Severach (author of the code that converts the .spec file to a makefile ) correctly, the set -u / set +u makes it much easier to detect needed variables that aren't defined.

Thanks for finding the cause of the warning, logs.

Now we need to figure out whether this fail counts as a makepkg bug or not.

eschwartz · 2020-05-20 15:28:49

This is not a makepkg bug, this is a well-known Severach bug. Protip: "set -u" is not actually considered good shell scripting: http://mywiki.wooledge.org/BashFAQ/112

Some people think they're super smart by doing strange things to PKGBUILDs, then undoing it because makepkg doesn't work that way and several thousand lines of code which doesn't work with set -u is being meddled with by a dozen lines of code which pretentiously thinks it works with set -u AND AS YOU HAVE JUST SEEN IT DOESN'T.
Then redoing it and undoing it and redoing it and undoing it, again and again throughout the course of the file.

Also his PKGBUILDs tend towards the sharply unreadable and I don't usually encounter ones as bad as his, though I grant they aren't as bad as https://github.com/Tk-Glitch/PKGBUILDS/ … t/PKGBUILD (this is not actually a PKGBUILD though).

Last edited by eschwartz (2020-05-20 15:29:46)

Alad · 2020-05-20 16:48:17

I've never seen anyone else but that particular maintainer use set -u (and a wide host of other peculiar malpractices). I would only base on how to write my PKGBUILDs on wiki guidelines.

loqs · 2020-05-20 17:54:32

Does the following patch fix the build issue?

diff --git a/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.c b/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.c
index df1beeb..5a0eb97 100644
--- a/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.c
+++ b/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.c
@@ -28,6 +28,16 @@
 GModule* g_module = NULL;
 char pre_lib_name[MAX_PATH];
 gboolean first_load = TRUE;
+void (*ShowPDLDialog)(const char* name, int print);
+gboolean (*InitPDLController)(GtkWidget* main_dlg, char *printer_name, const char* print_file, gboolean first_load);
+void (*UpdatePDLData)(int id, const char* value);
+void (*UpdatePDLDataInt)(int id, int value);
+void (*ClosePDLController)();
+void (*SavePDLPrinterData)();
+void (*PrintPDLFile)();
+char* (*GetPDLData)(int id);
+int (*GetPDLDataInt)(int id, int def);
+int (*ExecPDLJobMode)();
 
 int LoadPDL(GladeXML* main_xml, const char* print_file)
 {
diff --git a/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.h b/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.h
index 03808b8..f62a05b 100644
--- a/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.h
+++ b/extracted-cnrdrvcups-lb-5.10/cnrdrvcups-common-5.10/cngplp/src/load.h
@@ -28,15 +28,15 @@
 
 int LoadPDL(GladeXML* main_xml, const char* print_file);
 void UnLoadPDL();
-void (*ShowPDLDialog)(const char* name, int print);
-gboolean (*InitPDLController)(GtkWidget* main_dlg, char *printer_name, const char* print_file, gboolean first_load);
-void (*UpdatePDLData)(int id, const char* value);
-void (*UpdatePDLDataInt)(int id, int value);
-void (*ClosePDLController)();
-void (*SavePDLPrinterData)();
-void (*PrintPDLFile)();
-char* (*GetPDLData)(int id);
-int (*GetPDLDataInt)(int id, int def);
-int (*ExecPDLJobMode)();
+extern void (*ShowPDLDialog)(const char* name, int print);
+extern gboolean (*InitPDLController)(GtkWidget* main_dlg, char *printer_name, const char* print_file, gboolean first_load);
+extern void (*UpdatePDLData)(int id, const char* value);
+extern void (*UpdatePDLDataInt)(int id, int value);
+extern void (*ClosePDLController)();
+extern void (*SavePDLPrinterData)();
+extern void (*PrintPDLFile)();
+extern char* (*GetPDLData)(int id);
+extern int (*GetPDLDataInt)(int id, int def);
+extern int (*ExecPDLJobMode)();
 
 #endif

ayekat · 2020-05-20 18:58:32

eschwartz wrote:

This is not a makepkg bug, this is a well-known Severach bug. Protip: "set -u" is not actually considered good shell scripting: http://mywiki.wooledge.org/BashFAQ/112

As someone who uses -u in scripts, I'll have to point out that (even according to that article) it is not considered bad shell scripting either. It's more of a "pay attention when interacting with outside code bases", and that isn't limited to -u. But in case of those PKGBUILDs, that attention was obviously not paid.

As someone who's already had the misfortune of having an AUR package "adopted" by severach, I'm relieved to read that I'm not the only one being profoundly irritated by his work.

Last edited by ayekat (2020-05-20 19:01:25)

eschwartz · 2020-05-20 19:49:54

ayekat wrote:

As someone who uses -u in scripts, I'll have to point out that (even according to that article) it is not considered bad shell scripting either. It's more of a "pay attention when interacting with outside code bases", and that isn't limited to `-u`. But in case of those PKGBUILDs, that attention was obviously not paid.

"This feature is rather controversial, and has many extremely vocal advocates and opponents."

I'm one of its vocal opponents. That wiki page tries hard to be unbiased, even though I'm pretty positive greycat strongly disbelieves in set -u as well -- but notice by every listed positive there's a rebuttal, and by every negative there isn't a rebuttal (because you cannot rebut them ).

Admittedly, no one is quite as hardcore over set -u as they are over set -e: http://mywiki.wooledge.org/BashFAQ/105

That would be because if you control your entire script from beginning to end, and make it work with set -u, it might be a lot of useless busy work that makes your script ugly but doesn't achieve anything, but you can reliably make it work, and it will, in fact, work reliably -- in the sense that it will never trigger a false positive and abort (and false negatives don't regress functionality compared to the version of the script which didn't use set -u).

In contrast, set -e actively takes your script, eats it for lunch, aborts it at total random in unpredictable ways that change from point release to point release of the shell, and instead of merely being ugly and useless, it's a rabid dog that must be put down.

...

There are different levels of bad. Either way, using set -u in a PKGBUILD which is sourced by someone else's program which doesn't work with set -u, is just as bad as the general use of set -e.

eschwartz · 2020-05-20 20:01:55

General complaints about the use of set -u in a PKGBUILD:

In this case, makepkg actually uses set -e for limited purposes, in that the contents of a pkgver/prepare/build/check/package function and *only* the contents of these functions, are run using set -e, which trigger a trap that runs various cleanup tasks, and that trap gets run inside the set -u context which this odd PKGBUILD defined, AND THAT TRAP USES UNBOUND VARIABLES. By design.

Since it's running in a trap anyway, makepkg properly cleans up after itself, but it does print an ugly error message about makepkg's internal unbound local variables. If the PKGBUILD survives long enough to run set +u, it doesn't trigger internal unbound variable errors.

If the PKGBUILD's author has written a build() function which triggers a set -u abortion, i.e. the intended use of this strange set -u; run_some_commands; set +u; run_some_commands; set -u; run_some_commands; set +u ... then makepkg will abort because of set -u, but it won't do so by triggering ERR, so makepkg's error_function() trap is not invoked, which is a blatant violation of makepkg semantics.

The cleanup trap may still be run on EXIT to remove deps with makepkg -sr and similar, but error messages such as:

==> ERROR: A failure occurred in package().
Aborting...

will not be emitted, you just get a mysterious unbound variable error and that's the last line. Nor will makepkg correctly exit with E_USER_FUNCTION_FAILED, instead it fails with "E_FAIL: unknown failure".

tl;dr
Using set -u in a PKGBUILD will result in the wrong behavior from a makepkg perspective, *even if* it only produces errors in the manner in which the PKGBUILD author expected.

And now that I come to think about it, that's another objection I have against the use of set -u. If your script traps ERR and does things only on errors, but you exit because of set -u violations, your script is wrong and does the wrong thing because it didn't get trapped properly.

Arch Linux

#1 2020-05-20 12:48:24

[Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#2 2020-05-20 13:24:52

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#3 2020-05-20 14:10:48

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#4 2020-05-20 15:28:49

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#5 2020-05-20 16:48:17

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#6 2020-05-20 17:54:32

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#7 2020-05-20 18:58:32

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#8 2020-05-20 19:49:54

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

#9 2020-05-20 20:01:55

Re: [Solved] makepkg/util/message.sh: line 47: QUIET: unbound variable

Board footer