Package: release.debian.org
Dear Release Managers,
Version 0.8.0 of libcpuid supports arm/arm64 and I've uploaded a
version that includes those architectures, first to experimental to
check that it all went okay, then to unstable. I've also built cpu-x
5.3.1, which requires the libcpuid 0.8.0+, a
Thanks!
I guess preparing these is pretty straightforward.
Would like to think my efforts to keep debian/rules etc clean and tidy
made this work so easily.
Given that the patch is nothing but a changelog entry, I'm assuming
it's not really worth making a branch on fossil.
" * Backport to bookworm
address a number of crashes and security issues, including
+CVE-2021-3500 (closes: #988215)
+
+ -- Barak A. Pearlmutter Mon, 10 May 2021 18:56:59 +0100
+
djvulibre (3.5.28-1) unstable; urgency=medium
[ Leon Bottou ]
diff -Nru djvulibre-3.5.28/debian/control djvulibre-3.5.28/debian
r 13
+ * Fix day-of-week for changelog entry 0.pre3.4-1
+ * Add pithy comment to debian/watch
+ * stop quoting %s in mimecap entry (closes: #987415)
+
+ -- Barak A. Pearlmutter Fri, 23 Apr 2021 20:56:40 +0100
+
stopmotion (0.8.5-2) unstable; urgency=medium
* hack around integer size misma
.16.2/debian/changelog 2021-03-25 21:55:13.0 +
+++ ensmallen-2.16.2/debian/changelog 2021-04-16 16:49:42.0 +0100
@@ -1,3 +1,9 @@
+ensmallen (2.16.2-2) unstable; urgency=medium
+
+ * add autopkgtest support
+
+ -- Barak A. Pearlmutter Fri, 16 Apr 2021 16:49:42 +0100
+
ensm
Holy mother of complexity! They don't make autopkgtest easy to
understand, do they? And no virtual driver for pbuilder/cowdancer,
just to put an extra nail in my wrist (if I may use a seasonal
metaphor.)
Anyway, I believe the upload I've just pushed has correct autopkgtest
support, explicitly test
edium
+
+ * Address security issue: do not quote %s in mailcap entry (closes: #985594)
+
+ -- Barak A. Pearlmutter Sat, 20 Mar 2021 17:13:44 +
+
docx2txt (1.4-4) unstable; urgency=medium
* debian/rules does not require root
diff -Nru docx2txt-1.4/debian/docx2txt.mime docx2txt-1.4/d
> if the source has such an extensive test suite, doesn't that (at
least partially) qualify for autopkgtesting? Remember that packages that
have substantial testing with autopkgtest *of the installed binaries*
currently don't need to request unblocks if their not a key package.
I think so, yes. It
I was preparing one, but upstream released an official 2.15 release.
Which has an exhaustive test suite enabled in the build and passes (by
upstream standards; there are scary messages but they're expected) on
all architectures.
The delta is too big to sensibly check. But it's a proper release wit
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package fossil
[ Reason ]
Marked for autoremoval due to #985124.
The issue was fixed upstream. Given the nature of the package, I think
tracking their release candidate is
s: #985594)
+
+ -- Barak A. Pearlmutter Sat, 20 Mar 2021 17:13:44 +
+
docx2txt (1.4-4) unstable; urgency=medium
* debian/rules does not require root
diff -Nru docx2txt-1.4/debian/docx2txt.mime docx2txt-1.4/debian/docx2txt.mime
--- docx2txt-1.4/debian/docx2txt.mime 2020-12-11 21:55:16.0
Cool, thanks.
Is there a way for me to tell the autobuilder to automatically rebuild
ivtools once the rebuilt libace-dev is available?
(Really what we should do is autobuild-to-fixedpoint the entire
archive: rebuild all packages automatically until everything settles
down, and incrementally updat
Well, vala-mode-el 0.1-2 was uploaded and in unstable on 5-Nov-2014, so
this version has had some shaking down. No issues have been noted. I
let it rest a bit before marking the bug as done, even though I was
pretty sure it was fixed, because I wanted to be positive there weren't
any latent probl
e-debian-patch for in-tree rather than quilt patch
+ * Bump debian standards version (no changes required)
+ * Update upstream location
+ * Fix grammar in comment in source code
+ * Add support to use C# semantics when ECB and CEDIT are both installed
+
+ -- Barak A. Pearlmutter Wed, 05 Nov
rather than quilt patch
* Bump debian standards version (no changes required)
* Update upstream location
* Fix grammar in comment in source code
* Add support to use C# semantics when ECB and CEDIT are both installed
-- Barak A. Pearlmutter Wed, 05 Nov 2014 11:07:16
I've uploaded qhull (2012.1-4) which has a convenience link for
/usr/include/qhull/qhull.h, this should solve the issue with meshlab
(#738751) and perhaps the rest...
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
The qhull library was upgraded from 2009.1 to 2012.1, fixing a number
of bugs. Upstream bumped the SO from 5 to 6, for good reason, so all
the packages that use it need to be rebuilt. (
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu djview4_4.9-3 . ALL . -m "unify libtiff dependency, thanks to Harald Jenny
for noting the issue"
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of
> That second change looks wrong to me. (For the avoidance of doubt, the
> "=".)
Yeah, it is a bogus =. Can't believe it was missed.
In any case, these two #define's (NS_IN6ADDRSZ and NS_INT16SZ) are
shadowed by others, so that code is dead and they can be removed.
eeze, squeeze)
Author: Barak A. Pearlmutter
Date: Mon Jan 14 14:15:23 2013 +
patch for CVE-2013-0722
diff --git a/debian/changelog b/debian/changelog
index d725cc0..a9e76e8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+ettercap (1:0.7.3-2.1+squeeze1) stable;
Oops.
Dear Release team,
Please consider for the next point release this tiny patch to ettercap
addressing CVE-2013-0722.
--Barak.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact list
> I'm not aware of any security issues in Ettercap and the release
> announcement of 0.7.5 doesn't mention them either.
> The 0.7.4 release mentions several buffer overflows, but this version
> is already in testing.
Well, that depends on *which* 0.7.4 you mean, NG-0.7.4 vs v0.7.4, but in
any cas
> Do you have CVE numbers, BTS references or any further detail?
No, I don't believe any such processes were engaged. But examination of
the actual changes shows many potentially security-relevant deltas. The
tool is most commonly used in "friendly" networks to look for
vulnerabilities, so this
As I've stated previously, I don't believe that backporting fixes is
really feasible. There are too many, they are mixed with
non-security-related modifications, there would be enormous opportunity
for error, and ongoing security maintenance would be quite difficult.
Some background: upstream deve
That is a matter of release policy.
I believe I've made clear my own recommended action, listed the
alternative possibilities I consider realistic, and given supporting
reasoning. After that, this becomes a matter for the release team to
decide. They can take my recommendation, or do something e
7;t mind. Hint Hint.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscri
Good idea. Will add this info to the bug report.
Technically there are two bugs. 692623 is for the CSON "not evil" files
being derived files rather than truly original source, while 692624 is
for the "not evil" license itself. The latter is already tagged
wheezy-ignore, while the former is caus
/root/.gnupg/*
The problem was that the emacsen install-time byte compilation process
created this debris. The fix is a workaround causing the debris to be
created in a temporary directory where it can be safely deleted.
--Barak.
--
Barak A. Pearlmutter
> > # #692623
> > remove fossil/1:1.22.1-1
> This is worrying because fossil is the vcs used by sqlite upstream.
> It looks like fixing this would involve Packaging "cson" too. The
> alternative of dumping cson into the fossil source tree is probably
> not ideal.
> Barak, have you looked at thi
y improves security, and certainly makes the package more
auditable. But, they do not really change the generated binaries
(except for moving library files to multiarch dirs.)
--Barak.
--
Barak A. Pearlmutter
http://www.bcl.hamilton.ie/~barak/
--
To U
attention.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact lis
.
On the other hand, with 0.7.5 we have an active (quite pro-active in
fact) and highly responsive upstream team eager to fix any issues that
we might bring to their attention.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynoo
Sorry; I assumed no word meant no objections and I should go ahead.
In any case this is a simple one: copyright problem, no real changes
to the generated binaries. And I'll be happy with whatever you
decide.
--Barak.
--
To UNSUBSCRIBE, email to debian-re
I'd like to upload a tweaked adolc for the next stable update.
There are no changes to the binaries, but the source tarball
in stable contains non-free files.
See http://bugs.debian.org/641489 for details, and for the packaged
fix (in git) which is identical to the version in testing except that
t
could be "backported" to
generate a new version for testing, but that seems silly to me.)
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
To UNSU
I've thought about it, and I'm okay w/ removing oaklisp from squeeze.
As you say, it has a low popcount.
(The version I recently uploaded does build on amd64, and has no
changes to the actual executable generated aside from GCC switches, as
can be seen from looking at the src/ subdir. But it does
Thanks!
(In fact I'm already prepping a fix which includes your patch along
with a AMD64 FTBS fix, albeit a 32-bit one.)
--Barak.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listma
> ... unblocked ...
Thanks! (Especially so quickly, under the late circumstances, with a
non-leaf solib package.)
Your other points are noted: will check up on them, and get back
off-list since they are not release related.
--Barak.
--
To UNSUBSCRIBE,
Per req, pushed up v -3 in the old source format.
Might help a little, but there are still a lot of false positive
changes listed in the diff due to differential CVS keyword expansion.
This is the horror of CVS keywords I guess.
They're in the upstream tarball, so I can't get rid of the issue by
j
> ... I'm not very happy about the change to new source package
> format, ... Could you undo that?
Sure: I'm revert the switch to quilt format and will upload the
resulting package version -3 shortly. The only difference from -2 is
a changelog entry and the removal of debian/source/format.
Plea
Two minor addenda:
(1) typo in the 1st line above: should read 3.5.23-2, as in the diffs.
(2) there are some non-automated non-refresh changes in the autotools,
all in file configure.ac. Show here, with very short snippets of the
diff.
define the path the rsvg,
+AC_PATH_PROG(RSVG, rsvg, fal
t way exceed the odds of their
being a problem lurking in the very tiny number of substantive
non-critical changes.
A broken-down diffstat with comments appears below.
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co
True, the actual diff is tiny.
Both versions in question do not use the embedded sqlite, and instead
dynamic link with the system libsqlite3.
--Barak.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
Well, certainly I do understand the policy as written. I suppose I
was assuming that it would be applied with a great deal of discretion
early in the freeze, and become more stringent as time went on.
I suppose I do not agree that such an extremely binary policy, phased
in so abruptly, is optimal
Okay, so be it.
But I'm going to go ahead and make the case for letting it in though
anyway. Not just for fossil, but as a general comment which likely
will apply to other packages, and food for thought for the release
team.
I don't see any technical point to holding fossil back. It is a leaf
p
only went into unstable a few days ago due to a few
sqlite showstopper bugs that were only just fixed.)
--Barak.
--
Barak A. Pearlmutter
Hamilton Institute & Dept Comp Sci, NUI Maynooth, Co. Kildare, Ireland
http://www.bcl.hamilton.ie/~barak/
--
(flames ignored)
You can do a minimal lenny update if you want, I won't stop you.
But there is a good reason to split the library into the textual
support files vs code: it allows different versions of the library to
co-exist, e.g., libdjvulibre15 and libdjvulibre21. Which may not be
so useful f
/wiki.debian.org/ArchitectureSpecificsMemo in debian/control
architecture field (closes: #495828)
-- Barak A. Pearlmutter <[EMAIL PROTECTED]> Wed, 20 Aug 2008 20:46:54 +0100
raidutils (0.0.6-7) unstable; urgency=low
* do not ignore clean error in debian/rules (lintian)
*
Please allow djvulibre-3.5 3.5.20-10 into lenny.
Explanation:
Previous versions had minor dependency issues that caused an attempt
to do a minimal (no-graphics, server) installation that included image
processing tools that used the DjVu library to pull in substantial
hunks of X. So this fix ma
49 matches
Mail list logo
