Bug#1066957: dependency not satisfiable in bookworm-backports
Hi Julian, Thank you for the reply. The failure I encountered was an unbootable system; see `/var/log/apt/history.log` below. In that configuration, the system reboots at the grub loading screen, instead of proceeding to the grub menu. I was able to use Super Grub Disk to log in, downgrade and restore the missing packages, but I think this behavior qualifies as "critical." I would appreciate any assistance you can provide forwarding this report to the correct team. ``` Start-Date: 2024-03-13 12:21:38 Commandline: /usr/sbin/synaptic --hide-main-window --non-interactive --parent-window-id 56623118 -o Synaptic::closeZvt=true --set-selections-file /tmp/tmpabiw_6dz Requested-By: me (1000) Upgrade: grub-firmware-qemu:amd64 (2.06-13+deb12u1, 2.12-1~bpo12+1), grub2-common:amd64 (2.06-13+deb12u1, 2.12-1~bpo12+1), grub-common:amd64 (2.06-13+deb12u1, 2.12-1~bpo12+1) Remove: grub-efi-amd64:amd64 (2.06-13+deb12u1), grub-efi-amd64-bin:amd64 (2.06-13+deb12u1), shim-signed:amd64 (1.39+15.7-1) End-Date: 2024-03-13 12:21:45 ``` On Wed, 20 Mar 2024 12:39:02 +0100 Julian Andres Klode < julian.kl...@canonical.com> wrote: > On Fri, Mar 15, 2024 at 08:56:25PM -0400, TM wrote: > > Package: grub-efi-amd64-bin > > > > Version: 2.12-1~bpo12+1 > > > > Hello, > > > > This package seems to require[1] grub-efi-amd64-signed >= 1+2.12, which is > > available in testing[2]. > > > > Please excuse the report if this is expected behavior. Apt output follows. > > > > Thank you for your time. > > > > We did not upload that backport, and this is normal and expected > behavior, and it's out of our hands and up to the ftp team to approve > the signing binaries - it's not a bug. > -- > debian developer - deb.li/jak | jak-linux.org - free software dev > ubuntu core developer i speak de, en > >
Bug#1066957: dependency not satisfiable in bookworm-backports
Package: grub-efi-amd64-bin
Version: 2.12-1~bpo12+1
Hello,
This package seems to require[1] grub-efi-amd64-signed >= 1+2.12, which is
available in testing[2].
Please excuse the report if this is expected behavior. Apt output follows.
Thank you for your time.
$ sudo apt install grub2-common
The following packages will be upgraded:
grub-common grub-efi-amd64 grub-efi-amd64-bin{b} grub2-common
4 packages upgraded, 0 newly installed, 0 to remove and 4 not upgraded.
Need to get 5,578 kB of archives. After unpacking 5,963 kB will be freed.
The following packages have unmet dependencies:
grub-efi-amd64-bin : Breaks: grub-efi-amd64-signed (< 1+2.12~rc1) but
1+2.06+13+deb12u1 is installed
The following actions will resolve these dependencies:
Remove the following packages:
1) grub-efi-amd64 [2.06-13+deb12u1 (now, stable, stable-security)]
2) grub-efi-amd64-bin [2.06-13+deb12u1 (now, stable, stable-security)]
3) shim-signed [1.39+15.7-1 (now, stable)]
Leave the following dependencies unresolved:
4) grub-efi-amd64-signed recommends shim-signed
[1] Per changelog entry dated Tue, 05 Sep 2023 19:06:05 +0200
https://metadata.ftp-master.debian.org/changelogs//main/g/grub2/grub2_2.12-1~bpo12+1_changelog
[2] https://tracker.debian.org/pkg/grub-efi-amd64-signed
Bug#1061413: dependency not satisfiable in bookworm-backports
Package: qemu-system-x86
Version: 1:8.1.2+ds-1~bpo12+1
Hello,
This package seems to require[1] seabios >1.16.3-1, which is available in
testing[2].
Please excuse the report if this is expected behavior. Apt output follows.
Thank you for your time.
$ sudo apt install qemu-system-x86
The following packages will be upgraded:
qemu-block-extra qemu-system-common qemu-system-data qemu-system-gui
qemu-system-modules-opengl qemu-system-modules-spice qemu-system-x86{b}
qemu-utils
8 packages upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
Need to get 15.0 MB of archives. After unpacking 47.7 MB will be freed.
The following packages have unmet dependencies:
qemu-system-x86 : Depends: seabios (> 1.16.3-1~) but it is not going to be
installed
The following actions will resolve these dependencies:
Upgrade the following packages:
1) seabios [1.16.2-1 (now, stable) -> 1.16.3-2 (testing, unstable)]
[1]: Per changelog entry dated Wed, 20 Dec 2023
https://metadata.ftp-master.debian.org/changelogs//main/q/qemu/qemu_8.2.0+ds-5~bpo12+1_changelog
[2]: https://tracker.debian.org/pkg/seabios
Bug#626217: Re: Bug
Bug#602591: Re: Bug
Bug#852724: golang-1.7: go install -race fails with "permission denied"
Hello, I believe upstream is discussing a change in `go install` relevant to this issue. It was recently added to the go1.9 milestone. https://github.com/golang/go/issues/18981#issuecomment-278131082 Note `go run -race` may be a satisfactory workaround. > However, race-enabled binaries can use ten times the CPU and memory, so it is impractical to enable the race detector all the time. https://blog.golang.org/race-detector
Bug#856438: closed by Daniel Kahn Gillmor <d...@fifthhorseman.net> (Bug#856438: fixed in gnupg2 2.1.19-1)
Debian Bug Tracking System <ow...@bugs.debian.org>, 2017-03-17 03:39 +: ... > gnupg2 (2.1.19-1) experimental; urgency=medium > . >* New upstream release (Closes: #854359) >* many post-release bugfixes from upstream >* add logcheck filters for gpg-agent (Closes: #856438) Thanks Daniel! —much appreciated —Mike -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#856438: [pkg-gnupg-maint] Bug#856438: Add logcheck filters for systemd “Listening on GnuPG…” & “Closed GnuPG…” messages
Hi Daniel, Daniel Kahn Gillmor <d...@fifthhorseman.net>, 2017-02-28 18:30 -0800: > > On Tue 2017-02-28 18:17:08 -0800, Michael[tm] Smith wrote: > > Per discussion at > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850982#75 > > please consider adding the following to > > /etc/logcheck/ignore.d.server/systemd > > as part of the gnupg-agent package install. > > thanks for this suggestion, Michael. I'm not sure why you're suggesting > /etc/logcheck/ignore.d.server/systemd though. > > why .../systemd in particular? shouldn't it be .../gpg-agent ? Yeah, no reason I know of why it must be in .../systemd The reason I had suggested .../systemd was just that I noticed that on my system at least, all systemd filter rules are in /etc/logcheck/ignore.d.server/systemd So I suppose I wrongly just simply assumed the logcheck convention was to put filters for all systemd messages in that file. I don’t otherwise know what conventions are used by package maintainers for deciding what filenames to put logcheck filters in, but intuitively I guess it’d seem to make the most sense to use the same name as whatever package the filters are specific too. In other words, yeah, .../gpg-agent :) -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#850982: [pkg-gnupg-maint] Bug#850982: Exact command to globally disable gpg-agent user service?
Daniel Kahn Gillmor <d...@fifthhorseman.net>, 2017-02-28 16:12 -0800: > ... > Sure, i'd be happy to accept reasonable logcheck filters to the > gpg-agent and dirmngr binary packages. Please submit a separate bug > report with the suggested filters, and i'll review them and roll them > into the next release. Thanks—raised at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856438 -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#856438: Add logcheck filters for systemd “Listening on GnuPG…” & “Closed GnuPG…” messages
Package: gnupg-agent
Version: 2.1.18-3
Severity: wishlist
Per discussion at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850982#75
please consider adding the following to /etc/logcheck/ignore.d.server/systemd
as part of the gnupg-agent package install.
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent and passphrase cache\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG network certificate management daemon\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent and passphrase cache \(restricted\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent \(access for web browsers\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent \(ssh-agent emulation\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
network certificate management daemon\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent and passphrase cache\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent and passphrase cache \(restricted\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent \(ssh-agent emulation\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent \(access for web browsers\)\.$
I’ve also attached the filters in a separate file.
-- System Information:
Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.7.0-1-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=UTF-8 (charmap=UTF-8) (ignored: LC_ALL set
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages gnupg-agent depends on:
ii libassuan0 2.4.3-2
ii libc6 2.24-9
ii libgcrypt20 1.7.6-1
ii libgpg-error0 1.26-2
ii libnpth01.3-1
ii libreadline77.0-2
ii pinentry-curses [pinentry] 1.0.0-2
Versions of packages gnupg-agent recommends:
ii gnupg 2.1.18-3
Versions of packages gnupg-agent suggests:
pn dbus-user-session
pn libpam-systemd
pn pinentry-gnome3
pn scdaemon
-- debconf-show failed
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent and passphrase cache\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG network certificate management daemon\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent and passphrase cache \(restricted\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent \(access for web browsers\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Listening on
GnuPG cryptographic agent \(ssh-agent emulation\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
network certificate management daemon\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent and passphrase cache\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent and passphrase cache \(restricted\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent \(ssh-agent emulation\)\.$
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ systemd\[[[:digit:]]+\]: Closed GnuPG
cryptographic agent \(access for web browsers\)\.$
Bug#850982: [pkg-gnupg-maint] Bug#850982: Exact command to globally disable gpg-agent user service?
Daniel Kahn Gillmor <d...@fifthhorseman.net>, 2017-02-21 10:18 -0500: > On Mon 2017-02-20 23:11:56 -0500, Michael[tm] Smith wrote: ... > if there's nothing concretely wrong with current defaults, please stick > with them, rather than changing them gratuitously (or encouraging others > to do so). It'll improve the lives of the people who try to support you > and the software you use, i promise :) OK, understood > (that said, if there *is* something wrong with the current defaults, > please do report it -- the pkg-gnupg-maint team, like all debian > developers, want to fix problems and very much appreciate those > reports!) OK one small very concrete thing I think would help would be if the package added logcheck filters for messages the change has caused to now start getting logged to syslog in the following form: Feb 17 01:24:15 sideshowbarker systemd[1246]: Listening on GnuPG cryptographic agent and passphrase cache. Feb 17 01:24:15 sideshowbarker systemd[1246]: Listening on GnuPG network certificate management daemon. Feb 17 01:24:15 sideshowbarker systemd[1246]: Listening on GnuPG cryptographic agent and passphrase cache (restricted). Feb 17 01:24:15 sideshowbarker systemd[1246]: Listening on GnuPG cryptographic agent (access for web browsers). Feb 17 01:24:15 sideshowbarker systemd[1246]: Listening on GnuPG cryptographic agent (ssh-agent emulation). Feb 17 01:24:16 sideshowbarker systemd[1246]: Closed GnuPG network certificate management daemon. Feb 17 01:24:16 sideshowbarker systemd[1246]: Closed GnuPG cryptographic agent and passphrase cache. Feb 17 01:24:16 sideshowbarker systemd[1246]: Closed GnuPG cryptographic agent and passphrase cache (restricted). Feb 17 01:24:16 sideshowbarker systemd[1246]: Closed GnuPG cryptographic agent (ssh-agent emulation). Feb 17 01:24:16 sideshowbarker systemd[1246]: Closed GnuPG cryptographic agent (access for web browsers). Would it be possible for the package maintainers to add logcheck filters for those? Should I file a separate bug to request that? —Mike -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#850982: [pkg-gnupg-maint] Bug#850982: Exact command to globally disable gpg-agent user service?
Daniel Kahn Gillmor <d...@fifthhorseman.net>, 2017-02-20 15:27 -0500: > On Sun 2017-02-19 21:20:52 -0500, Michael[tm] Smith wrote: > > "Michael[tm] Smith" <m...@w3.org>, 2017-02-20 11:11 +0900: > > > > Can you confirm what the exact command is for globally disabling the > > gpg-agent > > user service? Is it the following? > >... > > systemctl --global mask --now gpg-agent.service gpg-agent.socket > > gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket > > Yes, look at the per-user command in > /usr/share/doc/gnupg-agent/README.Debian and replace --user with > --global. OK, thanks > If you're using systemd, i don't think doing this is a good idea, and if > you find problems with managing gpg-agent on a system that you've > configured like this, i'll probably be grumpy about supporting it. > > If you think it's a good idea for some reason, i'd really like to > understand what that reason is so we can fix it. > > You understand that no daemon is launched at all if no process ever > tries to use the agent, right? Yes, but how is that any different from the state my system was in before the change was made in 2.1.17 to have systemd automatically launch gpg-agent? I mean, the way it worked previously caused no observable problems for me. As far I understand it, the way it works without systemd getting involved is that calling gpg2 launches gpg-agent the first time it’s needed, and then it just stays running and everything works fine for me from a user point of view. I observe nothing broken or undesirable in that behavior. —Mike -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#850982: Exact command to globally disable gpg-agent user service?
"Michael[tm] Smith" <m...@w3.org>, 2017-02-20 11:11 +0900: > > Can you confirm what the exact command is for globally disabling the gpg-agent > user service? Is it the following? > > systemctl --global --user mask --now gpg-agent.service gpg-agent.socket > gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket Actually I guess that’s wrong and it should instead be the following, right? systemctl --global mask --now gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#850982: Exact command to globally disable gpg-agent user service?
Can you confirm what the exact command is for globally disabling the gpg-agent user service? Is it the following? systemctl --global --user mask --now gpg-agent.service gpg-agent.socket gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket -- Michael[tm] Smith https://sideshowbarker.net/ signature.asc Description: PGP signature
Bug#560238: emitting notification of net.ipv6.bindv6only=1 change during netbase package upgrade
Hi Marco, First off, thanks very much, genuinely, for all the work you do as the maintainer for the netbase package. I can understand that one of the unfortunate things about being a Debian developer is that you probably almost never hear from users unless they have bugs to report. So please do know that you have my sincere appreciation and respect and admiration for your work. Along with that, I do want to add a couple of comments about bug 560238, as replies to comments that Salvo and Paul posted earlier. Salvo Tomaselli tipos...@tiscali.it, 2009-12-10 09:25 +0100: You should modify the package to introduce a postinst script that shows some dialog, that tells the user what is going on, why is this change happening, give some links on where to find further informations, how to revert the change and most of all put a YES/NO to let the user decide if he wants to do the change, after he is aware that the change might break his system. FWIW, I agree with that. I think the package upgrade should at least do the apt-listchanges thing where it puts up a message on the console and/or mails a copy to an admin address. Paul Seelig psee...@debian.org, 2009-12-10 15:54 +0100: While the functionality was broken, it was not even possible to connect a local session to localhost, when it was connected under either its IP, or via 127.0.0.1, or its very own hostname. I ran into the same issue, and at first had no idea at all what the cause was. It took me a significant amount of time to get it figured out -- tried at first using netstat and lsof, etc., and not seeing any problems and just completely baffled as to what was going on. Paul Seelig psee...@debian.org, 2009-12-10 01:45 +0100: It took me much more time i could currently afford to find out what the breakage was caused by. That's the core concern here, I think. It's that unless/until the package is updated to emit some kind of user notification about the net.ipv6.bindv6only=1 change, you are risking to end up with a significant number of frustrated users -- because you're going to have N different users getting bitten by it when they run into problems on upgrade, and each of them needing to take probably at least something like 30 minutes or an hour go through the process of first probably thinking they must have done something wrong themselves, then checking their environment, tweaking other config options in their environment and finding that they have no effect, then (hopefully) resorting to using a search engine and finding out that it's a known issue and what the fix is. Yeah, the first step for users when something like this happens probably should be to try the search engine first, but for whatever reason, it often doesn't seem to be the first thing that people try. Again, thanks for your work on this package, and please just consider my comments for what they're worth to you. Regards, --Mike -- Michael(tm) Smith http://people.w3.org/mike/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#557599: Patch to fix powerdns 2.9.22 missing in collectd 4.8.1
Package: collectd Version: 4.8.1-1 Severity: normal The second patch from Luke Heberling in bug #535787 (message #74) is missing in 4.8.1. Accordingly, collectd hangs when used to collect stats for pdns-server 2.9.22. Luke's patch works well, it just needs to be included in collectd. It also may need to be included upstream; a quick glance suggests that it hasn't been included upstream yet. Thanks much! -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.18.8-xen (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages collectd depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy ii libc6 2.7-18 GNU C Library: Shared libraries ii librrd4 1.3.1-4Time-series data storage and displ Versions of packages collectd recommends: ii iptables1.4.2-6 administration tools for packet fi ii libatk1.0-0 1.22.0-1 The ATK accessibility toolkit ii libcairo2 1.6.4-7 The Cairo 2D vector graphics libra pn libcurl3-gnutls none (no description available) pn libdbi0 none (no description available) pn libdbus-1-3 none (no description available) pn libdbus-glib-1-2none (no description available) pn libesmtp5 none (no description available) ii libgcrypt11 1.4.1-1 LGPL Crypto library - runtime libr ii libglib2.0-02.16.6-2 The GLib library of C routines ii libgtk2.0-0 2.12.12-1~lenny1 The GTK+ graphical user interface pn libhal1 none (no description available) pn libmemcached2 none (no description available) ii libmysqlclient15off 5.0.51a-24+lenny2MySQL database client library pn libnotify1 none (no description available) pn libnotify1-gtk2.10 none (no description available) pn libopenipmi0none (no description available) pn liboping0 none (no description available) ii libpango1.0-0 1.20.5-5 Layout and rendering of internatio ii libpcap0.8 0.9.8-5 system interface for user-level pa ii libperl5.10 5.10.0-19lenny2 Shared Perl library ii libpq5 8.3.8-0lenny1PostgreSQL C client library ii libsensors3 1:2.10.7-1 library to read temperature/voltag ii libsnmp15 5.4.1~dfsg-12SNMP (Simple Network Management Pr ii libssl0.9.8 0.9.8g-15+lenny5 SSL shared libraries pn libupsclient1 none (no description available) pn libvirt0none (no description available) pn libxenstore3.0 none (no description available) ii libxml2 2.6.32.dfsg-5+lenny1 GNOME XML library pn libyajl1none (no description available) pn lm-sensors none (no description available) ii perl5.10.0-19lenny2 Larry Wall's Practical Extraction pn rrdtool none (no description available) Versions of packages collectd suggests: ii apache2-mpm-worker [http 2.2.9-10+lenny6 Apache HTTP Server - high speed th pn collectd-dev none (no description available) pn hddtemp none (no description available) pn libconfig-general-perl none (no description available) pn libhtml-parser-perl none (no description available) pn libregexp-common-perlnone (no description available) pn librrds-perl none (no description available) ii liburi-perl 1.35.dfsg.1-1 Manipulates and accesses URI strin pn mbmonnone (no description available) -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#473722: aptitude man pages added to regression tests for DocBook XSL stylesheets
Hi Daniel, @2008-04-01 06:50 -0700: Thanks for the patch. Thanks for your reply, and sorry for my delay in responding. Do you know any way to tell nxml-mode that it's editing a file that will be included into another XML file as an entity? There's no way to do that, as far as I know. The manpage is set up to work that way for the convenience of translators, and it means that I lose the ability to have my editor validate against the schema (which would catch things like this). When you say you lose the ability to have it validate against the schema, do you mean the problem of it flagging all the entities (VERSION;, aptitude;, etc.) as errors? (because of the issue of the definitions for those entities being not being in the manpage.xml file itself, but in the parent XML file). If that's the main issue, I realize that's a problem but it seems like it doesn't completely prevent you from being able to do validated editing of the manpage.xml file in nxml-mode. What I mean is, nxml-mode will still flag any other errors in the manpage.xml file. If I open the (unpatched) manpage.xml file in nxml-mode, with the schema set to DocBook, and I try to add text somewhere after a listitem (without a para or simpara), it does immediately flag it as an error. So it seems like it does actually still give you the ability to catch that kind of error in real time as you're editing the file (in spite of the file not being a standalone document). --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#473722: aptitude man pages added to regression tests for DocBook XSL stylesheets
Daniel Burrows [EMAIL PROTECTED], 2008-04-02 06:22 -0700: On Wed, Apr 02, 2008 at 04:24:16PM +0900, Michael(tm) Smith [EMAIL PROTECTED] was heard to say: When you say you lose the ability to have it validate against the schema, do you mean the problem of it flagging all the entities (VERSION;, aptitude;, etc.) as errors? (because of the issue of the definitions for those entities being not being in the manpage.xml file itself, but in the parent XML file). Yes, that's part of it; it means that I can't check that I've fixed all the real errors by using nxml's valid/invalid indicator. Yeah, that part I don't think there's any good fix for, unfortunately. Schema languages (RELAXNG and W3C XML Schema) don't really support entities. You have to use an internal DTD subset in each document in order to be use them at all (which then screws with trying to include those same files by (system entity) reference into another (parent) doc. The other part, though, is that nxml doesn't know I'm editing a DocBook file, so it doesn't flag things like not placing para between a listitem and the text it contains. Ah, OK. That at least I know there's a way to handle. It does at least check that the XML is well-formed (so it complains if I, e.g., don't balance my tags out), but none of the more semantic checks are performed. yeah, I understand what you mean now. I should have read your original mail more carefully... You mentioned having the schema set to DocBook. I went through the nxml-mode help yesterday and didn't see a way to do that; is there an Emacs function I have to call to set the schema manually? The way to do it is a bit opaque/arcane (as is most Emacs stuff I guess), but there is a way at least: You need to set the value of the rng-schema-locating-files variable to include the path to a file that contains a custom locating rule that tells Emacs to how to do associations of files to particular schemas. One way to set that is by including the following in your .emacs: (setq rng-schema-locating-files (append '(~/locatingrules.xml) rng-schema-locating-files-default)) Then, create a ~/locatingrules.xml file (of course you can name the file whatever you want and put it wherever you want) with the following content: locatingRules xmlns=http://thaiopensource.com/ns/locating-rules/1.0; documentElement prefix= localName=refentry typeId=DocBook/ /locatingRules That tells nxml-mode that any file which has a refentry element as its root element should be validated against the DocBook schema. With the file in place and with the rng-schema-locating-files variable set to point it, nxml-mode should automatically set the schema for the manpage.xml file to DocBook when you load it. If the above doesn't work for you, definitely let me know. --Mike P.S. FWIW, there's a system-wide file installed along nxml-mode that has a default set of locating rules: /usr/share/emacs/site-lisp/nxml-mode/schema/schemas.xml -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ locatingrules.xml Description: XML document
Bug#473722: aptitude: patch to fix bugs in manpage.xml source
Package: aptitude Version: 0.4.10-1+b2 Severity: important Tags: patch Source: aptitude Some of the DocBook markup in list items in the doc/en/manpage.xml source file is not valid and can't be processed properly by the DocBook XSL stylesheets, resulting in broken display of those parts of the aptitude.8 man page. The problem in the DocBook source is that there are instances where a listitem instance has text child content. That's not valid. The patch below fixes the problems by wrapping the text in simpara instances. para could also be used if you prefer. diff -r 9050a3ecc8ec doc/en/manpage.xml --- a/doc/en/manpage.xmlSun Mar 30 13:23:49 2008 -0700 +++ b/doc/en/manpage.xmlTue Apr 01 16:53:01 2008 +0900 @@ -952,14 +952,14 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new-upgrades/literal/term listitem - When the safe resolver is being used (i.e., link + simparaWhen the safe resolver is being used (i.e., link linkend='cmdlineSafeResolver'literal--safe-resolver/literal/link was passed or link linkend='configAlways-Use-Safe-Resolver'literalAptitude::Always-Use-Safe-Resolver/literal/link is set to literaltrue/literal), allow the dependency resolver to install upgrades for packages even if link linkend='configSafe-Resolver-No-New-Upgrades'literalAptitude::Safe-Resolver::No-New-Upgrades/literal/link - is set. + is set./simpara /listitem /varlistentry @@ -967,7 +967,7 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new-installs/literal/term listitem - Allow the link + simparaAllow the link linkend='manpageSafeUpgrade'literalsafe-upgrade/literal/link command to install new packages; when the safe resolver is being used (i.e., link @@ -978,7 +978,7 @@ i A texlive-latex-extra Conflicts textop resolver to install new packages. This option takes effect even if link linkend='configSafe-Resolver-No-New-Installs'literalAptitude::Safe-Resolver::No-New-Installs/literal/link - is true. + is true./simpara /listitem /varlistentry @@ -986,9 +986,9 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-untrusted/literal/term listitem - Install packages from untrusted sources without prompting. + simparaInstall packages from untrusted sources without prompting. You should only use this if you know what you are doing, as - it could easily compromise your system's security. + it could easily compromise your system's security./simpara /listitem /varlistentry @@ -1108,14 +1108,14 @@ i A texlive-latex-extra Conflicts textop termliteral--no-new-upgrades/literal/term listitem - When the safe resolver is being used (i.e., link + simparaWhen the safe resolver is being used (i.e., link linkend='cmdlineSafeResolver'literal--safe-resolver/literal/link was passed or link linkend='configAlways-Use-Safe-Resolver'literalAptitude::Always-Use-Safe-Resolver/literal/link is set to literaltrue/literal), allow the dependency resolver to install new packages even if link linkend='configSafe-Resolver-No-New-Upgrades'literalAptitude::Safe-Resolver::No-New-Installs/literal/link - is set. + is set./simpara /listitem /varlistentry @@ -2131,4 +2131,4 @@ The following packages will be REMOVED: citerefentryrefentrytitleapt/refentrytitlemanvolnum8/manvolnum/citerefentry /para /refsect1 -/refentry \ No newline at end of file +/refentry -- Package-specific info: Terminal: xterm $DISPLAY is set. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages aptitude depends on: ii apt [libapt-pkg-libc6.7-6 0.7.11 Advanced front-end for dpkg ii libc6 2.7-6 GNU C Library: Shared libraries ii libcwidget1 0.5.6.1-3 high-level terminal interface libr ii libgcc1 1:4.3.0-1 GCC support library ii libncursesw5 5.6+20080203-1 Shared libraries for terminal hand ii libsigc++-2.0-0c2a2.0.18-2 type-safe Signal Framework for C++ ii libstdc++64.3.0-1The GNU Standard C++ Library v3 Versions of packages aptitude recommends: pn aptitude-doc-en | aptitude-do none (no description available) pn libparse-debianchangelog-perl none (no description available) -- no debconf information -- Michael(tm) Smith http://people.w3.org/mike/ http
Bug#473722: updated patch
Here's an update to the patch for this bug report. This fixes on additional minor problem: An x-ref that had a typo in the value of ID it links to (should be configCmdLine-Verbose instead of configCmdLineVerbose). diff -r 9050a3ecc8ec manpage.xml --- manpage.xml Sun Mar 30 13:23:49 2008 -0700 +++ manpage.xml Tue Apr 01 19:22:22 2008 +0900 @@ -952,14 +952,14 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new-upgrades/literal/term listitem - When the safe resolver is being used (i.e., link + simparaWhen the safe resolver is being used (i.e., link linkend='cmdlineSafeResolver'literal--safe-resolver/literal/link was passed or link linkend='configAlways-Use-Safe-Resolver'literalAptitude::Always-Use-Safe-Resolver/literal/link is set to literaltrue/literal), allow the dependency resolver to install upgrades for packages even if link linkend='configSafe-Resolver-No-New-Upgrades'literalAptitude::Safe-Resolver::No-New-Upgrades/literal/link - is set. + is set./simpara /listitem /varlistentry @@ -967,7 +967,7 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new-installs/literal/term listitem - Allow the link + simparaAllow the link linkend='manpageSafeUpgrade'literalsafe-upgrade/literal/link command to install new packages; when the safe resolver is being used (i.e., link @@ -978,7 +978,7 @@ i A texlive-latex-extra Conflicts textop resolver to install new packages. This option takes effect even if link linkend='configSafe-Resolver-No-New-Installs'literalAptitude::Safe-Resolver::No-New-Installs/literal/link - is true. + is true./simpara /listitem /varlistentry @@ -986,9 +986,9 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-untrusted/literal/term listitem - Install packages from untrusted sources without prompting. + simparaInstall packages from untrusted sources without prompting. You should only use this if you know what you are doing, as - it could easily compromise your system's security. + it could easily compromise your system's security./simpara /listitem /varlistentry @@ -1108,14 +1108,14 @@ i A texlive-latex-extra Conflicts textop termliteral--no-new-upgrades/literal/term listitem - When the safe resolver is being used (i.e., link + simparaWhen the safe resolver is being used (i.e., link linkend='cmdlineSafeResolver'literal--safe-resolver/literal/link was passed or link linkend='configAlways-Use-Safe-Resolver'literalAptitude::Always-Use-Safe-Resolver/literal/link is set to literaltrue/literal), allow the dependency resolver to install new packages even if link linkend='configSafe-Resolver-No-New-Upgrades'literalAptitude::Safe-Resolver::No-New-Installs/literal/link - is set. + is set./simpara /listitem /varlistentry @@ -1452,7 +1452,7 @@ The following NEW packages will be insta para When combined with literal-v/literal or a non-zero value for link - linkend='configCmdLineVerbose'literalAptitude::CmdLine::Verbose/literal/link, + linkend='configCmdLine-Verbose'literalAptitude::CmdLine::Verbose/literal/link, this displays the entire chain of dependencies that lead each package to be installed. For instance: /para @@ -2131,4 +2131,4 @@ The following packages will be REMOVED: citerefentryrefentrytitleapt/refentrytitlemanvolnum8/manvolnum/citerefentry /para /refsect1 -/refentry \ No newline at end of file +/refentry --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ diff -r 9050a3ecc8ec manpage.xml --- manpage.xml Sun Mar 30 13:23:49 2008 -0700 +++ manpage.xml Tue Apr 01 19:22:22 2008 +0900 @@ -952,14 +952,14 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new-upgrades/literal/term listitem - When the safe resolver is being used (i.e., link + simparaWhen the safe resolver is being used (i.e., link linkend='cmdlineSafeResolver'literal--safe-resolver/literal/link was passed or link linkend='configAlways-Use-Safe-Resolver'literalAptitude::Always-Use-Safe-Resolver/literal/link is set to literaltrue/literal), allow the dependency resolver to install upgrades for packages even if link linkend='configSafe-Resolver-No-New-Upgrades'literalAptitude::Safe-Resolver::No-New-Upgrades/literal/link - is set. + is set./simpara /listitem /varlistentry @@ -967,7 +967,7 @@ i A texlive-latex-extra Conflicts textop termliteral--allow-new
Bug#473722: aptitude man pages added to regression tests for DocBook XSL stylesheets
I meant to mention in my report that I'm the maintainer of the man-page stylesheet in the DocBook XSL Stylesheets distribution, and the reason I came across the problems in the aptitude manpage.xml source is that I was in the process of adding the aptitude man-page sources to the set of sources I use for regression testing when I make updates to the manpages stylesheet. So, FWIW, I have an area for aptitude set up in the DocBook Project source repository: https://docbook.svn.sourceforge.net/svnroot/docbook/trunk/contrib/samples/refentry/aptitude It's just a makefile plus the patch; I run the makefile to check out the latest aptitude sources and build the docs against the changes to the manpage stylesheet in my workspace. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461709: /usr/sbin/spamd: spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA
Noah Meyerhans [EMAIL PROTECTED], 2008-03-04 08:28 -0500: On Sun, Jan 20, 2008 at 07:08:56PM +0900, Michael(tm) Smith wrote: spamd[8033]: spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA at /usr/lib/perl5/Net/DNS/RR.pm line 312 This bug is almost certainly in Net::DNS::RR from the libnet-dns-perl or Mail::SPF::Server from the libmail-spf-perl package. I'm not sure which yet, but spamassassin doesn't directly call the function that is generating this warning. Is this still happening on a (presumably) more up-to-date system? Not happening any longer. But up to March 13, I was getting a different but similar message: Can't locate object method new via package Net::DNS::RR::TXT at /usr/lib/perl5/Net/DNS/RR.pm line 305 Since March 13, that seems to have disappeared (I assume because when I did an apt-get upgrade, the Net::DNS::RR and/or Mail::SPF::Server package got upgraded). But I'm now seeing another error in the SPF stuff: spf: lookup failed: Can't locate object method qualifier_pattern via package Mail::SPF::Mech at usr/share/perl5/Mail/SPF/Record.pm line 212 So it almost seems like sort of a push-me-pull-you going on with those packages -- one bug gets fixed, another bug gets introduced... Anyway, I guess this particular bug can now be closed. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#461709: /usr/sbin/spamd: spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA
Michael Smith [EMAIL PROTECTED], 2008-01-20 18:55 +0900: I'm seeing the following message getting logged several times a day on my system. spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA To be clear, I'm seeing that message being logged by spamd, and the full message being logged is: spamd[8033]: spf: lookup failed: Can't locate object method new via package Net::DNS::RR::SOA at /usr/lib/perl5/Net/DNS/RR.pm line 312 :wq --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389832: xchat: words/characters getting truncated with LANG=ja_JP.UTF-8
Hi Bart, @2008-01-13 08:22 +0100: retitle 389832 xchat: words/characters getting truncated with LANG=ja_JP.UTF-8 tags 389832 help stop Michael, Does the problem still exist with version 2.8.4-1 ? No, I'm not seeing the problem any more. Whatever the cause was, it's now fixed in my environment at least, so I guess this bug can be closed. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#408842: Saxon 8 and Saxon 6 are separate upstream packages
Note that Saxon 8 is not a replacement for Saxon 6; it's a separate application upstream. Saxon 8 is a conformant XSLT 2.0 engine. Saxon 6 is a conformant XSLT 1.0 engine. The Saxon 6 Debian package needs to continue to remain available, because there are, stylesheet packages such as the docbook-xsl package that are based on XSLT 1.0, not on XSLT 2.0. --Mike P.S. In the case of the DocBook stylesheets, if/when we release a version of the stylesheets for use with Saxon 8 and whatever other XSLT 2.0 processors might be available by then, it will be a new, separate docbook-xsl2 package, not a replacement of the docbook-xsl package. -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#442049: pam_env Unable to open env file: /etc/environment
After upgrading pam packages yesterday, I'm seeing a similar problem, with messages in the following pattern getting logged dozens of time per day: Sep 13 17:02:17 sideshowbarker CRON[24692]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:02:17 sideshowbarker CRON[24692]: pam_unix(cron:session): session closed for user logcheck Sep 13 17:05:01 sideshowbarker CRON[25803]: pam_unix(cron:session): session opened for user news by (uid=0) Sep 13 17:05:01 sideshowbarker CRON[25802]: pam_unix(cron:session): session opened for user root by (uid=0) Sep 13 17:05:01 sideshowbarker CRON[25804]: pam_unix(cron:session): session opened for user root by (uid=0) Sep 13 17:05:01 sideshowbarker CRON[25803]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:05:01 sideshowbarker CRON[25802]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:05:01 sideshowbarker CRON[25804]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:05:01 sideshowbarker CRON[25803]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:05:01 sideshowbarker CRON[25803]: pam_unix(cron:session): session closed for user news Sep 13 17:05:01 sideshowbarker CRON[25802]: pam_env(cron:setcred): Unable to open env file: /etc/environment: No such file or directory Sep 13 17:05:01 sideshowbarker CRON[25802]: pam_unix(cron:session): session closed for user root ... I'm running testing/lenny on a server that I originally set up around 2004. I find neither an /etc/environment nor /etc/default/locale. I've not messed around manually with anything related to locale stuff; I update just by running apt-get update apt-get upgrade every few days. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#420114: DocBook XSL and git man pages
I'm the upstream maintainer of the manpages stylesheet in the DocBook XSL stylesheets distro, and I'm writing to say what Daniel noted earlier is completely correct. I made a backward-incompatible change in the 1.72.0 release that resulted in a regression that caused the bug described in this bug report. I have reverted that for the 1.73.0 release. (and unfortunately managed to introduce some additional regressions while I was at it -- but I think Daniel will have patched those downstream for the Debian 1.73.0 package). --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#385240: Debian bug #385240 (Cannot find unicode character file)
Vincent Lefevre [EMAIL PROTECTED], 2007-07-23 12:08 +0200: This bug seems to be fixed in 20041004-7. Yep --Mike -- Michael(tm) Smith http://people.w3.org/mike/ http://sideshowbarker.net/ smime.p7s Description: S/MIME cryptographic signature
Bug#429915: OTRS Installer Issue
Package: otrs2 Version: 2.1.7-2 Hi Torsten, when installing a new otrs2 system, the installer asks me at the beginning if I want to Configure database for otrs2 with dbconfig-common? Yes/No. Now if I select No, since I want to use my oracle 10.2g database, I am expecting the installer not to install any postgresql or mysql db on the system. Yet the next screen shows me a screen where I need to select postgresql or mysql, and if I say 'cancel' it comes back to that screen and doesn't let me leave, except if I install either postgresql/mysql. Could this be fixed? I mean if I say NO to dbconfig-common it should be obvious that I don't want any other databases installed and that I have my own database ready to connnect to, in my case even on a different server. I don't want to install software that I don't need on the system, and I also don't want the need to remove software that is installed by default but is never used by my system. kind regards, Tobias I am using Debian Etch 4.0 with dbd:oracle1.19 and Oracle DB 10.2g with OTRS2 2.1.6/2.1.7 debian built -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429916: OTRS Environment variable issues
Package: otrs2 Version: 2.1.7-2 Hi Torsten, When I enter any $ENV vars into the Config.pm http://Config.pm, otrs2 is not recognizing any of these. Though I expect otrs to identify $ENV vars through Config.pm http://Config.pm since Defaults.pm http://Defaults.pm shows that $ENV vars are possible in Config.pm http://Config.pm. At the moment I have put all the $ENV vars in apache2-perl-startup.pl yet IMHO they should also be recognized via Config.pm http://Config.pm. Kind regards, Tobias I am using Debian Etch 4.0 with dbd:oracle1.19 and Oracle DB 10.2g with OTRS2 2.1.6/2.1.7 debian built -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#340637: Debian bug #385240 (Cannot find unicode character file)
Chris, Dave, The problem described in Debian bug report #385240 can be reproduced using the following one-line XML document as a minimal test case. foo#xa0;/foo If I open that file in nXML mode, the following error message is emitted and nXML fails to fontify the buffer contents -- Internal nXML mode error in nxml-fontify (Cannot open load file /usr/share/emacs/site-lisp/nxml-mode/char-name/unicode/1D400-1D7FF) The cause appears to be the following patch that Dave submitted for bug #340637 and that was applied and released in the nxml-mode 20041004-6 package. --- nxml-mode-20041004.orig/rng-auto.el +++ nxml-mode-20041004/rng-auto.el @@ -56,8 +56,7 @@ (let* ((dir (file-name-directory load-file-name)) (schema-dir (concat dir schema/))) - (unless (member dir load-path) -(setq load-path (cons dir load-path))) + (add-to-list 'load-path dir 'append) (setq rng-schema-locating-files-default (list schemas.xml (abbreviate-file-name I hope that change can either be refined/fixed or backed out and that a new version of the package can be released soon. And in the mean time, I wonder if bug #385240 maybe should be moved to Serious or Important -- because as far as I can see, it breaks nxml fontification in any XML file that contains character references. --Mike -- Michael(tm) Smith http://people.w3.org/mike/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389832: only reproduces for me in ja_JP.UTF-8 environment
Here's a data point: If I set my environment to LANG=en_US.UTF-8, I don't observe this problem. I only observe it when I have my environment set to LANG=ja_JP.UTF-8. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384127: can't reproduce
I can't seem to reproduce this now, and anyway I suspect that it might have been caused by a bug in jless, not in groff. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#310895: docbook-xsl: Add option to enable filenames like $NAME.$LANG.$SECTION
Daniel Leidert [EMAIL PROTECTED], 2006-10-27 22:00 +0200: I got the above feature request. Because of a broken harddrive, I cannot check it myself atm, so I want to ask you directly: Do you already support the requested feature or is it something, that needs to be implemented? It's not yet supported. I'd need to implement support for it. In the latter case: What is your opinion about this feature request? Looks like a potentially worthwhile enhancement to me. But that said, I'm not sure I understand the use case. What's the purpose of an apt-get.fr.8 man page instead of just a man/fr/apt-get.8 page? In the case of implementing this, I guess such manpages should be put into $base.dir/$LANG if man.output.subdirs.enabled is enabled. Yep. But would that be in addition to adding support for foo.$LANG.1 ? --Mike -- Michael(tm) Smith xmpp:[EMAIL PROTECTED] irc://irc.freenode.net/mobile-web smime.p7s Description: S/MIME cryptographic signature
Bug#389694: xsltproc: problems with dblatex interaction (possibly due to patch for bug #383408)
Package: xsltproc
Version: 1.1.17-4
Severity: important
The dblatex application makes use of xsltproc. Since upgrading to
xsltproc 1.1.17, I am getting error messages such as the
following, which I do not get with xsltproc 1.1.16 -
/usr/local/share/dblatex/xsl/common/mklistings.xsl:104: element include:
XInclude error : encoding {$encoding} not supported
I suspect the cause is the patch that was applied to fix bug #383408.
Perhaps Andreas (dblatex packager for Debian) can try to see if he
can reproduce the errors.
--Mike
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages xsltproc depends on:
ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries
ii libgcrypt111.2.3-2 LGPL Crypto library - runtime libr
ii libgpg-error0 1.4-1 library for common error values an
ii libxml22.6.26.dfsg-3 GNOME XML library
ii libxslt1.1 1.1.17-4 XSLT processing library - runtime
xsltproc recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383408: this patch seems to break dblatex behavior
The dblatex application makes use of xsltproc. Since upgrading to
xsltproc 1.1.17, I am getting error messages such as the
following, which I do not get with xsltproc 1.1.16 -
/usr/local/share/dblatex/xsl/common/mklistings.xsl:104: element include:
XInclude error : encoding {$encoding} not supported
I suspect the cause is the patch that was applied to fix bug #383408.
Perhaps Andreas (dblatex packager for Debian) can try to see if he
can reproduce the errors.
--Mike
--
Michael(tm) Smith
xmpp:[EMAIL PROTECTED]
irc://irc.freenode.net/mobile-web
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#389832: xchat: words/characters getting truncated
Package: xchat Version: 2.6.4-2.1 Severity: important I just upgraded my xchat yesterday, and now parts of words and characters at the ends of lines are getting cut off in chat windows. Example: if the word windows falls at the end of a line, only half of the s will be rendered. Or it just may say windo (both w and s truncated). I don't see that pattern to the amount of truncation that happens. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages xchat depends on: ii libaspell15 0.60.4-4 GNU Aspell spell-checker runtime l ii libatk1.0-0 1.12.2-1 The ATK accessibility toolkit ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libcairo2 1.2.4-1 The Cairo 2D vector graphics libra ii libdbus-1-3 0.92-2 simple interprocess messaging syst ii libdbus-glib-1-20.71-2 simple interprocess messaging syst ii libfontconfig1 2.4.1-2 generic font configuration library ii libfreetype62.2.1-5 FreeType 2 font engine, shared lib ii libglib2.0-02.12.3-2 The GLib library of C routines ii libgtk2.0-0 2.8.20-1 The GTK+ graphical user interface ii libgtkspell02.0.10-3+b1 a spell-checking addon for GTK's T ii libice6 1:1.0.1-2X11 Inter-Client Exchange library ii libpango1.0-0 1.12.4-1 Layout and rendering of internatio ii libperl5.8 5.8.8-6.1Shared Perl library ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libsm6 1:1.0.1-2X11 Session Management library ii libssl0.9.8 0.9.8c-1 SSL shared libraries ii libx11-62:1.0.0-9X11 client-side library ii libxcursor1 1.1.7-4 X cursor management library ii libxext61:1.0.1-2X11 miscellaneous extension librar ii libxfixes3 1:4.0.1-4X11 miscellaneous 'fixes' extensio ii libxi6 1:1.0.1-3X11 Input extension library ii libxinerama11:1.0.1-4.1 X11 Xinerama extension library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender1 1:0.9.1-3X Rendering Extension client libra ii python2.4 2.4.3-8 An interactive high-level object-o ii tcl8.4 8.4.12-1.1 Tcl (the Tool Command Language) v8 ii xchat-common2.6.4-2.1Common files for X-Chat ii zlib1g 1:1.2.3-13 compression library - runtime xchat recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383408: [Dblatex-users] xsltproc: problems with dblatex interaction
benoit.guillon [EMAIL PROTECTED], 2006-09-27 23:35 +0200: Do the warnings still appear when using the -X option? Nope. Which is I guess what you'd probably expect. A No external file support message is emitted instead. Can you try the attached test case (from the docbook test suite)? Can you confirm that the listings are correctly displayed with the callouts bullets inside (and the callout list below)? I'll try it right now and let you know. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#383408: [Dblatex-users] xsltproc: problems with dblatex interaction
benoit.guillon [EMAIL PROTECTED], 2006-09-27 23:35 +0200: Can you try the attached test case (from the docbook test suite)? Can you confirm that the listings are correctly displayed with the callouts bullets inside (and the callout list below)? I just tried it. Results are here: http://sideshowbarker.net/outgoing/testco/ Despite the error messages, the callouts are displayed as expected (there are not callout lists below because there are actually no calloutlist instances in the XML source for the test case). --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#386580: Initial footnote support added
I added initial support for footnote and also for annotation and alt. Below is the change description for the commit. Please test with the latest snapshot and let me know what bugs you find. Added initial support in manpages output for footnote, annotation, and alt instances. Basically, they all now get handled the same way ulink instances are. They are treated as a class as note sources: A numbered marker is generated at the place in the main text flow where they occur, then their contents are displayed in an endnotes section at the end of the man page (currently titled REFERENCES, for English output, but will be changed to NOTES). This support is not yet complete. It works for most normal cases, but probably mishandles a good number of cases. More testing will be needed to expose the problems. It may well also introduce some bugs and regressions in other areas, including basic paragraph handling, handling of mixed block content, handling of other indented content, and handling of authorblurb and personblurb in the AUTHORS section. -- Michael(tm) Smith xmpp:[EMAIL PROTECTED] irc://irc.freenode.net/mobile-web -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386580: Adding warning message and suppressed footnote marker
The manpages stylesheet does not yet support output for footnote. The reason the footnote marker was being output is because the HTML stylesheets (which the manpages stylesheet) output it and I had not overridden that. The footnote marker is now suppressed, and if a refenty contains a footnote, the stylesheets will now output a message during processing that says: Warn: Output for footnote element is not yet supported. Foo ..where Foo is the refname of the refentry. You can test it with the latest snapshot. I will try to add complete footnote support in the next-next release (either 1.71.1 or 1.72.0, after the 1.71.0 release). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382505: We'd need to update the upstream docs also
If you were to change the Debian docbook-xsl package such that it uses /etc/papersize as a default papersize instead of using letter, as the upstream docs say, then you run the risk of a users discovering that every time they generate FO output, they are getting a different default thatn what the upstream docs say they should be getting, and them perhaps having no idea why that is happening. I suppose that if you implemented this, we could update the upstream docs to say that the default is letter except on Debian, where it's whatever is specified in /etc/papersize. But we've never put anything system-specific into the upstream docs before, and IMHO, this wouldn't really merit a setting a precedent for doing that. smime.p7s Description: S/MIME cryptographic signature
Bug#382505: We'd need to update the upstream docs also
Daniel Leidert [EMAIL PROTECTED], 2006-09-05 15:23 +0200: I thought about simply patching the docs in the debian package along with the param.xsl adding a notes That assumes the users actually have installed docbook-xsl-doc and that they are reading it instead of say, simply reading them over the web at http://docbook.sourceforge.net/release/xsl/current/doc/ That doesn't seem to me to be a very good assumption to make. I don't think, that this should be put in upstream docs directly. I would maybe suggest (if you like the idea of reading the libpaper config), that you implement this in the XSL2 stylesheets using unparsed-text() of a file, set to /etc/papersize by default. The DocBook XSL stylesheets are OS-agnostic, by design. /etc/papersize is not a system-agnostic value to set as a default in a set of stylesheets designed to work across platforms. The implementation for XSL1 is more a (working) workaround. But XSL2 offers the possibilities to do this, so it could be implemented. We are a long, long way away from having a usable set of stylesheets that rely on XSL2 See above. Don't put anything system specific into the docs. It's also possible, that one day this patch will be dropped, because of a better solution or any issues and then upstream docs may be outdated (and wrong) then. So I really don't think it's a good idea to put this into upstream docs. And my point is that if it's not put into the upstream docs (and believe me, I'm not disagreeing that is shouldn't be), then it the patch should be dropped from Debian. You otherwise will have users who have no idea where the default value is coming from. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#382505: We'd need to update the upstream docs also
Hi Daniel, I could simply add a note [1] to the xsl:message, where you (upstream) output, which format is used (fo/docbook.xsl - root.messages). IMHO this is enough to make users aware of this little workaround. [1] E.g.: See /usr/share/doc/docbook-xsl/README.Debian for more information. Yep. I hadn't thought of that. Great idea -- and sounds lke a reasonable solution to me. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#340637: patch breaks nxml-mode startup
The following part of the patch seems to break nxml-mode in my environment. See bug #385240 (Cannot find unicode character file) --- nxml-mode-20041004-4/rng-auto.el2004-10-04 13:57:56.0 +0900 +++ nxml-mode-20041004-6/rng-auto.el2006-09-06 13:35:11.0 +0900 @@ -56,8 +56,7 @@ (let* ((dir (file-name-directory load-file-name)) (schema-dir (concat dir schema/))) - (unless (member dir load-path) -(setq load-path (cons dir load-path))) + (add-to-list 'load-path dir 'append) (setq rng-schema-locating-files-default (list schemas.xml (abbreviate-file-name smime.p7s Description: S/MIME cryptographic signature
Bug#385240: change to
The culprit seems to be the following change that was made to the rng-auto.el file. --- nxml-mode-20041004-4/rng-auto.el2004-10-04 13:57:56.0 +0900 +++ nxml-mode-20041004-6/rng-auto.el2006-09-06 13:35:11.0 +0900 @@ -56,8 +56,7 @@ (let* ((dir (file-name-directory load-file-name)) (schema-dir (concat dir schema/))) - (unless (member dir load-path) -(setq load-path (cons dir load-path))) + (add-to-list 'load-path dir 'append) (setq rng-schema-locating-files-default (list schemas.xml (abbreviate-file-name smime.p7s Description: S/MIME cryptographic signature
Bug#385940: Fixed.
I've checked in a fix for this to upstream source. If possible, please test with the latest snapshot: http://docbook.sourceforge.net/snapshots/ But note this: address is a block element, always, and a DocBook verbatim also (the equivalent of an HTML PRE -- all linebreaks and whitespace within it are output as-is). So I'm not sure why you had it marked up like the following in your test file: paraFoo2 addressFooScreen/address/para If the intent of that was to try to make it display inline, it's not going to work -- not for HTML or FO output either -- because address is a block element so you might just as well mark it up like this: paraFoo2 addressFooScreen/address /para To see what I mean, compare the HTML output for the test file to the manpages output. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385940: Fixed.
Daniel Leidert [EMAIL PROTECTED], 2006-09-05 02:49 +0200: paraFoo2 addressFooScreen/address/para I was just testing with several verbatim elements to isolate the cause of this issue and the last I used was address. That's the whole reason. Ah, I see that now. I guess I would have realized that if I had taken time to actually read through the whole original bug report. Sorry for the noise about that. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#377783: debug log
Here's the last part of the debug log before it segfaults. mutt_index_menu[633]: Got op 99 a0007 NAMESPACE * NAMESPACE (( /)(#mhinbox NIL)(#mh/ /)) ((~ /)) ((#shared/ /)(#ftp/ /)(#news. .)(#public/ /)) browse_get_namespace: adding #mhinbox browse_get_namespace: adding #mh/ browse_get_namespace: adding ~ browse_get_namespace: adding #shared/ browse_get_namespace: adding #ftp/ browse_get_namespace: adding #news. browse_get_namespace: adding #public/ a0007 OK NAMESPACE completed a0008 LIST #mhinbox% a0008 OK LIST completed a0009 LIST #mh/% * NO /home/mikes/.mh_profile not found, mh format names disabled Handling untagged NO /home/mikes/.mh_profile not found, mh format names disabled smime.p7s Description: S/MIME cryptographic signature
Bug#377783: Gnatsweb bug #2444 filed upstream
Just FYI -- I've filed problem report #2444 for this issue in the mutt Gnatsweb bug-tracking system: http://bugs.mutt.org/cgi-bin/gnatsweb.pl?debug=database=muttcmd=view+audit-trailcmd=viewpr=2444 smime.p7s Description: S/MIME cryptographic signature
Bug#384127: groff: Special characters within \fB font escape not displayed correctly
Package: groff Version: 1.18.1.1-12 Severity: important I have a file containing the following and am viewing it in an en_US.UTF-8 environment. .SH AUTHOR .PP \fBSebastian\fR \fBDr\(:oge\fR .sp -1n .IP 3n Author. .SH COPYRIGHT Copyright \(co 2005 Sebastian Dr\(:oge The second instance of Dr\(:oge displays correctly, but the \fBDr\(:oge\fR instance does not (depending on which X shell I try it in, it either displays a replacement character, blank space, or some other character). I can reproduce this only on a Debian system. On other systems, the output displays as expected. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages groff depends on: ii groff-base 1.18.1.1-12 GNU troff text-formatting system ( ii libc62.3.6-15GNU C Library: Shared libraries ii libgcc1 1:4.1.1-5 GCC support library ii libice6 1:1.0.0-3 X11 Inter-Client Exchange library ii libsm6 1:1.0.0-4 X11 Session Management library ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-7 X11 client-side library ii libxaw7 1:1.0.1-5 X11 Athena Widget library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxmu6 1:1.0.1-3 X11 miscellaneous utility library ii libxpm4 1:3.5.4.2-3 X11 pixmap library ii libxt6 1:1.0.0-5 X11 toolkit intrinsics library Versions of packages groff recommends: ii gs 8.50-1.1Transitional package ii gs-gpl [gs] 8.50-1.1The GPL Ghostscript PostScript int ii imagemagick 7:6.2.4.5.dfsg1-0.9 Image manipulation programs ii libpaper11.1.19 Library for handling paper charact pn netpbm none (no description available) ii psutils 1.17-23 A collection of PostScript documen -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332474: (no subject)
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#332474: [EMAIL PROTECTED]strong supported in docbook-xsl 1.70.1.dfsg.1-0.2
Hi. I'm the upstream developer for the DocBook XSL manpages stylesheet. I added support for [EMAIL PROTECTED]strong to the upstream source quite a while back. I guess it was in the 1.69.1 release (which never got packaged for Debian). Anyway the Debian docbook-xsl 1.70.1.dfsg.1-0.2 package does contain the support, so I think this bug can probably be closed out. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383874: contrib normalization fixed upstream
Hi. I'm the upstream developer for the DocBook XSL manpages stylesheet. Daniel Leidert brought Debian bug #383874 to my attention. I've checked in a fix for bug #383874 to the upstream source. You can test it using the latest snapshot: http://docbook.sourceforge.net/snapshots/ The fix will be included in the next release -- which will either be numbered 1.70.2 or 1.80.0. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#383874: contrib normalization fixed upstream
Daniel Leidert [EMAIL PROTECTED], 2006-08-22 04:32 +0200: Thanks for the reply Michael. Just a question: The same issue affects also other children of author|editor|othercredit (like email, firstname, surname, authorblurb, ...). Shouldn't they be treated the same way? The authorblurb element can contain paragraph data, which can include verbatim environments (programlisting, screen, etc.). So it would be wrong to run normalize-space on it. As far as firstname and surname, yeah, perhaps they should be normalized. I'll take a look. If you have others mind, I can look at them case by case. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#383874: contrib normalization fixed upstream
Daniel Leidert [EMAIL PROTECTED], 2006-08-22 05:49 +0200: I think, the firstname and surname (othername too?), email, honorific and probably lineage elements should be normalized too, to avoid unintended linebreaks in the AUTHOR section. Fixed. Please test with the latest snapshot. All person name output is now normalized, as well as email. Also copyright output. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#254811: UTF-8 characters in docbook-xsl output
As noted, the unsightly accented characters are a result of HTML output being encoded in UTF-8 but being displayed in a browser with the encoding set to ISO 8859-1. This is not a bug in the DocBook XSL stylesheets. The stylesheets provide mechanisms for enabling you to set output encoding to whatever you want. For details, see the following: http://sagehill.net/docbookxsl/OutputEncoding.html Anyway, bug 254811 should be closed since this is neither a problem in the docbook-xsl Debian package nor in the upstream DocBook XSL stylesheets distribution. --Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291813: passivetex bugs, not docbook-xsl ones
xmlto relies on passivetex to convert the XSL-FO output from the DocBook XSL stylesheets to PDF. The error messages you cite are messages generated during the passivetex phase, not messages generated by any processing done with the DocBook XSL stylesheets. You could file this bug against the passivetex package, but I doubt it will do you much good -- the developer of passivetex has not made any fixes or updates to it in many years. If you haven't given up on DocBook yet, you might want to try DBLaTeX instead. http://dblatex.sourceforge.net/ It works much better than passivetex and is still being actively maintained by a maintainer who responds quickly to bug reports. Anyway, bug 291813 should probably be closed out. Or at least filed against a different package. No fix for this can or will ever be made upstream in the DocBook XSL stylesheets. --Mike smime.p7s Description: S/MIME cryptographic signature
Bug#383507: xml-core: Catalogs for ISO character entities should contain SYSTEM ID references
Package: xml-core Version: 0.09-0.1 Severity: important The XML versions of the ISO 8879:1986 character-entity sets are officially maintained by the W3 and the official base URL for them is: http://www.w3.org/2003/entities/iso8879/ The xml-core package adds data to the Debian XML and SGML catalog systems for resolving the FPI/PUBLIC ID for those character-entity sets, but adds no data for resolving the canonical SYSTEM ID for them. The package should add data for resolving the SYSTEM ID using the base URL above. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages xml-core depends on: ii perl 5.8.8-6.1 Larry Wall's Practical Extraction ii sgml-base 1.26 SGML infrastructure and SGML catal xml-core recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377783: mutt: segfault w/ .mh_profile not found.. when doing change-folder+questionmark
Package: mutt Version: 1.5.11+cvs20060403-2 Severity: important When doing c+? (change-folder+questionmark), mutt emits an error message saying, /home/mikes/.mh_profile not found, mh format names disabled, then segfaults. This is with IMAP, connecting to a UW-IMAP server. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'stable'), (70, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages mutt depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libdb4.44.4.20-3 Berkeley v4.4 Database Libraries [ ii libgnutls13 1.4.0-2 the GNU TLS library - runtime libr ii libidn110.6.3-1 GNU libidn library, implementation ii libncursesw55.5-2Shared libraries for terminal hand ii libsasl22.1.19.dfsg1-0.2 Authentication abstraction library ii smail [mail-transport-a 3.2.0.115-7.1Electronic mail transport system Versions of packages mutt recommends: ii locales 2.3.6-15 GNU C Library: National Language ( ii mime-support 3.36-1 MIME files 'mime.types' 'mailcap -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
