Bug#961646: node-deep-for-each breaks node-grunt-webpack

2020-05-26 Thread Xavier Guimard
Package: node-deep-for-each
Version: 3.0.0-1
Severity: serious
Control: affects -1 node-grunt-webpack

Version 3.0.0 breaks node-grunt-webpack. Probably due to this change:

> This library is no longer built with Babel, you must compile it
> yourself within your app

Revert to a version 2.x may solve this issue



Bug#961645: hypre: provide 64 bit (bigint/mixedint) build

2020-05-26 Thread Drew Parsons
Source: hypre
Severity: normal
Control: block 953116 by -1

We're discussing introducing a 64 bit-build for the computational
stack. This refers to 64-bit addressing to cells in meshes, etc.

c.f. Bug#953116 (petsc)
Bug#961108 (openmpi)
https://lists.debian.org/debian-science/2020/05/msg00051.html

BLAS is already 64-bit enabled.

For the 64-bit environment to work, it needs to be carried through all
along the library stack, from BLAS to PETSc.

PETSc depends on hypre, and 64-bit PETSc requires 64-bit hypre, or
more precisely, petsc --with-64-bit-indices option requires Hypre
built with --enable-bigint or --enable-mixedint.

Probably we want 2 separate builds, 32-bit (the current
libhypre-dev) and a separate 64-bit libhypre64-dev

Opening this bug to track the chain of 64-bit package dependencies.


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

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



Bug#953116: [petsc-maint] 32 bit vs 64 bit PETSc

2020-05-26 Thread Drew Parsons

On 2020-05-24 10:01, Drew Parsons wrote:

On 2020-05-23 23:45, Satish Balay wrote:


One more issue: Most externalpackages don't support 64bit-indices.

...

We haven't tried using MUMPS in this mode with PETSc


This will be the interesting test. I'll start with the 64-bit build of
MUMPS and see how tests hold up.



The PETSc mumps tests seem to be robust with respect to 64 bit.
(64 bit MUMPS in the form of -DPORD_INTSIZE64, not all-integer 
-DINTSIZE64)


That is, 32 bit PETSc passes its tests with 64 bit (PORD) MUMPS
and 64 bit PETSc passes its tests with 32 bit MUMPS.

The test in question that's passing is src/snes/tutorials/ex19, run with 
'make runex19_fieldsplit_mumps'

Perhaps it's not stress-testing 64 bit conditions.

Drew



Bug#961644: nmu: mumps_5.1.2-4+b2

2020-05-26 Thread Drew Parsons
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

