Bug#907732: maildir-utils: May need versioned depend on libxapian30
Hi Norbert, Sorry for the delay replying; lost track of this thread. > The problem I see is that during build even an old version can be used, > and during run time a version at least as new as the version it was > compiled against. > > But AFAIS this cannot be expressed in debian/control, and I would prefer > not introducing a strict dependency. > > Are you fine with closing this bug? Thanks for the explanation. That makes sense, and I'm fine with closing this bug. -Mark -- Mark J. Nelson Falmouth University http://www.kmjn.org
Bug#907732: maildir-utils: May need versioned depend on libxapian30
Norbert Preining writes: > But 1.4.7-2 is in testing, so there is not necessarily a need for having > a stricted dependency, as it would only complicate backporting. > > Upgrades from stable require full upgrade which also would bring in a > new libxapian30, so I don't really see the need to add this. > > Did you have a mixed system of partially updated one? It's a regular testing system, but yeah, partially updated. Maybe it's a bad habit nowadays, but I got in the habit years ago, when I had a slower internet connection, of updating software in aptitude individually, which I also like because it lets me keep tabs on what's pulling in what. Usually this works fine, because if software needs a newer version of a library it bumps the >= in the dependency, but in this case the unversioned depends on libxapian30 meant the upgrade didn't get pulled in. I see the point about complicating backports though, especially if xapian's upstream isn't carefully versioning its symbols. -Mark -- Mark J. Nelson Falmouth University http://www.kmjn.org
Bug#907732: maildir-utils: May need versioned depend on libxapian30
Package: maildir-utils Version: 1.0-6 Severity: normal Dear Maintainer, After upgrading maildir-utils from 1.0-5 to 1.0-6, some 'mu' commands stopped working with the following error message: mu: symbol lookup error: mu: undefined symbol: _ZN6Xapian4MSetaSEOS0_ Since I suspected this was some kind of mu/xapian version mismatch error, I upgraded libxapian30 from 1.4.5-1 to 1.4.7-2, which fixed the issue. Therefore I suspect that a more narrowly versioned depends is necessary. -Mark -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.16.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages maildir-utils depends on: ii dpkg1.19.0.5+b1 ii guile-2.2-libs 2.2.3+1-3+b1 ii install-info6.5.0.dfsg.1-2+b1 ii libc6 2.27-3 ii libgc1c21:7.4.2-8.3 ii libgcc1 1:8.2.0-4 ii libglib2.0-02.56.1-2 ii libgmime-2.6-0 2.6.23+dfsg1-1 ii libstdc++6 8.2.0-4 ii libxapian30 1.4.7-2 maildir-utils recommends no packages. maildir-utils suggests no packages. -- no debconf information
Bug#839639: latexml: Fails to load Error.pm
tags 839639 upstream fixed-upstream forwarded 839639 https://rt.cpan.org/Public/Bug/Display.html?id=112442 thanks This was fixed upstream in the 0.8.2 release. -- Mark J. Nelson The MetaMakers Institute Falmouth University http://www.kmjn.org
Bug#830564: texlive-bibtex-extra: please update the biblatex-ieee style
Norbert Preining writes: >> Manually updating to the current upstream version of biblatex-ieee >> from CTAN, version 2016/06/27, fixed the problem for me. > > The updated version is already in upstream TL and thus will be in > the next checkout/upload of the packages. Ah right, I should've checked there to see if the update was already on its way. Thanks! -Mark -- Mark J. Nelson MetaMakers Institute, Falmouth University http://www.kmjn.org
Bug#830564: texlive-bibtex-extra: please update the biblatex-ieee style
Package: texlive-bibtex-extra Version: 2016.20160623-1 Severity: normal Dear Maintainer, The current version of biblatex-ieee included in the texlive-bibtex-extra package, version 2016/05/08, appears to be incompatible with the current versions of biber (2.5) and TeX Live (2016.20160623). It produces this compile error when run through xetex+biber: ! Undefined control sequence. \bbl@main@language Manually updating to the current upstream version of biblatex-ieee from CTAN, version 2016/06/27, fixed the problem for me. Kind regards, Mark ## List of ls-R files -rw-r--r-- 1 root root 1301 Jul 8 18:35 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Feb 22 15:54 /usr/share/texmf/ls-R -> /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Jun 23 05:58 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Jun 23 05:58 /usr/share/texlive/texmf-dist/ls-R -> /var/lib/texmf/ls-R-TEXLIVEDIST ## Config files -rw-r--r-- 1 root root 475 Mar 22 21:40 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 3018 Jul 21 2015 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 Jun 23 05:58 /usr/share/texmf/web2c/updmap.cfg -> /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 2763 Jun 29 17:26 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 May 30 2014 mktex.cnf -rw-r--r-- 1 root root 475 Mar 22 21:40 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages texlive-bibtex-extra depends on: ii tex-common 6.05 ii texlive-base2016.20160623-1 ii texlive-binaries2016.20160513.41080-4 ii texlive-latex-base 2016.20160623-1 texlive-bibtex-extra recommends no packages. texlive-bibtex-extra suggests no packages. Versions of packages tex-common depends on: ii dpkg 1.18.7 ii ucf 3.0036 Versions of packages tex-common suggests: pn debhelper Versions of packages texlive-bibtex-extra is related to: ii tex-common6.05 ii texlive-binaries 2016.20160513.41080-4 -- debconf information excluded
Bug#237323: Diff output should be piped to pager
(Triaging old bugs.) Although I agree the default should probably use a pager, for what it's worth, this can be set in the config file as well. The 'diff' variable controls what command is used to diff. By default, it is, diff = diff -u CURRENT2 CURRENT1 (CURRENT1 and CURRENT2 are magic strings replaced with the two filenames.) You could change this to, diff = diff -u CURRENT2 CURRENT1 | pager -- Mark J. Nelson Anadrome Research http://www.kmjn.org
Bug#102300: unison: unison does not detect changes if time stamp didn't change
(Triaging old bugs.) The current version of the manual clarifies that this is intended default behavior, though it can be changed through a preference: "When running with the fastcheck preference set to true—the default on Unix systems—Unison uses file modtimes for a quick first pass to tell which files have definitely not changed; then, for each file that might have changed, it computes a fingerprint of the file's contents and compares it against the last-synchronized contents." Users who have programs that routinely update files without updating the modtime probably need to set fastcheck to false, which will avoid accidentally missing such files, at the expense of slower synchronization. I believe that's uncommon on Unix, which is the reason for the default. -- Mark J. Nelson Anadrome Research http://www.kmjn.org
Bug#394946: unison: merge2 option rejected
fixed 394946 2.48.3-1 fixed 394946 2.40.102-2 thanks Triaging an old bug: I believe the maintainers can safely close this bug. The 'merge2' option was removed almost a decade ago, and the documentation has long since been updated to remove any lingering confusion. -- Mark J. Nelson Anadrome Research http://www.kmjn.org
Bug#802919: unison: synchronization incompatibility when built with Ocaml versions pre/post-4.02
Package: unison Version: 2.48.3-1 Severity: normal Dear Maintainer, Since ocaml 4.02 recently entered unstable, I thought it might be a good time to bring up this issue (I haven't seen it discussed in another bug). Due to a change in ocaml's serialization format, unison built with an ocaml pre-4.02 can't synchronize with one built with 4.02 and later. This causes a compatibility mess, since the usual requirement that both endpoints must have the same unison version is no longer sufficient: they now have to have both the same unison version *and* be built by compatible versions of ocaml, either both pre-4.02 or both post-4.02. There is some discussion on the unison-users list here: http://marc.info/?l=unison-users&m=142286809310149&w=2 I am not sure what the best solution is. For the near-term future, there will probably be a significant number of installations needing both to be available. For example any Debian stable server will be using the pre-4.02 unison for some time to come. But anyone using unison on OSX via Homebrew, Macports, or pkgsrc already needs a post-4.02 version to sync with. -Mark -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages unison depends on: ii libc6 2.19-22 Versions of packages unison recommends: ii openssh-client [ssh-client] 1:6.9p1-2 Versions of packages unison suggests: pn unison-all -- no debconf information -- Mark J. Nelson Anadrome Research http://www.anadrome.org
Bug#705318: now in upstream stable
Fwiw, the current upstream stable (2.48.3) includes the -repeat watch functionality. Any plans to package the new version? -Mark -- Mark J. Nelson http://www.kmjn.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752622: mediawiki: 1.19.17 fixes security vulnerabilities
fixed 752622 1:1.19.17+dfsg-1 thanks I believe that since 1.19.17 has been uploaded, this bug can be closed. -Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org
Bug#728976: mlmmj: +list does not work
tags 728976 + upstream fixed-upstream thanks Fwiw, the 1.2.18.1 release is now out, and includes this fix (along with two other bugfixes). -Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#692026: 2.0.0 is in sid
fixed 692026 fish/2.0.0-1 fixed 709389 fish/2.0.0-1 thanks I believe these two wishlist bugs can be closed. They both requested an update from the old 1.23 release to the new, actively maintained upstream version, which was satisfied by the 11 July 2013 upload of fish 2.0.0. Fwiw, fish 2.1.0 was released just today, but that's another matter. Best regards, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#516499: says "Failed to open sound device." instead of entertaining
Fwiw, there's a FAQ entry about ALSA support upstream: * http://mp3blaster.sourceforge.net/#faq Perhaps the Debian package should be set up to use ALSA out of the box? That would smooth things for most users. However it requires compiling mp3blaster with SDL support (and depending on SDL), which is currently not the case. A separate bug, #565595, is already about that subject. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#527157: id3v2: written data depends on system locale, which can lead to corruption
fixed 527157 0.1.12-2.1 thanks I believe this is essentially the "write" version of the "read" problem in bug #559998, and both should be fixed in the patch recently NMU'd in 0.1.12-2.1. The charset issues are overall still pretty poor, though. Since both id3v2 and id3lib upstreams have been dormant for years, I believe the Debian maintainer (Stefan Ott) was planning to port id3v2 from id3lib to taglib, which is maintained upstream and handles charsets in a sane way. But I'm not sure what the status of the port is. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/
Bug#577722: Two minor security issues fixed in 0.8.15
Ran across this bug during some miscellaneous triage of old bugs. Since all currently supported Debian releases (i.e. squeeze onward) include 0.8.15, imo it can be closed. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#704527: biber: Character "(" not allowed in key although valid in BiBTeX
This bug should perhaps be reassigned to libbtparse1, since biber
currently defers to btparse on this matter. Unless biber would consider
changing its parsing back-end, it should probably be fixed (if at all)
in btparse.
From the btparse syntax documentation at
http://search.cpan.org/~gward/btparse-0.34/doc/bt_language.pod,
parentheses are purposely excluded from keys, but it's not clear if
that's due to a misunderstanding about whether they were allowed in
BibTeX. The documentation justifies why btparse removes '@', '\', and
'~' from the characters allowed in keys, even though BibTeX accepts
those three chars. But the docs claim that the following 10 characters
were already disallowed in BibTeX keys:
" # % ' ( ) , = { }
As you point out, this seems not to be true, since parentheses do work
in BibTeX. From my (non-expert) read of the PCCTS grammar under the
hood, it *should* be an easy fix: LPAREN as a semantically meaningful
element is only used in one very specific place in a BibTeX grammar, in
@comments, which shouldn't interfere with permitting parentheses in
entry keys. But I have not tried it.
Best,
Mark
--
Mark J. Nelson
IT University of Copenhagen
http://www.kmjn.org/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#280202: frozen-bubble: doesn't disable screensaver
I believe this (quite old!) bug can be closed. Since v1.2.10, released May 2006, SDL disables the X screensaver and DPMS monitor blanking by default, with an override option available for apps that *don't* want it disabled. So changes are no longer needed in frozen-bubble to get the desired behavior. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549653: feature not supported upstream
forwarded 549653 https://rt.cpan.org/Public/Bug/Display.html?id=84665 thanks Correction to my previous message: upstream actually does have a new maintainer. Therefore I've forwarded this request. Apologies for the misinformation. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#549653: feature not supported upstream
found 549653 2.019-1 tags 549653 upstream severity 549653 wishlist thanks This is still the case in the current version. But as reassigned to libpdf-api2-perl, this seems like a feature request more than a bug: PDF::API2 only supports certain kinds of compression, and duly errors out if an unsupported kind is requested. Unfortunately, upstream has been unmaintained since 2008, so the chances of significant new functionality being added are quite low, unless a new upstream maintainer is found. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/
Bug#631463: libpdf-api2-perl: Color data loaded from unicolor.txt is tainted since DSA-2265-1 fix applied
Recent versions of the package no longer load the color hash from unicolor.txt. Instead it's specified as a hash literal in PDF::API2::Resource::Colors. Therefore I believe this bug can be closed. Best, Mark -- Mark J. Nelson IT University of Copenhagen http://www.kmjn.org/
