Arch Linux User Repository

Just to be clear - I'll look into these errors. But the first and the last time I installed this package, it was installed correctly.

usr/include/c++/9.2.0/bits/fs_fwd.:39: Parse error at "std"

@ptrxyz - I got that error also. Tracked it down to actually another error which is ignored during module imports. In short it seems the first time I ran multibootusb without root it created a /tmp/multibootusb.log file. Then when running it as root when it tries to import the config file it for some reason can't because of incorrect permissions/ownership on that log file (and this error is ignored until the config variable is accessed). Anyhow, deleting /tmp/multibootusb.log and running as root worked for me.

When trying to install, this is what I get:

Using python version  3.7.4 (default, Oct  4 2019, 06:57:26) 
[GCC 9.2.0] on platform Linux-5.3.7-zen1-1-zen-x86_64-with-arch
Traceback (most recent call last):
  File "/usr/bin/multibootusb", line 187, in <module>
    if config.debug is True:
NameError: name 'config' is not defined

I'm not sure what causes this issue, does anyone know?

Please use a build() array according to Python package guidelines:

build() {
    cd "$pkgname-$pkgver"
    python setup.py build
}

package() {
    cd "$pkgname-$pkgver"
    python setup.py install --root="$pkgdir/" --optimize=1 --skip-build
}

It is unnecessary to change the permissions of the desktop file.

It's not necessary to include the following:

• pyqt5-common as python-pyqt5 depends on it.
• python-six as python-pyudev depends on it.
• util-linux as its part of the base-devel group.

Issue is resolved, possibly. I mean, there is no config not defined when building package.

This package is broken by an upstream issue, for the time being please use multibootusb-git.

I have the same issue as @ganileni but was able to solve it.

I have a quite lean setup and installing the package extra/udisks2 fixed the error, so I guess that's a missing dependency?

I located the issue. The polkit file was pointing to the wrong location of the binary, causing it to crash. I just pushed a change to the PKGBUILD that corrects this.