On 2020-01-07 Brian Wengel wrote:
> But I would expect "AUTH_SERVER_ALLOW_NOTLS_PASSWORDS = False" would disable
> it.
> What I'm trying to say is that whatever value you insert after the "=" is
> ignored.
I see.
That is unlikely to change. We use
.ifndef
which is true when a macro is defined
On 2020-01-03 Paul Gevers wrote:
> On 31-12-2019 18:26, Andreas Metzler wrote:
[...]
> > Afaict the involved packages should propagate to testing in 3 days, when
> > enblend-enfuse is old enough. I have commited the fix. [1]
> Unfortunately libvigraimpex is (hopefully only te
Control: owner -1 ametz...@debian.org
Control: retitle -1 ITA: libvigraimpex -- C++ computer vision library
On 2019-12-30 Andreas Metzler wrote:
[...]
> I intend to keep this in shape to the best I can do with QA uploads. I
> will not properly adopt since my C++ foo is weak.
Since Daniel
On 2019-12-31 Sebastiaan Couwenberg wrote:
> On 12/31/19 4:20 PM, Andreas Metzler wrote:
>> as Bas correctly diagnoses I am not currently building for all supported
>> versions but only for the default one because it is not trivial but
>> requires some work. Looking at pytho
On 2019-12-31 Sebastiaan Couwenberg wrote:
> On 12/30/19 9:48 PM, Paul Gevers wrote:
[...]
>> libvigraimpex is also part of the pseudo python3.8 transition [1], but
>> it is still red. This probably means that you are not correctly building
>> Python3 modules for all supported Python3 versions. Ca
On 2019-11-21 Daniel Stender wrote:
> Package: wnpp
> Severity: normal
> I'm orphaning this package due to retirement.
Hello,
I intend to keep this in shape to the best I can do with QA uploads. I
will not properly adopt since my C++ foo is weak.
Repo is currently available on
https://salsa.de
On 2019-12-26 Paul Gevers wrote:
> On 25-12-2019 19:29, Andreas Metzler wrote:
>> libvigraimpex is marked for autoremoval because of the python2 removal.
>> This is fixed in experimental, the new version features a soname bump.
[...]
> Normally we don't want python 2 remo
Control: block -1 by 947365
On 2019-12-23 Andreas Metzler wrote:
[...]
> I will do a QA upload.
I have opened a request for a transition slot.
cu Andreas
signature.asc
Description: PGP signature
On 2019-12-11 Marco d'Itri wrote:
> On Dec 11, Matthias Klose wrote:
> > there is really no need for a versioned libxcrypt1-dev package.
> > Please rename that properly to libxcrypt-dev.
> Can you be more specific in why this would not be allowed?
> Currently I am not building libxcrypt2 and lib
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
Hello,
libvigraimpex is marked for autoremoval because of the python2 removal.
This is fixed in experimental, the new version features a soname bump.
this should be a small scale transit
Package: libgl-dev
Version: 1.3.0-5
Severity: serious
Hello,
libgl-dev seems to lack a dependency on libx11-dev. Rebuilding e.g.
3depict results in the following error:
/usr/include/GL/glx.h:30:10: fatal error: X11/Xlib.h: No such file or directory
30 | #include
cu Andreas
On 2019-12-22 Paolo Greppi wrote:
> Hi ! and thanks for reporting.
> I have reproduced it by building libvigraimpex from this branch:
> https://salsa.debian.org/ametzler/libvigraimpex/tree/tmp-ametzler-python3
> The error is non-fatal (the build completes successfully) but I can
> see the same g
On 2019-12-21 Andreas Metzler wrote:
> On 2019-12-21 Andreas Metzler wrote:
[...]
> > I have now made progress to a successful build. Will post a patch series
> > or merge request today or tomorrow.
> See https://salsa.debian.org/science-team/libvigraimpex/merge_requests
On 2019-12-21 Andreas Metzler wrote:
> On 2019-12-21 Andreas Metzler wrote:
> > On 2019-10-01 Andreas Tille wrote:
> > > Control: tags -1 help
> > > Hi,
> > > I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> > > managed.
>
On 2019-12-21 Andreas Metzler wrote:
> On 2019-10-01 Andreas Tille wrote:
> > Control: tags -1 help
> > Hi,
> > I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> > managed.
> Hello Andreas,
> I did not get far trying to build what is curr
@@ -1,3 +1,11 @@
+doxygen (1.8.16-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Pull fix for https://github.com/doxygen/doxygen/issues/7290 from upstream
+GIT.
+
+ -- Andreas Metzler Sat, 21 Dec 2019 10:41:35 +0100
+
doxygen (1.8.16-1) unstable; urgency=medium
[ Steve
Source: doxygen
Version: 1.8.16-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hello,
doxygen does not build anymore on sid/amd64:
-- Found ZLIB: /usr/lib/x86_64-linux-gnu/libz.so (found version "1.2.11")
-- Using Qt5
CMake Error at
On 2019-10-01 Andreas Tille wrote:
> Control: tags -1 help
> Hi,
> I tried hard to port libvigraimpex to Python3 in Git[1] and think I
> managed.
Hello Andreas,
I did not get far trying to build what is currently on salsa:
make[1]: Entering directory '/tmp/VIGRA/libvigraimpex-1.11.1'
mkdir -p
On 2019-12-16 Karl Schmidt wrote:
> Package: exim4-base
> Version: 4.92-8+deb10u3
> Severity: normal
> The use of SMTPS is rather standard these days - (thunderbird, k9
> outlook etc.. ) all support this.
> Without openSSL one can't have a smart-host transport with: driver = smtps
Hello,
>Fr
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu
nmu sa-exim_4.2.1-18 . ANY . unstable . -m "Rebuild against
exim4-localscanapi-3.1 (exim 4.93)"
Hello,
please binNMU sa-exim to make it installable again.
exim 4.93 broke the local_scan e
On 2019-12-10 積丹尼 Dan Jacobson wrote:
> We read there
>To avoid the (small) performance issue one can locally create
> No only a (small) performance issue, but a source of warnings. You need
> to mention one will get warnings without doing this step.
Will do.
>certificates. The exim-ge
On 2019-12-04 Samuel Thibault wrote:
> Control: tags -1 + patch fixed-upstream
> Hello,
> Here are the patches which were applied upstream.
Thank you!
On 2019-12-01 Paul Sonnenschein wrote:
> Source: exim4
> Severity: important
> Version: 4.93~RC5-1
> User: debian-h...@lists.debian.org
> Usertags: hurd
> X-Debbugs-CC: debian-h...@lists.debian.org
> Hello,
> exim4 fails to build from source on hurd-i386 with the message:
> > *** Sorry - operat
bid-random-padding.patch
+from 3.6.10: Fix interop problems with gnutls 2.x. Closes: #933538
+(Thanks, Hanno Stock!)
+
+ -- Andreas Metzler Sat, 30 Nov 2019 13:41:59 +0100
+
gnutls28 (3.6.7-4) unstable; urgency=medium
* Cherry-pick important bug-fixes from 3.6.8:
diff -Nru gnutl
On 2019-11-30 Felix Lechner wrote:
> Hi Andreas,
> I created the attached test case in Lintian, but I cannot get the tag
> to show using '--pedantic':
> $ frontend/lintian --pedantic
> debian/test-out/packages/tags/checks/debian/rules/permissions-775/permissions-775_1.0.dsc
> P: permissions-775
On 2019-11-30 Felix Lechner wrote:
> On Fri, Nov 29, 2019 at 9:48 PM Andreas Metzler wrote:
>> -rwxrwxr-x 0/01277 2019-07-27 17:24 debian/rules
> The check in Lintian here should perhaps use a bitwise 'and':
>
> https://salsa.debian.org/lintia
Package: lintian
Version: 2.39.0
Severity: normal
Running lintian on libtasn1-6_4.14-3.dsc I get
P: libtasn1-6 source: debian-rules-not-executable
although the file is 775:
ametzler@argenau:/tmp/TASN$ tar tvf libtasn1-6_4.14-3.debian.tar.xz | \
grep rules
-rwxrwxr-x 0/01277 2
On 2019-11-18 Sebastian Andrzej Siewior wrote:
[request for changing cipher list]
Could you please take this upstream? This is not a point where Debian
will choose different defaults than upstream.
Thanks, cu Andreas
On 2019-11-18 Kai Bojens wrote:
> Would it be possible that an Exim Maintainer could simply answer the
> question wether Exim will ever be build with SMTPUTF8 (SUPPORT_I18N,
> SUPPORT_I18N_2008) or if there are any problems preventing this?
I intend to enable it after 4.93 has been released and p
Control: tags -1 pending
On 2019-11-15 Dean Hamstead wrote:
> Package: exim4-config
> Version: 4.92-8+deb10u2~bpo9+1
> Severity: normal
> Dear Maintainer,
>
> The message regarding openspf.org in conf.d/acl/30_exim4-config_check_rcpt is
> now broken as the openspf.org domain is gone.
Thanks f
On 2019-11-09 David Kalnischkies wrote:
> On Mon, Nov 04, 2019 at 05:49:53PM +0100, Robert Senger wrote:
>> We are running several debian repositories for custom kernel and
>> patched deb packages. We use apache2 on Buster, with https enabled,
>> to serve the repos.
>>
>> This worked fine, until
Source: exim4
Version: 4.93~RC2-1
Severity: serious
One of 4.93's changes
|
| JH/32 Introduce a general tainting mechanism for values read from the
| input channel, and values derived from them. Refuse to expand any
| tainted values, to catch one form of exploit.
|
Control: severity -1 serious
Control: forwared -1 https://bugs.exim.org/show_bug.cgi?id=2465
On 2019-11-05 Benedikt Spranger wrote:
[...]
> Config snippet:
> virtual:
> driver = redirect
> domains = dsearch;/etc/mail/virtual
> data = ${lookup{$local_part}lsearch{/etc/mail/virtual/$domain}}
Source: pslib
Version: 0.4.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hello,
the latest upload did not build:
https://buildd.debian.org/status/fetch.php?pkg=pslib&arch=arm64&ver=0.4.6-1&stamp=1573122104&raw=0
dh build-arch --
On 2019-11-03 Andreas Metzler wrote:
> Package: exim4-daemon-light
> Version: 4.93~RC0-1
> Severity: serious
> Tags: ftbfs
> Justification: fails to build from source (but built successfully in the past)
> 4.93~RC0-1 and later (including 4.93~RC1-2) FTBFS on mipsel, the bin
Package: exim4-daemon-light
Version: 4.93~RC0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
4.93~RC0-1 and later (including 4.93~RC1-2) FTBFS on mipsel, the binary
is built but broken.
/path/to/exim -C /dev/null -be '${if bool{0}{ye
Control: tags -1 patch
Attached seems to work for me.
>From 1d55037aa0644b42c25f40caea708c90280ee140 Mon Sep 17 00:00:00 2001
From: Andreas Metzler
Date: Sun, 3 Nov 2019 06:45:49 +0100
Subject: [PATCH 1/2] Build with -DLOCAL_SCAN.
---
debian/changelog | 7 +++
debian/rules | 2 +-
On 2019-11-01 Andreas Metzler wrote:
[...]
> As a hotfix I plan to upload with noguile profile support [...] after
> -3 has migrated to testing.
[...]
Done yesterday.
Control: severity -1 serious
On 2019-10-26 Andreas Metzler wrote:
> Package: sa-exim
> Version: 4.2.1-17
> Severity: normal
[...]
> #1 sa-exim 4.2.1-17 (binary) does not work with exim 4.93 since some
> exported functions have been replaced by #defines. Once the sources are
Package: lintian
Version: 2.32.0
Severity: normal
Hello,
I have just gotten this warning:
-
E: gnutls28 source: invalid-profile-name-in-build-profiles-field noguile guile-g
nutls
N:
N:The restriction formula in Build-Profiles field includes an unknown
N:bu
On 2019-10-31 Helmut Grohne wrote:
> On Thu, Oct 31, 2019 at 06:54:15PM +0100, Andreas Metzler wrote:
[...]
>> Would you mind explaning (or giving a pointer) why you would prefer this
>> over using the "noguile" profile?
> I'm not opposed to profiles in princip
On 2019-10-31 Helmut Grohne wrote:
[...]
> gnutls28 startes failing to cross build in the version above:
> http://crossqa.debian.net/build/gnutls28_3.6.10-3_ppc64el_20191031081945.log
> | /bin/mkdir -p "`dirname "modules/gnutls.go"`" ; \
> | : && out=1 || out=- ; \
> | unset GUILE_LOAD_COMP
+
+ * Non-maintainer upload.
+ * Apply ab73a746a0d6fcac2e682c5548eeb87fb9c9c82e from upstream GIT to fix
+build error against nettle 3.5. Closes: #940985
+
+ -- Andreas Metzler Sun, 27 Oct 2019 18:40:21 +0100
+
dnsmasq (2.80-1) unstable; urgency=low
* New upstream. (closes: #837602) (closes: #
On 2019-10-26 Andreas Metzler wrote:
> Package: sa-exim
> Version: 4.2.1-17
> Severity: normal
[...]
> #1 sa-exim 4.2.1-17 (binary) does not work with exim 4.93 since some
> exported functions have been replaced by #defines. Once the sources are
> compatible a rebuild will be n
On 2019-10-23 mo...@debian.org wrote:
> Source: exim4
> Version: 4.92.3-1
> Severity: normal
> Tags: sid bullseye
> User: debian-pyt...@lists.debian.org
> Usertags: py2removal
> Python2 becomes end-of-live upstream, and Debian aims to remove
> Python2 from the distribution, as discussed in
> https
Package: sa-exim
Version: 4.2.1-17
Severity: normal
I am moving this from direct maintainer-contact to the BTS.
https://alioth-lists.debian.net/pipermail/pkg-exim4-maintainers/2019-October/016333.html
https://alioth-lists.debian.net/pipermail/pkg-exim4-maintainers/2019-October/016341.html
#1 sa-e
Package: sa-exim
Version: 4.2.1-17
Severity: normal
Tags: patch
Building sa-exim throws lots of warnings like this one:
---
gcc -I/usr/include/exim4 -fPIC -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
-fdebug-prefix-map=/dev/shm/EXIM4/sa-exim-4.2.1=. -fstack-protector-strong
-Wformat -W
On 2019-10-11 Graham Inggs wrote:
> For reference, upstream proposed that applications requiring this
> function should link lutil or make their own copy of the code [1].
> Arch Linux bug report [2] refers to a patch [3], which resolves the issue.
> Gentoo bug report [4] refers to a pull request
On 2019-10-14 Marc Haber wrote:
> On Mon, Oct 14, 2019 at 09:23:17AM +0100, Adam D. Barratt wrote:
[...]
> Also, the configuration option is commented in the default file, and
> there is not even a macro to enable it. So, who enables this already
> knows her way around things.
> This should, IMO,
Control: tags -1 pending
guile-gnutls (targeted for experimental) was uploaded on September 22.
It is in the NEW queue.
cu Andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
Control: tags -1 patch
On 2019-08-31 Andreas Metzler wrote:
> Source: xplanet
> Version: 1.3.0-5.1
> Severity: important
> Hello,
> this package uses GifQuantizeBuffer() from giflib. The symbol has been
> dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
&
On 2019-10-03 Raphaël Hertzog wrote:
> Package: lintian
> Version: 2.24.0
> Severity: normal
> User: de...@kali.org
> Usertags: origin-kali
> I just uploaded ddd_3.3.12-5.2.dsc and I get this warning:
> W: ddd source: changelog-file-missing-explicit-entry 1:3.3.12-5.1 ->
> 1:3.3.12-5 (missing) -
On 2019-10-04 Sébastien Villemot wrote:
> Package: src:pfstools
> Version: 2.1.0-4
> Severity: serious
> Tags: patch ftbfs
> Control: block 934630 by -1
> Dear Maintainer,
> The Octave 5 transition has started, and pfstools FTBFS against the new
> version.
> The failure comes from the fact that
Control: tags -1 pending
On 2019-10-01 Steve Langasek wrote:
> Package: gnutls28
> Version: 3.6.9-5
> Severity: serious
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu eoan ubuntu-patch
> Dear maintainers,
> The texlive-generic-recommended transitional package has
On 2019-09-23 Helmut Grohne wrote:
> Source: autogen
> Version: 1:5.18.16-2
> Severity: important
> Tags: patch upstream
> User: debian-cr...@lists.debian.org
> Usertags: ftcbfs
> autogen fails to cross build from source. It used to build previously
> and this is important for cross bootstrapping
Control: tags -1 wontfix
On 2019-09-19 Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> > tags 905272 -wontfix
I am undoing this change. wontfix essentially means that the maintainer
has looked at the issue/suggestion and decided that the suggestion won't
b
On 2019-09-11 Andreas Henriksson wrote:
> Control: tags -1 + fixed-upstream upstream
> Control: forwarded -1 https://gitlab.com/gnutls/libtasn1/merge_requests/49
> FYI
> This issue has already been fixed in the master branch of the upstreams
> git repository. The patch can be downloaded at:
> ht
tScaleFactor() function. (Closes: #939740)
[...]
> From: Andreas Metzler
[...]
> Rebuilding hugin on current sid with libwxgtk 3.0.4+dfsg-10 creates a
> package that according to its dependencies [libwxgtk3.0-gtk3-0v5 (>=
> 3.0.4+dfsg)] is installable on testing but fails to run there (
Package: hugin
Version: 2019.0.0+dfsg-2
- Forwarded message from Carsten Wolf -
Date: Sun, 8 Sep 2019 12:04:06 +0200 (CEST)
From: Carsten Wolf
Subject: hugin/2019.0.0+dfsg-2 debian sid/testing crashing on start (amd64 as
well x86/32bit)
greetings to the debian maintainers of pac
Package: libwxgtk3.0-gtk3-0v5
Version: 3.0.4+dfsg-10
Severity: serious
Rebuilding hugin on current sid with libwxgtk 3.0.4+dfsg-10 creates a
package that according to its dependencies [libwxgtk3.0-gtk3-0v5 (>=
3.0.4+dfsg)] is installable on testing but fails to run there (with
libwxgtk3.0-gtk3-0v5
Package: release.debian.org
Severity: normal
Hello,
In hindsight I have chosen the wrong urgency for exim4 4.92.1-3, a
remote root command execution should migrate as fast as possible. Could
please bump the urgency/shorten the migration period?
urgent exim4/4.92.1-3
TIA, cu Andreas
-- System I
Source: libgnustep-gui0.27
Version: 0.27.0-5
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is
Source: libgdiplus
Version: 4.2-2
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is upgraded an
Source: xplanet
Version: 1.3.0-5.1
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is upgraded a
Source: qutemol
Version: 0.4.1~cvs2008-13
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is
Source: mplayer
Version: 2:1.3.0-8
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is upgraded a
Source: exactimage
Version: 1.0.2-4
Severity: important
Hello,
this package uses GifQuantizeBuffer() from giflib. The symbol has been
dropped in giflib 5.2 (libgif-dev/libgif7 5.2.1 is available in
experimental) and therefore the package
a) stops working when the gif library package is upgraded
On 2019-08-24 Andreas Metzler wrote:
> Source: debhelper
> Version: 12.5.3
> Severity: important
> Debhelper 12.5.3 breaks building libgcrypt20 1.8.4-5, the build fails at:
[...]
> This was introduced in 12.5.3, all other 12.x versions of debhelper
> succeed. (This is with com
Source: debhelper
Version: 12.5.3
Severity: important
Debhelper 12.5.3 breaks building libgcrypt20 1.8.4-5, the build fails at:
--
(sid)ametzler@argenau:/tmp/GCR/libgcrypt-1.8.4$ fakeroot dh_makeshlibs -V
'libgcrypt20 (>=1.8.0-0)' --add-udeb=libgcrypt20-udeb
dh_makeshlibs: lib
Package: libgif7
Version: 5.2.1-1
Severity: serious
Tags: upstream
Control: forwarded -1 https://sourceforge.net/p/giflib/bugs/142/
Hello,
the new libgif removes multiple symbols from its public API (and
ABI)[1]. One of the removals (GifQuantizeBuffer) causes breakage in
exactimage, mplayer-gui,
On 2019-08-14 Martin Duspiva wrote:
[...]
> I think that the bug #887489, which is already archived, is still persist.
> I have Debin 9 with backported Exim4 ( 4.92-8+deb10u1~bpo9+1 ) and the
> callout funciton in rcpt acl has as the same bad behavior as described in
> bug #887489.
> My acl r
Control: forwarded -1 https://bugs.exim.org/show_bug.cgi?id=2431
On 2019-08-14 Martin Duspiva wrote:
> Package: exim4
> Version: 4.92-8+deb10u1~bpo9+1
> Severity: normal
> Tags: upstream
> Dear Maintainer,
> I think that the bug #887489, which is already archived, is still
> persist. I have De
On 2019-06-16 "Torrance, Douglas" wrote:
> On Sun, Jun 16, 2019 at 7:30 AM Andreas Metzler
> mailto:ametz...@bebt.de>> wrote:
>> /usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
>> Requires: x11 xext xpm
>> Therefore anything build-depending on libdocka
Control: severity -1 serious
On 2019-08-08 Steve Langasek wrote:
> Package: gnutls28
> Version: 3.6.9-3
> Severity: important
[...]
> Dear maintainers,
> In Ubuntu we discovered that the new version of libgnutls was causing
> systemd-resolved to fail to start on i386, due to forbidden text reloc
On 2019-07-18 Sven Hartge wrote:
> On 17.07.19 20:46, Sven Hartge wrote:
>> Possible solution (untested): Also create a exim4-base.timer and
>> .service and create a Before= dependency on logrotate.service.
> I've whipped up a little Proof-of-Concept to test this, available also
> at https://sal
On 2019-07-27 Christian Garbs wrote:
> Package: exim4-base
> Version: 4.92-8+deb10u1
> Severity: normal
> Tags: ipv6
> After the update from Stretch to Buster, on one of my systems
> /etc/cron.daily/exim4-base failed on every run with just
> hostname: Name or service not known
> as an error mes
Source: nettle
Version: 3.4.1-1
Severity: wishlist
Hello,
nettle 3.5.1 was released end of June. Could you please update the
package?
Thanks, cu Andreas
On 2019-07-25 Sven Hartge wrote:
> On 19.07.19 07:29, Sven Hartge wrote:
>> On 18.07.19 20:01, Sven Hartge wrote:
>>> On 17.07.19 20:46, Sven Hartge wrote:
Possible solution (untested): Also create a exim4-base.timer and
.service and create a Before= dependency on logrotate.service.
>>
Source: debci
Severity: normal
Hello,
exim4 4.92-9 was marked as failed:
https://ci.debian.net/packages/e/exim4/
Result
——
∙ Status: fail (Erroneous package)
∙ Duration: 0h 0m 20s
[...]
autopkgtest [04:17:20]: testing package exim4 version 4.92-9
autopkgtest [04:17:20]: build not needed
aut
Package: piuparts.debian.org
Severity: normal
Hello,
exim4 4.92-9 is marked as failing in piuparts:
https://piuparts.debian.org/sid/source/e/exim4.html
Source: exim4 piuparts summary: failed Version:4.92-9
[...]
Binary: exim4 unknown package
Binary: exi
On 2019-06-19 Bjoern Buerger wrote:
> * Andreas Metzler (ametz...@bebt.de) [190618 19:15]:
[...]
> > Could you try
> > a) disabling BDAT (set chunking_advertise_hosts = )
> > b) try a backport of sa-exim 4.2.1-17?
> > See #879687.
> We could give it a try, but I
On 2019-06-19 Jeremy Sowden wrote:
[...]
> Your patch truncates any string value at the first %. I don't think
> that's the right way to go.
[...]
https://repo.or.cz/wmaker-crm.git/commit/e037ae3684928a2fbf4a3994562a322f5d3b0c71
is supposed to fix this.
cu Andreas
On 2019-06-17 Bjoern Buerger wrote:
> Am Mon, 17 Jun 2019 schrieb Andreas Metzler:
[...]
> > what version did you upgrade from, the previous bpo-version (4.92-2) or
> > the original stretch release?
> exim4-base:i386 (4.89-2+deb9u4, 4.92-7~bpo9+1)
> exim4-daemon-heavy:i386 (
On 2019-06-16 Ross Boylan wrote:
[...]
> So it sounds as if I should wait til gnutls30 3.6.7-4 appears before
> doing the upgrade. Or maybe the security problem is serious enough to
> warrant an upgrade now? TLS is likely to matter to me only as a
> client.
Hello Ross,
this choice a noop, 3.6.
On 2019-06-17 Bjoern Buerger wrote:
> Package: exim4-daemon-heavy
> Version: 4.92-7
> Severity: important
[...]
> We did update to 4.92-7 from bpo before we saw the problem for
> the first time.
Hello Bjoern,
what version did you upgrade from, the previous bpo-version (4.92-2) or
the origin
Package: libdockapp-dev
Version: 1:0.7.2-1
Severity: important
/usr/lib/x86_64-linux-gnu/pkgconfig/dockapp.pc:
Requires: x11 xext xpm
Therefore anything build-depending on libdockapp-dev and using pkg-config
to locate the library will FTBFS unless it has a direct b-d on
libxext-dev.
I think the
On 2019-06-15 Ross Boylan wrote:
> I've been following this bug because it came up as an issue for a
> security upgrade to libgnutls-openssl27 in buster. I'm still seeing
> 3.6.7-3 as the upgrade target.
Hello Ross,
I do not know whether this bug applies to packages using GnuTLS via the
openssl
On 2019-06-14 Marc Haber wrote:
> Package: exim4
[...]
> for some possibly historical reason, the dependencies between the exim
> packages are not versioned. This might lead to the latest security
> updates not being installed if some people just do apt install exim4
> instead of the recommended a
n smtp response to apply to the whole response instead
+ of resetting for every byte received.
++ 75_15-Fix-detection-of-32b-platform-at-build-time.-Bug-240.patch
+ https://bugs.exim.org/show_bug.cgi?id=2405
+ ${eval } was broken on 32bit archs.
+
+ -- Andreas Metzler Sat, 08 Jun 2
gitlab.com/gnutls/gnutls/issues/754
+
+ -- Andreas Metzler Wed, 12 Jun 2019 19:21:23 +0200
+
gnutls28 (3.6.7-3) unstable; urgency=medium
* Revert debhelper upgrade, use DH 10.
diff -Nru
gnutls28-3.6.7/debian/patches/40_rel3.6.8_01-gnutls_srp_entry_free-follow-consistent-behavior-in.patch
gnutl
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package exim4. This upload pulls 5 patches from upstream
GIT:
+ 75_11-GnuTLS-fix-tls_out_ocsp-under-hosts_request_ocsp.patch
Fix expansion of $tls_out_ocsp under hosts_reque
On 2019-06-04 Andreas Metzler wrote:
> On 2019-06-03 Dominik George wrote:
[...]
> >pwgen 16383 | gnutls-cli --no-ca-verification --port 5556 localhost
> > From a size of 16383 bytes onwards, I get:
> > |<1>| Received packet with illegal length: 16385
> >
On 2019-06-06 Sébastien Santoro wrote:
> Package: exim4-config
> Version: 4.89-2+deb9u4
> It's not possible anymore to install exim4-config and ssmtp on the
> same server.
> $ apt install exim4-config ssmtp
> …
> The following packages have unmet dependencies:
> exim4-config : Conflicts: ssmtp
On 2019-06-03 Dominik George wrote:
> Hi,
>> Is this reproducile with gnutls-cli or is the respective server
>> publically accessible?
> It is reproducible.
> 1. Create a buster chroot for the server, or something
>similar.
> 2. Install gnutls-bin 3.6.6-3 and ssl-cert.
> 3. Start something
Control: severity -1 serious
On 2019-06-03 Dominik George wrote:
> Package: libgnutls30
> Version: 3.6.7-3
> Severity: grave
> Justification: renders package unusable
> The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
> client library) when connecting to a server with the
Source: libidn2
Version: 2.0.5-1
Severity: minor
Tags: patch
Hello,
libidn2 still has a build-dependency on help2man although it has not been
used upstream since 2.0.0 [1] and the Debian package has also switched
to ronn in 2.0.3-1 [2].
cu Andreas
[1]
** The idn2 manual page is generated from m
On 2019-05-31 Kyrian wrote:
> Quoting Andreas Metzler :
[...]
> > So if paniclog is non-empty, but only contains ignored lines then the
> > log is not-rotated but warning mails are not sent out. So "warning
> > emails keep coming" will not happen.
> Yes, I agree
On 2019-05-31 Kev Green wrote:
> Package: exim4-base
> Version: 4.84.2-2+deb*
> Severity: normal
[...]
>* What exactly did you do (or not do) that was effective (or
> ineffective)?
> Doing $E4BCD_PANICLOG_NOISE to begin with was one mitigation, but it
> does not respect the 'once' mode o
Source: debhelper
Version: 12.1.1
Severity: normal
Hello,
one of the *changes* in v11 mode is the following:
| The helpers dh_installdocs, dh_installexamples, dh_installinfo, and
| dh_installman now error out if their config has a pattern that does
| not match anything or reference a path that do
On 2019-05-20 Paul Gevers wrote:
> On 19-05-2019 10:33, Andreas Metzler wrote:
>> I probably could try to pick the CVE related changes and other important
>> bug-fixes, however I do not think it is the right choice. The changes
>> will be smaller but the risk of breakage
701 - 800 of 3596 matches
Mail list logo
