Bug#928956: Document removal of ecryptfs-utils from Buster

[Andrei POPESCU]

Control: tags -1 + moreinfo

On Lu, 13 mai 19, 23:16:40, Daniel Lange wrote:
> Package: release-notes
> Severity: important
> 
> Due to #765854 ecryptfs-utils has been removed from Buster.
> The kernel module (ecryptfs.ko) is still built but depending on the upgrade
> path users will be unable to mount their encrypted home directories (pam
> module, ecryptfs-mount-private missing).
> So they should probably be strongly advised to not upgrade.

Hi Daniel,

It would be helpful to provide more information on:
 
 * reason for removal
   not essential, but it helps to understand the issue

 * what would be the alternative(s) available in buster

 * is there a (documented) migration path

Thanks,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Bug#885463: Submitted to SourceForge also

[Ján Jockusch]

Hi,

I submitted the bug report plus patch to SourceForge also, because I see 
no change here at Debian.


https://sourceforge.net/p/unixodbc/bugs/46/

For almost two years, we have a confirmed problem with libodbc1 *and* 
the solution, and the patch is just not going into mainline.


I wonder if the category of the bug can at least be raised to "patch 
submitted" instead of "information required", because I feel I have 
provided all information already.


Please, help. I'm getting a bit desperate now.

The next thing I can think of is to open a github repository for our 
patch and deliver it from there.


I hope it doesn't have to come to that.

Cheers,

Ján

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Niels Thykier]

Sean Whitton:
> Hello,
> 
> On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote:
> 
>> [re-sent with debian-release list address corrected...]
> 
> Also resending.  Sorry.
> 
>> so there is "#928172 debian-security-support: fails to upgrade from 
>> 'testing':
>> dpkg: error: error executing hook" which happens when base-files is upgraded
>> before debian-security-support (but doesnt happen if d-s-s is upgraded 
>> first...)
>>
>> So I think this can only be fixed properly (=without asking people to
>> upgrade to the latest stretch pointrelease but instead allowing upgrades
>> to buster from *any* stretch pointrelease) by adding a "pre-depends:
>> debian-security-support (>= 2019.04.25)" to base-files in buster.
> 
> I didn't think we supported upgrades from anything but the latest point
> release of the previous stable release?
> 
> My belief is based on the release notes saying that you should upgrade
> to the latest point relesae first.
> 

My understanding is that we prefer that upgrade paths works regardless
of which minor version of the stable release you upgrade from (to the
extend possible).

Thanks,
~Niels

Bug#885472: Patch for version 2.3.4-1.1

[Ján Jockusch]

Hello,

after more than a year, I am resending this message I already sent in 
Feb 2018:



two more weeks have passed, and with the revised patch there was not a 
single incident with a truncated INI file.


To make applying the patch easier, find attached a patch against version 
2.3.4-1.1, which is currently in "testing".


If there is anything else I can help with, please don't hesitate to 
contact me.



- Ján



--- unixodbc-2.3.4.orig/ini/iniCommit.c
+++ unixodbc-2.3.4/ini/iniCommit.c
@@ -31,7 +31,7 @@
 if (hIni->iniFileType == 0)
 {
 #endif
-hFile = uo_fopen( hIni->szFileName, "w" );
+hFile = uo_fopen( hIni->szFileName, "a" );
 #ifdef __OS2__
 }
 else
--- unixodbc-2.3.4.orig/ini/iniOpen.c
+++ unixodbc-2.3.4/ini/iniOpen.c
@@ -234,7 +234,7 @@
 if ( bCreate == TRUE )
 {
 if ( (*hIni)->iniFileType == 0 )
-hFile = uo_fopen( pszFileName, "w+" );
+hFile = uo_fopen( pszFileName, "a+" );
 else
 hFile = (FILE *)iniOS2Open( pszFileName);
 }
@@ -409,7 +409,7 @@
 
 if ( bCreate == TRUE )
 {
-hFile = uo_fopen( pszFileName, "w+" );
+hFile = uo_fopen( pszFileName, "a+" );
 }
 }
 
