Bug#1078026: -lmpi_mpifh does not work
https://salsa.debian.org/hpc-team/openmpi/-/commit/45d922571f1b8af1fff14774d61459f8d48fe472 indicates that this was known to be broken but analyzed as a bug in the packaging testcase itself? -- Eli Schwartz OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1078026: -lmpi_mpifh does not work
w __gmon_start__ In fact, I wonder what this library exists for at all. It's not a valid library for building openmpi software against. It doesn't appear to be installed by any other distros. It seems like it is something Debian has patched in, but I cannot figure out why. -- Eli Schwartz OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1059076: duplicity: --version returns $version, instead of an actual version
On Thu, 21 Dec 2023 08:18:38 +1000 Alexander Zangerl wrote: > On Wed, 20 Dec 2023 15:57:54 -0600, Kenneth Loafman writes: > >Duplicity has been this way for a long time. Where do you get your sources > >from? > > launchpad, as long as duplicity lived there. > not duplicity.gitlab.io, as that send you nowhere. > gitlab, since. > > anyway, code modified, case closed. I find this logic hard to accept. If you are actually using gitlab, then surely you should see the clear statement of intent on gitlab: upstream uses sourceforge as a source tarball hosting site and clearly expects this to be used. The sourceforge tarball contains a replaced $version. -- Eli Schwartz
Bug#1056818: meson: ftbfs with cython 3.0.x
Per your link, it does NOT succeed with the older cython release and therefore this is not a regression in cython. Please open a new ticket to report the generalized non-cython failure, and close this ticket as invalid. (If this report was mistargeted, then there may be others as well.) -- Eli Schwartz
Bug#1041499: meson: glib2.0 FTBFS on mips64el: "native build" but then "Can not run test applications in this cross environment"
On Wed, 19 Jul 2023 20:12:08 +0100 Simon McVittie wrote: > glib2.0's meson.build has several calls to 'cc.run(...)' guarded by > a check for 'cc_can_run = meson.can_run_host_binaries()'. > > On mips64el, Meson seems confused about whether this is a native or > cross build. At first, it correctly reports that this is a native build: > > <https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=mips64el&ver=2.76.4-2&stamp=1689773327&raw=0> > > The Meson build system > > Version: 1.2.0 > > Source dir: /<> > > Build dir: /<>/debian/build/deb > > Build type: native build > > Project name: glib > > Project version: 2.76.4 > > but then later, cc.run() fails: > > > ../../../meson.build:1127:14: ERROR: Can not run test applications in this > > cross environment. Update: Simon wrote a fix for this and it is merged upstream and tagged for the .1 maintenance release. https://github.com/mesonbuild/meson/pull/12080 -- Eli Schwartz
Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson
On 8/6/23 9:27 AM, Simon McVittie wrote: > On Tue, 01 Aug 2023 at 15:14:13 -0400, Eli Schwartz wrote: >> My conclusion was that all distros want bytecode, except for Debian, >> which doesn't want bytecode. > > Debian does want bytecode, but the Debian Python team's policy is to > generate it at package-installation time, rather than generating it at > package build time and including it in the content of the .deb. There was an implied "... in the downloadable package archive" there. :D Indeed, the other distro that simply runs a cleaning pass on the staging files , runs a package-installation-time script to create them too. > (This allows the same .deb to be used for more than one major version > of Python, without always having to rebuild it, as long as it doesn't > contain compiled extensions; requiring rebuilds for this would be a > problem because the Debian infrastructure cannot currently do fully > automated rebuilds of fully-architecture-independent packages, so doing > those rebuilds would require a package maintainer to sign and upload a > new package with only trivial changes, which would scale poorly across > the very large number of packages that depend on Python.) Aside, but: I find this very troublesome and bad for users. I have actually attempted to use "more than one major version of python", on Ubuntu which is admittedly not Debian but does reuse Debian's infrastructure for this. It was an unmitigated disaster, and I'm specifically talking about python packages that contain zero compiled extensions, purely python code. The issue is that lots of projects need source code changes to run on newer versions of python, obtained by updating to new upstream releases. It's very possible this was a Ubuntu-specific issue, but when Ubuntu Bionic packaged python 3.8 as an optional alternative to the system python 3.6, I hit lots of issues trying to switch Meson's CI over while upgrading from 3.6 to "at least 3.7", because various modules were not actually 3.8-ready and apparently no one bothered to check that the python3.8 package was compatible with all the software packaged in Ubuntu that was visible to it. I had to install them with pip instead, after forcing pip to ignore the apt versions. > CMake and Autotools packages have it easier here, because they don't > fail the build when given an option that is not recognised, so if they > gained a new option whose action we didn't want, we could give them a > -DDISABLE_NEW_THING=ON or --disable-new-thing argument unconditionally. autotools *does* fail the build when given an option that is not recognized, but it makes a special exception for user options prefixed with --enable / --disable / --with / --without, and documents this behavior under the rationale: """ An unknown option ordinarily indicates a mistake by the user and configure halts with an error. However, by default unknown --with-package and --enable-feature options elicit only a warning, to support configuring entire source trees. Source trees often contain multiple packages with a top-level configure script that uses the AC_CONFIG_SUBDIRS macro (see Subdirectories). Because the packages generally support different --with-package and --enable-feature options, the GNU Coding Standards say they must accept unrecognized options without halting. """ You can upgrade that warning to a fatal error using --enable-option-checking=fatal. Meson doesn't have the underlying problem, though, because it supports option namespacing, so it would be like autotools supporting: --subdir:with-package Hence meson uses errors instead of warnings. As for cmake... the less said, the better. :D cmake doesn't support options at all -- when you use -DDISABLE_NEW_THING=ON, you're setting a cmake scripting variable, not passing options into an option parser. cmake isn't capable of warning you on unknown options, which autotools does. And really, it can't, because the cmake files may not actually attempt to read DISABLE_NEW_THING except in certain codepaths. There's no centralized option parser like both autotools and meson have. So I would say that meson's behavior is pretty standard *for option parsing*, cmake is just a terrible build system. :D > I'm aware that Meson is intentionally being strict with -D > to detect typos and avoid unintended behaviour, but would it > be possible to add a variant of -D in a future version that > specifically ignores unrecognised options? Perhaps something like > --set-option-if-supported=python.bytecompile=-1? Hmm, I daresay I would not object to such a feature, actually. :) Although I wonder if it should be limited to machine files. -- Eli Schwartz
Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson
On 8/1/23 3:13 PM, Eli Schwartz wrote: > On Thu, 27 Jul 2023 15:43:26 +0100 Simon McVittie wrote: >> Is there a way this can be done, without making packages FTBFS if debhelper >> is backported to an older suite but Meson is not? -Dpython.bytecompile=-1 >> will cause `meson setup` to fail if Meson is an older version, and I'm not >> aware of a way to say "set this option if supported, ignore if not" without >> parsing `meson --version` and comparing it with a threshold. > > > Just tested, and adding this to a --native-file should work: > > ``` > [built-in options] > python.bytecompile = '-1' > ``` Sorry, no, this works for versions of meson that have the option, but setting unknown properties isn't ignored. Ignore me... -- Eli Schwartz
Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson
On Thu, 27 Jul 2023 15:43:26 +0100 Simon McVittie wrote: > Is there a way this can be done, without making packages FTBFS if debhelper > is backported to an older suite but Meson is not? -Dpython.bytecompile=-1 > will cause `meson setup` to fail if Meson is an older version, and I'm not > aware of a way to say "set this option if supported, ignore if not" without > parsing `meson --version` and comparing it with a threshold. Just tested, and adding this to a --native-file should work: ``` [built-in options] python.bytecompile = '-1' ``` -- Eli Schwartz
Bug#1042398: debhelper: should disable Python byte-compilation when building .deb with Meson
On Fri, 28 Jul 2023 13:41:14 +0300 Jussi Pakkanen wrote: > On Thu, 27 Jul 2023 at 17:45, Simon McVittie wrote: > > > As far as I'm aware, we never want to include .pyc in Debian packages, > > so I think debhelper's meson build system plugin should be turning this off > > as a standard setting for all Debian packages (similar to the way it > > sets --prefix=/usr as a standard setting for all Debian packages). > > > > Do the Meson maintainers agree? > > Obviously the defaults should do the correct thing. In fact until > yesterday that is what I thought the code does not do byte > compilation. We might even consider changing the default for this as I > would imagine all distros will hit the same issue. >From the original implementation, I discussed the topic: https://github.com/mesonbuild/meson/pull/11530#discussion_r1140204427 My conclusion was that all distros want bytecode, except for Debian, which doesn't want bytecode. There is one exception that does not want bytecode but instead of a lintian style "error if you have it" approach, they have a debhelper style "DTRT and automatically delete it" approach. I also made the following comment: """ I'm a bit surprised that debhelper doesn't help out your .deb by removing them for you, but whatever... It's theoretically possible to hardcode Debian yet again and skip this install script, but only if running inside a package build. Is there even a way to detect this? No idea. Not an enthusiastic topic anyway. """ -- Eli Schwartz
Bug#1040748: ftbfs in pycairo with meson 1.2.0 rc2
On 7/10/23 5:09 AM, Simon McVittie wrote: > Is there a way for debhelper to set this option without breaking the > build of packages that contain no Python? It should be fine to always pass this option on meson 1.2.0+, since the option will exist even if it is never read. -- Eli Schwartz
Bug#1040755: ftbfs in rygel with meson 1.2.0 rc2
Source: rygel Version: 0.42.3-2 Severity: important Tags: ftbfs upstream Forwarded: https://gitlab.gnome.org/GNOME/rygel/-/issues/230 X-Debbugs-CC: hel...@subdivi.de During an archive rebuild against the release candidate for meson in experimental, rygel failed to build from source with the following log excerpt: ``` cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir= lib/x86_64-linux-gnu -Dsystemd-user-units-dir=/usr/lib/systemd/user -Dapi-docs=true -Dintrospection=disabled -Dexamples=false -Dplugins=external,gst-launch,media-export ,mpris,playbin,ruih,tracker3 The Meson build system Version: 1.2.0.rc2 Source dir: /<> Build dir: /<>/obj-x86_64-linux-gnu Build type: native build ../meson.build:1:0: ERROR: Unexpected "[provides]" section, did you mean "[provide]"? ``` Previous versions of meson silently ignored this invalid section, but the release candidate complains about it. This is an upstream bug as the file did not do what it was expected to do, but it prevents building in Debian. The simplest solution is to delete the .wrap files from the subprojects/ directory, since Debian does not build this project with vendored dependencies. -- Eli Schwartz
Bug#1040753: FTBFS in gupnp-tools with meson 1.2.0 rc2
Source: gupnp-tools Version: 0.12.0-2 Severity: important Tags: ftbfs upstream fixed-upstream Forwarded: https://gitlab.gnome.org/GNOME/gupnp-tools/-/issues/26 X-Debbugs-CC: hel...@subdivi.de During an archive rebuild against the release candidate for meson in experimental, gupnp-tools failed to build from source with the following log excerpt: ``` cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstatedir=/var --libdir= lib/x86_64-linux-gnu The Meson build system Version: 1.2.0.rc2 Source dir: /<> Build dir: /<>/obj-x86_64-linux-gnu Build type: native build ../meson.build:1:0: ERROR: Unexpected "[provides]" section, did you mean "[provide]"? ``` Previous versions of meson silently ignored this invalid section, but the release candidate complains about it. This is an upstream bug as the file did not do what it was expected to do, but it prevents building in Debian. The simplest solution is to delete the .wrap files from the subprojects/ directory, since Debian does not build this project with vendored dependencies. It is also fixed upstream in git. -- Eli Schwartz
Bug#1040748: ftbfs in pycairo with meson 1.2.0 rc2
Source: pycairo Version: 1.24.0-1 Severity: important Tags: ftbfs X-Debbugs-CC: hel...@subdivi.de During an archive rebuild against the release candidate for meson in experimental, pycairo failed to build from source with the following log excerpt: ``` dh_auto_install -O--buildsystem=meson cd obj-x86_64-linux-gnu && DESTDIR=/<>/debian/tmp LC_ALL=C.UTF-8 ninja install [0/1] Installing files. Compiling '/<>/debian/tmp/usr/lib/python3/dist-packages/cairo/__init__.py'... [...] Running custom install script '/usr/bin/python3 /<>/obj-x86_64-linux-gnu/meson-private/pycompile.py python-3.11-installed.json 0' [...] dh_missing -O--buildsystem=meson dh_missing: warning: usr/lib/python3/dist-packages/cairo/__pycache__/__init__.cpython-311.pyc exists in debian/tmp but is not installed to anywhere dh_missing: error: missing files, aborting [...] make: *** [debian/rules:6: binary] Error 25 ``` This fails with the release candidate, but does not fail against the stable release of meson. The underlying cause is an additional feature of meson: https://mesonbuild.com/Release-notes-for-1-2-0.html#python-module-can-now-compile-bytecode If this file is not desired in the debian package, please specify your preferred value for this meson setting. For example, to avoid compiling bytecode as part of `meson install`, you could setup the build system with the `-Dpython.bytecompile=-1` option. -- Eli Schwartz
Bug#1040746: ftbfs in gnome-photos with recent babl
Source: gnome-photos Version: 43.0-2 Severity: serious Tags: ftbfs X-Debbugs-CC: hel...@subdivi.de During an archive rebuild against the release candidate for meson in experimental, gnome-photos failed to build from source with the following log excerpt: ``` ../meson.build:155:11: ERROR: Dependency "babl" not found, tried pkgconfig dh_auto_configure: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 meson setup .. --wrap-mode=nodownload --buildtype=plain --prefix=/usr --sysconfdir=/etc --localstate dir=/var --libdir=lib/x86_64-linux-gnu -Ddogtail=false -Dinstalled_tests=true returned exit code 1 make[1]: *** [debian/rules:12: override_dh_auto_configure] Error 25 ``` This *should* fail in all versions of meson, and occurs because of a renamed pkg-config file in libbabl-dev. Upstream adapted to this rename in: https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/248 https://gitlab.gnome.org/GNOME/gnome-photos/-/merge_requests/261 Both merge requests are available when upgrading to 44.0, or alternatively in 43.1 (a bugfix release containing only this change) -- Eli Schwartz
Bug#1040682: FTBFS in colord with meson 1.2.0 rc2
Control: severity -1 important Helmut Grohne clarified that the "serious" severity should not be set for packages that only fail with the new meson, since "the autoremover will act on serious bugs and we don't want that to happen just yet". The meson release candidates are only ever uploaded to experimental, and are a preview for the future. Temporarily downgrading the severity. This should be reset to "serious" once the final release is out, as which will go directly to unstable. -- Eli Schwartz
Bug#1040682: FTBFS in colord with meson 1.2.0 rc2
Source: colord Version: 1.4.6-2.2 Severity: serious Tags: ftbfs colord successfully passes dh_auto_configure, but fails to build immediately after: ``` dh override_dh_auto_configure-arch make[1]: Leaving directory '/<>' debian/rules override_dh_auto_configure-indep make[1]: Entering directory '/<>' meson configure -Dsession_example=false -Ddaemon_user=colord -Dvapi=true -Ddocs=false -Dinstalled_tests=true -Dargyllcms_sensor=true -Dsane=true -Dprint_profiles=true ERROR: No valid build directory found, cannot modify options. make[1]: *** [debian/rules:38: override_dh_auto_configure-indep] Error 1 ``` The cause of this is that setup options are passed to meson's "print the values of all options" subcommand. Previous versions of meson would print the following warning: The source directory instead of the build directory was specified. Only the default values for the project are printed, and all command line parameters are ignored. The release candidate makes this an error instead. If you want to print the values of available options, simply avoid passing arguments; this works both in a source directory and a build directory. -- Eli Schwartz
Bug#1040316: python3-minimal fails to install
This bug seems to have been caused by https://salsa.debian.org/cpython-team/python3-defaults/-/commit/8e243207fee371a7335674fc77db63044b62cb29 It migrated from imp to importlib, but importlib doesn't imply importlib.util -- you cannot and AFAIK never have been able to import the top-level package and assume the nested modules are available. That being said, it did work for me in my (non-Debian :P) 3.11 environment, purely because I had a .pth file that caused importlib.util to be imported at startup. (It is the stock setuptools one for namespace packages. You can isolate the interpreter a bit with -IS to catch this.) So a similar problem may explain why this wasn't caught during local testing. It probably makes sense to generally test this sort of thing with minimal packages installed, because sneaky .pth files will cause you issues all the time.
Bug#1026312: meson: diff for NMU version 1.0.0-1.1
This patch is non-upstreamable. I must confess however that I am surprised that setuptools is installed in your buildd at all -- Meson doesn't use it, and projects using Meson most likely don't also need setuptools at the same time. So this should be a moot point. If setuptools is not installed, it cannot overwrite the stdlib distutils. And there's a viable approach to not using distutils by the time distutils is removed from the stdlib. -- Eli Schwartz
Bug#1015132: meson: FTBFS: ./b 52a78b9866/../test cases/failing build/2 hidden symbol/bobuser.c:4: undefined reference to `hidden_function'
On Sat, 16 Jul 2022 20:55:02 +0200 Lucas Nussbaum wrote:
> Hi,
>
> The script I use to extract the failure from the log might have guessed
> badly indeed, however the build still fails, as shown by the full log
> linked in the bug:
> http://qa-logs.debian.net/2022/07/16/meson_0.63.0-1_unstable.log
> SO I wouldn't call that a "spurious failure".
>
> However looking at the log I don't really understand why the
> override_dh_auto_test target fails. Can you explain? Maybe I can improve
> my script.
>
> Lucas
The testsuite has two parts. The first part (that actually fails in this
case) is a standard python-unittest run, and presumably you have
heuristics that can catch that.
The second part is a very custom setup, you'll undoubtedly need to
manually code support for it. Since Debian includes the environment
variable $MESON_PRINT_TEST_OUTPUT for extra extra extra debug spew, it
logs full configure/build/test/install output for all tests, not just
the ones that represent test failures... including, as stated above,
passing tests that attempt to assert that certain things aren't expected
to work.
Let's take a look at run_project_tests.py which is driving these very
verbose tests:
class TestStatus(Enum):
OK = normal_green(' [SUCCESS] ')
SKIP = yellow(' [SKIPPED] ')
ERROR = red(' [ERROR] ')
UNEXSKIP = red('[UNEXSKIP] ')
UNEXRUN = red(' [UNEXRUN] ')
CANCELED = cyan('[CANCELED] ')
RUNNING = blue(' [RUNNING] ') # Should never be actually printed
LOG = bold(' [LOG] ') # Should never be actually printed
Individual test logs are always separated by lines beginning with the
string " [XXX]".
error, unexskip, and unexrun are the only failure states.
unexskip and unexrun can only happen in Meson's internal CI
($MESON_CI_JOBNAME is set and isn't "thirdparty").
So you can just filter for:
- any python-unittest matching logs (e.g. in between "===" and
"\nRan tests in s")
- anything in between " [ERROR]" and " []"
--
Eli Schwartz
Bug#855389: calibre: exception when adding custom open-with program
Should be fixed a very long time ago (4 months after it was reported here) via https://github.com/kovidgoyal/calibre/commit/768bdc2d8eaee4728a6dfe29e917b048f7aeea0a In the future, please consider trying to install the official prebuilt binaries at https://calibre-ebook.com/download_linux and seeing if the error can be duplicated; if you still get the error, then it's an upstream bug and can be reported to the calibre developer at https://calibre-ebook.com/bugs -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#947393: calibre: Unneeded patches deviate from upstream for no gain.
On 12/26/19 1:05 AM, Norbert Preining wrote: >> Fedora has a patch which completely prevents the application from >> checking for application updates, but leaves the plugin updater check >> running. Perhaps you would find this interesting? > > Really? The patch seems to remove the plugins update check code, too, at > least to my eyes? But yeah, this is where I would patch code if > necessary. > >> https://src.fedoraproject.org/rpms/calibre/blob/master/f/calibre-no-update.patch > ... > -try: > -update_plugins = > get_plugin_updates_available(raise_error=True) > -if update_plugins is not None: > -plugins_update_found = len(update_plugins) > It's too late at night for me to analyze this, but I have vague memories of looking at the patch and figuring that was what it did or was intended to do. Could be I misremembered. Maybe I'll take another look. Either way, that's indeed the logical place to patch it, so yeah. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#947394: calibre: missing zsh completions
Package: calibre
Version: 2.5.0+dfsg-1
calibre's installer can generate bash and zsh completions for all
command-line programs. The zsh completions do not automatically get
installed, however, since the destination directory is not predictable
(unlike bash).
In order to ensure the completions are installed, you must first create
the directory under the staging installation root, for example:
mkdir -p "${DESTDIR}"/usr/share/zsh/site-functions/
(per the default zsh upstream directory). IIRC, Debian uses the
directory .../zsh/vendor-completions/ instead. Whatever it is, calibre
will detect it exists, and try to write completions to it.
For more details, see the source code (which enumerates the directories
it searches for):
https://github.com/kovidgoyal/calibre/blob/e721f8aa3ede7ae1c62fb5a8b4a52ca5562e4df7/src/calibre/linux.py#L194-L210
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Bug#947393: calibre: Unneeded patches deviate from upstream for no gain.
On 12/25/19 9:48 PM, Norbert Preining wrote: > Hi Eli, > > thanks for the report. [...] >> - Disable-update-check-by-default.patch >> >> While I'm on the topic of Debian-specific patches... this patch seems to >> cause calibre to start up with the update checker disabled, but that >> will disable both the application version check and the plugins version >> check, and I don't believe the latter is appropriate to disable. Please >> check if this is overreaching, and find a more targeted patch if so. > > Indeed, but I think this was the original idea. Programs should not > start up and contact outside entities by default - at least this is what > I learned back then, maybe this is not a requirement anymore. Could be. The patch doesn't clearly explain the rationale, so without insider information I cannot be sure whether the intention was to prevent contacting a server, or just to prevent confusing messages about an update that isn't applicable to a stable release. For what it's worth, this is linked to: https://calibre-ebook.com/dynamic/calibre-usage "Usage statistics are collected whenever a user starts calibre. Every calibre installation has a unique ID, this ID remains unchanged by upgrades and even an uninstall/re-install. This ID is used to collect usage statistics. Only this ID is stored, no other identifying information is collected." So per the developer's promise, nothing is logged other than a UUID, operating system, version, and icon theme (if any). That last bit of information will be used in Preferences -> Look & Feel -> Change icon theme, in order to sort by popularity. I don't know if that commitment is sufficient for Debian. > I will check back with debian-devel. I would change the patch to make > it only check for updated plugins. We don't want users to try to mess up > the dpkg version with some hand-updates as root, that will not work out. That's a reasonable concern. My distro provides updates usually within a day (well, we are rolling), so I don't bother to disable this as generally no one is going to sudo install anything. Fedora has a patch which completely prevents the application from checking for application updates, but leaves the plugin updater check running. Perhaps you would find this interesting? https://src.fedoraproject.org/rpms/calibre/blob/master/f/calibre-no-update.patch > The patches that will be used (atm) for the package I am preparing are > - Disable-update-check-by-default.patch > see above > - Fix-desktop-integration-installation.patch > I am surprised that on Arch nothing like this is necessary ... > When I do this on Debian, the calibre installer tries to > actually install into system directories Well, it cannot because it doesn't run as root... I used to use XDG_DATA_DIRS in my recipe, until I eventually submitted https://github.com/kovidgoyal/calibre/commit/2a63948440fe2d60a5573b829f27000d5c0389e2 upstream to do this automatically when staging an install into a packaging root. I haven't run across any cases of it attempting to install to system directories when using this. xdg-desktop-menu does have some strange interactions with /usr/share/gnome/apps, but AFAICT it manages to disable those bits if the directory is not writable by the invoking user. > - no-detach-in-desktop-files > also something reasonable I think > - Hardening-Qt-code.patch > same with that > So I really think that Debian packages do **not** degress from upstream > as far as it is always assumed. The only *functional* change is the > update check, which, as I wrote, is a requirement AFAIR of Debian. To be fair, the package is a lot better now that it's using the upstream-approved mathjax bundle, and now that both Debian and calibre agree on whether markdown is a system module. Also several fixes that resulted from the forum thread at https://www.mobileread.com/forums/showthread.php?t=288093 Way back in the day, when cherrypy was still in use by the calibre codebase, that was broken on Debian too... there were a whole bunch of local modifications in the calibre fork. I actually submitted a rather snarky bug report to Arch Linux about that, since it was broken there too, although that was before I joined the packaging team. Taking a look at the current packaging you have, I'm happy to say that nothing jumps out at me as problematic anymore. Thanks for your work improving calibre on Debian. :) -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#646128: Conversion to MOBI-format fails, if X Window System is not present
calibre upstream requires interaction with the X display server for some parts of the conversion pipeline (e.g. image processing). One of the major features of the 2.0 release and the port to Qt5, was the headless plugin on Linux, which allowed any of the command-line tools to work without Xorg running. This bug report is obsolete since Thu Aug 21 23:54:55 2014, with the 2.0.0 release. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#726327: improve calibre-server packaging
This would require rewriting the entire upstream program, since they aren't separate applications. They are a single intertwined codebase which has multiple entry stubs. Also, the content server uses qt, so you're not getting rid of that anyway. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#802767: calibre: Please split ebook-viewer out as a seperate package
This would require rewriting the entire upstream program, since they aren't separate applications. They are a single intertwined codebase which has multiple entry stubs. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#690467: Calibre quick-start guide advises user to use "Book Designer" (probably non-free) program not in Debian
This bug report is obsolete, I guess, since current versions of calibre refer exclusively to the ebook-viewer application shipped natively by calibre. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#674104: calibre: localization zip file is not updated on package build
This makes no sense -- the locales.zip file is by definition the precompiled translations, and the translations/ directory is simply the sources for this. If for some reason you desire to rebuild these *anyway*, calibre has a built-in buildsystem command to regenerate it: python2 setup.py translations This bug should be closed as invalid. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#947393: calibre: Unneeded patches deviate from upstream for no gain.
Package: calibre Version: 4.6.0+dfsg-1 The current version of calibre has some patches which should probably be removed. - Fix-Markdown-module-loader.patch This is simply incorrect. The upstream code this is patching out, works with the system markdown but ensures that existing code which tries to import the old "calibre.ebooks.markdown" vendored version, continues to work by correctly proxying to the system version. This is implemented via a meta_path hook which intercepts "import " statements. Previous versions of calibre in debian incorrectly did a tree-wide sed to "fix" the vendored version of markdown, but the correct solution is to simply drop all custom modifications and trust upstream to get it right -- not add different patches. (The debian patch will break thirdparty plugins that rely on the stable calibre.ebooks API having this historic module. And it's harmless to leave it in.) - Use-packaged-instead-of-bundled-feedparser-Python-module.patch Same here, the meta_path hook ensures "from calibre.web.feeds.feedparser import parse" sees the system version, and I have no idea what the current version of the patch does at all, anymore... calibre already randomizes user agents, what is Debian trying to solve here? - Remove-Qt4-hack.patch/ Why are you doing this? It won't do anything or harm anything, unless someone has a pre-2.0 plugin installed, and this code is meant to prevent such plugins from breaking anything. Sure, it's unlikely such plugins still exist, but... it's not needed in order to package calibre on Debian, so why patch the code? In order to make it prettier? Submit upstream patches, in that case, but this is not Debian's job. - Don-t-load-external-URLs-for-privacy.patch The code you are patching is the code used to generate an HTML file which is uploaded to the upstream author's website, at https://plugins.calibre-ebook.com/ It's entirely reasonable for it to therefore use urls pointing at said website, but, it's not used in the calibre package at all and should therefore be ignored, rather than distracting efforts by making sure such a patch still applies. - Disable-update-check-by-default.patch While I'm on the topic of Debian-specific patches... this patch seems to cause calibre to start up with the update checker disabled, but that will disable both the application version check and the plugins version check, and I don't believe the latter is appropriate to disable. Please check if this is overreaching, and find a more targeted patch if so. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#947390: calibre should run the project unittests
Package: calibre Version: 2.5.0+dfsg-1 Severity: important calibre contains many unittests intended to verify that the package functionality works, which among other things verifies that every file imports cleanly, and that various common causes of a broken installation are not in effect. Please ensure these unittests are run to sanity-check the build, and fix any issues it may encounter. In order to run the unittests, you will need to execute via an X display server, for example using xvfb-run. Previous bugs that likely would have been avoided if the unittests were run, include (from my quick perusal): bug #934000 bug #941806 bug #906572 bug #932044 bug #941802 bug #866102 -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#947391: Please do not disable the plugin updater
Package: calibre Version: 2.5.0+dfsg-1 Regarding the patch: https://sources.debian.org/src/calibre/4.6.0+dfsg-1+exp1/debian/patches/Disable-plugin-dialog.patch/ "It uses a totally non-authenticated and non-trusted way of installing arbitrary code." But, this only removes the most visible location of the plugin downloader, not all of them, and furthermore, the rationale is incorrect, at least for as long as I can remember plugin updates are donloaded via secure HTTPS connections from the calibre author's website (which hosts the plugins). Getting onto the list of plugins requires manual whitelisting by the mobileread.com community moderators. And installing plugins is a 100% optional opt-in action which gives the user choice, albeit to install code not vetted by Debian, but thirdparty plugin stores are hardly the worst crime in the world. Please reconsider the patch -- it causes a grave lack of functionality to most power users of the application and is a source of friction with upstream. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#936270: Any update? We'll remove python-routes soon
On 12/25/19 6:59 PM, Norbert Preining wrote:
> Hi Eli,
>
> On Wed, 25 Dec 2019, Eli Schwartz wrote:
>> Are we discussing calibre itself, here, or the plugins? It's been
>> previously agreed that calibre itself is mostly ready.
>
> Indeed, unfortunately all the fixes in the py3 branch are not merged
> into a released tarball, and I am not eager to try to create orig
> tarballs myself from the git repo (I looked into it, but it seems a lot
> of stuff is needed in addition).
There's a totally unstable source tarball at
https://download.calibre-ebook.com/betas/, if you download a copy of it
for when it gets inevitably deleted and replaced by a new beta.
There's no PGP signatures for those files, though.
The release tarballs can be created in a simple enough fashion, the same
way I generate my daily builds from git:
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=calibre-git
Take a look at the source files I list there and the sequence of
commands I run in the build() shell function. I have tried to comment
anything I think might not be obvious in purpose.
One source of awkwardness is that the calibre-translations repo is not
versioned, so you either use whatever git master is at the time of
building, or else you use an archive created whenever you froze the sources.
>> That being said, given Debian deletes the plugin installer from the
>> menu, I'm not sure why Debian cares if plugins work.
>
> Huuu Maybe you are using something else, but **my** calibre has it:
> Preferences -> Plugins ... I can (and do!) install plugins, both from
> files as well as from the directory. And do updates.
"Preferences" has a dropdown action, which I suspect is the main way
people find the feature.
Partially removing the feature but still leaving it in there seems like
a very inaccurate way to address the (invalid) bug #640026, but I digress...
> You probably mean that piece of patch:
> --- calibre-debian.git.orig/src/calibre/gui2/actions/preferences.py
> +++ calibre-debian.git/src/calibre/gui2/actions/preferences.py
> @@ -30,8 +30,6 @@ class PreferencesAction(InterfaceAction)
> pm.addAction(QIcon(I('config.png')), _('Preferences'),
> self.do_config)
> cm('welcome wizard', _('Run Welcome &wizard'),
> icon='wizard.png', triggered=self.gui.run_wizard)
> -cm('plugin updater', _('Get plugins to enhance calibre'),
> -icon='plugins/plugin_updater.png',
> triggered=self.get_plugins)
> if not DEBUG:
> pm.addSeparator()
>
> ACtually I have no idea what it is undoing, because in my preference
> dialog I see and can update plugins, and grepping for get_plugins there
> are indeed several places where it is used.
I know *what* it's undoing, but I don't know *why*.
"What" it is doing, is removing the most visible method for downloading
plugins, thereby hiding the feature but leaving it available if you're
persistent enough.
If I had to take a wild guess, I'd think the idea is to discourage
people from using it without actually removing it...
> So bottomline, yes, Debian users *can* and *do* use plugins.
... meaning this is a deprioritized use case.
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User
signature.asc
Description: OpenPGP digital signature
Bug#936270: Any update? We'll remove python-routes soon
On 12/25/19 3:38 PM, Thomas Goirand wrote: >> I have more or less given up on my opposition and go with the flow, so >> if it is RC it is RC and I upload the Py3 version with its shortcomings. > > Hopefully, this sad situation will soon be addressed. > > If you need some help with the Py3 porting, I'd be happy to help with > that. Maybe this can help: you could give a go with something like this: > > apt-get install sixer > for i in $(find . -iname '*.py') ; do > echo "===> $i" > sixer all -w $i > done > > This usually gives rather good (but often incomplete) results, if you > address all of the warning it shows (which are usually not hard to fix, > like print() calls for example), and if there's no too hard to address > bytes vs str problems. Are we discussing calibre itself, here, or the plugins? It's been previously agreed that calibre itself is mostly ready. The debian package maintainer doesn't have the power to fix arbitrary user-installed plugins, hence why the community of *users* and plugin creators is working on porting them. The "shortcomings", then, are mainly about the almost complete lack of plugin support (as of today). That being said, given Debian deletes the plugin installer from the menu, I'm not sure why Debian cares if plugins work. ... There are also sporadic bug fixes for python3 compatibility as the beta builds continue to see use, and users continue to find miscellaneous errors when trying to use it with python3. 13 years of the program history says it's unlikely to crash at all under python2; it is thus infinitely safer that way. python3 means you must *expect* occasional issues where the port is incomplete. Thus there is value in sticking with python2 for as long as possible, lest you receive odd bug reports on occasion. But you'll need to decide on a balance yourself. Personally, I have the luxury of developing for a distro where it is much easier to add and remove packages and roll out major updates on a whim. And so I exercised my whim and uploaded a python3 build of calibre, so that my users can choose whether to install it for python2 or python3. I'll most likely leave it that way until calibre releases python3 support from beta. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#936270: calibre: plugins are now being ported to python3
A little over an hour ago, Kovid has released Windows/Linux/macOS binary builds of a python3 version of calibre, and alerted the plugin developer community that it is time to start porting. Watch this space for updates: https://www.mobileread.com/forums/showthread.php?t=325721 -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#936270: calibre: does not depend on cherrypy for a long time now
Hi. I notice you've all made quite a kerfuffle over the cherrypy module, with some people wishing to remove it for python2 from the Debian archives, and some people wishing to keep it because calibre depends on it. Please be advised that the calibre program dropped its dependency on cherrypy in version 3.0, with the complete from-scratch rewrite of its content-server component. This was a full major version and (as of the time of this writing) 52 feature releases ago. The removal occurred on Sun May 21 04:09:11 2017 via this commit: https://github.com/kovidgoyal/calibre/commit/5ed88a0bf596ea4389ac4fe08ccf249c7693d04d Please remove this ancient, unused dependency from the Debian packaging for calibre, thereby clearing the way to dropping the python2-cherrypy module. All it does is waste the disk space of calibre users. -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#941969: Arch Linux API for getting package information
In order to get information about a package, you add "json/" to the link. So, https://www.archlinux.org/packages/community/x86_64/diffoscope/ becomes https://www.archlinux.org/packages/community/x86_64/diffoscope/json/ Since this hardcodes architecture and repository information, you could do a search and get json instead. Given this exact-name search: https://www.archlinux.org/packages/?name=diffoscope You can get json like this: https://www.archlinux.org/packages/search/json/?name=diffoscope You should generally only get one search result due to the exact-name search, but if the package is in both the "community" repository and the "community-testing" repository, you could end up with two results, the -testing version being newer. You could either try to check that by hand, or add the search terms &repo=Core&repo=Extra&repo=Community&repo=Multilib to hardcode which repos you want to search in. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#896818: [Pkg-utopia-maintainers] Bug#896818: libnma over GI not working
On 06/26/2018 10:10 PM, Eli Schwartz wrote: > On Tue, 24 Apr 2018 23:07:25 +0200 Michael Biebl wrote: >> Thanks for the bug report. >> Seems we don't have any package in stretch yet, which uses >> gir1.2-nma-1.0, which is probably why this issue has went unnoticed. >> >> But that also means, it's probably not that important to fix this via a >> stable upload. Or put this differently: Why do you want to have this >> fixed in stretch, is there any software you use in stretch that requires >> gir1.2-nma-1.0? > One possibly good reason to get this fixed is because, Cinnamon will not > merge this PR until you do: https://github.com/linuxmint/Cinnamon/pull/7486 > > And this PR makes Cinnamon work better and support new features, like > https://github.com/linuxmint/Cinnamon/pull/7118 > > Since the current state of things is that the bindings are badly broken, > and this does nothing other than to make things work the way they were > always meant to, I think it is reasonable to backport this pretty minor fix. > > > End result: peoples' custom scripts no longer crash and burn. > > Also, downstream developers of software that is in fact in stretch, do > not need to burden themselves by refusing to improve their software on > the grounds that it will crash and burn on stretch. This affects both > people who build their own packages for testing, and people who develop > a respin of stretch, which is supposed to showcase their software. > > Like Linux Mint Debian Edition, which is based on stretch, but includes > the latest Cinnamon packages. > > Also, if downstream developers are afraid to use non-deprecated > libraries like libnma because it will break on Debian, it means other > distros which use more recent networkmanager versions cannot benefit > from fixes and improvements, which in its own small way drags down the > entire Linux ecosystem. As an Arch Linux user (and maintainer of the > Cinnamon desktop on Arch) I'd like to see Cinnamon be improved... > > It's such a simple fix... > > Please note also that the commit has been backported to > network-manager-applet's *maintenance* 1.4 branch, and is available in > 1.4.8 (released 3 weeks ago on 01 Jun 2018). > > Upstream-sanctioned maintenance releases which fix bugs resulting in > completely broken package components, are good candidates for inclusion. :) You yourself requested that the cinnamon maintainers apply downstream patches to cinnamon in order to stop using libnm-glib, cf. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857231 I'm really trying not to feel like this vindicates my extreme pessimism about Debian as a distribution, but when you pull stunts like this it's difficult. On the one hand you keep filing bugs against any packages which dare to code against libnm-glib/libnm-gtk. On the other hand, you refuse to fix the things you want developers to migrate *to*, on the grounds that they're not yet using it! If you would just *fix a completely broken component of networkmanager*, then progress in that upstream PR would move forward, and hopefully be merged into the next cinnamon release. You could then drop those patches from the cinnamon package. This would help move Debian away from being a janky distribution that obsessively patches everything to death. :( -- Eli Schwartz Bug Wrangler and Trusted User
Bug#892998: libnm/client: proxy *_enabled and metered properties to the wrong object make application using it crashing
Please note also that this commit was cherry-picked upstream for the network-manager 1.6 and 1.8 maintenance branches. See https://github.com/NetworkManager/NetworkManager/commit/b2af5f7ab676675a496adfa08541ecca43a9d9f8 It would be nice to have this fixed, for reasons similar to 896818 It's a maintenance branch fix which results in software working as it was always intended to, instead of crashing (which it was not intended to do). It makes users' custom scripts no longer crash and burn, and it makes developers of software that runs on stretch, more comfortable about considering improvements to their software which rely on libnm not being broken. Even if it is unlikely that newer versions of Cinnamon itself will be backported to stretch, Linux Mint Debian Edition which is a respin of stretch, will have those packages, Cinnamon developers will likely want to make personal builds for testing purposes, etc. so having this not crash can only be a good thing... And it means upstream software can get developed faster, which in the long run means that newer versions of Debian are more likely to see useful improvements faster, and other distros with newer versions of networkmanager that don't crash because of this bug, will be able to see those improvements immediately. -- Eli Schwartz Bug Wrangler and Trusted User
Bug#896818: [Pkg-utopia-maintainers] Bug#896818: libnma over GI not working
On Tue, 24 Apr 2018 23:07:25 +0200 Michael Biebl wrote: > Thanks for the bug report. > Seems we don't have any package in stretch yet, which uses > gir1.2-nma-1.0, which is probably why this issue has went unnoticed. > > But that also means, it's probably not that important to fix this via a > stable upload. Or put this differently: Why do you want to have this > fixed in stretch, is there any software you use in stretch that requires > gir1.2-nma-1.0? One possibly good reason to get this fixed is because, Cinnamon will not merge this PR until you do: https://github.com/linuxmint/Cinnamon/pull/7486 And this PR makes Cinnamon work better and support new features, like https://github.com/linuxmint/Cinnamon/pull/7118 Since the current state of things is that the bindings are badly broken, and this does nothing other than to make things work the way they were always meant to, I think it is reasonable to backport this pretty minor fix. End result: peoples' custom scripts no longer crash and burn. Also, downstream developers of software that is in fact in stretch, do not need to burden themselves by refusing to improve their software on the grounds that it will crash and burn on stretch. This affects both people who build their own packages for testing, and people who develop a respin of stretch, which is supposed to showcase their software. Like Linux Mint Debian Edition, which is based on stretch, but includes the latest Cinnamon packages. Also, if downstream developers are afraid to use non-deprecated libraries like libnma because it will break on Debian, it means other distros which use more recent networkmanager versions cannot benefit from fixes and improvements, which in its own small way drags down the entire Linux ecosystem. As an Arch Linux user (and maintainer of the Cinnamon desktop on Arch) I'd like to see Cinnamon be improved... It's such a simple fix... Please note also that the commit has been backported to network-manager-applet's *maintenance* 1.4 branch, and is available in 1.4.8 (released 3 weeks ago on 01 Jun 2018). Upstream-sanctioned maintenance releases which fix bugs resulting in completely broken package components, are good candidates for inclusion. :) -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
On 02/18/2018 04:04 PM, Sven Joachim wrote: > Historical reasons, POSIX has only mandated "command -v" since 2008 and > Debian does not even require that /bin/sh supports it, since the Policy > Manual specifies SUSv3 aka POSIX.2001 as the baseline[1]. As a > consequence, the minimal posh shell does not support[2] "command -v" > (not that using posh as /bin/sh is actually supported in Debian). > > See also bugs #747320[3] (talks about the "type" command, but mentions > "command -v" in the last comment) and #864615[4] (requests that Debian > should upgrade to SUSv4). > > Cheers, >Sven > > > 1. https://www.debian.org/doc/debian-policy/#scripts > 2. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397601 > 3. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747320 > 4. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864615 Hmm, well, it would be exceedingly nice to support a POSIX standard that is *only* a decade old. That debian policy mandates the local keyword on top of POSIX, as well as completely frivolous things like echo -n (even though printf is already allowed and unambiguously better than any conceivable version of echo in any shell implementation, no matter how you want to use it) so it would be nice if there was at least one reliable way to figure out if a command exists which I would think is more important. ... Having never heard of posh before (except in the context of powershell, which I severely doubt is what you meant), I looked it up. Apparently busybox/dash were not sufficient as regards POSIX-compliant sh shells with a super minimal footprint, so debian decided to strip a third shell down for no reason other than to remove everything which is not totally vital to the standardized sh requirement as specified there. I... guess? this could make sense purely for testing purposes, but it seems a bit of a reach to support that for end users *just because* it exists. Can I at least hope that it has meaningful performance benefits over dash??? Meh, I guess this is why we can't have nice things. Woe betide the person attempting to write modern yet POSIX compliant scripts in a generally cross-distro manner. Even Debian cannot do it, and they're the ones who made the big push to get rid of bashisms. I guess if I want my cross-distro scripts I will have to settle for GNU bash in all its tremendous [sic] glory. If I want to implement some tool I have no time to spelunk around the history of SUSv3 to determine if every outdated version of a standard supports it. Well, hopefully this works. I even fixed a couple extra things as a bonus. But this is getting rather exhausting... https://salsa.debian.org/eschwartz-guest/xorg-server/commits/debian-unstable -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
On 02/06/2018 05:58 AM, Emilio Pozuelo Monfort wrote: > There are some differences in command vs which, e.g.: > > emilio@tatooine:~$ which ls > /bin/ls > emilio@tatooine:~$ command -v ls > alias ls='ls --color=auto' > > Some special casing would need to be added to handle aliases, whereas with > 'which' we don't. > > OTOH portability is a good goal and I'm happy that you're using xvfb-run, so > if > we can come up with a good and clean solution then that'd be good. Well, this was a rather interesting summary of options (including why the which command itself might not be what you think it is): https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then I'm not sure I understand the case for avoiding command -v, as it will only fail if the user has somehow set an alias inside a non-interactive script, which implies either modifying the script, or *sourcing* it from an interactive shell. But, there are other options. If the script was strictly bash-only, you could use type -P. From testing bash, dash, and busybox ash, in all cases `hash $command` exited with no output and a successful status, if it detected a command executable in $PATH (bash went so far as to check if the command has executable permissions, which is also what GNU which does), OR it exited with a "permission denied" or "not found" on stderr and a return code of 1. hash is also POSIX. Since xvfb-run is not trying to remember the location of the command, only check that one exists on disk (i.e. `alias xauth=asdafsjdlfkjlsdkfjslfs` would currently break everything if someone was indeed mad enough to use aliases, and also *wanted* to break things), this seems like a reasonable solution as well. -- Eli Schwartz Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Bug#889676: xvfb: xvfb-run script contains an unnecessary dependency on the external tool "which"
Package: xvfb Version: 2:1.19.6-1 Severity: minor Arch Linux has imported the xvfb-run script from Debian's package, but our package dependencies do not mandate that the "which" utility be installed. OTOH we do have it in our base package group, which users are expected to have installed, although there is a bit of bikeshedding about whether these unstated dependencies should actually be explicitly listed... See the following xvfb bugreport on our bugtracker: https://bugs.archlinux.org/task/56997 All that being said, this immediately made me think, why is the script using `which` at all, rather than the POSIX `command -v` which is far more portable as any #!/bin/sh shell has this as a builtin. It also provides a micro-optimization by avoiding an external subprocess. Please consider making this script more reusable by switching to the POSIX shell builtin. Example output on a system which does not have /usr/bin/which available: $ xvfb-run some_command /usr/bin/xvfb-run: line 139: which: command not found xvfb-run: error: xauth command not found (This error message seems rather redundant.) -- Eli Schwartz Bug Wrangler and Trusted User