A user reports that libmumps-ptscotch-dev 5.1.2-4+b2 is causing
segfaults in stable (buster) and needs a rebuild (Bug#954326).

The user hasn't provided a test case to confirm the segfault, but
it won't hurt to run a binNMU anyway.

nmu mumps_5.1.2-4+b2 . ANY . buster . -m "Rebuild to fix libmumps-ptscotch 
segfault. Closes: #954326."

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

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



Bug#959643:

2020-05-26 Thread Michael Hudson-Doyle
FWIW there is a new release (1.0.7) available and that seems to fix this
failure (in Ubuntu, anyway).


Bug#911415: flex: yyinput() return value is backward incompatible

2020-05-26 Thread Manoj Srivastava
On Tue, May 26 2020, Bill Allombert wrote:

> On Fri, May 22, 2020 at 03:16:56AM -0700, Manoj Srivastava wrote:
>> 
>> On 12:19 Thursday, 21 May 2020 +0200, Bill Allombert wrote
>>  > On Wed, May 20, 2020 at 10:03:08PM -0700, Manoj Srivastava wrote:
>>  > > While it is true that the change was incompatible wwith what we
>>  > >  had befire, the change was made almost four and a half years ago. I
>>  > >  suspect we have gotten used to it now; and changing it back would just
>>  > >  cause issues.
>>  > 
>>  > Is the new behaviour documented now ?
>>  > This is needed to use yyinput() properly.
>> 
>>  See below. The yyinput usage is demonstrated in an example in
>>  the info node about generating C++ scanners.

> Well but this is not proper documentation, this is incidental
> documentation at best.  Someone writing a C scanner will not read this
> example.  Is it documented somewhere that the yyinput API has changed
> ?

Why should a writer of a C scanner care?

,[ 8 Actions ]
| (Note that if the scanner is compiled using 'C++', then 'input()' is
| instead referred to as yyinput(), in order to avoid a name clash with
| the 'C++' stream by the name of 'input'.)
`

People writing C++ scanners are likely to see it, and they are
 the only ones to care. One could create a github documentation issue
 about it if one feels strongly enough.


> Note that the time should be computed between the time the new flex is
> released and the time I report the problem, not between the git commit
> and now.

As far as upstream is concerned when they commited it is when
 the feature went out. At thi point, just reverting it is another change
 in behaviour. Again, a github issue could be an option if you feel this
 strongly about it.

Manoj

--
I don't care where I sit as long as I get fed.  -- Calvin Trillin
Manoj Srivastava    
4096R/C5779A1C E37E 5EC5 2A01 DA25 AD20  05B6 CF48 9438 C577 9A1C


smime.p7s
Description: S/MIME cryptographic signature


Bug#961643: double-check lintian overrides

2020-05-26 Thread Jelmer Vernooij
Package: lintian-brush
Version: 0.68
Severity: important

Not all fixers currently check lintian-overrides; for those
that don't, lintian-brush should check whether there are any
overrides that could match and revert the changes from the fixer
if there are any that are possibly relevant.

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

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

Versions of packages lintian-brush depends on:
ii  devscripts   2.20.3
ii  python3  3.8.2-3
ii  python3-breezy   3.1~alpha1-1
ii  python3-debian   0.1.37
ii  python3-distro-info  0.23
ii  python3-dulwich  0.19.15-1+b1
ii  python3-iniparse 0.4-3
ii  python3-levenshtein  0.12.0-5+b1
ii  python3-pkginfo  1.4.2-3
ii  python3-ruamel.yaml  0.15.89-3+b2

Versions of packages lintian-brush recommends:
ii  dos2unix   7.4.0-2
ii  gpg2.2.20-1
ii  libdebhelper-perl  13.1
ii  lintian2.76.0
ii  python3-asyncpg0.20.1-1+b1
ii  python3-pyinotify  0.9.6-1.3

Versions of packages lintian-brush suggests:
pn  gnome-pkg-tools
ii  postgresql-common  215

-- no debconf information



Bug#961605: rkhunter: /bin/which moved to /usr/bin/which

2020-05-26 Thread Francois Marier
On 2020-05-26 at 17:00:03, Christoph Anton Mitterer wrote:
> The symlink /bin/which to /usr/bin/which was removed.
> 
> Please adapt the template config to use /usr/bin/which .

I think that it was already done in order to fix #931396:

  
https://salsa.debian.org/pkg-security-team/rkhunter/-/commit/8bd8128fb3cb9f9a5d8e2493297b63d44fc65204

Maybe you don't have the latest copy of the config file on your system?

On my machine, I see this:

  $ grep /bin/which /etc/rkhunter.conf
  SCRIPTWHITELIST=/usr/bin/which

Francois

-- 
https://fmarier.org/



Bug#961642: tigercron: WARNING: tempfile is deprecated; consider using mktemp instead.

2020-05-26 Thread Francois Marier
Package: tiger
Version: 1:3.2.4~rc1-2
Severity: normal

Once an hour, tigercron generates the following WARNING in an email:

  WARNING: tempfile is deprecated; consider using mktemp instead.

Francois

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

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

Versions of packages tiger depends on:
ii  binutils   2.34-8
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.30-8
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0042

Versions of packages tiger recommends:
ii  chkrootkit  0.53-1
pn  john
ii  postfix [mail-transport-agent]  3.5.2-1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof   4.93.2+dfsg-1
pn  lynis  

-- debconf information:
* tiger/mail_rcpt: root
* tiger/policy_adapt:

-- 
https://fmarier.org/



Bug#961490: fwupd: version in stable too old, no updates possible

2020-05-26 Thread Matthias Klumpp
Am Di., 26. Mai 2020 um 20:24 Uhr schrieb :
>
> > -Original Message-
> > From: Ansgar 
> > Sent: Tuesday, May 26, 2020 8:01 AM
> > To: Steffen Schreiber; 961...@bugs.debian.org
> > Subject: Bug#961490: fwupd: version in stable too old, no updates possible
> >
> >
> > [EXTERNAL EMAIL]
> >
> > Hi,
> >
> > On Tue, 2020-05-26 at 13:56 +0200, Steffen Schreiber wrote:
> > > So I see you marked this bug as fixed/resolved.
> >
> > Someone (not the maintainer) did so, but please note that the bug
> > remains open even when marked as fixed in a newer version.  Debian's
> > stable release team prefers bugs to be fixed in unstable/testing before
> > they get fixed in (old)stable, so this is good.
>
> The particular circumstances of this issue are that the update in question 
> requires
> a newer version of fwupd than is in stable.  This is not a matter of just 
> backporting
> a change or two and it works.  There are daemon and plugin level changes that 
> have to
> go together to guarantee a proper update.
>
> This seems incompatible with the documentation around uploading to stable.
> https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> >
> > > What's the way going forward for users of stable? Installing packages
> > > from testing? Are you recommending to just forget about running Debian
> > > stable as is?
> >
> > The maintainer hasn't yet commented on how he wants to proceed.
> > Reasonable options seem to be to either update stable to the version
> > currently in testing (1.3.9) or to update to a later version of 1.2.X.
> >
> > Ansgar
>
> If a particular update requires a newer fwupd version I don't think it's 
> reasonable
> to push that version to all Debian users who may not need the newer fwupd 
> version
> and might not be willing to accept the risk of regressions in a newer version.
>
> "Fixes must be minimal and relevant"
>
> So in this circumstance if your device needs the newer version you should 
> probably
> take the package from testing instead.

Maybe talk to the release-team - they will probably not like adding a
change this big, but exceptions are always possible (e.g. firefox-esr
is exempt from this rule).
In any case though, you could provide a backport of the latest version
for easy installation by stable users as the next-best option :-)

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/



Bug#961156: tech-ctte: Call for votes on TC membership of Elana Hashman

2020-05-26 Thread Simon McVittie
On Wed, 20 May 2020 at 17:10:26 -0300, David Bremner wrote:
> I call for votes on the following ballot to fill a vacant seat in the
> Debian Technical Committee. The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt
> (§6.3.1).
> 
> ===BEGIN
> The Technical Committee recommends that Elana Hashman  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Elana Hashman 
> F: Further Discussion
> ===END

I vote S > F.

smcv


signature.asc
Description: PGP signature


Bug#961153: tech-ctte: Call for votes on TC membership of Sean Whitton

2020-05-26 Thread Simon McVittie
On Wed, 20 May 2020 at 17:03:16 -0300, David Bremner wrote:
> I call for votes on the following ballot to fill a vacant seat in the
> Debian Technical Committee. The voting period starts immediately and
> lasts for up to one week, or until the outcome is no longer in doubt
> (§6.3.1).
> 
> ===BEGIN
> The Technical Committee recommends that Sean Whitton  be
> appointed by the Debian Project Leader to the Technical Committee.
> 
> S: Recommend to Appoint Sean Whitton 
> F: Further Discussion
> ===END

I vote S > F.

smcv


signature.asc
Description: PGP signature


Bug#960534: transition: KDEPIM and KDE Frameworks

2020-05-26 Thread Sandro Knauß
Hey Sebastian,
 
> On 2020-05-22 11:52:27 +0200, Sandro Knauß wrote:
> > I forgot about the the auto-kdav transition that is also part of KDEPIM &
> > KDE Frameworks transition. That means that auto-kdav is automatically
> > solved together with kdepim 20.04 transition.
> 
> Feel free to go ahead with this. Please let us know once the uploads to
> unstable are all done. I'll schedule binNMUs for the remaining packages
> afterwards.

Okay I've uploaded everything, so you can schedule binNMUs with version 
dependencies. The buildds are still busy to finish the set of packages I 
uploaded.

hefee


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


Bug#961635: ITP: dragengine -- Drag[en]gine Game Engine

2020-05-26 Thread Roland Plüss
Package: wnpp
Severity: wishlist
Owner: Roland Plüss 

* Package name: dragengine
  Version : 1.1
  Upstream Author : Roland Plüss 
* URL : https://dragondreams.ch
* License : LGPL-3
  Programming Lang: C++, DragonScript, GLSL, Python
  Description : Drag[en]gine Game Engine

Required to play games (*.delga) or developing games. Run delauncher-gui
or delauncher-console. The Drag[en]gine is a new, fully free software
game engine based on the GLEM design which allows to develop games faster,
more stable and fully platform indepentend (-1 day portability).


* Package name: dragengine-dev
  Version : 1.1
  Upstream Author : Roland Plüss 
* URL : https://dragondreams.ch
* License : LGPL-3
  Programming Lang: C++, DragonScript, GLSL, Python
  Description : Drag[en]gine Game Engine Development Files

Required to create Drag[en]gine Modules (like graphic module, input module
and so forth). Not required to develop games.


* Package name: deigde
  Version : 1.1
  Upstream Author : Roland Plüss 
* URL : https://dragondreams.ch
* License : LGPL-3
  Programming Lang: C++, DragonScript, GLSL, Python
  Description : Drag[en]gine Game Development Environment

Required to developing games using the Drag[en]gine Game Engine. Run deigde.
Developing games using Drag[en]gine does not require compiling or linking
against the game engine.

* Package name: deigde-dev
  Version : 1.1
  Upstream Author : Roland Plüss 
* URL : https://dragondreams.ch
* License : LGPL-3
  Programming Lang: C++, DragonScript, GLSL, Python
  Description : Drag[en]gine IGDE Development

Required to create Drag[en]gine IGDE Editors. Not required to create games.

===

All these packages build from he same source repository at:
  https://github.com/LordOfDragons/dragengine

The debianization is located in upstream repository in branch "debian":
  https://github.com/LordOfDragons/dragengine/tree/debian

The packages are build from this branch but I dont know how to continue
from here. Here the information requested by reportbug:

- why is this package useful/relevant?
  It's a powerfull and future oriented game engine. I can harness this
  power already so I would like to allow other to harness this power too

- do you use it?
  For active game development projects

- how do you plan to maintain it?
  As much as possible which is why I put aside an own branch in the upstream 
repository

- inside a packaging team?
  The "games" team seems appropriate. I've talked to the team already on IRC 
recently

- are you looking for co-maintainers?
  I do not think multiple maintainers are required. But it never hurts to have 
helping hands

- do you need a sponsor?
  If I have understood the documentation correctly I do need a sponsor.
  So yes, I'm looking for one.


Bug#961563: crash: Build failure due to parallel execution

2020-05-26 Thread Benjamin Poirier
On 2020-05-26 17:10 +0300, Adrian Bunk wrote:
> Control: severity -1 normal
> Control: tags -1 - ftbfs
> 
> On Tue, May 26, 2020 at 11:58:19AM +0900, Benjamin Poirier wrote:
> > Source: crash
> > Severity: serious
> > Tags: upstream patch ftbfs
> > Justification: fails to build from source (but built successfully in the 
> > past)
> > 
> > Dear Maintainer,
> > 
> > The crash package sometimes fails to build when dpkg-buildpackage is
> > invoked with -j > 1:
> > 
> > # dpkg-buildpackage -us -uc -j4
> >...
> 
> You are not the first person to fall into this trap.
> 
>-j, --jobs[=jobs|auto]
>   Number  of jobs allowed to be run simultaneously, number
>   of jobs matching the number of online processors if auto
>   is  specified  (since dpkg 1.17.10), or unlimited number
>   if jobs is not  specified,  equivalent  to  the  make(1)
>   option  of the same name (since dpkg 1.14.7, long option
>   since dpkg 1.18.8).  Will add itself  to  the  MAKEFLAGS
>   environment  variable, which should cause all subsequent
>   make invocations to inherit the option, thus forcing the
>   parallel  setting  on  the  packaging  (and possibly the
>   upstream build system if that uses make)  regardless  of
>   their  support  for  parallel  builds, which might cause
>   build failures.
> 
> -J is the correct dpkg-buildpackage option.

Thanks for the tip. Indeed, specifying -J avoids the problem.

> 
> > This is because crash's configure rewrites Makefile via a temporary file
> > (Makefile.new) and it is now getting invoked multiple times in parallel.
> > This is a problem upstream.
> 
> Correct.
> 
> > It can be avoided with the following change:
> > --- a/debian/rules
> > +++ b/debian/rules
> > @@ -12,8 +12,7 @@ include /usr/share/dpkg/buildflags.mk
> > dh $@
> >  
> >  override_dh_auto_build:
> > -   dh_auto_build
> > -   $(MAKE) extensions lzo snappy
> > +   dh_auto_build -- all extensions lzo snappy
> >...
> 
> This would fix only the "dpkg-buildpackage -j1" case,

Since the crash package has debian/compat level 9, dh always invokes
make with -j1. So that patch avoided problems from dpkg-buildpackage
invocations with -j > 1.

> "dh $@ --parallel" would still fail due to
>   make -j4 all extensions lzo snappy
> 

Yeah... but I wasn't suggesting adding "--parallel".

Actually, the intention of the patch I suggested was not to enable
parallel building; it was to prevent it (since it's not supported
upstream).

> 
> The correct workaround to enable parallel building is:
> 
> %:
> dh $@ --parallel
> 
> override_dh_auto_build:
> $(MAKE)
> $(MAKE) extensions
> $(MAKE) lzo
> $(MAKE) snappy

True, but it doesn't bring any benefit I think because of crash's
Makefile:

 debian/rules build
dh build --parallel
dh: warning: Compatibility levels before 10 are deprecated (level 9 in 
use)
   dh_update_autotools_config -O--parallel
   dh_auto_configure -O--parallel
dh_auto_configure: warning: Compatibility levels before 10 are 
deprecated (level 9 in use)
   debian/rules override_dh_auto_build
make[1]: Entering directory '/root/crash-7.2.8'
/usr/bin/make
make[2]: Entering directory '/root/crash-7.2.8'
TARGET: X86_64
 CRASH: 7.2.8
   GDB: 7.6

make[3]: Entering directory '/root/crash-7.2.8'
make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent 
make rule.

Anyways, if pressed, I would agree that the initially reported failure
is due to a user error with regards to -j vs. -J. Please feel free to
close this bug.



Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

2020-05-26 Thread Matthew Fernandez


> On May 26, 2020, at 15:10, Mattia Rizzolo  wrote:
> 
>  * building the package shows this "scary" GCC warning:
> |In file included from /usr/include/string.h:495,
> | from cryptopass.c:19:
> |In function 'strncpy',
> |inlined from 'main' at cryptopass.c:200:9:
> |/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
> '__builtin___strncpy_chk' specified bound depends on the length of the source 
> argument [-Wstringop-overflow=]
> |  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
> (__dest));
> |  |  
> ^~
> |cryptopass.c: In function 'main':
> |cryptopass.c:191:25: note: length computed here
> |  191 | passlenbuflen = strlen(argv[3]);
> |  | ^~~

This prompted me to take a quick look at the source. There are multiple 
trivially exploitable buffer overflows in this code. E.g. 
src/cryptopass.c:147-149 [0]:

usernamelen = strlen(argv[1]);

memcpy(username, argv[1], usernamelen);

You could argue this program is only intended to receive input from a trusted 
user, but is a user meant to comprehend that passing large command line 
arguments results in memory corruption? Obviously everyone is free to develop 
code how they like, but IMHO security packages should be using fuzz testing, 
that would easily find this issue. AFAICT this code base has no test suite. I 
would suggest adding one as well as fuzzing this code before exposing the 
downstream public to it.

  [0]: 
https://github.com/basilgello/cryptopass/blob/master/src/cryptopass.c#L147-L149


Bug#961558: libkf5xmlgui5: removes KGestureMap, which breaks older kdebugdialog5 (package: libkf5kdelibs4support5-bin)

2020-05-26 Thread Sandro Knauß
Hey,

> It's nice you uploaded a new version, but you picked 5.59 as the breaks
> version, while 5.62 is surely still affected.

nrgh, that was a typo.

hefee


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


Bug#961558: libkf5xmlgui5: removes KGestureMap, which breaks older kdebugdialog5 (package: libkf5kdelibs4support5-bin)

2020-05-26 Thread Jiri Palecek



On 26. 05. 20 15:26, Jiri Palecek wrote:

Hello,

On 26. 05. 20 9:37, Sandro Knauß wrote:

Hey Jiri,

please do report such an issue on the package, that breaks and not at
the
source of the problem, that would gives us automatically the version of
libkf5kdelibs4support5-bin. If not always make sure that both
versions are
included in the bugreport. I expect, that you use the version still on
unstable. as the version on experimental runs fine.


Yes, that's true, it was 5.62. Sorry about that omission.

The Breaks i was suggesting was on linkf5kdelibs4support5 (<<5.69~).


It's nice you uploaded a new version, but you picked 5.59 as the breaks
version, while 5.62 is surely still affected.

Regards

    Jiri Palecek



Bug#961639: util-linux: FTBFS with uname26 error on glibc >= 2.30

2020-05-26 Thread Chris Hofstaedtler
Hi Helge Deller,

thanks for your report.

Please resubmit the patch with upstreams requirements (esp.
Signed-off-by) so this can be fixed upstream. (As this does not
appear to be a Debian-specific bug.)

Thanks,
Chris



Bug#961641: localepurge removes X11 locale files otherwise required

2020-05-26 Thread Michel Casabona
Package: localepurge
Version: 0.7.3.9
Severity: important

dmenu (from suckless-tools) and i3-dmenu-desktop (from package i3-wm) stopped 
working suddenly,
after localepurge was upgraded

Two error messages are shown in .xsession-errors:
warning: no locale support
warning: no locale modifiers support

The locale is set to fr_FR.UTF-8 
$ echo $LANG
fr_FR.UTF-8

but strace shows that dmenu tries to open
   /usr/share/X11/locale/en_US.UTF-8/XLC_LOCALE
which is indeed missing, purged today by localpurge on upgrade.

The workaround is simply to add en_US.UTF-8 to locale.nopurge,
reconfigure localepurge and reinstall libx11-data

Not sure why locale en_US.UTF-8 would be required, but it might be related to 
this:

$ grep $LANG /usr/share/X11/locale/locale.dir 
en_US.UTF-8/XLC_LOCALE  fr_FR.UTF-8
en_US.UTF-8/XLC_LOCALE: fr_FR.UTF-8

The comments found in locale.dir suggests that the problem could be rather 
common,
so localepurge should perhaps keep en_US.UTF-8 anyway. 

Thanks!


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.14 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages localepurge depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  locales2.30-8
ii  perl   5.30.2-1
ii  procps 2:3.3.16-5
ii  ucf3.0038+nmu1

localepurge recommends no packages.

Versions of packages localepurge suggests:
pn  bleachbit  
pn  debfoster  
ii  deborphan  1.7.33

-- debconf information:
  localepurge/showfreedspace: true
  localepurge/dontbothernew: false
  localepurge/remove_no:
  localepurge/none_selected: false
* localepurge/nopurge: en, en_US.UTF-8, fr, fr_FR, fr_FR@euro, fr_FR.UTF-8
* localepurge/mandelete: true
* localepurge/use-dpkg-feature: false
  localepurge/quickndirtycalc: true
  localepurge/verbose: false



Bug#961640: fontforge: Shows no glyphs when running on Wayland

2020-05-26 Thread Changwoo Ryu
Package: fontforge
Version: 1:20190801~dfsg-4
Severity: important

Hello,

When I run fontforge in Wayland (gnome-shell or weston),

$ env LANG=en_US.UTF-8 fontforge LexiGulim.ttf 

It doesn't show the font glyphs. Also I cannot see window decorations.
I can access the menu but the current selection is not highlighted.

If I run fontforge in XWayland,

$ env WAYLAND_DISPLAY= LANG=en_US.UTF-8 fontforge LexiGulim.ttf 

This shows glyphs and window decorations as expected.

See the screenshots attached.


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

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

Versions of packages fontforge depends on:
ii  fontforge-common  1:20190801~dfsg-4
ii  libc6 2.30-8
ii  libfontforge3 1:20190801~dfsg-4
ii  libgdraw6 1:20190801~dfsg-4

fontforge recommends no packages.

Versions of packages fontforge suggests:
ii  fontforge-doc  1:20190801~dfsg-4
ii  fontforge-extras   1:20190801~dfsg-4
ii  potrace1.16-2
ii  python3-fontforge  1:20190801~dfsg-4

-- no debconf information


Bug#961639: Acknowledgement (util-linux: FTBFS with uname26 error on glibc >= 2.30)

2020-05-26 Thread Helge Deller
Patch to fix the uname26 testcases
diff -up ./tests/ts/misc/setarch.org ./tests/ts/misc/setarch
--- ./tests/ts/misc/setarch.org	2020-05-26 22:27:49.173547933 +
+++ ./tests/ts/misc/setarch	2020-05-26 22:25:49.230293192 +
@@ -45,7 +45,7 @@ ts_init_subtest uname26
 finmsg="" # for debugging 2.6 issues

 echo "## --uname-2.6 echo" >>$TS_OUTPUT
-$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> $TS_OUTPUT
 if [ $? -eq 0 ]; then
 	expected='^2.6 worked$'
 else
@@ -56,7 +56,7 @@ fi
 sed -i "$ s/$expected/2.6 works or kernel too old/" $TS_OUTPUT

 echo "## --uname-2.6 true, non-verbose" >>$TS_OUTPUT
-$TS_CMD_SETARCH $ARCH --uname-2.6 true >> $TS_OUTPUT 2>> $TS_ERRLOG
+$TS_CMD_SETARCH $ARCH --uname-2.6 true >> $TS_OUTPUT 2>> $TS_OUTPUT
 if [ $? -eq 0 ]; then
 	echo "2.6 works or kernel too old" >> $TS_OUTPUT
 else


Bug#961639: util-linux: FTBFS with uname26 error on glibc >= 2.30

2020-05-26 Thread Helge Deller
Package: util-linux
Version: 2.35.2-2
Severity: important
Tags: ftbfs, patch

On architectures which already run glibc >= 2.30 the uname26 testcases fail.
Currently this bug affects at least hppa, ia64 and riscv64.

The problem is, that the testcase is wrong.
This command in ./tests/ts/misc/setarch:
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> 
$TS_ERRLOG

Errors are written to $TS_ERRLOG, while OK'ed output is written to $TS_OUTPUT.
With glibc >= 2.30 you get "FATAL: kernel too old", older glibc report "2.6 
worked".

But a few lines later in the script we have:
  sed -i "$ s/$expected/2.6 works or kernel too old/" $TS_OUTPUT
which only replaces the text in $TS_OUTPUT (and ignores $TS_ERRLOG).

Changing
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> 
$TS_ERRLOG
to
$TS_CMD_SETARCH $ARCH -v --uname-2.6 echo "2.6 worked" >> $TS_OUTPUT 2>> 
$TS_OUTPUT
fixes the uname26 tests.



Bug#961584: lxc-stop fails with exit code 1

2020-05-26 Thread Antonio Terceiro
Control: severity -1 serious

On Tue, May 26, 2020 at 06:35:50PM -0300, Antonio Terceiro wrote:
> On Tue, May 26, 2020 at 12:55:10PM +0200, Inaki Malerba wrote:
> > Source: lxc
> > Version: 1:4.0.2-1
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > Since version 1:4.0.2-1, we've found a change on the behavior of
> > lxc-stop when running on the Salsa-CI pipeline.
> > 
> > debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning
> > exit code 1.
> > 
> > This can be reproduced on salsa-ci pipeline, which calls `debci localtest`.
> > 
> > https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946
> > 
> > : failure: ['sudo', 'timeout', '600', 'lxc-stop',
> > '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1,
> > stderr '')
> 
> I have been using this version of lxc locally for autopkgtest for a
> while without any issues, so this issue is probably specific to running
> lxc under docker.
> 
> is there an easy/documented way of reproducing the salsa ci environment
> (i.e. lxc working under docker) locally? I downloaded
> registry.salsa.debian.org/salsa-ci-team/pipeline/autopkgtest, started a
> container with --privileged, and tried following the steps in the
> salsa-ci-yml, but I am probably missing something because the containers
> won't start apparently due to apparmor.

I'm upgrading this bug to serious to prevent this version from reaching
testing since this breaks Debian infrastructure. :-)


signature.asc
Description: PGP signature


Bug#961429: RFS: cryptopass/1.0.0-1 [ITP] -- CLI utility for generating long, unguessable passwords.

2020-05-26 Thread Mattia Rizzolo
Control: owner -1 !
Control: tag -1 moreinfo

On Sun, May 24, 2020 at 02:22:42PM +, Vasyl Gello wrote:
> I am looking for a sponsor for my package "cryptopass"

o/

>  * Vcs : https://salsa.debian.org/basilgello-guest/cryptopass

I'm mostly looking at the VCS, but I'm not ignoring the regular source
package either.


Things:

 * you are not using git-buildpackage, instead everything is just thrown
   into the master branch.  Please look into gbp.  Since this is a
   totally new package, I'm actually recommending you just destroy this
   repository and create it anew, starting with a blank
   `gbp import-orig`.
   Please also enable pristine-tar in your local configuration unless
   you have a reason not to, and I also recommend you put
   "sign-tags = True" in the DEFAULT section as well.
 * d/control:
   + any reason not to go to compat 13?
   + just to please my OCD, could you please move the Section field up
 next to Priority?  (this is just me, I just can't look at that! :|)
   + on that note, you should review the Section, since this is not a
 library from what I can see
   + the synopsis is not a sentence, as such it shouldn't end with a
 full stop
   + also in the synopsis, grammar improvement: s/for generating/to
 generate/
   + in contrast, the long description is made up of whole sentences,
 but it's not really flowing: "This program can be used to generate
 passwords from a seed composed by:  " is more welcoming to read
 than your initial line
  * d/changelog:
+ Make that only "Initial upload.  Closes: #xxx", no need for 3
  lines and "initial upload" is kind of standard.
  * d/copyright:
+ place the full local URI for the Apache-2.0 License
+ likewise for the CC0, you only wrote the remote URL
+ you assert that lib/base64/* is BSD-3-clause, but I can't really
  say it by looking at the source.  Since you are upstream, I urge
  you to include an extra file (like the referenced README?)
  explaining the origin of those bundled files
  * d/rules:
+ you have clearly copied this file from somewhere without
  understanding it… didn't you?
+ that DH_OPTIONS export to make "some magic below work", do you
  know what?  AFAIK it's pretty useless as it is, so please drop
  that
+ also go read the section "COMPATIBILITY LEVELS" of debhelper(7),
  to discover that starting with compat 10 "--with autoreconf" is
  implied
+ can you please explain what's so special of this package that you
  don't want to call ldconfig?  Since it's something so odd there
  ought to be a comment.
  * d/upstream/metadata:
+ Contact is obsoleted by Upstream-Contact in d/copyright (avoids
  duplication)
  * building the package shows this "scary" GCC warning:
|In file included from /usr/include/string.h:495,
| from cryptopass.c:19:
|In function 'strncpy',
|inlined from 'main' at cryptopass.c:200:9:
|/usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: warning: 
'__builtin___strncpy_chk' specified bound depends on the length of the source 
argument [-Wstringop-overflow=]
|  106 |   return __builtin___strncpy_chk (__dest, __src, __len, __bos 
(__dest));
|  |  ^~
|cryptopass.c: In function 'main':
|cryptopass.c:191:25: note: length computed here
|  191 | passlenbuflen = strlen(argv[3]);
|  | ^~~



Overall all of the above are indeed trivial matters, but this is
likewise a very trivial project to package.

One thing I have to think about is if this is something that debian
would benefit to have.  I'm not really security-minded, so I tend to be
wary about anything that tried to do crypto or handling passwords.  I
hope some random 3rd party will tell me that this is fine ^^

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961581: pbcopper: ftbfs on ppc64el

2020-05-26 Thread Michael Hudson-Doyle
On Tue, 26 May 2020 at 23:43, Andreas Tille  wrote:

> thanks for the patch.  I've uploaded pbcopper to new since
> it needed a soname bump and thus a new binary package name.
>

Thanks. I think a fixed simde has been uploaded now, so my patch might not
be needed at all...


Bug#961638: proposal: stocat - probabilistic cat

2020-05-26 Thread Stefano Zacchiroli
Package: moreutils
Version: 0.63-1+b1
Severity: wishlist
Tags: patch upstream

I'm hereby proposing the inclusion of the attached "stocat" utility to
moreutils. It's like cat, but output lines with a given probability, defaulting
to 10%. It's very useful for random sampling (and *much* more efficient at that
than using "shuf" which is unwieldy on very large inputs) and, while it can be
implemented instead with awk/perl oneliners, those oneliners aren't very
mnemonic and are error prone.

If desired, it could be extended by adding a reservoir sampling option, to
guarantee a selection of exactly K items.

Thanks a lot for moreutils!

Cheers

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_WARN
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages moreutils depends on:
ii  libc6  2.30-8
ii  libipc-run-perl20200505.0-1
ii  libtime-duration-perl  1.21-1
ii  libtimedate-perl   2.3200-1
ii  perl   5.30.2-1

moreutils recommends no packages.

moreutils suggests no packages.

-- no debconf information
#!/usr/bin/perl

=head1 NAME

stocat - stochastic cat, selecting lines with uniform probability


=head1 SYNOPSIS

=over

=item B [B<-p>|B<--probability> PROBABILITY] [I|B<->]...

=back


=head1 DESCRIPTION

Concatenate FILE(s) to standard output, but printing each input line to output
only with a given probability, defaulting to 0.1 (i.e., 10%).

With no FILE or when FILE is B<->, read standard input.


=head1 OPTIONS

=over 4

=item -p, --probability

Output lines with the given probability, specified as a number between 0 (0%
probability) and 1 (100% probability). Default: 0.1 (i.e., 10% probability).

=back


=head1 SEE ALSO

L


=head1 AUTHOR

Copyright 2020 by Stefano Zacchiroli 

Licensed under the GNU GPL.

=cut

use Getopt::Long;

sub die_usage() {
die "Usage: $0 [--probability|-p PROBABILITY] [file|-]\n";
}

my $probability = 0.1;
if (! GetOptions("probability|p=f" => \$probability)) {
die_usage();
}
if ($probability < 0 || $probability > 1) {
die_usage();
}

while (<>) {
print $_ if rand() <= $probability;
}


Bug#961637: bambam should not apply Caps-Lock or Num-Lock conditions upon exit.

2020-05-26 Thread Brian Minton
Package: bambam
Version: 1.0.1+dfsg-1
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

If the user types the scroll-lock key while in bambam, the terminal is not in a
frozen (e.g. Ctrl-S) state when the application exits.  However, if the user 
types the
caps-lock or num-lock keys, those key states remain active when the application
exits.

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

Kernel: Linux 5.5.0 (SMP w/4 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)
LSM: AppArmor: enabled

Versions of packages bambam depends on:
ii  python3 3.8.2-3
ii  python3-pygame  1.9.6+dfsg-2+b1

bambam recommends no packages.

bambam suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEAREIAB0WIQT5xLt2Dng/DewQpoprjrOgZc+6qQUCXs2N1wAKCRBrjrOgZc+6
qXu1APwLrZNwmNf0bm48JgzMKP/AbqSKhSjpEsuXhuIr1IQFDwD+P89ohblgI7w7
CSeTfCO3VqJGHBIzz/6SzaAdmGjTvNmIiAQBFggAMBYhBO7QFYAT3C5tbgAepDe5
UHrP8gFuBQJezY3gEhxicmlhbkBtaW50b24ubmFtZQAKCRA3uVB6z/IBbvmgAQC0
L3LzTSQN0UauNyMgV3zgAuKeDm+2vK6X6ZgCuZ1fpgD9GEZ2M0X/t/Z0b09tXys1
9kuIOftF3nJqkaFI8y9+eQE=
=Pa6Q
-END PGP SIGNATURE-



Bug#961584: lxc-stop fails with exit code 1

2020-05-26 Thread Antonio Terceiro
On Tue, May 26, 2020 at 12:55:10PM +0200, Inaki Malerba wrote:
> Source: lxc
> Version: 1:4.0.2-1
> Severity: important
> 
> Dear Maintainer,
> 
> Since version 1:4.0.2-1, we've found a change on the behavior of
> lxc-stop when running on the Salsa-CI pipeline.
> 
> debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning
> exit code 1.
> 
> This can be reproduced on salsa-ci pipeline, which calls `debci localtest`.
> 
> https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946
> 
> : failure: ['sudo', 'timeout', '600', 'lxc-stop',
> '--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1,
> stderr '')

I have been using this version of lxc locally for autopkgtest for a
while without any issues, so this issue is probably specific to running
lxc under docker.

is there an easy/documented way of reproducing the salsa ci environment
(i.e. lxc working under docker) locally? I downloaded
registry.salsa.debian.org/salsa-ci-team/pipeline/autopkgtest, started a
container with --privileged, and tried following the steps in the
salsa-ci-yml, but I am probably missing something because the containers
won't start apparently due to apparmor.


signature.asc
Description: PGP signature


Bug#936777: k3d: Python2 removal in sid/bullseye

2020-05-26 Thread Manuel A. Fernandez Montecelo
Hi!

Em 26 de mai. de 2020 às 20:43, Moritz Mühlenhoff  escreveu:
>
> On Wed, Sep 04, 2019 at 12:10:39AM +0200, Manuel A. Fernandez Montecelo wrote:
> > Control: forwarded -1 https://github.com/K-3D/k3d/issues/38
> >
> > Thanks for the report.  Asking upstream about their plans and best
> > course of action.
>
> Given upstream's reply at https://github.com/K-3D/k3d/issues/38 this
> seems unlikely to get ported, let's remove k3d?

Basically I'd like to extend its life in Debian and keep users using
this package rather than having to build the version themselves, as
long as it doesn't become a big burden for Debian -- when it does
sure, let's drop it, and if the moment is now, so be it.

This package is in a bad situation with Python2 and GTK dependencies,
but this is not the kind of application like a media player or similar
for which there are a gazillion alternatives with more or less the
same features -- this is a pretty specialized piece of software and
migration to some other tool can be a huge undertaking and might not
always be possible.

If the relevant Python2 packages are going to be removed imminently,
that's OK, we can remove it now.  And in any case, this package should
prevent the removal of Python2 if it's one of the last dependencies.

But if Python2 it's to be held for a few months/years because other
important/popular packages are not migrated yet (gnat-gps, kodi?), and
even if only to keep it for unstable, I'd prefer to remove this
package only when Python2 is removed.

Cheers and thanks for your work.

-- 
Manuel A. Fernandez Montecelo 



Bug#959931: qa.debian.org: udd.debian.org/dmd no more able to display HTML report

2020-05-26 Thread gregor herrmann
On Tue, 26 May 2020 13:19:40 +, Holger Levsen wrote:

> On Mon, May 25, 2020 at 09:47:18PM +0200, Lucas Nussbaum wrote:
> > At least the good thing is that I discovered that DMD actually has users ;)
> I look at my DMD page every day, 

I don't.

I look at DMD's RSS feeds :)

> so many thanks for all the work on it!

+1
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: The Eagles: Best of my love


signature.asc
Description: Digital Signature


Bug#961636: src:galera-3: fails to migrate to testing for too long: ftbfs on armel

2020-05-26 Thread Paul Gevers
Source: galera-3
Version: 25.3.28-2
Severity: serious
Control: close -1 25.3.29-2
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 958040

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:galera-3 in
its current version in unstable has been trying to migrate for 61 days
[2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=galera-3




signature.asc
Description: OpenPGP digital signature


Bug#961552: gnome-contacts: org.gnome.Contacts.png files are not installed

2020-05-26 Thread Simon Désaulniers
Actually,

I have found the issue: in the desktop file, there is a line

OnlyShowIn=GNOME;Unity;

which prevents awesome (possibly willingly) from loading the entry. I verified
that by overriding the desktop entry, i.e. by moving the desktop file to
~/.local/share/applications and trying with and without the line and without the
line Awesome succeeds in loading the file.

We could think that a patch could solve it in Debian, but I don't think that
this is a good idea since for uniformity's sake patches should be made for all
gnome packages that share this behaviour. This is not reasonable I think. I
guess that the good solution would be for Awesome to override this setting while
loading desktop files or at least let the user enable this behaviour.

Anyways. Case closed. ;)

Regards,

On Tue, May 26, 2020 at 03:47:25PM -0400, Simon Désaulniers wrote:
> Hi,
> 
> > apt-file looks at all the apt sources you have available, so you're seeing
> > the PNG icons in the version in stable. To see what's in the version you
> > actually have installed, use `dpkg -L gnome-contacts`.
> 
> Thanks for clarification! I didn't realize that apt-file was not looking into
> the right branch.
> 
> Yeah. I should have used `dpkg`.
> 
> > It looks as though since 3.31.3, gnome-contacts only installs scalable
> > icons in SVG format. This appears to have been a deliberate upstream
> > change. Is Awesome unable to display those?
> 
> So finally, I think that you're half right: yes it is about Awesome, but it's
> not that it doesn't read SVG, but it's that it's giving up on scanning the 
> whole
> directory since the current code for doing that is not yet efficient enough.
> 
> https://github.com/awesomeWM/awesome/issues/908
> 
> This issue can be closed I think. Thank you for your quick and bright 
> response!
> 
> Regards,
> 
> On Tue, May 26, 2020 at 09:01:32AM +0100, Simon McVittie wrote:
> > Control: retitle -1 gnome-contacts: only has scalable SVG icons, not bitmap 
> > PNG icons
> > 
> > On Mon, 25 May 2020 at 18:24:54 -0400, Simon Désaulniers wrote:
> > > After installing the package, the icon files are not installed on the 
> > > system.
> > > According to apt-file, they should be installed at the following paths:
> > > 
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/22x22/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/32x32/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/48x48/apps/org.gnome.Contacts.png
> > > gnome-contacts: 
> > > /usr/share/icons/hicolor/512x512/apps/org.gnome.Contacts.png
> > 
> > apt-file looks at all the apt sources you have available, so you're seeing
> > the PNG icons in the version in stable. To see what's in the version you
> > actually have installed, use `dpkg -L gnome-contacts`.
> > 
> > It looks as though since 3.31.3, gnome-contacts only installs scalable
> > icons in SVG format. This appears to have been a deliberate upstream
> > change. Is Awesome unable to display those?
> > 
> > smcv
> 
> -- 
> Simon Désaulniers
> sim.desaulni...@gmail.com



-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature


Bug#961634: RM: gr-gsm [s390x] -- RoQA; no longer builds on big endian

2020-05-26 Thread Adrian Bunk
Package: ftp.debian.org
Severity: normal

gr-gsm no longer builds on big endian, see #960773 for background.



Bug#961206: improve sphinx usage for cross building

2020-05-26 Thread Helmut Grohne
Hi Dmitry,

On Tue, May 26, 2020 at 02:46:28PM +0300, Dmitry Shachnev wrote:
> It would be nice to have a better estimate of how many packages can be
> fixed in an automated way in DPMT [1], how many packages cannot be fixed
> at all (e.g. because they use sphinx from Python interface) and how many
> packages are remaining.
> 
> [1] Ondřej Nový did the previous mass change that changed ‘sphinx-build’
> to ‘python3 -m sphinx’ in debian/rules, perhaps it would be easy for
> him to revert that change and at the same time update the build
> dependency.

Given that many packages use python3 -m sphinx now, the breakage would
be quite small actually. Using python3 -m sphinx would continue to just
work after the split (though it would still break cross building). So I
guess, we can simply remove DPMT from the calculation.

> The first step (making python3-sphinx provide sphinx) is zero cost, so
> I can do it quite soon.

Doing so enables depending on sphinx, but python3-sphinx and sphinx
actually need to be distinct packages, because sphinx should become
Multi-Arch: foreign while python3-sphinx should not. You cannot express
that using Provides.

> update-alternatives is no longer needed because Sphinx no longer supports
> Python 2.

I guessed that.

> Do you know what is the process of switching from update-alternatives
> to directly shipping the symlink? Can I just drop the postinst/postrm
> scripts and add that symlink, or I need to somehow unregister the
> alternative when the package is upgraded?

I think you need to actually declare Conflicts (not just Breaks and
Replaces) on any alternative (i.e. python-sphinx). Then, you'd remove
the alternative in preinst (like you do in prerm already) and unpacking
the symlinks should work.

Helmut



Bug#961633: mark golang-github-gorilla-websocket-dev Multi-Arch: foreign

2020-05-26 Thread Helmut Grohne
Package: golang-github-gorilla-websocket-dev
Version: 1.4.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability
Control: affects -1 src:containerd src:docker.io src:gitlab-ci-multi-runner

golang-github-gorilla-websocket-dev is another go library that happens
to be in the build dependency tree of many source packages that build
architecture dependent packages. I've listed three affected example
packages above.  Since it is Architecture: all, it cannot satisfy cross
Build-Depends at all. Fortunately, marking it Multi-Arch: foreign is a
good option here as it doesn't have any maintainer scripts nor
dependencies. Please consider applying the attached patch to move cross
building go packages forward.

Helmut
diff --minimal -Nru golang-github-gorilla-websocket-1.4.1/debian/changelog 
golang-github-gorilla-websocket-1.4.1/debian/changelog
--- golang-github-gorilla-websocket-1.4.1/debian/changelog  2019-11-14 
11:40:24.0 +0100
+++ golang-github-gorilla-websocket-1.4.1/debian/changelog  2020-05-26 
22:11:15.0 +0200
@@ -1,3 +1,11 @@
+golang-github-gorilla-websocket (1.4.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark golang-github-gorilla-websocket-dev Multi-Arch: foreign. (Closes:
+#-1)
+
+ -- Helmut Grohne   Tue, 26 May 2020 22:11:15 +0200
+
 golang-github-gorilla-websocket (1.4.1-2) unstable; urgency=medium
 
   * Source-only upload, after the initial binary upload due to
diff --minimal -Nru golang-github-gorilla-websocket-1.4.1/debian/control 
golang-github-gorilla-websocket-1.4.1/debian/control
--- golang-github-gorilla-websocket-1.4.1/debian/control2019-11-14 
11:40:13.0 +0100
+++ golang-github-gorilla-websocket-1.4.1/debian/control2020-05-26 
22:11:12.0 +0200
@@ -17,6 +17,7 @@
 
 Package: golang-github-gorilla-websocket-dev
 Architecture: all
+Multi-Arch: foreign
 Depends: ${misc:Depends}
 Breaks: golang-websocket-dev (<< 1.0.0+git20160606.12.a687089-1~)
 Provides: golang-websocket-dev


Bug#961632: ITP: umap-learn -- Uniform Manifold Approximation and Projection

2020-05-26 Thread Andreas Tille
Package: wnpp
Severity: wishlist

Subject: ITP: umap-learn -- Uniform Manifold Approximation and Projection
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: umap-learn
  Version : 0.4.3
  Upstream Author : Leland McInnes
* URL : https://github.com/lmcinnes/umap
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Uniform Manifold Approximation and Projection
 Uniform Manifold Approximation and Projection (UMAP) is a dimension
 reduction technique that can be used for visualisation similarly to t-
 SNE, but also for general non-linear dimension reduction. The algorithm
 is founded on three assumptions about the data:
 .
  1. The data is uniformly distributed on a Riemannian manifold;
  2. The Riemannian metric is locally constant (or can be
 approximated as such);
  3. The manifold is locally connected.
 .
 From these assumptions it is possible to model the manifold with a fuzzy
 topological structure. The embedding is found by searching for a low
 dimensional projection of the data that has the closest possible
 equivalent fuzzy topological structure.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/umap-learn



Bug#922961: ITP: vorta -- Desktop Backup Client for Borg

2020-05-26 Thread Nicholas D Steeves
Hi Félix,

Félix Sipma  writes:

> Hi Nicholas and others,
>
> Did you make any progress on this ITP?

Of course! :-) I'm still waiting to hear back from the Debian Borg
Collective though...

IIRC the blocker months ago was either related to the Python 3.8
transition, or to strange errors with QDarkStyle.  I haven't filed an
ITP for QDarkStyle, because I believe that the behaviour it enables is
not what most users expect.

  https://github.com/borgbase/vorta/issues/471

Best,
Nicholas

P.S. I suspect this ITP will take a while to resolve, because the
upstream is very much in the "release a standalone bundle with
everything vendored" camp..


signature.asc
Description: PGP signature


Bug#961631: libopenmpi3: causes openmpi-bin/buster to segfault

2020-05-26 Thread Andreas Beckmann
Package: libopenmpi3
Version: 4.0.3-6
Severity: serious

Hi Alastair,

I just managed by accident to do a partial upgrade of openmpi, i.e.
openmpi-bin was still the buster version while libopenmpi3 was already
upgraded to bullseye. This caused mpirun to segfault ...

I could reproduce it in a minimal buster chroot, installing
openmpi-bin/buster and thereafter enabling bullseye sources and
upgrading libgcc-8-dev gcc-8-base libmpx2 libc6-dev libopenmpi3 to
bullseye.
gdb says, the segfault happened
  in opal_hwloc_base_get_nbobjs_by_type () from 
/usr/lib/x86_64-linux-gnu/libopen-pal.so.40
so this is likely because mpirun causes both libhwloc.so.5 (own
dependency) and libhwloc.so.15 (libopen-rte.so.40 dependency) to be
loaded in the same process.

libopenmpi3 should probably break packages from buster depending on
both libopenmpi3 and libhwloc5. Luckily there are not that many:
  gromacs-openmpi (<< 2020~beta2-2) (*)
  libeztrace0 (<< 1.1-8-5+b1) (**)
  openmpi-bin (<< 4.0.2-4+b1) (**)
  starpu-contrib-examples (<< 1.3.2+dfsg-2+b1) (*)
  starpu-examples (<< 1.3.2+dfsg-4+b1) (**)
I haven't tried if they cause crashes as well ... I just tried to find
the first version no longer depending on libhwloc5 (either because it
switched to libhwloc15 (*) or because it just dropped the dependency
(**)).

So I would recomend to add these to libopenmpi3:
Breaks: gromacs-openmpi (<< 2020~beta2-2), libeztrace0 (<< 1.1-8-5+b1), 
openmpi-bin (<< 4.0.2-4+b1), starpu-contrib-examples (<< 1.3.2+dfsg-2+b1), 
starpu-examples (<< 1.3.2+dfsg-4+b1)
(They can go with the next soname bump or after bullseye was released).

Andreas



Bug#961552: gnome-contacts: org.gnome.Contacts.png files are not installed

2020-05-26 Thread Simon Désaulniers
Hi,

> apt-file looks at all the apt sources you have available, so you're seeing
> the PNG icons in the version in stable. To see what's in the version you
> actually have installed, use `dpkg -L gnome-contacts`.

Thanks for clarification! I didn't realize that apt-file was not looking into
the right branch.

Yeah. I should have used `dpkg`.

> It looks as though since 3.31.3, gnome-contacts only installs scalable
> icons in SVG format. This appears to have been a deliberate upstream
> change. Is Awesome unable to display those?

So finally, I think that you're half right: yes it is about Awesome, but it's
not that it doesn't read SVG, but it's that it's giving up on scanning the whole
directory since the current code for doing that is not yet efficient enough.

https://github.com/awesomeWM/awesome/issues/908

This issue can be closed I think. Thank you for your quick and bright response!

Regards,

On Tue, May 26, 2020 at 09:01:32AM +0100, Simon McVittie wrote:
> Control: retitle -1 gnome-contacts: only has scalable SVG icons, not bitmap 
> PNG icons
> 
> On Mon, 25 May 2020 at 18:24:54 -0400, Simon Désaulniers wrote:
> > After installing the package, the icon files are not installed on the 
> > system.
> > According to apt-file, they should be installed at the following paths:
> > 
> > gnome-contacts: 
> > /usr/share/icons/hicolor/16x16/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/22x22/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/32x32/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/48x48/apps/org.gnome.Contacts.png
> > gnome-contacts: 
> > /usr/share/icons/hicolor/512x512/apps/org.gnome.Contacts.png
> 
> apt-file looks at all the apt sources you have available, so you're seeing
> the PNG icons in the version in stable. To see what's in the version you
> actually have installed, use `dpkg -L gnome-contacts`.
> 
> It looks as though since 3.31.3, gnome-contacts only installs scalable
> icons in SVG format. This appears to have been a deliberate upstream
> change. Is Awesome unable to display those?
> 
> smcv

-- 
Simon Désaulniers
sim.desaulni...@gmail.com


signature.asc
Description: PGP signature


Bug#961630: redmine: please update to redmine 4.1

2020-05-26 Thread Michael Meier
Package: redmine
Severity: wishlist

Redmine 4.1 is available. It would be great if we could update to it.



-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (400, 'testing'), (300, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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)
LSM: AppArmor: enabled

Versions of packages redmine depends on:
pn  dbconfig-common 
ii  debconf [debconf-2.0]   1.5.71
pn  libjs-chart.js  
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-jquery-ui 1.12.1+dfsg-5
pn  libjs-raphael   
pn  redmine-sqlite | redmine-mysql | redmine-pgsql  
ii  ruby1:2.5.1
pn  ruby-actionpack-action-caching  
pn  ruby-actionpack-xml-parser  
pn  ruby-bundler
pn  ruby-coderay
pn  ruby-csv
pn  ruby-i18n   
pn  ruby-jquery-rails   
pn  ruby-mail   
pn  ruby-mime-types 
pn  ruby-mimemagic  
pn  ruby-mini-mime  
pn  ruby-net-ldap   
pn  ruby-nokogiri   
pn  ruby-rack   
pn  ruby-rack-test  
pn  ruby-rails  
pn  ruby-rails-dom-testing  
pn  ruby-rails-observers
pn  ruby-rbpdf  
pn  ruby-redcarpet  
pn  ruby-request-store  
pn  ruby-rmagick
pn  ruby-roadie 
pn  ruby-roadie-rails   
pn  ruby-rouge  

Versions of packages redmine recommends:
pn  passenger  

Versions of packages redmine suggests:
pn  bzr 
pn  cvs 
pn  darcs   
ii  git 1:2.26.2-1~bpo10+1
pn  mercurial   
pn  ruby-fcgi   
pn  subversion  



Bug#961629: python3-virtualenv: Fails to create a Python 3.7 environment

2020-05-26 Thread Alexander Clausen
Package: python3-virtualenv
Version: 20.0.21+ds-1
Severity: important

Dear Maintainer,

trying to create a Python 3.7 virtualenv fails, while Python 3.8 works,
as follows:

$ python3 -m virtualenv --no-download --python /usr/bin/python3.8 bleh 
created virtual environment CPython3.8.3.final.0-64 in 231ms
  creator CPython3Posix(dest=/home/alex/bleh, clear=False, global=False)
  seeder FromAppData(download=False, pip=latest, setuptools=latest, 
wheel=latest, pkg_resources=latest, via=copy, 
app_data_dir=/home/alex/.local/share/virtualenv/seed-app-data/v1.0.1.debian)
  activators 
BashActivator,CShellActivator,FishActivator,PowerShellActivator,PythonActivator,XonshActivator
$ python3 -m virtualenv --no-download --python /usr/bin/python3.7 bleh 
RuntimeError: failed to query /usr/bin/python3.7 with code 1 err: 'Traceback 
(most recent call last):\n  File 
"/usr/lib/python3/dist-packages/virtualenv/discovery/py_info.py", line 16, in 
\nfrom distutils import dist\nImportError: cannot import name 
\'dist\' from \'distutils\' (/usr/lib/python3.7/distutils/__init__.py)\n'
$ python3 --version
Python 3.8.3

This also breaks, for example, tox.

Thanks,
Alexander

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (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 python3-virtualenv depends on:
ii  python-pip-whl  20.1.1-1
ii  python3 3.8.2-3
ii  python3-appdirs 1.4.4-1
ii  python3-distlib 0.3.0-1
ii  python3-distutils   3.8.3-2
ii  python3-filelock3.0.12-2
ii  python3-importlib-metadata  1.6.0-1
ii  python3-pip 20.1.1-1
ii  python3-pkg-resources   46.1.3-1
ii  python3-six 1.15.0-1

python3-virtualenv recommends no packages.

python3-virtualenv suggests no packages.

-- no debconf information



Bug#960836: buster-pu: package gnutls28/3.6.7-4+deb10u4

2020-05-26 Thread Andreas Metzler
Control: tags 960836 + moreinfo

Please hold on approving this. I will probably need to add a fix for
https://gitlab.com/gnutls/gnutls/-/issues/997

cu Andreas



Bug#961628: RFS: shotwell/0.30.10-1 -- digital photo organizer

2020-05-26 Thread Jörg Frings-Fürst
Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "shotwell"

   Package name: shotwell
   Version : 0.30.10-1
   Upstream Author : Jim Nelson 
   URL : https://wiki.gnome.org/Apps/Shotwell
   License : LGPL-2.1
   Vcs : https://jff.email/cgit/shotwell.git
   Section : gnome

It builds those binary packages:

  shotwell - digital photo organizer
  shotwell-common - digital photo organizer - common files

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/shotwell

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/shotwell/shotwell_0.30.10-1.dsc

or from git:

  https://jff.email/cgit/shotwell.git/?h=release%2Fdebian%2F0.30.10-1
  
Changes since the last upload:

   * New upstream release.
 - Remove debian/patches/0115-fix_meson_build.patch.
   * debian/shotwell.manpages:
 - Install from debin/tmp to make dh_missing happy.
   * debian/shotwell.install:
 - Install from debin/tmp to make dh_missing happy.
   * debian/control:
 - Switch to debhelper-compat level 13.

CU
Jörg Frings-Fürst

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser


git:  https://jff.email/cgit/

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst


My wish list: 
 - Please send me a picture from the nature at your home.



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


Bug#961626: RM: yagtd -- RoQA; Depends on Python 2, dead upstream, unmaintained

2020-05-26 Thread Moritz Muehlenhoff
Package: ftp.debian.org
Severity: normal

Please remove yagtd. It depends on Python 2, is dead upstream (homepage
vanished along with gna.org) and the last maintainer uploas was in 2011.

Cheers,
Moritz



Bug#936777: k3d: Python2 removal in sid/bullseye

2020-05-26 Thread Moritz Mühlenhoff
On Wed, Sep 04, 2019 at 12:10:39AM +0200, Manuel A. Fernandez Montecelo wrote:
> Control: forwarded -1 https://github.com/K-3D/k3d/issues/38
> 
> Thanks for the report.  Asking upstream about their plans and best
> course of action.

Given upstream's reply at https://github.com/K-3D/k3d/issues/38 this
seems unlikely to get ported, let's remove k3d?

Cheers,
Moritz



Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds

2020-05-26 Thread Marcin Juszkiewicz
W dniu 26.05.2020 o 20:33, Alper Nebi Yasak pisze:
> Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds

>> And that's plain wrong.
>>
>> I want to run D-I on my monitor. Nevermind is it text mode one or gtk
>> one. My board does not require serial console to boot as I have
>> graphical output in U-Boot and can control it using USB keyboard.
> 
> I agree they should be included, so I'm changing bug metadata to that 
> (hopefully correctly).

Thanks!



Bug#961590: Include drm modules in non-gtk arm64 cdrom initrds

2020-05-26 Thread Alper Nebi Yasak

Control: reassign -1 debian-installer
Control: severity -1 normal
Control: retitle -1 Include drm modules in non-gtk arm64 cdrom initrds
Control: tag -1 patch

On 26/05/2020 20:40, Marcin Juszkiewicz wrote:

There are two initrds in that iso, 'install.a64/initrd.gz' doesn't
have drm modules, but the 'install.a64/gtk/initrd.gz' one has them.
Can you try booting the gtk one? If you boot to GRUB, 'Graphical
Install' should be using that.


And that's plain wrong.

I want to run D-I on my monitor. Nevermind is it text mode one or gtk
one. My board does not require serial console to boot as I have
graphical output in U-Boot and can control it using USB keyboard.


I agree they should be included, so I'm changing bug metadata to that 
(hopefully correctly).



And I prefer text mode D-I over gtk one.


You can also add DEBIAN_FRONTEND=newt to the kernel cmdline to force 
that in the gtk builds.


--

Haven't really tested, but this change should be enough:

diff --git a/build/pkg-lists/cdrom/arm64.cfg 
b/build/pkg-lists/cdrom/arm64.cfg

index bb5b3a6ff..672d00a64 100644
--- a/build/pkg-lists/cdrom/arm64.cfg
+++ b/build/pkg-lists/cdrom/arm64.cfg
@@ -1,6 +1,7 @@
 fat-modules-${kernel:Version}
 cdrom-core-modules-${kernel:Version}
 input-modules-${kernel:Version}
+fb-modules-${kernel:Version}
 console-setup-udeb
 kbd-udeb
 usb-modules-${kernel:Version}



Bug#961625: RM: libtuxcap -- RoQA; Python 2, unmaintained, no-reverse dependencies

2020-05-26 Thread Sebastian Ramacher
Package: ftp.debian.org
Severity: normal

Please remove libtuxcap from unstable. It has no reverse dependencies,
blocks Python 2 removal (#936928) and is NMU-maintained since 2011.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#961454: dahdi-dkms: Cannot compile using DKMS on kernel 5.4 backport and latter

2020-05-26 Thread Patrick ZAJDA

Hello,


It looks like the same issue as 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948983 




If I don't make a mistake, the error is the same.



Bug#961621: Node.js requires SSE2

2020-05-26 Thread Frank de Jong
No, this issue is not related to #922075, because, in my case, nodejs 
segfaults at startup, not further up ahead (I tried the npm install cmd 
in #922075). I am not sure where the dependency should be declared; I 
tried recompiling Node.js and noticed that the entire build is SSE2 
optimised.




Bug#961604: History was empty on first startup, but appeared on second launch

2020-05-26 Thread Oliver Sauder
This is a known issue see https://bugs.launchpad.net/diodon/+bug/1435033

Unfortunately so far it is not quite clear what causes this. Any
comments are welcome.

Oliver

On 26.05.20 16:58, Christoph Berg wrote:
> Package: diodon
> Version: 1.9.0-1
> Severity: normal
> 
> Hi,
> 
> I just started using diodon because clipit notified me that it is
> gone.
> 
> On the first startup, I selected some options (notably to track the
> primary selection and to sync selections), and tried to select some
> things. The history in the diodon systray icon remained empty
> ("").
> 
> Upon killing diodon and restarting it, things started working.
> 
> Using awesome, no gnome or other DE.
> 
> $ diodon
> 
> (diodon:29053): dbind-WARNING **: 16:58:18.339: Couldn't connect to 
> accessibility bus: Failed to connect to socket /tmp/dbus-Dz5rIZiGzD: 
> Verbindungsaufbau abgelehnt
> 
> (diodon:29053): Gdk-CRITICAL **: 16:58:18.535: 
> gdk_window_thaw_toplevel_updates: assertion 
> 'window->update_and_descendants_freeze_count > 0' failed
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
> LANGUAGE=de: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 diodon depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
> ii  libappindicator3-1   0.4.92-8
> ii  libc62.30-8
> ii  libdiodon0   1.9.0-1
> ii  libglib2.0-0 2.64.2-1
> ii  libgtk-3-0   3.24.20-1
> ii  libpeas-1.0-01.26.0-2
> ii  zeitgeist-core   1.0.2-3
> 
> diodon recommends no packages.
> 
> diodon suggests no packages.
> 
> -- no debconf information
> 
> Christoph
> 



Bug#961490: fwupd: version in stable too old, no updates possible

2020-05-26 Thread Mario.Limonciello
> -Original Message-
> From: Ansgar 
> Sent: Tuesday, May 26, 2020 8:01 AM
> To: Steffen Schreiber; 961...@bugs.debian.org
> Subject: Bug#961490: fwupd: version in stable too old, no updates possible
> 
> 
> [EXTERNAL EMAIL]
> 
> Hi,
> 
> On Tue, 2020-05-26 at 13:56 +0200, Steffen Schreiber wrote:
> > So I see you marked this bug as fixed/resolved.
> 
> Someone (not the maintainer) did so, but please note that the bug
> remains open even when marked as fixed in a newer version.  Debian's
> stable release team prefers bugs to be fixed in unstable/testing before
> they get fixed in (old)stable, so this is good.

The particular circumstances of this issue are that the update in question 
requires
a newer version of fwupd than is in stable.  This is not a matter of just 
backporting
a change or two and it works.  There are daemon and plugin level changes that 
have to
go together to guarantee a proper update.

This seems incompatible with the documentation around uploading to stable.
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable
> 
> > What's the way going forward for users of stable? Installing packages
> > from testing? Are you recommending to just forget about running Debian
> > stable as is?
> 
> The maintainer hasn't yet commented on how he wants to proceed.
> Reasonable options seem to be to either update stable to the version
> currently in testing (1.3.9) or to update to a later version of 1.2.X.
> 
> Ansgar

If a particular update requires a newer fwupd version I don't think it's 
reasonable
to push that version to all Debian users who may not need the newer fwupd 
version
and might not be willing to accept the risk of regressions in a newer version.

"Fixes must be minimal and relevant"

So in this circumstance if your device needs the newer version you should 
probably
take the package from testing instead.



Bug#961398: src:quantlib-swig: fails to migrate to testing for too long: FTBFS on mipsel

2020-05-26 Thread Dirk Eddelbuettel


Paul,

Thanks for the hint. The package for mipsel is now gone, migration of
quantlib-python should now resume.

Leaves the second part.  Come to think about it I have never written an
debian/rules to _not_ build something.  So maybe something like

ifneq "$(findstring $(cpu), mipsel)" ""
  exit 1
endif

in the build-arch == build-indep == build target?

Are there examples I could look at?

Thanks again, Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org



Bug#961624: Stubby systemd service fails to start on upgrade to 1.5.2-1

2020-05-26 Thread Harry Noël
Package: stubby
  Version: 1.5.2-1

Upgrade from 1.5.1-1+b2 to 1.5.2-1 results in service failing to start
- reporting 'Error getting user config file'Downgrade to 1.5.1-1+b2
resolves issue
● stubby.service - DNS Privacy Stub Resolver Loaded: loaded
(/lib/systemd/system/stubby.service; enabled; vendor preset:
enabled) Active: failed (Result: exit-code) since Tue 2020-05-26
18:53:20 BST; 5s ago   Docs: 
https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Daemon+-+StubbyP
rocess: 12323 ExecStart=/usr/bin/stubby (code=exited,
status=1/FAILURE)   Main PID: 12323 (code=exited, status=1/FAILURE)
May 26 18:53:19 *** systemd[1]: Started DNS Privacy Stub
Resolver.May 26 18:53:20 *** stubby[12323]: Error getting user
config fileMay 26 18:53:20 *** systemd[1]: stubby.service: Main
process exited, code=exited, status=1/FAILUREMay 26 18:53:20 ***
systemd[1]: stubby.service: Failed with result 'exit-code'.
  When I invoke `hello' without arguments from an ordinary shell
  prompt it prints `goodbye', rather than the expected `hello, world'.
  Here is a transcript:

Debian Sid
Linux version 5.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc
version 9.3.0 (Debian 9.3.0-11)) #1 SMP Debian 5.6.7-1 (2020-04-29)
KR
HN


