Bug#962442: ITP: mdtraj -- Read, write and analyze MD trajectories in Python

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: mdtraj
  Version : 1.9.4
  Upstream Author : Robert McGibbon and team
* URL : http://mdtraj.org/
* License : LGPL
  Programming Lang: Python
  Description : Read, write and analyze MD trajectories in Python

Read, write and analyze MD trajectories with only a few lines of
Python code.

MDTraj is a python library that allows users to manipulate molecular
dynamics (MD) trajectories. Features include:
* Wide MD format support, including pdb, xtc, trr, dcd, binpos,
netcdf, mdcrd, prmtop, and more.
* Extremely fast RMSD calculations (4x the speed of the original
Theobald QCP).
* Extensive analysis functions including those that compute
bonds, angles, dihedrals, hydrogen bonds, secondary structure, and NMR
observables.
* Lightweight, Pythonic API.

MDTraj includes a command-line application, mdconvert, for converting
trajectories between formats.

Enhances application of lammps, gromacs, and other molecular dynamics
simulation suites.

Complements or competes with pymatgen and mdanalysis. We need them all
installable in order to be able to test which one is most useful for a
given project.

To be maintained under the Debichem Team.

Bug#962440: ITP: mdanalysis -- analyse molecular dynamics files and trajectories

[Drew Parsons]

On 2020-06-08 13:30, Drew Parsons wrote:

Package: wnpp
* Package name: mdanalysis
* URL : https://www.mdanalysis.org/
  Description : analyse molecular dynamics files and trajectories



I should have added more long description:

MDAnalysis is a Python library for the analysis of computer simulations 
of many-body systems at the molecular scale, spanning use cases from 
interactions of drugs with proteins to novel materials. It is widely 
used in the scientific community and is written by scientists for 
scientists.


MDAnalysis allows one to read particle-based trajectories (including 
individual coordinate frames such as biomolecules in the PDB format) and 
access the atomic coordinates through NumPy arrays. This provides a 
flexible and relatively fast framework for complex analysis tasks. In 
addition, powerful atom selection commands are implemented. Trajectories 
can also be manipulated (for instance, fit to a reference structure) and 
written out.


It works with a wide range of popular simulation packages including 
Gromacs, Amber, NAMD, CHARMM, DL_Poly, HooMD, LAMMPS and many others — 
see the lists of supported trajectory formats and topology formats. 
MDAnalysis also includes widely used analysis algorithms in the 
MDAnalysis.analysis module.


The MDAnalysis project uses an open governance model and is fiscally 
sponsored by NumFOCUS.

Bug#962441: RFS: siconos/4.3.0+dfsg-1 [RC] -- modeling and simulation of nonsmooth dynamical systems (simulation runner tool)

[Stephen Sinclair]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: siconos
   Version : 4.3.0+dfsg-1
   Upstream Author : siconos-t...@lists.gforge.inria.fr
 * URL :
https://nonsmooth.gricad-pages.univ-grenoble-alpes.fr/siconos/index.html
 * License : Apache-2.0
 * Vcs : https://salsa.debian.org/science-team/siconos
   Section : science

It builds those binary packages:

  siconos - modeling and simulation of nonsmooth dynamical systems
(simulation runner tool)
  siconos-mechanics-tools - modeling and simulation of nonsmooth
dynamical systems (mechanics tools)
  libsiconos-numerics6 - modeling and simulation of nonsmooth
dynamical systems (numerics lib)
  libsiconos-numerics-dev - modeling and simulation of nonsmooth
dynamical systems (numerics dev)
  libsiconos-kernel6 - modeling and simulation of nonsmooth dynamical
systems (kernel lib)
  libsiconos-kernel-dev - modeling and simulation of nonsmooth
dynamical systems (kernel dev)
  libsiconos-control6 - modeling and simulation of nonsmooth dynamical
systems (control lib)
  libsiconos-control-dev - modeling and simulation of nonsmooth
dynamical systems (control dev)
  libsiconos-mechanics6 - modeling and simulation of nonsmooth
dynamical systems (mechanics lib)
  libsiconos-mechanics-dev - modeling and simulation of nonsmooth
dynamical systems (mechanics dev)
  libsiconos-io6 - modeling and simulation of nonsmooth dynamical
systems (io lib)
  libsiconos-io-dev - modeling and simulation of nonsmooth dynamical
systems (io dev)
  python3-siconos - modeling and simulation of nonsmooth dynamical
systems (python3)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/s/siconos/siconos_4.3.0+dfsg-1.dsc

Testing this package requires fclib 3.1.0+dfsg-1, which also needs
sponsorship.  It can be found here:

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

and can get downloading with dget using:

  dget -x 
https://mentors.debian.net/debian/pool/main/s/fclib/fclib_3.1.0+dfsg-1.dsc

