You are not logged in.

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

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

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

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)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

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

loqs
Member
Registered: 2014-03-06
Posts: 17,192

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

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

Offline

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

Lone_Wolf
Member
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,868

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

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.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

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

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

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

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)


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

Alad
Wiki Admin/IRC Op
From: Bagelstan
Registered: 2014-05-04
Posts: 2,407
Website

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

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.


Mods are just community members who have the occasionally necessary option to move threads around and edit posts. -- Trilby

Offline

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

loqs
Member
Registered: 2014-03-06
Posts: 17,192

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

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

Offline

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

ayekat
Member
Registered: 2011-01-17
Posts: 1,589

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

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)


pkgshackscfgblag

Offline

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

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

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

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 tongue).

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.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

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

eschwartz
Fellow
Registered: 2014-08-08
Posts: 4,097

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

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.


Managing AUR repos The Right Way -- aurpublish (now a standalone tool)

Offline

Board footer

Powered by FluxBB