Bug#933016: [Pkg-rust-maintainers] Bug#933016: rustc: status of nightly toolchains

[Angus Lees]

I think you are trying to compile a project that requires in-development
features of the Rust compiler.  I think you also want to do that without
getting involved in the Rust upstream development process and tools (like
rustup).  I don't think there is a way to resolve those two conflicting
goals to anyone's satisfaction.

I think the long-term solution for your project is to move to using only
stable Rust features (which would then be supported by the rustc Debian
packages).

(The current Debian/Rust choice is to only package stable toolchain
releases, as we see that as our role (as a distro) within the Rust
ecosystem.  If you want to develop rustc itself, or work with
unreleased/unstable features, then you will need to be prepared to join the
Rust community and their recommended tools (probably rustup, not apt-get).)

 - Gus

On Fri, 26 Jul 2019 at 05:09, Dmitry Bogatov  wrote:

>
> Source: rustc
> Severity: wishlist
>
> Dear Maintainer,
>
> are there any plans to add into Debian version of Rust compiler, that
> supports #![feature]?
>
> Currently, to compile project I am interested in, I am forced to use
> `curl | sh` installation, which is quite creepy.
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers buildd-unstable
>   APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (500,
> 'testing'), (1, 'buildd-experimental'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL
> set to en_US.utf8), LANGUAGE=C.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
> to en_US.utf8)
> Shell: /bin/sh linked to /usr/bin/dash
> Init: runit (via /run/runit.stopit)
> LSM: AppArmor: enabled
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>


-- 
 - Gus

Bug#915675: libasound2-data: Kernel 4.18 change breaks WD15 dock usb audio

[Angus Lees]

Yes, understood.

I don't know much about these files, but I gather the udev rule is the
entrypoint and refers to the desired file by name.  Perhaps we can have two
files and make the udev rule point to the right one by kernel version?
(assuming we can't do anything clever within the file itself)

 - Gus

On Thu, 6 Dec 2018 at 18:36, Elimar Riesebieter  wrote:

> * Angus Lees  [2018-12-06 09:29 +1100]:
>
> [...]
> >
> > After *much* debugging, I stumbled across
> >
> https://github.com/edrose/dell-dock-audio-fix/issues/2#issuecomment-440420105
> >
> > Apparently the device was renamed in the kernel, and
> > /usr/share/alsa/ucm/Dell-WD15-Dock/HiFi.conf needs to be updated
> > accordingly (s/WD15Dock/Dock/).  I can confirm this change (followed
> > by pulseaudio restart) fixed things immediately for me.
>
> There is a patch in upstreams git. But we have to find a solution
> where kernels < 4.18 are working as well. Thats not that easy,
> though.
>
> Elimar
> --
>   The path to source is always uphill!
> -unknown-
>


-- 
 - Gus

Bug#915675: libasound2-data: Kernel 4.18 change breaks WD15 dock usb audio

[Angus Lees]

Package: libasound2-data
Version: 1.1.7-1
Severity: normal

Dear Maintainer,

The usb-audio interface on my Dell USB-C WD15 dock stopped working
recently.  The immediate symptom is the device gone from pulseaudio,
with:
E: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
E: [pulseaudio] module.c: Failed to load module "module-alsa-card"
(argument: "device_id="1" name="usb-Generic_USB_Au
dio_200901010001-00"
card_name="alsa_card.usb-Generic_USB_Audio_200901010001-00"
namereg_fail=false tsched=yes fixed_
latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes
card_properties="module-udev-detect.discovered=1""): in
itialization failed.

After *much* debugging, I stumbled across
https://github.com/edrose/dell-dock-audio-fix/issues/2#issuecomment-440420105

Apparently the device was renamed in the kernel, and
/usr/share/alsa/ucm/Dell-WD15-Dock/HiFi.conf needs to be updated
accordingly (s/WD15Dock/Dock/).  I can confirm this change (followed
by pulseaudio restart) fixed things immediately for me.

 - Gus

-- System Information:
Debian Release: buster/sid
 APT prefers testing
 APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

libasound2-data depends on no packages.

libasound2-data recommends no packages.

Versions of packages libasound2-data suggests:
ii  alsa-utils  1.1.7-1

-- no debconf information

Bug#913572: [Pkg-rust-maintainers] Bug#913572: Shouldn't shipping broken symlinks be against policy?

[Angus Lees]

I think I am responsible for this dangling symlink :)

The issue is that the symlink target is _not_ in the 'rust-doc' package,
but in the 'gdb-doc' package which has nothing to do with the rust src
package, nor the rust maintainers.  Moving the rust-gdb symlink into
gdb-doc is not appropriate.

Background: rust-gdb is a tiny shell wrapper around gdb, that provides some
extra command line flags to set things up for debugging a rust program.  It
doesn't have a manpage upstream.  We could write one, but it would look
almost exactly like the gdb manpage since - again - just a wrapper.

So currently the rust-gdb package ships a rust-gdb.1.gz symlink that points
to gdb.1.gz (from the gdb-doc package).  Iirc, I originally created it as a
".so" stub troff file pointing to gdb.1, but some tool along the way
strongly suggested I replace that with the dangling symlink you see today.

Suggestions welcome - I imagine this is not a unique situation.  I think
our options are:
- no rust-gdb manpage at all
- a .so stub or symlink to gdb.1 (current situation)
- a manually-created stub manpage that just refers the reader to
gdb-doc/gdb.1
- (something else?)

I suspect you're going to choose that 3rd option, since it is the least
terrible and suggestions are almost free to make :)

NB: I'm ignoring the implied larger question of whether shipping broken
symlinks should or should not be against Debian policy.  I'll leave that
for the gallery to consider.

 - Gus

Bug#906585: [Pkg-rust-maintainers] Bug#906585: rustc: Backport the fix for Rust#44800 to stretch

[Angus Lees]

On Sun, 19 Aug 2018 at 20:39 Moritz Mühlenhoff  wrote:

> On Sat, Aug 18, 2018 at 03:19:46PM +0200, Nicolas Braud-Santoni wrote:
> > Would it be possible to turn it into a security upload, along with a
> binNMU of
> > all packages that were built with rustc (<< 1.24.1) ?
>
> 1.24 will reach stretch via the next 9.5 point release. I don't see any
> need to expedite this. Do we actually have any application in stretch yet
> which
> is written in Rust?
>

No, not in stretch (other than the rustc/libstd-rust toolchain itself).

 - Gus

Bug#903110: [Pkg-rust-maintainers] Bug#903110: rustc: wasm32 target is enabled, but doesn't work

[Angus Lees]

Fwiw: Unless there is something that acts on `rustc --print target-list`
without applying some human judgement first, I would rather we just
reassigned this bug to LLVM and enabled wasm.  "Fixing" this in rustc, and
then unfixing it again once we add support to LLVM seems a little bit like
chasing our tails...

Ditto for other cross-compile targets (windows, android, etc) that are
reported in `target-list` but don't _actually_ work due to other missing
parts of the toolchain.

 - Gus

On Fri, 6 Jul 2018 at 19:39 Niels Langager Ellegaard <
niels.langager.ellega...@greve-gym.dk> wrote:

>
> Package: rustc
> Version: 1.26.2+dfsg1-1
> Severity: minor
>
> Dear Maintainers,
>
> The wasm32-unknown-unknown target is enabled in rustc, but it doesn't
> work.
> Alledgedly the problem is that the coresponding webassembly target isn't
> enabled in
> llvm. I guess that the target should be disabled in rustc if it doesn't
> work.
> (But in the long run it would be great to have the target enabled)
>

Bug#898792: [Pkg-rust-maintainers] Bug#898792: rust-src: [RC] embedded copy of normalize.css

[Angus Lees]

severity 898792 normal
thanks

Downgrading severity, since I think we'd all agree that using a single CSS
file from one source rather than another does not render the entire Rust
toolchain as unusable or not suitable for release ;)
(and the Debian policy section cited is a "should" not "must" directive)

 - Gus

On Wed, 16 May 2018 at 06:54 Bastien ROUCARIÈS 
wrote:

> Package: rust-src
> Version: 1.24.1+dfsg1-1
> Severity: serious
> Justification: Policy 4.13
>
> This package include embedded copy of normalize.css
> /usr/src/rustc-1.24.1/src/librustdoc/html/static/normalize.css
>
> Please use the package libjs-normalize.css instead to use local copy
>
> Thanks
>
> Bastien___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>

