Re: [Pkg-rust-maintainers] rustc/cargo in stretch
On Wednesday, May 3, 2017 12:09:11 PM UTC Julien Cristau wrote: > > So I think we should remove both packages from stretch and avoid painting > > ourselves into a corner. Thoughts? Can you elaborate a bit more on the "paint ourself in a corner"? From my side, I can contribute these datapoints: * there are no rdeps on purpose, as we decided to postpone policy + dh-cargo + libs/apps after stretch release * rustc and cargo are now tied in self-bootstrapping and crossed-bootstrapping loops, so having at least some (albeit old) versions of both in a release may help * those packages are mostly intended as stepstones to a full ecosystems of libs/apps and to make backports slightly easier, users are basically expected to use rustup anyway (as the language is still evolving) * firefox security updates story is more complex than I currently grok, but it may involve shipping a fresh cargo+rustc+llvm toolchain either ways Ciao, Luca -- "If you build a wall, think of what you leave outside it" - Italo Calvino signature.asc Description: This is a digitally signed message part.
Bug#819282: wheezy-pu: package openldap/2.4.31-2+deb7u2
On Tuesday, May 03, 2016 07:31:29 AM Ryan Tandy wrote: > On Sun, May 01, 2016 at 03:07:38PM -0700, Ryan Tandy wrote: > >On Sun, May 01, 2016 at 10:27:12PM +0100, Adam D. Barratt wrote: > >>Any news on the upload? > > > >None from me. Awaiting a response from my sponsor (CCed). > > The package has been uploaded now. Thanks, Luca! This was sitting in my pending queue for some time, sorry for the delay :( Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Re: libuv minor bumps
On Wednesday, April 13, 2016 12:07:37 AM Jérémy Lal wrote: > Blocking the transition to testing is enough for me right now Great, you could go ahead and report a versioned RC bug (or I'll do it in some time, UTC morning). > i'm in favor of waiting a little before deciding something, because > https://github.com/nodejs/node/pull/4276#issuecomment-167992719 > shows Node.js 4 might get libuv 1.9 soon. I'll ask saghul for an informal feedback on this, and hopefully to have some policy written down, officially agreeing with that. I think/hope there won't be any need to revert it all. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG: 0xBB1A3A854F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer
Bug#779266: unblock: libuv/0.10.28-6
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package libuv
Latest upload (0.10.28-6) is a minimal update fixing security
bug #779173 (CVE-2015-0278).
Debdiff attached.
unblock libuv/0.10.28-6
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
diff -Nru libuv-0.10.28/debian/changelog libuv-0.10.28/debian/changelog
--- libuv-0.10.28/debian/changelog 2014-09-21 14:52:46.0 +0200
+++ libuv-0.10.28/debian/changelog 2015-02-25 11:03:04.0 +0100
@@ -1,3 +1,10 @@
+libuv (0.10.28-6) unstable; urgency=high
+
+ * Backported: call setgroups before calling setuid/setgid
+(Closes: #779173 - CVE-2015-0278)
+
+ -- Luca Bruno lu...@debian.org Wed, 25 Feb 2015 10:50:58 +0100
+
libuv (0.10.28-5) unstable; urgency=medium
* Too early for versioned provides, reverted
diff -Nru libuv-0.10.28/debian/patches/series libuv-0.10.28/debian/patches/series
--- libuv-0.10.28/debian/patches/series 2014-09-20 23:24:57.0 +0200
+++ libuv-0.10.28/debian/patches/series 2015-02-25 10:41:19.0 +0100
@@ -2,3 +2,4 @@
make-clean.diff
test_runner.diff
arm64-epoll-ftbfs.diff
+setgroups_CVE-2015-0278.diff
diff -Nru libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff
--- libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff 1970-01-01 01:00:00.0 +0100
+++ libuv-0.10.28/debian/patches/setgroups_CVE-2015-0278.diff 2015-02-25 10:40:02.0 +0100
@@ -0,0 +1,46 @@
+From 2773e1181dfb1e10fc2e3bfd3ffd83c71b730408 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Sa=C3=BAl=20Ibarra=20Corretg=C3=A9?= sag...@gmail.com
+Date: Mon, 10 Feb 2014 17:41:51 +0100
+Subject: [PATCH] unix: call setgoups before calling setuid/setgid
+
+Backported from v1.x (66ab389)
+
+PR-URL: https://github.com/libuv/libuv/pull/215
+Reviewed-By: Ben Noordhuis i...@bnoordhuis.nl
+---
+ src/unix/process.c | 15 +++
+ 1 file changed, 15 insertions(+)
+
+diff --git a/src/unix/process.c b/src/unix/process.c
+index 19686a2..d1f9440 100644
+--- a/src/unix/process.c
b/src/unix/process.c
+@@ -40,6 +40,10 @@
+ extern char **environ;
+ #endif
+
++#ifdef __linux__
++# include grp.h
++#endif
++
+
+ static ngx_queue_t* uv__process_queue(uv_loop_t* loop, int pid) {
+ assert(pid 0);
+@@ -331,6 +335,17 @@ static void uv__process_child_init(uv_process_options_t options,
+ _exit(127);
+ }
+
++ if (options.flags (UV_PROCESS_SETUID | UV_PROCESS_SETGID)) {
++/* When dropping privileges from root, the `setgroups` call will
++ * remove any extraneous groups. If we don't call this, then
++ * even though our uid has dropped, we may still have groups
++ * that enable us to do super-user things. This will fail if we
++ * aren't root, so don't bother checking the return value, this
++ * is just done as an optimistic privilege dropping function.
++ */
++SAVE_ERRNO(setgroups(0, NULL));
++ }
++
+ if ((options.flags UV_PROCESS_SETGID) setgid(options.gid)) {
+ uv__write_int(error_fd, errno);
+ _exit(127);
Bug#771962: [Pkg-openldap-devel] Bug#614569: RFS: Bug#614569: slapd fails to dump/reload partial replica -- NMU sponsor needed
On Wednesday 03 December 2014 18:21:08 Ryan Tandy wrote: On Wed, Dec 03, 2014 at 11:40:24PM +0100, Ferenc Wagner wrote: I got pre-approval on #771962: the upload will be unblocked, provided it's in unstable by Monday the 8th of December. People with upload rights, if you can spare a minute please review the above change and consider sponsoring the upload! Actually, review is welcome from anybody. :) Thanks very much for working on this, and the debdiff looks fine (but I haven't actually built or tested it). I hope you can find a sponsor in time. Luca, are you reading? I was following the discussion, and I have to say that I am not too comfortable in uploading this NMU at this point of the release cycle. So NACK on my side. My main concerns are: * I am not sure that I grok all the implications of that. I suspect that most of our (overly) complex pre/postinst scripts makes some assumption on schema/db consistency, at least implicitly. * We are changing the default behavior to fix a single-case situation, by removing a safety check. Mmmh... * This bug has been open since some time, never marked as RC, put on low-priority by the maintainer and upstream discouraged dropping the -s. * This is not even the proper solution, just a quick-hack patch. Moreover, I don't consider myself an LDAP expert, but I have some comments on the issue: * I would say that requiring/checking schema integrity across upgrade is a good general measure, and we should NOT work around that. Fail early, fail loudly. * IIRC disabling schemachecking is heavily discouraged. We don't offer that option in debconf. I assume the admin are really aware of the setup, and know its quirk. * Workarounds for the specific corner case exists, but maybe are a bit undocumented. So my alternative suggestion is: let's make it explicit that we value schema integrity, and we rely on it across upgrades; let's put a point in the release notes to document how to workaround this partial replica scenario; let's try to address this better in the next point release. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 0x4F3BBEBF `- http://www.debian.org | Debian GNU/Linux Developer signature.asc Description: This is a digitally signed message part.
Bug#706937: pu: package gcc-msp430/4.6.3~mspgcc-20120406-3+deb7u2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi RT, I'd like to upload a stable +deb7u2 for gcc-msp430. This is the fix for #706482 which was not closed with +deb7u1 due to short timing before the release. This revision reverts the previous doc-only change and cherry-pick the upstream fix for the IVT layout of FRAM chips. Full diff attached, diffstat as follow: changelog |7 +++ control|5 -- lts-patch/fram-fuse-blown.diff | 80 + patchlist |1 4 files changed, 88 insertions(+), 5 deletions(-) Please ACK, so that I proceed with the p-u upload. - -- System Information: Debian Release: 7.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlGHjl8ACgkQRqobajv7n7P/TQCdFCPAk9hv7qfSNIGiQPWGx36V tWIAnRLkVeJVFgd3zzrezKBUjZg8g9Ab =dN8x -END PGP SIGNATURE- diff -Nru gcc-msp430-4.6.3~mspgcc-20120406/debian/changelog gcc-msp430-4.6.3~mspgcc-20120406/debian/changelog --- gcc-msp430-4.6.3~mspgcc-20120406/debian/changelog 2013-05-02 14:43:37.0 +0200 +++ gcc-msp430-4.6.3~mspgcc-20120406/debian/changelog 2013-05-06 00:07:07.0 +0200 @@ -1,3 +1,10 @@ +gcc-msp430 (4.6.3~mspgcc-20120406-3+deb7u2) stable; urgency=high + + * Fix generation of wrong interrupt table for MSP430FR5xxx +targets, resulting in security fuse blown (Closes: #706482) + + -- Luca Bruno lu...@debian.org Sun, 05 May 2013 23:56:24 +0200 + gcc-msp430 (4.6.3~mspgcc-20120406-3+deb7u1) testing; urgency=high * Change package description to mention the incompatibility diff -Nru gcc-msp430-4.6.3~mspgcc-20120406/debian/control gcc-msp430-4.6.3~mspgcc-20120406/debian/control --- gcc-msp430-4.6.3~mspgcc-20120406/debian/control 2013-05-02 10:10:13.0 +0200 +++ gcc-msp430-4.6.3~mspgcc-20120406/debian/control 2013-05-06 00:05:38.0 +0200 @@ -20,8 +20,3 @@ This is the GNU C compiler, a fairly portable optimizing compiler for C for TI's MSP430 architecture. This package is primarily for MSP430 developers and cross-compilers and is not needed by normal users. - . - BEWARE: due to a bug in the memory layout reference of FRAM-based chips, - this package DOES NOT WORK with MSP430FR5xxx chips (eg. FraunchPad devkit). - DO NOT use gcc-msp430 on that chip series, as you will lose access to - JTAG and BSL, and permanently BRICK your chip! diff -Nru gcc-msp430-4.6.3~mspgcc-20120406/debian/lts-patch/fram-fuse-blown.diff gcc-msp430-4.6.3~mspgcc-20120406/debian/lts-patch/fram-fuse-blown.diff --- gcc-msp430-4.6.3~mspgcc-20120406/debian/lts-patch/fram-fuse-blown.diff 1970-01-01 01:00:00.0 +0100 +++ gcc-msp430-4.6.3~mspgcc-20120406/debian/lts-patch/fram-fuse-blown.diff 2013-05-05 23:55:35.0 +0200 @@ -0,0 +1,80 @@ +From 0594213396817815f584efe3257987e704b4f187 Mon Sep 17 00:00:00 2001 +From: Peter A. Bigot pabi...@users.sourceforge.net +Date: Thu, 12 Jul 2012 14:32:16 -0500 +Subject: [PATCH] SF 3540953 fram applications overwrite bsl/jtag passwords + +No MSP430 chip has more than 25 valid interrupts, and they are assigned from +the top down. The FRAM chips use lower words in the interrupt vector to +hold BSL and JTAG passwords, and having real addresses in those locations +has been shown to result in problems accessing BSL and JTAG. Leave the low +32 words erased; this matches as-delivered MSP430FR5739 content for those +addresses. +--- + gcc/config/msp430/crt0ivtbl.S | 44 - + 1 files changed, 42 insertions(+), 2 deletions(-) + +diff --git gcc-4.6.3.orig/gcc/config/msp430/crt0ivtbl.S gcc-4.6.3/gcc/config/msp430/crt0ivtbl.S +index 46bc0c1..68dff23 100644 +--- gcc-4.6.3.orig/gcc/config/msp430/crt0ivtbl.S gcc-4.6.3/gcc/config/msp430/crt0ivtbl.S +@@ -36,6 +36,7 @@ __br_unexpected_: + + DEFINE_IVTABLE INTERRUPT_VECTOR_COUNT + ++#if 32 = INTERRUPT_VECTOR_COUNT + INITIALIZE_ISR_SLOT 0 + INITIALIZE_ISR_SLOT 1 + INITIALIZE_ISR_SLOT 2 +@@ -69,8 +70,47 @@ DEFINE_IVTABLE INTERRUPT_VECTOR_COUNT + INITIALIZE_ISR_SLOT 29 + INITIALIZE_ISR_SLOT 30 + #endif /* 16 INTERRUPT_VECTOR_COUNT */ +-#if 32 INTERRUPT_VECTOR_COUNT +- INITIALIZE_ISR_SLOT 31 ++#else /* 32 = INTERRUPT_VECTOR_COUNT */ ++/* SF 3540953 fram applications overwrite bsl/jtag passwords ++ * ++ * No MSP430 chip has more than 25 valid interrupts, and they are assigned from ++ * the top down. The FRAM chips use lower words in the interrupt vector to ++ * hold BSL and JTAG passwords, and having real addresses in those locations ++ * has been shown to result in problems accessing BSL and JTAG. Leave the low ++ * 32 words erased; this matches as-delivered MSP430FR5739 content
Proposed ksplice 0.9.9-3, fixing #606282
Hi Release Team, I've a pending upload of ksplice to fix #606282. While working on this, Timo found out that we'd better integrate a couple of minor patches from upstream in order to ensure compatibility with our 2.6.32 stock kernel and definitely make ksplice a good release candidate (ie. it's almost useless w/o them). Attached is the complete debdiff with the proposed fixes. I'd personally go for this, and all the patches have been already accepted upstream, but I'd like to receive an explicit ack from you before proceeding. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer ksplice.debdiff Description: Binary data signature.asc Description: PGP signature
Please unblock istanbul 0.2.2-8
Hi, istanbul/0.2.2-8 fixes two RC bugs and had already aged in sid without further reports, please unblock it. debdiff attached. istanbul (0.2.2-8) unstable; urgency=medium * Remove GStreamer alsa explicit audiosource, not available on kfreebsd-* (Closes: #591739) * Avoid overwriting directories when saving screencast (Closes: #592258) -- Luca Bruno lu...@debian.org Tue, 17 Aug 2010 11:39:08 +0200 -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer istanbul_0.2.2-8.debdiff Description: Binary data pgpupYjqaoavn.pgp Description: PGP signature
Re: Decoupling GNOME 2.30 transitions
Josselin Mouette scrisse: *I urge anyone maintaining packages in the following lists to not upload these packages to unstable without double-checking with the release team and/or the GNOME team.* 2 - gnome-desktop (libgnome-desktop-2-11 → libgnome-desktop-2-17) Binary NMUs: avant-window-navigator awn-extras-applets awn will soon see a major release, but before that I have to get an ancillary lib through NEW. As that one too is entangled with libgnome-desktop and given the current ftp-master breakage, I will wait till this transition of yours is completed. Please send me an explicit 'go' when doable, or otherwise correct me if there's something wrong here. Cheers, Luca P.S. please CC: me when replying, I'm not actively reading -release -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpyUupyppOZw.pgp Description: PGP signature
Re: Unblock (or better solutions) for ksplice ( 0.8.7)
Marc 'HE' Brockschmidt scrisse: Luca Bruno [EMAIL PROTECTED] writes: So I'm asking what you suggest to do: - unblock 0.9.0-1 for lenny as is - upload the new 0.9.1-1 to sid and then unblock it for lenny I think it's too late for both of these options. Sorry, but accepting a few thousand new lines of code just a few weeks before the release is not really how Debian releases work. I know, this was basically an unfortunate timing, my bad. Given that there isn't a solution, and the status quo is not safe, the only conclusion is to not release with 0.8.7-1. Should I explicitely request a removal of 0.8.7-1 from Lenny or are you already taking care of this aspect? Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpWBlrTayuCp.pgp Description: PGP signature
Re: Unblock (or better solutions) for ksplice ( 0.8.7)
Adeodato Simó scrisse: * Marc 'HE' Brockschmidt [Tue, 14 Oct 2008 22:11:18 +0200]: - upload 0.9.0-1lenny0 to t-p-u with the backported offset patch Could you give a rough estimate how big this patch would be? AFAICT, this option was about accepting 0.9.0 in its entirety, plus a cherry-picked patch from 0.9.1. Yes that's what I meant, and the cherry-pick is a single line. Instead the 0.8.7 - 0.9.0 diff is much bigger: 57 files changed, 15261 insertions(+), 2707 deletions(-) (even if it includes lots of code moving, renaming and refactoring) Ciao, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpcVh5K59j7r.pgp Description: PGP signature
Unblock (or better solutions) for ksplice ( 0.8.7)
Hi, sorry if this mail comes a bit late in the release cycle, but I've recently got a mail exchange with ksplice upstream, and our actual situation isn't optimal. Basically ksplice 0.8.7 pre-dates 2.6.26 kernel and has various serious safety issues which can crash the whole kernel: - race conditions at module unloading - off-by-one bugs can lead to applying patches when it is unsafe - no dependency enforcements, user actions can panic ksplice mechanism Upstream agree with me that ksplice 0.8.7-1 shouldn't be released with Lenny. In the meantime, 0.9.0-1 fixes all of those and has been in unstable already for more than two weeks without bugs, so if you are confident with a complete new upstream release it should be ok. Upstream already released 0.9.1, which isn't yet packaged, which contains many improvements and in particular another 1-line patch to improve offset calculations (which can be optimal to have in the final stable package). So I'm asking what you suggest to do: - unblock 0.9.0-1 for lenny as is - upload 0.9.0-1lenny0 to t-p-u with the backported offset patch - upload the new 0.9.1-1 to sid and then unblock it for lenny - remove 0.8.7-1 and release without ksplice (really, not good) In any way a new upstream package should be targeted for lenny. Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpr1gydMoi5P.pgp Description: PGP signature
Re: Please allow ext3grep in lenny (freeze unblock or via t-p-u)
Luca Bruno scrisse: Hi, currently ext3grep isn't part of lenny, mainly because of bad timing between me and the other co-maintainer; it was also blocked by RC bug #491621. I hope you would allow ext3grep in lenny, as it will be quite a loss if we release without it. Please let me know how to proceed now. This is now a week without any reply from the release-team. I know you're actually quite overloaded, but having read latest Release Update I'd like to hear suggestions from the team now (if I'm still in time). Cheers, Luca -- .''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso) : :' : The Universal O.S.| lucab (AT) debian.org `. `'` | GPG Key ID: 3BFB9FB3 `- http://www.debian.org | Debian GNU/Linux Developer pgpWQgqVC73mc.pgp Description: PGP signature
Please allow ext3grep in lenny (freeze unblock or via t-p-u)
Hi,
currently ext3grep isn't part of lenny, mainly because of bad timing
between me and the other co-maintainer; it was also blocked by RC bug
#491621.
Version 0.8.0-1 has now been in sid for almost two weeks without a bug,
so I'm primarily asking here if the release team would concede a freeze
unblock for it. I'm anyway aware that the team rightly doesn't like
unblock for new upstream version, so I have already backported the fix
for #491621 in a t-p-u revision (0.6.0-1+lenny1, whose debdiff to
0.6.0-1 is attached here) as a fallback option to have it in lenny.
Patch was picked from upstream svn, it only contains inode_size
adjustments and due changes to related groups/blocks management.
I'm anyway more confident with 0.8.0-1, as it fixed a bunch of other
possible issues, and is mainly the sane evolution of initial ext3grep
draft into a more mature project.
Both changelog mention BE-arch drop, but this non-issue has already been
sorted out as per #495880.
I hope you would allow ext3grep in lenny, as it will be quite a loss if
we release without it.
Please let me know how to proceed now.
Ciao, Luca
--
.''`. ** Debian GNU/Linux ** | Luca Bruno (kaeso)
: :' : The Universal O.S.| lucab (AT) debian.org
`. `'` | GPG Key ID: 3BFB9FB3
`- http://www.debian.org | Debian GNU/Linux Developer
diff -u ext3grep-0.6.0/debian/changelog ext3grep-0.6.0/debian/changelog
--- ext3grep-0.6.0/debian/changelog
+++ ext3grep-0.6.0/debian/changelog
@@ -1,3 +1,12 @@
+ext3grep (0.6.0-1+lenny1) testing-proposed-updates; urgency=medium
+
+ * Allow inode_size_ to be larger than sizeof(Inode) (backported from
+upstream SVN r97, closes: #491621)
+ * Removed all big-endian arch, as ext3grep won't work there
+ * Urgency medium, fixes RC bug.
+
+ -- Luca Bruno [EMAIL PROTECTED] Wed, 27 Aug 2008 13:29:49 +0200
+
ext3grep (0.6.0-1) unstable; urgency=low
* Initial release (Closes: #470813)
diff -u ext3grep-0.6.0/debian/rules ext3grep-0.6.0/debian/rules
--- ext3grep-0.6.0/debian/rules
+++ ext3grep-0.6.0/debian/rules
@@ -3,6 +3,8 @@
# richer debug information.
# DEB_BUILD_OPTIONS += nostrip noopt
+include /usr/share/quilt/quilt.make
+
DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
@@ -16,7 +18,7 @@
EXTRA += --enable-debug --disable-optimization
endif
-clean:
+clean: unpatch
dh_testdir
dh_testroot
rm -f build-stamp
@@ -25,7 +27,7 @@
dh_clean
-config.status: configure
+config.status: patch configure
dh_testdir
ifneq $(wildcard /usr/share/misc/config.sub)
diff -u ext3grep-0.6.0/debian/control ext3grep-0.6.0/debian/control
--- ext3grep-0.6.0/debian/control
+++ ext3grep-0.6.0/debian/control
@@ -3,14 +3,14 @@
Priority: extra
Maintainer: Debian Forensics [EMAIL PROTECTED]
Uploaders: Luca Bruno [EMAIL PROTECTED], Rich Ercolani [EMAIL PROTECTED]
-Build-Depends: debhelper (= 7), autotools-dev, e2fslibs-dev, libncurses5 | libncurses-dev, pkg-config
+Build-Depends: debhelper (= 7), autotools-dev, e2fslibs-dev, libncurses5 | libncurses-dev, pkg-config, quilt
Standards-Version: 3.8.0
Homepage: http://code.google.com/p/ext3grep/
Vcs-Browser: http://git.debian.org/?p=forensics/ext3grep.git
Vcs-Git: git://git.debian.org/git/forensics/ext3grep.git
Package: ext3grep
-Architecture: any
+Architecture: alpha amd64 arm armel i386 ia64 mipsel
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Tool to help recover deleted files on ext3 filesystems
ext3grep is a simple tool intended to aid anyone who accidentally deletes a
only in patch2:
unchanged:
--- ext3grep-0.6.0.orig/debian/patches/series
+++ ext3grep-0.6.0/debian/patches/series
@@ -0,0 +1 @@
+inode_size.diff
only in patch2:
unchanged:
--- ext3grep-0.6.0.orig/debian/patches/inode_size.diff
+++ ext3grep-0.6.0/debian/patches/inode_size.diff
@@ -0,0 +1,231 @@
+--- ext3grep.orig/src/ext3grep.cc 2008-08-27 13:12:31.0 +0200
ext3grep/src/ext3grep.cc 2008-08-27 13:24:20.0 +0200
+@@ -367,10 +367,14 @@ void init_consts()
+ assert(block_size_ == fragment_size(super_block));
+ // The inode bitmap has to fit in a single block.
+ assert(inodes_per_group(super_block) = 8 * block_size_);
+- // inode_size is expected to be (at least) 128.
+- assert(inode_size_ = 128);
+- // But theoretically sizeof(Inode) can be more (not at the moment).
+- assert((size_t)inode_size_ = sizeof(Inode));
++ // The rest of the code assumes that sizeof(Inode) is a power of 2.
++ assert(sizeof(Inode) == 128);
++ // inode_size is expected to be (at least) the size of Inode.
++ assert(inode_size_ = sizeof(Inode));
++ // Each inode must fit within one block.
++ assert(inode_size_ = block_size_);
++ // inode_size must be a power of 2.
++ assert(!((inode_size_ - 1) inode_size_));
+ // There should fit exactly an integer number of inodes in one block.
+ assert((block_size_ / inode_size_) * inode_size_ == block_size_
