Custom Query (1145 matches)

Reported by andersk, 15 years ago.

Our original intention with the config-package-dev API was to disallow transformation of a generated conffiles, because there is no md5sum with which to check that the file is unmodified in the current build environment. Instead, one should transform the source of the generated conffile, e.g. /usr/share/kerberos-configs/krb.conf.template instead of /etc/krb.conf.debathena, as I think we do with all the current Debathena packages.

However, a quoting bug in check-files.mk causes this test to never trip:

$(call debian_check_files_tmp,%): package = $(shell dpkg -S $(name) | grep -v "^diversion by" | cut -f1 -d:)
$(call debian_check_files_tmp,%): $(truename)
	[ -n $(package) ]
	…

since both [ -n ] and [ -n foo ] return true.

Apparently XVM is a consumer of this API bug (/etc/postgresql/8.3/main/postgresql.conf in invirt-database), although that could easily be fixed.

Reported by mitchb, 15 years ago.

If the owner of a machine uses the GUI printing administration application to choose a default printer for their machine, this isn't honored by the commandline utilities if the machine prefers lprng. We currently check the PRINTER environment variable, and then hesiod clusterinfo to find a default queue. We should check if a default queue has been set in cups, and use that before turning to hesiod since it reflects a local sysadmin's choice.

One could argue that if we find the cups default queue, we should use the cups tools. However, if a machine prefers lprng normally, and a sysadmin uses the GUI to choose a default printer, it shouldn't cause which printing system their commandline apps use to suddenly change, so we should continue to use the system preference, and simply take the name of the queue from cups.

The attached patch uses python-cups, which isn't in Etch, so this may need to wait until Etch is desupported. I'd first worked out a solution that finds the default printer in /etc/cups/printers.conf. Unfortunately, the permissions on that file are fascist, so that doesn't work for mortals.

Reported by geofft, 15 years ago.

The debathena-misc-glue package installs a /usr/bin/acroread attachandrun script, which conflicts with installing Acrobat from the Ubuntu partner repository:

Selecting previously deselected package acroread.
(Reading database ... 400376 files and directories currently installed.)
Unpacking acroread (from .../acroread_9.1.3-1jaunty1_i386.deb) ...
dpkg: error processing /var/cache/apt/archives/acroread_9.1.3-1jaunty1_i386.deb (--unpack):
 trying to overwrite `/usr/bin/acroread', which is also in package debathena-misc-glue

Importantly, debathena-misc-glue does not declare a conflict with the acroread package. This would be an RC bug if this were Debian/Ubuntu?...

However, even with the declared conflict, the package is a hard dependency of debathena-login-graphical, so we need to do something more:

1. Make it a recommendation of login-graphical
2. Make the package put the script somewhere other than /usr/bin, or create those files if they don't exist in some script (instead of packaging them)
3. Split the package into debathena-acroread-glue etc., and make debathena-misc-glue a metapackage that depends on debathena-acroread-glue | acroread, etc.

Thoughts? See also  1019855, which could be solved with a local install of 64-bit acroread... but more generally, on systems with Debathena installed that don't have reliable AFS, we shouldn't prevent installing a local acroread.