Bug#884775: [Pkg-rust-maintainers] Bug#884775: /usr/bin/rustc: Error Compiling Code: "attempt to use impure library"

[Angus Lees]

tags 884775 + unreproducible notabug
close 884775
thanks

I suspect the original issue was caused by having a non-standard "ld" in
your $PATH - specifically, I suspect it was the guix ld-wrapper[1].  (Or
perhaps a non-standard "cc" that in turn uses this guix ld)

The reply to your stack overflow question[2] suggests
that GUIX_LD_WRAPPER_ALLOW_IMPURITIES=y should disable this assertion in
ld-wrapper.  .. Or of course fiddling with $PATH such that you return to
using the standard Debian gcc/binutils binaries.

If any of that sounds incorrect, please reopen this bug.

[1]
https://github.com/drewc/guix/blob/d34c0ac6e9c669702bc4957faa5ee51f2b9465c3/gnu/packages/ld-wrapper.scm#L142
[2]
https://stackoverflow.com/questions/47737761/rust-on-debian-9-2-error-due-to-impure-library

 - Gus

Bug#890213: squid-deb-proxy-client should try all browse domains

[Angus Lees]

Package: squid-deb-proxy-client
Version: 0.8.14
Severity: normal

Dear Maintainer,

I'm trying to setup static dns-sd entries for my apt cache (I don't
want to run avahi/mDNS on my proxy server).  This involves creating
_apt_proxy._tcp entries on a domain other than .local[1].  For reasons
that are not clear to me, avahi does not automatically merge browsing
domains, and leaves this up to the application[2].

Iiuc, squid-deb-proxy-client should iterate over the domains returned
by `avahi-browse -D` (and .local), doing something like (pseudo-code):

 for dom in local $(avahi-browse -D); do
if avahi-browse -d $dom _apt_proxy._tcp; then
   break
fi
 done


[1] http://www.dns-sd.org/serverstaticsetup.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=534076#c3

Thanks,
- Gus

-- System Information:
Debian Release: buster/sid
 APT prefers testing
 APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages squid-deb-proxy-client depends on:
ii  apt  1.6~alpha7
pn  avahi-utils  
ii  python   2.7.14-4

squid-deb-proxy-client recommends no packages.

squid-deb-proxy-client suggests no packages.

-- no debconf information

Bug#846177: [Pkg-rust-maintainers] Bug#846177: A rustc-src package would be useful for racer completion

[Angus Lees]

On Tue, 29 Nov 2016, 10:51 Dato Simó  wrote:

> It would be nice to have a rustc-src package containing the source for
> Rust itself.
>
> The (widely-used) racer completion engine needs access to the source in
> order to work.
>

I'm becoming a big fan of racer, so I'm all for this!  I haven't looked at
the internals however - I presume racer only needs the source for std (and
core) not the compiler itself?

 - Gus

>

Bug#834003: rustc: armhf FTBFS because upstream assumes armhf has neon but debian does not

[Angus Lees]

A relevant upstream discussion[*] seems to suggest that we should be using
arm-unknown-linux-gnueabihf and not armv7-*
I think this results in armv6, which sounds preferable to armv7+neon, and I
don't think will cause any other issues (Steve?).  Other options include
creating a new combination of "armv7 without neon" using either build flags
(see [*]) or via a new armv7-debian-linux-gnueabihf triple definition.

[*] https://users.rust-lang.org/t/rust-on-armv7l-with-no-neon-support/6037

 - Gus

Bug#832565: [Pkg-rust-maintainers] Bug#832565: rustc: don't embed llvm in librustc_llvm

[Angus Lees]

(Capturing some investigation I dumped into IRC)

On Wed, 27 Jul 2016 at 09:54 Ximin Luo  wrote:

> librustc_llvm-xx.so is approx 30MB, taking about half the space of
> libstd-rust-xx.
> Upstream tells me that this is due to embedding pretty much all of LLVM.
>
> We should explore options to make it instead dynamically link against LLVM,
> since that is the Debian convention. (Upstream probably won't spend too
> much
> time on this.) This would reduce the size of libstd-rust-xx by about half.
>

The relevant piece of code looks like it's src/librustc_llvm/build.rs:
let kind = if name.starts_with("LLVM") {
"static"
} else {
"dylib"
};

I suspect if we remove this block (and the following cargo:rustc-link-lib
print statement), then the linker would just find shared versions of the
LLVM libs if available.

*However:* It seems our LLVM (or upstream llvm-config?) isn't ready to help
users use dynamic libraries.  Specifically the output of `llvm-config-3.8
--libs` mentions a bunch of libraries for which we only have .a versions.

Some old-ish (2010-2012) LLVM upstream discussion supports the idea that
llvm-config needs more work before this will "just work":
- https://groups.google.com/forum/#!topic/llvm-dev/g81Hcoy0stw
- https://llvm.org/bugs/show_bug.cgi?id=3201
- http://llvm.org/viewvc/llvm-project?revision=96559=revision

The conclusion in the above threads seems to be that we should just ignore
llvm-config, use what we (Debian) know about the build environment, and
manually specify something like "-L/usr/lib/llvm-$v/lib -lLLVM".  This
seems an easy decision for us (and other distros with controlled build
environments), but inappropriate for Rust upstream IMO.

The discussion in/around https://github.com/rust-lang/rust/pull/27937 seems
to imply that support *does* exist in some form for dynamic linking libLLVM
(and perhaps gentoo are already using it?), but I still think we may need
some changes to Debian's LLVM packaging in addition to rustc.deb build
tweaks.  Closer analysis of this discussion needed.

I agree that we will get little prioritisation from upstream on this, as
static linking LLVM is the *right* approach when using the vendored LLVM
sources.

(The size could further be reduced by splitting dev vs runtime shared
> objects,
> but upstream don't seem to be doing this themselves yet, and any work we do
> here should definitely be consulted with them first.)
>

If you're suggesting just moving some "dev only" libstd libraries
(librustc_*.so ?) entirely to the -dev (or rustc) package, then this is an
interesting thought.  I think trying to separate run-time from dev-time
quickly becomes equivalent to breaking libstd-rust-x.y into several
separate packages and just letting shlibdeps do its thing.  That seems
quite reasonable once we have non-rustc Rust applications and
libstd-rust-x.y size is a concern.

See the discussion in https://github.com/rust-lang/rust/issues/23366 for
some related discussion on reducing the size of libstd runtime libs by
stripping the (large!) .note.rustc section.  I think this is a separate
bug/issue, but note that breaking the current symlinks and having different
link-time (libstd-rust-dev) and run-time (libstd-rust-x.y) lib files
actually results in a *larger* on-disk size for rustc users.  I don't think
this is useful to explore until we have Rust application packages whose
users might not also have rustc installed.

 - Gus

Bug#819475: [Pkg-rust-maintainers] Bug#819475: Bug#819475: rustc not run depend on gcc 4.9.2

[Angus Lees]

On Wed, 30 Mar 2016 at 13:27 Lihe Wang 
wrote:

> #~ rustc hello.rs
> error: linking with `cc` failed: exit code: 1
> note: "cc" "-Wl,--as-needed" "-m64" "-L"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "hello.0.o" "-o" "hello"
> "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic"
> "-Wl,-Bdynamic"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6a154fe0.rlib"
> "/usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6a154fe0.rlib" "-l"
> "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt"
> "-l" "compiler-rt"
> note: /usr/bin/ld:
> /usr/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib(jemalloc.pic.o):
> unrecognized relocation (0x2a) in section `.text.malloc_conf_init'
> /usr/bin/ld: final link failed: Bad value
> collect2: error: ld returned 1 exit status
>

It looks like this is a change in recent binutils (see discussion in
Bug#808205) - which I _think_ means our static libraries (librust-std-dev)
need to depend on binutils >= 2.25.90.20151209-1.  I note in the glibc-dev
case, however, the decision was "I therefore don't think we need to fix
that at the glibc level. Either we just ignore the problem saying we don't
support partial upgrades or we try to find a global way to fix the
dependencies for all libraries."

Lihe: The short version for you is if you're trying to run a mixed
stable/testing system(*), then you will also need to install binutils from
testing.
(*) rather than rebuild rustc.deb from source for stable.  If we had enough
man-power, it would probably make sense for us to maintain a rustc.deb for
stable-backports.

 - Gus

Bug#811573: FTBFS with GCC 6: statement indented as if it were guarded by

[Angus Lees]

Urgh.  These aren't bugs, and it looks like we're going to have to add
"-Wno-error=misleading-indentation" (or disable the misleading-indentation
warning entirely).

 - Gus

Bug#791961: saned won't run from systemd (bad status=22 or procnum=1)

[Angus Lees]

Interesting. Yes, setting Standard Input=null/Output=syslog/Error=syslog
works for me with sane-utils 1.0.24-13 and systemd 224-1.

I think part of my earlier confusion was because I hadn't realised saned
(now) has native systemd socket-activation support, and didn't need to be
run in inetd-compatiblity mode (Input=socket/Output=socket) (verified by
reading the saned code).   The inetd-compat mode also works for me, but of
course the native support is more robust to drivers that incorrectly write
debugging to stdout.

I discovered along the way that Input=socket/Output=syslog makes saned
produce log messages that look like the connection comes from localhost
rather than real client IP (ie: I guess it is using getpeername on stdout,
not stdin), and presumably this combination also fails when saned tries to
communicate with the client using this incorrect stdout.  Given the
confusion in some of the discussions, I wonder if some people have also
been trying this incorrect combination.

Thanks for you patience Jorg,
 - Gus

On Sun, 30 Aug 2015 at 20:48 Jörg Frings-Fürst 
wrote:

> tags 791961 + moreinfo
> tags 791961 + jessie
> thanks
>
> Hello,
>
> first thanks to all for spending your time helping to make Debian
> better with this bug report.
>
> Please can someone testing the attached systemd fileson a jessie
> system?
>
> Many thanks!
>
>
> CU
> Jörg
>
>
>
>
> --
> New:
> GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
> GPG key (long) : 09F89F3C8CA1D25D
> GPG Key: 8CA1D25D
> CAcert Key S/N : 0E:D4:56
>
> Old pgp Key: BE581B6E (revoked since 2014-12-31).
>
> Jörg Frings-Fürst
> D-54526 Niederkail
>
> Threema: SYR8SJXB
>
> IRC: j_...@freenode.net
>  j_...@oftc.net
>
> My wish list:
>  - Please send me a picture from the nature at your home.
>
>
>

Bug#796256: [Pkg-rust-maintainers] Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

[Angus Lees]

On Mon, 31 Aug 2015 at 19:26 Ximin Luo  wrote:

> On 31/08/15 10:58, Sylvestre Ledru wrote:
> > Le 31/08/2015 10:37, Ximin Luo a écrit :
> >> On 31/08/15 08:59, Sylvestre Ledru wrote:
> >>> We are aware of this and we decided to take this approach on purpose
> for
> >>> now. This is not perfect but as rust is a moving target,
> >>> we took this shortcut. We hope they will be able to improve/fix that
> >>> upstream in the near future.
> >>>
> >> How is the hash generated and how do we guarantee that our hash matches
> with upstream's hash? Is there a way to calculate the hash *before* doing
> the build?
> > We are using upstream hash.
> >
>
> You could have been a bit more helpful. In fact the hash is generated only
> from the upstream version string, and *not* in the contents of the files
> (which is the first reasonable thought for things that are hashes).
>
> debian/rules:RUST_HASH := $(shell printf '%s' $(DEB_VERSION_UPSTREAM) |
> sed -e 's/\+dfsg[0-9]*$$//' | md5sum | head -c 8)
> configure:CFG_HASH_COMMAND="$CFG_MD5 -q | cut -c 1-8"
> configure:CFG_HASH_COMMAND="$CFG_MD5SUM | cut -c 1-8"
> mk/main.mk:CFG_FILENAME_EXTRA=$(shell printf '%s' $(CFG_RELEASE) |
> $(CFG_HASH_COMMAND))
>
> So this actually contains no extra information than the strings (e.g.)
> "1.3.0" or "1.3.0-beta.3" or "1.3.0-nightly" etc, but has the disadvantage
> of not being comparable.
>

This is the case for libstd, but not for other dylibs.  The idea is that
it's a hash of the ABI - that is, the compiler version and the version of
every dependent library. For rustc/std itself, there are no dependent
libraries, hence this is just a hash of the compiler version.  I think it
would be wrong in the general case to make this just the source version
string.  In addition, ordering makes no sense on the library files -
"1.3.0" is potentially totally different symbol mangling and embedded LLVM
bitcode to "1.3.1", and there is no meaning to sorting the two, except that
it probably corresponds to the file mtime order.

I actually think the hash thing is a pretty neat take on symbol
versioning.  I'm not sure how much of the original vision is going to
survive whatever is required to declare ABI stability, however.

 - Gus

Bug#791961: saned@.service systemd file is wrong (afaics)

[Angus Lees]

Indeed, I'm thoroughly confused by the conclusion in #782971 - it seems the
exact opposite of my experience just now with sane-utils 1.0.24-13 and
systemd 224-1.

For me, I needed to modify /lib/systemd/system/saned@.service and set both
Standard{Input,Output} to 'socket' to get saned working correctly over the
network.  This matches what I read in the systemd manpages and elsewhere
for inetd-compatibility.

-- 
 - Gus

Bug#796256: [Pkg-rust-maintainers] Bug#796256: Please consider packaging a Rust version that allows #![feature(...)]

[Angus Lees]

tags 796256 upstream wontfix
close 796256
thanks

On Fri, 21 Aug 2015 at 06:03 Josh Triplett j...@joshtriplett.org wrote:

 Quite a bit of the Cargo ecosystem makes use of #![feature(...)] to
 enable unstable features.  Rust release builds prohibit this by default:


 /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/lib.rs:12:1:
 12:18 error: #[feature] may not be used on the stable release channel
 /home/josh/.cargo/git/checkouts/rust-fuse-e03750e721e8762f/master/src/
 lib.rs:12 #![feature(libc)]

   ^

 Please consider providing a package of rustc that allows these
 feature-gates.
 (That doesn't necessarily have to be a nightly version.)


Hrm.  I think this means you're asking for a rustc-nightly.deb - or some
other arbitrary periodically updated snapshot of rustc compiled with
--channel=nightly to unlock opt-in unstable features.

I can completely understand this desire, but I think this inconvenience is
a completely desired outcome of the Stability as a Deliverable Rust
strategy[1].  As a *distribution* I feel like shipping a nightly package
would be directly subverting this strategy and as such I consider this a
wishlist bug against the upstream policy/mechanism.

Personally, I'm reluctant to break the release-channels experiment so close
to the 1.0 release.  We may well declare it failed and do something
different in future, but right now I think Debian has an important role to
play in demonstrating what the stable Rust world looks like and providing
pressure for upstreams to avoid unstable features.

I hope you can understand why I'm going to close this upstream+wontfix - at
least for now.  Please feel free to reopen and/or continue the discussion
if you disagree.

[1] http://blog.rust-lang.org/2014/10/30/Stability.html

 - Gus

Bug#793147: [Pkg-rust-maintainers] Bug#793147: rustc FTBFS on mipsel: configure: error: unknown CPU type: mips

[Angus Lees]

On Wed, 22 Jul 2015 at 04:48 Gustavo Prado Alkmim alk...@ic.unicamp.br
wrote:

 Package: rustc
 Version: 1.1.0+dfsg1-1
 Package is failing to build on buildd. I'm working on a fix and I will
 attach it as soon as possible.


Oops.  This is a known issue (the toolchain bootstrapping currently only
works on i386+amd64), and please don't spend time on this - unless you want
to invest a fairly significant amount of effort (in which case, please
carry on! ;)

The Architecture: amd64 i386 field was mistakenly removed (by me) in the
1.1.0 upload.  I'll restore it asap to avoid consuming the time of porters
investigating an already known issue.

 - Gus

Bug#792908: lldb: Please provide a lldb.1 manpage symlink to lldb-$version.1

[Angus Lees]

Package: lldb
Version: 1:3.5-25
Severity: wishlist

This package provides an unversioned lldb executable.  For all the
same reasons, it would be nice to have an unversioned lldb manpage.

(I would like to take advantage of this to provide the manpage in the
rust-lldb package without adding a dependency on a specific lldb
version.  rust-lldb is a trivial shell wrapper around (unversioned)
/usr/bin/lldb)

 - Gus

-- System Information:
Debian Release: 8.0
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lldb depends on:
ii  lldb-3.5  1:3.5-10

lldb recommends no packages.

lldb suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#760530: aspell-en: en_GB missing gaol

[Angus Lees]

Package: aspell-en
Version: 7.1-0-1
Severity: minor

Gaol is a decreasingly popular, but still quite valid(*),
alternative spelling of jail in UK, Ireland and Australia.  See for
example the brief discussion on http://en.wiktionary.org/wiki/gaol

(*) Indeed, some view gaol as the more correct British spelling of
the US-ified jail.


% echo gaol | ispell -dbritish -a
@(#) International Ispell Version 3.3.02 12 Jun 2005
*

(ie: gaol is a recognised word by ispell)


% echo gaol | aspell -dbritish -a
@(#) International Ispell Version 3.1.20 (but really Aspell
0.60.7-20110707)
 gaol 9 0: goal, Gail, gal, GAO, AOL, Gael, Gall, Gaul, gall

(ie: gaol is not a recognised word by aspell, and here's a list of 
suggestions)


 - Gus

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages aspell-en depends on:
ii  aspell   0.60.7~20110707-1.1
ii  dictionaries-common  1.23.10

aspell-en recommends no packages.

aspell-en suggests no packages.

-- no debconf information


signature.asc
Description: This is a digitally signed message part.

Bug#624965: gcc 4.6 bullet build failure (patch)

[Angus Lees]

fyi: Upstream bug and trivial patch is here:
 http://code.google.com/p/bullet/issues/detail?id=481

 - Gus



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#475228: defoma: defoma-font tries to update cache in my homedir

[Angus Lees]

On Wed, Apr 9, 2008 at 6:41 PM, Paul Slootman [EMAIL PROTECTED] wrote:

 Package: defoma
 Version: 0.11.10-0.2
 Severity: normal

 I have my homedir on an NFS mounted filesystem. Hence root has no rights
 on my files.

 When installing latex-xft-fonts, I got the following output:

 Setting up latex-xft-fonts (0.1-7) ...
 Updating fontconfig cache for /usr/share/fonts/truetype/latex-xft-fonts
 /home/paul/.fontconfig/f1639389e5f55db35457162d771a17f5-x86-64.cache-2:
 Permission denied
 Why is it trying to do that? What will break now it failed to do that?
 Must it do that?


It runs 'fc-cache' after adding/removing any fonts.  fc-cache updates the
fontconfig cache, and I believe these errors are harmless but alarming to
people who don't understand whats going on.

Keithp, is there some extra flag fontconfig.defoma should be using to avoid
updating the $HOME/.fontconfig/ index?

-- 
- Gus

Bug#460313: RM: libhtml-embperl-perl -- RoM; apache1 specific; obsolete

[Angus Lees]

Package: ftp.debian.org
Severity: normal

Superseded upstream by libembperl-perl (although not completely
compatible).  No support for apache2 so its time for this package to
die.

Already removed from testing, please remove from unstable.

--
 - Gus


pgpP0sHrmv34v.pgp
Description: PGP signature

Bug#460036: RFA: defoma -- Debian Font Manager -- automatic font configuration framework

[Angus Lees]

Package: wnpp
Severity: normal

I request an adopter for the defoma package.

I still think defoma fills a need and we should keep it.  It needs a
rewrite into something more resembling maintainable/modern perl, the
gtk1 gui updated/removed and the font hints to be better specified
(look to fontconfig for some ideas here).  I'm happy to be part of
this but I don't have the time to lead such a large project.

The package description is:
 Defoma, which stands for DEbian FOnt MAnager, provides a framework
 for automatic font configuration. An application whose configuration
 of fonts usually requires manual intervention can automate the
 process through Defoma, by installing a Defoma-configuration
 script. The script gets called whenever a font is installed and
 removed, so that the script may update the application configuration.
 .
 Font packages should register their fonts to Defoma in order to have them
 configured automatically for applications.

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#412521: How does Embperl work with different Apache2 MPM models?

[Angus Lees]

On 5/1/07, Gunnar Wolf [EMAIL PROTECTED] wrote:


http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412521

In short, the user states embperl only works with the Prefork Apache
MPM. I have only used this MPM (and not the other ones, particularly
the ones based on threading) - and this is because only the Prefork
one works reliably with mod_perl (and much of my code is
mod_perl). However, I understand that if Embperl is not directly
called from inside Apache (i.e. if it is run via FastCGI), it can
safely run under threaded Apache2 servers - Am I right?

Probably we (and we might mean the Debian maintainers for Embperl
or our kind Gerald and his very nice team) should basically document
prominently the user might find this situation :) What do you think?



I added this block to README.Debian in a previous release:

NB: Embperl is not (yet) threadsafe and will not work with any of
   apache2's threaded models in mod_perl mode.  In Debian terms, if
   you want to use libembperl-perl with apache2 and mod_perl2, you
   must use the apache2-mpm-prefork apache2 package.
   Full apache2 thread support is currently slated for Embperl v2.1

I figure that was sufficient to close this bug (its against a version before
this note was added).  Its hard to adequately describe the situation using
package dependencies alone.

- Gus

Bug#418067: apache2-mpm-prefork: apache2 -X kills wrong process group on exit

[Angus Lees]

Package: apache2-mpm-prefork
Version: 2.2.3-4
Severity: normal

In apache2.2 (at least prefork mpm), 'apache2 -X' doesn't create a new
process group.  Despite that, on exit it sends a SIGTERM to whatever
the process group is, causing all sorts of damage.  Amongst them a
FTBFS on libembperl-perl when building/testing against apache 2.2 (bug
#416016).

The broken code is in server/mpm/prefork/prefork.c.  Follow the
behaviour of one_process=1 (triggered by -X): In prefork_pre_config()
it carefully avoids calling apr_proc_detach(), which would have done
all the daemonising, including creating a new process group.  In
ap_mpm_run() it calls unixd_killpg(getpgrp(), SIGTERM) during both
graceful and ungraceful shutdown.

I haven't looked at other mpm's code to see if the bug exists in some
form there too.

libembperl-perl ran its apache2 tests happily with apache2.0 so I
presume this is a relatively new bug.

I /think/ calling apr_proc_detach(APR_PROC_DETACH_FOREGROUND) even in
one_process (and probably all other foreground/no_detach) cases is the
right thing to do but I haven't tried it at all.

 - Gus

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-4-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages apache2-mpm-prefork depends on:
ii  apache2. 2.2.3-4 Next generation, scalable, extenda
ii  libapr1  1.2.7-8.2   The Apache Portable Runtime Librar
ii  libaprut 1.2.7+dfsg-2The Apache Portable Runtime Utilit
ii  libc62.3.6.ds1-13GNU C Library: Shared libraries
ii  libdb4.4 4.4.20-8Berkeley v4.4 Database Libraries [
ii  libexpat 1.95.8-3.4  XML parsing C library - runtime li
ii  libldap2 2.1.30-13.3 OpenLDAP libraries
ii  libpcre3 6.7-1   Perl 5 Compatible Regular Expressi
ii  libpq4   8.1.8-1 PostgreSQL C client library
ii  libsqlit 3.3.8-1.1   SQLite 3 shared library
ii  libuuid1 1.39+1.40-WIP-2006.11.14+dfsg-2 universally unique id library

apache2-mpm-prefork recommends no packages.

-- no debconf information
--
 - Gus
--
 - Gus


pgpRikuKlLB6o.pgp
Description: PGP signature

Bug#411253: ipvsadm: bashism in ipvsadm.postinst

[Angus Lees]

Package: ipvsadm
Version: 1.24+1.21-1.4
Severity: important

This line in ipvsadm.postinst:
 ipvsadm -L -n  /dev/null || true
should be changed to:
 ipvsadm -L -n  /dev/null 21 || true

in order to be more portable amongst bourne shells.  In particular, this
made ipvsadm uninstallable for me using a common sh - dash setup.

 - Gus

-- System Information:
Debian Release: 4.0
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.18-3-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages ipvsadm depends on:
ii  debconf [debconf-2.0]   1.5.11   Debian configuration management sy
ii  libc6   2.3.6.ds1-11 GNU C Library: Shared libraries
ii  libpopt01.10-3   lib for parsing cmdline parameters

ipvsadm recommends no packages.

-- debconf information:
* ipvsadm/kernel_does_not_support_ipvs:
  ipvsadm/daemon_multicast_interface: eth0
* ipvsadm/auto_load_rules: false
* ipvsadm/daemon_method: none


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#402014: fontconfig.defoma patch

[Angus Lees]

On 1/22/07, Keith Packard [EMAIL PROTECTED] wrote:


On Sun, 2007-01-21 at 23:08 +1100, Angus Lees wrote:

 hrm. you're right - we need to run fc-cache on the directories we
 didn't need to symlink to ..

Would it be better to add the new font directories to the fontconfig
configuration instead of symlinking the files to /var?



I can do so, but the symlinking seems simpler.  defoma tracks fonts by
filename, so its possible for fonts to be scattered anywhere in the
filesystem.How does the fontconfig searching/caching mechanism scale?
For example, a naive implementation would add 40+ dirs to cover the fonts
from tetex-extra alone.  Is this ok?

defoma's priority mechanism for resolving FontName conflicts (in
fontconfig's case) also relies on using the symlinks to communicate that
information to fontconfig - but I suspect noone actually cares about that
feature so we can lose that..

Aside: are the cache files for dir directories always written to
/var/cache/fontconfig/ now?

Oh, and we need to use --force for all directories; updating font files

won't regenerate cache files otherwise.



Sure, I thought any change to the font files would trigger an mtime check
somewhere so we wouldn't need --force, but I guess you don't stat every
file.   Just replace the fc-cache line in fontconfig.defoma with this:

Latest patch:
 system('fc-cache', '--force', $PkgDir);
 system('fc-cache', keys(%fccache_dirs)) if %fccache_dirs;

We now want:
 system('fc-cache', '--force', $PkgDir, keys(%fccache_dirs));

--
- Gus

Bug#402014: fontconfig.defoma patch

[Angus Lees]

At Sun, 21 Jan 2007 07:19:01 +1100, Keith Packard wrote:
 On Tue, 2007-01-16 at 17:39 +1100, Angus Lees wrote:
  Keith, here's the patch written during your talk at LCA ;)
 
  It fixes bug 402014, by simply adding '-f' to the fc-cache run, hence
  me filing it under this bug number.  Really though, this patch avoids
  creating symlinks for fonts that are already in a directory covered by
  fontconfig - but I couldn't find an actual bug for that.

 Thanks for the patch. It does look to me like the fc-cache invocation is
 wrong though; it still runs fc-cache on the $PkgDir instead of running
 it on each directory containing the new fonts. Am I mis-understanding
 the perl code here?

hrm. you're right - we need to run fc-cache on the directories we
didn't need to symlink to ..

3rd time lucky - patch attached.

 - Gus


fontconfig-defoma.patch
Description: Binary data


pgpVrHxuwQZiL.pgp
Description: PGP signature

Bug#402014: fontconfig.defoma patch

[Angus Lees]

Keith, here's the patch written during your talk at LCA ;)

It fixes bug 402014, by simply adding '-f' to the fc-cache run, hence
me filing it under this bug number.  Really though, this patch avoids
creating symlinks for fonts that are already in a directory covered by
fontconfig - but I couldn't find an actual bug for that.

 - Gus



fontconfig-defoma.patch
Description: Binary data

Bug#333724: Announce of the upcoming NMU for the libapache-sessionx-perl package

[Angus Lees]

On 11/20/06, Christian Perrier [EMAIL PROTECTED] wrote: Dear maintainer
of libapache-sessionx-perl and Debian translators,



On 13 nov 2006 I sent a notice to the maintainer of the
libapache-sessionx-perl Debian
package, mentioning the status of at least one old po-debconf translation
update in the BTS (bug #333724).

I announced the intent to build and possibly upload a non-maintainer
upload
for this package in order to fix this long-time pending localization
bug as well as all other pending translations.



By all means, NMU away.  Thanks for your assistance.

--
- Gus

Bug#393746: defoma: The wrong fonts are chosen for 'courier'

[Angus Lees]

reassign 393746 msttcorefontsthanksOn 10/17/06, Sam Morris [EMAIL PROTECTED] wrote:
I'm not sure exactly which package I should be reporting this bugagainst, so please bear with me. :)My problem: web pages that ask for the 'courier' font look ugly. Thefont is very blurry, and lines that should be straight are not. I am
attaching a picture of what the rendering looks like.As far as I can tell it's not actually courier that is being selected todraw the text: $ fc-match courier NimbusMonL-Regu.pfb: Nimbus Mono L Regular
 $ locate NimbusMonL-Regu.pfb /var/lib/defoma/fontconfig.d/N/NimbusMonL-Regu.pfbI would expect Courier New to be selected instead.Dear msttcorefonts maintainer,
Please add defoma 'Alias' options to your hints file. From a quick bit of websearching it appears that Courier New is intended to be metric compatible with Courier and Arial with Helvetica. I expect other fonts in the msttcorefonts set were designed as drop-in replacements for existing fonts too.
gsfonts.hints has plenty of Alias examples, if what I'm asking isn't clear (or ask me and I can provide more details).Sam (bug submitter),Even once this is done, what you are asking is essentially a subjective opinion of which font is a better replacement for Courier. Because there isn't a clearly superior choice for all possible uses of Courier fonts, you'll have to apply your own preference by editing /etc/defoma/hints/msttcorefonts.hints and increasing the 'Priority' options above 20 (and adding the desired font Aliases, if the msttcorefonts package hasn't been updated in the mean time). Running 'defoma-font reregister-all /etc/defoma/hints/msttcorefonts.hints' as root should then regenerate all the relevant font configuration.
-- Thanks,- Gus

Bug#388416: Problems with fontconfig's defoma script

[Angus Lees]

On 10/2/06, Josselin Mouette [EMAIL PROTECTED] wrote:
Hi Angus,we're currently facing some issues with the fontconfig defoma script,which is displaying error scanning messages. As neither Keith nor I doreally understand how defoma is working, I was wondering whether you
could have a look at what's going wrong.Hrm. All fontconfig.defoma does is create a symlink farm in /var/lib/defoma/fontconfig.d/, write a suitable fonts.conf (also in that directory) and then run fc-cache over that directory.
grep says the string 'error scanning' exists in fc-cache, so I'm guessing its some problem with that binary. Perhaps you can run 'fc-cache /var/lib/defoma/fontconfig.d' manually (as root), which should hopefully reproduce the message. Don't know after that, --verbose or strace perhaps? The cause is most likely a dangling font symlink (in which case let me know and I'll investigate further), a bad/corrupt font (let the font maintainer know) or some new fc-cache bug (thats your problem ;)
If it happens only in the 'cleaning up ...' stage, then it sounds like a package is removing its files before unregistering itself. Let me know the destination of the dangling symlink and I'll investigate the font package in question.
--  - Gus

Bug#365315: xterm and charcell fonts

[Angus Lees]

reassign 365315 xserver-xorg
retitle xserver-xorg whitespace in charcell fonts rendered as squares
thanks

 With the new version of today, the opendir issue has gone, but I
 found some kind of wrong encodings (with the space char) in a font
 previously perfectly working.  See the xterm screenshot enclosed.

 XTerm*Font: -monotype-andale mono-medium-r-normal--14-0-0-0-c-0-iso8859-15

I looked into this last week and it seems the Xserver behaviour has
changed with respect to charcell fonts (...-c-...).  If you change
this to use the monospace variant (...-m-...) it should appear as you
expect.  This is definately a change in behaviour (as I recall it,
previous Xservers treated the two identically), but I'm not sure it is
incorrect.

Rendering the spaces in the font as little squares probably is an
Xserver bug though.  Reassigning.


X guys:

xfd -fn '-monotype-andale mono-medium-r-normal--14-0-0-0-c-0-iso8859-15'
(or the 'charcell' variant of any other truetype monospaced font) and
look at all the squares where there should be whitespace.  Previous
Xservers didn't do the little squares.

Is this intentional?  Should x-ttcidfont-conf be generating the
charcell variants for these fonts at all?  (I never really did
understand the use-case for charcell fonts; is it meant to be only a
CJK thing?)

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#325935: warzone2100: Is this ITP still valid?

[Angus Lees]

On 7/29/06, Linas Žvirblis [EMAIL PROTECTED] wrote:

The latest packages, by the bug owner, I could find date back to year2005. Although upstream currently ships with Debian packaging filescreated by Angus Lees in March 2006.Is anyone still working on packaging Warzone 2100 for inclusion in
Debian? If not, I am willing to hijack this ITP.CC'ing this to Angus in hope that he will shed some light on the currentsituation.I asked Fanio once in March what he intended with this package and got no response. Since I gained upstream commit rights through other patches, I figured I may as well just submit my packaging files. I would be happy for you to take over package ownership and upload to Debian.

Before an upload into Debian proper, I'd suggest changing the package name to warzone2100{,-data} and possibly weakening the -data package dependency to simply $source:Upstream-Version, so we don't have to release a new (large) -data package for a simple binary recompile.
--  - Gus

Bug#319951: [Pkg-fonts-devel] Not sure that #319951 is still here

[Angus Lees]

[uninitialised variable at gs.defoma line 108]

That is/was a bug with gs.defoma; I've merged many bug reports for
it. As far as I know without having fixed the bug, it is not an
issue with ttf-farsiweb.--  - Gus

Bug#373659: acpi-support: shutsdown/brings up interfaces that were already down

[Angus Lees]

On 6/16/06, Raphael Hertzog [EMAIL PROTECTED] wrote:
[ please keep me in CC since the BTS hasn't affected a maintainer toacpi-support yet ]thanks for your bug reports. You appear to have some knowledge on thetopic and evidently some interest, would you be interested to co-maintain
the package?Sure. The only hardware I'd be able to test acpi-support on is my IBM T43p and an older Dell laptops.My hasty reporting of this bug isn't a good start though ;)
 suspend.d/55-down-interfaces.sh takes down all interfaces that exist, even those that are already down and 
resume.d/62-ifup.sh diligently brings up all the interfaces that were taken down.This means that my ethernet interface (which is managed through ifplugd) was correctly down, but acpi-support tries to bring it up on resume.
 A simpler alternative that would also fix this issue would be something like:Can you explain me why it would fix the issue?It only acts on the interfaces that ifupdown believe is up (and only brings back some of those interfaces, depending on what resume policy we choose to implement - see below)
 suspend.d/55-down-interfaces.sh:ifdown -e lo -aThe -e switch of ifdown is undocumented, what does it do? Exclude an
interface ?Ah. it appears it was deprecated in ifupdown 0.6.5. Shows how long its been since I updated my suspend script. Yes it excludes an interface, but we can skip that and just do ifdown -a without much extra cost.

 If you want to be more persistent and fall through to ifconfig down, as the current 
55-down-interfaces.sh does, you should walk through `cut -d= -f 1 /etc/network/run/ifstate`, rather than all interfaces that currently exist.How can a network interface appear in ifconfig if it's not up ?

You are completely right. It appears ifplugd actually brings my interface up, but doesn't give it an IP address yet.
 resume.d/62-ifup.sh:ifup -aThis would start all interfaces marked auto in /etc/network/interfaces and not
necessarily only those that were up when we suspended.What do I miss?Yes, it would bring up those same interfaces that were brought up on system boot. That would fix my immediate problem (disagreement over ifplugd-managed interfaces), but be a change from current behaviour.
I can see several policies we might want to implement here:Bring up each interface exactly as it was before:# suspendINTERFACES=$(cat /etc/network/run/ifstate)ifdown -a ...# resume 
for i in $INTERFACES; do ifup $i; doneBring up each interface that was up before, but let mapping scripts recheck for different networks, etc (good idea given that people suspend laptops precisely because they are about to move them)
INTERFACES=$(cut -d= -f1 /etc/network/run/ifstate)ifdown -a ...for i in $INTERFACES; do ifup $i; doneTake down / bring up interfaces that the user has tagged as 'allow-suspend' in /etc/network/interfaces
ifdown --allow=suspend ...ifup --allow=suspendTake down all up interfaces, and only bring up those the user normally brings up at system boot (fwiw, this is actually what I prefer, since the network environment where I resume my laptop usually bears no resemblance to where I suspended it)
ifdown -a ...ifup -a--  - Gus

Bug#373660: acpi-support: acpi_fakekey doesn't work

[Angus Lees]

Package: acpi-support
Version: 0.80-1
Severity: serious

acpi_fakekey doesn't seem to do anything on my Thinkpad T43p laptop.
This means suspend and hibernate doesn't actually trigger at all for
me.

I'm not sure what acpi_fakekey is supposed to do (strace shows it
writing to my keyboard /dev/input/event0 device - without checking
exactly what that event device is) and I don't understand why the
acpi-support scripts even have this foobtn.sh - foo.sh via
acpi_fakekey indirection in the first place..

 - Gus

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages acpi-support depends on:
ii  acpid 1.0.4-5Utilities for using ACPI power man
ii  dmidecode 2.8-2  Dump Desktop Management Interface 
ii  finger0.17-9 user information lookup program
ii  hdparm6.6-1  tune hard disk parameters for high
ii  laptop-detect 0.12.1 attempt to detect a laptop
ii  laptop-mode-tools 1.31-1 Scripts to spin down hard drive an
ii  lsb-base  3.1-10 Linux Standard Base 3.1 init scrip
ii  powermgmt-base1.24   Common utils and configs for power
ii  radeontool1.5-3  utility to control ATI Radeon back
ii  toshset   1.71-1 Access much of the Toshiba laptop 
ii  vbetool   0.6-1  run real-mode video BIOS code to a
ii  xbase-clients 1:7.0.1-2  miscellaneous X clients

acpi-support recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#373659: acpi-support: shutsdown/brings up interfaces that were already down

[Angus Lees]

Package: acpi-support
Version: 0.80-1
Severity: normal

suspend.d/55-down-interfaces.sh takes down all interfaces that exist,
even those that are already down and resume.d/62-ifup.sh diligently
brings up all the interfaces that were taken down.  This means that my
ethernet interface (which is managed through ifplugd) was correctly
down, but acpi-support tries to bring it up on resume.

A simpler alternative that would also fix this issue would be
something like:

suspend.d/55-down-interfaces.sh:
 ifdown -e lo -a

resume.d/62-ifup.sh:
 ifup -a

If you want to be more persistent and fall through to ifconfig down,
as the current 55-down-interfaces.sh does, you should walk through
`cut -d= -f 1 /etc/network/run/ifstate`, rather than all interfaces
that currently exist.

 - Gus

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.16-2-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages acpi-support depends on:
ii  acpid 1.0.4-5Utilities for using ACPI power man
ii  dmidecode 2.8-2  Dump Desktop Management Interface 
ii  finger0.17-9 user information lookup program
ii  hdparm6.6-1  tune hard disk parameters for high
ii  laptop-detect 0.12.1 attempt to detect a laptop
ii  laptop-mode-tools 1.31-1 Scripts to spin down hard drive an
ii  lsb-base  3.1-10 Linux Standard Base 3.1 init scrip
ii  powermgmt-base1.24   Common utils and configs for power
ii  radeontool1.5-3  utility to control ATI Radeon back
ii  toshset   1.71-1 Access much of the Toshiba laptop 
ii  vbetool   0.6-1  run real-mode video BIOS code to a
ii  xbase-clients 1:7.0.1-2  miscellaneous X clients

acpi-support recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#360456: libembperl-perl: FTBFS: match/div.asc failure.

[Angus Lees]

On 4/2/06, Kurt Roeckx [EMAIL PROTECTED] wrote:
Package: libembperl-perlVersion: 2.0.1-1Severity: seriousHi,Your package is failing to build with the following error:#147 match/div.htm... ok#148 match/div.asc...Error in Line 1
Is:Should: htmlInput:test/html/match/div.ascOutput: test/tmp/out.htmCompared to:test/cmp/div.ascLog:test/tmp/test.logTestparameter:offline = 0
 ERRORS detected! NOT all tests have been passed successfullymake[2]: *** [test_dynamic] Error 1
which architecture? which versions of build-dep packages?

Can you send me test/tmp/test.log and test/tmp/out.htm after the build failure?
--  - Gus

Bug#347268: another ttf-dejavu defoma hints change

[Angus Lees]

It seems you'll also want to replace
 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono-Roman.ttf
with
 /usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf

in ttf-dejavu.defoma-hints, since that file has also been renamed.

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#337351: libembperl-perl: FTBFS on arm - fails httpd syntax check 1

[Angus Lees]

At Fri, 4 Nov 2005 02:03:31 - (GMT), Wookey wrote:
 http://buildd.debian.org/fetch.php?pkg=libembperl-perlver=2.0.1-1arch=armst$
 
 fails during output caching tests:
 sub EXPIRES in source...  ok
 sub EXPIRES in source (cached)...ok
 
 Performing httpd syntax check 1 ...  ERROR: Syntax OK not found
 Got apache2: bad group name 1023
 
 Attempting to reproduce this on my netwinder unstable chroot I find that the
 package simply builds OK. I am at a bit of a loss to explain this. What
 exactly is that test doing? Trying to run apache or apache2?

At that point, its starting apache2 (in your case).  The bad group
name 1023 error is caused by the buildd user not having an entry in
the groups database.  Unfortunately, the apache config Group
directive only supports group names, not gids.

Also note very early on in the build (during perl Makefile.PL):
Test httpd will run as user buildd and group 1023

I should probably put in a specific (and more verbose) check for this
in the build script, since a number of buildds have had this problem.


Thanks for taking the time to investigate this.

-- 
 - Gus


pgpw4BArAq7V6.pgp
Description: PGP signature

Bug#333154: pwc-source: kernel/linux name detection broken

[Angus Lees]

Package: pwc-source
Version: 10.0.7a-5
Severity: normal

The KLINUX code in debian/rules doesn't work (always ends up with 
KLINUX=linux).  Adding  echo yes to the ifeq conditions fixes it:

   ifeq ($(shell test $(strip $(ksublevel)) -le  11  echo yes), yes)
  KLINUX=kernel
   else
  ifeq ($(shell test $(strip $(ksublevel)) -lt 9  echo yes), yes)
 $(error This driver needs a linux kernel version = 2.6.9)
  ...

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (89, 'testing'), (88, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-2-686
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)

Versions of packages pwc-source depends on:
ii  debhelper 4.2.32 helper programs for debian/rules
ii  module-assistant  0.9tool to make module package creati

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#326596: Warnings from gs.defoma script when upgrading fonts

[Angus Lees]

At Sun, 04 Sep 2005 11:49:58 +0200, Vincent Lönngren wrote:
 Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 
 108.

For the record, what version of gs-common do you have installed?

-- 
 - Gus


pgpJEAC9vebnY.pgp
Description: PGP signature

Bug#313067: defoma: Defoma prevents ghostscript from rendering fonts properly

[Angus Lees]

At Sat, 11 Jun 2005 12:14:17 -0400, Kirill wrote:
 I am trying to set up an HPLJ 1012 to print from KDE apps (KWord, Konqueror)
 using CUPS. I am getting most fonts messed up by ghostscript (gs-esp). I've
 been struggling with it for a whole week now with very little progress so far.

 When I print to a PostScript file and then try to view it with ghostscript,
 almost all fonts are totally messed up, both the typeface and letter spacing
 is bad. Same with print preview and on paper.
 
 Printing with Times New Roman in regular, italic, bold and bold italic and 
 then
 looking in the .ps file I see:
 
 %%DocumentFonts: Times-Bold Times-Italic Times-Roman Times-BoldItalic
 
 Then I run gs on it, and it says:
 
 ESP Ghostscript 7.07 (2003-07-12)
 Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved.
 This software comes with NO WARRANTY: see the file PUBLIC for details.
 Loading NimbusRomNo9L-MediItal font from 
 /var/lib/defoma/gs.d/dirs/fonts/n021024l.pfb... 2149928 764523 1763096 439747 
 0 done.
 Loading NimbusRomNo9L-ReguItal font from 
 /var/lib/defoma/gs.d/dirs/fonts/n021023l.pfb... 2307264 878740 1763096 385118 
 0 done.
 Loading NimbusRomNo9L-Medi font from 
 /var/lib/defoma/gs.d/dirs/fonts/n021004l.pfb... 2444504 1012113 1783192 
 401765 0 done.
 Loading NimbusRomNo9L-Regu font from 
 /var/lib/defoma/gs.d/dirs/fonts/n021003l.pfb... 2581744 1137566 1783192 
 387726 0 done.
 showpage, press return to continue
 
 Result: it shows the page with Nimbus Roman instead of Times New Roman, and
 all letter spacing is fubared.

URW Nimbus Roman is supposed to be metric-compatible with Adobe's
Times New Roman, so this substitution is exactly what is supposed to
happen.  (I'm assuming here that you haven't gone out and bought the
real Adobe fonts)

Having the letter spacing wrong probably means the original kword app
somehow didn't get the font metric information correct, however.  Has
this ever worked for you in the past?  My only experience with kword
was many years ago and I too was appalled at the print quality
although I never investigated it.

 When I format all text with Nimbus Roman, I get:
 
 %%DocumentFonts: NimbusRomanNo9L-Bold NimbusRomanNo9L-Italic NimbusRomanNo9L 
 NimbusRomanNo9L-BoldItalic
 
 in the .ps file, and then
 
 ESP Ghostscript 7.07 (2003-07-12)
 Copyright 2003 artofcode LLC and Easy Software Products, all rights reserved.
 This software comes with NO WARRANTY: see the file PUBLIC for details.
 Can't find (or can't open) font file 
 /usr/share/ghostscript/fonts/NimbusRomanNo9L-Italic.
 Can't find (or can't open) font file NimbusRomanNo9L-Italic.
 Substituting font Times-Italic for NimbusRomanNo9L-Italic.
 Loading NimbusRomNo9L-ReguItal font from 
 /var/lib/defoma/gs.d/dirs/fonts/n021023l.pfb... 2170024 782484 1763096 440505 
 0 done.
 Loading NimbusSanL-ReguItal font from 
 /var/lib/defoma/gs.d/dirs/fonts/n019023l.pfb... 2267072 876716 1763096 445071 
 0 done.
[...]
 
 and everything shows up in Nimbus Sans.

Hrm.  ghostscript (via Defoma and gsfonts.hints) only knows this font
as NimbusRomNo9L-ReguItal.  Where did kword get the name
NimbusRomanNo9L-Italic from?

Since Nimbus Roman isn't one of the base postcript fonts, Kword (or
whatever KDE component created the postscript) should have embedded
the font in the produced postscript file and ghostscript would not
have had to look for the font data itself.  Have you by any chance
turned some font embedding option off?  (I'd be extremely surprised if
it was off by default)

 Bold, italic and bold italic are shown fine, but normal Georgia it
 can't find because in defoma aliases it's known as Georgia-Regular
 rather than Georgia.
[similar with other font families]

It seems that kword is working off a totally different list of font
names than ghostscript.  This would be just fine if kword embedded the
font data in the postscript output, but it isn't and its expecting
ghostscript to be able to find the font data under the same font names
its using.

Since I don't have kword installed anywhere (and don't really want to
lug in all of KDE just to have a look), I'm CCing this to the kword
maintainer.  Ben, how does kword find font information when producing
postscript?  At the moment, it looks like Defoma (and ghostscript) are
doing the right thing and I'm thinking of reassigning this bug to
kword.


Kirill, As a temporary workaround, you could manually edit
/etc/defoma/hints/gsfonts.hints, etc and add the aliases that Kword is
assuming exist.  Just run defoma-font reregister-all $hintfile after
editing a hintfile for defoma to act on your changes.

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#313067: defoma: Defoma prevents ghostscript from rendering fonts properly

[Angus Lees]

At Sun, 28 Aug 2005 08:42:30 -0400, Kirill wrote:
  Having the letter spacing wrong probably means the original kword app
  somehow didn't get the font metric information correct, however.  Has
  this ever worked for you in the past?
 
 Not with Times New Roman. But if after editing gsfonts.hints (file
 attached) I select NimbusRoman, it displays and prints just fine.
 
 I edited msttcorefonts.hints as well (file attached), which helped
 solve some of the substitution problems, but not the spacing problem
 with Times New Roman in KWord.

Hrm.  I wonder why Kword has a different set of metrics for Times.  Is
this the (postscript standard) Times-Roman or microsoft's
Times-New-Roman font you were testing against here?

(Your original report had Times being correctly replaced by Nimbus
Roman but produced with the wrong metrics.  Here you mention Times New
Roman - a different font in the eyes of Defoma/postscript/fontconfig)

  Hrm.  ghostscript (via Defoma and gsfonts.hints) only knows this font
  as NimbusRomNo9L-ReguItal.  Where did kword get the name
  NimbusRomanNo9L-Italic from?
 
 It seems these names are somehow related to fontconfig font names.
 Output of fc-list also attached.

The GUI drop down widget-thing you select the fonts from almost
certainly comes from fontconfig.  I hope the KDE printing stuff is
doing something better than just removing whitespace from the
fontconfig names and hoping that makes a valid postscript FontName.

 Looks like at least the KDE printing component thinks that what it
 outputs are valid aliases for the existing fonts. I have no idea
 how it comes up with them. But no embedding should take place here.

So how do you print to a remote CUPS printer spooler for example,
where Arial (or whatever) simply may not be available?  The KDE
printing component really should be embedding the font data in the
generated postscript.

 You won't be able to blame the substitution problem on KWord alone,
 since other programs give the same results (Konqueror and so on).

I expect Kword's print output is generated via some common KDE
component, so all KDE print output would suffer the same problem.  Try
comparing against another fontconfig-using-but-not-KDE app like
mozilla or some gnome program.

-- 
 - Gus


pgp7Ivf0vDeKL.pgp
Description: PGP signature

Bug#322859: FTBFS: Cannot find apr.h

[Angus Lees]

At Sat, 13 Aug 2005 11:18:11 +0200, Marc 'HE' Brockschmidt wrote:
 This problem is caused by a radical API change in libapach2-mod-perl2
 1.999_22. Upstream has already reacted, so packaging the new 2.0rc5
 version should fix this FTBFS.

Yep, the 2.0rc5 build breaks somehow (doesn't find apache 1.3 modules)
and I haven't had a chance to look into it yet.  Should be something
trivial once I actually start looking..

-- 
 - Gus


pgpvzUB1qQ2Sy.pgp
Description: PGP signature

Bug#315682: marked as done (defoma: many hintfiles lack Location and even FontName)

[Angus Lees]

reopen 315682
retitle 315682 defoma-ps should generate Location and FontName hints
reassign 315682 psfontmgr
severity 315862 normal
thanks

At Sun, 26 Jun 2005 18:18:06 -0700, Debian Bug Tracking System wrote:
 However, many of the hintfiles installed automatically have no Location
 entries, and some even lack FontName.  In particular, the defoma-ps.hints
 file installed by  /usr/bin/defoma-psfont-installer from a PPD file has
 neither FontName nor Location entries.

I read this again and it realise you were referring to the hints
produced by defoma-ps.  So yes, I should fix that (Location is pretty
hard to deduce automatically, but we should be able to make an attempt
for common character sets at least).

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#313067: looks like the same bug as 251067

[Angus Lees]

At Wed, 22 Jun 2005 20:04:10 -0700 (PDT), Andrew Young wrote:
 The behavior reported here seems very similar to the problems with
 printing from mozilla, filed under 251067.  Take a look and see if
 these can be combined -- and see if it's possible to decide just *where*
 in the font-handling system the trouble is coming from.  There are so
 man interacting pieces, it's hard to tell.

Perhaps, although I'm not convinced without further
investigation. (and I need to read through #251067 in depth when I
have a lot more free time..)

Can you print to file and capture one of these bogus (postscript)
print jobs?  Then at least we have something to pull apart and
investigate.  You might want to make it available somewhere and
publish the location until this bug is resolved (since debbugs doesn't
really like larger attachments).

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#314549: zaptel: should build-dep on dpatch = 2.0.9

[Angus Lees]

Package: zaptel
Version: 1:1.0.7-4.1
Severity: normal

dpatch-run (used in the zaptel .dpatch scripts) was only introduced in
dpatch 2.0.9

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (890, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages zaptel depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libnewt0.51 0.51.6-23Not Erik's Windowing Toolkit - tex

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#314552: zaptel: bashism in postinst

[Angus Lees]

Package: zaptel
Version: 1:1.0.7-4.1
Severity: important

zaptel.postinst contains this piece of code:

N=1; 
while (( $N  250 )) ; do 
rm -f /dev/zap/$N; 
mknod /dev/zap/$N c 196 $N; 
N=`expr $N + 1` 
done

The (( ... )) construct is bash-specific.  A simple posix-compatible
replacement is:

...
while [ $N -lt 250 ]; do
...

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (890, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages zaptel depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libnewt0.51 0.51.6-23Not Erik's Windowing Toolkit - tex

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#310154: 855resolution: should be run from rcS.d

[Angus Lees]

Package: 855resolution
Version: 0.3-4
Severity: normal

855resolution only needs to be run once during bootup (it has no
stop equivalent) and has essentially no boot-time dependencies.  IMO
the init script should be run from runlevel S, not the usual [2345]
priority 20.

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (890, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages 855resolution depends on:
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an

-- no debconf information



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#308902: units: doesn't know about RU (rack units)

[Angus Lees]

Package: units
Version: 1.81-4
Severity: wishlist

Would be nice if units knew about rack units (RU)

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (890, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)

Versions of packages units depends on:
ii  libc6   2.3.2.ds1-21 GNU C Library: Shared libraries an
ii  libncurses5 5.4-4Shared libraries for terminal hand
ii  libreadline44.3-11   GNU readline and history libraries

-- no debconf information


pgpjScFQILJFk.pgp
Description: PGP signature

Bug#308604: libapache2-mod-perl2: Apparently requires CGI.pm = 3.08 which is unavailable

[Angus Lees]

Package: libapache2-mod-perl2
Severity: important
Version: 1.999.23-1

The upstream changes document mentions that CGI.pm = 3.08 is required
to understand the Great Apache2 Renaming.  This version is unavailable
in Debian, since libcgi-perl is ancient, libcgi-pm-perl no longer
exists and perl-modules (5.8.4-8) only contains 3.04.

(I guess this is really a bug against libcgi-perl/perl-modules, but
whatever -- I wanted to make sure the issue was recorded against
mod-perl2)

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing'), (89, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-1-k7
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#300278: defoma: debhelper files fail if defoma is removed before package

[Angus Lees]

At Sat, 26 Mar 2005 15:28:35 -0800, Steve Langasek wrote:
 Ok, downgrading; I'll leave it to the maintainer to evaluate whether this is
 something that needs changing.

Thanks for your debugging efforts.  It can't hurt to add the -x check,
so I'll do that in the next upload - good to know it isn't RC however.

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#295165: lilo-installer: postinst fails at debconf priority=critical

[Angus Lees]

Package: lilo-installer
Severity: important
Version: 1.05
Tags: patch

lilo-installer.postinst dies before doing anything if debconf
priority=critical, due to an unchecked debconf return code:

- db_input high lilo-installer/bootdev
+ db_input high lilo-installer/bootdev || [ $? -eq 30 ]

 - Gus

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (890, 'testing'), (89, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-1-686
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#292446: modutils: udebs missing Section and Priority

[Angus Lees]

Package: modutils
Version: 2.4.26-1.1
Severity: normal

% dpkg --info modutils-basic_2.4.26-1.1_i386.udeb
 new debian package, version 2.0.
 size 52600 bytes: control archive= 395 bytes.
 374 bytes,11 lines  control  
 Package: modutils-basic
 Version: 2.4.26-1.1
 Architecture: i386
 Depends: libc6 (= 2.3.2.ds1-4)
 Installed-Size: 112
 Origin: debian
 Maintainer: LaMont Jones [EMAIL PROTECTED]
 Source: modutils
 Description: Basic Linux module utilities for debian-installer
  This is a minimal package used by debian-installer.
  This package contains only the binaries 'modprobe' and 'insmod'.

There should be Section: debian-installer and Priority: extra
fields in there (same for modutils-full).

(This is not release-critical since official archives have override
files in place)

-- 
 - Gus


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]