Bug#868355: nmu: ceres-solver_1.12.0+dfsg0-1+b3
Hi all, well, I would prefer to rebuild all reverse dependencies after each new eigen3 (and probably any other header-only lib) upload [1] and be ready to request it. But it looks like it is not a common case to do such BinNMUs. [1] https://bugs.debian.org/845819 Regards Anton 2017-07-19 8:35 GMT+02:00 Philipp Huebner : > Hi, > > until I find the time to package the new release of Ceres Solver, > please go ahead with the BinNMU. > > With Eigen3 being a header-only library and numeric math libraries > making use of derivatives and templating like crazy, I believe this > strict Eigen3 check to be well reasoned. > > I'll ask upstream about this, but expect them to confirm it. > > > Regards, > -- > .''`. Philipp Huebner > : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F > `. `'` > `- >
Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 07/06/2017 11:13 PM, Paul Wise wrote: > On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: > >> For what it's worth, my opinion is that we should attempt to synchronize >> certdata.txt (and blacklist.txt, for that matter) across all suites (but >> not other changes to the packaging). This would remove another decision >> point in our infrastructure and ensure harmonious X509 processing across >> suites. > > I would like to see that happen too. I spent a few sessions over the past few days getting the mozilla bundle 2.14 committed to all the suite branches wheezy and newer. I have some more verification to work on and I'll get some packages rolled up and tested for all the suites. I appreciate the notes here! -- Kind regards, Michael
Bug#867461: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
On 2017-07-19 11:35:56, Michael Shuler wrote: > On 07/06/2017 11:13 PM, Paul Wise wrote: >> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote: >> >>> For what it's worth, my opinion is that we should attempt to synchronize >>> certdata.txt (and blacklist.txt, for that matter) across all suites (but >>> not other changes to the packaging). This would remove another decision >>> point in our infrastructure and ensure harmonious X509 processing across >>> suites. >> >> I would like to see that happen too. > > I spent a few sessions over the past few days getting the mozilla bundle > 2.14 committed to all the suite branches wheezy and newer. I have some > more verification to work on and I'll get some packages rolled up and > tested for all the suites. > > I appreciate the notes here! Thanks! let us know if you need help with the LTS bits. a. -- On reconnait la grandeur et la valeur d'une nation à la façon dont celle-ci traite ses animaux. - Mahatma Gandhi
Processed: Re: Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
Processing control commands: > tags -1 - moreinfo Bug #867814 [release.debian.org] stretch-pu: package ncurses/6.0+20161126-1+deb9u1 Removed tag(s) moreinfo. -- 867814: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867814 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#867814: stretch-pu: package ncurses/6.0+20161126-1+deb9u1
Control: tags -1 - moreinfo
On 2017-07-15 12:50 +0200, Sven Joachim wrote:
> Control: tags -1 - confirmed
> Control: tags -1 + moreinfo
>
> On 2017-07-15 11:04 +0100, Adam D. Barratt wrote:
>
>> Control: tags -1 + confirmed d-i
>>
>> On Sun, 2017-07-09 at 19:30 +0200, Sven Joachim wrote:
>>> Recently a few flaws in the tic program and the tic library have been
>>> detected: null pointer dereference, buffer overflow, stack smashing, you
>>> name it. Six bugs have been reported in the Red Hat bugtracker and four
>>> CVEs assigned. Fortunately there are rather few users who would run
>>> affected programs at all, so it was decided that no DSA would be
>>> necessary.
>
> Unfortunately the fixes have caused a regression in infocmp, see
> #868266. I expect an upstream fix this night, but to properly test it
> and prepare new packages taking a bit more time seems advisable. So I
> guess we'll have to defer that for 9.2.
The changes from the 20170715 patchlevel were a bit larger than I would
have liked, but applied with minimal tweaking to the stretch version.
Running "infocmp -C" on all the terminfo files in ncurses-{base,term}
showed no difference compared to the infocmp version currently in
stretch.
>> I'd be okay with this, but it will need a kibi-ack due to the udeb.
>
> The changes do not touch the tinfo library which is all that shipped in
> the udeb.
To elaborate on that, ncurses/tinfo/{alloc,parse}_entry.c are compiled
into the tic library while progs/dump_entry.c is for the infocmp and tic
programs. Building 6.0+20161126-1 and 6.0+20161126-1+deb9u1 in a
stretch chroot produced identical libtinfo.so.5.9 files.
Cheers,
Sven
--- ncurses-6.0+20161126/debian/changelog 2016-11-29 21:19:08.0 +0100
+++ ncurses-6.0+20161126/debian/changelog 2017-07-17 20:47:58.0 +0200
@@ -1,3 +1,13 @@
+ncurses (6.0+20161126-1+deb9u1) stretch; urgency=medium
+
+ * Cherry-pick upstream fixes from the 20170701 and 20170708 patchlevels
+for various crash bugs in the tic library and the tic binary
+(CVE-2017-10684, CVE-2017-10685, CVE-2017-2, CVE-2017-3).
+ * Backport termcap-format fix from the 20170715 patchlevel, repairing a
+regression from the above security fixes (see #868266).
+
+ -- Sven Joachim Mon, 17 Jul 2017 20:47:58 +0200
+
ncurses (6.0+20161126-1) unstable; urgency=low
* New upstream patchlevel.
diff -Nru ncurses-6.0+20161126/debian/patches/cve-fixes.diff ncurses-6.0+20161126/debian/patches/cve-fixes.diff
--- ncurses-6.0+20161126/debian/patches/cve-fixes.diff 1970-01-01 01:00:00.0 +0100
+++ ncurses-6.0+20161126/debian/patches/cve-fixes.diff 2017-07-17 20:47:58.0 +0200
@@ -0,0 +1,185 @@
+Author: Sven Joachim
+Description: Fixes for four CVEs
+ Fixes for CVE 2017-10684, CVE-2017-10685, CVE-2017-2,
+ CVE-2017-3 cherry-picked from upstream patchlevels 20170701 and
+ 20170708.
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464684
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464685
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464686
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464687
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464691
+Bug-RedHat: https://bugzilla.redhat.com/show_bug.cgi?id=1464692
+Forwarded: not-needed
+Last-Update: 2017-07-09
+
+---
+ ncurses/tinfo/alloc_entry.c |6 +-
+ ncurses/tinfo/parse_entry.c | 22 --
+ progs/dump_entry.c | 34 +-
+ 3 files changed, 38 insertions(+), 24 deletions(-)
+
+--- a/ncurses/tinfo/alloc_entry.c
b/ncurses/tinfo/alloc_entry.c
+@@ -96,7 +96,11 @@ _nc_save_str(const char *const string)
+ {
+ char *result = 0;
+ size_t old_next_free = next_free;
+-size_t len = strlen(string) + 1;
++size_t len;
++
++if (string == 0)
++ return _nc_save_str("");
++len = strlen(string) + 1;
+
+ if (len == 1 && next_free != 0) {
+ /*
+--- a/ncurses/tinfo/parse_entry.c
b/ncurses/tinfo/parse_entry.c
+@@ -236,13 +236,14 @@ _nc_parse_entry(struct entry *entryp, in
+ * implemented it. Note that the resulting terminal type was never the
+ * 2-character name, but was instead the first alias after that.
+ */
++#define ok_TC2(s) (isgraph(UChar(s)) && (s) != '|')
+ ptr = _nc_curr_token.tk_name;
+ if (_nc_syntax == SYN_TERMCAP
+ #if NCURSES_XNAMES
+ && !_nc_user_definable
+ #endif
+ ) {
+- if (ptr[2] == '|') {
++ if (ok_TC2(ptr[0]) && ok_TC2(ptr[1]) && (ptr[2] == '|')) {
+ ptr += 3;
+ _nc_curr_token.tk_name[2] = '\0';
+ }
+@@ -284,9 +285,11 @@ _nc_parse_entry(struct entry *entryp, in
+ if (is_use || is_tc) {
+ entryp->uses[entryp->nuses].name = _nc_save_str(_nc_curr_token.tk_valstring);
+ entryp->uses[entryp->nuses].line = _nc_curr_line;
+- entryp->nuses++;
+- if (entryp->nuses > 1 && is_tc) {
+- BAD_TC_USAGE
++ if (VALID_STRING(entryp->uses[entryp->nuses].name)) {
++ entryp->nuses++;
++ if (en
Bug#866389: transition: perl 5.26
On Fri, 14 Jul 2017 22:52:49 +0300, Niko Tyni wrote: > On Fri, Jul 14, 2017 at 10:50:16AM +0200, Emilio Pozuelo Monfort wrote: > > > > Thanks. Please go ahead and bump them to severity:serious as we are close to > > doing this. > > Thanks, done. Update re blocking bugs: In a couple of hours the last 4 NMUs will leave DELAYED. The remaining buggy packages, already targetted for auto-removal, then are: #826473: kdesrc-build: no rdepends, can be removed from testing (or maybe even from the archive, according to the bug log). #867213: syslog-ng-incubator: one rdep (syslog-ng). No reaction on the bug report, unrelated build failure; I guess syslog-ng* can be removed from testing if noone fixes the problem in time. So I think from the point of view of blockers we are basically ready. Cheers, gregor -- .''`. https://info.comodo.priv.at/ - Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#868722: transition: notmuch
Emilio Pozuelo Monfort writes: > > Up to you what happens with notmuch-addrlookup, as long as it gets fixed. With > that said, you can go ahead. > I have uploaded an NMU of notmuch-addrlookup to delayed/5
Bug#866389: transition: perl 5.26
On Thu, Jul 20, 2017 at 5:04 AM, gregor herrmann wrote: > #867213: syslog-ng-incubator: one rdep (syslog-ng). No reaction on > the bug report, unrelated build failure; I guess syslog-ng* > can be removed from testing if noone fixes the problem in > time. I'd like to point out that DSA relies on syslog-ng on debian.org hosts, so it would be appreciated if the issues could be fixed or worked around rather than removing syslog-ng from buster. Of course buster is not in use on any debian.org hosts yet. -- bye, pabs https://wiki.debian.org/PaulWise