Bug#913997: what is the current maintainer view on this ?

2020-05-26 Thread Paolo Greppi
The issue has been raised again on the yarnpkg side:
https://bugs.debian.org/940511

Antonio, what is your point of view ?
Do you think we can fix this for the Bookworm release ?

Thanks,

Paolo



Bug#940511: [Pkg-javascript-devel] Bug#940511: yarnpkg: Package symlink yarn -> yarnpkg

2020-05-26 Thread Paolo Greppi
See below ...

On Wed, 20 May 2020 18:08:29 +0200 =?UTF-8?Q?Ma=C3=ABl_Nison?= 
 wrote:
> Hi, I'm Maël, Yarn's lead maintainer.
> 
> While cmdtest has a popcon score higher than the yarn package, it's mostly
> because Yarn isn't traditionally installed using the Debian package. For
> historical reasons the 1.x branch always updated it, but in general our
> users install Yarn using it's "competitor", npm. The npm numbers give a
> very different picture: Yarn is downloaded 6.1m times per month.
> 
> There are currently talks to, potentially, ship symlinks for the three main
> package managers along with Node (npm, which is already there, along with
> Yarn and maybe pnpm). These plans aren't concrete yet, but a few people
> think it's worth studying. In any case, the decision is expected to be
> taken for Node 15, which will happen this year. To the extent possible, I
> think it could be wise (and very appreciated!) to consider renaming the
> `yarn` binary from `cmdtest` before it risks becoming an actual problem.
> 
> As a last note, I pinged Lars Wirzenius (who I think was the original
> cmdtest maintainer?), back in March '19. He mentioned having recently
> retired, but seemed fairly supportive of the idea ("I've now discussed the
> name of our testing tool with its other developer and we will likely change
> the name of our program during the Debian buster+1 development cycle").
> 
> Maël

Hi Maël,

thanks for the feedback and for your Debian contribution.

I've added here the info on the bug that has to be addressed by the cmdtest
maintainer (if he agrees) for us to be able to fix this one.

I'll also ping him.

Paolo



Bug#961623: man page inconsistent on --starting-build-commands

2020-05-26 Thread John Scott
Package: sbuild
Version: 0.79.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I was looking for what sbuild option I might use if I wanted to make
gcc a symlink to Clang for a session, without modifying the source
chroot. sbuild(1) says
 --starting-build-commands=string
Run these commands after dependencies are installed, just before the
package build with dpkg-buildpackage starts. The command is run as the
(non-root) user running sbuild inside the chroot.

Non-root, so it sounds like it wouldn't do the job. However the table
lower down says this:
 command/action root   chroot%c%e%d,%p
 ──
 ...
 --starting-build-commands  yesinsidenonoyes
 Run dpkg-buildpackage

This indicates that the commands *are* run as root. Since my symlink
command works it's probably the former that's wrong.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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

Versions of packages sbuild depends on:
ii  adduser 3.118
ii  libsbuild-perl  0.79.1-1
ii  perl5.30.2-1

Versions of packages sbuild recommends:
ii  autopkgtest  5.13.1
ii  debootstrap  1.0.123
ii  schroot  1.6.10-9

Versions of packages sbuild suggests:
pn  deborphan  
ii  e2fsprogs  1.45.6-1
ii  kmod   27+20200310-2
ii  wget   1.20.3-1+b2

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXs1aRwAKCRByvHFIwKst
pxYDAP4xyewcKqSpw2tyL/wUsz4gCtJtKYmMZsoffglsR1N+IwEA+ksPKh4e3ib+
tFDYoMDx/E64lO0H8RQaRtPY46nRVAU=
=eQ+e
-END PGP SIGNATURE-


Bug#961621: [Pkg-javascript-devel] Bug#961621: Node.js requires SSE2

2020-05-26 Thread Jérémy Lal
Le mar. 26 mai 2020 à 19:45, Frank  a écrit :

> Package: nodejs
> Version: 10.19.0~dfsg1-1
> Severity: minor
>
> Node.js will not run on i686 hardware such as Intel Pentium 3 or AMD
> Athlon XP.
> Support for x86 hardware without SSE2 has (unfortunately) been removed
> years ago, see
> https://groups.google.com/forum/#!topic/v8-dev/SJU63-g84fQ
> Package should therefore depend on package sse2-support (i386 arch
> only).
>

Thank you for that.
I suppose the dependency should be declared on libnodeXX, not on node
itself.
Might it be related to https://bugs.debian.org/922075 ?

Jérémy


Bug#875733: same with buster

2020-05-26 Thread Tomas Pospisek

I get this same behavior under Debian buster:

# cat /var/lib/lxc/foobar/config
[...]
lxc.cap.drop = sys_admin
[...]

foobar ist a container with systemd inside.

# lxc-start foobar

lxc-start foobar -F
lxc-start: foobar: conf.c: lxc_mount_auto_mounts: 770 No such file or directory - 
Failed to mount "/sys/fs/cgroup"

If I comment out "lxc.cap.drop = sys_admin" then the container succeeds to 
start.


Has anybody succeeded in running systemd inside an LXC container with 
"lxc.cap.drop = sys_admin" ?


*t



Bug#961622: segfault on watching any stream

2020-05-26 Thread Lee Garrett
Package: gnome-twitch
Version: 0.4.1-3
Severity: grave

Hi,

current gnome-twitch will segfault on any stream selected. I've tried the
gstreamer-cairo and gstreamer-opengl backend to verify it's not backend related.

It starts fine, but selecting any stream will give the following output:
$ gnome-twitch 
[17:49:27] Message - GNOME-Twitch : {GtApp:370} Startup, running version '0.4.1'
[17:49:27] Message - GNOME-Twitch : {GtFollowsManager:254} Follows file at 
'/home/randall/.local/share/gnome-twitch/followed-channels.json' doesn't exist
[17:49:27] Message - GNOME-Twitch : {GtApp:339} Activate
[17:49:27] Message - GNOME-Twitch : {GtPlayer:132} Loading chat settings
[17:49:29] Message - GNOME-Twitch : {GtPlayer:1287} Can't open channel, no 
backend loaded
[17:49:33] Message - GNOME-Twitch : {GtPlayer:999} Loaded player backend 
'GStreamer Cairo player backend'
[17:49:33] Message - GNOME-Twitch : {GtPlayerBackendGstreamerCairo:246} Init
[17:49:33] Critical - GLib-GObject : g_object_get: assertion 'G_IS_OBJECT 
(object)' failed
[17:49:33] Warning - GNOME-Twitch : cannot set NULL uri
[17:49:33] Critical - Gtk : gtk_widget_add_events: assertion 'GTK_IS_WIDGET 
(widget)' failed
[17:49:33] Critical - Gtk : gtk_widget_set_can_focus: assertion 'GTK_IS_WIDGET 
(widget)' failed
[17:49:33] Critical - Gtk : gtk_container_add: assertion 'GTK_IS_WIDGET 
(widget)' failed
[17:49:33] Warning - GLib-GObject : invalid (NULL) pointer instance
[17:49:33] Critical - GLib-GObject : g_signal_connect_data: assertion 
'G_TYPE_CHECK_INSTANCE (instance)' failed
[17:49:33] Warning - GLib-GObject : invalid (NULL) pointer instance
[17:49:33] Critical - GLib-GObject : g_signal_connect_data: assertion 
'G_TYPE_CHECK_INSTANCE (instance)' failed
[17:49:33] Message - GNOME-Twitch : {GtPlayer:1310} Opening stream 'asmongold' 
with quality 'source'
[17:49:33] Warning - GNOME-Twitch : {GtTwitch:336} Received unsuccessful 
response from url 'https://api.twitch.tv/api/channels/asmongold/access_token' 
with code '410' and body '{"error":"Gone","status":410,"message":"this API has 
been removed."}'
[17:49:33] Warning - GNOME-Twitch : {GtTwitch:594} Error getting stream access 
token for channel 'asmongold' because: Received unsuccessful response from url 
'https://api.twitch.tv/api/channels/asmongold/access_token' with code '410' and 
body '{"error":"Gone","status":410,"message":"this API has been removed."}'
Segmentation fault

Regards,
Lee

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.14 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gnome-twitch depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libc62.30-8
ii  libgdk-pixbuf2.0-0   2.40.0+dfsg-4
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libjson-glib-1.0-0   1.4.4-2
ii  libpeas-1.0-01.26.0-2
ii  libsoup2.4-1 2.70.0-1
ii  libwebkit2gtk-4.0-37 2.28.2-2
ii  libx11-6 2:1.6.9-2+b1

Versions of packages gnome-twitch recommends:
ii  gnome-twitch-player-backend-gstreamer-cairo  0.4.1-3

gnome-twitch suggests no packages.

-- no debconf information



Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

2020-05-26 Thread Marcin Juszkiewicz


W dniu 26.05.2020 o 19:25, Alper Nebi Yasak pisze:
> On 26/05/2020 20:09, Marcin Juszkiewicz wrote:
>> RockPro64 does not enable screen at all. And there are no DRM
>> modules in netinstall image [1]:
>> 
>> ~ # cd /lib/modules/5.6.0-1-arm64/ /lib/modules/5.6.0-1-arm64 #
>> find . -name *drm* /lib/modules/5.6.0-1-arm64 #
>> 
>> 1.
>> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso
>
>> 
> There are two initrds in that iso, 'install.a64/initrd.gz' doesn't
> have drm modules, but the 'install.a64/gtk/initrd.gz' one has them.
> Can you try booting the gtk one? If you boot to GRUB, 'Graphical
> Install' should be using that.

And that's plain wrong.

I want to run D-I on my monitor. Nevermind is it text mode one or gtk
one. My board does not require serial console to boot as I have
graphical output in U-Boot and can control it using USB keyboard.

And I prefer text mode D-I over gtk one.

> However, that image is currently broken due to a kernel version
> mismatch and won't actually install, try the weekly build instead:
> 
> https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso

Thanks. Works like a charm.



Bug#961621: Node.js requires SSE2

2020-05-26 Thread Frank

Package: nodejs
Version: 10.19.0~dfsg1-1
Severity: minor

Node.js will not run on i686 hardware such as Intel Pentium 3 or AMD 
Athlon XP.
Support for x86 hardware without SSE2 has (unfortunately) been removed 
years ago, see 
https://groups.google.com/forum/#!topic/v8-dev/SJU63-g84fQ
Package should therefore depend on package sse2-support (i386 arch 
only).


Error can be reproduced in a QEMU VM with options "qemu-system-i386 
-enable-kvm -cpu athlon,sse2=off". Execute cmd "nodejs" in the VM.


stdout error: Check failed: cpu.has_sse2(). FailureMessage Object: 
0xbfc159a4Illegal instruction
dmesg error: traps: nodejs[23846] trap invalid opcode ip:b6e95db5 
sp:bffdac50 error:0 in libnode.so.64[b6e49000+b78000]




Bug#961620: Way too many false positives for package-supports-alternative-init-but-no-init.d-script

2020-05-26 Thread Michael Biebl
Am 26.05.20 um 19:22 schrieb Michael Biebl:

> Looking at package-supports-alternative-init-but-no-init.d-script ...
... at
https://lintian.debian.org/tags/package-supports-alternative-init-but-no-init.d-script.html
to be specific

The first three packages being 389-ds-base, accountsservice and
alsa-utils. accountsservice and alsa-utils are false positives.



signature.asc
Description: OpenPGP digital signature


Bug#961620: Acknowledgement (Way too many false positives for package-supports-alternative-init-but-no-init.d-script)

2020-05-26 Thread Michael Biebl
I would like to add that the specific section of the debian policy
(9.11) which triggered the addition of this lintian check, has been
deleted in the mean time.



signature.asc
Description: OpenPGP digital signature


Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

2020-05-26 Thread Alper Nebi Yasak

On 26/05/2020 20:09, Marcin Juszkiewicz wrote:
 > RockPro64 does not enable screen at all. And there are no DRM modules in

netinstall image [1]:

~ # cd /lib/modules/5.6.0-1-arm64/
/lib/modules/5.6.0-1-arm64 # find . -name *drm*
/lib/modules/5.6.0-1-arm64 #

1. 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso


There are two initrds in that iso, 'install.a64/initrd.gz' doesn't have 
drm modules, but the 'install.a64/gtk/initrd.gz' one has them. Can you 
try booting the gtk one? If you boot to GRUB, 'Graphical Install' should 
be using that.


However, that image is currently broken due to a kernel version mismatch 
and won't actually install, try the weekly build instead:


https://cdimage.debian.org/cdimage/weekly-builds/arm64/iso-cd/debian-testing-arm64-netinst.iso



Bug#961620: Way too many false positives for package-supports-alternative-init-but-no-init.d-script

2020-05-26 Thread Michael Biebl
Package: lintian
Version: 2.76.0
Severity: normal

Looking at package-supports-alternative-init-but-no-init.d-script, it
seems this lintian check triggers a lot of false positives.

Just picking the first 3, already has 2 false positives. Imho that
ratio is a sign that either it should be lowered to pedantic, improved
significantly or removed.

Michael

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils 2.34-8
ii  bzip21.0.8-2
ii  diffstat 1.63-1
ii  dpkg 1.19.7
ii  dpkg-dev 1.19.7
ii  file 1:5.38-5
ii  gettext  0.19.8.1-10
ii  gpg  2.2.20-1
ii  intltool-debian  0.35.0+20060710.5
ii  libapt-pkg-perl  0.1.36+b3
ii  libarchive-zip-perl  1.68-1
ii  libcapture-tiny-perl 0.48-1
ii  libclass-xsaccessor-perl 1.19-3+b4
ii  libclone-perl0.45-1
ii  libcpanel-json-xs-perl   4.19-1
ii  libdevel-size-perl   0.83-1+b1
ii  libdigest-sha-perl   6.02-1+b2
ii  libdpkg-perl 1.19.7
ii  libemail-valid-perl  1.202-1
ii  libfile-basedir-perl 0.08-1
ii  libfile-find-rule-perl   0.34-1
ii  libfont-ttf-perl 1.06-1
ii  libhtml-parser-perl  3.72-5
ii  libio-async-loop-epoll-perl  0.20-1
ii  libio-async-perl 0.75-1
ii  libjson-maybexs-perl 1.004002-1
ii  liblist-compare-perl 0.53-1
ii  liblist-moreutils-perl   0.416-1+b5
ii  libmoo-perl  2.004000-1
ii  libmoox-aliases-perl 0.001006-1
ii  libnamespace-clean-perl  0.27-1
ii  libpath-tiny-perl0.112-1
ii  libsereal-decoder-perl   4.011+ds-1
ii  libsereal-encoder-perl   4.011+ds-1
ii  libtext-levenshtein-perl 0.13-1
ii  libtimedate-perl 2.3300-1
ii  libtry-tiny-perl 0.30-1
ii  libtype-tiny-perl1.010001-1
ii  libunicode-utf8-perl 0.62-1+b1
ii  liburi-perl  1.76-2
ii  libxml-libxml-perl   2.0134+dfsg-2
ii  libxml-writer-perl   0.625-1
ii  libyaml-libyaml-perl 0.82+repack-1
ii  man-db   2.9.1-1
ii  patchutils   0.3.4-2+b1
ii  perl [libdigest-sha-perl]5.30.2-1
ii  t1utils  1.41-4
ii  xz-utils 5.2.4-1+b1

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b6

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  libtext-template-perl  1.58-1

-- no debconf information



Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

2020-05-26 Thread Marcin Juszkiewicz
W dniu 26.05.2020 o 16:41, Alper Nebi Yasak pisze:
> On 26/05/2020 15:03, Marcin Juszkiewicz wrote:
>> Devices with Mali gpu can use 'panfrost' driver to provide working
>> framebuffer. And then Debian installer can be run on screen instead of
>> serial console.
>>
>> But 'panfrost' module is not available when d-i starts ;(
>>
>> So please include 'panfrost' in 'fb-modules' udeb.
> 
> Panfrost shouldn't be necessary for a working framebuffer. On my
> rk3399-gru-kevin, rockchipdrmfb handles that and d-i runs on the
> screen just fine.
> 
> Which device are you having this issue with?

RockPro64 does not enable screen at all. And there are no DRM modules in
netinstall image [1]:

~ # cd /lib/modules/5.6.0-1-arm64/
/lib/modules/5.6.0-1-arm64 # find . -name *drm*
/lib/modules/5.6.0-1-arm64 # 

1. 
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/arm64/iso-cd/debian-testing-arm64-netinst.iso



Bug#961619: ITP: libmath-cephes-perl -- perl interface to the math cephes library

2020-05-26 Thread Étienne Mollier
Package: wnpp
Owner: Etienne Mollier 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org, 
debian-...@lists.debian.org

* Package name: libmath-cephes-perl
  Version : 0.5305
  Upstream Author : Shlomi Fish 
* URL : https://metacpan.org/release/Math-Cephes
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : perl interface to the math cephes library

Math::Cephes provides an interface to over 150 mathematical functions of the
cephes math library of Stephen Moshier, including trigonometric, hyperbolic,
exponential, logarithmic, Bessel, Gamma, Beta, elliptic integrals,
hypergeometric, distribution functions, etc.

Some common constants, such as PI and SQRT2, are also available.  As well,
there is support for arithmetic operations for fractions (adding, subtracting,
dividing, multiplying) and also for various functions of complex numbers.

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.

This package is one of the dependencies of Statistics::PCA,
which in turn is necessary to enable PCA graphs in the package
prinseq-lite.  The source code of the package for Math::Cephes
is available on Salsa:

https://salsa.debian.org/perl-team/modules/packages/libmath-cephes-perl

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/



Bug#961481: ceph: Protocol incompatibility between armhf and amd64

2020-05-26 Thread Val Lorentz
Thanks for the tip.

I just tried downgrading an OSD (armhf) and a monitor (amd64) to
14.2.7-1~bpo10+1 using http://snapshot.debian.org/ ; but they are still
unable to communicate ("failed decoding of frame header:
buffer::bad_alloc").

So this might be a different issue, although related.



Bug#961617: RM: python-box2d -- ROM; obsolete since sugar-pippy-activity 75-1

2020-05-26 Thread Jonas Smedegaard
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi ftpmaster,

Please drop python-box2d from unstable: It is no longer needed by Sugar,
since src:sugar-pippy-activity 75-1.

 - Jonas

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl7NRKUACgkQLHwxRsGg
ASEajA/+JJg4jRHgZdzrzmDw4d+e9bkmaFOBzjs/YHswWiaaewAtjGsRvLpCkSCa
j1iLGQlGKSMGKSMqgZ7EY5sG3xAjQyEJr15rnL0UeZqbEfYWuPo+AOHs3TRc9tYI
VNt1fjYewq06vMSnYAE6rp9VPZnrsZT+LCjUdEBK1Fll9mxg4oJ204xxBGMDUAQ/
dB/LaZ7ZYRuJ2W4XZmgMzsB67f7mLrdPftwWChbwxTkxyvRazGP/rApuoKoN2/Wk
GAx1Ouc9wwnwmdueiK6R/AIqUG0PUAPH7UIFnLnTUOoo8RWoVTd/+DWqgJQlIsoo
TBVBmXFdoUnq0NLOKuvwBeDp095jCLzJDCFcdAi+/KOQhHkZJVgrz5xnMU8t0xEu
LMgqaveqhMlogXGL2IyDn9/O0+hK8vTt+CxSFQAdtP+fOggXCSLbkwFSlX1f0jpv
LaJ+5Ct92QvG/8pdQ1jytwql4rsrl4po6KXi4KVb15FXINl8aZXrZjx05B3K+3+O
KkExDvI8gmwtHvhaErlXxEHvJ9ErzDYfVKSpcp0oCw2bvibXdNp5lVA4dHCI5h7g
x5kVt3VplQJ6fG4arLhKKsPn0ERUnlVm3zuAumadVB6AJXPhuE6PD0y90wL/uBk2
h7iKrpIHv7Qug133a8UmmAK61G7wEvQDSFHwrlmZZsPBAFBwA8o=
=KHus
-END PGP SIGNATURE-



Bug#912846: grub2: stop depending on ttf-dejavu-core

2020-05-26 Thread Daniel Kiper
Hi,

In general I am OK with the patch. However, I want to ask you to respot
it using "git send-email". Additionally, please add proper commit message
and your SOB.

Daniel

On Sat, May 23, 2020 at 06:02:35PM +0200, Fabian Greffrath wrote:
> Control: forwarded -1 grub-de...@gnu.org
> Control: tags -1 upstream
>
> Hi grub devs,
>
> the attached patch adds /usr/share/fonts/truetype/dejavu to the DejaVu
> font search path in configure.ac. This is the directory where the
> fonts-dejavu-core package in Debian installs its fonts.
>
> Thanks!
>
>  - Fabian
>

> From a696233f623e9c2b480aa3ad10aed537c2890af6 Mon Sep 17 00:00:00 2001
> From: Fabian Greffrath 
> Date: Tue, 19 May 2020 12:19:26 +0200
> Subject: [PATCH] add /u/s/fonts/truetype/dejavu to the DejaVu fonts search
>  paths
>
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index b2576b0..41b8758 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1669,7 +1669,7 @@ fi
>
>  if test x"$starfield_excuse" = x; then
> for ext in pcf pcf.gz bdf bdf.gz ttf ttf.gz; do
> - for dir in . /usr/src /usr/share/fonts/X11/misc 
> /usr/share/fonts/truetype/ttf-dejavu /usr/share/fonts/dejavu 
> /usr/share/fonts/truetype; do
> + for dir in . /usr/src /usr/share/fonts/X11/misc 
> /usr/share/fonts/truetype/dejavu /usr/share/fonts/truetype/ttf-dejavu 
> /usr/share/fonts/dejavu /usr/share/fonts/truetype; do
>  if test -f "$dir/DejaVuSans.$ext"; then
>DJVU_FONT_SOURCE="$dir/DejaVuSans.$ext"
>break 2
> --
> 2.26.2



Bug#961609: Updating the xsunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: xsunpinyin
Version: 2.0.3-6
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the xsunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961613: Updating the ocserv Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: ocserv
Version: 0.12.6-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the ocserv package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961612: Updating the spice-html5 Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: spice-html5
Version: 0.1.7-4
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the spice-html5 package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961616: Updating the fcoe-utils Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: fcoe-utils
Version: 1.0.32+git20190507.9834b34-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the fcoe-utils package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961615: Updating the ibus-sunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: ibus-sunpinyin
Version: 2.0.3+git20181120-5
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the ibus-sunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961610: Updating the tigervnc Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: tigervnc
Version: 1.10.1+dfsg-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the tigervnc package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961611: Updating the sunpinyin Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: sunpinyin
Version: 3.0.0~rc1+ds1-3
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the sunpinyin package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961614: Updating the lldpad Uploaders list

2020-05-26 Thread Mattia Rizzolo
Source: lldpad
Version: 1.0.1+git20200210.2022b0c-2
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Liang Guo  has retired, so can't work on
the lldpad package anymore (at least with this address).

We are tracking their status in the MIA team and would like to ask you
to remove them from the Uploaders list of the package so we can close
that part of the file.

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#960302: [Pkg-roundcube-maintainers] Bug#960302: imap retry must be tunable

2020-05-26 Thread Matus UHLAR - fantomas

On 24.05.20 01:34, Sandro Knauß wrote:

Well I tried several times to reach upstream and they are often not answering.
Never the less I created a pull request with an updated version, that does no
retry for unrecoverable failures like authentication failure, no password,
configuration failure. That should improve the situation already in this issue.

@Matus UHLAR: please try the patch attached to the pull request if this fixes
your issue:
https://github.com/roundcube/roundcubemail/pull/7402


On 25.05.20 17:50, Matus UHLAR - fantomas wrote:

this patch works properly when invalid password is entered.


works properly even in backported version 1.4.4+dfsg.1-1~bpo10+1


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Chernobyl was an Windows 95 beta test site.



Bug#961608: O: herculesstudio -- Hercules GUI front-end

2020-05-26 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of herculesstudio, Liang Guo ,
has retired.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: herculesstudio
Binary: herculesstudio
Version: 1.5.0-2
Maintainer: Liang Guo 
Build-Depends: debhelper (>= 7.0.50~), qt5-qmake, quilt (>= 0.48-7~), 
qtbase5-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 ffc12fc3d131261b4a6821cbaae9bace 1953 herculesstudio_1.5.0-2.dsc
 0f44bbba6c9ea0217a14d2f6560213ba 368486 herculesstudio_1.5.0.orig.tar.gz
 8ea6e78f6e9e94b558b6ffd7d2345fb6 6616 herculesstudio_1.5.0-2.debian.tar.xz
Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=collab-maint/herculesstudio.git;a=summary
Vcs-Git: git://anonscm.debian.org/collab-maint/herculesstudio.git
Checksums-Sha256:
 5be5e46b98d71d8ab24f2141a040c54c46491fa2e42fccde7b5feaf6a32033d9 1953 
herculesstudio_1.5.0-2.dsc
 8cb57cd64bde1881f8896560381e8c40d9b75cd97b8cb4e5d6efdfadb65f8698 368486 
herculesstudio_1.5.0.orig.tar.gz
 d08359db52487a7e5131abe179613fc8880b7ed75d42a525024763cb98b5463c 6616 
herculesstudio_1.5.0-2.debian.tar.xz
Homepage: http://www.mvsdasd.org/hercstudio/
Package-List: 
 herculesstudio deb otherosfs extra arch=any
Directory: pool/main/h/herculesstudio
Priority: source
Section: otherosfs

Package: herculesstudio
Source: herculesstudio (1.5.0-2)
Version: 1.5.0-2+b3
Installed-Size: 1886
Maintainer: Liang Guo 
Architecture: amd64
Depends: libc6 (>= 2.14), libgcc1 (>= 1:3.0), libqt5core5a (>= 5.12.2), 
libqt5gui5 (>= 5.2.0) | libqt5gui5-gles (>= 5.2.0), libqt5network5 (>= 5.0.2), 
libqt5widgets5 (>= 5.11.0~rc1), libstdc++6 (>= 5.2), hercules (>= 3.07-2.1)
Description: Hercules GUI front-end
Description-md5: b0643232eedc59a37d975820c4239154
Homepage: http://www.mvsdasd.org/hercstudio/
Tag: admin::virtualization, implemented-in::python, interface::graphical,
 interface::x11, role::program, suite::openstack, system::cloud,
 system::virtual, uitoolkit::qt, x11::application
Section: otherosfs
Priority: optional
Filename: pool/main/h/herculesstudio/herculesstudio_1.5.0-2+b3_amd64.deb
Size: 507824
MD5sum: 9374d1fdbd1b0671c78bc8300433ede6
SHA256: 90a52b1c3c2e9670c01c4c24293e83e0f6c423c2a0d419359f0f243747f11239


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature


Bug#961607: RM: swap-cwm -- ROM; dead upstream, lack support for python3

2020-05-26 Thread Jonas Smedegaard
Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

As subject says, please drop swap-cwm from unstable:
There is no upstream activity for years and the codebase is python2 only
so unsuitable for upcoming releases of Debian.

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAl7NPbkACgkQLHwxRsGg
ASGt+Q/7B6+rzWASKiYkAFilzkh/+Hne/h43clYkM8JbqNvtWH7M5i3qtOMK+QaO
wWtSMO+J6r3b6task22X0AgF4UGNTgeRbe5lLgVB9HHNUhGawNkSLfIDV17FAhmS
9qszKCY6ojVIIs/EZKQUoSfxsIo90iNzsRsq4mtb7zzJuG63DATTCLSaWtXXHrqz
GXtqEowQp94R2pssR3HgwK/S93XPbsQs85XL/fu9ka0dcimTbqwZXKCj7B07GUDt
/PTmTL/1bSbdBX56cfG7DXRmGxvJfYGzaSP/dZDbQ0LDpt3oHwxH3SW5h8M1YHh6
1GRM6zrvVrArnj6vgWd5lCxMBjXEXjJ/j+Lvmuln25KNo/L3CAD8xO5MslqfhIMu
CLz1P69dgtf4Fiff+u4alWc8z20jsYpFPmNOd+G+PQ7gVxGbyocQeWNnipT35BYz
wfDqkUVYYeWfq59CA1ACbxCVHYEMsHTe/DxenUUCHHsUS4UgbcLjudFmBk23Ft+x
mqxmQ6gWaT5SUkkCL8+MNKIjRJYXkg/qNAcIXfDFD+uUkMKUYXDrEFEqSCJwX00m
l77i5tOacbpYXgW6dyt1y0Ty7mFe1NExZaCfCwVVTleMljv580b1TfBGOQ+O66Fj
a+wRAedIpUh/3DjRm+DKJl2HsDQTcYBT7ldXZTfDkkecA0LdS4E=
=CIcZ
-END PGP SIGNATURE-



Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

2020-05-26 Thread Axel Beckert
Hi josch,

Johannes Schauer wrote:
> > If it's similar as with mk-ci-build-deps above, this is likely a bug in
> > mk-build-deps then, just triggered by equivs.
> 
> Again, I don't want to be confrontational here.

Ok. Already forgotten. :-)

> I don't understand as much
> about equivs as you do. But what I tested is completely independent from
> mk-build-deps. What I tried was running:
> 
> equivs-build /usr/share/doc/equivs/examples/webserver.ctl
> 
> And I got the same error as Otto ("Unmet build dependencies:
> build-essential:native")

Sorry, it took me quite a while to realise that I couldn't reproduce
the problem because even in the "clean" pbuilder chroot (which is
meant for building packages) build-essential is pre-installed and
hence the build succeeds. I of course also have it installed
everywhere else where I work on equivs, too.

Then again, a hard dependency on build-essential which pulls in gcc
and g++ is definitely way too much for equivs which is aimed to be
quick and lightweight.

One idea was to add some logic to automatically decide if we can use
dpkg-buildpackage or not and if not, fall back to the old method by
calling debian/rules directly which would partially reopen #880165.

It seems as if build-essential gets automatically added to the build
dependencies by Dpkg::Vendor::Debian. So this might even be different
in other derivative distributions, hence we should neither hardcode it
as dependency nor should we test of it being installed or not.

But since equivs nearly never compiles stuff but is for metapackages,
the simple solution is probably to run dpkg-buildpackage always with
--no-check-builddeps.

Will first implement this.

A maybe a bit safer variant would be to call dpkg-checkbuilddeps
beforehand and filter out build-essential if it appears. That way
around it should hurt way less to hardcode the package name.

Will likely implement this afterwards.

Will then also merge your autopkgtest checks as they should show as
well that (or if ;-) this variant works.

P.S.: The workaround for now is to install build-essential even if not
used in the end.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE



Bug#954294: [tip: x86/urgent] x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long" (fwd)

2020-05-26 Thread Thorsten Glaser
tags 954294 + fixed-upstream
thanks

-- Forwarded message --
From: tip-bot2 for Andy Lutomirski 
Message-ID: <159050477082.17951.1414743958663563425.tip-bot2@tip-bot2>
To: linux-tip-comm...@vger.kernel.org
Cc: Thorsten Glaser , Andy Lutomirski ,
Borislav Petkov , sta...@kernel.org, x86 ,
LKML 
Date: Tue, 26 May 2020 14:52:50 -
Subject: [tip: x86/urgent] x86/syscalls: Revert
"x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"
Reply-To: linux-ker...@vger.kernel.org

The following commit has been merged into the x86/urgent branch of tip:

Commit-ID: 700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Gitweb:
https://git.kernel.org/tip/700d3a5a664df267f01ec8887fd2d8ff98f67e7f
Author:Andy Lutomirski 
AuthorDate:Fri, 08 May 2020 17:25:32 -07:00
Committer: Borislav Petkov 
CommitterDate: Tue, 26 May 2020 16:42:43 +02:00

x86/syscalls: Revert "x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long"

Revert

  45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long")

and add a comment to discourage someone else from making the same
mistake again.

It turns out that some user code fails to compile if __X32_SYSCALL_BIT
is unsigned long. See, for example [1] below.

 [ bp: Massage and do the same thing in the respective tools/ header. ]

Fixes: 45e29d119e99 ("x86/syscalls: Make __X32_SYSCALL_BIT be unsigned long")
Reported-by: Thorsten Glaser 
Signed-off-by: Andy Lutomirski 
Signed-off-by: Borislav Petkov 
Cc: sta...@kernel.org
Link: [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=954294
Link: 
https://lkml.kernel.org/r/92e55442b744a5951fdc9cfee10badd0a5f7f828.1588983892.git.l...@kernel.org
---
 arch/x86/include/uapi/asm/unistd.h   | 11 +--
 tools/arch/x86/include/uapi/asm/unistd.h |  2 +-
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/uapi/asm/unistd.h 
b/arch/x86/include/uapi/asm/unistd.h
index 196fdd0..be5e2e7 100644
--- a/arch/x86/include/uapi/asm/unistd.h
+++ b/arch/x86/include/uapi/asm/unistd.h
@@ -2,8 +2,15 @@
 #ifndef _UAPI_ASM_X86_UNISTD_H
 #define _UAPI_ASM_X86_UNISTD_H
 
-/* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT  0x4000UL
+/*
+ * x32 syscall flag bit.  Some user programs expect syscall NR macros
+ * and __X32_SYSCALL_BIT to have type int, even though syscall numbers
+ * are, for practical purposes, unsigned long.
+ *
+ * Fortunately, expressions like (nr & ~__X32_SYSCALL_BIT) do the right
+ * thing regardless.
+ */
+#define __X32_SYSCALL_BIT  0x4000
 
 #ifndef __KERNEL__
 # ifdef __i386__
diff --git a/tools/arch/x86/include/uapi/asm/unistd.h 
b/tools/arch/x86/include/uapi/asm/unistd.h
index 196fdd0..30d7d04 100644
--- a/tools/arch/x86/include/uapi/asm/unistd.h
+++ b/tools/arch/x86/include/uapi/asm/unistd.h
@@ -3,7 +3,7 @@
 #define _UAPI_ASM_X86_UNISTD_H
 
 /* x32 syscall flag bit */
-#define __X32_SYSCALL_BIT  0x4000UL
+#define __X32_SYSCALL_BIT  0x4000
 
 #ifndef __KERNEL__
 # ifdef __i386__



Bug#958414: Latest equivs version 2.3.0 breaks mk-build-deps

2020-05-26 Thread Johannes Schauer
Quoting Otto Kekäläinen (2020-05-26 15:56:04)
> Yes, installing build-essential manually has been the work-around I've
> been using. So that is now the permanent solution?

No, I think that now that equivs always uses dpkg-buildpackage instead of
manually invoking debian/rules it *must* depend on build-essential because
unless you tell dpkg-buildpackage to skip checking build dependencies, the
build-essential packages is required due to its call to dpkg-checkbuilddeps.

So as a workaround you could either:

 - install packages with recommends enabled (this will install build-essential
   because dpkg-dev recommends it)
 - or install build-essential manually

But the long-term solution is probably to add build-essential to the Depends of
equivs.

signature.asc
Description: signature


Bug#923826: python-blessed: FTBFS randomly (failing tests)

2020-05-26 Thread Santiago Vila
On Tue, May 26, 2020 at 05:19:28PM +0200, Pierre-Elliott Bécue wrote:
> Dear Santiago,
> 
> Blessed 1.17.6 will enter unstable soon, and its testing framework has
> been reworked by upstream.
> 
> Could you check if things ae running better now?

Sorry, it is extremely complex for me to try packages not in unstable with my
current setup, but I could try again once the package is in unstable.

Thanks a lot.



Bug#961606: sklearn-pandas: FTBFS: doctest error

2020-05-26 Thread Boyuan Yang
Source: sklearn-pandas
Version: 1.8.0-1
Severity: grave
Justification: FTBFS
X-Debbugs-CC: m...@cbaines.net feder...@debian.org

Dear Debian sklearn-pandas maintainers,

During a rebuild of your package, I found that your package currently
fails to build from source.


1 items had failures:
   5 of  63 in README.rst
63 tests in 1 items.
58 passed and 5 failed.
***Test Failed*** 5 failures.
E: pybuild pybuild:352: test: plugin distutils failed with: exit
code=1: cd /<>/.pybuild/cpython3_3.8_sklearn-pandas/build; 
python3.8 -m pytest ; cd {dir}; python{version} -m doctest -v
README.rst
dh_auto_test: error: pybuild --test --test-pytest -i python{version} -p
3.8 returned exit code 13
make: *** [debian/rules:7: build] Error 25
dpkg-buildpackage: error: debian/rules build subprocess returned exit
status 2


The full buildlog can be found in the attachment.

-- 
Regards,
Boyuan Yang
sbuild (Debian sbuild) 0.79.1 (22 April 2020) on hosiet-vm-home

+==+
| sklearn-pandas 1.8.0-1 (amd64)   Tue, 26 May 2020 15:17:20 + |
+==+

Package: sklearn-pandas
Version: 1.8.0-1
Source Version: 1.8.0-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: full

I: NOTICE: Log filtering will replace 
'var/run/schroot/mount/unstable-amd64-sbuild-03b399fa-6319-4a5f-82b3-6239d9035e87'
 with '<>'
I: NOTICE: Log filtering will replace 
'build/sklearn-pandas-9jnbV1/resolver-Zf4TNH' with '<>'

+--+
| Update chroot|
+--+

Hit:1 http://deb.debian.org/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

+--+
| Fetch source files   |
+--+


Local sources
-

/dev/shm/sklearn-pandas_1.8.0-1.dsc exists in /dev/shm; copying to chroot
I: NOTICE: Log filtering will replace 
'build/sklearn-pandas-9jnbV1/sklearn-pandas-1.8.0' with '<>'
I: NOTICE: Log filtering will replace 'build/sklearn-pandas-9jnbV1' with 
'<>'

+--+
| Install package build dependencies   |
+--+


Setup apt archive
-

Merged Build-Depends: debhelper-compat (= 12), build-essential, fakeroot, 
dh-python, python3-all, python3-setuptools, python3-mock, python3-pytest, 
python3-numpy, python3-pandas, python3-sklearn
Filtered Build-Depends: debhelper-compat (= 12), build-essential, fakeroot, 
dh-python, python3-all, python3-setuptools, python3-mock, python3-pytest, 
python3-numpy, python3-pandas, python3-sklearn
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in 
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [420 B]
Get:5 copy:/<>/apt_archive ./ Packages [501 B]
Fetched 1878 B in 0s (148 kB/s)
Reading package lists...
Reading package lists...

Install main build dependencies (apt-based resolver)


Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
  autoconf automake autopoint autotools-dev bsdmainutils debhelper
  dh-autoreconf dh-python dh-strip-nondeterminism dwz file gettext
  gettext-base groff-base intltool-debian libarchive-zip-perl libblas3 libbsd0
  libcroco3 libdebhelper-perl libelf1 libexpat1
  libfile-stripnondeterminism-perl libgfortran5 libglib2.0-0 libicu63
  liblapack3 liblbfgsb0 libmagic-mgc libmagic1 libmpdec2 libncurses6
  libncursesw6 libpipeline1 libprocps8 libpython3-stdlib libpython3.8-minimal
  libpython3.8-stdlib libreadline8 libsigsegv2 libsqlite3-0 libssl1.1
  libsub-override-perl libtool libuchardet0 libxml2 m4 man-db mime-support
  po-debconf procps python3 python3-all python3-atomicwrites python3-attr
  python3-dateutil python3-decorator python3-distutils
  python3-importlib-metadata python3-joblib python3-lib2to3 python3-minimal
  python3-mock python3-more-itertools python3-numpy python3-packaging
  python3-pandas python3-pandas-lib python3-pbr python3-pkg-resources
  python3-pluggy 

Bug#923826: python-blessed: FTBFS randomly (failing tests)

2020-05-26 Thread Pierre-Elliott Bécue
Dear Santiago,

Blessed 1.17.6 will enter unstable soon, and its testing framework has
been reworked by upstream.

Could you check if things ae running better now?

Thanks!

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.


signature.asc
Description: PGP signature


Bug#961481: ceph: Protocol incompatibility between armhf and amd64

2020-05-26 Thread Ard van Breemen

Hi Guys,

I've had working OSD's on armhf using 14.2.7 fixed using the workaround 
from #956293.
The OSD and mon worked on armhf 14.2.7 and amd64 14.2.8 (proxmox 
install).
When I upgraded the 14.2.7 cluster to 14.2.9, everything still worked, 
until I rebooted the proxmox server.

Everything since then just went sauer.

So: I have a complete working ceph cluster on 14.2.9 running on arm. 
ceph status works.
Mapping rbd using echo to the /sys/bus/rbd/add_single_major works (using 
the username, key and monitors from ceph.conf) on kernel 5.6.11 amd64 
and any other kernel (armhf or whatever).

So, the ceph cluster works and the protocol is still correct.

However as soon as I just want to do a ceph status on an amd64, I get an 
indefinite hanging ceph command line. No way to trace that (please tell 
me how).

This problem is limited to amd64 though.
When I install ceph on an i386 image, connecting to the ceph cluster 
works and the cluster is healthy.


So protocol wise amd64 kernel works with 32 bits clusters. But amd64 
user space does not work with 32 bits clusters.
This might be somewhere in the authentication chain, as 14.2.9 was 
working (as far as I know) until I rebooted the 64 bit system.

And I think that last CVE fix might be the problem.

Anyway, I hope this reaches someone...
Regards,
Ard van Breemen



Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

2020-05-26 Thread Jonathan Dowland

Hi!

On Mon, May 25, 2020 at 01:22:03PM +0200, Holger Wansing wrote:

This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to 
/boot
getting a size between 512 and 768MB (depending on disc size).


Thanks for fixing this,


I was not aware of this bug, so did not close it...


I'm not sure what to do with it, now. Partman is done and those bugs
archived. This is against debian-installer, and I presume there's some
lag before it picks up/bundles a fixed partman, so perhaps this bug
should track that. Can someone with more of a clue tell me if that makes
sense?


Should this be considered for backporting to stable?


And I'm guessing that should be tracked in yet another bug.



Bug#961604: History was empty on first startup, but appeared on second launch

2020-05-26 Thread Christoph Berg
Package: diodon
Version: 1.9.0-1
Severity: normal

Hi,

I just started using diodon because clipit notified me that it is
gone.

On the first startup, I selected some options (notably to track the
primary selection and to sync selections), and tried to select some
things. The history in the diodon systray icon remained empty
("").

Upon killing diodon and restarting it, things started working.

Using awesome, no gnome or other DE.

$ diodon

(diodon:29053): dbind-WARNING **: 16:58:18.339: Couldn't connect to 
accessibility bus: Failed to connect to socket /tmp/dbus-Dz5rIZiGzD: 
Verbindungsaufbau abgelehnt

(diodon:29053): Gdk-CRITICAL **: 16:58:18.535: 
gdk_window_thaw_toplevel_updates: assertion 
'window->update_and_descendants_freeze_count > 0' failed


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), 
LANGUAGE=de: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 diodon depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.36.0-1
ii  libappindicator3-1   0.4.92-8
ii  libc62.30-8
ii  libdiodon0   1.9.0-1
ii  libglib2.0-0 2.64.2-1
ii  libgtk-3-0   3.24.20-1
ii  libpeas-1.0-01.26.0-2
ii  zeitgeist-core   1.0.2-3

diodon recommends no packages.

diodon suggests no packages.

-- no debconf information

Christoph



Bug#961605: rkhunter: /bin/which moved to /usr/bin/which

2020-05-26 Thread Christoph Anton Mitterer
Package: rkhunter
Version: 1.4.6-8
Severity: normal


Hi.

The symlink /bin/which to /usr/bin/which was removed.

Please adapt the template config to use /usr/bin/which .


Cheers,
Chris.



Bug#961584: lxc-stop fails with exit code 1

2020-05-26 Thread Inaki Malerba
Source: lxc
Version: 1:4.0.2-1
Severity: important

Dear Maintainer,

Since version 1:4.0.2-1, we've found a change on the behavior of
lxc-stop when running on the Salsa-CI pipeline.

debci calls `lxc-stop --quiet --kill --name $NAME` and it's returning
exit code 1.

This can be reproduced on salsa-ci pipeline, which calls `debci localtest`.

https://salsa.debian.org/salsa-ci-team/pipeline/-/jobs/765946

: failure: ['sudo', 'timeout', '600', 'lxc-stop',
'--quiet', '--kill', '--name', 'ci-147-3f089355'] failed (exit status 1,
stderr '')


-- 
- ina



signature.asc
Description: OpenPGP digital signature


Bug#961603: RFP: verapdf -- first complete open source PDF/A validator

2020-05-26 Thread John Scott
Package: wnpp
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: verapdf
  Version : 1.16.1
  Upstream Author : Open Preservation Foundation
* URL : https://openpreservation.org/products/verapdf/
* License : GPL 3+ and MPL 2.0+
  Programming Lang: Java
  Description : first complete open source PDF/A validator

 veraPDF is the first complete open source PDF/A validator, covering all
 parts of the PDF/A standards. It comprises four components:
  • An implementation checker, which validates all parts and
conformance levels of the PDF/A specifications
  • A policy checker, which allows users to implement additional custom
checks to enforce institutional policy beyond the PDF/A specifications
  • A reporter, which processes the results, producing both human-readable
and machine-parsable reports
  • A metadata fixer, which repairs metadata in files based on conformance
with the standard
 .
 The software is accompanied by a comprehensive atomic test corpus, covering
 each clause in the PDF/A specifications.

I do not use VeraPDF yet, but think it looks very interesting. Its
description is most vocal about PDF/A, but the most recent releases
have added some support for checking PDF/UA's accessibility requirements,
so far PDF tagging in particular.

Given the scarcity of FLOSS for reading, let alone verifying, accessible
PDFs, VeraPDF is likely to play an important role this way. Its emphasis
on verifying practical usability seems strong.

It supports two backends, an in-house one and PDFBox; and also both
CLI and GUI utilities.

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQT287WtmxUhmhucNnhyvHFIwKstpwUCXs0tHAAKCRByvHFIwKst
p/6VAQD5AMZvc3tHF3GB97TbKHWZ+XQfpeiDXYTDocK71HowDwD/dMyzUNw8E4sO
qwnvTTrxaShoSY/PxEAftvvlj4f0BwY=
=jAD9
-END PGP SIGNATURE-


Bug#961590: d-i: add 'panfrost' to 'fb-modules' so graphical installer can be used

2020-05-26 Thread Alper Nebi Yasak

On 26/05/2020 15:03, Marcin Juszkiewicz wrote:

Devices with Mali gpu can use 'panfrost' driver to provide working
framebuffer. And then Debian installer can be run on screen instead of
serial console.

But 'panfrost' module is not available when d-i starts ;(

So please include 'panfrost' in 'fb-modules' udeb.


Panfrost shouldn't be necessary for a working framebuffer. On my 
rk3399-gru-kevin, rockchipdrmfb handles that and d-i runs on the screen 
just fine.


Which device are you having this issue with?



Bug#961602: castle-game-engine-doc: Depends on removed ttf-dejavu packages

2020-05-26 Thread Boyuan Yang
Package: castle-game-engine-doc
Severity: grave
Version: 6.4+dfsg1-3
Tags: sid  bullseye
X-Debbugs-CC: abou.almonta...@sfr.fr elb...@debian.org

Dear Debian castle-game-engine packagers,

Recent changes in Debian fonts-dejavu package (2.37-2) dropped the old
transitional package ttf-dejavu, ttf-dejavu-core and ttf-dejavu-extra.
[1][2] Your package still depends on them, thus will become
uninstallable.

As you can see in 
https://codesearch.debian.net/search?q=package%3Acastle-game-engine+ttf-dejavu=0
, your package is using hardcoded paths that points to the lagacy
location of the font. Please make another upload and use the new paths
provided by fonts-dejavu package.

[1] 
https://tracker.debian.org/news/1146775/accepted-fonts-dejavu-237-2-source-into-unstable/
[2] https://bugs.debian.org/872809

-- 
Regards,
Boyuan Yang


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


Bug#948087: future of aufs in Debian.

2020-05-26 Thread Jan Luca Naumann
Dear Peter,

I am in general still active but due to private stuff I was quite bad
maintaining aufs the last months, I am really sorry. I will try to take
a look into the package at the weekend. Additionally, I will create a
RFH bug, maybe somebody wants to help me so there is no single point of
failure in the future.

Best,
Jan

On 26.05.20 15:18, peter green wrote:
> The aufs package last saw a maintainer upload in September 2019 and was
> last-updated (by a NMU) in October 2019. It has had broken
> build-dependencies in testing for half a year now (since Linux 5.3.9-3
> migrated to testing in November 2019).
> 
> According to dak rm the aufs source-package has two
> reverse-dependencies, aufs-tools and fsprotect neither of which has any
> reverse-dependencies.
> 
> Adrian filed a rc bug in November 2019 which received no maintainer
> response, however the package was not autoremoved from testing due to
> aufs and aufs-tools being considered a "key packages" due to high
> popcon. This popcon actually seems to be growing in both absolute and
> percentage terms. I presume the high popcon is due to some deriviative
> (hence debian-derivatives and debian-live in cc) using aufs in their
> live image builds (as far as I can tell debian's own live images seem to
> use overlayfs instead nowadays).
> 
> aufs does seem to still be maintained upstream with upstream claiming
> support for Linux 5.6.
> 
> According to contributors.debian.net Jan Luca Naumann (the aufs
> maintainer) was last active in September 2019. Jan: are you still
> around? and if so do you still intend to maintain the aufs package? if
> not is someone else going to step up to the plate? or should these
> packages be removed from testing?



Bug#961600: cyrus-common: High CPU usage for httpd with 3.2

2020-05-26 Thread Gabriel Rolland [Res Novae]
Package: cyrus-common
Version: 3.2.0-5~bpo10+1
Severity: normal

Hi,
After the upgrade to version 3.2, the httpd process for CARD-DAV
connections reaches very high CPU usage in a short time.

-- System Information:
Debian Release: 10.4
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable'), (100, 'testing'),
(50, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages cyrus-common depends on:
ii adduser 3.118
ii db-upgrade-util 5.3.1+nmu1
ii db-util 5.3.1+nmu1
ii debconf [debconf-2.0] 1.5.71
ii e2fsprogs 1.44.5-1+deb10u3
ii exim4-daemon-heavy [mail-transport-agent] 4.92-8+deb10u4
ii gawk 1:4.2.1+dfsg-1
ii init-system-helpers 1.56+nmu1
ii libbrotli1 1.0.7-2
ii libc6 2.28-10
ii libclamav9 0.102.2+dfsg-0+deb10u1
ii libcom-err2 1.44.5-1+deb10u3
ii libgcc1 1:8.3.0-6
ii libgssapi-krb5-2 1.17-3
ii libical3 3.0.4-3
ii libicu63 63.1-6+deb10u1
ii libjansson4 2.12-1
ii libk5crypto3 1.17-3
ii libkrb5-3 1.17-3
ii libkrb5support0 1.17-3
ii libldap-2.4-2 2.4.47+dfsg-3+deb10u2
ii libnghttp2-14 1.40.0-1
ii libpcre3 2:8.39-12
ii libpq5 11.7-0+deb10u1
ii libsasl2-2 2.1.27+dfsg-1+deb10u1
ii libsasl2-modules 2.1.27+dfsg-1+deb10u1
ii libshp2 1.4.1-3
ii libsnmp30 5.7.3+dfsg-5
ii libsqlite3-0 3.27.2-3
ii libssl1.1 1.1.1d-0+deb10u3
ii libstdc++6 8.3.0-6
ii libwrap0 7.6.q-28
ii libxapian30 1.4.11-1
ii libxml2 2.9.4+dfsg1-7+b3
ii libzephyr4 3.1.2-1+b3
ii lsb-base 10.2019051400
ii netbase 5.6
ii perl 5.28.1-6
ii zlib1g 1:1.2.11.dfsg-1

Versions of packages cyrus-common recommends:
ii cyrus-admin 3.2.0-5~bpo10+1
ii cyrus-caldav 3.2.0-5~bpo10+1
ii cyrus-imapd 3.2.0-5~bpo10+1

Versions of packages cyrus-common suggests:
ii apt-listchanges 3.19
ii cyrus-admin 3.2.0-5~bpo10+1
ii cyrus-caldav 3.2.0-5~bpo10+1
ii cyrus-clients 3.2.0-5~bpo10+1
pn cyrus-doc 
ii cyrus-imapd 3.2.0-5~bpo10+1
pn cyrus-murder 
pn cyrus-nntpd 
pn cyrus-pop3d 
pn cyrus-replication 
ii sasl2-bin 2.1.27+dfsg-1+deb10u1

-- Configuration Files:
/etc/cyrus.conf changed:
START {
# do not delete this entry!
recover cmd="/usr/sbin/cyrus ctl_cyrusdb -r"
# this is only necessary if idlemethod is set to "idled" in imapd.conf
idled cmd="idled"
# this is useful on backend nodes of a Murder cluster
# it causes the backend to syncronize its mailbox list with
# the mupdate master upon startup
#mupdatepush cmd="/usr/sbin/cyrus ctl_mboxlist -m"
# this is recommended if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus expire -E 3"
# this is recommended if caching TLS sessions
tlsprune cmd="/usr/sbin/cyrus tls_prune"
}
SERVICES {
# --- Normal cyrus spool, or Murder backends ---
# add or remove based on preferences
imap cmd="imapd -U 30" listen="imap" prefork=0 maxchild=200
imaps cmd="imapd -s -U 30" listen="imaps" prefork=0 maxchild=200
#pop3 cmd="pop3d -U 30" listen="pop3" prefork=0 maxchild=50
#pop3s cmd="pop3d -s -U 30" listen="pop3s" prefork=0 maxchild=50
#nntp cmd="nntpd -U 30" listen="nntp" prefork=0 maxchild=100
#nntps cmd="nntpd -s -U 30" listen="nntps" prefork=0 maxchild=100
#http cmd="httpd -U 30" listen="8008" prefork=0 maxchild=100
https cmd="httpd -s -U 30" listen="8443" prefork=0 maxchild=100
# At least one form of LMTP is required for delivery
# (you must keep the Unix socket name in sync with imap.conf)
#lmtp cmd="lmtpd" listen="localhost:lmtp" prefork=0 maxchild=20
lmtpunix cmd="lmtpd" listen="/run/cyrus/socket/lmtp" prefork=0 maxchild=20
# --
# useful if you need to give users remote access to sieve
# by default, we limit this to localhost in Debian
sieve cmd="timsieved" listen="localhost:sieve" prefork=0 maxchild=100
# this one is needed for the notification services
notify cmd="notifyd" listen="/run/cyrus/socket/notify" proto="udp" prefork=1
# --- Murder frontends -
# enable these and disable the matching services above, # except for
sieve (which deals automatically with Murder)
# mupdate database service - must prefork at least 1
# (mupdate slaves)
#mupdate cmd="mupdate" listen=3905 prefork=1
# (mupdate master, only one in the entire cluster)
#mupdate cmd="mupdate -m" listen=3905 prefork=1
# proxies that will connect to the backends
#imap cmd="proxyd" listen="imap" prefork=0 maxchild=100
#imaps cmd="proxyd -s" listen="imaps" prefork=0 maxchild=100
#pop3 cmd="pop3proxyd" listen="pop3" prefork=0 maxchild=50
#pop3s cmd="pop3proxyd -s" listen="pop3s" prefork=0 maxchild=50
#lmtp cmd="lmtpproxyd" listen="lmtp" prefork=1 maxchild=20
# --
}
EVENTS {
# this is required
checkpoint cmd="/usr/sbin/cyrus ctl_cyrusdb -c" period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd="/usr/sbin/cyrus 

Bug#961599: Issues on depending packages on ppc64el

2020-05-26 Thread Frédéric Bonnard
Package: src:simde
Version:0.0.0.git.20200522-1

--

Dear maintainer,

since last version of simde, I noticed that bowtie2 fails on
ppc64el while it was not on a very similar version before but using
0.0.0.git.20200424-1 (I confirmed that by trying to rebuild bowtie2
2.4.1-4 which now fails)

https://buildd.debian.org/status/logs.php?pkg=bowtie2
The error reported is :
https://buildd.debian.org/status/fetch.php?pkg=bowtie2=ppc64el=2.4.1-5=1590436839=0
 I also got it with mmseqs2 .

I tried with simde's latest git tree as of 20200526 and it works. I
didn't dig more to identify precisely the problem, but you may know as
you follow simde's development more closely.


Regards,


F.
diff -Nru tnftp-20151004/debian/rules tnftp-20151004/debian/rules
--- tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
+++ tnftp-20151004/debian/rules 2020-05-10 16:01:50.0 +0200
@@ -17,6 +17,7 @@
 build: build-stamp
 build-stamp:
dh_testdir
+   dh_update_autotools_config
./configure --prefix=/usr --mandir=\$${prefix}/share/man
$(MAKE)
touch build-stamp


signature.asc
Description: PGP signature


  1   2   >