On 18/11/2024 10:33, Marc Haber wrote:
On Mon, Nov 18, 2024 at 10:29:43AM +, Matthew Vernon wrote:
On 18/11/2024 10:20, Marc Haber wrote:
On Sun, Nov 17, 2024 at 05:58:49PM +, Matthew Vernon wrote:
Can you disable them, please?
Sure, how would I do that?
Sorry, I've no idea
On 18/11/2024 10:20, Marc Haber wrote:
On Sun, Nov 17, 2024 at 05:58:49PM +, Matthew Vernon wrote:
Can you disable them, please?
Sure, how would I do that?
Sorry, I've no idea about how the aide autopkgtests are run...
Regards,
Matthew
Source: python-pcre2
Version: 0.3.0+ds-1
Severity: serious
Justification: blocking migration of another package
Hi,
PCRE2 JIT requires ARMv7 or better on 32-bit ARM, so is disabled on
armel (which only promises ARMv5) cf
https://manpages.debian.org/unstable/libpcre2-dev/pcre2jit.3.en.html
So
Source: aide
Version: 0.18.8-1
Severity: serious
Justification: blocking migration of another package
Hi,
PCRE2 JIT requires ARMv7 or better on 32-bit ARM, so is disabled on
armel (which only promises ARMv5) cf
https://manpages.debian.org/unstable/libpcre2-dev/pcre2jit.3.en.html
So the JIT te
Control: tags -1 help
Control: forwarded -1 https://github.com/PCRE2Project/pcre2/issues/565
On 15/11/2024 10:30, Simon McVittie wrote:
There is a different FTBFS on non-armel 32-bit architectures which might
also affect armel, or this might be a different failure mode with the same
root cause.
Control: tags -1 - help + pending
I would strongly recommend running dh_autoreconf. At the moment, pcre2 is
using the configure script as generated by upstream, which is not
meaningfully reviewable or bug-fixable.
Right, I've tested on eberlin, and using dh_autoreconf fixes this issue,
and th
On 15/11/2024 12:32, Simon McVittie wrote:
[useful stuff]
Thanks, worth looking at. FTR, 10.42-4 does still build in an unstable
mips64el environment (which seemed an obvious thing to double-check).
Regards,
Matthew
Control: tags -1 fixed-upstream
This is, I think, fixed in this upstream MR:
https://github.com/PCRE2Project/pcre2/pull/418
Obviously it needs applying to the Debian 10.44 package; I'll see how
1087562 goes before deciding whether to upload a 10.44 with just this patch.
Regards,
Matthew
On 15/11/2024 10:55, Chris Hofstaedtler wrote:
* Matthew Vernon [241115 11:45]:
Hm. AFAICT there is no mips64el porterbox available to test things on, only
buildds which don't have open access.
eberlin.d.o should work.
Thanks. I filtered the machine list for mips64el which explains
Control: tags -1 help
On 15/11/2024 10:24, Simon McVittie wrote:
This looks like it might be a problem with some toolchain component
(but I don't know which one), so please reassign and set "affects" on
src:pcre2 as appropriate.
Hm. AFAICT there is no mips64el porterbox available to test thin
On 30/09/2024 09:07, Daniel Lewart wrote:
Dear Chris, Helmut, and Matthew,
1) pcre3 is no longer a key package
2) On Aug 15, pcre3 was removed from testing
Can this bug be closed and marked as done?
There are still a bunch of packages (now only in unstable) that
{build,}-depend on pcre3 - s
Hi,
On 08/08/2024 21:38, Bastian Germann wrote:
I am uploading a NMU to DELAYED/10 in order to fix this.
Please find the debdiff attached.
Thanks (I was on VAC); do note that pcre3 is not going to be in the
trixie release, though (cf. bug 1071970).
Regards,
Matthew
Hi,
On 07/08/2024 06:18, Paul Gevers wrote:
On 06-08-2024 23:33, Bastian Germann wrote:
I am including a patch to drop the libpcre3-udeb.
Please consider applying so that the package can be autoremoved.
Please don't do that until you have approval from d-i. I included them
in the mail chain.
Hi,
On 06/08/2024 09:11, Bastian Germann wrote:
pcre3 is still showing up with "reason: priority" as key package in
https://udd.debian.org/cgi-bin/key_packages.yaml.cgi
So this bug's severity will not take effect to autoremove it even when
cfengine3 has migrated to testing.
I cannot find the
Hi,
I looked at the build log, and the problems look to be disk related?
/usr/bin/ld: final link failed: No space left on device
collect2: error: ld returned 1 exit status
(there follow further ENOSPC and also some No such file or directory
errors, which presumably relate to things not written
Hi,
On 21/12/2023 09:41, Helmut Grohne wrote:
Is it ok to call upgrade scenarios failures that cannot be reproduced
using apt unsupported until we no longer deal with aliasing?
I incline towards "no"; if an upgrade has failed part-way (as does
happen), people may then reasonably use dpkg dir
Hi,
On 06/07/2023 06:33, Vasyl Gello wrote:
Yes I definitely see the bug. However, Kodi extensively uses pcrecpp and
the only replacement I see for pcre2 is jpcre2 [1]
There is an ITP bug about it since 2017 but no package.
Matthew, from your experience, is jpcre2 the only C++ wrapper for pcr
Hi,
On 10/03/2023 23:12, Jose Antonio Jimenez Madrid wrote:
I have just uploaded to mentors a new version of the package fixing this
bug.
I will made other improvements after Bookworm is released as we are very
close to the full freeze.
The new package can be found here:
https://mentors.debian
Hi,
On 14/02/2023 18:36, Jose Antonio Jimenez Madrid wrote:
I will test this patch and let you to know whether the bug is fixed.
Any joy? We're approaching the time that eterm is going to be
autoremoved from bookworm...
Thanks,
Matthew
Package: rsyslog
Version: 8.2212.0-1
Severity: serious
Hi,
When removing the systemv init scripts from rsyslog (which can be
managed by orphan-sysvinit-scripts), the following was also removed from
/usr/lib/rsyslog/rsyslog-rotate:
else
invoke-rc.d rsyslog rotate > /dev/null
This means on
Hi,
Do you have plans to fix this before the bookworm freeze, please?
I think netbsd at least have patched eterm to work with the newer imlib;
at least per the comment here https://github.com/mej/Eterm/issues/4
That linked to http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/x11/eterm/patches/
Whic
Hi,
I'm struggling a bit here; I wanted to try and bisect pcre2 upstream
commits to see where this bug might have been introduced (or get to the
bottom of what link-grammar's test is doing wrong, I see they've been
troublesome in the past cf #975696).
I took unstable's link-grammar source, a
Hi,
On 05/01/2023 01:07, Adrian Bunk wrote:
https://tracker.debian.org/pkg/pcre2
Issues preventing migration:
∙ ∙ autopkgtest for link-grammar/5.11.0~dfsg-1: amd64: Pass, arm64: Regression
♻ (reference ♻), armel: Regression ♻ (reference ♻), armhf: Regression ♻
(reference ♻), i386: Pass, ppc64
Hi,
On 22/11/2021 09:16, Ondřej Surý wrote:
I analysed the problem in:
https://github.com/PhilipHazel/pcre2/issues/56
Thanks! I've had a read of that, and AIUI it's a behaviour change
(matching that of perl) rather than an ABI change?
I guess bumping the version in the symbols file like
Hi,
On 15/11/2021 14:34, Ondřej Surý wrote:
This appears when built with 10.39, but the runtime version is less than that.
My guess is that this needs manual debian/libpcre2-8.shlibs override. (Or just
mangle the symbols file, so it always generates correct versioned dependency.)
I've had a
Hi,
On 15/11/2021 14:03, Ondřej Surý wrote:
It’s still a bug, but I think it might be a bug in pcre2. The other
Matthew (in CC) might need to bump the shlibs on the shared lib to >= 10.39
I'm slightly confused - this appears to be an issue in a php function
that went away after an upgrade? Or
On 21/02/2021 22:30, Vincent Lefevre wrote:
On 2021-02-21 14:06:20 -0400, Jesse Smith wrote:
A new version of SysV init and innserv have been published today. The
new version of insserv (1.23.0) fixes the above issue. It can be
downloaded from here: http://download.savannah.nongnu.org/releases/s
-levels and document Default-{Start,Stop} more clearly
+(Closes: #971713)
+
+ -- Matthew Vernon Sun, 21 Feb 2021 17:13:07 +
+
insserv (1.21.0-1) unstable; urgency=medium
* New upstream release
diff --git a/debian/patches/patches-from-trek-closes-971713.patch b/debian/patches/patches-fro
On 15/12/2020 21:34, Jesse Smith wrote:
On 2020-12-15 5:04 p.m., Trek wrote:
On Tue, 15 Dec 2020 12:45:40 -0400
Jesse Smith wrote:
I gave the patch a test run and, while I like what it does in theory,
in practise I'm running into trouble with it. When I use the attached
patch and then run "ma
forcemerge 946279 946290
quit
Hi,
Please check the BTS for duplicates before filing bugs.
Thanks,
Matthew
On 06/12/2019 15:53, Boyuan Yang wrote:
> When installing the new package libpcre2-posix2, it provides the same file as
> libpcre2-posix0 without declaring Breaks: relationship. This would make the
> upgrade fail.
Bother, yes, this is because the previous libpcre2-posix0 was misnamed
(the soname
Hi,
I've pushed a -2 with a patch from upstream that fixes an ARM issue; I'm
not sure it'll be what we need, but we'll see.
Regards,
Matthew
forwarded 945972 https://bugs.exim.org/show_bug.cgi?id=2478
quit
On 01/12/2019 23:15, Michael Biebl wrote:
> pcre2 FTBFS on armel:
> https://buildd.debian.org/status/fetch.php?pkg=pcre2&arch=armel&ver=10.34-1&stamp=1574962559&raw=0
Thanks for the bug report; I've forwarded it upstream. I'm afrai
On 22/08/2019 18:50, Antoine Amarilli wrote:
Hi Chris,
On Wed, Aug 21, 2019 at 03:52:44PM -0700, Chris Lamb wrote:
Cool! I'm not sure whether this other edge case is important -- are
there situations where an attacker in front of a locked computer could
manage to pull this off?
I think we m
forwarded 925360 https://bugs.exim.org/show_bug.cgi?id=2385
quit
Hi,
On 23/03/2019 18:54, Guillem Jover wrote:
> I just upgraded a server of mine to Debian buster, and roundcube's
> postinst started to crash with "Illegal instruction" messages from a
> php process, due to usage of a SSE2 instruc
On 06/03/2019 15:04, Andrej Shadura wrote:
> On Mon, 04 Mar 2019 22:54:04 + Santiago Vila wrote:
>> dh_makeshlibs -plibpcre3 --add-udeb="libpcre3-udeb" -V 'libpcre3 (>=
>> 1:8.35)' -- -c4
>> dh_makeshlibs -plibpcrecpp0v5 -V 'libpcrecpp0v5 (>= 7.7)' -- -c4
>> dpkg-gensymbols: error: some symbo
On 08/10/18 21:38, Adrian Bunk wrote:
On Mon, Oct 08, 2018 at 08:53:57PM +0100, Matthew Vernon wrote:
Hi,
Hi Matthew,
On 27/09/18 19:09, Adrian Bunk wrote:
I've prepared an NMU for rsbackup (versioned as 5.0-2.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I s
Hi,
On 27/09/18 19:09, Adrian Bunk wrote:
I've prepared an NMU for rsbackup (versioned as 5.0-2.1) and uploaded
it to DELAYED/14. Please feel free to tell me if I should cancel it.
Thanks, but the right answer is to upload 5.1-1, which I will be doing
shortly.
Regards,
Matthew
severity 904506 important
quit
So this has now built successfully (I think version skew between gcc :-/
), so I think the severity is now important. Probably still worth making
more symbols optional.
Regards,
Matthew
On 24/07/18 23:10, Simon McVittie wrote:
Source: pcre3
Version: 2:8.39-11
Severity: serious
Justification: fails to build from source (but built successfully in the past)
https://buildd.debian.org/status/package.php?p=pcre3 says pcre3 is still
failing to build on most architectures with symbols
Hi,
FYI.
https://github.com/libsigcplusplus/libsigcplusplus/issues/1
HTH,
Matthew
On 21/07/18 13:22, Richard Kettlewell wrote:
In https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897852:
I think this is a pangomm bug - see the errors below about incompatible
function type casts.
To me it looks like a sigc++ bug, and one that is being addressed upstream:
https://github.com
reassign 897852 src:pangomm
quit
Hi,
I think this is a pangomm bug - see the errors below about incompatible
function type casts.
I was misled by the final error message, but actually, that's because
the autoconfery for rsbackup does:
# 1. Glibmm uses C++14 features
# 2. Which Clang moans
reassign 897852 src:rsbackup
quit
Sorry again. I completely forgot I'd already been round this loop, and
am already blocked by 897895
I need more coffee :(
Matthew
Hi,
On 10/03/18 00:51, Jonathan Nieder wrote:
Thanks. This FTBFS bug is still serious, but even better, you can
close it.
I was going to keep this bug open for the underlying JIT-on-mips issue :)
I don't see the new version at
https://salsa.debian.org/debian/pcre2/commits/master. Is it on
Hi,
This is blocking git updates from migrating to testing
(https://qa.debian.org/excuses.php?package=git), so my preference
would be removing "mips mipsel mips64el" from the list of JIT arches
for now as a stopgap.
Done and uploaded, so I've downgraded this bug to important.
Regards,
Matthe
On 9 March 2018 18:47:25 GMT+00:00, Jonathan Nieder wrote:
>Hi,
>
>Matthew Vernon wrote:
>> On 09/03/18 15:20, James Cowgill wrote:
>
>>> Source: pcre2
>>> Version: 10.31-1
>>> Severity: serious
>[...]
>>> pcre2 FTBFS on mips* with lots
Hi,
On 09/03/18 15:20, James Cowgill wrote:
Source: pcre2
Version: 10.31-1
Severity: serious
Tags: sid buster
Forwarded: https://bugs.exim.org/show_bug.cgi?id=2254
Hi,
pcre2 FTBFS on mips* with lots of testsuite failures. It looks to me
like the JIT is bust.
I forwarded the log upstream to th
On 03/12/17 22:27, Matthew Vernon wrote:
2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't
seem to have worked on on s390, despite the build being known to work if
called entirely with ulimit -s unlimited. I think I'd like some help
from the s390 people here
On 11/10/17 08:39, Gianfranco Costamagna wrote:
control: tags -1 -moreinfo
Could you try re-running this test on s390x with a higher stack limit
set, please?
ulimit -s unlimited && dpkg-buildpackage works on zelenka (s390x porterbox)
I thought I'd modified the build script to have the same e
control: reopen -1
quit
2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't
seem to have worked on on s390, despite the build being known to work if
called entirely with ulimit -s unlimited. I think I'd like some help
from the s390 people here - how am I driving the buildd wr
control: reopen -1
quit
2 problems - the freebsd buildds give EPERM on ulimit, and it doesn't
seem to have worked on on s390, despite the build being known to work if
called entirely with ulimit -s unlimited. I think I'd like some help
from the s390 people here - how am I driving the buildd wr
On 03/12/17 05:45, Jeremy Bicha wrote:
pcre3 2:8.39-6 still fails to build on the Debian buildds on s390s:
https://buildd.debian.org/status/package.php?p=pcre3
OK; looks like I need to add `ulimit -s hard` before running the tests,
then.
Regards,
Matthew
On 20/11/17 22:22, Adrian Bunk wrote:
[snip]
One real-world problem where this dodgy code does break has been found
to affect real software, and the suggested patch that disables some
otherwise possible optimizations for one function is confirmed to
workaround this specific breakage.
This is a
severity 878107 important
tags 878107 + upstream moreinfo
quit
Hi,
On 09/10/17 21:23, Ondřej Surý wrote:
> the system-wide pcre3 library stack frame size detection is broken as
> described in
> https://bugs.exim.org/show_bug.cgi?id=2173
I note that upstream aren't proposing to address this.
>
tags -1 moreinfo
quit
Hi,
> Test 2: API, errors, internals, and non-Perl stuff (not UTF-16)
> Segmentation fault
>
> ** Test 2 requires a lot of stack. If it has crashed with a
> ** segmentation fault, it may be that you do not have enough
> ** stack available by default. Please see the 'pcresta
Package: xorg
Version: 1:7.7+19
Severity: serious
Hi,
Since upgrading to stretch, I can no longer switch to a VT - if I do
Ctrl-Alt-F1 the mouse pointer briefly changes back to that of gdm3 (I
think), then the entire machine locks up solid - unresponsive to ping
or anything, and I have to power-c
Hi,
Attached would be the proposed debdiff for a NMU in case needed (I
will use in any case a delayed queue if I upload).
Let me know if you would appreciate the NMU or prefer to do the upload
on your own if you agree.
Thanks for this; given you've done the necessary work (that was quick!),
tags 811969 +moreinfo
quit
Hi,
>> dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see
>> diff output below
>> dpkg-gensymbols: warning: some symbols or patterns disappeared in the
>> symbols file: see diff output below
>> dpkg-gensymbols: warning: debian/libpcrecpp0v5/D
Package: virtualbox-dkms
Version: 4.3.36-dfsg-1+deb8u1
Severity: serious
Hi,
This module does not build on my system any more (see attached log)
There appear to be at least 2 errors:
/var/lib/dkms/virtualbox/4.3.36/build/vboxdrv/r0drv/linux/memobj-r0drv-linux.c:581:21:
error: implicit declarat
Package: trn
Version: 3.6-24
Severity: grave
Tags: security upstream
Justification: user security hole
Hi,
I am the maintainer for trn, and have seen evidence that it's not safe
to use with untrusted input (e.g. usenet).
Further, I've asked and no-one wants to work on its rather elderly
code-b
Package: icedove
Version: 1:45.1.0-1
Severity: serious
Hi,
The most recent icedove is far too unstable; it SEGVs fairly frequently.
I run it on my workstation at work, starting it afresh in the morning
and closing it when I leave work. I estimate I'm seeing a SEGV about
every other work-day. T
fixed 819050 2:8.38-3
severity 819050 important
tags 819050 fixed-upstream upstream help
quit
Hi,
> When investigating a segmentation fault in suricata it was showing
> the crash is caused by libpcre3 when pcre_exec of a certain regex is
> called. Further investigations have shown that also prceg
On 23/12/15 17:23, Simon McVittie wrote:
X-Debbugs-Cc set to libpc...@packages.debian.org. Matthew, it would be
great if you could upload new pcre3 versions to experimental initially,
Sorry; I'll try and remember to do so for the next upstream release
(which won't be for a while).
Regards,
Hi,
This bug just bit me while upgrading my sbuild unstable chroot ; I
worked around it by creating /var/lib/libuuid , but I don't think people
should be expected to do this!
Regards,
Matthew
Package: linux
Version: 3.16.7-ckt11-1+deb8u2
Severity: critical
Hi,
TL;DR - please provide a kernel with a newer drbd module (e.g. 8.4.6),
as the current version is incompatible with stable's drbd-utils and
will result in kernel panics under load.
I have the following kernel:
Linux version 3.1
On 29/09/14 12:49, Apollon Oikonomopoulos wrote:
> Hi,
>
> On Thu, 18 Sep 2014 15:12:39 +0100 Matthew Vernon wrote:
>> It's Ben Harris' patch, not mine, but yes, I hope to upload a fixed
>> version. Don't let me stop you doing so sooner, though :-)
>
&
Hi,
On 18/09/14 11:39, Michael Prokop wrote:
> * Matthew Vernon [Mon Aug 04, 2014 at 04:37:51PM +0100]:
>> severity 714234 grave
>> tags 714234 +upstream patch
>> forwarded 714234 http://sourceforge.net/p/dump/bugs/157/
>> quit
>
>> This bug bit me, and meant
Hi,
Thanks for the report; I’ll get to this once I’m home from travelling (so not
for a week or so yet) unless someone gets an NMU in first.
The answer for post-jessie is perhaps to re-package to use debhelper for the
building, but I think a more minimal patch would be better for jessie.
Regar
Hi,
Upstream have released 0.3.15, which fixes this bug. I’m still away (and will
be for a while yet); would one of the java team mind uploading 0.3.15, please?
Hopefully it’ll just drop in on top of the existing packaging…
Thanks,
Matthew
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@li
Hi,
There's also an error in debian/ant-contrib.poms - the
--has-package-version is incorrect and should be removed, otherwise if
you build using maven, then mh_resolve_dependencies puts a versioned
dependency on 1.0b5-SNAPSHOT into the package you're building, which
isn't satisfiable.
Regards,
Package: ant-contrib
Version: 1.0~b3+svn177-5
Severity: serious
Tags: patch
Hi,
ant-contrib's installed POM contains 3 dependencies that are
unsatisfiable in the Debian maven repository. This means that
maven-based builds of packages that depend upon it will fail.
The enclosed patch adds a maven
Package: apache2-dev
Version: 2.4.4-2
Severity: serious
Tags: upstream
Hi,
httpd.h contains the following:
/** strtoul does not exist on sunos4. */
#ifdef strtoul
#undef strtoul
#endif
#define strtoul strtoul_is_not_a_portable_function_use_strtol_instead
i.e. apache intentionally breaks strtoul
Hi,
Sorry, I don't think this email's going to help very much.
On 02/01/13 22:49, Steven Chamberlain wrote:
Hi!
On 02/01/13 20:26, Cyril Brulebois wrote:
Jul 10 16:48:43 in-target: grub-common is already the newest version.
Jul 10 16:48:43 in-target: 0 upgraded, 0 newly installed, 0 to remo
Hi,
Thanks for all the activity on this bug. I have a couple of comments
i) finding this bug (and, well, some of the associated code quality
issues with bcrypt) has persuaded me that I don't want to use bcrypt for
any data I care about.
ii) "gpg -c --cipher-algo aes" is almost certainly a bett
Package: bcrypt
Version: 1.1-6
Severity: critical
Justification: causes serious data loss
Hi,
bcrypt doesn't handle at least some files (possibly large ones?).
This source file
13G -rw-r--r-- 1 matthew matthew 13G Nov 16 16:01 CTS-2012-11.tar.bz2
when encrypted with bcrypt -cr, results in on
tags 679320 moreinfo unreproducible help
quit
Hi!
Your package failed to build on the buildds:
rm -f eftest
cc -g -O2 -DUSE_SEMAPHORE -fPIC eftest.o libefence.a -o eftest -lpthread
Testing Electric Fence.
After the last test, it should print that the test has PASSED.
./eftest
Electric Fen
Hi,
I have just tested and the version in testing also FTBFS on kfreebsd
OOI, what's the failure mode?
Thanks,
Matthew
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On 19/09/11 15:55, Colin Watson wrote:
On Thu, Sep 08, 2011 at 06:14:49PM +0100, Colin Watson wrote:
* Build with -fno-tree-dse, since otherwise GCC>= 4.5 misoptimises
allocateMoreSlots() (closes: #625756, LP: #749139).
In fact, as GCC upstream pointed out, a more targeted - and I thin
Hi,
Hi.
the 2.1.15 lost previous support for GNU/kFreeBSD.
Please apply the same patch as previously or fix eftest.c
to handle both SIGBUS and SIGSEGV faults simultaneously
on all architectures.
Sorry, my mistake. I've uploaded 2.1.16 containing the same patch again.
Regards,
Matthew
--
No need to delay. I have been very busy, and can't directly upload myself
anyway. It would be good if someone else wants to take over as maintainer, as I
have not been keeping up on the package.
--matthew
Quoting David Paleino :
> Dear maintainer,
>
> I've prepared an NMU for log4cxx (versioned
Hi,
> OK. So let us see why it did not compile:
> sudo bash -x /usr/lib/emacsen-common/packages/vm emacs21
>
> That should have been run by the postinst.
I've attached the transcript. install fails because the clean step
fails because cus-load.el~ doesn't get deleted, so the
Hi,
Further experimentation shows that if I load
/usr/share/emacs21/site-lisp/vm/vm.el by hand then M-x vm works.
I still can't figure out why emacs21 can't do this by itself, but most
other lisp seems to be working, so I think it's a problem with the vm
packaging...
Matthew
--
"At least you
Package: vm
Version: 8.0.9-4
Severity: grave
Justification: renders package unusable
Hi,
I've just upgraded my home machine to lenny from etch, and now vm
doesn't work. At all. emacs -f vm says:
Symbol's function definition is void: vm
FWIW, load-path is:
("/home/mcv21/elisp/" "/home/mcv21/eli
Sorry, I mentioned two conflicting versions in my email...
I was testing with the current version in testing which is 3.52.6-2.
--Matthew
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
I could not duplicate this bug using the current version (3.52.4-5)
iodbc 3.52.6-2
libc2.7-13
the upstream releases included a number of bug fixes ... was this fixed?
Can anyone else duplicate this?
--Matthew Vernon
suner...@vernshome.net
--
To UNSUBSCRIBE, email to debian-bugs-rc
Chris Lamb writes:
> tags 494544 + patch
> thanks
Thanks for a very swift patch :)
Regards,
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsub
ng sort keys. POSIX 1003.1-2001 (*note
Standards conformance::) does not allow this; use `-k' instead. "
-k fields are numbered starting with 1
So, I think, the answer is to replace "sort +1nr" with "sort -nrk 2"
on line 71 of makeconc.pl
Matthew
--
Matthew Verno
On 7 Nov 2006, at 13:18, Bastian Blank wrote:
On Tue, Nov 07, 2006 at 12:44:56PM +, Matthew Vernon wrote:
What do you mean? are the files no longer there? not being used? what
symptoms are you observing? etc. etc. Many other people have upgraded
sarge->etch without a problem, so ple
are you observing? etc. etc. Many other people have upgraded
sarge->etch without a problem, so please provide as much information
as you can so we can track the problem down.
Matthew
--
Matthew Vernon MA VetMB LGSM MRCVS
Farm Animal Epidemiology and Informatics Unit
Department of Veterin
Hi,
* New upstream release. (Closes: #388289)
It's not clear to me that this does address this issue - will the new
packages install onto a stable system? Is that the recommended
solution for people running stable?
Matthew
--
Matthew Vernon MA VetMB LGSM MRCVS
Farm A
> The only thing that removes the high score file is purging the
> package -- so is it a possibility that angband was somehow purged? If
> not, I see no mechanism for the high scores file to have been removed.
Here's the relevant bits of the upgrade typescript:
Preparing to replace an
Hi,
> The only thing that removes the high score file is purging the
> package -- so is it a possibility that angband was somehow purged? If
> not, I see no mechanism for the high scores file to have been removed.
No, the package wasn't purged. I might even have a transcript of the
u
Package: python-mode
Version: 4.70-1
Severity: grave
Justification: renders package unusable
[EMAIL PROTECTED]:~# dpkg --configure python-mode
Setting up python-mode (4.70-1) ...
install/python-mode: Handling install for emacsen flavor emacs20
Wrote /usr/share/emacs20/site-lisp/python-mode/doctes
Package: angband
Version: 1:3.0.5-1
Severity: grave
Justification: causes non-serious data loss
Hi,
I just upgraded my system from woody to sarge, and angband has forgotten all
the previous high-scores (though my monster memory remains intact); there
wasn't even a warning this was going to happen
severity 368098 important
quit
> If you do not approve of this, please let me know.
I don't. Not least of which, your patch doesn't actually solve the
problem of not properly uniqifying the maintainer list.
Matthew
--
"At least you know where you are with Microsoft."
"True. I just wish I'd bro
Package: musixtex
Version: 1:0.112.1-3
Severity: grave
Justification: renders package unusable
Hi,
I wanted to add some music into a booklet I was typesetting. Prior to
adding music, LaTeX was happy.
I added the following snippet:
\begin{music}
\instrumentnumber{1}
\setstaffs{1}{2}
\setclef{1}{\
Hi,
I'm building fixed packages as I type this.
Matthew
--
Rapun.sel - outermost outpost of the Pick Empire
http://www.pick.ucam.org
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Hi,
> Is there any further information? Or, already fixed? I can't
> reproduce this bug.
Sorry, I've been busy.
> > 1. Are there any files in /usr/share/xemacs21/site-lisp/gnus? Do
> > you have *.elc files there?
Yes, 152 elc files. I have no idea where they came from,
though. Should
reopen #340503
quiit
> > foundation: "|/var/lib/mailman/mail/wrapper post foundation"
>
> > Now it has to look like:
>
> > foundation:"|/var/lib/foundation/mail/mailman post
> > foundation"
> ^^
>
> Certainly
1 - 100 of 109 matches
Mail list logo