--- unixodbc-2.3.4.orig/odbcinst/_odbcinst_SystemINI.c
+++ unixodbc-2.3.4/odbcinst/_odbcinst_SystemINI.c
@@ -176,7 +176,7 @@
else
 {
 /* does not exist so try creating it */
-hFile = uo_fopen( pszFileName, "w" );
+hFile = uo_fopen( pszFileName, "a" );
 if ( hFile )
 uo_fclose( hFile );
 else

Bug#928964: gpg fails to emit OpenPGP secret keys if the stored keyfile has a comment or a uri

[Daniel Kahn Gillmor]

Package: gpg
Version: 2.2.12-1
Control: found -1 2.2.13-1
Control: found -1 2.2.14-1
Control: found -1 2.2.15-1
Control: tags -1 patch upstream
Control: affects -1 src:monkeysphere
Control: forwarded -1 https://dev.gnupg.org/T4490

When a passphraseless keyfile in ~/.gnupg/private-keys-v1.d/*.key
contains a (comment) sublist or a (uri) sublist, and it is associated
with an OpenPGP certificate, then "gpg --export-secret-key" fails with
"Bad secret key".

This happens because the code to translate from the S-expression to an
OpenPGP certificate is too brittle, assuming that a (private-key) list
can only have one sublist, which is the list for the private key itself.

The attached patch fixes the problem by ignoring all sublists after the
first in a (private-key) list.

--dkg

From 29adca88f5f6425f5311c27bb839718a4956ec3a Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Mon, 13 May 2019 21:22:38 -0400
Subject: [PATCH] gpg: enable OpenPGP export of cleartext keys with comments

* g10/export.c (cleartext_secret_key_to_openpgp): ignore trailing
sublists in private-key S-expression.

--

When gpg-agent learns about a private key from its ssh-agent
interface, it stores its S-expression with the comment attached.  The
export mechanism for OpenPGP keys already in cleartext was too brittle
because it would choke on these comments.  This change lets it ignore
any additional trailing sublists.

Signed-off-by: Daniel Kahn Gillmor 
Gnupg-Bug-Id: 4490
---
 g10/export.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/g10/export.c b/g10/export.c
index 4f6c9137e..b12da9cdb 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -596,7 +596,10 @@ cleartext_secret_key_to_openpgp (gcry_sexp_t s_key, PKT_public_key *pk)
   top_list = gcry_sexp_find_token (s_key, "private-key", 0);
   if (!top_list)
 goto bad_seckey;
-  if (gcry_sexp_length(top_list) != 2)
+
+  /* ignore all S-expression after the first sublist -- we assume that
+ they are comments or otherwise irrelevant to OpenPGP */
+  if (gcry_sexp_length(top_list) < 2)
 goto bad_seckey;
   key = gcry_sexp_nth (top_list, 1);
   if (!key)
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#928963: gpg-agent READKEY emits an invalid S-expression when private key file has comment (on 64-bit big-endian platforms)

[Daniel Kahn Gillmor]

Package: gpg-agent
Severity: serious
Version: 2.2.12-1
Control: found -1 2.2.13-1
Control: found -1 2.2.14-1
Control: found -1 2.2.15-1
Control: affects -1 src:monkeysphere
Control: tags -1 patch upstream
Control: forwarded -1 https://dev.gnupg.org/T4501

On sparc64, powerpc64, and s390x (debian's three 64-bit big-endian
platforms), gpg is unable to create a new OpenPGP certificate from some
secret keys that it already knows about.

In particular, "gpg --batch --generate" from a Key-Grip: line that
refers to a key file in private-keys-v1.d/ that contains a comment
sublist will fail with "Invalid S-expression" on those platforms.

This is due to a buggy invocation of gcry_sexp_build_array that is only
tickled when int is smaller than size_t and the platform is big-endian,
which causes the comment string to be set to zero length, which itself
is interpreted as an error of GPG_ERR_SEXP_ZERO_PREFIX.

However, this failure causes necessary functionality for
"monkeysphere-host import-key" as of monkeysphere version 0.43-3 to
break on these platforms, making monkeysphere FTBFS because the failure
is caught by its test suite.

The attached patch resolves the issue when i test it on
zelenka.debian.org (s390x), and should also work on the other two
platforms.

--dkg

From e4a158faacd67e15e87183fb48e8bd0cc70f90a8 Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor 
Date: Tue, 14 May 2019 00:05:42 -0400
Subject: [PATCH] agent: correct length for uri and comment on 64-bit
 big-endian platforms

* agent/findkey.c (agent_public_key_from_file): pass size_t as int to
gcry_sexp_build_array's %b.

--

This is only a problem on big-endian systems where size_t is not the
same size as an int.  It was causing failures on debian's s390x,
powerpc64, and sparc64 platforms.

There may well be other failures with %b on those platforms in the
codebase, and it probably needs an audit.

Once you have a key in private-keys-v1.d/$KEYGRIP.key with a comment
or a uri of reasonable length associated with it, this fix can be
tested with:

   gpg-agent --server <<<"READKEY $KEYGRIP"

On the failing platforms, the printed comment will be of length 0.

Gnupg-bug-id: 4501
Signed-off-by: Daniel Kahn Gillmor 
---
 agent/findkey.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/agent/findkey.c b/agent/findkey.c
index 755a90be1..20c9dc56a 100644
--- a/agent/findkey.c
+++ b/agent/findkey.c
@@ -1366,6 +1366,7 @@ agent_public_key_from_file (ctrl_t ctrl,
   gcry_sexp_t uri_sexp, comment_sexp;
   const char *uri, *comment;
   size_t uri_length, comment_length;
+  int uri_intlen, comment_intlen;
   char *format, *p;
   void *args[2+7+2+2+1]; /* Size is 2 + max. # of elements + 2 for uri + 2
 for comment + end-of-list.  */
@@ -1447,14 +1448,16 @@ agent_public_key_from_file (ctrl_t ctrl,
 {
   p = stpcpy (p, "(uri %b)");
   assert (argidx+1 < DIM (args));
-  args[argidx++] = (void *)&uri_length;
+  uri_intlen = (int)uri_length;
+  args[argidx++] = (void *)&uri_intlen;
   args[argidx++] = (void *)&uri;
 }
   if (comment)
 {
   p = stpcpy (p, "(comment %b)");
   assert (argidx+1 < DIM (args));
-  args[argidx++] = (void *)&comment_length;
+  comment_intlen = (int)comment_length;
+  args[argidx++] = (void *)&comment_intlen;
   args[argidx++] = (void*)&comment;
 }
   *p++ = ')';
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#927713: CVE-2019-10740

[Salvatore Bonaccorso]

Hi Guilhem

On Tue, May 14, 2019 at 02:05:31AM +0200, Guilhem Moulin wrote:
> Hi,
> 
> On Mon, 13 May 2019 at 21:43:23 +0200, Salvatore Bonaccorso wrote:
> > On Sun, Apr 21, 2019 at 10:25:22PM +0200, Moritz Muehlenhoff wrote:
> >> Source: roundcube
> >> Severity: important
> >> Tags: security
> >> 
> >> This was assigned CVE-2019-10740:
> >> https://github.com/roundcube/roundcubemail/issues/6638
> > 
> > The issue seems to have been adressed upstream now.
> 
> Thanks for the follow-up!  AFAICT this issue is mostly irrelevant for
> Stretch/Buster as it's about the Enigma plugin, which depends on a PHP
> PEAR module (php-crypt-gpg) that's in neither release.
> 
> While it might be worth fixing in a later point release, or in an upload
> to security-master along with the next security fix, this probably
> doesn't warrant a DSA does it?

Ack, right! I have updated the security-tracker accordingly!

Regards,
Salvatore

Bug#928962: hashcash FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: hashcash
Version: 1.21-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

hashcash fails to cross build from source, because it does not pass
cross tools to make. The easiest way of fixing that - using
dh_auto_build - makes hashcash cross buildable. Please consider applying
the attached patch.

Helmut
diff -u hashcash-1.21/debian/changelog hashcash-1.21/debian/changelog
--- hashcash-1.21/debian/changelog
+++ hashcash-1.21/debian/changelog
@@ -1,3 +1,9 @@
+hashcash (1.21-3) UNRELEASED; urgency=medium
+
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 14 May 2019 06:19:40 +0200
+
 hashcash (1.21-2) unstable; urgency=medium
 
   * QA upload.
diff -u hashcash-1.21/debian/rules hashcash-1.21/debian/rules
--- hashcash-1.21/debian/rules
+++ hashcash-1.21/debian/rules
@@ -10,10 +10,6 @@
 
 INSTALL = /usr/bin/install
 
-ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
-   INSTALL_PROGRAM += -s
-endif
-
 CFLAGS = `dpkg-buildflags --get CFLAGS`
 CFLAGS += -Wall -DREGEXP_POSIX
 CFLAGS += `dpkg-buildflags --get CPPFLAGS`
@@ -49,7 +45,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) "CFLAGS=$(CFLAGS) $(OPTFLAGS)" hashcash
+   dh_auto_build -- "CFLAGS=$(CFLAGS) $(OPTFLAGS)" hashcash
$(MAKE) docs
#/usr/bin/docbook-to-man debian/hashcash.sgml > hashcash.1
 

Bug#928505: fixed in ruby-pygments.rb 1.2.0-4

[dai]

Hi,

On Sun, May 12, 2019 at 09:55:33PM +0530, Pirate Praveen wrote:
> We will have to file an unblock request for this to migrate to testing.
> Can you file it?

sorry for my afk, but thanks to release team (maybe), it migrated to testing.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

On 14/05/19 4:02 am, Alexis Murzeau wrote:
> Le 28/04/2019 à 21:52, Alexis Murzeau a écrit :

...

> As this package is going to be removed if nothing happen, I will try to
> backport a patch from upstream forks.
> popcon indicate that is really used (while I don't use it myself), and
> might be more used given virtualbox was removed from buster [0].
> 
> 
> [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
> 

Yes, please go ahead I can help you with testing.

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

On 29/04/19 1:22 am, Alexis Murzeau wrote:
> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57

The error log in issue 57 is same as what I get.

>  - https://github.com/tobimensch/aqemu/pull/61

Yes, please
https://github.com/tobimensch/aqemu/pull/61/commits/9ff55188fb8479e573d6ed6f5669147af48316a9
try to backport this patch. I can help you in testing.


--abhijith

Bug#927126: aqemu: after updating can't open VMs

[Abhijith PA]

Hi, I missed this mail somehow. Sorry for the late reply


On 29/04/19 1:22 am, Alexis Murzeau wrote:
> On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA  wrote:
>> I recently updated aqemu and ended up in not able to open VMs.
>>
>> Following is the message is what I get when I open VMs
>>
>> AQEMU Error [264] >>>
>> Sender: QEMU return value != 0
>> Message:
>>
> 
> Hi,
> 
> When you right-click on your VM and choose "Show QEMU Arguments", what
> are the arguments of qemu ?
> If you try to run the command directly in a console, does it works ?
> If not, what's the qemu error ?
> 
> I tried myself and got errors about the vlan option.
> This option seems to be deprecated since a long time and removed now.

Yes, I can manually run vm when those arguments (removing vlan) are copied.

> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57
>  - https://github.com/tobimensch/aqemu/pull/61
> 

Bug#927189: unblock: docker.io/18.09.1+dfsg1-5+b10

[Arnaud Rebillout]

On 4/23/19 4:42 PM, Ivo De Decker wrote:
> Control: tags -1 moreinfo
>
> Hi,
>
> On Tue, Apr 16, 2019 at 05:42:00AM +, Niels Thykier wrote:
>>> I'd like to fix #925224 [1] for buster. The fix is trivial, and allows
>>> the docker's debootstrap script to work again when it queries
>>> security.debian.org, by following redirections. Please see bug for
>>> more details.
>>>
>>> I attached a source debdiff as mentioned in buster freeze policy [2].
>>>
>>> Sorry for the inconvenience,
> Your upload incorporated a newer version of golang-golang-x-sys in ustable,
> which has changes that are not appropriate during the freeze. If you want
> docker.io to migrate, the changes in golang-golang-x-sys need to be reverted.
>
> Thanks,
>
> Ivo
>
  Hi Ivo,

thanks for noticing about golang-golang-x-sys.

I just had a quick look, so it turns out that:

- testing has "golang-golang-x-sys (= 0.0~git20181228.9a3f9b0-1)"
- unstable has "golang-golang-x-sys (=0.0~git20190412.9773273-1)"

As long as I upload a source package to unstable, it will be built
against golang-golang-x-sys from unstable, hence it will be unsuitable
for testing.

It seems that I should instead upload to *testing-proposed-update**s*,
am I correct?

Please notice that the version of docker.io in unstable right now
(18.09.1+dfsg1-7) has two bug fixes compared to testing:

- *#925224*, which was initially the reason to open this unblock bug
- *#921600*, which is a bug fix I just uploaded, and I believe should
also be part of buster

If you agree with this additional bug fix, then what version should I
use for the package:

- testing-proposed-updates: *18.09.1+dfsg1-7+deb10u1* seems suitable
- unstable: should I bump the version as well, so that it's above
18.09.1+dfsg1-7+deb10u1? Something like 18.09.1+dfsg1-7+deb11u1 (+deb11
feels strange honestly).

Sorry to bother you with these, I'm very new and learning all these
procedures.

Thanks again,

  Arnaud

Bug#928503: Want "dgit reportbug" to submit a patch, or something

[Sean Whitton]

Hello,

On Mon 13 May 2019 at 11:49AM +01, Ian Jackson wrote:

> Sean Whitton writes ("Bug#928503: Want "dgit reportbug" to submit a patch, or 
> something"):
>
>> I think that in the vast majority of cases this tool would produce the
>> needed output even if your git tree was not obtained with dgit clone, so
>> I would hope that it could be completely decoupled from dgit.
>
> Maybe.  The question isn't really whether the git tree was made by
> dgit clone, but:
>   * what format the NMUer's tree is in
>   * where we obtain the prior-to-NMU git view
>
> If we assume that the NMUer's git branch is as if from dgit
> clone/fetch branch, and that the NMUer has worked in a way that would
> be appropriate for dgit quilt-fixup, then we can obtain the
> prior-to-NMU git view from `dgit fetch', and everything is a SMOP.
>
> I think the result would need dgit only for dgit fetch.  But I don't
> see what dgit fetch could be replaced with.  And the NMUer's workflow
> must be dgit-NMU-ish (make commits to actual files; ignore
> debian/patches; no merging).
>
> If we can't make these assumptions then: what if the NMUer used
> vcs-git and some salsa branch ?  What if the NMUer uses some gbp pq
> NMU workflow (I have no idea if such a thing is even possible, but I
> bet there are people who do something like this) ?  What if the NMUer
> manually created a file in debian/patches ?  etc.

Hmm, I think I was implicitly assuming that the user would supply a
revision range, rather than the tool trying to guess that range.

I'm undecided how important it to automatically determine the revision
range.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928961: [kdevelop] kdevelop calls incorrectly konsole and gdb, resulting in debugging failure

[Synthea]

Package: kdevelop
Version: 4:5.0.3-1+b1
Severity: normal

As said in this link, kdevelop calls incorrectly gdb (it should be
called as a child to the sh script in debuggers/gdb/stty.cpp it seems),
resulting in gdb complaining about not getting access to a tty.

https://stackoverflow.com/questions/7407088/kdevelop-debugging-warning-failed-to-set-controlling-terminal-operation-not-pe


--- System information. ---
Architecture: 
Kernel:   Linux 4.9.0-5-amd64

Debian Release: 9.8
  500 stable-updates  deb.debian.org 
  500 stable  security.debian.org
  500 stable  deb.debian.org
  100 stretch-backports deb.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-
kdevelop-data  (>= 4:5.0.3-1) | 4:5.0.3-1
kdevplatform10-libs(>= 5.0.3) | 5.0.3-1
kio   | 5.28.0-2
libc6   (>= 2.14) | 
libclang1-3.9 (>= 1:3.9.1-6~) | 
libgcc1(>= 1:3.0) | 
libkasten3controllers3 (>= 4:14.12.0) | 
libkasten3core3(>= 4:14.12.0) | 
libkasten3okteta1controllers1  (>= 4:14.12.0) | 
libkasten3okteta1core1 (>= 4:14.12.0) | 
libkasten3okteta1gui1  (>= 4:14.12.0) | 
libkf5completion5 (>= 4.97.0) | 
libkf5configcore5 (>= 4.98.0) | 
libkf5configgui5  (>= 4.97.0) | 
libkf5configwidgets5  (>= 4.96.0) | 
libkf5coreaddons5 (>= 5.16.0) | 
libkf5crash5  (>= 5.15.0) | 
libkf5declarative5(>= 4.96.0) | 
libkf5i18n5   (>= 4.97.0) | 
libkf5iconthemes5 (>= 4.96.0) | 
libkf5itemviews5  (>= 4.96.0) | 
libkf5jobwidgets5 (>= 4.96.0) | 
libkf5kiocore5(>= 4.96.0) | 
libkf5kiowidgets5 (>= 4.96.0) | 
libkf5newstuff5   (>= 4.95.0) | 
libkf5parts5  (>= 4.96.0) | 
libkf5texteditor5 | 
libkf5threadweaver5   (>= 4.98.0) | 
libkf5widgetsaddons5  (>= 4.96.0) | 
libkf5xmlgui5 (>= 4.96.0) | 
libprocesscore7  (>= 4:5.3.0) | 
libprocessui7 (>= 5.2.50+git) | 
libqt5core5a   (>= 5.7.0) | 
libqt5dbus5(>= 5.4.0) | 
libqt5gui5 (>= 5.7.0) | 
libqt5help5   (>= 5.6.0~beta) | 
libqt5network5 (>= 5.4.0) | 
libqt5quickwidgets5(>= 5.3.0) | 
libqt5webkit5   (>= 5.6.0~rc) | 
libqt5widgets5 (>= 5.4.0) | 
libqt5xml5 (>= 5.4.0) | 
libstdc++6   (>= 5.2) | 


Recommends(Version) | Installed
===-+-===
g++ | 4:6.3.0-4
gcc | 4:6.3.0-4
gdb(>= 7.0) | 7.12-6
kapptemplate| 4:16.08.3-1
make| 4.1-9.1
kio-extras  | 4:16.08.3-1


Suggests   (Version) | Installed
-+-===
cmake| 3.7.2-1
kdevelop-l10n| 
ninja-build  | 1.7.2-1





signature.asc
Description: This is a digitally signed message part

Bug#916822: u-boot-sunxi: A20-OLinuXino-Lime2 Rev. K cannot load linux

[Vagrant Cascadian]

On 2019-04-28, James Valleroy wrote:
> I tried with the eMMC u-boot from u-boot-sunxi_2019.01+dfsg-5. But it
> stops at the some point:
>
> # first boot attempt
>
> U-Boot SPL 2019.01+dfsg-5 (Apr 19 2019 - 23:43:08 +)
> DRAM: 1024 MiB
> CPU: 91200Hz, AXI/AHB/APB: 3/2/2
> Trying to boot from MMC1
>
>
> U-Boot 2019.01+dfsg-5 (Apr 19 2019 - 23:43:08 +) Allwinner Technology
>
> CPU:   Allwinner A20 (SUN7I)
> Model: Olimex A20-OLinuXino-LIME2-eMMC
> I2C:   ready
> DRAM:  1 GiB


From this commit in u-boot upstream, it sounds like Revision K cannot
reliably boot from eMMC, and recent versions of the board have an SPI
flash added for booting:

  
https://git.denx.de/?p=u-boot.git;a=commit;h=58e9502e6d98976e2df8ee7d9d8e61ce9250ad7b

If your board has SPI flash, you could install u-boot from experimental
(currently 2019.07~rc1) and install to flash. It might also be possible
to backport the changes to 2019.01, if they're not too invasive.

But it sounds like the vendor worked around the issue by changing the
hardware; there may be no workaround in software.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Steffen Ullrich]

> Ah I see, thanks for the clarification.  I thought you meant it could
> yield a deadlock.  Aren't temporary failures also possible on plain
> sockets (though of course the extra SSL layer make it strictly more
> likely to happen)?  IIRC if the checksum of the incoming packet
> mismatches, which causes the read() call to block until the packet is
> retransmitted.

select only shows an fd ready  if data are available for read in the socket
buffer. Data with wrong checksum are discarded by the kernel before they are
put into the socket buffer and thus don't cause select to show it ready for
read.

select(2) explicitly says:

  A file descriptor is considered ready if it is possible to perform a
  corresponding I/O operation (e.g., read(2)  without blocking ...

> > And while using blocking I/O with polling sockets might be fine with plain
> > sockets where each byte is part of application data it is not fine with SSL
> > since the unit in SSL is not a byte but a record and some records might
> > contain application data and some not.
>
> Why is that not fine, if the SSL_read() caller is ready for that (documented)
> outcome, and doesn't assume that the call will always block until some
> application data is received?

IO::Socket::SSL is intended as abstraction which behaves as much as possible
as other IO::Socket classes. It is not intended that the developer has to be
familiar with the exact semantics of SSL_read (which also changed over
time, especially with OpenSSL 1.1.0 and again with OpenSSL 1.1.1). While it
is impossible to behave in exactly all cases sysread is usually not expect
to return a temporary error on a blocking socket.

> Then I don't get it.  AFAICT the current documentation reflects what
> happens with blocking sockets and OpenSSL <1.1.1a, namely that
> IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
> renegotiated.  Are you saying that the intention was to keep retrying
> (either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
> OpenSSL ≥0.9.6) until application data is received or a fatal error is
> encountered?

Yes, the intention was to reflect as much as possible what is expected from
IO::Socket::sysread and not what the SSL_read documentation says.

> Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
> used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
> particular, a quick codesearch returns a few prominent programs that
> reverted the new OpenSSL default.

For applications using lower level libraries it is perfectly fine to follow
changes in the behavior in these lower level libraries. The idea behind
higher level abstractions is that this does not need to be done, i.e. it
should hide lower level implementation details and just continue to work. It
is not always possible but at least one can try.

> Anyway this bug can probably be closed now, maybe we should follow up
> elsewhere.  Thanks for the discussion & analysis!

Thank You too. Regards,
Steffen

Bug#928947: u-boot: Add support for Pine64 LTS board

[Sunil Mohan Adapa]

On 13/05/19 6:36 pm, Vagrant Cascadian wrote:
[...]
>> U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
>> DRAM: 2048 MiB
>> Trying to boot from MMC1
>> NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
>> NOTICE:  Configuring SPC Controller
>> NOTICE:  BL3-1: v1.0(debug):
>> NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018
> 
> It looks like you're using the atf-allwinner package (or a custom ATF
> build) instead of arm-trusted-firmware. Both should work ok, but at some
> point atf-allwinner may get deprecated.
> 
> There's a u-boot-install-sunxi64 script that can be used to install
> u-boot, and will prefer firmware binaries from arm-trusted-firmware.

Thanks for the tip. I will make changes to freedom-maker to start using
arm-trusted-firmware instead. We are already using
u-boot-install-sunxi64 script.

Meanwhile, on a built image, I have switched to arm-trusted-firmware and
reran u-boot-install-sunxi64. Here is the fresh boot log:

U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL31: v2.0(debug):
NOTICE:  BL31: Built : 23:33:29, Nov 27 2018
NOTICE:  BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE:  BL31: Found U-Boot DTB at 0x407f2a8, model: Pine64 LTS
INFO:ARM GICv2 driver initialized
INFO:Configuring SPC Controller
NOTICE:  BL31: PMIC: Detected AXP803 on RSB.
INFO:PMIC: AXP803: dcdc1 voltage: 3.300V
INFO:PMIC: AXP803: dcdc5 voltage: 1.200V
INFO:PMIC: AXP803: dcdc6 voltage: 1.100V
INFO:PMIC: AXP803: dldo1 voltage: 3.300V
INFO:PMIC: AXP803: Enabling DC1SW
INFO:BL31: Platform setup done
INFO:BL31: Initializing runtime services
INFO:BL31: cortex_a53: CPU workaround for 843419 was applied
INFO:BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:BL31: Preparing for EL3 exit to normal world
INFO:Entry point address = 0x4a00
INFO:SPSR = 0x3c9


U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 7 ms (310.5 KiB/s)
## Executing script at 4fc0
18560880 bytes read in 858 ms (20.6 MiB/s)
16053 bytes read in 13 ms (1.2 MiB/s)
25179720 bytes read in 1169 ms (20.5 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fc000, end 49fff648 ... OK
   Loading Device Tree to 487f5000, end 487fbeb4 ... OK

Starting kernel ...

[2.737551] sun50i-de2-bus 100.de2: Error couldn't map SRAM to device

Debian GNU/Linux 10 freedombox ttyS0

freedombox login:

-- 
Sunil



signature.asc
Description: OpenPGP digital signature

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Sean Whitton]

Hello,

On Mon 13 May 2019 at 11:32AM +00, Holger Levsen wrote:

> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
>
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.

I didn't think we supported upgrades from anything but the latest point
release of the previous stable release?

My belief is based on the release notes saying that you should upgrade
to the latest point relesae first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Sean Whitton]

Hello,

On Mon 13 May 2019 at 11:52AM +00, Holger Levsen wrote:

> [re-sent with debian-release list address corrected...]

Also resending.  Sorry.

> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upgraded 
> first...)
>
> So I think this can only be fixed properly (=without asking people to
> upgrade to the latest stretch pointrelease but instead allowing upgrades
> to buster from *any* stretch pointrelease) by adding a "pre-depends:
> debian-security-support (>= 2019.04.25)" to base-files in buster.

I didn't think we supported upgrades from anything but the latest point
release of the previous stable release?

My belief is based on the release notes saying that you should upgrade
to the latest point relesae first.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928666: Want dgit FAQ

[Sean Whitton]

control: retitle -1 want more entries in dgit faq & add links to it in existing 
docs

Hello,

On Sun 12 May 2019 at 10:22PM +01, Ian Jackson wrote:

> Sean Whitton writes ("Re: Bug#928666: Want dgit FAQ"):
>> I would like to just get this published on the Debian wiki as soon as
>> possible; let me know if you really want to avoid that, Ian.
>
> Great!  Please go ahead.  That's great.  (I haven't reviewed these,
> but it's a wiki...)

Done:

https://wiki.debian.org/DgitFAQ

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928947: u-boot: Add support for Pine64 LTS board

[Vagrant Cascadian]

On 2019-05-13, Sunil Mohan Adapa wrote:
> On 13/05/19 2:09 pm, Vagrant Cascadian wrote:
>> On 2019-05-13, Sunil Mohan Adapa wrote:
>>> It would be nice to have support for the Pine64 LTS board which is different
>>> from Pine64+ board that is already supported. Upstream u-boot, flash-kernel 
>>> and
>>> Debian kernel already have support for the board.
>> 
>> Thanks! Committed to git.
>> 
>> Would you consider testing against u-boot 2019.01+dfsg-* packages in
>> Debian too, so support could be added for buster?
>
> Thank your for merging the patch. I have tested the patch on branch
> debian/2019.01+dfsg-6 with the following results. Everything looks good.

Great, I'll try and get it into buster!


> U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
> DRAM: 2048 MiB
> Trying to boot from MMC1
> NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
> NOTICE:  Configuring SPC Controller
> NOTICE:  BL3-1: v1.0(debug):
> NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018

It looks like you're using the atf-allwinner package (or a custom ATF
build) instead of arm-trusted-firmware. Both should work ok, but at some
point atf-allwinner may get deprecated.

There's a u-boot-install-sunxi64 script that can be used to install
u-boot, and will prefer firmware binaries from arm-trusted-firmware.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928947: u-boot: Add support for Pine64 LTS board

[Sunil Mohan Adapa]

On 13/05/19 2:09 pm, Vagrant Cascadian wrote:
> On 2019-05-13, Sunil Mohan Adapa wrote:
>> Source: u-boot
>> Version: 2019.07-rc1+dfsg-4
> ...
>> It would be nice to have support for the Pine64 LTS board which is different
>> from Pine64+ board that is already supported. Upstream u-boot, flash-kernel 
>> and
>> Debian kernel already have support for the board.
> 
> Thanks! Committed to git.
> 
> Would you consider testing against u-boot 2019.01+dfsg-* packages in
> Debian too, so support could be added for buster?

Thank your for merging the patch. I have tested the patch on branch
debian/2019.01+dfsg-6 with the following results. Everything looks good.

Boot Log


U-Boot SPL 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):
NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018
NOTICE:  DT: sun50i-a64-pine64-lts
INFO:Configuring AXP PMIC
INFO:PMIC: DRAM voltage: 1.24V
INFO:PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 00
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9


U-Boot 2019.01+dfsg-6 (May 12 2019 - 01:20:19 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
USB0:   USB EHCI 1.00
USB1:   USB OHCI 1.0
USB2:   USB EHCI 1.00
USB3:   USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 7 ms (310.5 KiB/s)
## Executing script at 4fc0
18560880 bytes read in 927 ms (19.1 MiB/s)
16053 bytes read in 12 ms (1.3 MiB/s)
25179720 bytes read in 1261 ms (19 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fc000, end 49fff648 ... OK
   Loading Device Tree to 487f5000, end 487fbeb4 ... OK

Starting kernel ...

[2.670794] sun50i-de2-bus 100.de2: Error couldn't map SRAM to device

Debian GNU/Linux 10 freedombox ttyS0

freedombox login:

Board Model
---

root@freedombox:~# cat /sys/firmware/devicetree/base/model
Pine64 LTSroot@freedombox:~#

Package Versions


root@freedombox:~# uname -a
Linux freedombox 4.19.0-5-arm64 #1 SMP Debian 4.19.37-1 (2019-05-05)
aarch64 GNU/Linux

root@freedombox:~# dpkg -l u-boot-sunxi
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=
ii  u-boot-sunxi:arm64 2019.01+dfsg-6 arm64A boot loader for
sunxi systems

root@freedombox:~# dpkg -l flash-kernel
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  flash-kernel   3.98 arm64utility to make certain
embedded devices bootable

RAM
---

root@freedombox:~# free -m
  totalusedfree  shared  buff/cache
available
Mem:   2001 2491515   8 236
   1667
Swap: 0   0   0

Ethernet Performance


root@freedombox:~# iperf3 -c 10.42.1.1
Connecting to host 10.42.1.1, port 5201
[  5] local 10.42.1.210 port 46178 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   108 MBytes   909 Mbits/sec0369 KBytes

[  5]   1.00-2.00   sec   108 MBytes   903 Mbits/sec0385 KBytes

[  5]   2.00-3.00   sec   107 MBytes   896 Mbits/sec0385 KBytes

[  5]   3.00-4.00   sec   107 MBytes   897 Mbits/sec0420 KBytes

[  5]   4.00-5.00   sec   107 MBytes   896 Mbits/sec0438 KBytes

[  5]   5.00-6.00   sec   106 MBytes   893 Mbits/sec0438 KBytes

[  5]   6.00-7.00   sec   107 MBytes   899 Mbits/sec0563 KBytes

[  5]   7.00-8.00   sec   107 MBytes   899 Mbits/sec0619 K

Bug#926130: e2fsck returns 1 which makes e2scrub fails

[Theodore Ts'o]

Hi.  I haven't forgotten about your bug report.  The problem has been
I can't find any explanation for how e2fsck could have returned an
exit status of 1 given the output shown below.

> bigon@fornost:~$ sudo LC_ALL=C e2scrub /var/lib/sbuild/
>   Logical volume "sbuildbuild.e2scrub" created.
> e2fsck 1.45.0 (6-Mar-2019)
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> /dev/fornost/sbuildbuild.e2scrub: 13/983040 files (0.0% non-contiguous),
> 68098/3932160 blocks

So... if you could do the following, I would greatly appreciate it.

1)  Confirm that this is still reproducing for you with e2fsprogs 1.45.0.

2) I've just released e2fsprogs 1.45.1 to Debian unstable.  If you
could try installing e2fsprogs, and see if you can still reproduce the
problem with e2fsprogs 1.45.1.

3) If you can, please create an /etc/e2fsck.conf containing the
following:

[options]
max_count_problems = 2
log_dir = /tmp
problem_log_filename = e2fsck-problems-%N.%h.INFO.%D-%T
log_filename = e2fsck-%N.%h.INFO.%D-%T
log_dir_wait = true

4) The rerun the e2scrub command and send me the output of
/tmp/e2fsck-problems-*INFO* and /tmp/e2fsck-*INFO* files that will be
created as a result of running e2fsck.

Many thanks, and my apologies for not getting back to you sooner.

  - Ted
 

Bug#928429: dpkg: trigger cycle postgresql-common -> sgml-base while upgrading from stretch to buster

[Guillem Jover]

Hi!

On Fri, 2019-05-10 at 21:45:09 +0200, Andreas Beckmann wrote:
> On 2019-05-09 06:00, Guillem Jover wrote:
> > awaiting trigger does not help matters, I'm not entirely sure this
> > might not be still a problem with dpkg itself. :/
> 
> I can also reproduce the problem in stretch -> sid upgrades, so in case
> you need to fix dpkg I can verify that before it migrates to testing.

Thanks for the detailed log! Ok, I think I've got a patch now, and it
still passes the functional test suite. Would it be possible and easy
to test that with the failing piuparts runs? Otherwise I'll try to
setup some chroot somewhere to do that.

I'm attaching the patch. Otherwise already built (and signed) binary
packages can be temporarily found at:

  

Thanks,
Guillem
From a333d52e9f7f99951a89b2b61a5f6807d6fb678c Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 13 May 2019 03:36:03 +0200
Subject: [PATCH] dpkg: Introduce a new dependency try level for trigger cycle
 checks

This new dependtry level will also check trigger cycles on trigger
process deferral due to unsatisfiable dependencies.

Closes: #928429
---
 debian/changelog |  3 +++
 src/main.h   | 13 +
 src/trigproc.c   |  8 +---
 3 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 3d97a0111..2a0615f36 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -6,6 +6,9 @@ dpkg (1.19.7) UNRELEASED; urgency=medium
   * dpkg: Set the force defaults before loading the config file, otherwise we
 incorrectly override them. Regression introduced in dpkg 1.19.5.
 Closes: #928671
+  * dpkg: Split the trigger dependtry into two, the second of which will be
+the one checking trigger cycles when deferring trigger processing due to
+unsatisfiable dependencies. Closes: #928429
 
   [ Updated programs translations ]
   * Catalan (Guillem Jover).
diff --git a/src/main.h b/src/main.h
index e4a251969..7f341303e 100644
--- a/src/main.h
+++ b/src/main.h
@@ -234,18 +234,23 @@ void deferred_configure(struct pkginfo *pkg);
  *   Start processing triggers if necessary.
  *   Do as for try 2.
  *
- * Try 4 (only if --force-depends-version):
+ * Try 4:
+ *   Same as for try 3, but check trigger cycles even when deferring
+ *   processing due to unsatisfiable depedencies.
+ *
+ * Try 5 (only if --force-depends-version):
  *   Same as for try 2, but don't mind version number in dependencies.
  *
- * Try 5 (only if --force-depends):
+ * Try 6 (only if --force-depends):
  *   Do anyway.
  */
 enum dependtry {
 	DEPEND_TRY_NORMAL = 1,
 	DEPEND_TRY_CYCLES = 2,
 	DEPEND_TRY_TRIGGERS = 3,
-	DEPEND_TRY_FORCE_DEPENDS_VERSION = 4,
-	DEPEND_TRY_FORCE_DEPENDS = 5,
+	DEPEND_TRY_TRIGGERS_CYCLES = 4,
+	DEPEND_TRY_FORCE_DEPENDS_VERSION = 5,
+	DEPEND_TRY_FORCE_DEPENDS = 6,
 	DEPEND_TRY_LAST,
 };
 
diff --git a/src/trigproc.c b/src/trigproc.c
index 59e30d143..54b15bbe1 100644
--- a/src/trigproc.c
+++ b/src/trigproc.c
@@ -407,9 +407,11 @@ trigproc(struct pkginfo *pkg, enum trigproc_type type)
 
 		ok = dependencies_ok(pkg, NULL, &depwhynot);
 		if (ok == DEP_CHECK_DEFER) {
-			gaveup = check_trigger_cycle(pkg);
-			if (gaveup == pkg)
-return;
+			if (dependtry >= DEPEND_TRY_TRIGGERS_CYCLES) {
+gaveup = check_trigger_cycle(pkg);
+if (gaveup == pkg)
+	return;
+			}
 
 			varbuf_destroy(&depwhynot);
 			enqueue_package(pkg);
-- 
2.21.0.1020.gf2820cf01a

Bug#926618: Bug

[John Scott]

On Thu, 11 Apr 2019 11:30:43 -0400 Nicholas D Steeves  
wrote:
> I wonder if that package fulfills this RFP?  If not, and if this bug
> remains inactive for a month, please ping me and I'll take a look.

It does not, unfortunately. That package is already in the Debian archive, and 
is the client-side program that the Web Extension works with and depends on.

Bug#928960: unblock: forensics-all/3.7

[Joao Eriberto Mota Filho]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package forensics-all.

The mdk4 was just removed from Depends field in debian/control because of
bug #921694.

I attached a debdiff.

unblock forensics-all/3.7

Thanks in advance.

Regards,

Eriberto

Bug#927713: CVE-2019-10740

[Guilhem Moulin]

Hi,

On Mon, 13 May 2019 at 21:43:23 +0200, Salvatore Bonaccorso wrote:
> On Sun, Apr 21, 2019 at 10:25:22PM +0200, Moritz Muehlenhoff wrote:
>> Source: roundcube
>> Severity: important
>> Tags: security
>> 
>> This was assigned CVE-2019-10740:
>> https://github.com/roundcube/roundcubemail/issues/6638
> 
> The issue seems to have been adressed upstream now.

Thanks for the follow-up!  AFAICT this issue is mostly irrelevant for
Stretch/Buster as it's about the Enigma plugin, which depends on a PHP
PEAR module (php-crypt-gpg) that's in neither release.

While it might be worth fixing in a later point release, or in an upload
to security-master along with the next security fix, this probably
doesn't warrant a DSA does it?

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928959: papi: DFSG-unfree file in source

[Sean Whitton]

Source: papi
Version: 5.7.0-1
Severity: serious

At least one file in this package fails to permit derivative works:

spwhitton@iris:~/tmp/papi>head -n15 src/components/appio/tests/iozone/fileop.c
/*
 * Author: Don Capps
 * 3/13/2006
 *
 *   Author: Don Capps (ca...@iozone.org)
 *   7417 Crenshaw
 *   Plano, TX 75025
 *
 *  Copyright 2006, 2007, 2008, 2009   Don Capps.
 *
 *  License to freely use and distribute this software is hereby granted
 *  by the author, subject to the condition that this copyright notice
 *  remains intact.  The author retains the exclusive right to publish
 *  derivative works based on this work, including, but not limited to,
 *  revised versions of this work",

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 22:24:55 +0200, Steffen Ullrich wrote:
> On Mon, May 13, 2019 at 03:18:14PM +0200, Guilhem Moulin  
> wrote:
>> Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
>> default flags?  libssl mentions no such thing beside the new default
>> mode.  And in fact the s_client() program, *from OpenSSL upstream
>> itself*, does precisely that: a select loop in blocking I/O mode (unless
>> the ‘-nbio’ flag is set).
> 
> "Before" meaning already with previous OpenSSL versions. But the effect was
> likely hard to notice: an incomplete SSL record would not cause a permanent
> hang but only a blocking read until the rest of the data was received, i.e.
> only some slow down in some situations.

Ah I see, thanks for the clarification.  I thought you meant it could
yield a deadlock.  Aren't temporary failures also possible on plain
sockets (though of course the extra SSL layer make it strictly more
likely to happen)?  IIRC if the checksum of the incoming packet
mismatches, which causes the read() call to block until the packet is
retransmitted.

> And while using blocking I/O with polling sockets might be fine with plain
> sockets where each byte is part of application data it is not fine with SSL
> since the unit in SSL is not a byte but a record and some records might
> contain application data and some not.

Why is that not fine, if the SSL_read() caller is ready for that (documented)
outcome, and doesn't assume that the call will always block until some
application data is received?

>> The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
>> as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
>> SSL socket has a different behavior than usual read(2) system calls, in
>> that read failures should be treated with care, as there are both
>> retryable (eg. when no application data was received) and non-retryable
>> errors.
> 
> As I was the one who wrote the documentation for IO::Socket::SSL: the part
> about sysread failing was supposed to be about non-blocking sockets. A
> blocking socket was not expected to return nothing just because the
> handshake was not done.

Then I don't get it.  AFAICT the current documentation reflects what
happens with blocking sockets and OpenSSL <1.1.1a, namely that
IO::Socket::SSL::sysread() returns undef when the TLS ≤1.2 session is
renegotiated.  Are you saying that the intention was to keep retrying
(either Perl-side, or within SSL_read() via SSL_MODE_AUTO_RETRY with
OpenSSL ≥0.9.6) until application data is received or a fatal error is
encountered?
 
> Do you know a relevant module or actually used application which has
> problems because of the default mode of SSL_MODE_AUTO_RETRY the ability to
> change it would fix the related problems and not introduce new ones, i.e.
> where such a fix would be the right thing to do?

Not anything using IO::Socket::SSL, I'm afraid.  I'm personally more
used to the lower-level APIs like libssl and Net::SSLeay.  For libssl in
particular, a quick codesearch returns a few prominent programs that
reverted the new OpenSSL default.

  Apache2's mod_ssl:
Bug:https://github.com/openssl/openssl/issues/7178
Commit: 
https://github.com/apache/httpd/commit/6ee9d597e01281f2ef2e146586129af6aed7854d#diff-b70bd458eb699e70c322ee797a3e0991

  Neon:
File:   
http://svn.webdav.org/repos/projects/neon/tags/0.30.2/src/ne_socket.c
Change: 
http://lists.manyfish.co.uk/pipermail/neon-commits/2018-September/001077.html
  
  YottaDB
Bug: 
https://github.com/YottaDB/YDB/commit/1d0a8943d8be24a6f3dd3e4d2c8bfaad1fb75c87

> Another option might be to have an option SSL_mode_auto_retry which by
> default is not set but might be set to either 0 or 1 to get a consistent
> behavior across different OpenSSL versions.

I quite like this approach :-)

Anyway this bug can probably be closed now, maybe we should follow up
elsewhere.  Thanks for the discussion & analysis!
-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928450: RFS: megadown/0~20190502+git734e46f-1 [RC]

[Lev Lazinskiy]

Hi Adam, 

On Sun, 5 May 2019 13:46:57 +0200 Adam Borowski  wrote:
> On Sat, May 04, 2019 at 04:08:32PM -0700, Lev Lazinskiy wrote:
> >   I am looking for a sponsor for my package "megadown"
> > 
> >  * Package name: megadown
> >Version : 0~20190502+git734e46f-1
> 
> >   Changes since the last upload:
> > 
> >   * New upstream release (Closes: #927462) which is an RC bug. 
> >   * Remove patch series. Upstream swapped out python for jq. Python is no
longer
> > required
> >   * Add jq as dependency
> 
> Hi!
> This is a non-maintainer upload, and you don't seem to have followed the
> usual rules.  Also, during a freeze, only small targetted fixes are
> appropriate -- this is a bulk new upstream version.  There are cases when
> there's no better way than such a large upload (like Firefox and Chromium
> these days), but as the patch fixing #927462 is tiny and obvious (although
> I don't know if it's enough), it strongly seems the large upload is not
> needed.
> 
> Thus, could you please extract (and test) just the fix?  Only if that
> doesn't work we could debate uploading the whole new upstream version.
> 
> Also, although a RC bug that hasn't seen maintainer response within two
> weeks is eligible for a 0-day NMU, you'd still need to follow at least parts
> of the procedure.  Especially, the upload needs to be marked appropriately:
> the first line of the changelog should say "Non-maintainer upload.", the
> version needs to be .1, etc.  NMUs are supposed to be small which is similar
> to during-freeze updates.
> 
> (Even if such a procedure might seem like an unnecessary hurdle, it doubles
> as a way to ensure you are aware what you're doing.)

Thank you very much for all of this great feedback. This was my first time
attempting to update a package. I don't necessarily use or need this package,
but the fix seemed simple enough so I gave it a shot to try to help out with the
RC Bug. 

It looks like the RC bug was already resolved by another NMU. 

I really appreciate the additional direction that you provided and I will keep
this in mind for the future. 

> 
> 
> Meow!
> -- 
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Did ya know that typing "test -j8" instead of "ctest -j8"
> ⢿⡄⠘⠷⠚⠋⠀ will make your testsuite pass much faster, and fix bugs?
> ⠈⠳⣄
> 
> 
--
Lev Lazinskiy
https://levlaz.org

e: l...@levlaz.org


signature.asc
Description: This is a digitally signed message part

Bug#928450: RFS: megadown/0~20190502+git734e46f-1 [RC]

[Alexis Murzeau]

Hi,

Just to inform you that Boyuan has closed the bug #927462 (with a non 
maintainer upload):

> Date: Mon, 13 May 2019 13:59:17 -0400
> Source: megadown
> Architecture: source
> Version: 0~20180705+git83c53dd-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Vivia Nikolaidou 
> Changed-By: Boyuan Yang 
> Closes: 927462
> Changes:
>  megadown (0~20180705+git83c53dd-1.1) unstable; urgency=medium
>  .
>   * Non-maintainer upload.
>   * Cherry-pick upstream fix on link parsing logic to make the tool
>  actually usable. (Closes: #927462)


So I guess this RFS can be closed (unless something is still missing?).


#927462: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927462
-- 
Alexis Murzeau

Bug#928958: scanbd: wrong permissions

[sergio]

Package: scanbd
Version: 1.5.1-4
Severity: normal

Dear Maintainer,

99-saned.rules uses saned group:

# dpkg -L scanbd | grep 99-saned.rules
/lib/udev/rules.d/99-saned.rules

# cat /lib/udev/rules.d/99-saned.rules | grep ENV
ENV{libsane_matched}=="yes", GROUP="saned"

while scanbd.conf scanner:

# cat /etc/scanbd/scanbd.conf | grep "^\s*group"
group   = scaner

Bug#926180: scilab: FTBFS on all - New trouble

[Alexis Murzeau]

Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit :
> 
> On 12/05/2019 22:10, Julien Puydt wrote:
>> Hi,
>>
>> On 12/05/2019 11:46, Alexis Murzeau wrote:
>>
>>> I saw that there is a bugfix release 6.0.2 with many fixes [0].
>> I had started to package 6.0.2 on salsa already in february. I removed
>> the patch about Linenum as that was supposed to have been reworked and
>> fixed, and it now fails with :
>>
>> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I
>> ./src/xml2modelica  nums.cmxa ./src/xml2modelica/xMLTree.ml
>> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml
>> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml
>> ./src/xml2modelica/xMLLexer.ml
>> ./src/xml2modelica/modelicaCodeGenerator.ml
>> ./src/xml2modelica/xML2Modelica.ml
>> File "./src/xml2modelica/xML2Modelica.ml", line 1:
>> Error: Files ./src/xml2modelica/xMLParser.cmx
>>and ./src/xml2modelica/linenum.cmx
>>make inconsistent assumptions over implementation Linenum
>>
>> ie : it looks like upstream's fix isn't correct.
> 
> + upstream
> 
> S
> 
> 

Reversing the order of the includes parameters when compiling
XML2Modelica fix the build for me, ie. including xml2modelica first:
`-I ./src/xml2modelica -I ./src/modelica_compiler`

I think ocamlopt prefer to use a part of Linenum from
./src/modelica_compiler and the other one from ./src/xml2modelica which
lead to the error.

But I'm not sure this is the way to handle it cleanly.
The files "linenum.mll" are almost the same between both directories.
The only difference is the comment at the beginning of the file.

Maybe some of these "linenum.mll" file can be removed to keep only one ?

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F

Bug#927126: aqemu: after updating can't open VMs

[Alexis Murzeau]

Le 28/04/2019 à 21:52, Alexis Murzeau a écrit :
> On Mon, 15 Apr 2019 16:55:13 +0530 Abhijith PA  wrote:
>> I recently updated aqemu and ended up in not able to open VMs.
>>
>> Following is the message is what I get when I open VMs
>>
>> AQEMU Error [264] >>>
>> Sender: QEMU return value != 0
>> Message:
>>
> 
> Hi,
> 
> When you right-click on your VM and choose "Show QEMU Arguments", what
> are the arguments of qemu ?
> If you try to run the command directly in a console, does it works ?
> If not, what's the qemu error ?
> 
> I tried myself and got errors about the vlan option.
> This option seems to be deprecated since a long time and removed now.
> 
> The vlan argument issue has a upstream issues open [0].
> 
> [0] :
>  - https://github.com/tobimensch/aqemu/issues/58
>  - https://github.com/tobimensch/aqemu/issues/57
>  - https://github.com/tobimensch/aqemu/pull/61
> 

As this package is going to be removed if nothing happen, I will try to
backport a patch from upstream forks.
popcon indicate that is really used (while I don't use it myself), and
might be more used given virtualbox was removed from buster [0].


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#926644: xpat2: debian/watch should be updated

[Arne Wichmann]

begin  quotation  from Axel Beckert (in <20190408114259.gl25...@sym.noone.org>):
> uscan on xpat2's source directory bails out as follows:
> 
> > In watch file debian/watch, reading FTP
> > directory ftp://sunsite.unc.edu/pub/Linux/games/solitaires/ failed:
> > 500 Connection refused
> 
> It seems as if https://www.ibiblio.org/pub/Linux/games/solitaires/
> would a good replacement.

Thank you for the pointer. Whenever I do another upload I will consider
this.

cu

AW
-- 
[...] If you don't want to be restricted, don't agree to it. If you are
coerced, comply as much as you must to protect yourself, just don't support
it. Noone can free you but yourself. (crag, on Debian Planet)
Arne Wichmann (a...@saar.de)


signature.asc
Description: PGP signature

Bug#920453: googler does not display results without "--noua" switch

[Sebastian Stabbert]

Hello,

thank you for the kind reply, it was indeed a PEBCAK issue,
I fixed my environment and it is working now as expected.

Cheers,
Sebastian

2019-03-20 6:40 GMT+01:00, SZ Lin (林上智) :
> Hi,
> Sebastian Stabbert  於 2019年1月26日 週六
> 上午1:03寫道：
>>
>> Package: googler
>> Version: 2.9.0-1
>> Severity: normal
>
> Could you describe your operating environment? I think it might be a
> PEBCAK issue.
>
> This issue won't be able to reproduce in my Linux environment.
> However, this issue
> appears in the remote console (e.g., putty). After using the tool of
> git bisec, I've confirmed v3.7.1 [1]
> fixed this issue. The reason is that there is no agent in remote
> console; therefore the argument of "--ua" is needed.
>
> Please feel free to use v3.7.1 of googler in stretch-backports archive [2].
>
> [1]
> https://github.com/jarun/googler/commit/e704598f275f4e4bf8af100fe415ff6b8a981aaf
> [2] https://packages.debian.org/stretch-backports/googler
>
> SZ
>>
>>
>>
>> -- System Information:
>> Debian Release: 9.6
>>   APT prefers stable
>>   APT policy: (500, 'stable')
>> Architecture: amd64 (x86_64)
>>
>> Kernel: Linux 4.13.0-38-generic (SMP w/8 CPU cores)
>> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
>> LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>>
>> Versions of packages googler depends on:
>> ii  python3  3.5.3-1
>>
>> googler recommends no packages.
>>
>> googler suggests no packages.
>>
>> -- no debconf information
>

Bug#920937: 20190502-1?

[David Moreno]

Is this also happening with 20190502-1 from Sid?

Bug#926180: scilab: FTBFS on all - baseline violation?

[Rebecca N. Palmer]

Given that the error is "Illegal instruction", and reproducibly happens 
on x86-bm-01 and not the other machines we've tried, could it be 
something assuming CPU features more recent than the amd64 baseline?


If so, it's not obvious where: scilab does contain some C/C++ code (as 
well as Java), but there aren't any asm() or __builtin_ia32* calls in 
it, or any -march options in the build log.  Maybe it's in a dependency, 
not scilab itself?


There is an open "illegal instruction crash in Xcos" bug upstream, which 
may or may not be related: 
https://bugzilla.scilab.org/show_bug.cgi?id=11003#c6


Alexis Murzeau wrote:

will such bug-fix upstream release be accepted in
buster, now that we are in full freeze ?


Generally not: Debian prefers not to fix minor bugs during freeze 
because this might accidentally create major ones.

https://release.debian.org/buster/freeze_policy.html

Bug#926996: kmail: CVE-2019-10732: decryption based on replying to PGP or S/MIME encrypted emails

[Sandro Knauß]

Control: reassign -1 kf5-messagelib

The code lies in kf5-messagelib, that's why I reassign the bug. Please update 
the security tracker accordingly.

> Discussion on https://bugs.kde.org/show_bug.cgi?id=404698 seems to
> indicate the issue is getting resolved upstream.

Yes I fixed the bug upstream and will hopefully find time the next days to 
backport it to 18.08.

hefee


signature.asc
Description: This is a digitally signed message part.

Bug#928204: check-support-status: cannot create /var/lib/debian-security-support/security-support.semaphore: Directory nonexistent

[Santiago Vila]

Way to reproduce it:

1. Install package in the *host* machine:
# apt-get install debian-security-support

2. Enter a sid chroot where debian-security-support has never been installed:
# schroot -c sid

3. Install package inside the chroot:
# apt-get install debian-security-support

The postinst blindly assumes that if the user debian-security-support
exists, then /var/lib/debian-security-support should also exist:

if ! getent passwd "$USERNAME" > /dev/null; then
   adduser \
   [...]
   --home "$LIB_DIR" \
   [...]
   "$USERNAME"
fi

But schroot by default copies /etc/passwd from the host machine (where
the user already exists) inside the chroot, breaking the assumption.

Maybe the patch below is enough to fix this.

Thanks.

--- a/debian/debian-security-support.postinst
+++ b/debian/debian-security-support.postinst
@@ -20,6 +20,11 @@ configure)
 "$USERNAME"
 fi
 
+if [ ! -d "$LIB_DIR" ]; then
+  mkdir "$LIB_DIR"
+  chown $USERNAME:$USERNAME "$LIB_DIR"
+fi
+
 if [ "$TMPDIR" ] && [ "$(stat --format=%a "$TMPDIR")" != '1777' ] ; then
 export TMPDIR='/tmp'
 fi

Bug#928957: expiration task fails on non-existent files

[Eduard Bloch]

Package: apt-cacher-ng
Version: 3.2-1
Severity: serious

This bug is basically reminder to myself and not to whoever runs into
this issue.

Looks like apt-cacher-ng expiery manages to maneuver itself into a state
which cannot be recovered. It reports non-existent files from apparently
guessed sources, like:

Error summary:
debrep/dists/jessie/main/installer-amd64/current/images/SHA256SUMS: 404 Not 
Found
debrep/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS: 
404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615+deb9u5+b2/images/SHA256SUMS:
 404 Not Found
localhost/ftp.de.debian.org/debian/dists/stretch/main/installer-amd64/20170615/images/SHA256SUMS:
 404 Not Found

I have a vague idea where it comes from (old heuristics which fetched
voluntarily additional metadata which was not well linked in old Debian
versions, like 10 years ago). This needs to be investigated (digging
through history) and probably removed, or fixed.

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Bug#887932: Same issue

[Julien]

Hi,

I've the same issue since the last update my Intel 8265 card doesn't 
works for bluetooth (wifi works fine).


julien@xh270:~$ sudo dmesg | grep iw
[4.811745] iwlwifi :03:00.0: enabling device ( -> 0002)
[4.825056] iwlwifi :03:00.0: firmware: direct-loading firmware 
iwlwifi-8265-36.ucode
[4.825485] iwlwifi :03:00.0: loaded firmware version 
36.9f0a2d68.0 op_mode iwlmvm
[4.925883] iwlwifi :03:00.0: Detected Intel(R) Dual Band 
Wireless AC 8265, REV=0x230

[4.987903] iwlwifi :03:00.0: base HW address: 34:e1:2d:24:e1:f9
[5.080812] ieee80211 phy0: Selected rate control algorithm 
'iwl-mvm-rs'

[5.087209] iwlwifi :03:00.0 wlp3s0: renamed from wlan0

julien@xh270:~$ sudo lspci -v
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 
78)
	Subsystem: Intel Corporation Wireless 8265 / 8275 (Dual Band 
Wireless-AC 8265)

Flags: bus master, fast devsel, latency 0, IRQ 140
Memory at df00 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 34-e1-2d-ff-ff-24-e1-f9
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

I'm going to try the latest update of the package (in sid).

Bug#928204: lower severity

[Cyril Brulebois]

HoLger,

Holger Levsen  (2019-05-13):
> severity 928204 important
> tags 928204 unreproducible moreinfo
> # thanks
> 
> Kibi,
> 
> #928204 is the bug with the title "check-support-status: cannot create 
> /var/lib/debian-security-support/security-support.semaphore: Directory
> nonexistent"...
> 
> how did you create that chroot? is maybe apparmor involved (in a way
> thats not the default? (guessing based on the hostname in your log.)

debootstrap; I'm running with apparmor=1 but that has absolutely 0
things to do with the hostname (https://en.wikipedia.org/wiki/Armorica).


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#928952: Problems after security update 9.26a~dfsg-0+deb9u3

[Paul van der Vlis]

Op 13-05-19 om 22:42 schreef Salvatore Bonaccorso:

> Do the test packages of
> https://people.debian.org/~carnil/tmp/cups-filters/ for cups filter
> resolve the issue for you?

Yes ;-)

With regards,
Paul van der Vlis



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#928956: Document removal of ecryptfs-utils from Buster

[Daniel Lange]

Package: release-notes
Severity: important

Due to #765854 ecryptfs-utils has been removed from Buster.
The kernel module (ecryptfs.ko) is still built but depending on the 
upgrade path users will be unable to mount their encrypted home 
directories (pam module, ecryptfs-mount-private missing).

So they should probably be strongly advised to not upgrade.

Bug#928947: u-boot: Add support for Pine64 LTS board

[Vagrant Cascadian]

On 2019-05-13, Sunil Mohan Adapa wrote:
> Source: u-boot
> Version: 2019.07-rc1+dfsg-4
...
> It would be nice to have support for the Pine64 LTS board which is different
> from Pine64+ board that is already supported. Upstream u-boot, flash-kernel 
> and
> Debian kernel already have support for the board.

Thanks! Committed to git.

Would you consider testing against u-boot 2019.01+dfsg-* packages in
Debian too, so support could be added for buster?


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#877748: python-sugar3 needs gstreamer1.0-plugins-good for autoaudiosink element

[James Cameron]

This is probably fixed, as 0.112-3 does have dependency on 
gstreamer1.0-plugins-good

Bug#928718: groonga 6.1.5-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

The upload referenced by this bug report has been flagged for acceptance into 
the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: groonga
Version: 6.1.5-1+deb9u1

Explanation: mitigate privilege escalation by changing the owner and group of 
logs with "su" option

Bug#928901: shutdown-qapps FTCBFS: missing Build-Depens: qt5-qmake:native

[Helmut Grohne]

Hi Christian,

On Tue, May 14, 2019 at 12:26:05AM +0900, Christian Metscher wrote:
> There is one thing I'd like to confirm.
> Why is the native in "qt5-qmake:native" needed? Would it be okay to remove it?

The :native is crucial. It determines for which architecture the
dependency is resolved. By default, all Build-Depends are resolved for
the host architecture and :native requests build architecture
resolution. As long as build equals host, there's no difference, but
lrelease always runs the build architecture qmake. Missing the build
architecture qmake yields:

WARNING: Could not find qmake configuration file linux-g++.
lrelease error: cannot process project file 'qprogram-starter.pro'.

See http://crossqa.debian.net/src/shutdown-qapps. After emitting the
message, lrelease exists successfully, which arguably is a Debian policy
section 4.6 violation.

Helmut

Bug#928942:

[Leandro Doctors]

Control: user qa.debian@packages.debian.org
Control: usertags -1 + udd

Bug#928955: RFP: yubikey-manager -- configuration of FIDO2, OTP and PIV functionality for YubiKey devices

[Francois Marier]

Package: wnpp
Severity: wishlist

* Package name: yubikey-manager
  Version : 2.1.0
  Upstream Author : YubiKey
* URL : 
https://www.yubico.com/products/services-software/download/yubikey-manager/
* License : Simplified BSD
  Programming Lang: Python
  Description : configuration of FIDO2, OTP and PIV functionality for 
YubiKey devices

YubiKey Manager (ykman) is a command line tool for configuring a YubiKey over
all transports. It is capable of reading out device information as well as
configuring several aspects of a YubiKey, including enabling or disabling
connection transports an programming various types of credentials.

(This appears to be the successor to yubikey-personalization-gui.)

-- 
https://fmarier.org/

Bug#928952: Problems after security update 9.26a~dfsg-0+deb9u3

[Salvatore Bonaccorso]

Hi Paul,

On Mon, May 13, 2019 at 10:21:21PM +0200, Paul van der Vlis wrote:
> Package: ghostscript
> Version: 9.26a~dfsg-0+deb9u3
> 
> 
> After doing the Ghostscript upgrade from 9.26a~dfsg-0+deb9u2 to
> 9.26a~dfsg-0+deb9u3 cups did not print anymore at a customer PC.
> Downgrading the ghostscript package did help.
> 
> My customer is using a Brother HL-L2365DW connected through USB with
> "Generic PCL6/PCL XL Printer Foomatic/ljet4d" driver.
> 
> My Lexmark x546dtn network printer does work fine using postscript after
> the upgrade, but not using PCL6. I get there:
> Idle - "Filter failed".
> 
> I guess there is something wrong with printing PCL6.

Do the test packages of
https://people.debian.org/~carnil/tmp/cups-filters/ for cups filter
resolve the issue for you?

Regards,
Salvatore

Bug#928204: lower severity

[Holger Levsen]

control: severity -1 serious
thanks

On Mon, May 13, 2019 at 10:19:29PM +0200, Santiago Vila wrote:
> This just happened to me a few minutes ago:
> 
> Setting up debian-security-support (2019.04.25) ...
> /usr/bin/check-support-status: 269: /usr/bin/check-support-status: cannot 
> create
> /var/lib/debian-security-support/security-support.semaphore: Directory 
> nonexistent

ack :/


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

In Europe there are people prosecuted by courts because they saved other people
from drowning in the  Mediterranean Sea.  That is almost as absurd  as if there
were people being prosecuted because they save humans from drowning in the sea.


signature.asc
Description: PGP signature

Bug#928954: unblock: lemonldap-ng/2.0.2+ds-7+deb10u1

[Xavier Guimard]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package lemonldap-ng

Hi all,

during an internal audit, one of lemonldap-ng's developers discovered an
attack vector (#928944, CVE-2019-12046). It opens 3 security issues:
 - [high] for 2.0.0 ≤ version < 2.0.4: when CSRF tokens are
   enabled (default) and tokens are stored in session DB (not default,
   used with poor load-balancers), the token can be used to open an
   anonymous short-life session (2mn). It allows one to access to all
   aplications without additional rules
 - [medium] for every versions < 2.0.4 or 1.9.19 when SAML/OIDC tokens are
   stored in sessions DB (not default), tokens can be used to have an
   anonymous session
 - [low] for every versions < 2.0.4 or 1.9.19: when self-registration
   is allowed, mail token can be used to have an anonymous session.

The patch contains 3 parts:
 - the fix itself:
   * lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
   * lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/OneTimeToken.pm
   * lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Plugins/MailPasswordReset.pm
   * lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/SMTP.pm
 - regressions workaround:
   * REST, SOAP, CDA and "Main::Run" files
   * lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/Remote.pm
 - 3 upstream tests to prove that issues are fixed
   * lemonldap-ng-portal/t/41-Token-Global-Storage.t
   * lemonldap-ng-portal/t/42-Register-Security.t
   * lemonldap-ng-portal/t/77-2F-Mail-with-global-storage.t

lemonldap-ng has no reverse dependencies. Upstream provides more than
9000 unit tests that runs all main features, so I think it low risky to
unblock lemonldap-ng.

Cheers,
Xavier

unblock lemonldap-ng/2.0.2+ds-7+deb10u1

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing'), (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 9bf7afa99..216a6aa65 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+lemonldap-ng (2.0.2+ds-7+deb10u1) unstable; urgency=high
+
+  * Fix tokens security (Closes: #928944, CVE-2019-12046)
+
+ -- Xavier Guimard   Mon, 13 May 2019 21:22:34 +0200
+
 lemonldap-ng (2.0.2+ds-7) unstable; urgency=medium
 
   * Import upstream translations update
diff --git a/debian/patches/CVE-2019-12046.patch 
b/debian/patches/CVE-2019-12046.patch
new file mode 100644
index 0..a1d144478
--- /dev/null
+++ b/debian/patches/CVE-2019-12046.patch
@@ -0,0 +1,530 @@
+Description: Fix for CVE 
+ When CSRF is enabled (default) and tokens are stored in session database
+ (not default, used for poor load balancers), a short-life session can be
+ created without being authentified.
+ This patch fixes also a low level vulnerability on self-register (same vector,
+ see https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1743)
+ .
+ This patch adds also 2 new upstream tests to prove that issues are fixed.
+ .
+ https://security-tracker.debian.org/tracker/CVE-2019-12046
+Author: Xavier Guimard 
+Origin: upstream, https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
+Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
+Bug-Debian: https://bugs.debian.org/928944
+Forwarded: not-needed
+Last-Update: 2019-05-12
+
+--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
 b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
+@@ -21,7 +21,7 @@
+ modified => 0,
+ };
+ foreach (
+-qw(baseUrl user password realm localStorage localStorageOptions 
lwpOpts lwpSslOpts)
++qw(baseUrl user password realm localStorage localStorageOptions 
lwpOpts lwpSslOpts kind)
+   )
+ {
+ $self->{$_} = $args->{$_};
+@@ -116,8 +116,13 @@
+ 
+ sub getJson {
+ my $self = shift;
+-my $url  = shift;
+-my $resp = $self->ua->get( $self->base . $url, @_ );
++my $id   = shift;
++my $resp = $self->ua->get(
++$self->base
++  . $id
++  . ( $self->{kind} ne 'SSO' ? "?kind=$self->{kind}" : '' ),
++@_
++);
+ if ( $resp->is_success ) {
+ my $res;
+ eval { $res = from_json( $resp->content, { allow_nonref => 1 } ) };
+--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
 b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
+@@ -139,6 +139,14 @@
+ 
+ # Load session data into object
+ if ($data) {
++if ( $self->kind and $data->{_session_kind} ) {
++unless ( $data->{_session_kind} eq $self->kind ) {
++$self->error(
++"Session kind mismatch : 

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Steffen Ullrich]

On Mon, May 13, 2019 at 03:18:14PM +0200, Guilhem Moulin  
wrote:
> On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> > Applications which relied on blocking I/O in connection with select could
> > also hang before,
>
> Uh, what?  “Before” meaning with ≤TLSv1.2, or with OpenSSL <1.1.1a's
> default flags?  libssl mentions no such thing beside the new default
> mode.  And in fact the s_client() program, *from OpenSSL upstream
> itself*, does precisely that: a select loop in blocking I/O mode (unless
> the ‘-nbio’ flag is set).

"Before" meaning already with previous OpenSSL versions. But the effect was
likely hard to notice: an incomplete SSL record would not cause a permanent
hang but only a blocking read until the rest of the data was received, i.e.
only some slow down in some situations.

>
> 
> https://github.com/openssl/openssl/blob/OpenSSL_1_1_1/apps/s_client.c#L2817
>
> s_client() is roughly speaking a C version the ‘netcat.pl’ prototype I
> attached earlier.  Unsurprisingly, since 1.1.1a the code clears
> SSL_MODE_AUTO_RETRY from the bitmask mode of the newly created SSL_CTX
> object.  That change was even done in the very same commit that enabled
> SSL_MODE_AUTO_RETRY by default :-)
>
> 
> https://github.com/openssl/openssl/commit/693cf80c6ff54ae276a44d305d4ad07168ec6895#diff-7f3b79983f6d53c047c90a62813cc11f

s_client is just a better test program and not production code which
actually cares about edge cases. And the change was likely needed since
s_client now had serious problems and this was the easiest way to address
these.

> IMHO using polling sockets in blocking I/O is fairly common.  Granted,
> that itself itself doesn't say much about code quality, but the fact that
> the OpenSSL project *does* use it (and explicitly mentions it in the
> docs) gives me confidence that it's a fine use which should still be
> supported.

From my experience with OpenSSL and its documentation I don't agree with
this. Documentation is sometimes wrong or misleading and more often
incomplete (but its actually improving).
And while using blocking I/O with polling sockets might be fine with plain
sockets where each byte is part of application data it is not fine with SSL
since the unit in SSL is not a byte but a record and some records might
contain application data and some not.

> The documentation (libssl's SSL_read()'s [0], Net::SSLeay::read() [1],
> as well as IO::Socket::SSL::sysread() [2]) all warn that reading from an
> SSL socket has a different behavior than usual read(2) system calls, in
> that read failures should be treated with care, as there are both
> retryable (eg. when no application data was received) and non-retryable
> errors.

As I was the one who wrote the documentation for IO::Socket::SSL: the part
about sysread failing was supposed to be about non-blocking sockets. A
blocking socket was not expected to return nothing just because the handshake
was not done.

>
> So from my perspective, the expectation that IO::Socket::SSL::sysread()
> behaves like a “normal” sysread doesn't hold, and never did.  (There is
> even an entry for “Expecting exactly the same behavior as plain
> sockets” in the “Common errors” section of IO::Socket::SSL's manpage!)

This part talks about specific cases and how to deal with these but says
nothing about blocking sockets temporary failing.

> For what it's worth I think it's a shame that SSL_MODE_AUTO_RETRY was
> not the default earlier, as it's convenient to be able to write
>
> $sock->sysread($buf, $len) // die;
>
> and not bother about inspecting $SSL_ERROR.  But programs have been

I agree with that. But in the past SSL_MODE_AUTO_RETRY was only relevant
with unexpected renegotiations which nearly never happened. So nobody
actually noticed.

> written with the old default in mind, and the fact that SSL_read()
> doesn't behave like a normal read() system call.  For these programs to
> keep working, there needs to be a way to switch SSL_MODE_AUTO_RETRY off.
> libssl provides SSL_CTX_clear_mode(), Net::SSLeay has
> CTX_ctrl(,78,SSL_CTRL_CLEAR_MODE,0), and I'd like to have something
> similar in IO::Socket::SSL, too.

I'm not convinced that this is the way to go, i.e. I'd rather see the
applications use non-blocking sockets.  But I'm also not stubbornly
against it.
Do you know a relevant module or actually used application which has
problems because of the default mode of SSL_MODE_AUTO_RETRY the ability to
change it would fix the related problems and not introduce new ones, i.e.
where such a fix would be the right thing to do?
LWP of course does not count since the right thing to do in LWP was to
remove the obsolete patch which kept the socket blocking.

I have also some problems to provide a consistent API for this which can
actually be understood. This would in my opinion mean that I have a clear
default for the value, i.e. that I enable SSL_MODE_AUTO_RETRY by default for
older OpenSSL versions the same way it is done in OpenSSL 1.1.1. But th

Bug#928953: libreoffice: Impossible to move a dialog window

[Michel Le Bihan]

Source: libreoffice
Severity: important

It is impossible to move any dialog window in any OpenOffice application and to
view data that is under it. Moving those windows is necessary to inspect the
data that is under one has selected without closing the window. If the window
is minimized, it might be impossible to reopen it or access the main
application window (it will just be grayed out). Please see the recording:
https://lebihan.pl/files/2019-05-13%2022:07:38.005519.webm



-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (650, 'unstable'), (600, 'experimental'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8), 
LANGUAGE=fr_FR.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#928952: Problems after security update 9.26a~dfsg-0+deb9u3

[Paul van der Vlis]

Package: ghostscript
Version: 9.26a~dfsg-0+deb9u3


After doing the Ghostscript upgrade from 9.26a~dfsg-0+deb9u2 to
9.26a~dfsg-0+deb9u3 cups did not print anymore at a customer PC.
Downgrading the ghostscript package did help.

My customer is using a Brother HL-L2365DW connected through USB with
"Generic PCL6/PCL XL Printer Foomatic/ljet4d" driver.

My Lexmark x546dtn network printer does work fine using postscript after
the upgrade, but not using PCL6. I get there:
Idle - "Filter failed".

I guess there is something wrong with printing PCL6.

Workarround:

apt install libgs9-common=9.26a~dfsg-0+deb9u2 \
 libgs9=9.26a~dfsg-0+deb9u2 ghostscript=9.26a~dfsg-0+deb9u2
systemctl restart cups
make a file /etc/apt/preferences.d/ghostscript for pinning:
---
Package: libgs9-common
Pin: version 9.26a~dfsg-0+deb9u2
Pin-Priority: 1001

Package: libgs9
Pin: version 9.26a~dfsg-0+deb9u2
Pin-Priority: 1001

Package: ghostscript
Pin: version 9.26a~dfsg-0+deb9u2
Pin-Priority: 1001
---
apt update

With regards,
Paul van der Vlis



-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Bug#928204: lower severity

[Santiago Vila]

On Mon, 13 May 2019, Holger Levsen wrote:

> severity 928204 important
> tags 928204 unreproducible moreinfo
> # thanks
> 
> Kibi,
> 
> #928204 is the bug with the title "check-support-status: cannot create 
> /var/lib/debian-security-support/security-support.semaphore: Directory
> nonexistent"...
> 
> how did you create that chroot? is maybe apparmor involved (in a way
> thats not the default? (guessing based on the hostname in your log.)

This just happened to me a few minutes ago:

Setting up debian-security-support (2019.04.25) ...
/usr/bin/check-support-status: 269: /usr/bin/check-support-status: cannot create
/var/lib/debian-security-support/security-support.semaphore: Directory 
nonexistent

My chroot was created with debootstrap, it's a chroot which I use to
build packages, so apparmor is not involved (host machine has stretch).

I'll try to investigate about this after I upload base-files.

Thanks.

Bug#928951: [PATCH 1/1] flash-kernel: Marvell 8040 MACCHIATOBin Double-shot

[Heinrich Schuchardt]

Package: flash-kernel
Version: 3.98
Severity: normal
Tags: patch

The model property in armada-8040-mcbin.dtb has been changed to
'Marvell 8040 MACCHIATOBin Double-shot' in Linux kernel 5.0.

A new board 'Marvell 8040 MACCHIATOBin Single-shot' has been added.

Signed-off-by: Heinrich Schuchardt 
---
 db/all.db | 8 
 1 file changed, 8 insertions(+)

diff --git a/db/all.db b/db/all.db
index 0839d50..f386b75 100644
--- a/db/all.db
+++ b/db/all.db
@@ -945,6 +945,7 @@ U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools

 Machine: Marvell 8040 MACCHIATOBin
+Machine: Marvell 8040 MACCHIATOBin Double-shot
 Machine: Marvell 8040 MACHIATOBin
 Kernel-Flavors: arm64
 DTB-Id: marvell/armada-8040-mcbin.dtb
@@ -952,6 +953,13 @@ Boot-Script-Path: /boot/boot.scr
 U-Boot-Script-Name: bootscr.uboot-generic
 Required-Packages: u-boot-tools

+Machine: Marvell 8040 MACCHIATOBin Single-shot
+Kernel-Flavors: arm64
+DTB-Id: marvell/armada-8040-mcbin-singleshot.dtb
+Boot-Script-Path: /boot/boot.scr
+U-Boot-Script-Name: bootscr.uboot-generic
+Required-Packages: u-boot-tools
+
 # Marvell dev board has different names depending on how it's booted,
 # via DTB or older ATAGS
 Machine: Marvell Armada XP GP Board
--
2.20.1

Bug#928950: unblock: megadown/0~20180705+git83c53dd-1.1

[Boyuan Yang]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: vivia.nikolai...@puri.sm pitsior...@gmail.com

Please unblock megadown 0~20180705+git83c53dd-1.1 . This upload fixes RC bug 
https://bugs.debian.org/927462 which renders the package unusable.

The full debdiff is pasted here.

--
Regards,
Boyuan Yang

diff --git a/debian/changelog b/debian/changelog
index 8f6859f..b6146d2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+megadown (0~20180705+git83c53dd-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick upstream fix on link parsing logic to make the tool
+actually usable. (Closes: #927462)
+
+ -- Boyuan Yang   Mon, 13 May 2019 13:59:17 -0400
+
 megadown (0~20180705+git83c53dd-1) unstable; urgency=medium
 
   * Initial release (Closes: #904702)
diff --git a/debian/patches/0003-File-hex-key-fix.patch b/debian/patches/0003-
File-hex-key-fix.patch
new file mode 100644
index 000..3f9a66d
--- /dev/null
+++ b/debian/patches/0003-File-hex-key-fix.patch
@@ -0,0 +1,26 @@
+From: tonikelope 
+Date: Wed, 17 Apr 2019 12:41:19 +0200
+Subject: File hex key fix
+
+Bug-Debian: https://bugs.debian.org/927462
+Applied-Upstream: 
https://github.com/tonikelope/megadown/commit/734e46fec67a2798bfbb5e21a75f04b90afafd65
+Signed-Off-By: Boyuan Yang 
+
+---
+ megadown | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+diff --git a/megadown b/megadown
+index d928bad..a0c362a 100755
+--- a/megadown
 b/megadown
+@@ -145,8 +145,7 @@ function hrk2hk {
+   declare -A hk
+   hk[0]=$(( 0x${1:0:16} ^ 0x${1:32:16} ))
+   hk[1]=$(( 0x${1:16:16} ^ 0x${1:48:16} ))
+-
+-  printf "%016x" ${hk[*]}
++  printf "%016x%016x" ${hk[0]} ${hk[1]}
+ }
+ 
+ # 1:link
diff --git a/debian/patches/series b/debian/patches/series
index 2f4b7de..9665868 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 use_installed_helpers.patch
 2to3.patch
+0003-File-hex-key-fix.patch


signature.asc
Description: This is a digitally signed message part

Bug#928948: hostapd: syslog is spammed every two seconds

[Andrej Shadura]

Hi,

On Mon, 13 May 2019 at 21:42, sergio  wrote:
> Dear Maintainer,
>
> after installing hostap on debian buster syslog begin sapammed every
> 2 seconds with:
>
> systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling 
> restart.
> systemd[1]: hostapd.service: Scheduled restart job, restart counter is at 72.
> systemd[1]: Stopped Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
> Authenticator.
> systemd[1]: Starting Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
> Authenticator...
> hostapd[3500]: Configuration file: /etc/hostapd/hostapd.conf
> hostapd[3500]: Could not open configuration file '/etc/hostapd/hostapd.conf' 
> for reading.
> hostapd[3500]: Failed to set up interface with /etc/hostapd/hostapd.conf
> hostapd[3500]: Failed to initialize interface
> systemd[1]: hostapd.service: Control process exited, code=exited, 
> status=1/FAILURE
> systemd[1]: hostapd.service: Failed with result 'exit-code'.
> systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 
> 802.1X/WPA/WPA2/EAP Authenticator.

Could you please provide more details?

The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
is not readable or missing, the hostapd.service is masked during the
package installation unless it was already running.

>From what you wrote it sounds like the package hasn’t been installed
before, but then it wouldn’t run by default.

-- 
Cheers,
  Andrej

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

On Mon, 13 May 2019 at 06:31:26 +0200, Steffen Ullrich wrote:
> Additionally switching off SSL_MODE_AUTO_RETRY would actually just add
> a different unexpected behavior: that sysread might return with EAGAIN
> on a blocking socket.

FWIW as shown below that's always been the case, until OpenSSL 1.1.1a
where SSL_MODE_AUTO_RETRY was switched on by default, so I'd say it's
wrong to expect that it won't :-P  Also I'm not arguing that the default
should be toggled back in IO::Socket::SSL, but that it should have a
flag to optionally revert to the old OpenSSL default.

Please consider the following code, which uses blocking I/O and merely
echoes what's being received from the SSL/TLS server.

perl -I. -MIO::Socket::SSL -e '
my $sock = IO::Socket::SSL->new(
PeerAddr => "127.0.0.1:4433",
SSL_ca_file => "/tmp/cert.pem"
) // die;
while(1) {
my $buf = "";
$sock->sysread($buf, 4096) //
die "errno=\"$!\", SSL_ERROR=\"$SSL_ERROR\"\n";
print $buf;
}'

Running in a Stretch chroot (libssl1.1 1.1.0j-1~deb9u1, libnet-ssleay-perl
1.80-1, and IO::Socket::SSL upstream 2.066), it dies with the following
message when the server renegotiates the TLSv1.2 session (“r\n” command
in the `s_server` input):

errno="Resource temporarily unavailable", SSL_ERROR="SSL wants a read first"

That's expected because SSL_read() fails and SSL_get_error() returns
SSL_ERROR_WANT_READ.  That code is broken as it doesn't inspect
$SSL_ERROR on sysread failure, and treats retryable errors as fatal.
With TLSv1.3 (but ensuring SSL_MODE_AUTO_RETRY is still unset) it's way
worse because it dies immediately after the handshake, not “just” when
the session is renegotiated.  In that light it makes sense that the
OpenSSL developers have switched SSL_MODE_AUTO_RETRY on by default.

Now with an OpenSSL version where SSL_MODE_AUTO_RETRY is set by default,
SSL_read() automatically retries and blocks until application data is
received, so the above program keeps looping as expected.  Automatic
retrying in lower-level functions is a fine default, but unfortunately
breaks applications that *were* relying on SSL_read() *not* blocking
when only non-application data was received.  That's why there needs to
be a way to optionally switch it back off.  Changing these programs to
use non-blocking I/O is clearly much more invasive.

> I've added more information regarding this to the IO::Socket::SSL
> documentation:
> https://github.com/noxxi/p5-io-socket-ssl/commit/ee176e489f02bfaaa479fc8d9312c8458bf55565

| A sysread on the IO::Socket::SSL socket will not return any data
| though since it is an abstraction which only returns application data.
| This causes the sysread to hang in case the socket was blocking

As shown above this is incorrect for OpenSSL <1.1.1a's (or any later
OpenSSL version where SSL_MODE_AUTO_RETRY was switched off).  There
IO::Socket::SSL::sysread() doesn't hang, but instead fails immediately
and sets $SSL_ERROR to SSL_ERROR_WANT_READ (and $! to EAGAIN).  While
setting errno to EAGAIN is specific to IO::Socket::SSL (and AFAICT
undocumented for blocking I/O), the manpage for SSL_read() and its higher
level bindings & wrappers, incl. IO::Socket::SSL, explicitly says that
upon failure one should first check SSL_get_error() for SSL-specific
errors, i.e., not rely on the errno value unless the SSL error code is
SSL_ERROR_SYSCALL.  That also applies to blocking I/O.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#928949: unblock: s3ql/3.1+dfsg-2

[David Gilman]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Dear release managers:

s3ql is a FUSE front end for cloud storage providers such as Amazon's
s3, Google Cloud's knockoff of s3 and OpenStack's knockoff of s3.

Users who want to use s3ql with Google's cloud storage API need to
obtain an OAuth credential with the appropriate permissions. s3ql
ships a helper binary s3ql_oauth_client that makes the appropriate API
calls to obtain a token with the correct permissions. Google made
breaking changes to the token's structure and s3ql_oauth_client is no
longer able to create these tokens.

s3ql shipped a fix to s3ql_oauth_client in version 3.1. Please
consider shipping version 3.1 in debian buster so users of s3ql and
Google's cloud storage can obtain valid credentials. If the fix is not
in buster users will be forced to figure out the OAuth flow by
themselves (very painful) or grab a copy of s3ql 3.1 from its upstream
just so they can run s3ql_oauth_client to get a token.

unblock s3ql/3.1+dfsg-2

Bug#927713: CVE-2019-10740

[Salvatore Bonaccorso]

Hi,

On Sun, Apr 21, 2019 at 10:25:22PM +0200, Moritz Muehlenhoff wrote:
> Source: roundcube
> Severity: important
> Tags: security
> 
> This was assigned CVE-2019-10740:
> https://github.com/roundcube/roundcubemail/issues/6638

The issue seems to have been adressed upstream now.

Regards,
Salvatore

Bug#926996: kmail: CVE-2019-10732: decryption based on replying to PGP or S/MIME encrypted emails

[Salvatore Bonaccorso]

Control: tags -1 + fixed-upstream

On Sat, Apr 13, 2019 at 10:31:53AM +0200, Salvatore Bonaccorso wrote:
> Source: kmail
> Version: 4:18.08.3-1
> Severity: important
> Tags: security upstream
> Forwarded: https://bugs.kde.org/show_bug.cgi?id=404698

Discussion on https://bugs.kde.org/show_bug.cgi?id=404698 seems to
indicate the issue is getting resolved upstream.

Regards,
Salvatore

Bug#928948: hostapd: syslog is spammed every two seconds

[sergio]

Package: hostapd
Version: 2:2.7+git20190128+0c1e29f-5
Severity: serious

Dear Maintainer,

after installing hostap on debian buster syslog begin sapammed every
2 seconds with:

systemd[1]: hostapd.service: Service RestartSec=2s expired, scheduling restart.
systemd[1]: hostapd.service: Scheduled restart job, restart counter is at 72.
systemd[1]: Stopped Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
Authenticator.
systemd[1]: Starting Advanced IEEE 802.11 AP and IEEE 802.1X/WPA/WPA2/EAP 
Authenticator...
hostapd[3500]: Configuration file: /etc/hostapd/hostapd.conf
hostapd[3500]: Could not open configuration file '/etc/hostapd/hostapd.conf' 
for reading.
hostapd[3500]: Failed to set up interface with /etc/hostapd/hostapd.conf
hostapd[3500]: Failed to initialize interface
systemd[1]: hostapd.service: Control process exited, code=exited, 
status=1/FAILURE
systemd[1]: hostapd.service: Failed with result 'exit-code'.
systemd[1]: Failed to start Advanced IEEE 802.11 AP and IEEE 
802.1X/WPA/WPA2/EAP Authenticator.

Bug#928947: u-boot: Add support for Pine64 LTS board

[Sunil Mohan Adapa]

Source: u-boot
Version: 2019.07-rc1+dfsg-4
Severity: wishlist
Tags: patch

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

It would be nice to have support for the Pine64 LTS board which is different
from Pine64+ board that is already supported. Upstream u-boot, flash-kernel and
Debian kernel already have support for the board.

The attached patch adds the target. It was tested as follows:

Boot Log
- 

U-Boot SPL 2019.07-rc1+dfsg-4 (May 13 2019 - 03:38:27 +)
DRAM: 2048 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):
NOTICE:  BL3-1: Built : 12:32:39, Apr 11 2018
NOTICE:  DT: sun50i-a64-pine64-lts
INFO:Configuring AXP PMIC
INFO:PMIC: DRAM voltage: 1.24V
INFO:PMIC: setup successful
NOTICE:  SCPI: dummy stub handler, implementation level: 00
INFO:BL3-1: Initializing runtime services
INFO:BL3-1: Preparing for EL3 exit to normal world
INFO:BL3-1: Next image address: 0x4a00, SPSR: 0x3c9


U-Boot 2019.07-rc1+dfsg-4 (May 13 2019 - 03:38:27 +) Allwinner Technology

CPU:   Allwinner A64 (SUN50I)
Model: Pine64 LTS
DRAM:  2 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from FAT... Card did not respond to voltage select!
In:serial
Out:   serial
Err:   serial
Net:   phy interface7
eth0: ethernet@1c3
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1b000: USB EHCI 1.00
Bus usb@1c1b400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1b000 for devices... 1 USB Device(s) found
scanning bus usb@1c1b400 for devices... 1 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
2226 bytes read in 2 ms (1.1 MiB/s)
## Executing script at 4fc0
18560880 bytes read in 926 ms (19.1 MiB/s)
16053 bytes read in 4 ms (3.8 MiB/s)
25179720 bytes read in 1250 ms (19.2 MiB/s)
Booting Debian 4.19.0-5-arm64 from mmc 0:1...
## Flattened Device Tree blob at 4fa0
   Booting using the fdt blob at 0x4fa0
EHCI failed to shut down host controller.
   Loading Ramdisk to 487fc000, end 49fff648 ... OK
   Loading Device Tree to 487f5000, end 487fbeb4 ... OK

Starting kernel ...

[2.670977] sun50i-de2-bus 100.de2: Error couldn't map SRAM to device

Debian GNU/Linux 10 freedombox ttyS0

freedombox login:

Board Model
- ---

root@freedombox:~# cat /sys/firmware/devicetree/base/model
Pine64 LTSroot@freedombox:~#

Package Versions
- 

root@freedombox:~# uname -a
Linux freedombox 4.19.0-5-arm64 #1 SMP Debian 4.19.37-1 (2019-05-05) aarch64
GNU/Linux

root@freedombox:~# dpkg -l u-boot-sunxi
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   VersionArchitecture Description
+++-==-==--=
ii  u-boot-sunxi:arm64 2019.07~rc1+dfsg-4 arm64A boot loader for sunxi
systems

root@freedombox:~# dpkg -l flash-kernel
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  flash-kernel   3.98 arm64utility to make certain embedded
devices bootable

RAM
- ---

root@freedombox:~# free -m
  totalusedfree  shared  buff/cache   available
Mem:   2001 2811177   8 5421632
Swap: 0   0   0

Ethernet Performance
- 

root@freedombox:~# iperf3 -c 10.42.1.1
Connecting to host 10.42.1.1, port 5201
[  5] local 10.42.1.210 port 49568 connected to 10.42.1.1 port 5201
[ ID] Interval   Transfer Bitrate Retr  Cwnd
[  5]   0.00-1.00   sec   109 MBytes   915 Mbits/sec0383 KBytes
[  5]   1.00-2.00   sec   107 MBytes   899 Mbits/sec0383 KBytes
[  5]   2.00-3.00   sec   107 MBytes   897 Mbits/sec0402 KBytes
[  5]   3.00-4.00   sec   107 MBytes   900 Mbits/sec0421 KBytes
[  5]   4.00-5.00   sec   107 MBytes   899 Mbits/sec0421 KBytes
[  5]   5.00-6.00   sec   107 MBytes   900 Mbits/sec   18335 KBytes
[  5]   6.00-7.00   sec   107 MBytes   896 Mbits/sec0376 KBytes
[  5]   7.00-8.00   sec   107 MBytes   896 Mbits/sec0376 KBytes
[  5]   8.00-9.00   sec   108 MBytes   904 Mbits/sec0423 KBytes
[  5]   

Bug#928946: RFP: drupal-console-launcher -- DrupalConsole global executable aka Launcher

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: drupal-console-launcher
  Version : 1.8.0
* URL : https://github.com/hechoendrupal/drupal-console-launcher
* License : GPL
  Programming Lang: PHP
  Description : DrupalConsole global executable aka Launcher

This is a global executable that enables you to run the command, drupal, from
any directory within your site's project. Without it you will be inconvenienced
by having to run the command only from your drupal root directory.

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

On Mon, May 13, 2019 at 08:17:26PM +0100, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 19:08 +, Holger Levsen wrote:
> > reassign -1 base-files
> > retitle -1 base-files: please add a break on d-s-s < 2019.04.25
 
and FWIW and for future releases, I've just now done
https://salsa.debian.org/debian/debian-security-support/commit/970c319393cc1a43d6213b21e92b3ec1c6b77e73
"check-support-status.in: don't fail if security-support-ended.debX does
not exist for the release d-s-s is running on. Closes: #927450." though
I won't upload this immediatly as I'm not sure it's the most ideal fix
for this. Maybe it is though.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#928945: RFP: drush-launcher -- A small wrapper around Drush for your global $PATH

[Pierre Rudloff]

Package: wnpp
Severity: wishlist

* Package name: drush-launcher
  Version : 0.6.0
* URL : https://github.com/drush-ops/drush-launcher
* License : GPL
  Programming Lang: PHP
  Description : A small wrapper around Drush for your global $PATH

By installing the drush launcher globally on your local machine, you can simply
type drush on the command line, and the launcher will find and execute the
project specific version of drush located in your project's vendor directory.

Bug#923031: libopusfile0 multiarch conflict

[John Eikenberry]

Was about to file a bug on this but noticed one was already filed.

Wanted to +1 this though as I'm left with the choice of keeping the old version
of libsdl2-mixer or removing a couple useful packages.

Thanks.

-- 

John Eikenberry
[ j...@zhar.net - http://zhar.net ]

"Perfection is attained, not when no more can be added, but when no more
 can be removed." -- Antoine de Saint-Exupery

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Ben Hutchings]

On Mon, 2019-05-13 at 19:08 +, Holger Levsen wrote:
> reassign -1 base-files
> retitle -1 base-files: please add a break on d-s-s < 2019.04.25
> thanks
> 
> On Mon, May 13, 2019 at 01:00:14PM +0100, Ben Hutchings wrote:
> > On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> > > So I think this can only be fixed properly (=without asking people to
> > > upgrade to the latest stretch pointrelease but instead allowing upgrades
> > > to buster from *any* stretch pointrelease) by adding a "pre-depends:
> > > debian-security-support (>= 2019.04.25)" to base-files in buster.
> > This makes debian-security-support transitively essential, whereas it
> > used to be optional.
> 
> thanks, Ben.
> 
> > Is "Conflicts" not strong enough?
>  
> after re-reading
> https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
> and
> https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
> (policy 7.3 and 7.4) I now also think that a "Breaks:
> debian-security-support (>= 2019.04.25)" in src:base-files is in order.

After re-reading, I concur that "Breaks" should be sufficient.  But
please do test this!

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.




signature.asc
Description: This is a digitally signed message part

Bug#928172: fixing debian-security-support upgrades from stretch (for good)

[Holger Levsen]

reassign -1 base-files
retitle -1 base-files: please add a break on d-s-s < 2019.04.25
thanks

On Mon, May 13, 2019 at 01:00:14PM +0100, Ben Hutchings wrote:
> On Mon, 2019-05-13 at 11:52 +, Holger Levsen wrote:
> > So I think this can only be fixed properly (=without asking people to
> > upgrade to the latest stretch pointrelease but instead allowing upgrades
> > to buster from *any* stretch pointrelease) by adding a "pre-depends:
> > debian-security-support (>= 2019.04.25)" to base-files in buster.
> This makes debian-security-support transitively essential, whereas it
> used to be optional.

thanks, Ben.

> Is "Conflicts" not strong enough?
 
after re-reading
https://www.debian.org/doc/debian-policy/ch-relationships.html#packages-which-break-other-packages-breaks
and
https://www.debian.org/doc/debian-policy/ch-relationships.html#conflicting-binary-packages-conflicts
(policy 7.3 and 7.4) I now also think that a "Breaks:
debian-security-support (>= 2019.04.25)" in src:base-files is in order.

Thanks.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

we'll all die. make a difference while you can. disobey. smile.


signature.asc
Description: PGP signature

Bug#928944: CVE-2019-12046: lemonldap-ng tokens allows anonymous session when stored in session DB

[Xavier]

Package: liblemonldap-ng-portal-perl
Severity: grave
Tags: security upstream patch
Justification: user security hole
Forwarded: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Found: 1.9.7-3

Hi all,

during an internal audit, one of lemonldap-ngi's developers discovered an
attack vector. It opens 3 security issues:
 - [high] for 2.0.0 ≤ version < 2.0.4: when CSRF tokens are
   enabled (default) and tokens are stored in session DB (not default,
   used with poor load-balancers), the token can be used to open an
   anonymous short-life session (2mn). It allows one to access to all
   aplications without additional rules
 - [high] for every versions < 2.0.4 or 1.9.19 when SAML/OIDC tokens are
   stored in sessions DB (not default), tokens can be used to have an
   anonymous session
 - [low] for every versions < 2.0.4 or 1.9.19: when self-registration
   is allowed, mail token can be used to have an anonymous session.

Attachements:
 - lemonldap-ng_2.0.2+ds-6.debdiff: fix for stretch
 - lemonldap-ng_2.0.2+ds-7.patch: patch for Buster. It includes 3 new
   upstream tests to prove that vulnerabilities are fixed
 - llng-1742-test.sh: a small tool that can be used to test an existing
   2.0.x installation

This issue also affects Ubuntu-19.04 which includes lemonldap-ng_2.0.2+ds-6.

Cheers,
Xavier

Description: Fix for CVE 
 When CSRF is enabled (default) and tokens are stored in session database
 (not default, used for poor load balancers), a short-life session can be
 created without being authentified.
 This patch fixes also a low level vulnerability on self-register (same vector,
 see https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1743)
 .
 This patch adds also 2 new upstream tests to prove that issues are fixed.
 .
 https://security-tracker.debian.org/tracker/CVE-2019-12046
Author: Xavier Guimard 
Origin: upstream, https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug: https://gitlab.ow2.org/lemonldap-ng/lemonldap-ng/issues/1742
Bug-Debian: https://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded: not-needed
Last-Update: 2019-05-12

--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Apache/Session/REST.pm
@@ -21,7 +21,7 @@
 modified => 0,
 };
 foreach (
-qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts)
+qw(baseUrl user password realm localStorage localStorageOptions lwpOpts lwpSslOpts kind)
   )
 {
 $self->{$_} = $args->{$_};
@@ -116,8 +116,13 @@
 
 sub getJson {
 my $self = shift;
-my $url  = shift;
-my $resp = $self->ua->get( $self->base . $url, @_ );
+my $id   = shift;
+my $resp = $self->ua->get(
+$self->base
+  . $id
+  . ( $self->{kind} ne 'SSO' ? "?kind=$self->{kind}" : '' ),
+@_
+);
 if ( $resp->is_success ) {
 my $res;
 eval { $res = from_json( $resp->content, { allow_nonref => 1 } ) };
--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session.pm
@@ -139,6 +139,14 @@
 
 # Load session data into object
 if ($data) {
+if ( $self->kind and $data->{_session_kind} ) {
+unless ( $data->{_session_kind} eq $self->kind ) {
+$self->error(
+"Session kind mismatch : $data->{_session_kind} is not "
+  . $self->kind );
+return undef;
+}
+}
 $self->_save_data($data);
 $self->kind( $data->{_session_kind} );
 $self->id( $data->{_session_id} );
@@ -158,7 +166,7 @@
 if ( $self->storageModule =~ /^Lemonldap::NG::Common::Apache::Session/ )
 {
 tie %h, $self->storageModule, $self->id,
-  { %{ $self->options }, %$options };
+  { %{ $self->options }, %$options, kind => $self->kind };
 }
 else {
 tie %h, 'Lemonldap::NG::Common::Apache::Session', $self->id,
--- a/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session/REST.pm
+++ b/lemonldap-ng-common/lib/Lemonldap/NG/Common/Session/REST.pm
@@ -248,7 +248,7 @@
   Lemonldap::NG::Handler::PSGI::Main->tsv->{sessionCacheOptions},
 id=> $id,
 force => $force,
-kind  => $mod->{kind},
+( $id ? () : ( kind => $mod->{kind} ) ),
 ( $info ? ( info => $info ) : () ),
 }
 );
@@ -271,6 +271,9 @@
 $self->error('Unknown (or unconfigured) session type');
 return ();
 }
+if ( my $kind = $req->params('kind') ) {
+$m->{kind} = $kind;
+}
 return $m;
 }
 
--- a/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/OneTimeToken.pm
+++ b/lemonldap-ng-portal/lib/Lemonldap/NG/Portal/Lib/OneTimeToken.pm
@@ -5,7 +5,7 @@
 use JSON qw(from_json to_json);
 use Crypt::URandom;
 
-our $VERSION = '2.0.2';
+our $VERSION = '2.0.4';
 
 

Bug#928943: cryptsetup-initramfs: Error message during boot: Couldn't find device with uuid

[Christof Baumann]

Package: cryptsetup-initramfs
Version: 2:2.1.0-3
Severity: minor
Tags: patch

Hi,

my root partition resides on an lvm logical volume which is part
of a volume group consisting of two physical volumes.
Both physical volumes are encrypted with luks.
In order to activate the lvm volume group both physical volumes
need to be unlocked so I added them both to /etc/crypttab.
This works fine except that the following error messages
are output on every boot by the initramfs script local-top/cryptroot:

Couldn't find device with uuid xx------xx.
Refusing activation of partial LV vgroup0/lv0. Use '--activationmode partial'
to override.

In order to get rid of this I changed the script to only attempt
activation of lvm volume groups after all the disks in /etc/crypttab
have been unlocked.

The check for dm-crypt devices needs to stay in the first pass as this
is part of the unlocking procedure but the lvm volume group activation
can be moved to a second step.
Like this the above error messages are gone and I couldn't think
of anything that would now go wrong because of that.

Cheers,
Christof



-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cryptsetup-initramfs depends on:
ii  busybox 1:1.30.1-4
ii  cryptsetup-run  2:2.1.0-3
ii  initramfs-tools [linux-initramfs-tool]  0.133

Versions of packages cryptsetup-initramfs recommends:
ii  console-setup  1.191
ii  kbd2.0.4-4

cryptsetup-initramfs suggests no packages.

-- no debconf information
>From 422096ea74e4adbcbb28ad1e61ffa16971c05cf8 Mon Sep 17 00:00:00 2001
From: Christof Baumann 
Date: Wed, 8 May 2019 20:30:55 +0200
Subject: [PATCH] Activate LVM vgroups after unlocking all mappings

Because an lvm volume group may be composed by several mappings.
In this case this lead to an error message like this:

Couldn't find device with uuid xx------xx.
Refusing activation of partial LV . Use '--activationmode partial'

The boot was still successful in this case as we try activating the volume
group after every successful mapping setup.
However as this was output on stderr it changed the boot screen behavior
in my case: the systemd messages which are normally suppressed with the
quiet grub option are then output.

So I propose to only activate lvm volume groups after having unlocked
all crypttab entries.
---
 debian/initramfs/scripts/local-top/cryptroot | 50 ++--
 1 file changed, 35 insertions(+), 15 deletions(-)

diff --git a/debian/initramfs/scripts/local-top/cryptroot 
b/debian/initramfs/scripts/local-top/cryptroot
index 6a831cd3..304b1317 100644
--- a/debian/initramfs/scripts/local-top/cryptroot
+++ b/debian/initramfs/scripts/local-top/cryptroot
@@ -71,10 +71,10 @@ wait_for_source() {
 return 1
 }
 
-# setup_mapping()
-#   Set up a crypttab(5) mapping defined by $CRYPTTAB_NAME,
+# open_mapping()
+#   Open (unlock) a crypttab(5) mapping defined by $CRYPTTAB_NAME,
 #   $CRYPTTAB_SOURCE, $CRYPTTAB_KEY, $CRYPTTAB_OPTIONS.
-setup_mapping() {
+open_mapping() {
 local dev
 
 # The same target can be specified multiple times
@@ -124,7 +124,7 @@ setup_mapping() {
 fi
 
 get_crypt_type # set CRYPTTAB_TYPE to the type of crypt device
-local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" fstype vg rv
+local count=0 maxtries="${CRYPTTAB_OPTION_tries:-3}" fstype rv
 while [ $maxtries -le 0 ] || [ $count -lt $maxtries ]; do
 if [ -z "${CRYPTTAB_OPTION_keyscript+x}" ] && [ "$CRYPTTAB_KEY" != 
"none" ]; then
 # unlock via keyfile
@@ -145,8 +145,8 @@ setup_mapping() {
 return 1
 fi
 
-if ! fstype="$(get_fstype "$dev")" || [ "$fstype" = "unknown" ]; then
-if [ "$CRYPTTAB_TYPE" != "luks" ]; then
+if [ "$CRYPTTAB_TYPE" != "luks" ]; then
+if ! fstype="$(get_fstype "$dev")" || [ "$fstype" = "unknown" ]; 
then
 # bad password for plain dm-crypt device?  or mkfs not run yet?
 cryptsetup_message "ERROR: $CRYPTTAB_NAME: unknown fstype, bad 
password or options?"
 wait_for_udev 10
@@ -154,17 +154,9 @@ setup_mapping() {
 sleep 1
 continue
 fi
-elif [ "$fstype" = lvm2 ]; then
-if [ ! -x /sbin/lvm ]; then
-cryptsetup_message "WARNING: $CRYPTTAB_NAME: lvm is not 
available"
-return 1
-elif vg="$(lvm pvs --noheadings -o vg_name --config 
'log{prefix=""}' -- "$dev")"; then
-# activate the

Bug#928942: udd: cannot import database dump into PostgreSQL ("function release_name(text) does not exist")

[Leandro Doctors]

Package: qa.debian.org
Severity: grave
Justification: causes non-serious data loss


Dear Maintainer,

(Sorry for any format error in this bug. I tried to use "reportbug",
but it gave me so many problems I gave up and ended up creating this
manually...)


I am trying to create a replica from the public dump of the UDD on my
local PostgreSQL server.
As recommended in the UDD README, I am following the instructions from
https://salsa.debian.org/qa/udd/blob/master/vagrant/provision.sh

Specifically, I do as follows.

0) Install the appropriate dependencies, per the same provision.sh file:
(See details at the bottom of this message.)
Apart from avoiding to install the unneeded 'apache2', the only
relevant difference is the PostgreSQL version - I use Buster's version
11, instead of Stretch's 9.6. However, I doubt this would affect
this...

apt install -y apache2 postgresql postgresql-plperl-9.6
postgresql-9.6-debversion ruby-debian ruby-oj rsync python-yaml
python-psycopg2 ruby-pg ruby-sequel-pg

1) Start the PostgreSQL service
sudo service postgresql start

2) Create the 'udd' database (If I don't, I cannot restore the dump)
sudo -u postgres createdb -T template0 -E SQL_ASCII udd

3) Add 'debversions' extension to the database (If I don't, I get a
lot of errors)
psql udd -c 'create extension debversion'

4) Make my local user the owner of the database
sudo -u postgres psql -c 'alter database udd owner to allentiak'

5) Grant permissions (as the provision script)
sudo -u postgres psql udd -c 'GRANT usage on schema public to public'
sudo -u postgres psql udd -c 'grant select on all tables in schema
public to public'

6) Finally, I import the dump
sudo -u postgres pg_restore -j 8 --no-owner -v -C -d postgres
udd.dump.2019.05.06.dump


After step 6, I get the following error:

```
pg_restore: launching item 4101 MATERIALIZED VIEW DATA tmp
pg_restore: creating MATERIALIZED VIEW DATA "public.tmp"
pg_restore: [archiver (db)] Error from TOC entry 4101; 0 91852869
MATERIALIZED VIEW DATA tmp udd
pg_restore: [archiver (db)] could not execute query: ERROR:
function release_name(text) does not exist
LINE 1: SELECT release_name($1)
   ^
HINT:  No function matches the given name and argument types. You
might need to add explicit type casts.
QUERY:  SELECT release_name($1)
CONTEXT:  PL/pgSQL function public.bugs_rt_affects_dist(text) line
4 during statement block local variable initialization
Command was: REFRESH MATERIALIZED VIEW public.tmp;

[...]

pg_restore: finished item 4101 MATERIALIZED VIEW DATA tmp
pg_restore: finished main parallel loop
WARNING: errors ignored on restore: 4
```

On the one hand, it looks as if the 'release_name(text)' function was
used before def (if such a thing is possible in Pg/SQL)... However,
this dupm was created automatically...

On the other hand, I am aware of #899307, involving 'SELECT' statemets
when using 'ruby-sequel-pg'. However, there are plenty of SELECT
statements in the dump file, and only one of them seems to fail...



-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8),
LANGUAGE=en_IE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


Versions of packages postgresql depends on:
ii  postgresql-11  11.2-2

postgresql recommends no packages.

Versions of packages postgresql suggests:
pn  postgresql-doc  

Versions of packages postgresql-11 depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgcc11:8.3.0-7
ii  libgssapi-krb5-2   1.17-2
ii  libicu63   63.1-6
ii  libldap-2.4-2  2.4.47+dfsg-3
ii  libllvm7   1:7.0.1-8
ii  libpam0g   1.3.1-5
ii  libpq5 11.2-2
ii  libselinux12.8-1+b1
ii  libssl1.1  1.1.1b-2
ii  libstdc++6 8.3.0-7
ii  libsystemd0241-3
ii  libuuid1   2.33.1-0.1
ii  libxml22.9.4+dfsg1-7+b3
ii  libxslt1.1 1.1.32-2
ii  locales2.28-10
ii  postgresql-client-11   11.2-2
ii  postgresql-common  200+deb10u1
ii  ssl-cert   1.0.39
ii  tzdata 2019a-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages postgresql-11 recommends:
ii  sysstat  12.0.3-2

postgresql-11 suggests no packages.


Versions of packages postgresql-11-debversion depends on:
ii  libapt-pkg5.0  1.8.1
ii  libc6  2.28-10
ii  postgresql-11  11.2-2

postgresql-11-debversion recommends no packages.

postgresql-11-debversion suggests no packages.


Versions of packages pyt

Bug#914714: reproducible builds: vary binary-arch and binary-indep vs binary builds

[Holger Levsen]

Hi Vagrant,

On Mon, May 13, 2019 at 10:12:32AM -0700, Vagrant Cascadian wrote:
> From a quick glance at the jenkins code it looks feasible to implement
> the split arch:all and arch:any build, but what's unclear is how to
> compare a single arch:all+any .buildinfo against two .buildinfo files
> (arch:all and arch:any).
> 
> Maybe something like "mergechanges" applied to .buildinfo files?
 
maybe, yes.

> > instead of making our rebuilds in the lab more efficient/complicated,
> > I'd rather spend time on working rebuilding against the actual debian
> > archive, based on the published .buildinfo files from these builds.
> This also would be very helpful...

the quoted bit from me is still very true.

> A problem I'm facing, having introduced a change in u-boot that now
> builds an arch:all package that only builds on amd64/i386, but has
> significantly different arch:any packages for arm64/armhf that really
> should get tested.
> 
> Maybe we should only test arch:all on amd64? Though that's edging into a
> different kind of bug entirely.

that and I'm not sure how much your desired way of testing u-boot
is generally useful.

> That seems pretty doable; amd64+i386 would be the easiest but perhaps
> least interesting to test...  or testing four consecutive builds across
> all four architectures... that seems almost too adventurous! Especially
> given that some packages only build arch:all on specific architectures.

again: I'd like to rebuild against the actual archive (first, before I'd
working on improve our 'theoretical testlab' again). That said, as
always, patches welcome and existing patches I'll likely happily merge.

I'm sorry to sound so "negative", I'd just like to focus on the actual
rebuilder thing. Which *is* shaping up, just slower than I'd like.


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#927723: sway: Please upload new upstream version

[Birger Schacht]

Hi,

On 5/13/19 6:46 PM, iskre...@mail.bg wrote:
> What is needed to be done as of now so the final version (1.0) get into the
> experimental repository ? 

As mentioned above, sway 1.0 needs wlroots 0.5 which is not in
experimental yet (it is in NEW though).

cheers,
Birger

Bug#928718: stretch-pu: groonga/6.1.5-1+deb9u1

[Adam D. Barratt]

On Sat, 2019-05-11 at 22:57 +0900, Kentaro Hayashi wrote:
> Hi,
> 
> It should be stretch-proposed-updates instead stretch.

No, "stretch" was correct, as per Salvatore's mail in #928304 and the
link I pointed you to.

Regards,

Adam

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Holger Levsen]

Hi,

On Thu, May 09, 2019 at 07:24:56PM +0200, Salvatore Bonaccorso wrote:
> > On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote:
> > > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > > wrote:
> > > > > 
> > > > >Perhaps the simplest and more correct might be to name it using
> > > > >something like source+amd64 as the arch name, which seems like a
> > > > >dubious arch, but at least is accurate and might be trivial to
> > > > >implement, taking care of not ending up with such fake arch in
> > > > >unexpected places…
> > > > > 
> > > > > and I cannot find anything wrong with this simple solution and have
> > > > > already asked Guillem in August to implement this ;)
> > > > 
> > > > So, as I mentioned at the time this would require modifing the internal
> > > > filtering of the debian/files entries to cover this case in several of
> > > > the tools. It also modifies the documented filename pattern in
> > > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > > But this breaks previous public filename "interfaces", seems rather
> > > > intrusive, and entirely inappropriate for a stable update, which means
> > > > it would not fix your immediate problems anyway, only starting with
> > > > Buster. :/
> > > Although this would not help us for stretch-security uploads, such a
> > > move starting from buster would be very appreciated!

Guillem, back in November Salvatore said they would appreciate this
"source+amd64 as the arch name" solution for this bug (see above), while
now (because nothing happened I believe) he suggests disabling source
all uploads for security builds, which IMO would be a *very* bad and sad
outcome, as I believe source only security uploads are even more desired
than regular source only uploads...

> We regularly get biten by this issue when contributors to security
> uploads, most recently with the bind9 upload but as well others.
> 
> Would it be possible to at least workaround this on dak's side?
> Disabling source-only uploads completely would seem to be a step back
> on that regards.
> 
> Though if that's the only way  out of having to regularly fetch the
> rejected builds, do manual renamings and resigning and reuploading of
> files, then we should then just disable source-only uploads for the
> security suites again.
> 
> So I think we pretty much would prefer to be able to continue so.
> 
> Just to be clear, thanks a lot for your work, this is not meant as
> critique, just hilighting that we have recurring issues due to this
> bug when people perform uploads for security.

sigh, understandable...


-- 
tschau,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#928939: unblock: hello/2.10-2

[Niels Thykier]

Control: tags -1 moreinfo confirmed

Santiago Vila:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Hello. I'm asked to make a release of hello to fix the version skew
> created by the test security upload for stretch. Since this package
> serves as example, there are several things that I could fix as well,
> but I consider "safe enough" the ones in this debdiff.
> 
> This is not uploaded yet. Waiting for approval.
> 
> Thanks.
> 
> [...]
> 

Please go ahead with the upload and remove the moreinfo tag once it is
uploaded and ready to be unblocked.

Thanks,
~Niels

Bug#928941: HOME and TERM are stripped by mistake

[Alf Gaida]

Package: lxqt-sudo
Version: 0.14.1-1
Severity: critical
Tags: patch

Configurations are written into wrong directories etc - not funny,
if a programm is called with lxsudo again the false written config
will be read, if called with a right working (graphical) sudo not.

Informations written into wrong directories might cause security
breaches.

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.1-towo.1-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages lxqt-sudo depends on:
ii  libc6   2.28-10
ii  liblxqt00.14.2~12-ga398a7c-1
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-7

Versions of packages lxqt-sudo recommends:
ii  lxqt-qtplugin   0.14.1~8-g02a9e71-1
ii  lxqt-sudo-l10n  0.14.1-1

lxqt-sudo suggests no packages.

-- no debconf information

Bug#928940: unblock: ruby2.5/2.5.5-2

[Antonio Terceiro]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ruby2.5. The latest uploaded fixes the one
pending RC bug. The fix is pretty simple, just putting 2 files in the
correct location.

the diff:

8<8<8<-
diff --git a/debian/changelog b/debian/changelog
index 370de1ed..5cab009b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ruby2.5 (2.5.5-2) unstable; urgency=medium
+
+  * debian/tests/excludes/: fix exclusion of Rinda tests that depend on
+network availability, by moving the existing excludes files to the correct
+location. (Closes: #927122)
+
+ -- Antonio Terceiro   Mon, 13 May 2019 10:55:06 -0300
+
 ruby2.5 (2.5.5-1) unstable; urgency=medium
 
   * New upstream version 2.5.5. Includes a series of bug fixes, most notably
diff --git a/debian/tests/excludes/any/TestRingFinger.rb 
b/debian/tests/excludes/any/Rinda/TestRingFinger.rb
similarity index 100%
rename from debian/tests/excludes/any/TestRingFinger.rb
rename to debian/tests/excludes/any/Rinda/TestRingFinger.rb
diff --git a/debian/tests/excludes/any/TestRingServer.rb 
b/debian/tests/excludes/any/Rinda/TestRingServer.rb
similarity index 100%
rename from debian/tests/excludes/any/TestRingServer.rb
rename to debian/tests/excludes/any/Rinda/TestRingServer.rb
8<8<8<-


unblock ruby2.5/2.5.5-2

-- System Information:
Debian Release: 10.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
'unstable'), (500, 'testing'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled


signature.asc
Description: PGP signature

Bug#928887: hello: version skew: 2.10-1+deb9u1 (stretch-security) > 2.10-1 (buster)

[Santiago Vila]

tags 928887 + pending
thanks

I've asked release.debian.org for permission to do very minimal
changes in addition to the dummy upload (see #928939 for details).

Thanks.

Bug#928889: debhelper: dh_autoreconf says "sh: 1: build-aux/git-version-gen: not found"

[Santiago Vila]

On Sun, May 12, 2019 at 04:57:00PM +, Niels Thykier wrote:

> > I tried using compat version 12 in package "hello" and this is what 
> > happened:
> 
> For reference/FYI, I suspect this will happen already at compat 10 or
> later (I noted that hello in sid uses compat 9 and compat 10 is the
> first to use dh_autoreconf by default).

Yes, indeed.

> I think this is because of two things:
> 
>  1) The source does not include build-aux/git-version-gen
>  2) The configure.ac references build-aux/git-version-gen and appears
> to use it unconditionally[1]
> 
> So when dh_autoreconf does its job of regenerating the build scripts
> from configure.ac, then it will trigger those warnings because of the
> above.  I.e. this is a "hello"-specific issue.
> 
> Not sure what the proper fix is here.  Options include:
> 
>  * Have upstream include build-aux/git-version-gen in the source
>- Though it may need git and a git repo to work properly, so this
>  might only make sense from the PoV of ensuring that we have the
>  complete source of the build scripts.
> 
>  * Patch configure.ac to *not* rely on the build-aux/git-version-gen
>script
> 
>  * Skip reconfiguration by overriding dh_autoreconf (see [2] as an
>example).

I tried the third option (skip dh_autoreconf), then I realized that
debhelper passes options to ./configure which the current configure
script does not understand yet because it's too old.

So I decided to keep compat version 9 for now. Next step should be
to ask upstream hello for a new release using updated tools, as I believe
the initial weird message I reported is not common in other packages.

Thanks a lot.

Bug#914714: reproducible builds: vary binary-arch and binary-indep vs binary builds

[Vagrant Cascadian]

On 2018-11-26, Holger Levsen wrote:
> On Mon, Nov 26, 2018 at 05:18:15PM +0100, Ivo De Decker wrote:
>> Please consider having the first build do separate binary-arch and
>> binary-indep builds and having the second build do a full binary build (with
>> arch and indep binaries in the same build run).
>> 
>> Rationale:
>> 
>> - Some packages might produce different binaries in both of these scenario's.
>> - The buildds run separate binary-arch and binary-indep builds, so this 
>> brings
>>   the reproducible builds infrastructure closer to what is done on the
>>   buildds, while still testing the full build (which is probably more common
>>   for maintainer uploads, which unfortunately still exist).
>
> that's something I like.
>
>> - Some packages might fail in on of these scenario's, but not in the other.
>>   This could happen because the build-deps-{arch,indep} are not correct, or
>>   because the build process is different.
>> - R-b tests the full build on all architectures that are tested. The
>>   binary-indep build on the buildds happens only on amd64, and we generally
>>   consider it to be acceptable if arch:all binaries can only be built on some
>>   architectures. By separating the builds, packages that fail to build the
>>   binary-indep target on some architectures can be clearly identified.
>
> that's something I dont really like. (because it has cognitive and other
> costs for us (working on r-b).)
>
> But still, the first quoted block convinced me that it's worthwhile to
> do. Just I'm not sure when, so I'd definitly accept patches.

From a quick glance at the jenkins code it looks feasible to implement
the split arch:all and arch:any build, but what's unclear is how to
compare a single arch:all+any .buildinfo against two .buildinfo files
(arch:all and arch:any).

Maybe something like "mergechanges" applied to .buildinfo files?


>> The process could maybe even be extended somewhat further in the last case.
>> For those packages, the second build could run the binary-arch target again.
>
> instead of making our rebuilds in the lab more efficient/complicated,
> I'd rather spend time on working rebuilding against the actual debian
> archive, based on the published .buildinfo files from these builds.

This also would be very helpful...

A problem I'm facing, having introduced a change in u-boot that now
builds an arch:all package that only builds on amd64/i386, but has
significantly different arch:any packages for arm64/armhf that really
should get tested.

Maybe we should only test arch:all on amd64? Though that's edging into a
different kind of bug entirely.


> But this is my POV, if someone wants to implement this, I'd very
> probably take those patches.
>
>> That would allow packages to be tested for reproducibility even on
>> architectures where the binary-arch (or binary) target doesn't work. 
>> Obviously
>> this would be more complicated to implement. It also would require a double
>> state to keep track of this (FTBFS for binary/binary-indep and a secondary
>> state for binary-arch). This is probably only useful if a simple
>> implementation shows that this is common.
>
> we btw also need / should check, whether arch:all rebuilds on different
> arch have reproducible results...

That seems pretty doable; amd64+i386 would be the easiest but perhaps
least interesting to test...  or testing four consecutive builds across
all four architectures... that seems almost too adventurous! Especially
given that some packages only build arch:all on specific architectures.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928939: unblock: hello/2.10-2

[Santiago Vila]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hello. I'm asked to make a release of hello to fix the version skew
created by the test security upload for stretch. Since this package
serves as example, there are several things that I could fix as well,
but I consider "safe enough" the ones in this debdiff.

This is not uploaded yet. Waiting for approval.

Thanks.

diff -Nru hello-2.10/debian/changelog hello-2.10/debian/changelog
--- hello-2.10/debian/changelog 2015-03-22 11:56:16.0 +0100
+++ hello-2.10/debian/changelog 2019-05-12 22:26:59.0 +0200
@@ -1,3 +1,12 @@
+hello (2.10-2) unstable; urgency=medium
+
+  * Fix version skew. Closes: #928887.
+  * Drop debian/compat and use new syntax to specify compat level.
+  * Standards-Version: 4.3.0 (no changes for this).
+  * Rules-Requires-Root: no
+
+ -- Santiago Vila   Sun, 12 May 2019 20:26:59 +
+
 hello (2.10-1) unstable; urgency=low
 
   * New upstream release.
diff -Nru hello-2.10/debian/compat hello-2.10/debian/compat
--- hello-2.10/debian/compat2015-03-22 11:00:00.0 +0100
+++ hello-2.10/debian/compat1970-01-01 01:00:00.0 +0100
@@ -1 +0,0 @@
-9
diff -Nru hello-2.10/debian/control hello-2.10/debian/control
--- hello-2.10/debian/control   2015-03-22 11:00:00.0 +0100
+++ hello-2.10/debian/control   2019-05-12 22:26:59.0 +0200
@@ -2,9 +2,10 @@
 Section: devel
 Priority: optional
 Maintainer: Santiago Vila 
-Standards-Version: 3.9.6
-Build-Depends: debhelper (>= 9.20120311)
+Standards-Version: 4.3.0
+Build-Depends: debhelper-compat (= 9)
 Homepage: http://www.gnu.org/software/hello/
+Rules-Requires-Root: no
 
 Package: hello
 Architecture: any

Bug#928938: cronic: Add option to report on return status only

[Dave Page]

Package: cronic
Version: 3-1
Severity: wishlist
Tags: patch upstream

Dear Maintainer,

An increasing number of applications we use through cron are putting
debug output on STDERR while returning 0 by default, and cannot be
quietened. Examples include docker and gitlab maintenance

We have locally patched our cronic to support an option, -r, which will
cause cronic to only generate a report if the return code is nonzero,
even if there is STDERR output. We submit it for your consideration.

-- System Information:
Debian Release: 9.9
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages cronic depends on:
ii  bash  4.4-5

cronic recommends no packages.

Versions of packages cronic suggests:
ii  cron  3.0pl1-128+deb9u1

-- no debconf information
--- cronic.orig 2019-05-13 17:46:13.150590183 +0100
+++ cronic  2019-05-13 17:19:01.098080693 +0100
@@ -11,6 +11,18 @@
 ERR=$TMP/cronic.err
 TRACE=$TMP/cronic.trace
 
+CRONIC_RESULT_ONLY=""
+
+# Go over $@ to look for - parameters
+while getopts r opt; do
+  case $opt in
+r)
+  CRONIC_RESULT_ONLY="yes"
+  ;;
+  esac
+done
+shift "$((OPTIND-1))"
+
 set +e
 "$@" >$OUT 2>$TRACE
 RESULT=$?
@@ -24,7 +36,7 @@
 ERR=$TRACE
 fi
 
-if [ $RESULT -ne 0 -o -s "$ERR" ]
+if [[ -n "$CRONIC_RESULT_ONLY" && $RESULT -ne 0 ]] || [[ -z 
"$CRONIC_RESULT_ONLY" && ( $RESULT -ne 0 || -s "$ERR" ) ]]
 then
 echo "Cronic detected failure or error output for the command:"
 echo "$@"

Bug#927723: sway: Please upload new upstream version

[iskrenx2]

Hello, how can I help with this ? 


What is needed to be done as of now so the final version (1.0) get into the
experimental repository ? 


Thank you. 




-

П.П. Видя ли, дори Радостина има сайт. Радостина, която опазва 
източнобалканската свиня. Направи си сайт и ти. Виж как на www.superhosting.bg
 
https://www.superhosting.bg/?utm_source=mbg&utm_medium=cpm&utm_content=mail_footer&utm_campaign=newuser_campaign2019

Bug#928750: - Bug in grubx64.efi triggered by shim?

[Steve McIntyre]

Hi Michael!

On Mon, May 13, 2019 at 10:34:46AM +0200, Michael Kesper wrote:
>
>Is it possible that the erroneous behaviour of grubx64.efi (not loading its 
>config
>files when being loaded by bootnetx64.efi aka shim-signed) gets triggered by
>how the shim calls grubx64?
>With Debian 9, the same setup (boot the installer via UEFI PXE) worked.
>
>References:
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928750
>  https://lists.debian.org/debian-boot/2019/05/msg00076.html
>  https://lists.debian.org/debian-boot/2019/05/msg00084.html

Ah. Apologies, you've clearly found a bug in our setup. :-(

It looks like what you're seeing is that the signed grub image is
using a different $prefix setting, and now it needs help to find the
grub.cfg file.

The debian-installer build used to rebuild its own grub EFI image and
change some config during that build (using -p
"$netboot_prefix/grub"), but now we can't do that (as it would lose
the signature). We need to update our netboot tree and the
documentation to reflect this.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Bug#924787: I would really like to see yubikey-personalization in buster

[Karl O. Pinc]

Hi,

The release critical bug count for buster is getting really low.
Is there anything to be done to be sure yubikey-personalization
gets into buster?

Regards,

Karl 
Free Software:  "You don't pay back, you pay forward."
 -- Robert A. Heinlein

Bug#928937: feynmf: compressed manual

[Jerome Benoit]

Package: feynmf
Version: 1.08-10
Severity: normal

Dear Maintainer,

it appears that the manual feynmf.ps is distributed as
a compressed PS document. It should be distributed
uncompressed in such a way that it can be accessible
from texdoctk.

$ texdoctk # -> File search -> feynmf -> feymf.ps.gz
-> view => opened in text format


A better option would be to distribute it in PDF format.

Thanks for your work,
Jerome


-- System Information:
Debian Release: Stretch*
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages feynmf depends on:
ii  dpkg 1.18.25
ii  perl 5.24.1-3+deb9u5
ii  tex-common   6.06
ii  texlive-extra-utils  2016.20170123-5
ii  texlive-font-utils   2016.20170123-5
ii  texlive-latex-base   2016.20170123-5

feynmf recommends no packages.

Versions of packages feynmf suggests:
ii  texlive-metapost  2016.20170123-5

-- no debconf information

Bug#908678: security-tracker - Breaks salsa.d.o

[Bastian Blank]

Hi Salvatore

On Thu, Sep 13, 2018 at 01:37:35PM +0200, Salvatore Bonaccorso wrote:
> On Wed, Sep 12, 2018 at 03:10:56PM +0200, Bastian Blank wrote:
> > As the problems caused by the state of this repo now causes user visible
> > outages, this needs to be fixed.

Please provide a plan how and when to fix this before 2019-06-30.

Just for the record: you must drop the complete project before importing
the rewritten repository.  GitLab keeps all the revisions around, as 
they are associated with jobs.

Regards,
Bastian

-- 
Captain's Log, star date 21:34.5...

Bug#923091: That merged-usr is mandatory is RC

[Bastian Blank]

Control: severity -1 wishlist

Hi Ian

On Mon, May 13, 2019 at 11:22:35AM +0100, Ian Jackson wrote:
> In #923091, Guillem (with dpkg maintainer hat on) asks for a
> base-installer option to allow installing buster without merged-usr.

No, he did not mention dpkg.  But as always, please provide a patch and
answer kibi's questions.

Regards,
Bastian

-- 
First study the enemy.  Seek weakness.
-- Romulan Commander, "Balance of Terror", stardate 1709.2

Bug#927063: closed by saul...@legtux.org (libreoffice-writer: Writer aborts with 'unexpected error' when opening one particular docx file)

[Oliver Sander]

Hi Stéphane,

thanks for caring about my bug report. However, you wrote:

> This kind of bug is not specific to Debian. I recommend you register on the 
> bugtracker of LO and follow it.

This is indeed what I did before filing the Debian report.  In particular,
my Debian report says:

> I filed an upstream bug: 
> https://bugs.documentfoundation.org/show_bug.cgi?id=124607
> but upstream cannot reproduce it.  So could this be a packaging bug...

And later in that bugreport I note that I get the bug with the Debian package 
of LO
but not with the same LO version downloaded directly from the Document 
Foundation site.

So I am not convinced yet that this is not a Debian issue.

Best regards,
Oliver




On 13.05.19 14:21, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the libreoffice-writer package:
> 
> #927063: libreoffice-writer: Writer aborts with 'unexpected error' when 
> opening one particular docx file
> 
> It has been closed by saul...@legtux.org.
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact saul...@legtux.org by
> replying to this email.
> 
> 



signature.asc
Description: OpenPGP digital signature

Bug#914015: bus-daemon: Activated service 'org.freedesktop.systemd1' failed

[Simon McVittie]

Control: reassign -1 systemd

On Sun, 18 Nov 2018 at 15:52:39 +0100, Helge Kreutzmann wrote:
> At the very end of the boot, just after the first user logs in
> (usually using sddm / X) I get the following messages in my logs:
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated 
> service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 
> exited with status 1
> Nov 18 07:02:33 samd dbus-daemon[2879]: [session uid=1000 pid=2877] Activated 
> service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 
> exited with status 1

These messages are caused by the "stub" service files that systemd
installs. It installed them because early versions of systemd activation
required them to exist.

Since dbus 1.11.0, a dbus-daemon that is run with --systemd-activation
automatically assumes that o.fd.systemd1 is an activatable
service. As a result, after Debian 10 'buster' is released,
/usr/share/dbus-1/services/org.freedesktop.systemd1.service and
/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service should
become unnecessary, and they can be removed from the systemd package for
bullseye.

(Pedantically, systemd ought to have Breaks: dbus (<< 1.11.0) after that
change is made, but we don't support upgrades that skip a release.)

Thanks,
smcv

Bug#928053: Adjusting severity

[Alberto Gonzalez Iniesta]

severity 928053 important
thanks

Hi,

Thanks, Christian and Ervin, for your help. I'm lowering the severity of
this bug since it does not really affect Debian (as explained in
upstream link regarding this issue).

If anyone disagrees with this change, please get in touch with me before
raising it again.

Regards,

Alberto

-- 
Alberto Gonzalez Iniesta| Formación, consultoría y soporte técnico
mailto/sip: a...@inittab.org | en GNU/Linux y software libre
Encrypted mail preferred| http://inittab.com

Key fingerprint = 5347 CBD8 3E30 A9EB 4D7D  4BF2 009B 3375 6B9A AA55

Bug#928936: ghostscript: CUPS PDF printing (using pdftopdf) broken

[Chris Boot]

Package: ghostscript
Version: 9.26a~dfsg-0+deb9u3
Severity: important
Tags: security

Dear maintainers & security folks,

The 9.26a~dfsg-0+deb9u3 update has broken printing of PDFs on a number
of systems that we maintain. The PDF files are printed simply using "lp
-d$printer foo.pdf". This results in the filters failing and the job
getting stopped.

The relevant portions of the CUPS error_log are:

D [13/May/2019:14:39:43 +0100] [Job 54554] Options from the PPD file:
D [13/May/2019:14:39:43 +0100] [Job 54554]

D [13/May/2019:14:39:43 +0100] [Job 54554] File: 
D [13/May/2019:14:39:43 +0100] [Job 54554]

D [13/May/2019:14:39:43 +0100] [Job 54554] Filetype: PDF
D [13/May/2019:14:39:43 +0100] [Job 54554] Storing temporary files in
/var/spool/cups/tmp
D [13/May/2019:14:39:43 +0100] [Job 54554] PID 24463
(/usr/lib/cups/filter/pdftopdf) exited with no errors.
D [13/May/2019:14:39:43 +0100] [Job 54554] Process is dying with
\"Unable to determine number of pages, page count: -1
D [13/May/2019:14:39:43 +0100] [Job 54554] \", exit stat 3
D [13/May/2019:14:39:43 +0100] [Job 54554] Cleaning up...
D [13/May/2019:14:39:43 +0100] [Job 54554] PID 24464
(/usr/lib/cups/filter/foomatic-rip) stopped with status 3.
D [13/May/2019:14:39:43 +0100] [Job 54554] Hint: Try setting the
LogLevel to "debug" to find out more.

Best regards,
Chris

Bug#928894: [pkg-gnupg-maint] Bug#928894: custom keyring is not honoured

[Daniel Kahn Gillmor]

On Mon 2019-05-13 01:01:57 +0100, Toni Mueller wrote:
> I did not do this. This variable is unset in my environment.

right, you were working with a pre-existing keyring.  I believe that
keyring already had a copy of the teabot public key.

> Your experiment only shows that the key did *not* end
> up in /tmp/cdtemp.AhkyjS/pubring.kbx. Otherwise, the "gpg -k" above
> should have listed it, instead of saying "No public key".

yes.  i understand your bug report to claim that the default keyring is
being used, when you ask it to not be used.

I was demonstrating that the default keyring was not actually used when
i tried to replicate the issue.

>> perhaps the teabot key was already in your default keyring before you
>> run the --recv-keys operation?  that would certainly explain the
>> behavior that you're seeing.
>
> No, it does not. If a key is already there, it would not say
> "imported: 1".

I don't think this is an accurate analysis.  when you say
--no-default-keyring --keyring /path/to/foo, and /path/to/foo is an
empty keyring, then gpg *should* say "imported: 1" when it adds a key to
/path/to/foo, regardless of whether there the same key is present in the
default keyring This still has no effect on the default keyring, as
you've asked it to not touch the default keyring.

> And since it said "imported: 1" for you, I challenge you to find the
> location of that key, because it is obviously not in your temporary
> keyring.

I beg to differ.  it is not in the default keyring, but it *is* in the
temporary keyring.

I'm still trying to understand and replicate your report.  perhaps the
difference is in whether or not we're using the standard homedir for
gpg?  so i tried with a throwaway account, without setting a different
homedir, and still couldn't replicate:

--
0 jj955@alice:~$ gpg --version
gpg (GnuPG) 2.2.15
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/jj955/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
0 jj955@alice:~$ rm -rf .gnupg ~/gitea.gpg
0 jj955@alice:~$ mkdir -m 0700 .gnupg
0 jj955@alice:~$ echo list-options show-keyring > .gnupg/gpg.conf
0 jj955@alice:~$ gpg -k tea...@gitea.io
gpg: keybox '/home/jj955/.gnupg/pubring.kbx' created
gpg: /home/jj955/.gnupg/trustdb.gpg: trustdb created
gpg: error reading key: No public key
2 jj955@alice:~$ touch ~/gitea.gpg
0 jj955@alice:~$ gpg --keyring ~/gitea.gpg -k tea...@gitea.io
gpg: error reading key: No public key
2 jj955@alice:~$ gpg --keyring ~/gitea.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 2D9AE806EC1592E2: public key "Teabot " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:   imported: 1
0 jj955@alice:~$ gpg --keyring ~/gitea.gpg --no-default-keyring --recv-keys 
CC64B1DB67ABBEECAB24B6455FC346329753F4B0
gpg: key 2D9AE806EC1592E2: 6 signatures not checked due to missing keys
gpg: key 2D9AE806EC1592E2: "Teabot " not changed
gpg: Total number processed: 1
gpg:  unchanged: 1
0 jj955@alice:~$ gpg --keyring ~/gitea.gpg -k tea...@gitea.io
Keyring: /home/jj955/gitea.gpg
--
pub   rsa4096 2018-06-24 [SC] [expires: 2020-06-23]
  7C9E68152594688862D62AF62D9AE806EC1592E2
uid   [ unknown] Teabot 
sub   rsa4096 2018-06-24 [E] [expires: 2020-06-23]
sub   rsa4096 2018-06-24 [S] [expires: 2019-06-24]

0 jj955@alice:~$ 
--

I tried again on a different machine with gpg 2.2.13, and still could
not replicate:

--
0 dkg@sid:~$ gpg --version
gpg (GnuPG) 2.2.13
libgcrypt 1.8.4
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/dkg/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
0 dkg@sid:~$ rm -rf ~/.gnupg ~/gitea.gpg
0 dkg@sid:~$ mkdir -m 0700 ~/.gnupg
0 dkg@sid:~$ echo list-options show-keyring > ~/.gnupg/gpg.conf
0 dkg@sid:~$ gpg -k tea...@gitea.io
gpg: keybox '/home/dkg/.gnupg/pubring.kbx' created
gpg: /home/dkg/.gnupg/trustdb.gpg: trustdb created
gpg: error reading key: No public key
2 d