Changes since the last upload:

   * New upstream version. (Closes: #962219) (Closes: #961735)
   * Add dependencies libboost-timer-dev, libboost-chrono-dev.
   * Depend on openblas and lapacke instead of atlas.
   * Require fclib 3.1.0
   * Update location of install paths.
   * Enable WITH_GENERATION, now required for serialization.
   * Install new siconos_export_raw_data tool.
   * Fix cmake import targets to allow independent packages.
   * Update patches for new upstream version.
   * Add a flag for gfortran to avoid a regression in GCC-10.
 (Closes: #957794)
   * Remove unused build rule for swig3.0 symlink.
   * Remove non-existent files from debian/copyright.
   * Rewrite patch descriptions using gbp pq.
   * Fix a Python warning about using 'is' with a literal.

Regards,

--
  Stephen Sinclair

Bug#962440: ITP: mdanalysis -- analyse molecular dynamics files and trajectories

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: mdanalysis
  Version : 0.20.1
  Upstream Author : O. Beckstein and team
* URL : https://www.mdanalysis.org/
* License : GPL
  Programming Lang: Python
  Description : analyse molecular dynamics files and trajectories


Enhances application of lammps, gromacs, and other molecular dynamics
simulation suites.

Complements or competes with pymatgen and mdtraj. We need them all
installable in order to be able to test which one is most useful for a
given project.

To be maintained under the Debichem Team.

Bug#781425: /etc/apt/listchanges.conf.d

[Paul Wise]

Control: forwarded -1 
https://salsa.debian.org/debian/apt-listchanges/-/merge_requests/6
Control: tags -1 + patch

On Sat, 28 Mar 2015 16:44:26 -0700 Josh Triplett wrote:

> I'd love to have an /etc/apt/listchanges.conf.d to drop configuration
> file snippets into.  That would make it easy to configure
> apt-listchanges by dropping in a configuration file (such as via a local
> package) rather than editing the existing file.

I have implemented this in the merge request linked above.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#559706: [INTL:it] eject Italian translation

[xiao sheng wen 肖盛文]

hi, Holger Wansing

    The old eject package is take over by util-linux
 [1].

so, https://salsa.debian.org/debian/eject/ isn't use now.

If the Italian translation in the new version eject package in testing
is still outdated, I  suggest to report a new bug.(the eject source code
is change)

This bug should been close now.


Thanks for your guidance.

I'm sorry for so later to reply,  email is to much.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=737658


此致！

在 2020/5/9 上午4:41, Holger Wansing 写道:
> Hi,
>
> recently you applied the Italian po file from this bug to the new eject git
> repo at salsa:
> https://salsa.debian.org/debian/eject/-/commit/e4b2394dc2f4a72d0df3f84596fd63c8a6890941
>
> That was however not done correctly:
> the file is the italian program translation, but it was inserted into 
> ../debian/po/it.po which is the translation file for the debian-installer.
>
> You can easily control that, if you check the number of contained strings:
> the program translation has 61 strings, while the debian-installer translation
> has only 1 string!
> As it is now, the Italian translation will not work!
>
>
> Moreover, there are debian patches under ../debian/patches/ which contains
> a patch named '1000-translations.patch'. 
> That patch already has the italian translation file integrated (however in an 
> older version from 2009-06-23 21:51+0200). 
>
> So you will need to change your workflow, to deal with ../debian/patches,
> to get changings from the Debian site into the upstream source.
>
> See https://www.debian.org/doc/manuals/debmake-doc/ch04.en.html#alt-patch
> or
> https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.en.html#separating-your-patches-into-multiple-files
> or
> https://www.debian.org/doc/manuals/maint-guide/dother.en.html#patches
>
>
>
> Holger
>
>
-- 
肖盛文 xiao sheng wen Faris Xiao 
微信(wechat)：atzlinux
《铜豌豆 Linux》 
基于 Debian 的 Linux 中文桌面操作系统：https://www.atzlinux.com
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
GnuPG Public Key: 0x339240CB



signature.asc
Description: OpenPGP digital signature

Bug#960495: transition: gdal

[Sebastiaan Couwenberg]

On 5/30/20 11:42 AM, Sebastiaan Couwenberg wrote:
> On 5/13/20 12:07 PM, Bas Couwenberg wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>> Control: forwarded -1 
>> https://release.debian.org/transitions/html/auto-gdal.html
>> Control: block -1 by 960369 953138
>>
>> For the Debian GIS team I'd like to transition to GDAL 3.1.0.
>>
>> All reverse dependencies rebuilt successfully with GDAL 3.1.0 from
>> experimental as summarized below, except fiona & mysql-workbench.
> 
> fiona has been fixed in the mean time, and mysql-workbench is unrelated
> to gdal.
> 
> Can we do this transition after the icu one now that the R transitions
> have completed?

icu & boost-defaults have migrated to testing, can we do the gdal
transition now?

>> libgdal-grass doesn't need a binNMU as the 3.1.0 version will be
>> uploaded to unstable instead.
>>
>>
>> Transition: gdal
>>
>>  libgdal26 (3.0.4+dfsg-1+b6) -> libgdal27 (3.1.0+dfsg-1~exp1)
>>
>> The status of the most recent rebuilds is as follows.
>>
>>  fiona   (1.8.13-1)   FTBFS (#960369)
>>  gazebo  (11.0.0+dfsg1-2) OK
>>  gmt (6.0.0+dfsg-2)   OK
>>  libcitygml  (2.0.9-2)OK
>>  libosmium   (2.15.5-1)   SKIP (B-D only)
>>  mapcache(1.10.0-1)   OK
>>  mapnik  (3.0.23+ds-1)OK
>>  mapproxy(1.12.0-1)   SKIP (B-D only)
>>  mapserver   (7.6.0-1)OK
>>  merkaartor  (0.18.4+ds-4)OK
>>  mysql-workbench (8.0.19+dfsg-1)  FTBFS (#953138)
>>  ncl (6.6.2-2)OK
>>  node-srs(0.4.8+dfsg-4)   OK
>>  octave-mapping  (1.4.0-1)OK
>>  openorienteering-mapper (0.9.1-1)OK
>>  openscenegraph  (3.6.4+dfsg1-3)  OK
>>  pdal(2.1.0+ds-2) OK
>>  pgsql-ogr-fdw   (1.0.9-1)OK
>>  pktools (2.6.7.6+ds-2)   OK
>>  postgis (3.0.1+dfsg-4)   OK
>>  python-django   (2:2.2.12-1) SKIP (B-D only)
>>  qmapshack   (1.14.1-1)   OK
>>  r-cran-mi   (1.0-7)  SKIP (B-D only)
>>  r-cran-rgdal(1.4-8-1)OK
>>  r-cran-sf   (0.9-3+dfsg-1)   OK
>>  r-cran-tmvtnorm (1.4-10-3)   SKIP (B-D only)
>>  rasterio(1.1.4-1)OK
>>  saga(7.3.0+dfsg-4)   OK
>>  sumo(1.4.0+dfsg1-1)  OK
>>  vtk6(6.3.0+dfsg2-5)  SKIP (B-D only)
>>  vtk7(7.1.1+dfsg2-4)  OK
>>
>>  cloudcompare(2.10.3-4)   SKIP (B-D only)
>>  grass   (7.8.3-1)OK
>>  opencv  (4.2.0+dfsg-6)   OK
>>  osgearth(2.10.2+dfsg-2)  OK
>>  osmcoastline(2.2.4-1)OK
>>  paraview(5.7.0-4)OK
>>  pyosmium(3.0.0-1)SKIP (B-D only)
>>
>>  libgdal-grass   (3.0.4-2 / 3.1.0-1~exp1) FTBFS / OK
>>  otb (7.1.0+dfsg-1)   OK
>>  qgis(3.10.5+dfsg-2)  OK

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#962401: netcdf-fortran: please make the build reproducible

[Sebastiaan Couwenberg]

On 6/8/20 12:49 AM, Chris Lamb wrote:
>>> You have removed some settings, but you left in FFLAGS which varies on
>>> the build path.
>>
>> This is ideally something that is fixed in dpkg-buildflags or gcc, since
>> the introduction of the prefix-map option it also raised
>> file-references-package-build-path lintian issue for many packages.
> 
> Thanks for applying the patch, but I believe you have the cause and
> effect reversed in your thinking about this system.
> 
> The entire point of dpkg-buildflags is to pass the -ffile-prefix-map
> and -fdebug-prefix-map arguments to GCC. There is nothing to fix as
> their entire purpose is to pass this varying path to GCC. The only
> "fix" possible would be to remove this mechanism entirely, defeating
> the goal of being able to do a reproducible builds in the first place.
> 
> In other words, if a package happens to trigger that Lintian tag, then
> that is (correctly) informing the maintainer that it is (incorrectly)
> recording this inconsequential build path in a binary artefact and
> is something for the maintainer to address.
> 
> Hope that clarifies things on your end, despite this being somewhat out
> of scope for this bug report.

Recording buildflags is a very common practice by upstreams, it's not
the responsibility of the package maintainer to filter out buildflags
that contain the buildpath, that's something added by the toolchain. Not
using the buildpath for the prefix-map seems like a better idea. Or
having a dh tool remove the flag in post-processing, instead of
expecting maintainers to add patches like this.

While the intentions of the prefix-map may be good, the (lintian) fall
out of the implementation makes it no so good in my opinion.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#960421: libpwiz: FTBFS with boost 1.71

[peter green]

Some googling lead me to

https://svnweb.freebsd.org/ports/head/multimedia/mkvtoolnix/files/patch-boost-1.69?view=markup=482787

which suggests it is now necessary to manually convert from tribool to bool by 
writing bool{value}

Unfortunately after doing that I get

In file included from /usr/include/boost/type_traits/is_convertible.hpp:20,
 from /usr/include/boost/iterator/interoperable.hpp:13,
 from /usr/include/boost/iterator/iterator_facade.hpp:11,
 from /usr/include/boost/range/iterator_range_core.hpp:27,
 from /usr/include/boost/lexical_cast.hpp:30,
 from ./pwiz/utility/misc/optimized_lexical_cast.hpp:29,
 from ./pwiz/utility/misc/Environment.hpp:24,
 from ./pwiz/utility/misc/Std.hpp:29,
 from pwiz/data/identdata/Serializer_Text.cpp:25:
/usr/include/boost/lexical_cast/detail/converter_lexical.hpp: In instantiation of ‘struct 
boost::detail::deduce_source_char_impl
 >’:
/usr/include/boost/lexical_cast/detail/converter_lexical.hpp:279:89: required from 
‘struct boost::detail::deduce_source_char’
/usr/include/boost/lexical_cast/detail/converter_lexical.hpp:406:85: required from ‘struct 
boost::detail::lexical_cast_stream_traits >’
/usr/include/boost/lexical_cast/detail/converter_lexical.hpp:468:15: required from ‘struct 
boost::detail::lexical_converter_impl, 
boost::logic::tribool>’
/usr/include/boost/lexical_cast/try_lexical_convert.hpp:201:44: required from ‘bool 
boost::conversion::detail::try_lexical_convert(const Source&, Target&) [with Target = 
std::__cxx11::basic_string; Source = boost::logic::tribool]’
/usr/include/boost/lexical_cast.hpp:41:60:   required from ‘Target 
boost::lexical_cast(const Source&) [with Target = 
std::__cxx11::basic_string; Source = boost::logic::tribool]’
pwiz/data/identdata/TextWriter.hpp:136:57:   required from ‘pwiz::identdata::TextWriter& 
pwiz::identdata::TextWriter::operator()(const string&, const object_type&) [with 
object_type = boost::logic::tribool; std::string = std::__cxx11::basic_string]’
pwiz/data/identdata/TextWriter.hpp:509:53:   required from here
/usr/include/boost/lexical_cast/detail/converter_lexical.hpp:210:13: error: 
static assertion failed: Source type is neither std::ostream`able nor 
std::wostream`able
  210 | BOOST_STATIC_ASSERT_MSG((result_t::value || boost::has_left_shift< 
std::basic_ostream< type >, T >::value),
  | ^~~
make[1]: *** [Makefile:5478: pwiz/data/identdata/Serializer_Text.lo] Error 1

Which I have no clue about.

Debdiff of what I have done so far is attatched.

diff -Nru libpwiz-3.0.18342/debian/changelog libpwiz-3.0.18342/debian/changelog
--- libpwiz-3.0.18342/debian/changelog  2019-02-01 22:38:03.0 +
+++ libpwiz-3.0.18342/debian/changelog  2020-06-08 01:56:54.0 +
@@ -1,3 +1,10 @@
+libpwiz (3.0.18342-2+rpi1) bullseye-staging; urgency=medium
+
+  * Explicitly convert tribool to bool, this seems to be needed with the
+new boost.
+
+ -- Peter Michael Green   Mon, 08 Jun 2020 01:56:54 
+
+
 libpwiz (3.0.18342-2) unstable; urgency=low
 
   * Improve header path (move pwiz to proteowizard) to ease with nested
diff -Nru libpwiz-3.0.18342/debian/patches/boost.patch 
libpwiz-3.0.18342/debian/patches/boost.patch
--- libpwiz-3.0.18342/debian/patches/boost.patch1970-01-01 
00:00:00.0 +
+++ libpwiz-3.0.18342/debian/patches/boost.patch2020-06-08 
01:56:54.0 +
@@ -0,0 +1,42 @@
+Description: Explicitly convert tribool to bool
+ this seems to be needed with the new boost.
+Author: Peter Michael Green 
+
+--- libpwiz-3.0.18342.orig/pwiz/data/identdata/IdentData.cpp
 libpwiz-3.0.18342/pwiz/data/identdata/IdentData.cpp
+@@ -1047,7 +1047,7 @@ PWIZ_API_DECL proteome::DigestedPeptide
+ BOOST_FOREACH(CVID cleavageAgent, cleavageAgents)
+ {
+ if (!findPeptideEvidenceWithRegex(pe, peptide, 
peptideSequenceInContext, cleavageAgent, "",
+-  sip.enzymes.independent, 
nTerminusIsSpecific, cTerminusIsSpecific,
++  bool{sip.enzymes.independent}, 
nTerminusIsSpecific, cTerminusIsSpecific,
+   bestSpecificity, bestResult))
+ break;
+ }
+@@ -1055,7 +1055,7 @@ PWIZ_API_DECL proteome::DigestedPeptide
+ BOOST_FOREACH(const string& regex, cleavageAgentRegexes)
+ {
+ if (!findPeptideEvidenceWithRegex(pe, peptide, 
peptideSequenceInContext, CVID_Unknown, regex,
+-  sip.enzymes.independent, 
nTerminusIsSpecific, cTerminusIsSpecific,
++  bool{sip.enzymes.independent}, 
nTerminusIsSpecific, cTerminusIsSpecific,
+   bestSpecificity, bestResult))
+ break;
+ }
+@@ -1109,7 +1109,7 @@ PWIZ_API_DECL vector

Bug#962176: numba: fails autopktest with numpy 1.18

[Drew Parsons]

Source: numba
Followup-For: Bug #962176

The upstream patch does not apply cleaning (on its own), doesn't give
a clean build that passes all tests.

Probably we need to wait for their next release, else pull an entire
git snapshot or rc release. But 0.50.0 is already rc, shouldn't be too
long before final release.

Bug#962439: sctk: use pdftoppm instead of convert in debian/replacement_files/Makefile

[Michael Hudson-Doyle]

Source: sctk
Version: 2.4.10-20151007-1312Z+dfsg2-3
Severity: normal
Tags: patch

Dear Maintainer,

I've just patched sctk in Ubuntu as our default ImageMagick security
policy does not allow convert(1) to access PDFs but rather use pdftoppm.
As a bonus the resulting file is smaller and looks much nicer :) I don't
now if Debian is interested in this really, but I'm attaching the
debdiff anyway.

Cheers,
mwh

-- System Information:
Debian Release: bullseye/sid
  APT prefers focal-updates
  APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), 
(400, 'focal-proposed'), (100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.4.0-33-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog   2020-03-23 
04:57:23.0 +1300
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/changelog   2020-06-08 
15:03:11.0 +1200
@@ -1,3 +1,10 @@
+sctk (2.4.10-20151007-1312Z+dfsg2-3ubuntu1) groovy; urgency=medium
+
+  * Use pdftoppm instead of convert to convert pdf to jpg as the latter fails
+with the default security policy on Ubuntu.
+
+ -- Michael Hudson-Doyle   Mon, 08 Jun 2020 
15:03:11 +1200
+
 sctk (2.4.10-20151007-1312Z+dfsg2-3build1) focal; urgency=medium
 
   * No-change rebuild for libgcc-s1 package name change.
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/control
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 2016-04-28 
04:42:33.0 +1200
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/control 2020-06-08 
15:03:11.0 +1200
@@ -1,13 +1,15 @@
 Source: sctk
 Section: science
 Priority: optional
-Maintainer: Giulio Paci 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Giulio Paci 
 Build-Depends: cdbs,
  devscripts,
  debhelper (>= 9~),
  dh-buildinfo,
  dpkg-dev (>= 1.16.1~),
  librsvg2-bin,
+ poppler-utils,
  texlive-latex-base,
  texlive-latex-extra,
  imagemagick,
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/control.in 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/control.in
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/control.in  2016-04-28 
04:42:33.0 +1200
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/control.in  2020-06-08 
15:03:11.0 +1200
@@ -1,7 +1,8 @@
 Source: sctk
 Section: science
 Priority: optional
-Maintainer: Giulio Paci 
+Maintainer: Ubuntu Developers 
+XSBC-Original-Maintainer: Giulio Paci 
 Build-Depends: @cdbs@
 Standards-Version: 3.9.8
 Homepage: http://www.nist.gov/itl/iad/mig/tools.cfm
diff -Nru sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile 
sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile
--- sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile  
2016-04-28 04:42:33.0 +1200
+++ sctk-2.4.10-20151007-1312Z+dfsg2/debian/replacement_files/Makefile  
2020-06-08 15:03:11.0 +1200
@@ -34,7 +34,7 @@
 all: $(OUTPUT)
 
 %.jpg: %.pdf
-   convert -density 300 $< $@
+   pdftoppm -jpeg -singlefile -r 300 $< > $@
 
 %.png: %.svg
convert "$<" "$@"

Bug#961414: waybar: New upstream version

[Martin Michlmayr]

* Michele Cane  [2020-05-24 13:12]:
> upstream is at 0.9.2 could you please update?

Any update on this?

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#962438: ITP: pore-c -- processing data from an ONT poreC run

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: pore-c -- processing data from an ONT poreC run
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: pore-c
  Version : 0.2.0~rc1
  Upstream Author : Copyright: Matthew Pendleton 

* URL : https://github.com/nanoporetech/pore-c
* License : MPL-2.0
  Programming Lang: Python
  Description : processing data from an ONT poreC run
 This package is designed to analyse the data from multi-contact pore-C
 reads. It is similar to the pairtools package in scope, however it is
 specifically designed to handle multi-contact reads (aka c-walks). It
 carries out the following operations:
 .
  * pre-processing a reference genome to generate auxiliary files used
in downstream analyses
  * creating virtual digests of the reference genome
  * processing read-sorted BAM files to filter spurious alignments,
detect ligation junctions and assign fragments
  * converting the resulting contacts to a pairs format and a
COO-formatted matrix compatible with Cooler for downstream processing.

Remark: This package is maintained by Steffen Moeller at
   https://salsa.debian.org/med-team/pore-c

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Cyril Brulebois]

Cyril Brulebois  (2020-06-08):
> Dropping the ../english/ prefix for sitemap.wml leads to a reasonable
> diff for the English sitemap (sitemap.en.html):
> 
> --- stretch.en.html   2020-06-08 00:07:43.916768223 +0200
> +++ buster.en.html2020-06-08 00:07:47.248781809 +0200
> @@ -4,8 +4,8 @@
>
>Site map for Debian web pages 
>mailto:webmas...@debian.org;>
> -  
> -  
> +  
> +  
>
>
>
> @@ -377,7 +377,7 @@
>  
>  Last Modified: Sun, Jun 7 21:49:47 UTC 2020
>  
> -Last Built: Sun, Jun 7 22:07:43 UTC 2020
> +Last Built: Sun, Jun 7 22:07:46 UTC 2020
>
>Copyright  1997-2020
>   https://www.spi-inc.org/;>SPI and others; See  href="./license" rel="copyright">license terms
> 
> Therefore, I suspect we *might* be able to get away with this if we were
> to add a symlink from all language directories, from $LANG/sitemap.wml
> to ../english/sitemap.wml, as a companion change to dropping the
> ../english prefix mentioned above (only tested successfully on English).
> I'll be checking this hypothesis and possibly pushing a branch / opening
> an MR if that works fine.

OK. This isn't so simple. I've pushed this branch:
  
https://salsa.debian.org/webmaster-team/webwml/-/tree/pu/partial-workaround-924172

I'm attaching several sitemap files, built either in stretch or in
buster, in English or in French, from the master branch or from the
workaround branch:

buster.en.html.master
buster.en.html.workaround
buster.fr.html.master
buster.fr.html.workaround
stretch.en.html.master
stretch.en.html.workaround
stretch.fr.html.master
stretch.fr.html.workaround

For each language, diffing the stretch built between master and the
workaround yields no (practical) differences.

Diffing stretch.en.master.html and buster.en.master.html shows many
../english/ being added; which could be arguably seen as a no-op.

Diffing stretch.fr.master.html and buster.fr.master.html shows many
../english/ being added; which breaks navigation as that's another
language…

Diffing stretch.en.master.html and buster.en.workaround.html shows
no practical differences (per my previous mail).

Diffing stretch.fr.master.html and buster.fr.workaround.html shows
the lost translations between (patched or unpatched) French version
built in stretch and patched French version built in English. It
seems we're losing translations for items which would have suffered
from the ../english/ addition.

Interestingly, this list seems to match the special cases defined in
english/sitemap.wml (which is about pass protection this time, see
the escape tag definition and comment above). I haven't tried to
double check the flags passed to each pass in each cases though
(running out of time).


Overall, it seems my proposed patch papers around the issue but not
fully. But it could help unstuck the move to buster if we agree the
partial translations for the sitemaps are better than rather broken
sitemaps.


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


signature.asc
Description: PGP signature

Bug#962437: debian-spamd shouldn't have valid shell

[Elliott Mitchell]

Package: spamassassin
Version: 3.4.2-1+deb10u2

The postinst script for SpamAssassin creates the user "debian-spamd" with
the shell set to /bin/sh.  When looking I found minimal reason for
debian-spamd to have a valid shell.  In fact the only reason I could find
was spamassassin.postinst using `su`.

If "-s /bin/sh" is added to the use of `su` that fixes the issue.  With
this fix, everything /appears/ to function with debian-spamd having a
shell of /bin/false.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#962102: ITP: ltunify -- Pair and manage Logitech devices that use the unifying receiver

[Peter Wu]

Hi all,

Peter here, author of ltunify. Thank you for your interest :-)
Regarding Solaar vs ltunify, I have contributed to both projects, but
continue to use ltunify because it is a small program with no external
dependencies. This makes it perfect for pairing or listing devices on a
minimal point-of-sales system for example, or copying over the binary
and run it over SSH.

For those looking for more features such as the ability to control
settings such as swapping the Fn buttons on keyboards, or a GUI/CLI to
control new or existing devices, Solaar offers this. While it was
dormant for a while, it has gained new maintainers, so it will continue
to be a great alternative. In the future, Solaar might offload some of
its protocol stuff to a separate daemon, but this development has not
completed yet. See these references:
https://github.com/pwr-Solaar/Solaar/issues/654
https://github.com/FFY00/logitechd

For those interested in battery status, Solaar offers this
functionality, but so does UPower (as integrated with the Plasma and
GNOME desktops, and possibly others).

A point to note, both Solaar and ltunify have a udev rule that grants
the seated user rights to directly control the receiver by making the
hidraw node accessible to non-root users. I still use this rule myself
for usability, but more cautious users should note that this also allows
those users to directly read events such as keystrokes, potentially
bypassing additional security measures put in place by Wayland for
example. For most users this should not be a problem, if arbitrary code
is running as your user, you have more problems to worry about.

There have some fixes since the 0.2 release, so if it helps I could tag
a new version.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl

P.S. hoi Geert!

Bug#962401: netcdf-fortran: please make the build reproducible

[Chris Lamb]

Sebastiaan,

> > You have removed some settings, but you left in FFLAGS which varies on
> > the build path.
>
> This is ideally something that is fixed in dpkg-buildflags or gcc, since
> the introduction of the prefix-map option it also raised
> file-references-package-build-path lintian issue for many packages.

Thanks for applying the patch, but I believe you have the cause and
effect reversed in your thinking about this system.

The entire point of dpkg-buildflags is to pass the -ffile-prefix-map
and -fdebug-prefix-map arguments to GCC. There is nothing to fix as
their entire purpose is to pass this varying path to GCC. The only
"fix" possible would be to remove this mechanism entirely, defeating
the goal of being able to do a reproducible builds in the first place.

In other words, if a package happens to trigger that Lintian tag, then
that is (correctly) informing the maintainer that it is (incorrectly)
recording this inconsequential build path in a binary artefact and
is something for the maintainer to address.

Hope that clarifies things on your end, despite this being somewhat out
of scope for this bug report.


Best wishes,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org  chris-lamb.co.uk
   `-

Bug#962419: /usr/local/share/texmf owned by group staff even if /etc/staff-group-for-usr-local not present

[Norbert Preining]

tag 962419 + pending
thanks

Fixed in git

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Cyril Brulebois]

(Looping in wml package maintainer + original author)

Hi!

Laura Arjona Reina  (2020-06-07):
> Thanks Cyril for your work here.
> 
> We're trying to fix all the issues so the migration of www-master to
> buster can be done as soon as possible.

You're welcome, helping towards that goal was my original intent.

> I'll comment on the issues you found:
> 
> 1. Changes related to canonicalization(?) of the URL
> 
> The files affected are:
> 
> 1.1.- */News/news.*.rdf  (all languages)
> 
> All those files are built using /english/News/news.rdf.in which includes
> this line:
> 
> 
> 
> it seems that the variable $(HOME) is interpreted differently by the
> make or wml commands in buster.
> 
> I have played with the "-D HOME~." line in /english/.wmlrc but it does
> not solve the issue.
> 
> The file is built (in english and all the other languages except
> Chinese) by lines 36-37 of the /english/News/Makefile:
> 
>   $(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) \
>   $(ENGLISHDIR)/News/news.rdf.in
> 
> If I change that to
> 
>   $(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) news.rdf.in
> 
> then the English file is built with correct URL to the CSS, but the
> other languages fail.
> 
> I don't know how to solve this, except using an absolute reference to
> the CSS file in the /english/News/news.rdf.in instead of the $(HOME)
> variable.

I'll skip this for now, to concentrate on the topic I've debugged this
evening; this might be related though!

> 1.2. */sitemap.*.html  (all languages)
> 
> I guess it's the same problem (that the $(HOME) variable is used and
> interpreted wrongly with the new make or wml), but this file and how it
> is built is more cryptic for me so I wouldn't know how to start.
> 
> The sitemap would be completely broken until this issue is fixed, if
> we migrate www-master to buster :/
> 
> Help needed!

For the record, we're talking about:
  https://salsa.debian.org/webmaster-team/webwml

The problem can be triggered with:
  make -C english sitemap.en.html

Another file in the same directory can be obtained with:
  make -C english index.en.html


OK, so I've spent some time on this. Based on the HOME mention, I tried
to switch it from `-D HOME~.` to `-D HOME=.` in english/.wmlrc but that
wasn't sufficient. I had to turn *all* such defines in that file from
`~` to `=` to get a reasonable sitemap.

The wml_intro.7 manpage quickly explains the difference between both,
but that seems to be happening in passes 2 and 3; english/sitemap.wml is
one of the only files were pass protection is used, but that turned out
to be a red herring…


Adding the `-v2` flag to the `$(WML)` calls in english/Makefile made the
issue apparent: as early as pass 1, we have different parameters being
sent to wml_p1_ipp between stretch (2.0.12) and buster (2.12.2), among
which:

 * stretch:

"-DBUGS=Bugs"
"-DINTRO=intro"

 * buster:
"-DBUGS=../english/Bugs"
"-DINTRO=../english/intro" 

for our english/sitemap.wml

BUT

that's not the case for index.en.html, built from english/index.wml!

At this point, I suspected the origin of the change in behavior was the
path to the input file:

  $(WML) … index.wml is OK
  $(WML) … ../english/sitemap.wml is not OK

because the latter triggers the insertion of `../english/` in lots of
places (defined with `~` instead of `=`) with 2.12.2, which was not the
case with 2.0.12.


Dropping the ../english/ prefix for sitemap.wml leads to a reasonable
diff for the English sitemap (sitemap.en.html):

--- stretch.en.html 2020-06-08 00:07:43.916768223 +0200
+++ buster.en.html  2020-06-08 00:07:47.248781809 +0200
@@ -4,8 +4,8 @@
   
   Site map for Debian web pages 
   mailto:webmas...@debian.org;>
-  
-  
+  
+  
   
   
   
@@ -377,7 +377,7 @@
 
 Last Modified: Sun, Jun 7 21:49:47 UTC 2020
 
-Last Built: Sun, Jun 7 22:07:43 UTC 2020
+Last Built: Sun, Jun 7 22:07:46 UTC 2020
   
   Copyright  1997-2020
  https://www.spi-inc.org/;>SPI and others; See license terms

Therefore, I suspect we *might* be able to get away with this if we were
to add a symlink from all language directories, from $LANG/sitemap.wml
to ../english/sitemap.wml, as a companion change to dropping the
../english prefix mentioned above (only tested successfully on English).
I'll be checking this hypothesis and possibly pushing a branch / opening
an MR if that works fine.

I'm sending this mail to reach out to upstream so they can comment on
whether the change was intentional or an unwanted side effect.

I might look at the News/RDF thing in the meanwhile.


> 3. Changes in a log file
> 
> Not important (and probably we shouldn't provide the card there, maybe
> in the debian-flyers repo?)
> 
> 4. Changes in ordering of coordinators
> 5. Changes in ordering under wnpp
> 6. Changes in order under l10n
> 8. More ordering changes (architectures, DSAs)
> 
> Thanks for reporting, and for 

Bug#962414: [Pkg-fonts-devel] Bug#962414: Please import new upstream version 4 or newer

[Nicholas D Steeves]

Hi Fabian,

Fabian Greffrath  writes:

> Hi,FiraCode v4 has a major regression, thus I'd rather wait for the next 
> release: 
> https://github.com/tonsky/FiraCode/issues/1049https://github.com/tonsky/FiraCode/issues/1059
>  - FabianVon meinem Samsung Galaxy Smartphone gesendet.
>  Ursprüngliche Nachricht Von: Nicholas D Steeves 
>  Datum: 07.06.20  19:57  (GMT+01:00) An: Debian Bug 
> Tracking System  Betreff: [Pkg-fonts-devel] 
> Bug#962414: Please import new upstream version 4
>   or newer Package: fonts-firacodeVersion: 3.1+dfsg1-1Severity: 
> normalHi,While investigating which version of Fira fonts were bundled with 
> anapplication I'm packaging, I noticed that our fonts-firacode packagewas out 
> of date.Please import new upstream version 4 or newer.Best,NicholasP.S. Thank 
> you for building woff2 format 
> fonts!___Pkg-fonts-devel mailing 
> listPkg-fonts-devel@alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-fonts-devel

Sounds reasonable to me.  Also, that's why I wrote "or newer", since you
would know best :-)

Thank you,
Nicholas


signature.asc
Description: PGP signature

Bug#962419: /usr/local/share/texmf owned by group staff even if /etc/staff-group-for-usr-local not present

[Norbert Preining]

Hi Sébastien,

On Sun, 07 Jun 2020, Sébastien Villemot wrote:
> > permissions should only be given when the file 
> > /etc/staff-group-for-usr-local

Thanks for the report. Is it enough during installation to check for
that file, or should we change permissions for older installations, too?

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#962436: debian-history: [INTL:pt] Update on Portuguese translation of manpage

[Américo Monteiro]

Package: debian-history
Version: 2.24
3ags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  debian-history's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro




debian-history_2.24_pt.po.gz
Description: application/gzip

Bug#962435: ITP: ruby-async-pool -- singleplex and multiplex resource pool for implementing robust clients

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: ruby-async-pool
  Version : 0.3.2
  Upstream Author : Samuel G. D. Williams. 
* URL : https://github.com/socketry/async-pool
* License : MIT
  Programming Lang: Ruby
  Description : singleplex and multiplex resource pool for implementing 
robust clients

 Async::Pool provides support for connection pooling both singleplex
 and multiplex resources.

 This ITP depends on
 - ruby-async (#962380)

Bug#569049: mbw: Memory bandwith test inverts DUMB and MEMCPY tests. Dumb copy appears faster than memcpy

[Celelibi]

For what it's worth. This bug has just been fixed upstream.
https://github.com/raas/mbw
10 years after was reported here. ^^

Let's just hope that the maintainer of this package is still around and
will eventally upgrade.

Best regards,
Celelibi

Bug#962434: ros-resource-retriever: calls home during build.

[Gianfranco Costamagna]

Source: ros-resource-retriever
Version: 1.12.6-1
Severity: serious

Hello, using internet during build is forbidden by policy, but still allowed in 
Debian builders.

In Ubuntu, where this is more strictly forbidden, the failure seems to indicate 
that the package
is trying to connect to internet during tests:
see e.g.
https://launchpad.net/ubuntu/+source/ros-resource-retriever/1.12.6-1/+build/19419607

[  FAILED  ] 1 test, listed below:
[  FAILED  ] Retriever.http

def test_http():
res = r.get("http://packages.ros.org/ros.key;)
assert len(res) > 0



thanks

Gianfranco

Bug#962431: mark sng Multi-Arch: foreign

[Helmut Grohne]

Package: sng
Version: 1.1.0-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:sdlbasic

sdlbasic fails to cross build from source, because it fails running sng
with an Exec format error. Usually this indicates that the relevant
package should be marked Multi-Arch: foreign. In this case, such a
marking is reasonable, because sng exclusively deals with
architecture-independent file formats (PNG and a textual representation
thereof). Please consider applying the attached patch.

Helmut
diff --minimal -Nru sng-1.1.0/debian/changelog sng-1.1.0/debian/changelog
--- sng-1.1.0/debian/changelog  2020-02-02 10:56:23.0 +0100
+++ sng-1.1.0/debian/changelog  2020-06-07 09:53:01.0 +0200
@@ -1,3 +1,10 @@
+sng (1.1.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark sng Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Jun 2020 09:53:01 +0200
+
 sng (1.1.0-3) unstable; urgency=medium
 
   * Depend on x11-common for rgb.txt color database.
diff --minimal -Nru sng-1.1.0/debian/control sng-1.1.0/debian/control
--- sng-1.1.0/debian/control2020-02-02 10:53:15.0 +0100
+++ sng-1.1.0/debian/control2020-06-07 09:52:59.0 +0200
@@ -13,6 +13,7 @@
 
 Package: sng
 Architecture: any
+Multi-Arch: foreign
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  x11-common

Bug#962433: bitmeter FTCBFS: broken, outdated, embedded copy of PKG_CHECK_MODULES

[Helmut Grohne]

Source: bitmeter
Version: 1.2-4
Tags: fixed-upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

bitmeter fails to cross build from source, because it uses a broken,
outdated, embedded copy of PKG_CHECK_MODULES (in aclocal.m4). The
relevant bug is already fixed in the upstream macro (for a very long
time). Please remove your copy and use the system copy of this macro.
Failing that, please update your copy and register[1] it with the
security tracker.

Helmut

[1] https://wiki.debian.org/EmbeddedCopies

Bug#962429: kcontacts FTCBFS: missing Build-Depends qttools5-dev

[Helmut Grohne]

Source: kcontacts
Version: 5:5.70.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

kcontacts fails to cross build from source, because it misses a build
dependency on qttools5-dev. Please refer to #915122 for details and
consider applying the attached patch.

Helmut
diff --minimal -Nru kcontacts-5.70.0/debian/changelog 
kcontacts-5.70.0/debian/changelog
--- kcontacts-5.70.0/debian/changelog   2020-05-26 23:56:54.0 +0200
+++ kcontacts-5.70.0/debian/changelog   2020-06-07 22:12:41.0 +0200
@@ -1,3 +1,10 @@
+kcontacts (5:5.70.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Missing Build-Depends: qttools5-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Jun 2020 22:12:41 +0200
+
 kcontacts (5:5.70.0-1) unstable; urgency=medium
 
   [ Sandro Knauß ]
diff --minimal -Nru kcontacts-5.70.0/debian/control 
kcontacts-5.70.0/debian/control
--- kcontacts-5.70.0/debian/control 2020-05-26 23:56:54.0 +0200
+++ kcontacts-5.70.0/debian/control 2020-06-07 22:12:40.0 +0200
@@ -14,6 +14,7 @@
pkg-kde-tools (>> 0.15.15),
qhelpgenerator-qt5,
qtbase5-dev (>= 5.12.0~),
+   qttools5-dev,
xauth,
xvfb
 Standards-Version: 4.5.0

Bug#962430: ebook2cw FTCBFS: strips with the build architecture strip

[Helmut Grohne]

Source: ebook2cw
Version: 0.8.2-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

ebook2cw fails to cross build from source, because it strips with the
build architecture strip during make install via install -s. Beyond
breaking cross compilation, doing so also breaks
DEB_BUILD_OPTIONS=nostrip as well as generation of -dbgsym packages.
Please consider applying the attached patch to fix all of these.

Helmut
diff --minimal -Nru ebook2cw-0.8.2/debian/changelog 
ebook2cw-0.8.2/debian/changelog
--- ebook2cw-0.8.2/debian/changelog 2015-11-12 15:10:06.0 +0100
+++ ebook2cw-0.8.2/debian/changelog 2020-06-07 09:47:17.0 +0200
@@ -1,3 +1,10 @@
+ebook2cw (0.8.2-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Don't strip during make install. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Jun 2020 09:47:17 +0200
+
 ebook2cw (0.8.2-2) unstable; urgency=low
 
   * Bump Standard-Version to 3.9.6.
diff --minimal -Nru ebook2cw-0.8.2/debian/patches/cross.patch 
ebook2cw-0.8.2/debian/patches/cross.patch
--- ebook2cw-0.8.2/debian/patches/cross.patch   1970-01-01 01:00:00.0 
+0100
+++ ebook2cw-0.8.2/debian/patches/cross.patch   2020-06-07 09:46:45.0 
+0200
@@ -0,0 +1,37 @@
+--- ebook2cw-0.8.2.orig/Makefile
 ebook2cw-0.8.2/Makefile
+@@ -10,6 +10,7 @@
+ USE_LAME?=YES
+ USE_OGG?=YES
+ 
++INSTALL?=install
+ CFLAGS:=$(CFLAGS) -D DESTDIR=\"$(ROOT_DESTDIR)\" -D VERSION=\"$(VERSION)\"
+ 
+ ifeq ($(USE_LAME), YES)
+@@ -37,16 +38,16 @@
+   $(CC) $(CPPFLAGS) $(CFLAGS) -static ebook2cw.c $(LDFLAGS) -lm -o 
ebook2cw
+ 
+ install:
+-  install -d -v  $(DESTDIR)/share/man/man1/
+-  install -d -v  $(DESTDIR)/bin/
+-  install -d -v  $(DESTDIR)/share/doc/ebook2cw/
+-  install -d -v  
$(DESTDIR)/share/doc/ebook2cw/examples/
+-  install -s -m 0755 ebook2cw$(DESTDIR)/bin/
+-  install-m 0644 ebook2cw.1  $(DESTDIR)/share/man/man1/
+-  install-m 0644 README  $(DESTDIR)/share/doc/ebook2cw/
+-  install-m 0644 ebook2cw.conf   
$(DESTDIR)/share/doc/ebook2cw/examples/
+-  install-m 0644 isomap.txt  
$(DESTDIR)/share/doc/ebook2cw/examples/
+-  install-m 0644 utf8map.txt 
$(DESTDIR)/share/doc/ebook2cw/examples/
++  $(INSTALL) -d -v  $(DESTDIR)/share/man/man1/
++  $(INSTALL) -d -v  $(DESTDIR)/bin/
++  $(INSTALL) -d -v  $(DESTDIR)/share/doc/ebook2cw/
++  $(INSTALL) -d -v  
$(DESTDIR)/share/doc/ebook2cw/examples/
++  $(INSTALL) -s -m 0755 ebook2cw$(DESTDIR)/bin/
++  $(INSTALL)-m 0644 ebook2cw.1  $(DESTDIR)/share/man/man1/
++  $(INSTALL)-m 0644 README  $(DESTDIR)/share/doc/ebook2cw/
++  $(INSTALL)-m 0644 ebook2cw.conf   
$(DESTDIR)/share/doc/ebook2cw/examples/
++  $(INSTALL)-m 0644 isomap.txt  
$(DESTDIR)/share/doc/ebook2cw/examples/
++  $(INSTALL)-m 0644 utf8map.txt 
$(DESTDIR)/share/doc/ebook2cw/examples/
+   
+ uninstall:
+   rm -f $(DESTDIR)/bin/ebook2cw
diff --minimal -Nru ebook2cw-0.8.2/debian/patches/series 
ebook2cw-0.8.2/debian/patches/series
--- ebook2cw-0.8.2/debian/patches/series2013-01-23 11:32:31.0 
+0100
+++ ebook2cw-0.8.2/debian/patches/series2020-06-07 09:45:55.0 
+0200
@@ -2,3 +2,4 @@
 escape-minuses-on-manpage.patch
 makefile-respect-CC-CFLAGS.patch
 configfile-buffer-overflow.patch
+cross.patch
diff --minimal -Nru ebook2cw-0.8.2/debian/rules ebook2cw-0.8.2/debian/rules
--- ebook2cw-0.8.2/debian/rules 2013-01-22 11:49:59.0 +0100
+++ ebook2cw-0.8.2/debian/rules 2020-06-07 09:47:15.0 +0200
@@ -11,3 +11,6 @@
 
 %:
dh $@
+
+override_dh_auto_install:
+   dh_auto_install -- INSTALL='install --strip-program=true'

Bug#962432: move libcw.pc to a multiarch location

[Helmut Grohne]

Package: libcw6-dev
Version: 3.5.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:cwdaemon

cwdaemon fails to cross build from source, because it cannot find
libcw.pc. During cross compilation, pkg-config does not search
/usr/lib/pkgconfig. The .pc file should be moved to a multiarch
location. Please consider applying the attached patch.

Helmut
diff --minimal -Nru unixcw-3.5.1/debian/changelog unixcw-3.5.1/debian/changelog
--- unixcw-3.5.1/debian/changelog   2019-02-19 09:46:06.0 +0100
+++ unixcw-3.5.1/debian/changelog   2020-06-07 23:05:34.0 +0200
@@ -1,3 +1,10 @@
+unixcw (3.5.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Use a multiarch --libdir. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Jun 2020 23:05:34 +0200
+
 unixcw (3.5.1-3) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru unixcw-3.5.1/debian/libcw6-dev.install 
unixcw-3.5.1/debian/libcw6-dev.install
--- unixcw-3.5.1/debian/libcw6-dev.install  2019-02-19 09:31:44.0 
+0100
+++ unixcw-3.5.1/debian/libcw6-dev.install  2020-06-07 23:05:18.0 
+0200
@@ -1,4 +1,4 @@
-usr/lib/libcw.a
+usr/lib/*/libcw.a
 
 # lintian-info -t dev-pkg-without-shlib-symlink | 
non-dev-pkg-with-shlib-symlink:
 #   "A "-dev" package is supposed to install a "libsomething.so" symbolic
@@ -15,10 +15,10 @@
 # that it should be created at some point. I can't see any explicit call
 # to "ln -s" in debian/* files... But as long as it works implicitly, I'm
 # willing to think that this is just how things should be.
-usr/lib/libcw.so
+usr/lib/*/libcw.so
 
 usr/include/libcw.h
 usr/include/libcw_debug.h
 usr/share/man/man3
 usr/share/doc/libcw6-dev
-usr/lib/pkgconfig/libcw.pc
+usr/lib/*/pkgconfig/libcw.pc
diff --minimal -Nru unixcw-3.5.1/debian/libcw6.install 
unixcw-3.5.1/debian/libcw6.install
--- unixcw-3.5.1/debian/libcw6.install  2019-02-19 09:31:55.0 +0100
+++ unixcw-3.5.1/debian/libcw6.install  2020-06-07 23:05:26.0 +0200
@@ -1,3 +1,3 @@
-usr/lib/libcw.so.6.6.1
-usr/lib/libcw.so.6
+usr/lib/*/libcw.so.6.6.1
+usr/lib/*/libcw.so.6
 usr/share/man/man7/cw.7
diff --minimal -Nru unixcw-3.5.1/debian/rules unixcw-3.5.1/debian/rules
--- unixcw-3.5.1/debian/rules   2019-02-19 09:38:46.0 +0100
+++ unixcw-3.5.1/debian/rules   2020-06-07 23:04:59.0 +0200
@@ -41,7 +41,7 @@
 config.status: configure
dh_testdir
 # Add here commands to configure the package.
-   QT4DIR="/usr/share/qt4" CFLAGS="$(CFLAGS)" ./configure 
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info
+   QT4DIR="/usr/share/qt4" CFLAGS="$(CFLAGS)" ./configure 
--host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
 
 
 #Architecture

Bug#962428: rbdoom3bfg FTCBFS: confuses build and host

[Helmut Grohne]

Source: rbdoom3bfg
Version: 1.2.0+dfsg~git20200327-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

rbdoom3bfg fails to cross build from source, because debian/rules
confuses the terms build and host. Please refer to man dpkg-architecture
for their definition. The attached patch also generalizes the detection
to other possible architectures such as hurd-amd64 (if ever). Please
consider applying it.

Helmut
diff --minimal -Nru rbdoom3bfg-1.2.0+dfsg~git20200327/debian/changelog 
rbdoom3bfg-1.2.0+dfsg~git20200327/debian/changelog
--- rbdoom3bfg-1.2.0+dfsg~git20200327/debian/changelog  2020-03-31 
11:27:50.0 +0200
+++ rbdoom3bfg-1.2.0+dfsg~git20200327/debian/changelog  2020-06-07 
09:04:25.0 +0200
@@ -1,3 +1,10 @@
+rbdoom3bfg (1.2.0+dfsg~git20200327-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: fix build/host confusion. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 07 Jun 2020 09:04:25 +0200
+
 rbdoom3bfg (1.2.0+dfsg~git20200327-1) unstable; urgency=medium
 
   * New upstream git snapshot.
diff --minimal -Nru rbdoom3bfg-1.2.0+dfsg~git20200327/debian/rules 
rbdoom3bfg-1.2.0+dfsg~git20200327/debian/rules
--- rbdoom3bfg-1.2.0+dfsg~git20200327/debian/rules  2020-03-31 
10:41:47.0 +0200
+++ rbdoom3bfg-1.2.0+dfsg~git20200327/debian/rules  2020-06-07 
09:04:25.0 +0200
@@ -1,5 +1,6 @@
 #!/usr/bin/make -f
 
+include /usr/share/dpkg/architecture.mk
 include /usr/share/dpkg/pkg-info.mk
 
 # output every command that modifies files on the build system.
@@ -9,10 +10,8 @@
 export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
-DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
-
 CMAKE_ADDTIONAL_FLAGS ?=
-ifeq ($(findstring $(DEB_BUILD_ARCH), amd64 kfreebsd-amd64),)
+ifneq ($(DEB_HOST_ARCH_CPU),amd64)
 CMAKE_ADDITIONAL_FLAGS ?= -DUSE_INTRINSICS=OFF
 endif
 

Bug#960381: cupt: diff for NMU version 2.10.4+nmu1

[Sebastian Ramacher]

Control: tags 960381 + pending

Dear maintainer,

I've prepared an NMU for cupt (versioned as 2.10.4+nmu1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru cupt-2.10.4/cpp/CMakeLists.txt cupt-2.10.4+nmu1/cpp/CMakeLists.txt
--- cupt-2.10.4/cpp/CMakeLists.txt	2019-11-10 10:53:34.0 +0100
+++ cupt-2.10.4+nmu1/cpp/CMakeLists.txt	2020-06-07 22:52:03.0 +0200
@@ -8,9 +8,9 @@
 
 find_package(Boost 1.42.0)
 IF(Boost_FOUND)
-	IF(Boost_VERSION LESS 104200)
+	IF(Boost_VERSION LESS 1.42)
 		message(FATAL_ERROR "need Boost of version 1.42.0")
-	ENDIF(Boost_VERSION LESS 104200)
+	ENDIF(Boost_VERSION LESS 1.42)
 ELSE()
 	message(FATAL_ERROR "missing Boost")
 ENDIF()
diff -Nru cupt-2.10.4/debian/changelog cupt-2.10.4+nmu1/debian/changelog
--- cupt-2.10.4/debian/changelog	2019-11-10 10:53:34.0 +0100
+++ cupt-2.10.4+nmu1/debian/changelog	2020-06-07 22:56:21.0 +0200
@@ -1,3 +1,11 @@
+cupt (2.10.4+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * cmakelists: Fix boost version check (Closes: #960381)
+Based on the patch from Ubuntu
+
+ -- Sebastian Ramacher   Sun, 07 Jun 2020 22:56:21 +0200
+
 cupt (2.10.4) unstable; urgency=low
 
   * console:


signature.asc
Description: PGP signature

Bug#962427: golang-github-klauspost-pgzip: Please update to upstream version 1.2.3 or later

[Reinhard Tartler]

Package: golang-github-klauspost-pgzip
Severity: wishlist

Needed by container/storage v1.16 branch

thanks

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

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

Bug#962426: golang-github-klauspost-compress: Please update to new upstream version 1.10.3

[Reinhard Tartler]

Package: golang-github-klauspost-compress
Severity: wishlist

This is needed by containers/storage v1.16.

Thanks!

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

Architecture: amd64 (x86_64)
Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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

Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint

[wxcafé]

Btw the workaround seems to be to mask zfs-mount-generator (`mkdir 
/etc/systemd/system-generators/; ln -s /dev/null 
/etc/systemd/system-generators/zfs-mount-generator`)


Cheers

-- 
Clément 'wxcafé' Hertling

Bug#960243: zimlib: diff for NMU version 4.0.4-5.1

[Sebastian Ramacher]

Control: tags 960243 + patch
Control: tags 960243 + pending

Dear maintainer,

I've prepared an NMU for zimlib (versioned as 4.0.4-5.1) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru zimlib-4.0.4/debian/changelog zimlib-4.0.4/debian/changelog
--- zimlib-4.0.4/debian/changelog	2018-12-19 09:53:38.0 +0100
+++ zimlib-4.0.4/debian/changelog	2020-06-07 22:26:22.0 +0200
@@ -1,3 +1,11 @@
+zimlib (4.0.4-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/libzim4.symbols: Mark more template instantiations as optional and
+update for changes due to icu 67. (Closes: #960243)
+
+ -- Sebastian Ramacher   Sun, 07 Jun 2020 22:26:22 +0200
+
 zimlib (4.0.4-5) unstable; urgency=medium
 
   * Have libzim-dev depend upon libraries it Requires in libzim.pc
diff -Nru zimlib-4.0.4/debian/libzim4.symbols zimlib-4.0.4/debian/libzim4.symbols
--- zimlib-4.0.4/debian/libzim4.symbols	2018-12-11 08:33:26.0 +0100
+++ zimlib-4.0.4/debian/libzim4.symbols	2020-06-07 22:25:05.0 +0200
@@ -165,6 +165,8 @@
  _ZN3zim4unix2FS6renameERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEES9_@Base 4.0.4
  _ZN3zim4unix2FS8openFileERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 4.0.4
  _ZN3zim4unix2FS9removeDirERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE@Base 4.0.4
+ (optional=templinst)_ZN3zim5CacheINS_15article_index_tESt10shared_ptrIKNS_6DirentEEE3putERKS1_RKS5_@Base 4.0.4
+ (optional=templinst)_ZN3zim5CacheINS_15cluster_index_tESt10shared_ptrINS_7ClusterEEE3putERKS1_RKS4_@Base 4.0.4
  _ZN3zim6Dirent15deletedMimeTypeE@Base 4.0.4
  _ZN3zim6Dirent16redirectMimeTypeE@Base 4.0.4
  _ZN3zim6Dirent18linktargetMimeTypeE@Base 4.0.4
@@ -310,10 +312,10 @@
  (optional=templinst)_ZN5QueueIPN3zim6writer7ClusterEED0Ev@Base 4.0.4
  (optional=templinst)_ZN5QueueIPN3zim6writer7ClusterEED1Ev@Base 4.0.4
  (optional=templinst)_ZN5QueueIPN3zim6writer7ClusterEED2Ev@Base 4.0.4
- (optional=templinst)_ZN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIc6AppendEPKci@Base 4.0.4
- (optional=templinst)_ZN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD0Ev@Base 4.0.4
- (optional=templinst)_ZN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD1Ev@Base 4.0.4
- (optional=templinst)_ZN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD2Ev@Base 4.0.4
+ (optional=templinst)_ZN6icu_6714StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIc6AppendEPKci@Base 4.0.4
+ (optional=templinst)_ZN6icu_6714StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD0Ev@Base 4.0.4
+ (optional=templinst)_ZN6icu_6714StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD1Ev@Base 4.0.4
+ (optional=templinst)_ZN6icu_6714StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcD2Ev@Base 4.0.4
  _ZN8RESOURCE9stopwords2enB5cxx11E@Base 4.0.4
  _ZN8RESOURCE9stopwords2heB5cxx11E@Base 4.0.4
  _ZN8RESOURCE9stopwords3fraB5cxx11E@Base 4.0.4
@@ -454,8 +456,8 @@
  (optional=templinst|arch=ia64)_ZNSt10unique_ptrIN3zim15search_iterator12InternalDataESt14default_deleteIS2_EED2Ev@Base 4.0.4
  (optional=templinst|arch=ia64)_ZNSt10unique_ptrIN3zim6Search12InternalDataESt14default_deleteIS2_EED1Ev@Base 4.0.4
  (optional=templinst|arch=ia64)_ZNSt10unique_ptrIN3zim6Search12InternalDataESt14default_deleteIS2_EED2Ev@Base 4.0.4
- (optional=templinst)_ZNSt10unique_ptrIN6icu_6314TransliteratorESt14default_deleteIS1_EED1Ev@Base 4.0.4
- (optional=templinst)_ZNSt10unique_ptrIN6icu_6314TransliteratorESt14default_deleteIS1_EED2Ev@Base 4.0.4
+ (optional=templinst)_ZNSt10unique_ptrIN6icu_6714TransliteratorESt14default_deleteIS1_EED1Ev@Base 4.0.4
+ (optional=templinst)_ZNSt10unique_ptrIN6icu_6714TransliteratorESt14default_deleteIS1_EED2Ev@Base 4.0.4
  (optional=templinst)_ZNSt11_Deque_baseIPN3zim6writer7ClusterESaIS3_EED1Ev@Base 4.0.4
  (optional=templinst)_ZNSt11_Deque_baseIPN3zim6writer7ClusterESaIS3_EED2Ev@Base 4.0.4
  (optional=templinst|arch=armel)_ZNSt12__shared_ptrIKN3zim6BufferELN9__gnu_cxx12_Lock_policyE1EEC1INS0_12MemoryBufferILb1EEEvEEPT_@Base 4.0.4
@@ -664,6 +666,7 @@
  (optional=templinst|arch=!ia64)_ZSt4swapIN3zim6writer6DirentEENSt9enable_ifIXsrSt6__and_IJSt6__not_ISt15__is_tuple_likeIT_EESt21is_move_constructibleIS7_ESt18is_move_assignableIS7_EEE5valueEvE4typeERS7_SH_@Base 4.0.4
  (optional=templinst)_ZSt9__find_ifIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS0_5__ops10_Iter_predIPFbcT_SG_SG_T0_St26random_access_iterator_tag@Base 4.0.4
  (optional=templinst)_ZSt9__find_ifIN9__gnu_cxx17__normal_iteratorIPKcNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcENS0_5__ops16_Iter_equals_valIS2_EEET_SE_SE_T0_St26random_access_iterator_tag@Base 4.0.4
+ (optional=templinst)_ZStplIcSt11char_traitsIcESaIcEENSt7__cxx1112basic_stringIT_T0_T1_EEOS8_RKS8_@Base 4.0.4
  

Bug#962425: libscrypt-kdf-dev: broken symlink installed

[Matthew Fernandez]

Subject: libscrypt-kdf-dev: broken symlink installed
Package: libscrypt-kdf-dev
Version: 1.3.0-3
Severity: normal

Dear Maintainer,

When installing libscrypt-kdf-dev on amd64, a symlink libscrypt-kdf.so ->
libscrypt-kdf.so.1.0.0 is installed in /usr/lib/x86_64-linux-gnu.
However, libscrypt-kdf.so.1.0.0 itself is not installed. This results in
confusing link failures when you try to compile against it. I think the
problem is that libscrypt-kdf-dev is lacking a dependency on
libscrypt-kdf1 that installs the SO.

Thanks,
Matt

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

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

-- no debconf information
Report will be sent to Debian Bug Tracking System 

Bug#959599: frama-c: FTBFS fixed upstream

[John Scott]

Control: forwarded -1 
https://lists.gforge.inria.fr/pipermail/frama-c-discuss/2020-June/005823.html
Control: tags -1 fixed-upstream
> Hello,
> 
> Le jeu. 4 juin 2020 à 18:43, John Scott  a écrit :
> > I'm not the maintainer, just a prospective user taking a look, but Frama-C
> > hasn't been building from source in a while [1] and I couldn't find a bug
> > for
> > it. It fails with
> > File "src/plugins/wp/ProverWhy3.ml", line 131, characters 29-45:
> > 131 |   Why3.(Term.t_const Number.(const_of_big_int (BigInt.of_string
> > (Z.to_string z Why3.Ty.ty_int
> > Error: Unbound value const_of_big_int
> 
> Thanks for the report. There is indeed a compatibility issue between
> Frama-C 20.0 and Why3 1.3, which is fixed in the upcoming Frama-C 21.0
> (currently available in beta) On the other hand, Frama-C 21.0 won't be
> compatible with Why3 < 1.3

I'm having trouble finding their VCS and what commit fixed this, but updating
Frama-C to the beta should be sufficient. Unstable and testing already have
Why3 >= 1.3.

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

Bug#960321: burp: flaky arm64 autopkgtest: .../src/test/clientscript failed

[Calogero Lo Leggio]

As suggested by upstream developer, I removed superfluous 'slow and
intensive' test.


The definitive fix is introduced in version 2.2.18-8


References:
github issue to upstream dev: https://github.com/grke/burp/issues/866
salsa commit:
https://salsa.debian.org/debian/burp/-/commit/f9363a7af36ac729c319f0545c8b1e070df4090d


Thanks!


> References:
>
> [1]: https://github.com/grke/burp/issues/866
>
> [2]:
>
https://salsa.debian.org/debian/burp/-/commit/513e4c37a59f5cea98bc7723188c2ed0cb70f776
>



signature.asc
Description: OpenPGP digital signature

Bug#962424: zfsutils-linux: systemd zfs-mount-generator breaks boot if multiple datasets have the same mountpoint

[wxcafe]

Package: zfsutils-linux
Version: 0.8.4-1~bpo10+1
Severity: grave
Tags: upstream
Justification: renders package unusable

Hey

The systemd zfs-mount-generator script
(/lib/systemd/system-generators/zfs-mount-generator) can break system
boot if there are multiple datasets with the same mountpoint, because it
ignores the zfs property canmount=noauto.

I store backups on my system and after upgrading the system wouldn't
boot anymore because while my backups are canmount=noauto, the generator
was trying to mount multiple datasets to the same mountpoints (/, /usr/,
...) which obviously breaks... everything.

I'd say that's less than ideal. ZoL's integration with systemd has
always been subpar (until 0.8.4 zfs-import-cache was broken because it
looked at /usr/local/etc/zfs/zpool.cache instead of
/etc/zfs/zpool.cache, for example), but breaking boot in a patch release
is really not good


-- System Information:
Debian Release: 10.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.5.0-0.bpo.2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages zfsutils-linux depends on:
ii  libblkid12.33.1-0.1
ii  libc62.28-10
ii  libnvpair1linux  0.8.4-1~bpo10+1
ii  libudev1 241-7~deb10u4
ii  libuuid1 2.33.1-0.1
ii  libuutil1linux   0.8.4-1~bpo10+1
ii  libzfs2linux 0.8.4-1~bpo10+1
ii  libzpool2linux   0.8.4-1~bpo10+1
ii  python3  3.7.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages zfsutils-linux recommends:
ii  lsb-base10.2019051400
ii  zfs-dkms [zfs-modules]  0.8.4-1~bpo10+1
ii  zfs-zed 0.8.4-1~bpo10+1

Versions of packages zfsutils-linux suggests:
pn  nfs-kernel-server  
pn  samba-common-bin   
ii  zfs-initramfs  0.8.4-1~bpo10+1

-- Configuration Files:
/etc/cron.d/zfsutils-linux [Errno 2] No such file or directory: 
'/etc/cron.d/zfsutils-linux'
/etc/sudoers.d/zfs [Errno 13] Permission denied: '/etc/sudoers.d/zfs'

-- no debconf information

Bug#949837: innoextract: diff for NMU version 1.8-1.2

[Sebastian Ramacher]

Control: tags 949837 + pending

Dear maintainer,

I've prepared an NMU for innoextract (versioned as 1.8-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru innoextract-1.8/debian/changelog innoextract-1.8/debian/changelog
--- innoextract-1.8/debian/changelog	2020-05-02 20:00:51.0 +0200
+++ innoextract-1.8/debian/changelog	2020-06-07 22:00:19.0 +0200
@@ -1,3 +1,11 @@
+innoextract (1.8-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Apply upstream patch to fix build with boost 1.71.
+(Closes: #949837)
+
+ -- Sebastian Ramacher   Sun, 07 Jun 2020 22:00:19 +0200
+
 innoextract (1.8-1.1) unstable; urgency=low
 
   * Non-maintainer upload.
diff -Nru innoextract-1.8/debian/patches/b47f46102bccf1d813ca159230029b0cd820ceff.patch innoextract-1.8/debian/patches/b47f46102bccf1d813ca159230029b0cd820ceff.patch
--- innoextract-1.8/debian/patches/b47f46102bccf1d813ca159230029b0cd820ceff.patch	1970-01-01 01:00:00.0 +0100
+++ innoextract-1.8/debian/patches/b47f46102bccf1d813ca159230029b0cd820ceff.patch	2020-06-07 21:59:01.0 +0200
@@ -0,0 +1,158 @@
+From b47f46102bccf1d813ca159230029b0cd820ceff Mon Sep 17 00:00:00 2001
+From: Daniel Scharrer 
+Date: Mon, 23 Sep 2019 00:00:52 +0200
+Subject: [PATCH] CMake: Remove library link checks
+
+This was needed with older CMake versions to work around CMake searching
+under lib with -m32 instead of under lib32 for platforms where lib
+contains 64-bit binaries. This has since been fixed in CMake and users
+of older CMake versions can add the lib32 directories to
+CMAKE_LIBRARY_PATH to work around the issue on their end.
+
+With newer CMake and Boost versions these checks fail because the
+boost-config.cmake files shipped with Boost use imported targets instead
+of library paths and try_compile does not add these imported targets to
+the generated project.
+
+See: https://gitlab.kitware.com/cmake/cmake/issues/11260
+---
+ CMakeLists.txt   |  4 --
+ cmake/CompileCheck.cmake | 88 
+ 2 files changed, 92 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index b98e59d..8aba97c 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -158,7 +158,6 @@ endif()
+ 
+ if(USE_LZMA)
+ 	find_package(LZMA REQUIRED)
+-	check_link_library(LZMA LZMA_LIBRARIES)
+ 	list(APPEND LIBRARIES ${LZMA_LIBRARIES})
+ 	include_directories(SYSTEM ${LZMA_INCLUDE_DIR})
+ 	add_definitions(${LZMA_DEFINITIONS})
+@@ -176,7 +175,6 @@ find_package(Boost REQUIRED COMPONENTS
+ 	system
+ 	program_options
+ )
+-check_link_library(Boost Boost_LIBRARIES)
+ list(APPEND LIBRARIES ${Boost_LIBRARIES})
+ link_directories(${Boost_LIBRARY_DIRS})
+ include_directories(SYSTEM ${Boost_INCLUDE_DIR})
+@@ -210,7 +208,6 @@ if(Boost_HAS_STATIC_LIBS)
+ break()
+ 			endif()
+ 		endforeach()
+-		check_link_library(${Lib} ${LIB}_LIBRARIES)
+ 		list(APPEND LIBRARIES ${${LIB}_LIBRARIES})
+ 	endforeach()
+ endif()
+@@ -227,7 +224,6 @@ elseif(NOT WITH_CONV OR WITH_CONV STREQUAL "iconv")
+ 	endif()
+ 	find_package(iconv ${ICONV_REQUIRED})
+ 	if(ICONV_FOUND)
+-		check_link_library(iconv iconv_LIBRARIES)
+ 		list(APPEND LIBRARIES ${iconv_LIBRARIES})
+ 		include_directories(SYSTEM ${iconv_INCLUDE_DIR})
+ 		add_definitions(${iconv_DEFINITIONS})
+diff --git a/cmake/CompileCheck.cmake b/cmake/CompileCheck.cmake
+index 1e88599..4a72d38 100644
+--- a/cmake/CompileCheck.cmake
 b/cmake/CompileCheck.cmake
+@@ -192,95 +192,7 @@ function(add_ldflag FLAG)
+ 	
+ endfunction(add_ldflag)
+ 
+-function(try_link_library LIBRARY_NAME LIBRARY_FILE ERROR_VAR)
+-	# See if we can link a simple program with the library using the configured c++ compiler
+-	set(link_test_file "${CMAKE_CURRENT_BINARY_DIR}/link_test.cpp")
+-	file(WRITE ${link_test_file} "int main(){}\n")
+-	if(CMAKE_THREAD_LIBS_INIT)
+-		list(APPEND LIBRARY_FILE "${CMAKE_THREAD_LIBS_INIT}")
+-	endif()
+-	try_compile(
+-		CHECK_${LIBRARY_NAME}_LINK "${PROJECT_BINARY_DIR}" "${link_test_file}"
+-		CMAKE_FLAGS "-DLINK_LIBRARIES=${LIBRARY_FILE}"
+-		"-DCMAKE_CXX_FLAGS=${CMAKE_CXX_FLAGS}"
+-		"-DCMAKE_EXE_LINKER_FLAGS=${CMAKE_EXE_LINKER_FLAGS}"
+-		"-DCMAKE_SHARED_LINKER_FLAGS=${CMAKE_SHARED_LINKER_FLAGS}"
+-		"-DCMAKE_MODULE_LINKER_FLAGS=${CMAKE_MODULE_LINKER_FLAGS}"
+-		OUTPUT_VARIABLE ERRORLOG
+-	)
+-	set(${ERROR_VAR} "${ERRORLOG}" PARENT_SCOPE)
+-endfunction(try_link_library)
+-
+-##
+-# Check that a a library actually works for the current configuration
+-# This is neede because CMake prefers /usr/lib over /usr/lib32 for -m32 builds
+-# See https://public.kitware.com/Bug/view.php?id=11260
+-function(check_link_library LIBRARY_NAME LIBRARY_VARIABLE)
+-	
+-	if(MSVC)
+-		# The main point of this is to work around CMakes ignorance of lib32.
+-		# This doesn't really apply for systems 

Bug#962423: pglogical FTBFS error: static declaration of 'AcquireDeletionLock' follows non-static declaration

[peter green]

Package: pglogical
Version: 2.3.1-1
Severity: serious
Tags: ftbfs

It seems pglogical recently started failing to build.

http://buildd.raspbian.org/status/fetch.php?pkg=pglogical=armhf=2.3.1-1%2Bb1=1591473342

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/pglogical.html


/build/1st/pglogical-2.3.1/pglogical_dependency.c:235:13: error: static 
declaration of 'AcquireDeletionLock' follows non-static declaration
   235 | static void AcquireDeletionLock(const ObjectAddress *object, int 
flags);
   | ^~~
In file included from /build/1st/pglogical-2.3.1/pglogical_dependency.c:29:
/usr/include/postgresql/12/server/catalog/dependency.h:145:13: note: previous 
declaration of 'AcquireDeletionLock' was here
   145 | extern void AcquireDeletionLock(const ObjectAddress *object, int 
flags);
   | ^~~
/build/1st/pglogical-2.3.1/pglogical_dependency.c:236:13: error: static 
declaration of 'ReleaseDeletionLock' follows non-static declaration
   236 | static void ReleaseDeletionLock(const ObjectAddress *object);
   | ^~~
In file included from /build/1st/pglogical-2.3.1/pglogical_dependency.c:29:
/usr/include/postgresql/12/server/catalog/dependency.h:147:13: note: previous 
declaration of 'ReleaseDeletionLock' was here
   147 | extern void ReleaseDeletionLock(const ObjectAddress *object);
   | ^~~
make[2]: *** [: pglogical_dependency.o] Error 1

Bug#962422: /usr/local/lib/python3.8 owned by group staff even if /etc/staff-group-for-usr-local not present

[Sébastien Villemot]

Package: python3.8-minimal
Version: 3.8.3-1
Severity: normal

Dear Maintainer,

The /usr/local/lib/python3.8 directory (and its dist-packages subdirectory), as
created by the postinst script of python3.8-minimal, is always owned by group
staff, with permissions 2775.

This is a violation of Debian Policy §9.1.2. Those specific ownership and
permissions should only be given when the file /etc/staff-group-for-usr-local
is present. When it is not, the directory should be owned by root:root and have
permissions 0755.

Note that, since buster, new installations do not have
/etc/staff-group-for-usr-local by default, which makes this bug biting more
often.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#962421: libjs-pdf for PDF.js was packaged for Debian Jessie but is missing from Sid

[hyiltiz]

Package: libjs-pdf
Version: libjs-pdf is missing from the repository
Severity: normal

Any idea why this package is dropped? PDF.js is a very common library used by 
browsers to render PDF embedded inside the browser. I am using qutebrowser, and 
it couldn't not find pdf.js.

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

Kernel: Linux 5.6.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
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

Bug#962232: vanguards indirectly build-depends on cruft package.

[Scott Kitterman]

On Thu, 4 Jun 2020 21:21:53 +0100 peter green  wrote:
> Package: vanguards
> Version: 0.3.1-2
> Severity: serious
> 
> vanguards build-depends on pypy-pytest which depends on pypy-funcsigs which 
is no longer built by the python-funcsigs source package. The pytest 
maintainer has also said they would like to get rid of pypy support from 
pytest. Afaict vanguards is the only application that build-depends on pypy-
pytest (there are also some module packages but they all look like they could 
drop pypy support at the same time pytest does).
> 
> The ideal fix would be to move to pypy3, but I understand that is currently 
blocked on tooling (see https://bugs.debian.org/cgi-bin/bugreport.cgi?
bug=932820 ). Over in bug 937769 Chris Lamb proposed a patch to run the 
testsuite with python 3. Obviously running the testsuite with a different 
python version from that used to actually run the program is suboptimal but I 
think it's the lesser evil here.
> 
> I manually applied the patch, cleaning up some formatting and making the 
dependency versioning for the python3-stem build-dependency match that for the 
pypy-stem build-dependency. While testing I also noticed some clean target 
issues so I fixed them.
> 
> A debdiff is attatched, if I get no objections (and the maintainer doesn't 
upload this first) I will likely NMU this in a week or so.
> 
pypy-pytest is a cruft package now, so it's no longer indirect.

Scott K

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

Bug#962419: /usr/local/share/texmf owned by group staff even if /etc/staff-group-for-usr-local not present

[Sébastien Villemot]

Le dimanche 07 juin 2020 à 21:21 +0200, Sébastien Villemot a écrit :

> This is a violation of Debian Policy §9.1.2. Those specific ownerships and
> permissions should only be given when the file /etc/staff-group-for-usr-local
> is present. When it is not, the directory should be owned by root:root and 
> have
> permissions 0775.

Sorry, I meant 0755.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#962414: [Pkg-fonts-devel] Bug#962414: Please import new upstream version 4 or newer

[Fabian Greffrath]

Hi,FiraCode v4 has a major regression, thus I'd rather wait for the next 
release: 
https://github.com/tonsky/FiraCode/issues/1049https://github.com/tonsky/FiraCode/issues/1059
 - FabianVon meinem Samsung Galaxy Smartphone gesendet.
 Ursprüngliche Nachricht Von: Nicholas D Steeves 
 Datum: 07.06.20  19:57  (GMT+01:00) An: Debian Bug 
Tracking System  Betreff: [Pkg-fonts-devel] Bug#962414: 
Please import new upstream version 4
  or newer Package: fonts-firacodeVersion: 3.1+dfsg1-1Severity: normalHi,While 
investigating which version of Fira fonts were bundled with anapplication I'm 
packaging, I noticed that our fonts-firacode packagewas out of date.Please 
import new upstream version 4 or newer.Best,NicholasP.S. Thank you for building 
woff2 format 
fonts!___Pkg-fonts-devel mailing 
listPkg-fonts-devel@alioth-lists.debian.nethttps://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-fonts-devel

Bug#962420: /usr/local/share/fonts owned by group staff even if /etc/staff-group-for-usr-local not present

[Sébastien Villemot]

Le dimanche 07 juin 2020 à 21:26 +0200, Sébastien Villemot a écrit :

> This is a violation of Debian Policy §9.1.2. Those specific ownerships and
> permissions should only be given when the file /etc/staff-group-for-usr-local
> is present. When it is not, the directory should be owned by root:root and 
> have
> permissions 0775.

Sorry, I meant 0755.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  https://sebastien.villemot.name
⠈⠳⣄  https://www.debian.org



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

Bug#962420: /usr/local/share/fonts owned by group staff even if /etc/staff-group-for-usr-local not present

[Sébastien Villemot]

Package: fontconfig-config
Version: 2.13.1-2
Severity: normal

The /usr/local/share/fonts directory, as created by the postinst script of
fontconfig-config, is always owned by group staff, with permissions 2775.

This is a violation of Debian Policy §9.1.2. Those specific ownerships and
permissions should only be given when the file /etc/staff-group-for-usr-local
is present. When it is not, the directory should be owned by root:root and have
permissions 0775.

Note that, since buster, new installations do not have
/etc/staff-group-for-usr-local by default, which makes this bug biting more
often.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#956253: mu-editor 1.0.3 packaged (with bonus features)

[Keith Packard]

Nick Morrott  writes:

> There is a bug report asking for 1.1.alpha to be packaged [1], so I
> think a sensible plan might be to get a mildly-patched 1.0.3 into
> unstable and then consider uploading the current alpha into
> experimental?

I had packaged 1.1.alpha, which has a number of useful additions
(including built-in reformatting), but then went and looked at the
Debian packaging and noticed that you had fixed a number of DFSG
issues. It would probably be easier to merge changes from upstream to a
1.1.alpha experimental release than on top of 1.0.3, so it might make
sense to publish a 'pure' 1.0.3 to unstable and then add a fancy
1.1.alpha to experimental.

Are you keeping a patch-queue branch anywhere to help with evaluating
which fixes to include? I've pushed my branch to

https://salsa.debian.org/keithp/mu-editor/-/tree/patch-queue/debian/master

That's got the three additions I'm using in class:

 1. add snek mode (needed for my snek-based class)
 2. close repl/plotter when serial port disappears (helps when unplugging USB)
 3. scale button bar icons (helps on small screens)

I had to back-port these to 1.0.3, so they haven't had as much review or
testing in this version.

> I wonder if there are there any other standalone commits post 1.0.3
> that might also be worthwhile patching in? Let me look into this this
> week.

Thanks.

-- 
-keith


signature.asc
Description: PGP signature

Bug#962139: [btrfs-progs] initramfs hooks failed with on libgcc_s.so.1

[Daniel Schröter]

On 04.06.20 20:18, Daniel Schröter wrote:
> I have the file under /usr:
> # ll /usr/lib/x86_64-linux-gnu/libgcc_s.so.1
> -rw-r--r-- 1 root root 99K Feb  4 15:52 
> /usr/lib/x86_64-linux-gnu/libgcc_s.so.1

I linked it:
# ln -s /usr/lib/x86_64-linux-gnu/libgcc_s.so.1 
/lib/x86_64-linux-gnu/libgcc_s.so.1

and now its working.
Maybe it's a bug in libgcc1. But I cannot upgrade it to version 10.1.0 because 
of missing
dependencies to gcc-10-base (UNAVAILABLE).

Bye

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Laura Arjona Reina]

Hi

El 7/6/20 a las 16:02, Axel Beckert escribió:

> Just ot be sure: I should still provide a stable update for buster,
> right?
> 

I don't know if the type of bug qualifies for a stable update.

For www.debian.org, we'll be using the -O1 workaround for building the
Chinese pages, and that's about optimization, we don't lose any
functionality, so I think we can wait for bullseye.

Boyuan, please correct me if I am wrong...

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#962419: /usr/local/share/texmf owned by group staff even if /etc/staff-group-for-usr-local not present

[Sébastien Villemot]

Package: tex-common
Version: 6.11
Severity: normal

Dear Maintainer,

The /usr/local/share/texmf directory, as created by the postinst script, is
always owned by group staff, with permissions 2775.

This is a violation of Debian Policy §9.1.2. Those specific ownerships and
permissions should only be given when the file /etc/staff-group-for-usr-local
is present. When it is not, the directory should be owned by root:root and have
permissions 0775.

Note that, since buster, new installations do not have
/etc/staff-group-for-usr-local by default, which makes this bug biting more
often.

Best,

--
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org

Bug#962418: ITP: python-email-validator -- Robust email address syntax and deliverability validation library

[Sergio Durigan Junior]

Package: wnpp
Severity: wishlist
Owner: Sergio Durigan Junior 

* Package name: python-email-validator
  Version : 1.1.1
  Upstream Author : Joshua Tauberer 
* URL : https://github.com/JoshData/python-email-validator
* License : Public Domain
  Programming Lang: Python
  Description : Robust email address syntax and deliverability validation 
library

 This library validates that a string is of the form x...@y.com. This is
 the sort of validation you would want for an email-based login form
 on a website.

I will maintain this package with the DPMT.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/


signature.asc
Description: PGP signature

Bug#962284: mailman: File "/usr/lib/mailman/cron/cull_bad_shunt", line 77 SyntaxError with Python 3

[Dominic Hargreaves]

On Sun, Jun 07, 2020 at 11:30:55AM -0600, Joe Pfeiffer wrote:
> Dominic Hargreaves writes:
> >
> >Mailman 2 will never support python 3 and it has been removed from
> >unstable and testing (see mailman3 for the future, but bear in mind it's
> >very much not a transparent upgrade).
> 
> Yeah, the amount of work I anticipate for the switch is why I've been
> procrastinating.  I wasn't aware it had been removed from unstable and
> testing; it sounds like I'm going to have to bite the bullet sooner
> rather than later

Yep, I sympathise - I have the same issue (speaking as one of the
maintainers of alioth-lists.debian.net as well as some other installs.
(For the avoidance of doubt, I'm not the maintainer of the mailman
package.)

I believe it's already been determined that python 2 will not be shipped
with bullseye.

> >That said, as far as I can tell even
> >in unstable, /usr/bin/python is still pointing to /usr/bin/python2.7,
> >so you must have manually changed the link in /usr/bin/python behind
> >the packaging system's back?
> 
> At this point, update-alternatives lists python3 as the "auto"
> alternative, so that appears to be the default (I'm nothing resembling
> an expert on Debian policies or packaging, so it's entirely possible
> I'm reading more into that than I should).

This confused me, since Python in Debian doesn't have alternatives set
up - but a quick web search reveals various people suggesting receipes
for setting this up by hand, so at a guess you must have done this,
aybe following something like this?

https://stackoverflow.com/questions/43062608/how-to-update-alternatives-to-python-3-without-breaking-apt

The default you're seeing is not a part of the Debian system.

I mention this merely as a clarification for future readers of the
bug report. Glad to see that you've managed to get things working
for yourself :)

Cheers
Dominic

Bug#721192: ITP: apostrophe -- a simple markdown editor

[Nicholas D Steeves]

correction:

Nicholas D Steeves  writes:

> Interesting you found this issue!  I just imported the latest release
> and found bundled woff2-format fonts (non dfsg-free).  I've contacted
> upstream about this.  FYI, for fonts to be dfsg-free their source needs
> to be included.  If Apostrophe cannot be made to work with
> fonts-firacode and/or texlive-fonts-extra, then our options are a) wait
> for the maintainer[s] of that/those package[s] to provide woff2 format
> fonts b) use missing-source to get those fonts' source and compile the
> required woff2 fonts during Apostrophe's build, then bundle the
> Apostrophe-specific font binaries with this package.
>

fonts-firacode already provides woff2-format.


signature.asc
Description: PGP signature

Bug#962417: ITP: pll-modules -- high level modules for the low level phylogenetic likelihood library (devel)

[Shayan Doust]

Package: wnpp
Severity: wishlist

Subject: ITP: pll-modules -- high level modules for the low level phylogenetic 
likelihood library (devel)
Package: wnpp
Owner: Shayan Doust 
Severity: wishlist

* Package name: pll-modules
  Version : 0.0+git20170809.d6cc565
  Upstream Author : , 2016, Diego Darriba
* URL : https://github.com/ddarriba/pll-modules
* License : AGPL-3+
  Programming Lang: C
  Description : high level modules for the low level phylogenetic 
likelihood library (devel)
 This package provides high level modules for the low level phylogenetic
 likelihood library.
 .
 This package contains the static library and header files.

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

Bug#960243: zimlib FTBFS with ICU 67.1

[Peter Green]

I downloaded the build logs  and filtered them to show the missing symbols that 
were not already marked as optional.

plugwash@thinkpad:~$ wget -O zimlib.log 
'https://buildd.debian.org/status/fetch.php?pkg=zimlib=amd64=4.0.4-5%2Bb1=1591384179=0'
plugwash@thinkpad:~$ html2text -width 10 zimlib.log | grep MISSING | grep 
-v optional
+#MISSING: 4.0.4-5+b1# 
_ZTIN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcE@Base
 4.0.4
+#MISSING: 4.0.4-5+b1# 
_ZTSN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcE@Base
 4.0.4
+#MISSING: 4.0.4-5+b1# 
_ZTVN6icu_6314StringByteSinkINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcE@Base
 4.0.4
plugwash@thinkpad:~$

Decoding these with c++filt -n goves

typeinfo for icu_63::StringByteSink, std::allocator > >
typeinfo name for icu_63::StringByteSink, std::allocator > >
vtable for icu_63::StringByteSink, 
std::allocator > >

These look like ICU template instantiations to me and seem unlikely to be part 
of the public interface of zimlib. If I was the maintainer I would probablly 
just mark them as optional.

Bug#721192: ITP: apostrophe -- a simple markdown editor

[Nicholas D Steeves]

Control: unblock -1 by 960767
Control: forwarded -1 https://gitlab.gnome.org/somas/apostrophe/-/issues/189

Hi Birger,

Birger Schacht  writes:

> Hi,
>
> I'd be also interested in getting apostrophe into Debian. I tried the
> flatpak version, but there seems to be a problem with missing fonts
> which makes the text harder to read.
>

Interesting you found this issue!  I just imported the latest release
and found bundled woff2-format fonts (non dfsg-free).  I've contacted
upstream about this.  FYI, for fonts to be dfsg-free their source needs
to be included.  If Apostrophe cannot be made to work with
fonts-firacode and/or texlive-fonts-extra, then our options are a) wait
for the maintainer[s] of that/those package[s] to provide woff2 format
fonts b) use missing-source to get those fonts' source and compile the
required woff2 fonts during Apostrophe's build, then bundle the
Apostrophe-specific font binaries with this package.

> I took a glance a the code and although pressagio is mentioned in
> `apostrophe/auto_correct.py` that file does not seem to be used in the
> app (yet?). Are you sure its a blocker?
>

It had set it as a blocker while I continued the copyright review,
because I had hoped that upstream would have reenabled this
functionality by now.  It looks like they haven't yet, so I've unblocked
this bug.  FYI, that discussion was moved here:

  https://gitlab.gnome.org/somas/apostrophe/-/issues/200#note_742981

> I created a preliminary package (because, confused as I am, I didn't
> realize there is already an ITP ;)) and using that I did not encounter
> any problems (though its not in any way ready for release- I did not
> even look at the licenses for example...)
>

Sorry for your wasted time.  For future reference, always check for an
ITP first, take a glance at the build system to verify it's something
you know how to package, and then do the copyright review before finally
proceeding with any work.  Why?  It doesn't make sense to spend all the
time packaging something for Debian just to learn that ftpmasters (or
your sponsor) will reject it.  It's only happened to me once or twice,
but there have been times where upstream's unwillingness to make changes
made a package impossible to include in Debian (eg: "non" due to
waf...with waf-embedded py2 IIRC).

> Nicholas, if you push your repository to salsa I'd be happy to help with
> the remaining 20%!
>

Unfortunately the source repo is not yet DFSG-free and thus cannot be
redistributed on Debian infrastructure.  Yeah, for two font files, but
this is one rule I will not bend.

Thank you for the offer!  As soon as I'm able to I'll push to the PAPT :-)

Cheers,
Nicholas

Bug#962247: Required Configuration Files Not Found

[Nilesh Patra]

Hi,

On Fri, 5 Jun 2020 at 14:30, Andreas Tille  wrote:

> Hi Dario,
>
> thanks a lot for your bug report.  To bad that nobody reported before
> this issue which seems pretty obvious.  May be everybody is using circos
> with the --conf option (as our autopkgtest is doing it as well) and thus
> the issue was hidden.
>
> On Fri, Jun 05, 2020 at 02:00:13AM +, Dario Strbenac wrote:
> > Package: circos
> > Version: 0.69.6
> >
> > I think this software has not been correctly packaged. Running the
> circos command with no parameters results in
> >
> >   The Config::General module reported the error
> >   Config::General The file "etc/colors_fonts_patterns.conf" does not
> exist
> >   within ConfigPath:
> >
>  
> /etc/circos.circos.circos/etc./usr/bin/etc./usr/bin/../etc./usr/bin/.../usr/bin!
> >   at /usr/share/perl5/Circos/Configuration.pm line 820
> >
> > The server administrator at university investigated the c and explains
> "The issue is that it looked for file etc/colors_fonts_patterns.conf in
> various places including current directory and in /etc/circos, when that
> file was present as /etc/circos/colors_fonts_patterns.conf (while circos
> tried the name /etc/circos/etc/colors_fonts_patterns.conf with an extra or
> bogus /etc/ in the middle)."
>
> I've patched the code and moved some additional config files from
> examples to /etc/circos which helped to solve all these issues.
> Unfortunately there is a remaining one.  @Nilesh or @Pranav:  Do you
> have time to fix this one:
>
> /tmp $ circos
> debuggroup summary 0.17s welcome to circos v0.69-8 15 Jun 2019 on Perl
> 5.030002
> debuggroup summary 0.17s current working directory /tmp
> debuggroup summary 0.17s command /usr/bin/circos [no flags]
> debuggroup summary 0.17s guessing configuration file
> debuggroup summary 0.17s found conf file /usr/share/circos/etc/circos.conf
>
>   *** CIRCOS ERROR ***
>
>   cwd: /tmp
>
>   command: /usr/bin/circos
>
>   CONFIGURATION FILE ERROR
>
>   Error parsing the configuration file. You used an <>
> directive,
>   but the FILE could not be found. This FILE is interpreted relative to the
>   configuration file in which the <> directive is used. Circos
> lookd
>   for the file in these directories
>
>   /usr/share/circos/etc
>
>   /etc/circos
>
>   /usr/share/circos/etc
>
>   /usr/share/circos/etc/etc
>
>   /usr/bin/etc
>
>   /usr/bin/../etc
>
>   /usr/bin/..
>
>   /usr/bin
>
>   The Config::General module reported the error
>
>   Config::General The file "/usr/share/circos/fonts.conf" does not exist
> within
>   ConfigPath:
>
> /usr/share/circos/etc./etc/circos./usr/share/circos/etc./usr/share/circos/etc/etc./usr/bin/etc./usr/bin/../etc./usr/bin/.../usr/bin!
>   at /usr/share/perl5/Circos/Configuration.pm line 820.
>
>   If you are having trouble debugging this error, first read the best
> practices
>   tutorial for helpful tips that address many common problems
>
>
> http://www.circos.ca/documentation/tutorials/reference/best_practices
>
>   The debugging facility is helpful to figure out what's happening under
> the
>   hood
>
>   http://www.circos.ca/documentation/tutorials/configuration/debugging
>
>   If you're still stumped, get support in the Circos Google Group.
>
>   http://groups.google.com/group/circos-data-visualization
>
>   Please include this error, all your configuration, data files and the
> version
>   of Circos you're running (circos -v). Do not email me directly -- please
> use
>   the group.
>
>   Stack trace:
>  at /usr/share/perl5/Circos/Error.pm line 425.
> Circos::Error::fatal_error("configuration", "cannot_find_include",
> "/usr/share/circos/etc\x{a}/etc/circos\x{a}/usr/share/circos/etc\x{a}/usr/"...,
> "Config::General The file \"/usr/share/circos/fonts.conf\" does "...)
> called at /usr/share/perl5/Circos/Configuration.pm line 826
>
> Circos::Configuration::loadconfiguration("/usr/share/circos/etc/circos.conf")
> called at /usr/share/perl5/Circos.pm line 148
> Circos::run("Circos", "_cwd", "/tmp", "_argv", "") called at
> /usr/bin/circos line 538
>
>
> I admit I'm running out of ideas why the file
>
>   Config::General The file "/usr/share/circos/fonts.conf" does not
> exist within
>
> is seeked instead of  "/usr/share/circos/etc/fonts.conf" - may be that's
> a cause of the patches I did in debian/patches/fix_config_path.patch.
>
> Unfortunately I'm a bit running out of time to hunt this down finally.
>

This was so because the config files are full of (relative) hardcoded
paths.
I read up the documentation, only to realise that the code just works that
way i.e. with hardcoded relative paths: the only way to prevent this is to
add an absolute hard-coded path.
Hence, I replaced all the hardcoded paths with the installation paths
(which is also, in a way hard-coded). But this will likely work on all(most
of) GNU/Linux distributions and I suppose that's what we care about.
I've pushed a patch, please take a look if it looks right to you.

Kind Regards,

Bug#962416: debianutils: [INTL:pt] Update on Portuguese translation of manpage

[Américo Monteiro]

Package: debianutils
Version: 4.11
3ags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  debianutils's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro




debianutils_4.11_pt.po.gz
Description: application/gzip

Bug#962381: gqrx-sdr: gqrx segmentation fault at start time in testing

[A. Maitland Bottoms]

On Sun, 07 Jun 2020 10:36:54 +0200
Antonio Radici  wrote:

> gqrx does not start in testing, this renders the package unusable.

I'm sorry to hear this.

I noticed the -b3 version get upgraded today too, but it works for me
when I start it
(I have a box tracking testing, so no chroot here.)

> 
> The problem is reproducible by spinning up a testing chroot (as of
> today) and trying to start gqrx

gqrx without hardware can be fragile. For that there are run time
arguments. `gqrx --reset` and `gqrx --edit` handle initial
configuration problems. Does it then work for you selecting the input
device doing `gqrx --edit` ?

What device are you trying to use? Does your chroot expose it correctly
and with the right permissions?

-Maitland

Bug#962415: RFP: j-lawyer office app for German lawyers

[Dr. Michael Stehmann]

Package: wnpp
Severity: wishlist
* Package name : j-lawyer.org
  Version : 1.12.0.8
  Upstream Author : Jens Kutschke 
* URL : https://www.j-lawyer.org
* License : GNU Affero General Public License version 3
  Programming Lang: java
  Description : application for German lawyers

The market for law firm software is almost completely dominated by
proprietary solutions. j-lawyer.org is a professional and free
alternative for all commercial software solutions. It includes document
management, address and file management, but also functions like direct
search in judgements and laws.

The software is built on a three-tier architecture based on a database
(MySQL or MariaDB), middleware (Wildfly AS) and a client (Java).

This application won the third prize of Thomas-Krenn-Award 2019.

While libreoffice-canzeley-client is designed for smaller law firms,
j-lawyer.org satisfies the needs of larger ones.

I do not use it myself because I am the author of Canzeley (upstream of
libreoffice-canzeley-client), but j-lawyer.org is a very important
component to establish Free Software in companies.

Kind regards
Michael Stehmann



signature.asc
Description: OpenPGP digital signature

Bug#962414: Please import new upstream version 4 or newer

[Nicholas D Steeves]

Package: fonts-firacode
Version: 3.1+dfsg1-1
Severity: normal

Hi,

While investigating which version of Fira fonts were bundled with an
application I'm packaging, I noticed that our fonts-firacode package
was out of date.

Please import new upstream version 4 or newer.


Best,
Nicholas

P.S. Thank you for building woff2 format fonts!

Bug#771080: Still a problem

[darkdragon]

This bug is driving me crazy for some time. While it is possible to disable
auto unmounting completely (setting timeout to zero), I actually *want*
auto unmount when *nothing* is open while keeping it mounted when
*anything* (e.g. nautilus) is open. It would be really nice, if nautilus
would show the same expected behavior as thunar.

Bug#962388: ITP: re2j -- linear-time regular expression matching in Java

[Vincent Prat]

I get your point here.
Thank you for pointing this out.
I will try to contact upstream to clarify the issue.

Bug#962284: mailman: File "/usr/lib/mailman/cron/cull_bad_shunt", line 77 SyntaxError with Python 3

[Joe Pfeiffer]

Dominic Hargreaves writes:
>
>Mailman 2 will never support python 3 and it has been removed from
>unstable and testing (see mailman3 for the future, but bear in mind it's
>very much not a transparent upgrade).

Yeah, the amount of work I anticipate for the switch is why I've been
procrastinating.  I wasn't aware it had been removed from unstable and
testing; it sounds like I'm going to have to bite the bullet sooner
rather than later

>That said, as far as I can tell even
>in unstable, /usr/bin/python is still pointing to /usr/bin/python2.7,
>so you must have manually changed the link in /usr/bin/python behind
>the packaging system's back?

At this point, update-alternatives lists python3 as the "auto"
alternative, so that appears to be the default (I'm nothing resembling
an expert on Debian policies or packaging, so it's entirely possible
I'm reading more into that than I should).

>It does appear to be a bug in this package that /usr/bin/python is used
>(Python policy says that /usr/bin/python2 must be used if the
>application requires a specific major version of python), but
>in practical terms it doesn't appear need fixing since the default isn't
>going to change in the stable releases.
>
>I've attached a trivial patch for completeness (which I prepared before
>I realised that there is no supported mechanism to actually switch
>/usr/bin/python that I can see) in case it's of help. If you're manually
>changing files in /usr/bin, you could of course just fix the scripts
>to specify /usr/bin/python2 by hand, though I don't recommend this
>approach.

That's what I've wound up doing (after filing the bug report, I found
several more scripts in mailman that also break with python3).
-- 
Joe Pfeiffer   575.525.2764 (H)
1440 Tierra del Sol Dr 575.496.3501 (C)
Las Cruces, NM 88007-5548  

Bug#962413: fakeroot: [INTL:pt] Update on Portuguese translation of manpage

[Américo Monteiro]

Package: fakeroot
Version: 1.24-1
3ags: l10n, patch-
Severity: wishlist

Updated Portuguese translation for  fakeroot's manpage
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro




fakeroot_1.24-1_pt.po.gz
Description: application/gzip

Bug#962412: OpenRC and LSB header logic

[Ivan J.]

Package: insserv
Version: 1.21.0-1

Hi. Attached is an insserv patch that adds better support for OpenRC
initscripts. Naturally, it looks for #!/sbin/openrc-run as the shebang
in the initscript and acts accordingly.

If merged, this can also close #960934
>From 6b1313cb395d951bc1395137d8d2feff6f73eb23 Mon Sep 17 00:00:00 2001
From: Merlijn Wajer 
Date: Sun, 7 Jun 2020 17:22:06 +
Subject: [PATCH] Support OpenRC initscripts when scanning for LSB.

This patch adds support for OpenRC scripts and avoids the
unnecessary warnings that insserv produces when the LSB headers
are missing. In OpenRC they are unnecessary because dependencies
are handled internally with the depend() function.

Co-authored-by: Ivan J. 
---
 insserv.c | 43 +++
 1 file changed, 39 insertions(+), 4 deletions(-)

diff --git a/insserv.c b/insserv.c
index f949f05..75c6140 100644
--- a/insserv.c
+++ b/insserv.c
@@ -1390,6 +1390,35 @@ static inline void scan_script_reset(void)
 xreset(script_inf.interactive);
 }
 
+/*
+ * return 1 if the script is an openrc script
+ */
+
+static int is_openrc_job(const char *path)
+{
+char buf[64];
+FILE *script = NULL;
+
+script = fopen(path, "r");
+if (script == NULL) {
+warn("Can not open script %s: %s\n", path, strerror(errno));
+return 0;
+}
+
+if (fgets(buf, 64, script) == NULL) {
+warn("Could not read script %s: %s\n", path, strerror(errno));
+fclose(script);
+return 0;
+}
+
+fclose(script);
+
+if (!strncmp(buf, "#!/sbin/openrc-run\n", 19))
+return 1;
+
+return 0;
+}
+
 /*
  * return name of upstart job if the script is a symlink to
  * /lib/init/upstart-job, or NULL if path do not point to an
@@ -1461,6 +1490,7 @@ static char *is_upstart_job(const char *path)
 #define FOUND_LSB_OVERRIDE 0x04
 #define FOUND_LSB_UPSTART  0x08
 #define FOUND_LSB_SYSTEMD  0x10
+#define FOUND_LSB_OPENRC   0x20
 
 static int o_flags = O_RDONLY;
 
@@ -1820,6 +1850,11 @@ static uchar scan_script_defaults(int dfd, const char *restrict const path,
 }
 #endif /* WANT_SYSTEMD */
 
+if (is_openrc_job(path)) {
+ret |= FOUND_LSB_OPENRC;
+goto out;
+}
+
 if (NULL != (upstart_job = is_upstart_job(path))) {
 	xreset(upstart_job);
 	/*
@@ -2035,7 +2070,7 @@ static void scan_script_locations(const char *const path, const char *const over
 		if (!lsb)
 		service->attr.flags |= SERV_NOTLSB;
 
-		if ((lsb & FOUND_LSB_HEADER) == 0) {
+		if ((lsb & (FOUND_LSB_HEADER|FOUND_LSB_OPENRC)) == 0) {
 		if ((lsb & (FOUND_LSB_DEFAULT|FOUND_LSB_OVERRIDE)) == 0)
 		warn("warning: script '%s' missing LSB tags and overrides\n", d->d_name);
 		else
@@ -3134,7 +3169,7 @@ int main (int argc, char *argv[])
 	char * provides, * begin, * token;
 	const uchar lsb = scan_script_defaults(dfd, name, override_path, (char**)0, false, ignore);
 
-	if ((lsb & FOUND_LSB_HEADER) == 0) {
+	if ((lsb & (FOUND_LSB_HEADER|FOUND_LSB_OPENRC)) == 0) {
 	if ((lsb & (FOUND_LSB_DEFAULT|FOUND_LSB_OVERRIDE)) == 0)
 	warn("warning: script '%s' missing LSB tags and overrides\n", name);
 	else
@@ -3329,7 +3364,7 @@ int main (int argc, char *argv[])
 	/* main scanner for LSB comment in current script */
 	lsb = scan_script_defaults(dfd, d->d_name, override_path, (char**)0, false, ignore);
 
-	if ((lsb & FOUND_LSB_HEADER) == 0) {
+	if ((lsb & (FOUND_LSB_HEADER|FOUND_LSB_OPENRC)) == 0) {
 	if ((lsb & (FOUND_LSB_DEFAULT|FOUND_LSB_OVERRIDE)) == 0)
 	warn("warning: script '%s' missing LSB tags and overrides\n", d->d_name);
 	else
@@ -3370,7 +3405,7 @@ int main (int argc, char *argv[])
 #endif /* SUSE */
 
 #ifndef SUSE
-	if (!lsb) {
+	if (!lsb || (lsb & FOUND_LSB_OPENRC)) {
 	script_inf.required_start = xstrdup(DEFAULT_DEPENDENCY);
 	script_inf.required_stop = xstrdup(DEFAULT_DEPENDENCY);
 	script_inf.default_start = xstrdup(DEFAULT_START_LVL);
-- 
2.20.1

Bug#962411: bilibop: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: bilibop
Version: 0.6.1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for bilibop's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


bilibop_0.6.1_pt.po.gz
Description: application/gzip

Bug#962410: phonon: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: phonon
Version: 4_4.11.1-3
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for phonon's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


phonon_4_4.11.1-3_pt.po.gz
Description: application/gzip

Bug#924172: www.debian.org: differences under english/ between builds in stretch and buster

[Laura Arjona Reina]

Hello all,

Thanks Cyril for your work here.
We're trying to fix all the issues so the migration of www-master to
buster can be done as soon as possible.

I'll comment on the issues you found:

1. Changes related to canonicalization(?) of the URL

The files affected are:

1.1.- */News/news.*.rdf  (all languages)

All those files are built using /english/News/news.rdf.in which includes
this line:



it seems that the variable $(HOME) is interpreted differently by the
make or wml commands in buster.

I have played with the "-D HOME~." line in /english/.wmlrc but it does
not solve the issue.

The file is built (in english and all the other languages except
Chinese) by lines 36-37 of the /english/News/Makefile:

$(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) \
$(ENGLISHDIR)/News/news.rdf.in

If I change that to

$(WML) $(shell egrep '^-D (CUR_|CHAR)' ../.wmlrc) news.rdf.in

then the English file is built with correct URL to the CSS, but the
other languages fail.

I don't know how to solve this, except using an absolute reference to
the CSS file in the /english/News/news.rdf.in instead of the $(HOME)
variable.

1.2. */sitemap.*.html  (all languages)

I guess it's the same problem (that the $(HOME) variable is used and
interpreted wrongly with the new make or wml), but this file and how it
is built is more cryptic for me so I wouldn't know how to start.

The sitemap would be completely broken until this issue is fixed, if we
migrate www-master to buster :/

Help needed!

2. Changes in mail address representation

I confirm this happens but it's indeed random changes in the addresses
obfuscation, so I don't consider this an issue.

3. Changes in a log file

Not important (and probably we shouldn't provide the card there, maybe
in the debian-flyers repo?)

4. Changes in ordering of coordinators
5. Changes in ordering under wnpp
6. Changes in order under l10n
8. More ordering changes (architectures, DSAs)

Thanks for reporting, and for the work towards reproducibility.
I think these are not blockers for the migration to buster of
www-master.debian.org

Maybe we could open a specific bug about these "reproducibility issues"
and see if somebody is willing/able to work on it?

7. Changes related to image width/height attributes

This is indeed as Julien commented, a bug in wml which is fixed in buster.

Thanks
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#962396: debian-keyring: Please upload recent updates

[Gunnar Wolf]

close 962396
thanks

Bálint Réczey dijo [Sun, Jun 07, 2020 at 02:56:17PM +0200]:
> Please update the keyring. Thank you.
> The last update took place ~2 months ago and a new one would be due, I
> think. I'm looking forward to being able to upload to the archive
> again. :-)

Updates take place on a monthly basis, around the 25th every month. We
do not always update the package, as it's not really needed.

I will close this bug.

Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominique Dumont]

On Sunday, 24 May 2020 20:00:28 CEST gregor herrmann wrote:
> > So, what are people's thoughts? Do we want to take this position
> > and change the default in Debian? Extending distribution to debian-perl
> > for wider visibility.
> 
> A tentative "yes" from me :)

A more firm "yes" from me ;-)

> Maybe we should seek communication with upstream in
> https://github.com/chansen/p5-http-tiny/issues/68 (or a new issue
> since that one is closed) as a next step?

I do not really agree with the rationale of  
https://github.com/chansen/p5-http-tiny/issues/68. Most people won't make an 
informed decision because they 
won't realize that TLS is disabled. The only way for people to make an 
informed decision is to exit on error when verify_ssl is not defined, which is 
not really user friendly ;-)

I think TLS should be verified by default, even more so in Debian because our 
list of trusted CA is regularly updated.

All the best

Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominic Hargreaves]

Control: forwarded 954089 https://github.com/chansen/p5-http-tiny/issues/134
Control: forwarded 962407 https://github.com/chansen/p5-http-tiny/issues/134

On Sun, Jun 07, 2020 at 05:22:21PM +0100, Dominic Hargreaves wrote:
> Control: reassign -1 src:perl
> Control: retitle -1 perl: Default HTTP::Tiny to verifying SSL certificates
> 
> On Sun, May 24, 2020 at 08:00:28PM +0200, gregor herrmann wrote:
> > On Sun, 24 May 2020 17:38:54 +0100, Dominic Hargreaves wrote:
> > 
> > > I rebuilt perl with the patch at [1] and rebuild perl dependencies
> > > against it, and did not see any related failures [2].
> > 
> > Thanks alot!
> >  
> > > So, what are people's thoughts? Do we want to take this position
> > > and change the default in Debian? Extending distribution to debian-perl
> > > for wider visibility.
> > 
> > A tentative "yes" from me :)
> > 
> > Maybe we should seek communication with upstream in
> > https://github.com/chansen/p5-http-tiny/issues/68 (or a new issue
> > since that one is closed) as a next step?
> 
> I'll comment on the above issue (I don't think opening a new issue
> to discuss an identical point, even if it is a while later, is friendly
> to the project - and it makes the previous, relevant arguments, less
> visible.)

Correction, given the amount of time that's passed and that I'm not
even sure if the person who responded negatively on the previous
issue speaks for the current maintainers, I have opened a new issue:

https://github.com/chansen/p5-http-tiny/issues/134

Cheers
Dominic

Bug#962409: kwartz-client: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: kwartz-client
Version: 1.5-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for kwartz-client's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


kwartz-client_1.5-1_pt.po.gz
Description: application/gzip

Bug#962408: ldh-gui-suite: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: ldh-gui-suite
Version: 0.1_20190927-6
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for ldh-gui-suite's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


ldh-gui-suite_0.1_20190927-6_pt.po.gz
Description: application/gzip

Bug#954089: libplack-perl: Please verify server identity via SSL

[Dominic Hargreaves]

Control: reassign -1 src:perl
Control: retitle -1 perl: Default HTTP::Tiny to verifying SSL certificates

On Sun, May 24, 2020 at 08:00:28PM +0200, gregor herrmann wrote:
> On Sun, 24 May 2020 17:38:54 +0100, Dominic Hargreaves wrote:
> 
> > I rebuilt perl with the patch at [1] and rebuild perl dependencies
> > against it, and did not see any related failures [2].
> 
> Thanks alot!
>  
> > So, what are people's thoughts? Do we want to take this position
> > and change the default in Debian? Extending distribution to debian-perl
> > for wider visibility.
> 
> A tentative "yes" from me :)
> 
> Maybe we should seek communication with upstream in
> https://github.com/chansen/p5-http-tiny/issues/68 (or a new issue
> since that one is closed) as a next step?

I'll comment on the above issue (I don't think opening a new issue
to discuss an identical point, even if it is a while later, is friendly
to the project - and it makes the previous, relevant arguments, less
visible.)

Bug#962406: progress-linux: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: progress-linux
Version: 20190101-13
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for progress-linux's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


progress-linux_20190101-13_pt.po.gz
Description: application/gzip

Bug#962388: ITP: re2j -- linear-time regular expression matching in Java

[Florian Weimer]

* Vincent Prat:

> Package: wnpp
> Severity: wishlist
> X-Debbugs-CC: debian-j...@lists.debian.org
>
> * Package name    : re2j
>   Version     : 1.3
>   Upstream Author : The Go Authors
> * URL : https://github.com/google/re2j
> * License : BSD-3
>   Programming Lang: Java
>   Description : linear-time regular expression matching in Java

The upstream repository does not seem to contain a license for the
Java port, only an acknowledgment of the Go base.  It's unlikely that
the “Go authors“ wrote the Java port.  Is this really distributable?

Some files (java/com/google/re2j/Matcher.java for example) do not even
refer to the LICENSE file, making the distribution terms even less
clear.

Bug#962405: /proc/sys/kernel/random/boot_id DENIED

[Andrey Rahmatullin]

Package: apparmor
Version: 2.13.4-2
Severity: normal

audit[495496]: AVC apparmor="DENIED" operation="open" profile="/usr/sbin/cupsd"
name="/proc/sys/kernel/random/boot_id" pid=495496 comm="cupsd"
requested_mask="r" denied_mask="r" fsuid=0 ouid=0

This seems to be fixed in Ubuntu, see
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1872564 and
https://launchpadlibrarian.net/479552230/apparmor_2.13.3-7ubuntu5_2.13.3-7ubuntu6.diff.gz



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

Kernel: Linux 5.6.0-2-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.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 apparmor depends on:
ii  debconf [debconf-2.0]  1.5.74
ii  libc6  2.30-8
ii  lsb-base   11.1.0
ii  python33.8.2-3

apparmor recommends no packages.

Versions of packages apparmor suggests:
ii  apparmor-profiles-extra  1.27
ii  apparmor-utils   2.13.4-2

-- debconf information excluded

Bug#962404: ircd-hybrid: [INTL:pt] Updated Portuguese translation - debconf messages

[Américo Monteiro]

Package: ircd-hybrid
Version: 1_8.2.31+dfsg.1-1
Tags: l10n, patch
Severity: wishlist

Updated Portuguese translation for ircd-hybrid's debconf messages
Translator: Américo Monteiro 
Feel free to use it.

For translation updates please contact 'Last Translator' 

-- 
Melhores cumprimentos/Best regards,

Américo Monteiro

-


ircd-hybrid_1_8.2.31+dfsg.1-1_pt.po.gz
Description: application/gzip

Bug#962403: youtube-dl

[Rupert]

Package: youtube-dl
Version: 2019.01.17-1.1
Severity: normal

Dear Maintainer,
When trying to use youtube-dl I got the following error: "youtube says:
video not available" and tried to update by running the command
"youtube-dl -U" but got this: "youtube-dl: error: youtube-dl's
self-update mechanism is disabled on Debian. Please update youtube-dl
using apt(8). See https://packages.debian.org/sid/youtube-dl for the
latest packaged version." thing is apt kept telling me that the latest
youtube-dl version was installed, so I downloaded the .deb for testing
a.k.a Bullseye, installed it, fortunately it gave me no errors nor was
any package replaced/updated, no changes were made to the sources.list
file and now youtube-dl works as expected. Is it possible that Buster's
youtube-dl gets updated with Bullseye's as a regular update/upgrade via
apt?

-- System Information:
Debian Release: 10.4 (Buster/Stable)
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-9-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.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

Bug#922136: jmeter wont start due to mismatch version of PatternMatcher

[Emmanuel Bourg]

Le 12/02/2019 à 15:31, usuario a écrit :

> An error occurred: org/apache/oro/text/regex/PatternMatcher has been compiled 
> by a more recent version of the Java Runtime (class file version 54.0), this 
> version of the Java Runtime only recognizes class file versions up to 52.0

This error means OpenJDK 8 is your default JRE. You should use OpenJDK
11 instead:

sudo update-java-alternatives --set java-1.11.0-openjdk-amd64

Emmanuel Bourg

Bug#960301: firefox-esr: [regression] cannot find the microphone

[Francesco Poli]

On Thu, 4 Jun 2020 17:35:20 +0900 Mike Hommey wrote:

[...]
> Can you test 68.9.0esr-1?

I've just tried, after installing it from unstable.

No luck!
The microphone fails to work with firefox-esr/68.9.0esr-1



-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpkrZ1SZNrXo.pgp
Description: PGP signature

Bug#962401: netcdf-fortran: please make the build reproducible

[Sebastiaan Couwenberg]

Control: tags -1 pending

On 6/7/20 4:51 PM, Chris Lamb wrote:
> You have removed some settings, but you left in FFLAGS which varies on
> the buld path.

This is ideally something that is fixed in dpkg-buildflags or gcc, since
the introduction of the prefix-map option it also raised
file-references-package-build-path lintian issue for many packages.

> A patch is attached (which updates your existing patch) which
> sanitises this variable to remove the varying components rather than
> simply removing.

Thanks for the updated patch, I've applied the changes in git.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#962402: haskell-text-icu: FTBFS on ppc64el and s390x: toEnum{BlockCode}: tag (302) is outside of enumeration's range (0,280)

[Sebastian Ramacher]

Source: haskell-text-icu
Version: 0.7.0.1-13
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)

haskell-text-icu failed to build on ppc64el and s390x:
|   t_blockCode: [Failed]
| *** Failed! (after 25 tests):
| Exception:
|   toEnum{BlockCode}: tag (302) is outside of enumeration's range (0,280)
|   CallStack (from HasCallStack):
| error, called at Data/Text/ICU/Char.hsc:420:17 in 
text-icu-0.7.0.1-HrPKp64TYdw7vXJENJMEzR:Data.Text.ICU.Char
| '\200806'
| (used seed -154261753971613436)

See
https://buildd.debian.org/status/fetch.php?pkg=haskell-text-icu=ppc64el=0.7.0.1-13=1591383958=0

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#962284: mailman: File "/usr/lib/mailman/cron/cull_bad_shunt", line 77 SyntaxError with Python 3

[Dominic Hargreaves]

On Fri, Jun 05, 2020 at 08:56:57AM -0600, Joe Pfeiffer wrote:
> Got the following this morning, after switching to Python 3:
> 
> From: r...@pfeifferfamily.net (Cron Daemon)
> To: l...@pfeifferfamily.net
> Subject: Cron  [ -x /usr/lib/mailman/cron/cull_bad_shunt ] && 
> /usr/lib/mailman/cron/cull_bad_shunt
> Date: Fri, 05 Jun 2020 04:30:01 -0600
> Content-Type: text/plain; charset=UTF-8
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.28, version=1.2.4
> 
>   File "/usr/lib/mailman/cron/cull_bad_shunt", line 77
> except getopt.error, msg:
>^
> SyntaxError: invalid syntax
> 
> The issue appears to be that Python3 no longer accepts the comma in an
> except block.

Mailman 2 will never support python 3 and it has been removed from
unstable and testing (see mailman3 for the future, but bear in mind it's
very much not a transparent upgrade). That said, as far as I can tell even
in unstable, /usr/bin/python is still pointing to /usr/bin/python2.7,
so you must have manually changed the link in /usr/bin/python behind
the packaging system's back?

It does appear to be a bug in this package that /usr/bin/python is used
(Python policy says that /usr/bin/python2 must be used if the
application requires a specific major version of python), but
in practical terms it doesn't appear need fixing since the default isn't
going to change in the stable releases.

I've attached a trivial patch for completeness (which I prepared before
I realised that there is no supported mechanism to actually switch
/usr/bin/python that I can see) in case it's of help. If you're manually
changing files in /usr/bin, you could of course just fix the scripts
to specify /usr/bin/python2 by hand, though I don't recommend this
approach.

Dominic
diff -Nru mailman-2.1.29/debian/rules mailman-2.1.29/debian/rules
--- mailman-2.1.29/debian/rules	2018-06-23 14:14:21.0 +0100
+++ mailman-2.1.29/debian/rules	2020-06-07 15:01:34.0 +0100
@@ -38,7 +38,8 @@
 		--with-groupname=list \
 		--with-mail-gid=daemon --with-cgi-gid=www-data \
 		--without-permcheck --with-mailhost=localhost \
-		--with-urlhost=localhost
+		--with-urlhost=localhost \
+		--with-python=/usr/bin/python2
 
 clean:
 	dh_testdir

Bug#962401: netcdf-fortran: please make the build reproducible

[Chris Lamb]

Source: netcdf-fortran
Version: 4.5.3+ds-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

Hi,

Whilst working on the Reproducible Builds effort [0] we noticed that
netcdf-fortran could not be built reproducibly.

You have removed some settings, but you left in FFLAGS which varies on
the buld path.

A patch is attached (which updates your existing patch) which
sanitises this variable to remove the varying components rather than
simply removing.

 [0] https://reproducible-builds.org/


Regards,

--
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   ` a/configure.ac  2020-06-07 15:19:43.658722034 +0100
--- b/configure.ac  2020-06-07 15:43:28.676618324 +0100
@@ -600,6 +600,7 @@
 AC_SUBST(HAS_NC4_PARALLEL,[$nc_has_parallel4])
 AC_SUBST(HAS_PARALLEL,[$nc_has_parallel])
 AC_SUBST([AM_LDFLAGS])
+AC_SUBST(FFLAGS_FILTERED,[`echo "$FFLAGS" | sed -e 's@ [[^ 
]]*-f\(file\|debug\)-prefix-map=[[^ ]]*@@g'`])
 
 # Some files need to exist in build directories that do not correspond
 # to their source directory, or the test program makes an assumption
--- a/debian/patches/reproducible-settings.patch2020-06-07 
15:19:43.662722069 +0100
--- b/debian/patches/reproducible-settings.patch2020-06-07 
15:43:33.116653163 +0100
@@ -1,9 +1,9 @@
 Description: Remove settings that make the build unreproducible.
 Author: Bas Couwenberg 
 
 a/libnetcdff.settings.in
-+++ b/libnetcdff.settings.in
-@@ -4,9 +4,6 @@
+--- netcdf-fortran-4.5.3+ds.orig/libnetcdff.settings.in
 netcdf-fortran-4.5.3+ds/libnetcdff.settings.in
+@@ -4,15 +4,12 @@
  # General
  ---
  Library Version:  @PACKAGE_VERSION@
@@ -13,3 +13,20 @@
  Install Prefix: @prefix@
  
  # Compiling Options
+ -
+ Fortran Compiler:   @FC_VERSION@
+-FFLAGS: @FFLAGS@
++FFLAGS: @FFLAGS_FILTERED@
+ LDFLAGS:  @LDFLAGS@
+ AM_LDFLAGS: @AM_LDFLAGS@
+ Shared Library:   @enable_shared@
+--- netcdf-fortran-4.5.3+ds.orig/configure.ac
 netcdf-fortran-4.5.3+ds/configure.ac
+@@ -600,6 +600,7 @@ AC_SUBST(HAS_PNETCDF,[$nc_has_pnetcdf])
+ AC_SUBST(HAS_NC4_PARALLEL,[$nc_has_parallel4])
+ AC_SUBST(HAS_PARALLEL,[$nc_has_parallel])
+ AC_SUBST([AM_LDFLAGS])
++AC_SUBST(FFLAGS_FILTERED,[`echo "$FFLAGS" | sed -e 's@ [[^ 
]]*-f\(file\|debug\)-prefix-map=[[^ ]]*@@g'`])
+ 
+ # Some files need to exist in build directories that do not correspond
+ # to their source directory, or the test program makes an assumption
--- a/libnetcdff.settings.in2020-06-07 15:19:43.658722034 +0100
--- b/libnetcdff.settings.in2020-06-07 15:40:25.739206770 +0100
@@ -9,7 +9,7 @@
 # Compiling Options
 -
 Fortran Compiler:   @FC_VERSION@
-FFLAGS: @FFLAGS@
+FFLAGS: @FFLAGS_FILTERED@
 LDFLAGS:   @LDFLAGS@
 AM_LDFLAGS: @AM_LDFLAGS@
 Shared Library:@enable_shared@

Bug#962400: ITP: nanosv -- structural variant caller for nanopore data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: nanosv -- structural variant caller for nanopore data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: nanosv
  Version : 1.2.4
  Upstream Author : Markus J van Roosmalen 
* URL : https://github.com/mroosmalen/nanosv
* License : MIT
  Programming Lang: Python
  Description : structural variant caller for nanopore data
 NanoSV is a software package that can be used to identify structural
 genomic variations in long-read sequencing data, such as data produced
 by Oxford Nanopore Technologies’ MinION, GridION or PromethION
 instruments, or Pacific Biosciences RSII or Sequel sequencers. NanoSV
 has been extensively tested using Oxford Nanopore MinION sequencing data.

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

Bug#960562: [Aptitude-devel] Bug#960562: had to reinstall a package to avoid 'bullying'

[積丹尼 Dan Jacobson]

It turns out my city computer didn't have that problem. So I can't help
further with any bundles.

Bug#962190: primer3: please disable Big Endian tests on autopkgtests too

[Adrian Bunk]

On Thu, Jun 04, 2020 at 12:47:24PM +0200, Gianfranco Costamagna wrote:
> Source: primer3
> Version: 2.4.0-2
> Severity: serious
> 
> Hello, can you please apply the same on autopkgtests? now autopkgtests 
> failures are considered RC buggy
> 
> something like this might work:
>...

Running tests is pointless when the only "fix" for failing tests is to 
disable tests until the build/autopkgtest succeeds.

Either the package or the test is broken on big endian.

Could an s390x porter (Cc added) please take a look?

Thanks
Adrian

Bug#962399: vmdb2 FTBFS: help2man: can't get `--help' info from vmdb2

[Adrian Bunk]

Source: vmdb2
Version: 0.16-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=vmdb2=all=0.16-1=1591514624=0

...
   debian/rules override_dh_installman
make[1]: Entering directory '/<>'
[ ! -e vmdb2.1 ]
help2man -N vmdb2 -i debian/vmdb2.1.in > debian/vmdb2.1
help2man: can't get `--help' info from vmdb2
Try `--no-discard-stderr' if option outputs to stderr
make[1]: *** [debian/rules:18: override_dh_installman] Error 127

Bug#956253: mu-editor 1.0.3 packaged (with bonus features)

[Nick Morrott]

On Tue, 26 May 2020 at 05:43, Keith Packard  wrote:
>
>
> I've got mu-editor version 1.0.3+dfsg packaged; the bits are all on
> salsa here:
>
> https://salsa.debian.org/keithp/mu-editor
>
> I'd like to get this into debian, mostly because I added support for the
> class I'm teaching using a smaller language (snek), along with a couple
> of other features I need for that. I've had those patches pending in
> upstream mu since last summer, but merging and other development appears
> to have stalled out there with no new features merged since about
> October.

Dear Keith and Ryan,

Thank you for sending this. I had also noticed that development
releases had slowed down significantly a while back.

There is a bug report asking for 1.1.alpha to be packaged [1], so I
think a sensible plan might be to get a mildly-patched 1.0.3 into
unstable and then consider uploading the current alpha into
experimental?

  [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956253

I wonder if there are there any other standalone commits post 1.0.3
that might also be worthwhile patching in? Let me look into this this
week.

Thanks,
Nick

Bug#962385: RFS: git-subrepo/0.4.1~2 [ITP] -- GIT Submodule alternative

[Samo Pogačnik]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "git-subrepo"

 * Package name: git-subrepo
   Version : 0.4.1~2
   Upstream Author : Ingy döt Net 
 * URL : https://github.com/ingydotnet/git-subrepo
 * License : MIT
 * Vcs : https://github.com/spog/git-subrepo-debian
   Section : vcs

It builds those binary packages:

  git-subrepo - GIT Submodule alternative

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

  https://mentors.debian.net/package/git-subrepo

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/git-subrepo/git-subrepo_0.4.1~2.dsc

Changes since the last upload:

   [ spog ]
   * Fixed reading installed subrepo command info.
   * Added subrepo to git completion commands
 .
   [ admorgan ]
   * Fix Bash version error messages and add to .rc
   * Nicer YAML formatting in .travis.yml
   * Wrap a long line
   * Update the docs
   * Force `make update` to always update docs
   * Don't use XXX in perl stuff
   * Add testing on MacOS
   * Remove conflicting -C from install -d commands.
   * Update version requirement documentation
   * Correct error message in branch
   * Use topo-order in subrepo branch
   * Make “git subrepo clean -f ...” delete refs correctly
   * Fix #410 Push empty repositories with recent git versions
   * Make subrepo work when run in a worktree
   * Simplify finding subrepos
   * Ask git to find the .gitrepo files
   * Doc: fix sentence repetition
   * Fix typos
   * Fixed typo
   * Travis CI not checking out a branch.

Regards,

--
  Samo Pogačnik

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Axel Beckert]

Hi,

Laura Arjona Reina wrote:
> I have compared the results of builds in stretch and buster both with
> and without the option, and there are no changes in stretch, and the
> UTF-8 issues are fixed in buster with the option

Thanks for these tests.

> So, I think that Bug#959474 can be closed, but I'll leave it open until
> we effectively migrate to Buster and see the results in www.debian.org
> "live" :-)

Just ot be sure: I should still provide a stable update for buster,
right?

(Sorry, was a bit busy IRL and nearly forgot about this open "to do"
item. So thanks for the reminder.)

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#962224: lightdm does not source ~/.profile

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Control: forcemerge 636108 -1

On Thu, 2020-06-04 at 19:27 +0100, Graeme Vetterlein wrote:
> Having switched to lightdm from GDM3 (due to another bug in gdm3) I now find
> ~/.profile does
> not run.
> 
> In order to debug this I created a clean user (new) called guest (pid=1001)
> I modified ~/.profile and ~/.bash_profile to log their use (see attached
> log)
> 
> In summary the behaviour was:
> 
> gdm3 + cinnamon = Runs ~/.profile only
> gdm3 + xfce = Runs ~/.profile only
> gdm3 + gnome3 = Runs ~/.profile only
> 
> Switch to lioghtdm & reboot system
> 
> lightdm + cinnamon = Runs neither
> lightdm + xfce = Runs neither
> lightdm + gnome = Runs neither
> lightdm + gnome(2nd version) = Runs neither
> 
> The doc @ https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/794315 poin
> ts
> to where this has been fixed in the past.

Hi Graeme,

this is a duplicate of #636108 so I'm merging the bugs. Note that .profile (et
al) are explicitely a configuration file of *bourne shells:

# /etc/profile: system-wide .profile file for the Bourne shell (sh(1))
# and Bourne compatible shells (bash(1), ksh(1), ash(1), ...).

lightdm is *definitely not* a bourne or bourne-compatible shell and thus 
doesn't source any profile file.

If you want to set something to the desktop environment, use ~/.xsessionrc.

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAl7c8eEACgkQ3rYcyPpX
RFtVkgf6A5m9CXSC6E9X6a3qhXrOazblQ7iqeKqVEqMZ+/kOtyAS53CNt0G7DyqZ
rY99OIdaWKZdoqahTF4fXCqBhlTf/XaBLeh55K3J+WPIatEPSebHD/hvwKaqvfFM
8yWoGpy1eMuWlcQSkAiZrnxgZomlEFNMLPlZQK1+4sZ8RJ0qvYdApgtb4dllfVaP
K++E0XqVhf8OjQNodF9SXdJ3vFlYzlBaKHZH76h+wZpIBpoEsRD05FYkxBmAYH/L
Dz3YcVGBcoCSTk+UgQfLFK6EurmzCMo4i+jlKC7jZm1dG7m91KJDWQv4BxHjjyqc
gwwt80voUnk3F2G8xHAPX3unzjkNdA==
=ZpEp
-END PGP SIGNATURE-

Bug#933128: libparse-debianchangelog-perl: Unsuitable for Bullseye unless someone becomes upstream

[Axel Beckert]

Hi,

intrigeri wrote:
> I did not dare proposing this course of action so far because the
> notes from our BoF at DebConf19 are a bit ambiguous about whether we
> decided to remove the package from sid, in addition to removing it
> from testing.

I wasn't at the BoF, but was opposing rather strongly afterwards since
I was not aware that libdpkg-dev is partially a fork and provides the
same functionality. (And I didn't want to loose the changelog parsing
functionality in aptitude.)

Since Guillem cleared up this and even provided a patch for aptitude
(which is applied and in testing for a week or two), I changed my
opinion on this topic completely.

> If another team member +1's the package removal, I'll happily proceed.

Seconded. :-)

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


signature.asc
Description: PGP signature

Bug#959474: Issues with Chinese language (all variants) when building some pages in buster

[Laura Arjona Reina]

Hi all

As a workaround for the Debian website, until wml 2.12.2~ds1-3 or higher
arrives to stable, I have added the option "-O1" to the options passed
to wml for Chinese, in the /chinese/Make.lang file:


+# Add "-O1"  to wml to be passed to htmlstrip, to avoid malformed UTF-8
+# see bug #959474
+# This option needs to be kept in Chinese until wml 2.12.2~ds1-3 or higher
+# arrives to Debian stable
+
+WMLOPTIONSZH = -O1

 WMLOUTPUT = -o UNDEFuZH@uCNuCNHKuCNTW:$(*F).zh-cn.html.tmp@g+w \
-o UNDEFuZH@uHKuCNHKuHKTWuTWHK:$(*F).zh-hk.html.tmp@g+w \
@@ -54,7 +60,7 @@ WMLPROLOG = --prolog=$(FORMAT_ZH)
 # Remove initial blank line due "[ZH::]" in $(TEMPLDIR)/common_tags.wml,
 # an unfortunate but necessary workaround of a bug in slice < 1.3.9
 WMLEPILOG = --epilog=$(STRIP_INITIAL_BLANK_LINE)
-WML = wml $(WMLOPTIONS) $(WMLOUTPUT) $(WMLPROLOG) $(WMLEPILOG)
+WML = wml $(WMLOPTIONS) $(WMLOPTIONSZH) $(WMLOUTPUT) $(WMLPROLOG)
$(WMLEPILOG)

I have compared the results of builds in stretch and buster both with
and without the option, and there are no changes in stretch, and the
UTF-8 issues are fixed in buster with the option (by the way, thanks
Boyuan for the additional fixes you did to mitigate the error).

So, I think that Bug#959474 can be closed, but I'll leave it open until
we effectively migrate to Buster and see the results in www.debian.org
"live" :-)

Thanks everybody for your work!

Kind regards,
-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#962398: ITP: ruby-protocol-http2 -- low level implementation of the HTTP/2 protocol

[Hideki Yamane]

Package: wnpp
Severity: wishlist
Owner: Hideki Yamane 

* Package name: ruby-protocol-http2
  Version : 0.14.0
  Upstream Author : Samuel G. D. Williams 
* URL : https://github.com/socketry/protocol-http2
* License : MIT
  Programming Lang: Ruby
  Description : low level implementation of the HTTP/2 protocol

 Protocol::HTTP2 provides a low-level implementation of the HTTP/2
 protocol.


 This ITP depends
 - ruby-protocol-http (#962374)
 - ruby-protocol-hpack (#962397)