Bug#264173:
Hi, Thanks for this patch, but I'm actually going to do something slightly differen, since I think having default: break; at the bottom of switch statements is good practice, and K+R agree with me :) Thanks, Matthew -- Matthew Vernon MA VetMB LGSM MRCVS Farm Animal Epidemiology and Informatics Unit Department of Veterinary Medicine, University of Cambridge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#149017:
severity 149017 wishlist merge 149017 84419 quit This is essentially the same bug as 84419. I'm not sure adding PAM is worth it... Matthew -- Matthew Vernon MA VetMB LGSM MRCVS Farm Animal Epidemiology and Informatics Unit Department of Veterinary Medicine, University of Cambridge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#714234: (no subject)
severity 714234 grave
tags 714234 +upstream patch
forwarded 714234 http://sourceforge.net/p/dump/bugs/157/
quit
Hi,
This bug bit me, and meant that restoring an incremental backup failed :-(
My justification of severity is that broken backups result in data loss.
Ben Harris has analysed the bug and suggested a patch; you can find them
attached to the "forwarded" URL above, but I include them here:
"More analysis, building on sangamesh's work above:
The bug is that in findunreflinks(), the code for removing unreferenced
directories unconditionally calls deleteino() and then adds the node to
removelist even though this might already have been done. This causes a
panic in deleteino() because e_ino is zero, and causes an infinite loop
when anything tries to traverse removelist. The fix will be to skip
directories that are already scheduled for deletion.
And here's a possible patch to fix the problem. It assumes that if an
entry has e_ino == 0, that means it's already been passed to deletino()
and added to removelist. I think this is true. It's certainly the case
that all additions to removelist have e_ino == 0, so this should stop
the hangs and the panics from removino(). At worst, it will leave
spurious directories around after a restore."
I think a fix to this should be seriously considered for stable.
Regards,
Matthew
Index: restore/restore.c
===
RCS file: /cvsroot/dump/dump/restore/restore.c,v
retrieving revision 1.39
diff -u -r1.39 restore.c
--- restore/restore.c 22 Mar 2010 16:08:10 - 1.39
+++ restore/restore.c 1 Aug 2014 14:03:56 -
@@ -593,7 +593,7 @@
if (np->e_type == LEAF) {
removeleaf(np);
freeentry(np);
- } else {
+ } else if (np->e_ino != 0){
np->e_flags |= TMPNAME;
deleteino(np->e_ino);
np->e_next = removelist;
Bug#714234: (no subject)
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 that restoring an incremental backup failed :-( >> My justification of severity is that broken backups result in data loss. > [...] >> I think a fix to this should be seriously considered for stable. > > Do you plan to upload a package including your change? > Because with the current severity of this bug report we won't see > dump in Debian/jessie otherwise. :( 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 :-) Regards, Matthew -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/541ae857.4010...@debian.org
Bug#714234: (no subject)
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 :-) > > As I would like to get ganeti-instance-debootstrap into jessie again, I > intend to make an upload fixing this tomorrow (debdiff attached), if > nobody objects. Sorry; I'd just completed an upload when I got your email. Regards, Matthew -- To UNSUBSCRIBE, email to debian-qa-packages-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54294a98.1080...@debian.org
Bug#305565: dosemu: Following installation instructions results in "..no operating system"
Package: dosemu Version: 1.0.2.1-7 Severity: grave Justification: renders package unusable Hi, I installed dosemu as per the instructions (including downloading the freedos tarball (whose location has changed)), and only ever get "Sorry, there is no operating system". Needless to say, this is somewhat frustrating and less than useful... Cheers, Matthew -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux ming 2.4.25 #3 Thu Mar 18 16:33:28 GMT 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages dosemu depends on: ii debconf 1.0.32 Debian configuration management sy ii libc6 2.2.5-11.8 GNU C Library: Shared libraries an ii slang11.4.4-7.2 The S-Lang programming library - r ii xbase-clients 4.1.0-16woody5 miscellaneous X clients ii xlibs 4.1.0-16woody5 X Window System client libraries ii xutils4.1.0-16woody5 X Window System utility programs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305565: acknowledged by developer (Use the recommended package.)
> dosemu-freedos is recommended and README.Debian tell you to use it. Not in stable, it doesn't. I suggest marking this one "woody", and closing it once sarge is out. 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]
Bug#999917: analog: depends on obsolete pcre3 library
Source: analog Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000006: parser: depends on obsolete pcre3 library
Source: parser Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000007: pads: depends on obsolete pcre3 library
Source: pads Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000027: awffull: depends on obsolete pcre3 library
Source: awffull Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000039: maildir-filter: depends on obsolete pcre3 library
Source: maildir-filter Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000059: libpcre++: depends on obsolete pcre3 library
Source: libpcre++ Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000077: c-icap: depends on obsolete pcre3 library
Source: c-icap Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000094: libopkele: depends on obsolete pcre3 library
Source: libopkele Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000096: cadabra: depends on obsolete pcre3 library
Source: cadabra Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000097: compton: depends on obsolete pcre3 library
Source: compton Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#1000123: fsvs: depends on obsolete pcre3 library
Source: fsvs Severity: important User: matthew-pcre...@debian.org Usertags: obsolete-pcre3 Dear maintainer, Your package still depends on the old, obsolete PCRE3[0] libraries (i.e. libpcre3-dev). This has been end of life for a while now, and upstream do not intend to fix any further bugs in it. Accordingly, I would like to remove the pcre3 libraries from Debian, preferably in time for the release of Bookworm. The newer PCRE2 library was first released in 2015, and has been in Debian since stretch. Upstream's documentation for PCRE2 is available here: https://pcre.org/current/doc/html/ Many large projects that use PCRE have made the switch now (e.g. git, php); it does involve some work, but we are now at the stage where PCRE3 should not be used, particularly if it might ever be exposed to untrusted input. This mass bug filing was discussed on debian-devel@ in https://lists.debian.org/debian-devel/2021/11/msg00176.html Regards, Matthew [0] Historical reasons mean that old PCRE is packaged as pcre3 in Debian
Bug#241297: prboom: Kills display when run in X
Package: prboom Version: 2.2.2-1 Severity: critical Justification: breaks the whole system Hi, if I start prboom from a console, I get aa-lib graphics (not very good, but there you go). If I start it from X, then my display goes black (and the monitor light suggests its not getting any signal), and the system is unrecoverable - the only way I get my display back is to reboot the system. I don't consider this acceptable... Matthew -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux ming 2.4.25 #3 Thu Mar 18 16:33:28 GMT 2004 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages prboom depends on: ii libc6 2.2.5-11.5 GNU C Library: Shared libraries an ii libsdl-mixer1.2 1.2.1-5mixer library for Simple DirectMed ii libsdl-net1.2 1.2.2-1.1 network library for Simple DirectM ii libsdl1.2debian 1.2.4-1Simple DirectMedia Layer ii libsmpeg0 0.4.4-8SDL MPEG Player Library - shared l ii xlibs 4.1.0-16woody3 X Window System client libraries
