Bug#898813: telegram-desktop: URI passed to the client via command line is ignored

[Alexander Kernozhitsky]

Package: telegram-desktop
Version: 1.2.17-1
Severity: normal

Dear Maintainer,

According to `man telegram-desktop` output:

telegram-desktop [-startintray] [-many] [-debug] [-- URI]

we can pass an URI to open a specified chat or a channel inside the application.
But it seems that the passed URI is ignored. I looked into the code and
noticed that it is parsed by the command line options parser, but is
used nowhere else in the code.

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

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

Versions of packages telegram-desktop depends on:
ii  libavcodec57  7:3.4.2-2+b1
ii  libavformat57 7:3.4.2-2+b1
ii  libavutil55   7:3.4.2-2+b1
ii  libc6 2.27-3
ii  libgcc1   1:8.1.0-1
ii  libglib2.0-0  2.56.1-2
ii  libminizip1   1.1-8+b1
ii  libopenal11:1.18.2-3
ii  libqt5core5a [qtbase-abi-5-10-0]  5.10.1+dfsg-6
ii  libqt5dbus5   5.10.1+dfsg-6
ii  libqt5gui55.10.1+dfsg-6
ii  libqt5network55.10.1+dfsg-6
ii  libqt5widgets55.10.1+dfsg-6
ii  libssl1.1 1.1.0h-2
ii  libstdc++68.1.0-1
ii  libswresample27:3.4.2-2+b1
ii  libswscale4   7:3.4.2-2+b1
ii  libtgvoip1.0.31.0.3-3
ii  libx11-6  2:1.6.5-1
ii  qt5-image-formats-plugins 5.10.1-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages telegram-desktop recommends:
ii  fonts-open-sans 1.11-1
ii  libappindicator3-1  0.4.92-5

telegram-desktop suggests no packages.

-- no debconf information

Bug#895741: plastimatch FTBFS with libdlib-dev 19.10-1

[Hugo Lefeuvre]

Hi Adrian,

Yes, it is most likely a bug in the dlib package. Last dlib updates made
Debian packaging considerably trickier by separating build of static
files and build of shared libraries. I have just noticed that we ship
the cmake config files of the shared build into the -dev package, which
might be the source of your problems. In fact, we should rather ship the
files produced by the static build (but still, I'm not 100% it's going to
be sufficient).

I have just prepared an upload addressing this issue, but I had
difficulties to build plastimatch with dlib 19.1 (configuration issues,
plastimatch seems to to use deprecated directives), so I couldn't really
test it.

You can find test packages here[0]. Can you try them ?

Regards,
 Hugo

[0] https://people.debian.org/~hle/testpkg/dlib/

-- 
 Hugo Lefeuvre (hle)|www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA


signature.asc
Description: PGP signature

Bug#898812: wine: Why is font divbyzero.patch still being applied to stable, testing and sid debian packages of wine.

[oiaohm]

Package: wine
Version: 3.0-1
Severity: normal

Dear Maintainer,

https://sources.debian.org/patches/wine/3.0-1/font-divbyzero.patch/

If you read the associated wine bug
https://bugs.winehq.org/show_bug.cgi?id=38762

The divide by zero issue was in fact fixed in freetype 2.6.2 .The
changing of the scale value to 1 end up not copying windows behavior
where face->size.height == 0 equals font not display.   So its not a
error to have face->size.height==0.

So this should be set min version of freetype greater than where the
patch was added and that is freetype 2.6.2 and this suitable  for
stable, testing and sid.

Thing to remember there are third party fonts out there with stupid
metrics so the correct place to address the font divide by zero
problem was always freetype.

I can see that min version of freetype has not been updated as libwine
is packages are still with libfreetype6 (>= 2.2.1) instead of
libfreetype6 (>= 2.6.2) as required to address this issue properly
without the patch.


Peter Dolding




-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine depends on:
ii  wine32  3.0-1+b1
ii  wine64  3.0-1+b1

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-4.3
pn  playonlinux  
pn  winbind  
pn  wine-binfmt  
pn  winetricks   

Versions of packages wine is related to:
ii  fonts-wine   3.0-1
ii  wine 3.0-1
ii  wine-development [wine]  3.7-1
ii  wine32   3.0-1+b1
ii  wine64   3.0-1+b1

-- debconf-show failed

Bug#898792: [Pkg-rust-maintainers] Bug#898792: rust-src: [RC] embedded copy of normalize.css

[Angus Lees]

severity 898792 normal
thanks

Downgrading severity, since I think we'd all agree that using a single CSS
file from one source rather than another does not render the entire Rust
toolchain as unusable or not suitable for release ;)
(and the Debian policy section cited is a "should" not "must" directive)

 - Gus

On Wed, 16 May 2018 at 06:54 Bastien ROUCARIÈS 
wrote:

> Package: rust-src
> Version: 1.24.1+dfsg1-1
> Severity: serious
> Justification: Policy 4.13
>
> This package include embedded copy of normalize.css
> /usr/src/rustc-1.24.1/src/librustdoc/html/static/normalize.css
>
> Please use the package libjs-normalize.css instead to use local copy
>
> Thanks
>
> Bastien___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
>
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
>

Bug#898778: hooks/btrfs fails

[Witold Baryluk]

Package: initramfs-tools
Followup-For: Bug #898778

Appears to be fixed in btrfs-progs 4.16.1-2

I got strange error from apt, but it is probably fine now:


...
Przetwarzanie wyzwalaczy pakietu initramfs-tools (0.130)...
update-initramfs: Generating /boot/initrd.img-4.16.0-1-amd64


...
W: APT had planned for dpkg to do more than it reported back (195 vs 199).
   Affected packages: initramfs-tools:amd64
$


# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-4.16.0-1-amd64
update-initramfs: Generating /boot/initrd.img-4.15.0-3-amd64
update-initramfs: Generating /boot/initrd.img-4.15.0-2-amd64
update-initramfs: Generating /boot/initrd.img-4.15.0-1-amd64
#


So, it appears to be a duplicate of #898719 and can be closed.

Bug#896847: libsynctex2: texworks/texmaker both segfaulting with libsynctex1/libsynctex2 installed

[Marc Jeffrey Driftmeyer]

They’re now fixed. I figured the lack of all packages built against libsynctex2 
was the problem.

- Marc

Marc Jeffrey Driftmeyer
Founder & CEO of Reanimality Studios LLC
Cell: (509) 435-5212
url: https://www.reanimastudios.com 
url: https://www.holoworlds.net 
email: m...@reanimality.com 
email: m...@holoworlds.net 





> On May 14, 2018, at 11:49 PM, Hilmar Preuße  wrote:
> 
> Am 25.04.2018 um 00:41 teilte Marc Jeffrey Driftmeyer mit:
> 
> Hi Marc,
> 
>> TeXworks segaults with a core dump. Texmaker outputs undefined
>> symbols and segfaults. Happened right after the latest TeXLive
>> restructure.
> This problem should be solved, now all packages (except gummi, but bug has a 
> patch) should be ported to libsynctex2. Please reconsider your bug report and 
> close it then.
> 
> hille@sid:~ $ apt-rdepends -r libsynctex1
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> libsynctex1
>  Reverse Depends: gummi (0.6.6-4)
> gummi
> 
> Hilmar
> -- 
> #206401 http://counter.li.org

Bug#898658: f-irc gets SEGV with TERM=xterm-256color

[Thomas Dickey]

On Tue, May 15, 2018 at 08:47:38PM +0200, Sven Joachim wrote:
> CC'ing ncurses maintainer, it looks like the library might be at fault
> here.
...
> So it seems that the ncurses library did not allocate enough memory to
> hold all the color pairs in sp->_color_pairs, resulting in the eventual
> heap buffer overflow.
> 
> That's how far I have tracked the issue, hopefully Thomas Dickey can
> investigate it further and even provide a fix.

I can reproduce this, will see...

-- 
Thomas E. Dickey 
https://invisible-island.net
ftp://ftp.invisible-island.net


signature.asc
Description: Digital signature

Bug#898398: Fails with "incompatible character encodings: ASCII-8BIT and UTF-8"

[Stéphane Glondu]

Le 16/05/2018 à 00:52, Francesco Poli a écrit :
 Since a few days, the cron.daily job of apt-listbugs fails with the 
 following message:

 /etc/cron.daily/apt-listbugs:
 /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:701:in `block (4 levels) in 
 display_bugs': incompatible character encodings: ASCII-8BIT and UTF-8 
 (Encoding::CompatibilityError)
>>>
>>> Hello Stéphane!
>>> Thanks for your bug report.
>>
>> It turns out the bug disappeared by itself...
> 
> Maybe the bug that had non-ASCII UTF-8 characters in the subject line
> was fixed or downgraded in the meanwhile?
> 
> You should be able to figure out which one, by digging
> in /var/backups/apt-listbugs.preferences*
> 
> Could you please take a look?

Yes. I think the culprit is this one:

> Explanation: Pinned by apt-listbugs at 2018-05-01 06:59:38 +0200
> Explanation:   #897018: texlive-latex-extra: \MakeAutoQuote{»}{«} does not 
> work any more
> Package: texlive-latex-extra
> Pin: version 2017.20180305-2
> Pin-Priority: 3

Cheers,

-- 
Stéphane

Bug#845297: converting translation metadata

[Steve McIntyre]

On Wed, May 16, 2018 at 01:37:25AM +0100, Steve McIntyre wrote:
>On Wed, May 16, 2018 at 12:05:17AM +0100, Steve McIntyre wrote:
>
>Initial script attached.

After some more discussion on irc with pabs, I've tweaked the script
to use file hashes instead of commit hashes. It's a little slower, but
perfectly usable (~90s runtime on my laptop). Here's the new version,
to allow for comparison.

We'll still need to update the rest of our tools, but step 1 looks OK
I think. Bedtime for now... :-)


-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer
#!/usr/bin/perl

# This script walks the webwml tree to look for translated files. It
# looks for the wml::debian::translation-check header to see if a file
# is a stranslation of an original, then checks for the revision
# status of the master document.
#
# Part of the effort to switch from CVS to Git
#
# Originally written 2018 by Steve McIntyre <93...@debian.org>
# © Copyright 2018 Software in the public interest, Inc.
# This program is released under the GNU General Public License, v2.

use strict;
use warnings;

use Getopt::Long;
use Data::Dumper;
use File::Spec::Functions;
use File::Find;
use lib ($0 =~ m|(.*)/|, $1 or ".") ."/Perl";
use Webwml::TransCheck;

my $help = 0;
my $verbose = 0;
my $dry_run = 0;
my $revs_file = "";
my %rev_map;

sub usage {
print <<'EOT';
Usage: switch_to_git_translations.pl [options]
Options:
  --help display this message
  --verbose  run verbosely
  --dry-run  do not modify translation-check headers
  --revisions=REVISIONS  location of the cvs2git revisions map file

Find all wml files under the current directory, updating revisions for
translations.
EOT
exit(0);
}

# log very verbose messages
sub vvlog {
if ($verbose >= 2) {
	print STDOUT $_[0] . "\n";
}
}

# log verbose messages
sub vlog {
if ($verbose >= 1) {
	print STDOUT $_[0] . "\n";
}
}

# Parse the revisions file for use, building a hash of the git and cvs versions for each file
sub parse_revisions
{
my $revs_file = shift;
open(IN, "<", "$revs_file") or die "Can't open revisions file \$revs_file\" for reading: $!\n";
while (my $line = ) {
	chomp $line;
	my ($file, $cvs_ver, $commit_hash);
	if ($line =~ m,^(\S+) ([.\d]+) ([[:xdigit:]]+)$,)
	{
	$file = $1;
	$cvs_ver = $2;
	$commit_hash = $3;
	$rev_map{"$file"}{"$cvs_ver"}{"commit_hash"} = $commit_hash;
	} else {
	die "Failed to parse revisions file at line $.\n";
	}
	vvlog("Found file $file with CVS version $cvs_ver in commit hash $commit_hash");
}
close IN;
vlog("Parsed revisions file \"$revs_file\", found revisions for " . scalar(keys %rev_map) . " files");
}

# return a list of filenames with the given extension
sub find_files_ext
{
my $dir = shift or die('Internal error: No dir specified');
my $ext = shift or die('Internal error: No ext specified');

my @files;
find( sub { if (-f and m/\.$ext$/) { my $filename = $File::Find::name; $filename =~ s,\.\/,,; push @files, $filename }}, $dir );
return @files;
}

# Update the translation-check metadata header in a wml file
sub update_wml_file_metadata
{
my $file = shift;
my $revision = shift;
my $hash = shift;
my $text = "";

open (IN, "< $file") or die "Can't open $file for reading: $!\n";
while () {
	if (m/^#use wml::debian::translation-check/) {
	s/(translation="?)($revision)("?)/$1$hash$3/;
	}
	$text .= $_;
}
close(IN);
open(OUT, "> $file") or die "Can't open $file for writing: $!\n";
print OUT $text;
close OUT;
}

# Parse a wml file, and see if there's a translation-check header. If
# so, use the rev_map data to switch the translation information from
# the cvs version to the git hash *if available*. If it's not
# available, report an error.
sub parse_wml_file
{
my $file = shift;
my $info = 0; # Do we have any translation header info at all?
my $tc = Webwml::TransCheck->new("$file") or die "Failed transcheck: $!\n";
vlog("Looking at wml file $file");
my $target_lang = "english";
my $maint = $tc->maintainer();
if (defined($maint)) {
	vvlog("  Maintainer: $maint");
	$info += 1;
}
my $revision = $tc->revision();
if (defined($revision)) {
	vvlog("  Revision: $revision");
	$info += 1;
}
my $original = $tc->original();
if (defined($original)) {
	vvlog("  Original: $original");
	$info += 1;
	$target_lang = $original;
}
my $mindelta = $tc->mindelta();
if (defined($mindelta)) {
	vvlog("  Mindelta: $mindelta");
	$info += 1;
}
my $maxdelta = $tc->maxdelta();
if (defined($maxdelta)) {
	vvlog("  Maxdelta: $maxdelta");
	$info += 1;
}
  

Bug#895812: RFS: json-editor.js/0.7.28+ds-1 [ITP]

[Michael Lustfield]

I'm currently out of the country for a couple weeks and have no access to a
computer or my key.

At a cursory glance, I see no issues. When I return, if not uploaded, I'll
plan to do so.

Thanks for your efforts!

On Wed, May 16, 2018, 00:42 Joel Cross  wrote:

> Dear reviewers,
>
> I have uploaded a new version of json-editor.js, which addresses many of
> Paolo's concerns. It can be downloaded from
> https://mentors.debian.net/package/json-editor.js, and the git repository
> is available at https://salsa.debian.org/joelcross-guest/json-editor.js.
>
> -
> Joel Cross
>

Bug#898811: RFS: pygithub/1.40a3-1 [ITP]

[eamanu15]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name: pygithub
   Version : 1.40a3-1
   Upstream Author : Author : Adam Dangoor 
   Vincent Jacques <
vinc...@vincent-jacques.net>
Jeremy Phelps <
jphe...@linuxfoundation.org>
* URL : https://pypi.python.org/pypi/PyGithub
* License : LGPL-3+
  Section : python

 It builds those binary packages:

python-github - Access to full Github API v3 from Python2
python3-github - Access the full Github API v3 from Python3

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

https://mentors.debian.net/package/pygithub
or https://salsa.debian.org/python-team/modules/pygithub

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

dget -x
https://mentors.debian.net/debian/pool/main/p/pygithub/pygithub_1.40a3-1.dsc
or
git clone g...@salsa.debian.org:python-team/modules/pygithub.git

More information about pygithub can be obtained from
http://pygithub.readthedocs.io/

Changes since the last upload:
  * New upstream release
  * Update Standards-Version from 4.1.3 to 4.1.4 version
  * Add Uploaders field from debian/control to intent to adopt the
 package (Closes: #851187)


Regards,
Emmanuel Arias
-- 
Arias Emmanuel
https://www.linkedin.com/in/emmanuel-arias-437a6a8a
http://eamanu.com

Bug#898810: wine: revert_opengl46.patch applied to wine why no upstream bug.

[oiaohm]

Package: wine
Version: 3.0-1
Severity: normal

Dear Maintainer,

I was looking over patches that are being added to wine.

I stumbled on the
https://sources.debian.org/patches/wine/3.0-1/revert_opengl46.patch/ and when I
look at it is in the fact of not right.

Is this caused because you are not using the current khronos files
https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/gl.xml
https://raw.github.com/KhronosGroup/OpenGL-Registry/master/xml/wgl.xml

If so work out how to use current kronous files.  Maybe make this
/usr/share/khronos-api directory versioned.   Why is wine project downloading
the kronous files directly is so when users update their opengl to newer
versions old builds of wine stand a chance of working and taking advantage of
newer features.

There is a possiblity that the opengl46 patch is wrong to start off with.
{"GL_EXT_texture_filter_anisotropic",   ARB_TEXTURE_FILTER_ANISOTROPIC}
This line in the patch makes me smell a possible issue that someone might have
done a straight find and replace incorrectly.   If that is the case
EXT_TEXTURE_FILTER_ANISOTROPIC and  ARB_TEXTURE_FILTER_ANISOTROPIC handling
need to be implemented next to each other.   As in try
ARB_TEXTURE_FILTER_ANISOTROPIC if that don't exist try
EXT_TEXTURE_FILTER_ANISOTROPIC and after that fail.  If this is the case there
need to be a wine bug opened and a patch submitted upstream.

Please note I do serousally think this is a bug in wine source code.  From the
gl.xml file from kronous
extension name="GL_ARB_texture_filter_anisotropic" supported="gl|glcore"
extension name="GL_EXT_texture_filter_anisotropic" supported="gl|gles1|gles2"

Note the supported.   Running on android with glex1 or gles2 not seeing
ARB_TEXTURE_FILTER_ANISOTROPIC and only seeing EXT_TEXTURE_FILTER_ANISOTROPIC
would be normal.   Please remember wine is adding android support so has to
support gles1 and gles2 as you even get new android devices today missing
Opengl ES 3.0

If what I suspect is the case and not caused somehow by what you have done with
the khronos files please open upstream bug report in wine.

Peter Dolding




-- Package-specific info:
/usr/bin/wine points to /usr/bin/wine-development.

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

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

Versions of packages wine depends on:
ii  wine32  3.0-1+b1
ii  wine64  3.0-1+b1

wine recommends no packages.

Versions of packages wine suggests:
ii  dosbox   0.74-4.3
pn  playonlinux  
pn  winbind  
pn  wine-binfmt  
pn  winetricks   

Versions of packages wine is related to:
ii  fonts-wine   3.0-1
ii  wine 3.0-1
ii  wine-development [wine]  3.7-1
ii  wine32   3.0-1+b1
ii  wine64   3.0-1+b1

-- debconf-show failed

Bug#845297: converting translation metadata

[Steve McIntyre]

On Wed, May 16, 2018 at 12:05:17AM +0100, Steve McIntyre wrote:
>I'm writing a script switch_to_git_translations.pl to walk through all
>the wml files and switch from cvs revision numbers to git revision
>numbers. I'm doing consistency checks as I slowly develop the
>script, for the sake of paranoia :-).
>
>I've found that there are some files that appear to have broken
>translation-check metadata. I've mentioned some in IRC, but for
>completeness we have a few more listed here.
>
>Laura and Thomas have already fixed some of these (as tagged
>here). I'm about to fix the rest myself and push the fixes.

These are all fixed now, thanks Thomas!

OK, so one more thing. In the wiki page about this area:

  "Note that there can be multiple levels of translation-check headers
   chaining through different files, for example:"

Thinking about this, that's actually irrelevant to this work. I *can*
track through a chain of dependencies here (tedious, but possible -
may potentially involve checking out different versions of files from
git), but I really don't think we need to at all. Feel free to try and
convince me otherwise!

Initial script attached.

Checking the git diff output after running the script without
--dry-run (i.e. making changes), I can see a few more files which I
think look bogus for their translation-check metadata. They've all got
multiple translation-check lines in the header, with (maybe?)
conflicting data:

tack:~/debian/www/test_webwml_cvs2git$ git diff --stat | grep -v 2
 french/consultants/xpile.wml  |   4 ++--
 japanese/international/Vietnamese.wml |   4 ++--
 russian/consultants/xpile.wml |   4 ++--
 russian/international/Croatian/index.wml  |   4 ++--
 russian/legal/anssi.wml   |   4 ++--
 43566 files changed, 43578 insertions(+), 43578 deletions(-)

For the sake of 5 files, I'm tempted to (again) just fix up the
metadata in CVS to remove any amiguity here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Who needs computer imagery when you've got Brian Blessed?
#!/usr/bin/perl

# This script walks the webwml tree to look for translated files. It
# looks for the wml::debian::translation-check header to see if a file
# is a stranslation of an original, then checks for the revision
# status of the master document.
#
# Part of the effort to switch from CVS to Git
#
# Originally written 2018 by Steve McIntyre <93...@debian.org>
# © Copyright 2018 Software in the public interest, Inc.
# This program is released under the GNU General Public License, v2.

use strict;
use warnings;

use Getopt::Long;
use Data::Dumper;
use File::Spec::Functions;
use File::Find;
use lib ($0 =~ m|(.*)/|, $1 or ".") ."/Perl";
use Webwml::TransCheck;

my $help = 0;
my $verbose = 0;
my $dry_run = 0;
my $revs_file = "";
my %rev_map;

sub usage {
print <<'EOT';
Usage: switch_to_git_translations.pl [options]
Options:
  --help display this message
  --verbose  run verbosely
  --dry-run  do not modify translation-check headers
  --revisions=REVISIONS  location of the cvs2git revisions map file

Find all wml files under the current directory, updating revisions for
translations.
EOT
exit(0);
}

# log very verbose messages
sub vvlog {
if ($verbose >= 2) {
	print STDOUT $_[0] . "\n";
}
}

# log verbose messages
sub vlog {
if ($verbose >= 1) {
	print STDOUT $_[0] . "\n";
}
}

# Parse the revisions file for use, building a hash of the git and cvs versions for each file
sub parse_revisions
{
my $revs_file = shift;
open(IN, "<", "$revs_file") or die "Can't open revisions file \$revs_file\" for reading: $!\n";
while (my $line = ) {
	chomp $line;
	my ($file, $cvs_ver, $git_hash);
	if ($line =~ m,^(\S+) ([.\d]+) ([[:xdigit:]]+)$,)
	{
	$file = $1;
	$cvs_ver = $2;
	$git_hash = $3;
	$rev_map{"$file"}{"$cvs_ver"}{"git_hash"} = $git_hash;
#	$rev_map{"$file"}{"$git_hash"}{"cvs_ver"} = $cvs_ver;
	} else {
	die "Failed to parse revisions file at line $.\n";
	}
	vvlog("Found file $file with CVS version $cvs_ver in git hash $git_hash");
}
close IN;
vlog("Parsed revisions file \"$revs_file\", found revisions for " . scalar(keys %rev_map) . " files");
}

# return a list of filenames with the given extension
sub find_files_ext
{
my $dir = shift or die('Internal error: No dir specified');
my $ext = shift or die('Internal error: No ext specified');

my @files;
find( sub { if (-f and m/\.$ext$/) { my $filename = $File::Find::name; $filename =~ s,\.\/,,; push @files, $filename }}, $dir );
return @files;
}

# Update the translation-check metadata header in a wml file
sub update_wml_file_metadata
{
my $file = shift;
my $revision = shift;
my $hash = shift;
my $text = "";

open (IN, "< $file") or die "Can't open $file for reading: $!\n";
while () {
	if (m/^#use 

Bug#898738: debootstrap fails when specifying components

[Hideki Yamane]

Hi,

 Sorry, and thank you for digging it.

On Tue, 15 May 2018 21:44:38 +0200
Cyril Brulebois  wrote:
> I think I've found the issue. At least partly reverting the commit
> makes retrieving/validating indices work again, possibly because
> un-local-izing names was a bad idea? (I took all hunks from the commit
> that touched the download_release_indices function. Not everything is
> needed I guess.)
> 
> See attached patch, against the offending commit. It doesn't apply to
> master as-is because of the by-hash addition.

 Simply initialize "ext" prevents this failure, could you check attached
 patch, please?


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From 768183053bcd02f050fcd2d50c08024ff48a786f Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Wed, 16 May 2018 08:55:23 +0900
Subject: [PATCH] Fix download failure when specifying multiple components
 (Closes: #898738)

> # debootstrap --components=main,contrib,non-free unstable unstable http://deb.debian.org/debian
(snip)
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
(snip)

Fix above by initializing "ext" for each component
---
 functions | 1 +
 1 file changed, 1 insertion(+)

diff --git a/functions b/functions
index fa7c060..74d25b3 100644
--- a/functions
+++ b/functions
@@ -681,6 +681,7 @@ download_release_indices () {
 		bz2i="$(get_release_checksum "$reldest" "$subpath.bz2")"
 		gzi="$(get_release_checksum "$reldest" "$subpath.gz")"
 		normi="$(get_release_checksum "$reldest" "$subpath")"
+		ext=""
 		if [ "$acquirebyhash" != "" ]; then
 			ext="$ext byhash"
 		fi
-- 
2.17.0

Bug#898809: lintian -F internal error: cannot run shared-libs check on package binary

[Matthias Klose]

Package: lintian
Version: 2.5.86
Severity: important
Tags: sid buster

This causes the gcc-8-cross packages built on amd64 and i386 failing the lintian
-F check during upload (packages at p.d.o/~d.../tmp).

$ lintian -F ../gcc-8-cross_16_amd64.changes 2>&1 | tee ../log.lintian
Use of uninitialized value $lib in pattern match (m//) at
/usr/share/lintian/checks/files.pm line 339.
Use of uninitialized value $val in split at
/usr/share/perl5/Lintian/Collect/Binary.pm line 423, <$_[...]> line 22776.
Use of uninitialized value $val in split at
/usr/share/perl5/Lintian/Collect/Binary.pm line 423, <$_[...]> line 22776.
internal error: shlib usr/lib/gcc-cross/arm-linux-gnueabi/8/libgo.a(log.o) not
found in package (should not happen!) at
/usr/share/lintian/checks/shared-libs.pm line 198.
internal error: cannot run shared-libs check on package
binary:gccgo-8-arm-linux-gnueabi/8.1.0-3cross2/amd64
warning: skipping check of binary:gccgo-8-arm-linux-gnueabi/8.1.0-3cross2/amd64

Bug#898808: linux-image-4.16.0-0.bpo.1-amd64: Wrong 40Hz screen refresh rate at 1366x768, introduced after kernek 4.13

[Eduardo GV]

Package: src:linux
Version: 4.16.5-1~bpo9+1
Severity: important

Dear Maintainer,

   * What led up to the situation?
Too low screen refresh rate lead to not smooth movement in HD videos at 60 fps
Then glxgears shows that refresh rate is 40 Hz instead of 60 Hz
There is no way to get 60 Hz back with this kernel.
This was introduced AFTER kernel 4.13

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I tried to get the correct refresh rate of 60 Hz at 1366x768 with xrandr and 
others. It is ineffective.

   * What was the outcome of this action?
The screen refresh rate is stuck at 40 Hz

   * What outcome did you expect instead?
I expected to have the correct refresh rate of 60 Hz, necessary for smooth 
video.
This can only be achieved by booting with kernel 4.13 or older.

*** End of the template - remove these template lines ***


-- Package-specific info:
** Version:
Linux version 4.16.0-0.bpo.1-amd64 (debian-ker...@lists.debian.org) (gcc 
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.16.5-1~bpo9+1 
(2018-05-06)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.16.0-0.bpo.1-amd64 
root=UUID=37d26fee-2d22-44c1-987d-52285adf8a8b ro

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Model information
sys_vendor: HP
product_name: HP Laptop 15-bs0xx
product_version: Type1ProductConfigId
chassis_vendor: HP
chassis_version: Chassis Version
bios_vendor: Insyde
bios_version: F.24
board_vendor: HP
board_name: 832A
board_version: 23.40

** Loaded modules:
vboxpci(O)
vboxnetadp(O)
vboxnetflt(O)
vboxdrv(O)
msr
pci_stub
cpufreq_conservative
cpufreq_userspace
cpufreq_powersave
cmac
bnep
binfmt_misc
nls_ascii
nls_cp437
vfat
fat
uvcvideo
videobuf2_vmalloc
videobuf2_memops
videobuf2_v4l2
videobuf2_common
videodev
intel_rapl
btusb
media
hid_multitouch
btrtl
x86_pkg_temp_thermal
intel_powerclamp
btbcm
btintel
coretemp
bluetooth
kvm_intel
drbg
kvm
snd_hda_codec_hdmi
snd_hda_codec_realtek
snd_hda_codec_generic
arc4
ansi_cprng
hp_wmi
wmi_bmof
iwlmvm
mac80211
snd_soc_skl
snd_soc_skl_ipc
snd_hda_ext_core
ecdh_generic
snd_soc_sst_dsp
irqbypass
snd_soc_sst_ipc
snd_soc_acpi
snd_soc_core
iwlwifi
snd_compress
crct10dif_pclmul
cfg80211
snd_hda_intel
crc32_pclmul
ghash_clmulni_intel
rfkill
tpm_crb
intel_cstate
snd_hda_codec
tpm_tis
i915
intel_uncore
tpm_tis_core
efi_pstore
evdev
intel_rapl_perf
tpm
drm_kms_helper
snd_hda_core
snd_hwdep
snd_pcm
snd_timer
snd
processor_thermal_device
mei_me
drm
rng_core
joydev
pcspkr
shpchp
iTCO_wdt
serio_raw
efivars
iTCO_vendor_support
video
int340x_thermal_zone
kxcjk_1013
wmi
industrialio_triggered_buffer
kfifo_buf
intel_vbtn
soundcore
industrialio
mei
sparse_keymap
battery
ac
i2c_algo_bit
int3400_thermal
acpi_thermal_rel
button
hp_wireless
intel_soc_dts_iosf
intel_pch_thermal
acpi_pad
sg
parport_pc
ppdev
lp
parport
efivarfs
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
hid_generic
usbhid
hid
sr_mod
cdrom
sd_mod
crc32c_intel
aesni_intel
ahci
aes_x86_64
libahci
crypto_simd
cryptd
glue_helper
xhci_pci
libata
xhci_hcd
scsi_mod
psmouse
r8169
i2c_i801
usbcore
mii
usb_common
fan
thermal

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Device [8086:5904] (rev 02)
Subsystem: Hewlett-Packard Company Device [103c:832a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:5916] 
(rev 02) (prog-if 00 [VGA controller])
Subsystem: Hewlett-Packard Company Device [103c:832a]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:04.0 Signal processing controller [1180]: Intel Corporation Skylake 
Processor Thermal Subsystem [8086:1903] (rev 02)
Subsystem: Hewlett-Packard Company Skylake Processor Thermal Subsystem 
[103c:832a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: proc_thermal
Kernel modules: processor_thermal_device

00:08.0 System peripheral [0880]: Intel Corporation Skylake Gaussian Mixture 
Model [8086:1911]
Subsystem: Hewlett-Packard Company Skylake Gaussian Mixture Model 
[103c:832a]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI 
Controller [8086:9d2f] (rev 21) (prog-if 30 [XHCI])
Subsystem: Hewlett-Packard Company Sunrise Point-LP USB 3.0 xHCI 
Controller 

Bug#845297: bugs in translation metadata

[Steve McIntyre]

I'm writing a script switch_to_git_translations.pl to walk through all
the wml files and switch from cvs revision numbers to git revision
numbers. I'm doing consistency checks as I slowly develop the
script, for the sake of paranoia :-).

I've found that there are some files that appear to have broken
translation-check metadata. I've mentioned some in IRC, but for
completeness we have a few more listed here.

Laura and Thomas have already fixed some of these (as tagged
here). I'm about to fix the rest myself and push the fixes.

french/users/com/portantier.wml has a broken translation-check header   - FIXED 
IN CVS

Looking at wml file vietnamese/security/2015/dsa-3284.wml
  Looking up english/security/2015/dsa-3284.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3280.wml
  Looking up english/security/2015/dsa-3280.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3288.wml
  Looking up english/security/2015/dsa-3288.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3282.wml
  Looking up english/security/2015/dsa-3282.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3276.wml
  Looking up english/security/2015/dsa-3276.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3283.wml
  Looking up english/security/2015/dsa-3283.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3278.wml
  Looking up english/security/2015/dsa-3278.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3289.wml
  Looking up english/security/2015/dsa-3289.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3277.wml
  Looking up english/security/2015/dsa-3277.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3279.wml
  Looking up english/security/2015/dsa-3279.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3285.wml
  Looking up english/security/2015/dsa-3285.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/security/2015/dsa-3275.wml
  Looking up english/security/2015/dsa-3275.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/News/2015/20150606.wml
  Looking up english/News/2015/20150606.wml with cvs rev 1.2
  No mapping found
Looking at wml file vietnamese/News/weekly/index.wml
  Looking up english/News/weekly/index.wml with cvs rev 1.37
  No mapping found
Looking at wml file french/News/weekly/2017/04/index.wml
  Looking up english/News/weekly/2017/04/index.wml with cvs rev 1.4 maintainer=
  No mapping found   - FIXED IN CVS
Looking at wml file french/News/weekly/2018/01/index.wml
  Looking up english/News/weekly/2018/01/index.wml with cvs rev 1.5 maintainer=
  No mapping found   - FIXED IN CVS
Looking at wml file italian/News/weekly/2015/06/index.wml
  Looking up english/News/weekly/2015/06/index.wml with cvs rev 1.4
  No mapping found

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"This dress doesn't reverse." -- Alden Spiess

Bug#898398: Fails with "incompatible character encodings: ASCII-8BIT and UTF-8"

[Francesco Poli]

On Tue, 15 May 2018 12:56:48 +0200 Stéphane Glondu wrote:

> On 11/05/2018 19:12, Francesco Poli wrote:
> >> Since a few days, the cron.daily job of apt-listbugs fails with the 
> >> following message:
> >>
> >> /etc/cron.daily/apt-listbugs:
> >> /usr/lib/ruby/vendor_ruby/aptlistbugs/logic.rb:701:in `block (4 levels) in 
> >> display_bugs': incompatible character encodings: ASCII-8BIT and UTF-8 
> >> (Encoding::CompatibilityError)
> > 
> > Hello Stéphane!
> > Thanks for your bug report.
> 
> It turns out the bug disappeared by itself...

Maybe the bug that had non-ASCII UTF-8 characters in the subject line
was fixed or downgraded in the meanwhile?

You should be able to figure out which one, by digging
in /var/backups/apt-listbugs.preferences*

Could you please take a look?

> 
> > Could you please paste the content of file
> > /etc/apt/preferences.d/apt-listbugs ?
> 
> Currently, it is:
> 
[...]
> > It seems to me that the issue you are experiencing is the same
> > as #749193, but I would like to check that this is actually the case.
> > 
> > Please let me know.
> 
> It looks like it.

Thanks for confirming.
I will later reassign and merge...



-- 
 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


pgp8yzKNICNNy.pgp
Description: PGP signature

Bug#898201: fix?

[Julien]

Hi,

This upstream patch should fix this issue : 
https://git.kernel.org/pub/scm/bluetooth/bluez.git/commit/?id=37a30b5435a45c3f8e233309fc70fc7de92b2e76

Bug#898799: lintian: False positive for debhelper-compat-file-contains-multiple-levels

[Axel Beckert]

Hi,

to be more precise:

Axel Beckert wrote:
> The following IMHO fully valid and not accidentially with ">>" appended
> debian/compat file of debsums [...]

... as currently in git:
https://salsa.debian.org/perl-team/modules/packages/debsums/blob/master/debian/compat

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#898795: firefox-esr: [RC] embedded copy of normalize.css

[Mike Hommey]

On Tue, May 15, 2018 at 10:56:51PM +0200, Bastien ROUCARIÈS wrote:
> Package: firefox-esr
> Severity: serious
> Justification: Policy 4.13
> 
> This package include embedded copy of normalize.css
> browser/base/content/aboutaccounts/normalize.css
> (aka about:accounts)
> 
> 
> Please use the package libjs-normalize.css instead to use local copy

That package doesn't exist.
https://packages.debian.org/search?keywords=libjs-normalize.css

Mike

Bug#898807: nova: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: nova
Version: 2:17.0.0-4
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|==
|FAIL: 
nova.tests.unit.virt.xenapi.test_xenapi.XenAPIDiffieHellmanTestCase.test_encrypt_newlines_inside_message
|nova.tests.unit.virt.xenapi.test_xenapi.XenAPIDiffieHellmanTestCase.test_encrypt_newlines_inside_message
|--
|_StringException: pythonlogging:'': {{{2018-05-01 20:48:09,960 WARNING 
[oslo_config.cfg] Config option key_manager.api_class  is deprecated. Use 
option key_manager.backend instead.}}}
|
|Traceback (most recent call last):
|  File "/<>/nova/tests/unit/virt/xenapi/test_xenapi.py", line 
1592, in test_encrypt_newlines_inside_message
|self._test_encryption('Message\nwith\ninterior\nnewlines.')
|  File "/<>/nova/tests/unit/virt/xenapi/test_xenapi.py", line 
1577, in _test_encryption
|enc = self.alice.encrypt(message)
|  File "/<>/nova/virt/xenapi/agent.py", line 432, in encrypt
|return self._run_ssl(text).strip('\n')
|  File "/<>/nova/virt/xenapi/agent.py", line 428, in _run_ssl
|raise RuntimeError(_('OpenSSL error: %s') % err)
|RuntimeError: OpenSSL error: *** WARNING : deprecated key derivation used.
|Using -iter or -pbkdf2 would be better.

seems to be due to an additional message on stderr.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nova_17.0.0-4_amd64-2018-05-01T20%3A39%3A38Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nova_17.0.0-4_amd64-2018-05-02T18%3A46%3A36Z

Sebastian

Bug#898806: libicu-dev: circular dependency hell

[Bill Allombert]

Package: libicu-dev
Version: 60.2-6
Severity: important

Hello Laszlo,

There is a circular dependency between libicu-dev, libharfbuzz-dev, 
libicu-le-hb-dev, 
and between libicu-le-hb0 and libicu60:

libicu-dev  :Depends: libicu60 (= 60.2-6), libicu-le-hb-dev
libharfbuzz-dev :Depends: libicu-dev
libicu-le-hb-dev:Depends: libicu-le-hb0 (= 1.0.3+git161113-5), 
libharfbuzz-dev

libicu-le-hb0   :Depends: libicu60 (>= 60.1-1~)
libicu60:Depends: libicu-le-hb0

Complex circular dependencies are known to cause problems during upgrade, so we
should try to avoid them.

See threads 
http://lists.debian.org/debian-devel/2005/06/msg02111.html
http://lists.debian.org/debian-devel/2005/11/msg01101.html

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#869194: awscli failing to upload empty files on => due to python-s3transfer

[Joseph Herlant]

Control: reassign -1 python-s3transfer
Control: forwarded -1 https://github.com/boto/s3transfer/pull/102

Reassigning this bug to python-s3transfer as it is the one that will
be patch to support the missing argument.

Upstream issues:
https://github.com/aws/aws-cli/issues/2403#issuecomment-389325158

Bug report in Ubuntu:
https://bugs.launchpad.net/ubuntu/+source/python-s3transfer/+bug/1696800

There are actually 2 upstream patches, the 2nd one superseeding the
1st: https://github.com/boto/s3transfer/pull/88 and
https://github.com/boto/s3transfer/pull/102

Joseph

Bug#898448: reopening 898448

[Josh Triplett]

reopen 898448
thanks

I can still reproduce this segfault with the patched libfreerdp2-2 in
current unstable.

Bug#898805: nodejs: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: nodejs
Version: 8.11.1~dfsg-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

The Error
|Error: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/nodejs_8.11.1~dfsg-2_amd64-2018-05-01T20%3A40%3A21Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/nodejs_8.11.1~dfsg-2_amd64-2018-05-02T18%3A46%3A33Z

Sebastian

Bug#898804: myproxy: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: myproxy
Version: 6.1.28-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

|The Error
|Problem with server credentials. GSS Major Status: General failure GSS Minor 
Status Error Chain: globus_gsi_gssapi: Error with GSI credential 
globus_gsi_gssapi: Error with gss credential handle globus_gsi_gssapi: Error 
with openssl: Couldn't set the certificate to be used for the SSL context 
OpenSSL Error: ../ssl/ssl_rsa.c:310: in library: SSL routines, function 
SSL_CTX_use_certificate: ca md too weak  
|FAIL myproxy-test-wrapper (exit status: 1)

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/myproxy_6.1.28-2_amd64-2018-05-01T20%3A28%3A31Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/myproxy_6.1.28-2_amd64-2018-05-02T18%3A46%3A02Z

Sebastian

Bug#898803: globus-gssapi-gsi: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gssapi-gsi
Version: 13.5-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

I suspect the failure due to a too small key in the testsuite
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gssapi-gsi_13.5-1_amd64-2018-05-01T20%3A05%3A40Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gssapi-gsi_13.5-1_amd64-2018-05-02T18%3A43%3A41Z

Sebastian

Bug#898802: globus-gram-job-manager: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gram-job-manager
Version: 14.36-2
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?

I suspect a too small key in the testsuite 1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gram-job-manager_14.36-2_amd64-2018-05-01T20%3A03%3A44Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gram-job-manager_14.36-2_amd64-2018-05-02T18%3A43%3A40Z

Sebastian

Bug#898801: globus-gass-copy: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: globus-gass-copy
Version: 9.28-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
Could you please have a look?
The Error 
|# 530-OpenSSL Error: ../ssl/ssl_rsa.c:310: in library: SSL routines, function 
SSL_CTX_use_certificate: ee key too small

is due to:
1.1.1~~pre6-1 changelog):
|   * Increase default security level from 1 to 2. This moves from the 80 bit
| security level to the 112 bit securit level and will require 2048 bit RSA
| and DHE keys.

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/globus-gass-copy_9.28-1_amd64-2018-05-01T20%3A03%3A39Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/globus-gass-copy_9.28-1_amd64-2018-05-02T18%3A43%3A39Z

Sebastian

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Mario Frasca]

> planning to update it to
> support Python 3.x in preparation for 2.7 reaching end of life?
btw, since my two adopted children `bauble` and `ghini` both depend on
`fibra`, and python is reaching end of life for them too, I'm afraid I
will port `fibra` to python3 anyway, that it is accepted into Debian or not.
I'm already reconstructing its history, and will publish it in github as
soon as I'm done.
M

Bug#898800: foolscap: FTBFS against openssl 1.1.1

[Sebastian Andrzej Siewior]

Source: foolscap
Version: 0.13.1-1
Severity: important
User: pkg-openssl-de...@lists.alioth.debian.org
Usertags: openssl-1.1.1

The new openssl 1.1.1 is currently in experimental [0]. This package
failed to build against this new package [1] while it built fine against
the openssl version currently in unstable [2].
There was a discussion about this on openssl's issue tracker [3], [4].

[0] https://lists.debian.org/msgid-search/20180501211400.ga21...@roeckx.be
[1] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/attempted/foolscap_0.13.1-1_amd64-2018-05-02T00%3A10%3A30Z
[2] 
https://breakpoint.cc/openssl-rebuild/2018-05-03-rebuild-openssl1.1.1-pre6/successful/foolscap_0.13.1-1_amd64-2018-05-02T18%3A43%3A34Z
[3] https://github.com/openssl/openssl/issues/6228
[4] https://github.com/openssl/openssl/issues/6234

Sebastian

Bug#898799: lintian: False positive for debhelper-compat-file-contains-multiple-levels

[Axel Beckert]

Package: lintian
Version: 2.5.86
Severity: normal

The following IMHO fully valid and not accidentially with ">>" appended
debian/compat file of debsums triggers the lintian tag
debhelper-compat-file-contains-multiple-levels:

---8<--
10
# Needs to stay on a compat level which is supported in stable,
# i.e. 10 for stretch (and probably 11 for buster)
--->8---

IMO this lintian warning should only be triggered, if each line only
contains numbers and especially does not begin with hash marks as
commonly used for comments.

Currently debhelper only looks at the first line of the debian/compat
file and hence ignores anything behind (which probably also caused this
tag to be implemented), but the tag should be only emitted if those
lines are obviously created by using ">>" instead of ">", not with
arbitrary content.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), 
(111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), 
(105, 'experimental-debug')
Architecture: amd64 (x86_64)

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

Versions of packages lintian depends on:
ii  binutils  2.30-19
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.5+b1
ii  file  1:5.33-2
ii  gettext   0.19.8.1-6+b1
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.34
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdigest-sha-perl6.02-1
ii  libdpkg-perl  1.19.0.5
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.08-1
ii  libipc-run-perl   0.99-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.26 [libdigest-sha-perl]  5.26.2-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.74-1
ii  libxml-simple-perl2.25-1
ii  libyaml-libyaml-perl  0.69+repack-1
ii  man-db2.8.3-2
ii  patchutils0.3.4-2
ii  perl  5.26.2-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

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

Versions of packages lintian suggests:
ii  binutils-multiarch 2.30-19
ii  dpkg-dev   1.19.0.5
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.53-1

-- no debconf information

Bug#898672: iodine: iodine-client-start reports local address in seconds, e.g. as "7128sec"

[gregor herrmann]

On Tue, 15 May 2018 18:00:42 +0200, gregor herrmann wrote:

> On Tue, 15 May 2018 16:51:30 +0100, Barak A. Pearlmutter wrote:
> > Okay, I pushed another fix to avoid all use of ifconfig and instead use ip.
> > Please let me know if it's okay.
> Thanks, works perfectly for me.
> 
> Axel, maybe you could try https://github.com/barak/iodine-client-start
> as and check if there are any problems in your setup.

After a short private mail exchange with Axel I've now uploaded
iodine as is, we can discuss the other mentioned issue or any other
problems in a new bug report while this bug is fixed by the upload.

Thanks again to both of you.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Leonard Cohen: A Thousand Kisses Deep


signature.asc
Description: Digital Signature

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Mario Frasca]

I don't see any inconvenience with this what you suggest.
I can import the library (with, if necessary, its history) into a new
github project.
I already patched upstream so it can be loaded in python3.

Bug#898798: [twitter-bootstrap3] uscan is broken

[Bastien ROUCARIÈS]

Package: twitter-bootstrap3
Severity: important
 
uscan is broken so we do not know that your package is not up to date;

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

Bug#898235: [patch] required dependencies needed to build btrfs-progs-4.16.1

[Nicholas D Steeves]

Control: fixed -1 btrfs-progs/4.16.1-1

On Sat, May 12, 2018 at 10:06:48AM +0100, Dimitri John Ledkov wrote:
> Hi,
> 
> On 9 May 2018 at 02:15, Nicholas D Steeves  wrote:
> > Package: src:btrfs-progs
> > Severity: normal
> > Tags: patch
> >
> > Attached is a patch that will allow btrfs-progs-4.16.1 to be built on
> > Debian and Ubuntu.  AFAICT there's no need to add --with python3 at
> > this time, but I'm guessing that some day that might become a good
> > idea.
> 
> I have started on packaging 4.16.1 as well. And i would NAK this for now.

I agree, your solution in 4.16.1-1 is a better way to do this :-) BTW,
would you please change the debhelper (>= 11) dep to (>=11~)?

> It seems like btrfs-progs upstream makefiles are buggy. It tries hard
> to create dynamic & static binaries, and libraries, however, neither
> libtrfs nor libtrfs-utils libraries are dynamically linked to the
> btrsfs-* utils. Thus at the moment, it looks like nothing links to
> btrfs.so, althought everything could have been linked to it.
> 
> I'm not sure what the upstream intention is/was for the btrfs.so - is
> it internal only library, which should then be noinst; or is it meant
> to be a public library, yet private, as in libbtrfs.so.0 without any
> public -dev package; and similarly what to do about btrfs-util.so and
> the python bindings.

From what I understand the Python bindings will allow access to common
operations like snapshotting, without needing to use a subprocess and
without needing to parse btrfs' output.  'Not sure if it can do this
yet, but I'll look into it in the months to come.

> Thus I was going to seek upstream clarification on wether or not btrfs
> & btrfs-util libraries are meant to be public or private; and
> installed or not.
> 
> I wonder if this is the result of not using automake =/

Sorry, all I've heard is that the core tools are going to break out
more of their code to the libraries.  OpenSUSE packages the libraries
separately, and as they're the project most committed to btrfs it
seems like a reasonable thing to do, and that the libraries are meant
to be used by other applications.
http://download.opensuse.org/tumbleweed/repo/oss/x86_64/

Cheers!
Nicholas


signature.asc
Description: PGP signature

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Jeremy Stanley]

On 2018-05-15 14:20:15 -0500 (-0500), Mario Frasca wrote:
[...]
> it was developed between 2008-11 (0.0.6) and 2009-8 (0.0.17)
> [...]

The dates made me strongly suspect, but skimming the upstream source
confirms, this is very much not a Py3K-ready library. Are you
becoming de facto upstream for this and planning to update it to
support Python 3.x in preparation for 2.7 reaching end of life?
-- 
Jeremy Stanley

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Mario Frasca]

I did not notice the template

  Package: sponsorship-requests
  Severity: normal [important for RC bugs, wishlist for new packages]

  Dear mentors,

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

 * Package name: fibra
   Version : 0.0.17-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstreams web site]
 * License : [fill in]
   Section : python

  It builds those binary packages:

 python-fibra - Advanced cooperative concurrency using Python generators.
 python-fibra-doc - Advanced cooperative concurrency using Python generators.
 python3-fibra - Advanced cooperative concurrency using Python generators.

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fibra/fibra_0.0.17-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  this is my first upload.


  Regards,
   Mario Frasca

Bug#898788: libreoffice-help-common: [RC] embedded copy of normalize.css

[Rene Engelhard]

Hi,

On Tue, May 15, 2018 at 10:56:25PM +0200, Rene Engelhard wrote:
> Which package? Don't see a package shipping it?

#898789 suggests libjs-normalize.css. Which doesn't exist.

Regards,

Rene

Bug#898708: vcs-deprecated-in-debian-infrastructure browse.dgit.debian.org

[Ian Jackson]

Chris Lamb writes ("Re: vcs-deprecated-in-debian-infrastructure 
browse.dgit.debian.org"):
> tags 898708 + pending
> thanks
> 
> Hi Ian,
> > browse.dgit.debian.org is fully supported and is not going away.
> 
> Was merely an oversight, don't worry. ;)

Right.  I thought I should avoid any doubt though :-).

>  Applied in Git, pending upload:
> 
>   
> https://salsa.debian.org/lintian/lintian.git/commit/cdeb447a02cd382ec5c22fb8ace02dfd8280e76b

Thanks.  FYI, I looked at that in my ordinary browser (very limited
JS, no cookies, etc.) and it invited me to log in.  Surely that is not
right ?

Ian.

Bug#898788: libreoffice-help-common: [RC] embedded copy of normalize.css

[Rene Engelhard]

severity 898788 important
retitle 898788 libreoffice-help-common: embedded copy of normalize.css
thanks

Hi,

On Tue, May 15, 2018 at 10:39:44PM +0200, Bastien ROUCARIÈS wrote:
> Package: libreoffice-help-common
> Version: 1:6.1.0~beta1~git20180507-1
> Severity: serious
> Justification: Policy 4.13

Debian policy 4.13 says "should", not "must". I'd agree with you if this
was non-free, it isn't, though:

rene@frodo:~/data/git/LibreOffice/master/helpcontent2$ head -n 1
./help3xsl/normalize.css
/*! normalize.css v8.0.0 | MIT License |
 * github.com/necolas/normalize.css */

And why are the other ones not RC buggy? Why is chromium
not RC buggy? Why not texlive including poppler? etc.

This is at most important.

> This package include embedded copy of normalize.css
> /usr/share/libreoffice/help/normalize.css
> 
> Please use the package instead to use local copy

Which package? Don't see a package shipping it?

# apt-file search normalize.css
cargo-doc: /usr/share/doc/cargo-doc/doc/normalize.css
coffeescript-doc:
/usr/share/doc/coffeescript/html/annotated-source/public/stylesheets/normalize.css
glances:
/usr/lib/python3/dist-packages/glances/outputs/static/css/normalize.css
grafana-data: /usr/share/grafana/missing-sources/normalize.css
grafana-data: /usr/share/grafana/missing-sources/normalize.css.url
icingaweb2: /usr/share/icingaweb2/public/css/vendor/normalize.css
ldap-account-manager:
/usr/share/ldap-account-manager/style/responsive/105_normalize.css
libreoffice-help-common: /usr/share/libreoffice/help/normalize.css
r-cran-shiny:
/usr/lib/R/site-library/shiny/www/shared/ionrangeslider/css/normalize.css
recon-ng: /usr/share/recon-ng/recon/core/web/static/normalize.css
rust-doc: /usr/share/doc/rust-doc/html/normalize.css
rust-src: /usr/src/rustc-1.24.1/src/librustdoc/html/static/normalize.css
rust-src: /usr/src/rustc-1.25.0/src/librustdoc/html/static/normalize.css
sympa:
/usr/share/sympa/static_content/external/foundation/css/normalize.cs

I don't see a package shipping it?

Regards,

Rene

Bug#799170: Patch for cronolog

[S E]

Here's a patch for cronolog - same as what I submitted upstream [1],
but there's some question if it will ever be merged given the lack of
maintenance of cronolog. There's also some additional technical
discussion around details of the bug [2].

[1] https://github.com/fordmason/cronolog/pull/5
[2] https://bugs.launchpad.net/debian/+source/cronolog/+bug/1770676

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

diff -Nru cronolog-1.6.2+rpk/debian/changelog
cronolog-1.6.2+rpk/debian/changelog
- --- cronolog-1.6.2+rpk/debian/changelog2017-11-01 13:32:47.0 +
+++ cronolog-1.6.2+rpk/debian/changelog2018-05-15 17:47:53.0 +
@@ -1,3 +1,10 @@
+cronolog (1.6.2+rpk-3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix links broken by stat() on NULL pointer (Closes: #799170).
+
+ -- Scott Emmons   Tue, 15 May 2018 17:47:53 +
+
 cronolog (1.6.2+rpk-2) unstable; urgency=medium

   * QA upload
diff -Nru cronolog-1.6.2+rpk/debian/patches/090_fix_broken_links.patch
cronolog-1.6.2+rpk/debian/patches/090_fix_broken_links.patch
- --- cronolog-1.6.2+rpk/debian/patches/090_fix_broken_links.patch
1970-01-01 00:00:00.0 +
+++ cronolog-1.6.2+rpk/debian/patches/090_fix_broken_links.patch
2018-05-15 17:47:53.0 +
@@ -0,0 +1,18 @@
+Index: cronolog-1.6.2+rpk/src/cronoutils.c
+===
+--- cronolog-1.6.2+rpk.orig/src/cronoutils.c
 cronolog-1.6.2+rpk/src/cronoutils.c
+@@ -195,11 +195,11 @@ create_link(char *pfilename,
+ {
+ struct statstat_buf;
+
+-if (stat(prevlinkname, _buf) == 0)
++if (prevlinkname && stat(prevlinkname, _buf) == 0)
+ {
+ unlink(prevlinkname);
+ }
+-if (stat(linkname, _buf) == 0)
++if (linkname && stat(linkname, _buf) == 0)
+ {
+ if (prevlinkname) {
+ rename(linkname, prevlinkname);
diff -Nru cronolog-1.6.2+rpk/debian/patches/series
cronolog-1.6.2+rpk/debian/patches/series
- --- cronolog-1.6.2+rpk/debian/patches/series2011-06-09
01:41:16.0 +
+++ cronolog-1.6.2+rpk/debian/patches/series2018-05-15
17:47:53.0 +
@@ -4,3 +4,4 @@
 060_cronosplit_manpage_correction.diff
 070_manpages_fixes.diff
 080_cronosplit_utime.diff
+090_fix_broken_links.patch
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE//XzeneJP7JXus+2Ud1pESCK794FAlr7R0kACgkQUd1pESCK
794onRAApqg4rsVoXCG5dlERhDiqywm5EzOJEtmIi1DS8tTi7jZ+mj1MbPlUUGeq
E5t3Z8uzV9Qi0UEdQqC/LUbWZ76JSzpPOt0bK956MZzZcDCgxRt7EcV1wX3+7Yu5
6TH7C2dYaZ+eWdXzblu2GRZAAUWGwxuRgFTT0ueskVPRU82dtX3uQdLugdzNu7Lf
e0HTUlEv8kuCdlI6G6fWll1ygbWKVvogrelfifwL8msy+3ZSPkb7PtT19PP4RdBA
2FjhM+RnsDXrpWQbUc9N12iXPqcAo8pQa3Bh+LYIe6vQBtlB9SdK3/IHl0PUXhAG
Kc8QhLZlHDYZVv6R3WFHeAjmLUSTcXXfmiEF/qwiMtGMMnbqwNJiO25GPbrdh2bV
96sa5dwkSNCEd6zxhEKAdrb18y/DSSFofOhNOmZoauHbwb65Cw4WHkgPlmFVwDvw
UsAGORiOK8gLG1MqTGOSX4Toku40G7YGWlYVczyP+suDB2wK6fxZVKVAXAKztlrr
19n+BZgi0vEDWm7ZJcgCL0K6wcPdSdOBOEttrhaBrAHb/BE5FAERVQ/7lmbkspJZ
gXB7pAfUCOAh2Juj1/esZWig2sv+5GxTQEZphP2lg6wHvNjzD1Bit4M3uvDzzz+P
tvZbNgsKo4JiDtSfBUcJctjXZ0ADnjURRzl24SUkA9mJcsVM3pg=
=lYFZ
-END PGP SIGNATURE-

Bug#898796: thunderbird: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: thunderbird
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
mozilla/browser/base/content/aboutaccounts/normalize.css

Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898795: firefox-esr: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: firefox-esr
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
browser/base/content/aboutaccounts/normalize.css
(aka about:accounts)


Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898637: (no subject)

[ZenWalker]

I can't reproduce the issue, it works fine here

Do you have the same problem in pluma 1.20.0 ?

If it works fine for you in 1.20.0, then this new feature causes the
bug:

https://github.com/mate-desktop/pluma/pull/276

Bug#898708: vcs-deprecated-in-debian-infrastructure browse.dgit.debian.org

[Chris Lamb]

tags 898708 + pending
thanks

Hi Ian,

> browse.dgit.debian.org is fully supported and is not going away.

Was merely an oversight, don't worry. ;)  Applied in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian.git/commit/cdeb447a02cd382ec5c22fb8ace02dfd8280e76b

  checks/fields.pm   | 2 +-
  debian/changelog   | 3 +++
  .../debian/debian/control.in   | 2 +-
  3 files changed, 5 insertions(+), 2 deletions(-)


Regards,

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

Bug#898226: git: please transition from asciidoc to asciidoctor

[Nicholas D Steeves]

Control: block 895462 by -1

I'm not sure that -1 is actually wishlist...

On Tue, May 08, 2018 at 03:14:47PM -0700, Jonathan Nieder wrote:
> tags 898226 + upstream
> # asciidoc is not gone yet :)
> severity 898226 wishlist
> quit
> 
> Hi,
> 
> Nicholas D Steeves wrote:
> 
> > https://lists.debian.org/debian-backports/2018/05/msg00063.html
> >
> > src:git/1:2.17.0-1 Build-Depends on asciidoc (>= 8.6.10); however,
> > in asciidoc/NEWS.Debian the following is advised:
> >
> >   asciidoc (8.6.10-1) unstable; urgency=low
> >
> > The version 8.6.10 has been marked as FINAL RELEASE by the upstream 
> > maintainers.
> > They advise their users to move to asciidoctor.
> > See: https://github.com/asciidoc/asciidoc/releases
> 
> Thanks for writing.  If possible, I prefer to move to sphinx instead.
> I'll start a conversation upstream.

Yeah, I also prefer sphinx--much more powerful.  On the upside,
asciidoctor is really easy to switch to!  I've heard a sed -i
's/asciidoc/asciidoctor/' debian/control is often all that is
required.  It also looks like upstream already supports Asciidoctor,
given changelog entries such as these:

debian/changelog.upstream
1427:  Documentation: enable compat-mode for Asciidoctor
1432:  Documentation: convert SubmittingPatches to AsciiDoc
3405:  subtree: honour USE_ASCIIDOCTOR when set

> [...]
> > Consequently, to unblock an update of the existing stretch-backport of
> > src:git it is preferable that src:git in sid transition to asciidoctor
> > at this time, rather than creating a NEW stretch-backport of
> > asciidoc/8.6.10-1.
> 
> Backports should not require this --- git has built fine with older
> versions of asciidoc before.  I'm happy to work with anyone interested
> in helping with the backport at g...@packages.debian.org.

Yes, it did :-) however, in this -backports thread Mert Dirik said
that the asciidoc version bump allowed git to build reproducibly. (
https://lists.debian.org/debian-backports/2018/05/msg00063.html )
Given that 1) no-change bpos should be done whenever possible, and the
sid branch should be modified to allow this, and 2) reproducibility is
good, and both unstable and backports should be reproducible, it
follows that 3) backport newer asciidoc to stretch or 4) transition to
asciidoctor or 5) transition to sphinx is needed to continue to
fulfill #1 and #2.  Stretch has asciidoctor, but I haven't yet tested
if it's new enough.

CCing g...@packages.debian.org, but please reply to this bug, because I
am not yet subscribed.

Shall I go ahead and do the work to transition to Asciidoctor, or
would you like to wait for upstream's response wrt sphinx?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#898794: wims-module: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: wims-modules
Version: 1:4.15b~dfsg1-11
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
 /var/lib/wims/public_html/scripts/js/bower_components/normalize.min.css


Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898791: rust-doc: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: rust-doc
Version: 1.24.1+dfsg1-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/doc/rust-doc/html/normalize.css

Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Jeremy Stanley]

On 2018-05-15 14:20:15 -0500 (-0500), Mario Frasca wrote:
[...]
> it was developed between 2008-11 (0.0.6) and 2009-8 (0.0.17)
[...]

The dates made me strongly suspect, but skimming the upstream source
confirms, this is very much not a Py3K-ready library. Are you
becoming de facto upstream for this and planning to update it to
support Python 3.x in preparation for 2.7 reaching end of life?
-- 
Jeremy Stanley

Bug#898721: lintian -- maybe false positive on description-starts-with-package-name

[Chris Lamb]

tags 898721 + moreinfo
thanks

Hi Thorsten,

> I am not sure whether this is a good english expression, but if so, this 
> is a false positive:
> 
> Description: base58 encode/decode: command-line interface

It's "valid" but very clunky. Could you suggest they use, for example:

  command-line interface to encode and decode base58 integers

?

Moreover, I'm not sure what pattern would deterministically detect
this as a false-positive...


Best wishes,

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

Bug#898792: rust-src: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: rust-src
Version: 1.24.1+dfsg1-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/src/rustc-1.24.1/src/librustdoc/html/static/normalize.css

Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898793: sympa: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: sympa
Version: 6.2.32~dfsg-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/sympa/static_content/external/foundation/css/normalize.css


Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898790: r-cran-shiny: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: r-cran-shiny
Version: 1.0.5+dfsg-4
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/libreoffice/help/normalize.css

Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898789: recon-ng: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: recon-ng
Version: 4.9.3-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/recon-ng/recon/core/web/static/normalize.css


Please use the package libjs-normalize.css instead to use local copy

Thanks 

Bastien

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

Bug#898759: should report UNRELEASED in a NEWS.Debian file

[Chris Lamb]

tags 898759 + moreinfo
thanks

Hi Marc,

> lintian should report if the NEWS.Debian file contains UNRELEASED in the
> top line as a warning.

Does Lintian not do this already? For example:

  
https://lintian.debian.org/tags/debian-news-entry-has-strange-distribution.html

We also check for mismatches in the distribution and priority between
debian/changelog.


Best wishes,

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

Bug#898788: libreoffice-help-common: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: libreoffice-help-common
Version: 1:6.1.0~beta1~git20180507-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/libreoffice/help/normalize.css

Please use the package instead to use local copy

Thanks 

Bastien

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

Bug#898716: zotero-standalone: Can open dropdown menus, but clicking buttons does nothing (buster)

[Sébastien Villemot]

Dear Darachm,

On Tue, May 15, 2018 at 08:42:43AM -0400, darachm wrote:
> Package: zotero-standalone
> Version: 4.0.29.16+dfsg-1
> Severity: important

> The program 'zotero' opens nicely from the terminal with an xorg
> display (i3 wm), reporting:
> 
> xulrunner not found, trying firefox instead.
> 
> I can click on menus and buttons, and menus drop down or buttons
> visually "click", but the corresponding action does not take place.

Thanks for your report.

I guess the solution would be to package Zotero 5 in Debian, but this is not an
easy task, and may not happen soon (if at all). See the discussion in #871502.

Best,

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


signature.asc
Description: PGP signature

Bug#898787: ldap-account-manager: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: src:ldap-account-manager
Version: 6.3-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
/usr/share/ldap-account-manager/style/responsive/105_normalize.css

Please use the package instead to use local copy

Thanks 

Bastien

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

Bug#898786: icingaweb2: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: src:icingaweb2
Version: 2.5.3-1
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
icingaweb2: /usr/share/icingaweb2/public/css/vendor/normalize.css

Please use the package (maybe using suggest) instead to use local copy

Thanks 

Bastien

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

Bug#898785: granafa: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: src:granafa
Version: 2.6.0+dfsg-3
Severity: serious
Justification: Policy 4.13

This package include embedded copy of normalize.css
The files:
grafana-data: /usr/share/grafana/missing-sources/normalize.css
grafana-data: /usr/share/grafana/missing-sources/normalize.css.url

(possibly included in some html file)

Please use the package (maybe using suggest) instead to use local copy

Thanks 

Bastien

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

Bug#898226:

[Nicholas D Steeves]

On Wed, May 09, 2018 at 12:35:56PM +0800, Aron Xu wrote:
> Control: owner -1 Nicholas D Steeves 
> 
> Hi Nicholas,
> 
> Please feel free to take this, thank you!
> 
> Regards,
> Aron

Thanks Aron!

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#898784: ITP: r-cran-rstan -- GNU R interface to Stan

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-rstan
  Version : 2.17.3
  Upstream Author : Jiqiang Guo, Jonah Gabry, Ben Goodrich, Daniel Lee,
* URL : https://cran.r-project.org/package=rstan
* License : GPL-3+
  Programming Lang: GNU R
  Description : GNU R interface to Stan
 User-facing R functions are provided to parse, compile, test, estimate,
 and analyze Stan models by accessing the header-only Stan library
 provided by the 'StanHeaders' package. The Stan project develops a
 probabilistic programming language that implements full Bayesian
 statistical inference via Markov Chain Monte Carlo, rough Bayesian
 inference via 'variational' approximation, and (optionally penalized)
 maximum likelihood estimation via optimization. In all three cases,
 automatic differentiation is used to quickly and accurately evaluate
 gradients without burdening the user with the need to derive the partial
 derivatives.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-rstan
This package belongs to a set of dependencies for r-cran-brms which is
needed to upgrade r-cran-emmeans to the latest upstream version.

Bug#898630: enigmail: efail attack against enigmail

[David Sanders]

I think this bug applies to Thunderbird as well as Enigmail and both 
packages need urgent updates.


The Enigmail part can be corrected by updating to version 2.0.3, but the 
user will still be vulnerable until a new version of Thunderbird is 
released and pushed out to users. Long term the openPGP standard needs 
to be updated to address the issue.


Could the maintainers of Enigmail take for action updating to the 
already released 2.0.3? And forwarding the bug to Thunderbird for 
further action?


Thanks,
David

On Mon, 14 May 2018 15:15:26 +0200 Yves-Alexis Perez  
wrote:

> Package: enigmail
> Severity: grave
> Tags: security
> Justification: user security hole
>
> Hi Daniel,
>
> in case you haven't already heard about it by now, a vulnerability has
> been published against S/MIME and PGP/MIME in various email clients,
> including thunderbird (and enigmail).
>
> I'm unsure if CVE-2017-17688 (OpenPGP CFB gadget attacks) applies
> to Thunderbird/enigmail or only GnuPG, but the PGP/MIME vulnerability
> does apply to enigmail.
>
> Some fixes apparently went in to enigmail 2.0.0 but I'm unsure which of
> them yet, so any pointers appreciated (for example by closing with the
> correct version number :).
>
> I think we'll likely want to release a DSA too.
>
> Regards,
> --
> Yves-Alexis

Bug#898783: linux-image-amd64: Raven Ridge not supported in debian kernel image

[Diego Roversi]

Package: linux-image-amd64
Version: 4.16+93
Severity: normal

Dear maintener,
  
  from version 4.15, linux support raven ridge gpu, but it need to be
enabled in the build config. 

  I've succed to enable gpu on a AMD Ryzen 2200G, changing this
following lines in linux config:

#
# Display Engine Configuration
#
CONFIG_DRM_AMD_DC=y
CONFIG_DRM_AMD_DC_PRE_VEGA=y
CONFIG_DRM_AMD_DC_FBC=y
CONFIG_DRM_AMD_DC_DCN1_0=y
# CONFIG_DEBUG_KERNEL_DC is not set

  Test was made using 4.17-rc4, but should work also with 4.16. I've
found the information on https://wiki.gentoo.org/wiki/AMDGPU .

  Note: it also need updated amdgpu firmware from upstream.

Thanks,
  Diego Roversi

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

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

Versions of packages linux-image-amd64 depends on:
ii  linux-image-4.16.0-1-amd64  4.16.5-1

linux-image-amd64 recommends no packages.

linux-image-amd64 suggests no packages.

-- debconf-show failed

Bug#898782: glances: [RC] embedded copy of normalize.css

[Bastien ROUCARIÈS]

Package: src:glances
Version: 2.11.1-3
Severity: serious
Justification: Policy 4.13

The files:
glances: /usr/lib/python3/dist-packages/glances/outputs/static/css/normalize.css


Please use the package (maybe using suggest) instead to use local copy

Thanks 

Bastien

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

Bug#887861: Enable NetworkManager.wait-online.service on diskful workstations

[Wolfgang Schweer]

On Tue, May 15, 2018 at 07:58:30AM +, Mike Gabriel wrote:
> The point is that /etc/network/interfaces has an entry for eth0 (or what the
> first NIC is called).
> 
> This is true for stretch, at least. Could you check, if your buster systems
> manage eth0 via ifupdown? If so, NetworkManager ignores that interface and
> the wait-online service has no effect on that device.
 
Hi Mike.

AFAIK this is the case since ages (forced to be ethX instead of a 
predictable interface name via kernel command line param 'net.ifnames=0' 
setting in grub.conf since Stretch).

It works for me too (virtual network, no real world deployment 
available), if all entries except the loopback ones are commented.

> This is true for stretch, at least. Could you check, if your buster 
> systems manage eth0 via ifupdown? If so, NetworkManager ignores that 
> interface and the wait-online service has no effect on that device.

IIRC, the NetworkManager configuration isn't touched at all by 
d-e-config, i.e. it's the one shipped w/ package 'network-manager':

[main]
plugins=ifupdown,keyfile

[ifupdown]
managed=false

Wolfgang


signature.asc
Description: PGP signature

Bug#898781: python-ipywidgets-doc: HTML documentation appears to be missing (All 'Format' sections are invalid)

[Diane Trout]

Package: python-ipywidgets-doc
Version: 6.0.0-2
Severity: important

Dear Maintainer,

While installing python-ipywidgets-doc dpkg reported the following error.

  Processing 1 added doc-base file...
  Error in `/usr/share/doc-base/python-ipywidgets-doc', line 11: all `Format'
sections are invalid.
  Note: `install-docs --verbose --check file_name' may give more details about
the above error.

I ran --verbose --check:

  Warning in `/usr/share/doc-base/python-ipywidgets-doc', line 11: file
`/usr/share/doc/python-ipywidgets-doc/html/  index.html' does not exist.
  Error in `/usr/share/doc-base/python-ipywidgets-doc', line 11: all `Format'
sections are invalid.

There doesn't appear to be any HTML files in the .deb

  dpkg --listfiles python-ipywidgets-doc
  /.
  /usr
  /usr/share
  /usr/share/doc
  /usr/share/doc/python-ipywidgets-doc
  /usr/share/doc/python-ipywidgets-doc/changelog.Debian.gz
  /usr/share/doc/python-ipywidgets-doc/copyright
  /usr/share/doc/python-ipywidgets-doc/html
  /usr/share/doc/python-ipywidgets-doc/html/_static
  /usr/share/doc-base
  /usr/share/doc-base/python-ipywidgets-doc
  /usr/share/lintian
  /usr/share/lintian/overrides
  /usr/share/lintian/overrides/python-ipywidgets-doc
  /usr/share/doc/python-ipywidgets-doc/html/_static/mathjax




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

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

Versions of packages python-ipywidgets-doc depends on:
ii  jupyter-sphinx-theme-common  0.0.6+ds1-3
ii  libjs-mathjax2.7.3+dfsg-1

python-ipywidgets-doc recommends no packages.

python-ipywidgets-doc suggests no packages.

-- no debconf information

Bug#897942: Consent to use GPL-2+ required for past contributors to debian/*

[Nicholas D Steeves]

On Sat, May 05, 2018 at 08:09:20AM +0200, Vincent Fourmond wrote:
> On Sat, May 5, 2018 at 2:01 AM, Nicholas D Steeves  wrote:
> > Package: yaml-mode
> > Version: 0.0.9-2
> > Severity: normal
> >
> > Dear Vincent and Jari,
> >
> > Thank you for your work on yaml-mode.  It made the process of learning
> > to write config files in yaml much less painful, and I expect to
> > continue to use it for the foreseeable future.
> >
> > I've adopted yaml-mode under the umbrella of the Debian Emacsen Team,
> > and at this time I'd like to take the opportunity to modernise the
> > package in various ways.  Moving to machine-readable copyright-format
> > 1.0 will require documentation of past contributors to debian/*'s
> > consent to license their work as GPL-2+ (preferred) or a license of
> > their choice.
> >
> > Would you please reply to this bug, stating that you'd like your
> > contributions to yaml-mode/debian/* to be GPL-2+?
> >
> > Sincerely,
> > Nicholas
>
>   Yes, that's fine for me, and definitely what I intended to do in the
> original debian/copyright file.
> 
>   Kind regards,
> 
>   Vincent Fourmond
> 

Thank you for the quick reply Vincent!  I've filed a transition to
machine-readable copyright bug...oops, I just realised that was
unecessary, since I had decided to track the confirmation in this bug
rather than in a README.source.  Sorry for the noise!

Because I've elpafied the package, elpa-yaml-mode will need to pass
through new.  Would you be willing to sponsor the upload sometime late
next week?

Sincerely,
Nicholas


signature.asc
Description: PGP signature

Bug#895035: osc: crashes with memory corruption when using new libssl1.1

[Simon McVittie]

Control: tags -1 + patch fixed-upstream

On Wed, 02 May 2018 at 17:19:20 +0100, Simon McVittie wrote:
> * https://github.com/openSUSE/osc/issues/398
> 
>   """
>   - m2crypto 0.29 does no SSL_free(...) (which is fixed in 0.30)
> (that's why this bug is not triggered with m2crypto 0.29)
>   - there's a "bug" in ssl_update_cache cache in openssl 1.1.0h (in
> short: the session is not put in the session cache...)
>   - osc currently relies on the fact that the session is in the session
> cache (or more precisely, that there are at least two references to
> the SSL_SESSION), which is, of course, a bug in osc
>   """

The osc crash appears to be fixable by the patch that was applied
upstream (see attached Disable-ssl-session-resumption.patch). If I'm
understanding the commit message correctly, strictly speaking this was
already an osc bug (it made bad assumptions about session caching),
but the regression in openssl changed its impact from "might crash in
rare cases" to "crashes every time".

> * https://github.com/openssl/openssl/pull/5967
> 
>   """
>   Commit d316cdc introduced some extra
>   checks into the session-cache update procedure, intended to prevent
>   the caching of sessions whose resumption would lead to a handshake
>   failure, since if the server is authenticating the client, there needs to
>   be an application-set "session id context" to match up to the authentication
>   context. While that change is effective for its stated purpose, there
>   was also some collatoral damage introduced along with the fix -- clients
>   that set SSL_VERIFY_PEER are not expected to set an sid_ctx, and so
>   their usage of session caching was erroneously denied.
> 
>   Fix the scope of the original commit by limiting it to only acting
>   when the SSL is a server SSL.
>   """

Sorry for the delay in testing this.

Applying openssl commit c84f7d9251446bf76c179bf5da31f25944f4b975
(and reverting osc to the version that crashes) seems
to be another way to address this. See attached
c84f7d9251446bf76c179bf5da31f25944f4b975.patch.

Regards,
smcv
From: Marcus Huewe 
Date: Tue, 8 May 2018 14:23:08 +0200
Subject: Disable ssl session resumption

The old code could potentially yield to a use-after-free situation,
which results in UB. For this, consider the following scenario, where
osc performs several HTTPS requests (assumption: the server supports
ssl session resumption):

- HTTPS Request 1:
  * a new SSL *s connection is established, which also creates a new
SSL_SESSION *ss => ss->references == 1
  * once the handshake is done, the ss is put into the session cache
(see ssl_update_cache) => ss->references == 2
  - osc saves the session ss in a class variable
  - s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1

- HTTPS Request 2:
  * setup a new SSL *s connection that reuses the saved session ss
=> ss->references == 2
  * once the handshake is done, ssl_update_cache is called, which is a
NOP, because s->hit == 1 (that is, the session was resumed)
  * osc saves the session ss in a class variable
  * s is SSL_free()d, which calls SSL_SESSION_free => ss->references == 1

...

> 2 hours later (see tls1_default_timeout)

...

- HTTPS Request 256:
  * setup a new SSL *s connection that reuses the saved session ss
=> ss->references == 2
  * once the handshake is done, ssl_update_cache is called, but is
_no_ NOP anymore
  * ssl_update_cache flushes the session cache (this is done every
255/256 (depending on the way we count) connections) => ss is
SSL_SESSION_free()d => ss->references == 1
  * osc saves the session ss in a class variable
  * s is SSL_free()d, which calls SSL_SESSION_free:
since ss->references == 1, ss is eventually free()d

- HTTPS Request 257:
  * setup a new SSL *s connection that reuses the saved session ss

Since ss does not exist anymore, the remaining program execution is UB.

(Note: SSL_free(...) is _NOT_ called, if M2Crypto 0.29 is used.
M2Crypto 0.30 calls SSL_free(...) again.)

Due to a bug in OpenSSL_1_1_0h (see openssl commit 8e405776858) the
scenario from above can be triggered with exactly 2 HTTPS requests (the
SSL_SESSION is not cached, because we configured SSL_VERIFY_PEER, but
no sid_ctx was set). This is fixed in openssl commit c4fa1f7fc01.

In order to reliably reuse a session, we probably need to listen to the
session cache changes. Such callbacks could be registered via
SSL_CTX_sess_set_new_cb and/or SSL_CTX_sess_set_remove_cb, but both
functions are not provided by M2Crypto. Another idea is to directly utilize
the session cache, but this also has to be implemented in M2Crypto first.
Yet another approach is to retrieve the session via SSL_get1_session, which
increases the session's refcnt, but this also needs to be implemented in
M2Crypto first (if we choose to use this approach, we also have to make
sure that we eventually free the session manually...).

Fixes: #398 ("SIGSEGV on \"osc commit\"")

Bug#898780: coffeescript-doc: [RC] embedded code copy of node-normalize.css

[Bastien ROUCARIÈS]

Package: src:coffeescript-doc
Version: 1.12.7~dfsg-3
Severity: serious
Justification: Policy 4.13

The files:
coffeescript-doc: /usr/share/doc/coffeescript/html/annotated-source/public/
stylesheets/normalize.css
Are embedded copy of node-normalize.css.

Please use the package (maybe using suggest) instead to use local copy

Thanks 

Bastien



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

Bug#898777: please switch to machine-readable copyright format 1.0

[Nicholas D Steeves]

Package: yaml-mode
Version: 0.0.9-2
Severity: minor

Control: block -1 by 897315

Filing this bug as a reminder to myself to switch to copyright format 1.0 if 
897315 isn't resolved in the next week.

Regards,
Nicholas

Bug#898779: src:cargo-doc: [RC] embedded code copy of node-normalize.css

[Bastien Roucariès]

Package: src:cargo-doc
Version: 0.25.0-2
Severity: serious
Justification: Policy 4.13

The files:
cargo-doc: /usr/share/doc/cargo-doc/doc/normalize.css
cargo-doc: /usr/share/doc/cargo-doc/doc/stylesheets/normalize.css

Are embedded copy of node-normalize.css.

Please use the package (maybe using suggest) instead to use local copy

Thanks

Bastien

Bug#898778: hooks/btrfs fails

[Witold Baryluk]

Package: initramfs-tools
Version: 0.130
Severity: important

Hi.


# LC_ALL=C dpkg --configure -a
Setting up initramfs-tools (0.130) ...
update-initramfs: deferring update (trigger activated)
Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.16.0-1-amd64
E: /usr/share/initramfs-tools/hooks/btrfs failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.16.0-1-amd64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned 
error exit status 1
Errors were encountered while processing:
 initramfs-tools


$ dpkg -l | grep btrfs
ii  btrfs-progs4.16.1-1 
   amd64Checksumming Copy on Write Filesystem utilities
ii  btrfs-tools4.15.1-2 
   amd64transitional dummy package
ii  extlinux   3:6.04~git20171011.af7e95c3+dfsg1-3  
   amd64collection of bootloaders (Linux ext2/ext3/ext4, btrfs, and xfs 
bootloader)
$


Thanks!


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 27M Mar 21 08:53 /boot/initrd.img-4.15.0-1-amd64
-rw-r--r-- 1 root root 27M Apr 16 18:49 /boot/initrd.img-4.15.0-2-amd64
-rw-r--r-- 1 root root 27M Apr 22 22:37 /boot/initrd.img-4.15.0-3-amd64
-rw-r--r-- 1 root root 28M May  5 02:53 /boot/initrd.img-4.16.0-1-amd64
-- /proc/cmdline
BOOT_IMAGE=/vmlinuz-4.16.0-1-amd64 root=/dev/mapper/xyz_mirrored--ssd-root ro 
intel_iommu=on iommu=pt

-- resume
RESUME=/dev/mapper/xyz_mirrored--ssd-swap_1
-- /proc/filesystems
btrfs
ext3
ext2
ext4
vfat
fuseblk
xfs
jfs
msdos
ntfs
minix
hfs
hfsplus
qnx4
ufs

-- lsmod
Module  Size  Used by
ufs86016  0
qnx4   16384  0
hfsplus   114688  0
hfs69632  0
minix  40960  0
ntfs  106496  0
msdos  20480  0
jfs   208896  0
xfs  1433600  0
vboxpci28672  0
vboxnetadp 28672  0
vboxnetflt 32768  0
vboxdrv   483328  3 vboxnetadp,vboxnetflt,vboxpci
xt_nat 16384  0
veth   16384  0
uas28672  0
usb_storage69632  2 uas
cpuid  16384  0
fuse  118784  3
zfs  4022272  37
zunicode  335872  1 zfs
zlua  180224  1 zfs
zcommon86016  1 zfs
znvpair90112  2 zcommon,zfs
zavl   16384  1 zfs
icp   286720  1 zfs
spl   114688  5 znvpair,zcommon,zfs,icp,zavl
nf_conntrack_netlink49152  0
nfnetlink  16384  2 nf_conntrack_netlink
xfrm_user  45056  1
xfrm_algo  16384  1 xfrm_user
xt_addrtype16384  2
br_netfilter   24576  0
overlay   102400  0
pci_stub   16384  1
xt_CHECKSUM16384  1
iptable_mangle 16384  1
ipt_MASQUERADE 16384  4
nf_nat_masquerade_ipv416384  1 ipt_MASQUERADE
iptable_nat16384  1
nf_nat_ipv416384  1 iptable_nat
nf_nat 36864  3 xt_nat,nf_nat_masquerade_ipv4,nf_nat_ipv4
nf_conntrack_ipv4  16384  7
nf_defrag_ipv4 16384  1 nf_conntrack_ipv4
xt_conntrack   16384  2
nf_conntrack  155648  8 
xt_nat,nf_conntrack_ipv4,ipt_MASQUERADE,nf_conntrack_netlink,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
ipt_REJECT 16384  2
nf_reject_ipv4 16384  1 ipt_REJECT
xt_tcpudp  16384  6
tun45056  1
bridge184320  1 br_netfilter
stp16384  1 bridge
llc16384  2 bridge,stp
ip6table_filter16384  0
ip6_tables 28672  1 ip6table_filter
devlink61440  0
iptable_filter 16384  1
cpufreq_userspace  16384  0
cpufreq_conservative16384  0
cpufreq_powersave  16384  0
binfmt_misc20480  1
nls_ascii  16384  2
quota_v2   16384  2
nls_cp437  20480  2
quota_tree 20480  1 quota_v2
vfat   24576  2
fat77824  2 msdos,vfat
intel_rapl 24576  0
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
kvm_intel 180224  0
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
mxm_wmi16384  0
amdkfd176128  1
kvm   704512  1 kvm_intel
efi_pstore 16384  0
irqbypass  16384  1 kvm
amdgpu   2752512  26
snd_hda_codec_hdmi 57344  1
chash  16384  1 amdgpu
gpu_sched  28672  1 amdgpu

Bug#898775: osc: not enough Build-Depends to run `debian/rules clean`

[Simon McVittie]

On Tue, 15 May 2018 at 20:40:15 +0100, Simon McVittie wrote:
> osc's Build-Depends are insufficient to run `debian/rules clean`
> (Policy §7.7), because they don't include two packages that provide
> debhelper sequences.

Those packages are actually insufficient too, because `setup.py clean`
indirectly imports python-urlgrabber. Better patch attached.

smcv
>From efec71c9c7e28f6e6beef25426989f226f3023a2 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 15 May 2018 20:34:34 +0100
Subject: [PATCH] Merge Build-Depends-Indep into Build-Depends
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The python2 and bash-completion debhelper sequences are needed for
the clean target when building a source package, but that target is
only guaranteed to have the Build-Depends available (Policy §7.7); and
python-urlgrabber turns out to also be needed during clean, because
it's indirectly imported by setup.py.

Closes: #898775
---
 debian/changelog | 12 
 debian/control   | 12 ++--
 2 files changed, 18 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 63d283c..e14f894 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+osc (0.162.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Merge Build-Depends-Indep into Build-Depends. The python2 and
+bash-completion debhelper sequences are needed for the clean target
+when building a source package, but that target is only guaranteed to
+have the Build-Depends available; and python-urlgrabber turns out to
+also be needed during clean, because it's indirectly imported
+by setup.py. (Closes: #898775)
+
+ -- Simon McVittie   Tue, 15 May 2018 20:04:29 +0100
+
 osc (0.162.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 1d5b1c8..4414a47 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,12 @@ Maintainer: RPM packaging team 
 Uploaders: Michal Čihař 
 Section: devel
 Priority: optional
-Build-Depends: debhelper (>= 9),
-   dh-exec
-Build-Depends-Indep: python,
- python-urlgrabber,
- dh-python,
- bash-completion
+Build-Depends: bash-completion,
+   debhelper (>= 9),
+   dh-exec,
+   dh-python,
+   python,
+   python-urlgrabber
 Standards-Version: 4.1.3
 Vcs-Browser: https://anonscm.debian.org/git/pkg-rpm/osc.git
 Vcs-Git: https://anonscm.debian.org/git/pkg-rpm/osc.git
-- 
2.17.0

Bug#898776: numpy.arange does not work on several platforms

[Ole Streicher]

Package: python3-numpy
Version: 1:1.14.3-2
Severity: serious
Control: affects -1 src:astropy
Control: forwarded -1 https://github.com/numpy/numpy/issues/11103

Hi,

On several platforms, numpy.arange does not work properly with 128 bit.
For example on arm64:

Python 3.6.5 (default, May 11 2018, 13:30:17)
[GCC 7.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy
>>> numpy.arange(3)
array([0, 1, 2])
>>> numpy.arange(3, dtype=numpy.float128)
array([0., 0., 0.], dtype=float128)

This (or similar) happens on arm64, ppc64el, s390x, riscv64, and others.

This causes an FTBFS for astropy on these platforms, therefore the severity.

Best regards

Ole

Bug#898738: debootstrap fails when specifying components

[Cyril Brulebois]

Luca Falavigna  (2018-05-15):
> found 898738 1.0.97
> thanks

Right, I knew I was forgetting something. That happens when I spend too
much time debugging and adjusting the write-up as I go. Thanks for
fixing.

> 2018-05-15 21:19 GMT+02:00 Cyril Brulebois :
> > The issue seems to be the non-free Packages file being checked
> > against the checksum of the contrib one (both sha256 checksum and
> > size in fact), so that can't work.
> 
> Thanks for checking! Indeed the problem can be reproduced from 1.0.97
> (hence adjusting found correctly). I'll have a look in the next few
> days as well.

I think I've found the issue. At least partly reverting the commit
makes retrieving/validating indices work again, possibly because
un-local-izing names was a bad idea? (I took all hunks from the commit
that touched the download_release_indices function. Not everything is
needed I guess.)

See attached patch, against the offending commit. It doesn't apply to
master as-is because of the by-hash addition.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant
--- a/functions
+++ b/functions
@@ -610,10 +617,13 @@ download_release_sig () {
 }
 
 download_release_indices () {
-	local m1="${MIRRORS%% *}"
-	local inreldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/InRelease")"
-	local reldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/Release")"
-	local relsigdest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/Release.gpg")"
+	local m1 inreldest reldest relsigdest totalpkgs \
+	  subpath xzi bz2i gzi normi i ext \
+	  donepkgs pkgdest
+	m1="${MIRRORS%% *}"
+	inreldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/InRelease")"
+	reldest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/Release")"
+	relsigdest="$TARGET/$($DLDEST rel "$SUITE" "$m1" "dists/$SUITE/Release.gpg")"
 
 	download_release_sig "$m1" "$inreldest" "$reldest" "$relsigdest"
 
@@ -621,14 +631,13 @@ download_release_indices () {
 
 	extract_release_components "$reldest"
 
-	local totalpkgs=0
+	totalpkgs=0
 	for c in $COMPONENTS; do
-		local subpath="$c/binary-$ARCH/Packages"
-		local xzi="`get_release_checksum "$reldest" "$subpath.xz"`"
-		local bz2i="`get_release_checksum "$reldest" "$subpath.bz2"`"
-		local gzi="`get_release_checksum "$reldest" "$subpath.gz"`"
-		local normi="`get_release_checksum "$reldest" "$subpath"`"
-		local i=
+		subpath="$c/binary-$ARCH/Packages"
+		xzi="$(get_release_checksum "$reldest" "$subpath.xz")"
+		bz2i="$(get_release_checksum "$reldest" "$subpath.bz2")"
+		gzi="$(get_release_checksum "$reldest" "$subpath.gz")"
+		normi="$(get_release_checksum "$reldest" "$subpath")"
 		if [ "$normi" != "" ]; then
 			i="$normi"
 		elif in_path bunzip2 && [ "$bz2i" != "" ]; then
@@ -639,25 +648,22 @@ download_release_indices () {
 			i="$gzi"
 		fi
 		if [ "$i" != "" ]; then
-			totalpkgs="$(( $totalpkgs + ${i#* } ))"
+			totalpkgs=$(( $totalpkgs + ${i#* } ))
 		else
 			mv "$reldest" "$reldest.malformed"
 			error 1 MISSINGRELENTRY "Invalid Release file, no entry for %s" "$subpath"
 		fi
 	done
 
-	local donepkgs=0
-	local pkgdest
+	donepkgs=0
 	progress 0 $totalpkgs DOWNPKGS "Downloading Packages files"
 	for c in $COMPONENTS; do
-		local subpath="$c/binary-$ARCH/Packages"
-		local path="dists/$SUITE/$subpath"
-		local xzi="`get_release_checksum "$reldest" "$subpath.xz"`"
-		local bz2i="`get_release_checksum "$reldest" "$subpath.bz2"`"
-		local gzi="`get_release_checksum "$reldest" "$subpath.gz"`"
-		local normi="`get_release_checksum "$reldest" "$subpath"`"
-		local ext=
-		local i=
+		subpath="$c/binary-$ARCH/Packages"
+		path="dists/$SUITE/$subpath"
+		xzi="$(get_release_checksum "$reldest" "$subpath.xz")"
+		bz2i="$(get_release_checksum "$reldest" "$subpath.bz2")"
+		gzi="$(get_release_checksum "$reldest" "$subpath.gz")"
+		normi="$(get_release_checksum "$reldest" "$subpath")"
 		if [ "$normi" != "" ]; then
 			ext="$ext $normi ."
 			i="$normi"
@@ -674,7 +680,7 @@ download_release_indices () {
 			ext="$ext $gzi gz"
 			i="${i:-$gzi}"
 		fi
-		progress_next "$(($donepkgs + ${i#* }))"
+		progress_next $(($donepkgs + ${i#* }))
 		for m in $MIRRORS; do
 			pkgdest="$TARGET/$($DLDEST pkg "$SUITE" "$c" "$ARCH" "$m" "$path")"
 			if get "$m/$path" "$pkgdest" $ext; then break; fi
@@ -682,7 +688,7 @@ download_release_indices () {
 		if [ ! -f "$pkgdest" ]; then
 			error 1 COULDNTDL "Couldn't download %s" "$m/$path"
 		fi
-		donepkgs="$(($donepkgs + ${i#* }))"
+		donepkgs=$(($donepkgs + ${i#* }))
 		progress $donepkgs $totalpkgs DOWNPKGS "Downloading Packages files"
 	done
 }


signature.asc
Description: PGP signature

Bug#898775: osc: not enough Build-Depends to run `debian/rules clean`

[Simon McVittie]

Source: osc
Version: 0.162.1
Severity: normal
Tags: patch

osc's Build-Depends are insufficient to run `debian/rules clean`
(Policy §7.7), because they don't include two packages that provide
debhelper sequences.

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

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

-- no debconf information
>From 82ca04bf72803f7aff08f7015e720eee7e887517 Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Tue, 15 May 2018 20:34:34 +0100
Subject: [PATCH] Move python and bash-completion from B-D-I to B-D

The python2 and bash-completion debhelper sequences are needed for the
clean target when building a source package, but that target is only
guaranteed to have the Build-Depends available.
---
 debian/changelog | 10 ++
 debian/control   | 12 ++--
 2 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 63d283c..4bb9bd4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+osc (0.162.1-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Move python and bash-completion from Build-Depends-Indep to
+Build-Depends. The python2 and bash-completion debhelper sequences are
+needed for the clean target when building a source package, but that
+target is only guaranteed to have the Build-Depends available.
+
+ -- Simon McVittie   Tue, 15 May 2018 20:04:29 +0100
+
 osc (0.162.1-1) unstable; urgency=medium
 
   * New upstream release.
diff --git a/debian/control b/debian/control
index 1d5b1c8..6d373f6 100644
--- a/debian/control
+++ b/debian/control
@@ -3,12 +3,12 @@ Maintainer: RPM packaging team 
 Uploaders: Michal Čihař 
 Section: devel
 Priority: optional
-Build-Depends: debhelper (>= 9),
-   dh-exec
-Build-Depends-Indep: python,
- python-urlgrabber,
- dh-python,
- bash-completion
+Build-Depends: bash-completion,
+   debhelper (>= 9),
+   dh-exec,
+   python
+Build-Depends-Indep: python-urlgrabber,
+ dh-python
 Standards-Version: 4.1.3
 Vcs-Browser: https://anonscm.debian.org/git/pkg-rpm/osc.git
 Vcs-Git: https://anonscm.debian.org/git/pkg-rpm/osc.git
-- 
2.17.0

Bug#895264: updates

[Antoine Beaupre]

There is yet another new version (2.0.0) which introduces, again, new
dependencies (like xml-helpers, tuple, and gtk-sni-tray).

The new version also needs a newer dbus version, which might break other
rdeps like git-annex, fdo-notify or xmobar.

One dependency that was missing was rate-limit - I asked upstream to
ship it in Stackage, but it was refused:

https://github.com/acw/rate-limit/issues/3

Clint then uploaded rate-limit in NEW, so that's solved:

https://tracker.debian.org/news/951382/accepted-haskell-rate-limit-140-1-source-amd64-all-into-unstable-unstable/

tuple seems to be in NEW as well, and Clint will upload xml-helpers.

Otherwise there's an issue open to have Taffybar part of stackage which
would simplify package updates in the future as well:

https://github.com/taffybar/taffybar/issues/141

Hope moves ahead. At this point it's likely the focus will first be on
the 1.x series as there's already a bunch of new stuff there, and then
maybe 2.x can be packaged...

Whee, thanks Clint for all the work!

A.

-- 
The world is a dangerous place, not because of those who do evil,
but because of those who look on and do nothing.
- Albert Einstein


signature.asc
Description: PGP signature

Bug#898715: lintian: fails to parse extended timestamps in tarballs

[Stephen Kitt]

Hi Chris,

On Tue, 15 May 2018 20:00:00 +0100, Chris Lamb  wrote:
> Thanks for the patch! I fixed it in a slightly different way, but you
> did 90% of the work:
> 
>   
> https://salsa.debian.org/lintian/lintian.git/commit/f4ee651c1792f6d645014d3aa20490506d981a5c

Nice, I wasn’t sure how to ensure the group started with a period and then
contained only digits in a Perl regex!

Regards,

Stephen


pgpZpXM91wSo3.pgp
Description: OpenPGP digital signature

Bug#867180: sbuild: autopkgtest/lxc: cannot create /autopkgtest-virt-dummy-location/etc/group: Directory nonexistent

[Ian Jackson]

In summary: I think the root cause is that the lxc container is not
set up the way sbuild expects.

The named directory becomes $self->get('Location') within sbuild; it's
a dummy value used when (as in this case) the chroot provider does not
have a way to access the within-chroot filesystem from outside it.

It is used in relatively few places.  Searching for more of the error
message found a use in basesetup (in ChrootSetup.pm).  It seems to try
to use it only if the `sbuild' group is not found in the chroot.

Looking at the code, sbuild expects various other preparatory things
to have been done to the chroot.  It expects a /build directory, and
/var/lib/sbuild, and so on.  I can't find any of this documented
anywhere.

Hopefully the following, observed in an schroot of mine, is helpful:

$ id sbuild
uid=120(sbuild) gid=124(sbuild) groups=124(sbuild)
$ find /build/ /var/lib/sbuild/ -ls
   606209  4 drwxrws---   2 sbuild   sbuild   4096 Jun  3  2016 /build/
   344285  4 drwxrws---   3 sbuild   sbuild   4096 Jun  3  2016 
/var/lib/sbuild/
   344838  4 -rw-rw-r--   1 root sbuild   1417 Jun  3  2016 
/var/lib/sbuild/package-checklist
   344355  4 drwxrws---   2 sbuild   sbuild   4096 Jun  3  2016 
/var/lib/sbuild/srcdep-lock
   344721  4 -rw---   1 root sbuild117 Jun  3  2016 
/var/lib/sbuild/apt.conf
$ 

Is there a script that someone could run in an existing
vm/container/whatever, to prepare it appropriately, before
snapshotting ?

Also, the error message seems poor.

I suggest the following approach:

 * Break out the relevant bits of sbuild-createchroot into an
   advertised script that can be run as root within the master
   image (what schroot calls the source chroot).

 * Replace calls to ->get('Location') with ->get_location($reason)
   and make the latter fail if the access is not supported.
   $reason will be an explanation of what schroot was trying to do.
   So it will say something like
 E: filesystem access to chroot not supported (wanted because: trying to 
add sbuild group)

 * In the longer term, the virt servers should have a way to edit
   the master image.  Then you could say sbuild --setup-the-thing
   --autopkgtest-etc.

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#898738: debootstrap fails when specifying components

[Luca Falavigna]

found 898738 1.0.97
thanks



Hi,

2018-05-15 21:19 GMT+02:00 Cyril Brulebois :
> The issue seems to be the non-free Packages file being checked against
> the checksum of the contrib one (both sha256 checksum and size in fact),
> so that can't work.

Thanks for checking! Indeed the problem can be reproduced from 1.0.97
(hence adjusting found correctly). I'll have a look in the next few
days as well.

-- 
Cheers,
Luca

Bug#898773: RFS: python-fibra/0.0.17-1 [ITP 898736]

[Mario Frasca]

Package: sponsorship-requests
Severity: normal

Dear Maintainer,

I'm on my way to become the maintainer of a couple of packages for the
management of botanic collections, namely bauble and ghini.desktop.

both of them rely upon fibra, and fibra wasn't yet in Debian.

so I need fibra in two different packages, and it is also small enough so
that it's being a learning example for me of what difficulties to expect
when I'll face the larger packages.

Fibra itself is a mature product, it was developed between 2008-11 (0.0.6)
and 2009-8 (0.0.17), after that the upstream developer did not think of
renaming the stable version to 1.0.0.

It offers collaborative concurrency, and has been helpful in bauble,
avoiding us trouble with threading and real concurrency.

friendly regards,
Mario Frasca


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

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

Bug#898738: debootstrap fails when specifying components

[Cyril Brulebois]

Hi,

Luca Falavigna  (2018-05-15):
> Source: debootstrap
> Version: 1.0.98
> Severity: serious

Thanks for the heads-up.

> debootstrap fails when specifying components on command line:
> 
> # debootstrap --components=main,contrib,non-free unstable unstable
> http://deb.debian.org/debian
> I: Target architecture can be executed
> I: Checking Release signature
> I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
> I: Validating Packages
> I: Retrieving Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages
> I: Retrieving Packages
> I: Validating Packages
> W: Retrying failed download of
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages.gz
> W: 
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages.gz
> was corrupt
> I: Retrieving Packages
> E: Couldn't download
> http://deb.debian.org/debian/dists/unstable/contrib/binary-amd64/Packages

This is likely due to recent changes to add by-hash support, which makes
such errors fatal? (Low on time, can't really check right away.)

Anyway, before, we could see such errors but they wouldn't be fatal.
I've tracked this with the test case you suggested and with “git
bisect”, to this commit:
| commit d45ca044136553c9ef9ca194e8b48668aa6e694f
| Author: Hideki Yamane 
| Date:   Mon Apr 9 22:10:59 2018 +0900
| 
| Clean up with shellcheck


The following patch highlights the issue:
| kibi@wodi:~/debian-installer/packages/debootstrap$ git diff
| diff --git a/functions b/functions
| index 3fc7a7c..847f853 100644
| --- a/functions
| +++ b/functions
| @@ -358,6 +358,7 @@ get () {
| fi
| if [ "$checksum" != "" ]; then
| info VALIDATING "Validating %s %s" 
"$displayname" "$versionname"
| +   info TOTO "verify_checksum $dest2 $checksum 
$siz"
| if verify_checksum "$dest2" "$checksum" 
"$siz"; then
| checksum=""
| fi

See the output:
| I: Retrieving InRelease 
| I: Checking Release signature
| I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_main_binary-amd64_Packages.xz
 51576750586b79c6814c968a610c2f15fb3288bf569fe2f7ce86cadaaa7e5a8b 8063628
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_contrib_binary-amd64_Packages.xz
 78dd59c641a2fec36aef9017a1f0cbbb150a6f3b151024b7fa4aba473a6bada0 63160
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_non-free_binary-amd64_Packages.xz
 78dd59c641a2fec36aef9017a1f0cbbb150a6f3b151024b7fa4aba473a6bada0 63160
| W: Retrying failed download of 
http://ftp.fr.debian.org/debian/dists/unstable/non-free/binary-amd64/Packages.xz
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_non-free_binary-amd64_Packages.xz
 78dd59c641a2fec36aef9017a1f0cbbb150a6f3b151024b7fa4aba473a6bada0 63160
| W: Retrying failed download of 
http://ftp.fr.debian.org/debian/dists/unstable/non-free/binary-amd64/Packages.xz
[repeated]

The issue seems to be the non-free Packages file being checked against
the checksum of the contrib one (both sha256 checksum and size in fact),
so that can't work.

Going back to the previous commit (73b0bd2ce6), with the same one-line
patch:
| I: Retrieving InRelease 
| I: Checking Release signature
| I: Valid Release signature (key id 126C0D24BD8A2942CC7DF8AC7638D0442B90D010)
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_main_binary-amd64_Packages.xz
 51576750586b79c6814c968a610c2f15fb3288bf569fe2f7ce86cadaaa7e5a8b 8063628
| I: Retrieving Packages 
| I: Validating Packages 
| I: verify_checksum 
/scratch/unstable/var/lib/apt/lists/partial/debootstrap.invalid_dists_unstable_contrib_binary-amd64_Packages.xz
 

Bug#898727: Please provide adt-virt-* names, at least for buster

[Ian Jackson]

Martin Pitt writes ("Re: Bug#898727: Please provide adt-virt-* names, at least 
for buster"):
> Control: tag -1 moreinfo
...
> Do you have examples of such "expectations"? These were deprecated
> two years ago (with warning messages) and removed one year ago, with
> a NEWS and blogs and emails and all that. I haven't seen any bug
> reports or otherwise from any user that asked for bringing them
> back; this is the first one. Why now? Introducing these
> long-obsolete aliases again after they already got dropped in a
> stable release seems just unnecessary effort to me.

They were not dropped in a stable release.  They are present in
autopkgtest 4.4 in stretch, and AFAICT they generate no deprecation
warnings.

zealot:~> adt-virt-schroot build
ok
quit
zealot:~>

So I think a sensible transition would keep them (with the deprecation
warnings) in buster.  The cost of doing so is very low.

Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#898727: Please provide adt-virt-* names, at least for buster

[Martin Pitt]

Control: tag -1 moreinfo

Hello Ian,

Ian Jackson [2018-05-15 14:44 +0100]:
> These names are part of an external interface.  It is not very
> friendly to just remove them them.
> 
> This is particularly true because other programs have an expectation
> that they can have the user specify `foo' and then run `adt-virt-foo'
> from PATH.

Do you have examples of such "expectations"? These were deprecated two years
ago (with warning messages) and removed one year ago, with a NEWS and blogs and
emails and all that. I haven't seen any bug reports or otherwise from any user
that asked for bringing them back; this is the first one. Why now? Introducing
these long-obsolete aliases again after they already got dropped in a stable
release seems just unnecessary effort to me.

Martin

Bug#673322: Hello dear

[mona wilson]

Hello dear
God the blessing is up to you. I'm Mona Wilson. You look great and 
attractive. You look like an interesting person and I'm glad to establish 
mutual friendship with you. Take your time and answer me to get to know me 
bett.er, write me my email; (mona.wilso...@outlook.com) Thank you and we hope 
to hear from you soon. And I'm sorry if I scold you, but know you'll be my 
greatest luck. Thanks, 
Mona

Bug#898715: lintian: fails to parse extended timestamps in tarballs

[Chris Lamb]

tags 898715 + pending
thanks

Hey Stephen,

Thanks for the patch! I fixed it in a slightly different way, but you
did 90% of the work:

  
https://salsa.debian.org/lintian/lintian.git/commit/f4ee651c1792f6d645014d3aa20490506d981a5c

  debian/changelog   | 5 +
  lib/Lintian/Collect/Package.pm | 3 ++-
  2 files changed, 7 insertions(+), 1 deletion(-)

Thanks again :)


Best wishes,

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

Bug#282850: Patch: Added option to increase label width

[Thomas Hooge]

Hello,

i changed behavior from label width as a constant to changeable
with command line option --width  or -w .

This perhaps fixes this bug.

Yours
Thomas
--- /usr/sbin/sysv-rc-conf	2012-05-09 12:21:50.0 +0200
+++ sysv-rc-conf	2018-05-02 10:20:58.973408688 +0200
@@ -31,7 +31,6 @@
 BOTTOM_WIN_HEIGHT   => 4,
 DEFAULT_K_PRI   => 80,
 DEFAULT_S_PRI   => 20,
-LABEL_WIDTH => 10,
 LIST_SN_LENGTH  => 12,
 LIST_SN_PAD => 1,
 MAX_ROWS=> 8,
@@ -52,6 +51,7 @@
 chkcfg_list   => undef,
 chkcfg_sn => '',
 chkcfg_state  => '',
+label_width   => 10,
 );
 
 GetOptions("cache=s"	=> \$opts{cache_dir},
@@ -65,6 +65,7 @@
 	   "show=s"	=> \$opts{show},
 	   "verbose=s"	=> \$opts{verbose},
"Version"=> sub { print STDERR "$0 $VERSION\n"; exit; },
+   "width=i"=> \$opts{label_width},
 	  ) or exit(1);
 
 my $runlevel_cmd = '/sbin/runlevel';
@@ -712,7 +713,7 @@
 	undef, 'Label',
 	-text   => $left_label,
 	-y	=> $row,
-	-width  => LABEL_WIDTH,
+	-width  => $opts{label_width},
 	-height => last_x() + 1,
 	);
 
@@ -791,7 +792,7 @@
 {
 my ($screen, $sn, $row) = @_;
 
-for (my $i = 0, my $right_n = 12; $i <= $#show_rls; $i++, $right_n += 8) {
+for (my $i = 0, my $right_n = $opts{label_width} + 2; $i <= $#show_rls; $i++, $right_n += 8) {
 	my $on_or_off = 0;
 my $initial_state = 0;
 	# We only want to show S\d\d services as selected. 
@@ -830,7 +831,7 @@
 {
 my ($screen, $sn, $row) = @_;
 
-for (my $i = 0, my $right_n = 11; $i <= $#show_rls; $i++, $right_n += 8) {
+for (my $i = 0, my $right_n = $opts{label_width} + 1; $i <= $#show_rls; $i++, $right_n += 8) {
 	my $text = exists $runlevels{$sn}{$show_rls[$i]}
 		? $runlevels{$sn}{$show_rls[$i]}
 		: '';
@@ -867,10 +868,10 @@
 
 my @label_rls = @show_rls;
 
-my $text = 'service  ' . shift @label_rls;
+my $text = 'service' . ' ' x ($opts{label_width} - 4) . shift @label_rls;
 foreach (@label_rls) { $text .= "   $_" };
 $text .= "\n";
-$text .= "-" x 76;
+$text .= "-" x ($opts{label_width} + 2 + scalar(@show_rls) * 8);
 
 $window->add(
 	undef, 'Label',

Bug#898772: qemu: Keys get "stuck" when window loses focus

[Benjamin Moody]

Source: qemu
Version: 1:2.8+dfsg-6+deb9u3
Severity: normal
Tags: patch

Dear Maintainer,

when running qemu in the default graphical mode, it does not correctly
handle what happens when the window loses keyboard focus.

For example:

 * The window manager is configured to switch focus when Super+Tab is
   pressed.

 * A qemu window is focused.

 * I press Super; a KeyPress event is sent to qemu, and the
   corresponding keycode is sent to the guest OS.

 * I press Tab, which is grabbed by the window manager; the WM
   switches focus to another window.

 * I release both keys; the KeyRelease events are now delivered to
   that other window, and not to qemu.

 * The guest OS still believes the Super key is pressed, and will
   continue to believe so until I re-focus the qemu window, and press
   and release Super while the window is focused.

The result can be quite frustrating because qemu doesn't give any
visual indication of what keys it believes are currently pressed, and
in most cases neither does the guest OS.  Fixing the problem requires
the user to realize what has happened (which isn't obvious) and then
to press keys one at a time until they become un-wedged.


It appears that qemu will actually keep track of which "modifier" keys
are pressed, and automatically release *those* particular keys when
the window loses focus.  However:

 - It is limited to left and right Shift, Control, and Alt.

 - It is based on qemu's idea of what physical keycodes correspond to
   modifiers, which may have nothing to do with what keys are actually
   mapped as X modifiers.

 - There's no particular reason that the underlying problem is limited
   to modifiers in the first place (there are plenty of other ways
   that the window can lose focus while one or more keys are pressed.)


Below is a patch to fix this behavior for the SDL interface used in
stretch.

It looks like the latest version of the package, in unstable, has
removed the SDL interface in favor of GTK+.  I haven't tested it, but
from a quick skim of the source, it appears that the GTK+ interface
will have the same problem (see gd_key_event() and
gtk_release_modifiers() in ui/gtk.c.)


--- qemu-2.8+dfsg.orig/ui/sdl.c
+++ qemu-2.8+dfsg/ui/sdl.c
@@ -328,17 +328,6 @@ static void sdl_process_key(SDL_Keyboard
 /* sent when leaving window: reset the modifiers state */
 reset_keys();
 return;
-case 0x2a:  /* Left Shift */
-case 0x36:  /* Right Shift */
-case 0x1d:  /* Left CTRL */
-case 0x9d:  /* Right CTRL */
-case 0x38:  /* Left ALT */
-case 0xb8: /* Right ALT */
-if (ev->type == SDL_KEYUP)
-modifiers_state[keycode] = 0;
-else
-modifiers_state[keycode] = 1;
-break;
 #define QEMU_SDL_VERSION ((SDL_MAJOR_VERSION << 8) + SDL_MINOR_VERSION)
 #if QEMU_SDL_VERSION < 0x102 || QEMU_SDL_VERSION == 0x102 && SDL_PATCHLEVEL < 
14
 /* SDL versions before 1.2.14 don't support key up for caps/num lock. 
*/
@@ -351,6 +340,12 @@ static void sdl_process_key(SDL_Keyboard
 #endif
 }
 
+assert(keycode >= 0 && keycode < ARRAY_SIZE(modifiers_state));
+if (ev->type == SDL_KEYUP)
+modifiers_state[keycode] = 0;
+else
+modifiers_state[keycode] = 1;
+
 /* now send the key code */
 qemu_input_event_send_key_number(dcl->con, keycode,
  ev->type == SDL_KEYDOWN);

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

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

Bug#898658: f-irc gets SEGV with TERM=xterm-256color

[Sven Joachim]

CC'ing ncurses maintainer, it looks like the library might be at fault
here.

On 2018-05-15 03:05 +0900, nozzy123no...@gmail.com wrote:

> Package: f-irc
> Version: 1.36-1+b3
> Severity: serious
>
> Dear Maintainer,
>
>  This version of f-irc always gets SEGV when TERM environmental
> variable set to xterm-256color ,which is default under gnome-terminal.
>
>  However, when I set TERM  to xterm,vt100 or kterm,f-irc seems to work
> well.
>
>  Does anyone fix this problem?

No fix, but at least a backtrace in gdb:

,
| Program received signal SIGSEGV, Segmentation fault.
| _nc_pair_content 
(sp=0x5659daf0, pair=7353, f=0xd1a4, b=0xd1a8) at 
../../ncurses/base/lib_color.c:942
| 942 int bg = BACK_OF(sp->_color_pairs[pair]);
| (gdb) bt full
| #0  _nc_pair_content (sp=0x5659daf0, pair=7353, f=0xd1a4, b=0xd1a8) 
at ../../ncurses/base/lib_color.c:942
| fg = 
| bg = 
| result = 1449406468
| #1  0xf7f713de in pair_content_sp (sp=0x5659daf0, pair=7353, f=0xd216, 
b=0xd218)
| at ../../ncurses/base/lib_color.c:972
| my_f = 0
| my_b = 0
| rc = 
| #2  0xf7f7147a in pair_content (pair=7353, f=0xd216, b=0xd218) at 
../../ncurses/base/lib_color.c:984
| No locals.
| #3  0x5657b88b in init_nick_colorpairs () at nickcolor.c:90
| pair = 7353
| cr = 680
| cg = 0
| cb = 680
| loop = 5
| fg = 0
| bg = 0
| fg_r = 255
| fg_g = 255
| fg_b = 255
| bg_r = 0
| bg_g = 0
| bg_b = 0
| #4  0x5655d7b3 in main (argc=1, argv=0xd394) at main.c:670
| config_loaded = -1
`

To investigate the issue more closely, I set a breakpoint on
pair_content and used the "cont" command with some increments until I
got to the critical value of pair=7353.  Then I single-stepped through
the code:

,
| Breakpoint 1, pair_content (pair=7353, f=0xd216, b=0xd218) at 
../../ncurses/base/lib_color.c:983
| 983 {
| (gdb) step
| 984 return NCURSES_SP_NAME(pair_content) (CURRENT_SCREEN, pair, f, b);
| (gdb) step
| pair_content_sp (sp=0x5659daf0, pair=7353, f=0xd216, b=0xd218) at 
../../ncurses/base/lib_color.c:970
| 970 {
| (gdb) step
| 972 int rc = _nc_pair_content(SP_PARM, pair, _f, _b);
| (gdb) step
| 970 {
| (gdb) step
| 972 int rc = _nc_pair_content(SP_PARM, pair, _f, _b);
| (gdb) step
| _nc_pair_content (sp=0x5659daf0, pair=7353, f=0xd1a4, b=0xd1a8) at 
../../ncurses/base/lib_color.c:929
| 929 {
| (gdb) step
| 938 if (!ValidPair(sp, pair)) {
| (gdb) step
| 941 int fg = FORE_OF(sp->_color_pairs[pair]);
| (gdb) step
| 951 if (f)
| (gdb) step
| 941 int fg = FORE_OF(sp->_color_pairs[pair]);
| (gdb) step
| 942 int bg = BACK_OF(sp->_color_pairs[pair]);
| (gdb) step
| 
| Program received signal SIGSEGV, Segmentation fault.
| _nc_pair_content 
(sp=0x5659daf0, pair=7353, f=0xd1a4, b=0xd1a8) at 
../../ncurses/base/lib_color.c:942
| 942 int bg = BACK_OF(sp->_color_pairs[pair]);
`

What is sp->_color_pairs[pair] ?  It is not accessible:

,
| (gdb) print sp->_color_pairs[pair]
| Cannot access memory at address 0x56643004
| (gdb) print sp->_color_pairs[pair-1]
| Cannot access memory at address 0x56643000
| (gdb) print sp->_color_pairs[pair-2]
| $1 = {fg = 0, bg = 0, mode = 0, prev = 0, next = 0}
`

So it seems that the ncurses library did not allocate enough memory to
hold all the color pairs in sp->_color_pairs, resulting in the eventual
heap buffer overflow.

That's how far I have tracked the issue, hopefully Thomas Dickey can
investigate it further and even provide a fix.

Cheers,
   Sven

Bug#898771: libconfig-model-dpkg-perl: Please replace Maintainers @lists.alioth.debian.org by @alioth-lists.debian.net

[Andreas Tille]

Package: libconfig-model-dpkg-perl
Severity: normal

Hi,

alioth lists were moved from lists.alioth.debian.org to
@alioth-lists.debian.net.  As far as I understood the maintainers
of alioth-lists.debian.net would prefer the real DNS name instead
of the redirect.  Thus it would be sensible to replace this in the
maintainer fields of packages.

I admit there might be some side effects that one and the same
team will hide behind two addresses for a certain time - so feel
free to discuss this and possibly set wontfix but I wanted to
keep some record at this place.

Kind regards

   Andreas.

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

Kernel: Linux 4.9.0-5-amd64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libconfig-model-dpkg-perl depends on:
ii  libapt-pkg-perl  0.1.32
pn  libarray-intspan-perl
pn  libconfig-model-perl 
pn  libexporter-lite-perl
pn  liblog-log4perl-perl 
pn  libmouse-perl
pn  libparse-recdescent-perl 
ii  libsoftware-license-perl 0.103012-1
pn  libtext-autoformat-perl  
pn  libtext-levenshtein-damerau-perl 
ii  liburi-perl  1.71-1
ii  libwww-perl  6.15-1
pn  libyaml-perl 
pn  licensecheck 
pn  lintian  
ii  perl 5.24.1-3+deb9u3
ii  perl-modules-5.24 [libmodule-corelist-perl]  5.24.1-3+deb9u3

Versions of packages libconfig-model-dpkg-perl recommends:
pn  libconfig-model-tkui-perl  

libconfig-model-dpkg-perl suggests no packages.

Bug#890942: node-evp-bytestokey: autopkgtest (still) broken in experimental

[Steve Langasek]

Package: node-evp-bytestokey
Version: 1.0.3-3
Followup-For: Bug #890942
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Hi Bastian,

It seems that your 1.0.3-3 upload to unstable includes partial fixes for the
autopkgtests (resolving the problems with the test dependencies), but two
other bugs with the autopkgtest that I previously noted here are still
present and the autopkgtests continue to fail:

  https://ci.debian.net/packages/n/node-evp-bytestokey/unstable/amd64/

Attached is an updated patch against 1.0.3-3.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru node-evp-bytestokey-1.0.3/debian/tests/runtestsuite 
node-evp-bytestokey-1.0.3/debian/tests/runtestsuite
--- node-evp-bytestokey-1.0.3/debian/tests/runtestsuite 2018-02-22 
04:18:40.0 -0800
+++ node-evp-bytestokey-1.0.3/debian/tests/runtestsuite 2018-02-22 
07:54:40.0 -0800
@@ -5,7 +5,7 @@
 V=1
 export V
 
-PACKAGE="evp-bytestokey"
+PACKAGE="evp_bytestokey"
 SEDCMD="s,require(['][.][.]/?['],require('$PACKAGE',g"
 
 tmpdir=$(mktemp -d)
@@ -18,7 +18,6 @@
 
 cp -r test "$tmpdir"
 cp binding.gyp "$tmpdir"
-cp -r build "$tmpdir"
 cp package.json "$tmpdir"
 
 

Bug#898757: musescore: crash on startup

[Thorsten Glaser]

severity 898757 normal
tags 898757 + moreinfo
thanks

Hi Rob,

>After displaying the splash screen, Musescore stops

while I understand your frustration this works for others,
so I’m downgrading the severity. I’m even using it on an
i386 system the same as you are.

Please do the following: install gdb-minimal (unless you
already have gdb installed) and musescore-dbgsym, then run
it from the command line as:

$ gdb /usr/bin/musescore
[…]
(gdb) r
[…]

If you then, at the point of crash, get a “(gdb)” prompt
back, type the command “bt” and press Enter.

Please do paste the complete output.

Thanks,
//mirabilos
-- 
15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha
15:48⎜ also warum machen die xorg Jungs eigentlich alles
kaputt? :)15:49⎜ thkoehler: weil sie als Kinder nie den
gebauten Turm selber umschmeissen durften?  -- ~/.Xmodmap wonders…

Bug#898770: arno-iptables-firewall: arno-fwfilter man page should list all available options

[Markus Koschany]

Package: arno-iptables-firewall
Version: 2.0.1.f-1
Severity: normal

Hi,

the man page of arno-fwfilter does not list all available options at
the moment.

The options are:

echo "-h, --help - Print this help"
!!  echo "-r, --no-resolve   - Disable resolving of IPs to names"
echo "-o, --html-output  - Use basic HTML to format the output"
echo "-l, --no-locations - Disable obtaining the IPs geographical location"
echo "-c, --no-colors- Disable the use of (ANSI) colors in the output"
echo "-s, --single-line  - Put all information about an event in a single 
line"

The -r option is missing. Without -r arno-fwfilter can be very slow.

Thanks

Markus

Bug#898769: adduser: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: adduser 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of adduser debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing
list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert


nl.po.gz
Description: application/gzip


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

Bug#898768: gnome-twitch: Segfault everytime you try to watch a stream

[Éter]

Package: gnome-twitch
Version: 0.4.1-2
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

Gnome-twitch segfaults everytime you try to watch a stream because of a change
on twitch API.

Upstream patch: https://github.com/dengelt/gnome-
twitch/commit/54b210db90e9698da57bed9ceb5119c6b6e5b686

Upstream bug report: https://github.com/vinszent/gnome-twitch/issues/356

Regards!



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

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

Versions of packages gnome-twitch depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.28.0-2
ii  libc62.27-3
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.30-1
ii  libjson-glib-1.0-0   1.4.2-4
ii  libpeas-1.0-01.22.0-2
ii  libsoup2.4-1 2.62.2-1
ii  libwebkit2gtk-4.0-37 2.20.2-1+b1
ii  libx11-6 2:1.6.5-1

Versions of packages gnome-twitch recommends:
ii  gnome-twitch-player-backend-gstreamer-cairo0.4.1-2
ii  gnome-twitch-player-backend-gstreamer-clutter  0.4.1-2
ii  gnome-twitch-player-backend-gstreamer-opengl   0.4.1-2
ii  gnome-twitch-player-backend-mpv-opengl 0.4.1-2

gnome-twitch suggests no packages.

-- no debconf information

Bug#845297: Migration to Salsa - reorganization of webmaster-team and repos

[Laura Arjona Reina]

Hello again

I have moved (transferred in gitlab words) some repos.
The current structure is:

https://salsa.debian.org/webmaster-team/
https://salsa.debian.org/webmaster-team/cgi (cgi.debian.org)
https://salsa.debian.org/webmaster-team/cron (cron scripts)
https://salsa.debian.org/webmaster-team/theming_debbugs (theming for
debbugs)
https://salsa.debian.org/webmaster-team/theming_gitweb (theming for gitweb)
https://salsa.debian.org/webmaster-team/theming_ikiwiki (theming for
ikiwiki)
https://salsa.debian.org/webmaster-team/theming_planet (theming for planet)

Note that I removed the empty debwww repo, and renamed the theming repos
so it is more clear for everybody.

I will update the alioth settings of the old repos to refer to their new
location.

I didn't move the test_webwml* repos up, because I missed my own
deadline and other people are working on them. So they are still here:

https://salsa.debian.org/webmaster-team/webwml/test_webwml_cvs2git (test)
https://salsa.debian.org/webmaster-team/webwml/test_webwml (test)

I think we can leave them like this for now, and remove both the test
repos and the webwml subgroup when we do the final migration.

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

Bug#898767: linux-image-4.16.0-1-amd64: (temporary, unreliable) hang on boot since upgrade to 4.16

[Ralf Jung]

Package: src:linux
Version: 4.16.5-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

since the upgrade to kerkenl 4.16, the system does not boot reliably any more.
Instead, most of the time, it hangs showing the following messages:

[2.639465] nouveau :01:00.0: bus: MMIO read of  FAULT at 022554 
[ IBUS ]
[2.645516] nouveau :01:00.0: bus: MMIO read of  FAULT at 10ac08 
[ IBUS ]
[2.719537] i915 :00:02.0: firmware: failed to load 
i915/skl_dmc_ver1_27.bin (-2)
[2.719539] firmware_class: See https://wiki.debian.org/Firmware for 
information about missing firmware

The two nouveau messages are old (they already showed with the 4.15 kernel), but
not so the ones about the firmware.  I have firmware-linux installed.

Sometimes this hang seems to not end (I have waited >30sec) and I have to reset
the machine. Other times (like just now), after a few seconds, the kernel
continues to boot.

Kind regards,
Ralf

-- Package-specific info:
** Version:
Linux version 4.16.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-17)) #1 SMP Debian 4.16.5-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/vmlinuz-4.16.0-1-amd64 root=/dev/mapper/vg-root ro quiet splash

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

** Kernel log:
[   46.673568] iwlwifi :02:00.0: loaded firmware version 31.532993.0 
op_mode iwlmvm
[   46.694233] pstore: Registered efi as persistent store backend
[   46.719185] snd_hda_intel :00:1f.3: bound :00:02.0 (ops 
i915_audio_component_bind_ops [i915])
[   46.719294] input: ThinkPad Extra Buttons as 
/devices/platform/thinkpad_acpi/input/input9
[   46.721032] uvcvideo: Found UVC 1.00 device Integrated Camera (04f2:b52c)
[   46.723565] uvcvideo: Failed to initialize entity for entity 6
[   46.723566] uvcvideo: Failed to register entites (-22).
[   46.723618] input: Integrated Camera: Integrated C as 
/devices/pci:00/:00:14.0/usb1/1-8/1-8:1.0/input/input11
[   46.725324] Bluetooth: Core ver 2.22
[   46.725333] NET: Registered protocol family 31
[   46.725333] Bluetooth: HCI device and connection manager initialized
[   46.725336] Bluetooth: HCI socket layer initialized
[   46.725338] Bluetooth: L2CAP socket layer initialized
[   46.725343] Bluetooth: SCO socket layer initialized
[   46.726976] usbcore: registered new interface driver uvcvideo
[   46.726976] USB Video Class driver (1.1.1)
[   46.730442] iwlwifi :02:00.0: Detected Intel(R) Dual Band Wireless AC 
8260, REV=0x208
[   46.734238] usbcore: registered new interface driver btusb
[   46.734757] Bluetooth: hci0: Bootloader revision 0.0 build 2 week 52 2014
[   46.741784] Bluetooth: hci0: Device revision is 5
[   46.741785] Bluetooth: hci0: Secure boot is enabled
[   46.741786] Bluetooth: hci0: OTP lock is enabled
[   46.741786] Bluetooth: hci0: API lock is enabled
[   46.741787] Bluetooth: hci0: Debug lock is disabled
[   46.741788] Bluetooth: hci0: Minimum firmware build 1 week 10 2014
[   46.741961] intel_rapl: Found RAPL domain package
[   46.741962] intel_rapl: Found RAPL domain core
[   46.741963] intel_rapl: Found RAPL domain uncore
[   46.741964] intel_rapl: Found RAPL domain dram
[   46.744394] bluetooth hci0: firmware: direct-loading firmware 
intel/ibt-11-5.sfi
[   46.744400] Bluetooth: hci0: Found device firmware: intel/ibt-11-5.sfi
[   46.756577] Adding 3903484k swap on /dev/mapper/vg-swap.  Priority:-2 
extents:1 across:3903484k SSFS
[   46.762767] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC298: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   46.762769] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   46.762771] snd_hda_codec_realtek hdaudioC0D0:hp_outs=2 
(0x17/0x21/0x0/0x0/0x0)
[   46.762772] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   46.762773] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   46.762775] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x18
[   46.762776] snd_hda_codec_realtek hdaudioC0D0:  Dock Mic=0x19
[   46.762778] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x12
[   46.805235] iwlwifi :02:00.0: base HW address: e4:a4:71:65:d2:a4
[   46.828321] input: HDA Digital PCBeep as 
/devices/pci:00/:00:1f.3/sound/card0/input12
[   46.829036] input: HDA Intel PCH Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input13
[   46.829866] input: HDA Intel PCH Dock Mic as 
/devices/pci:00/:00:1f.3/sound/card0/input14
[   46.829915] input: HDA Intel PCH Dock Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input15
[   46.830007] input: HDA Intel PCH Headphone as 
/devices/pci:00/:00:1f.3/sound/card0/input16
[   46.881465] ieee80211 phy0: Selected rate control algorithm 'iwl-mvm-rs'
[   46.881627] thermal thermal_zone3: failed to read out thermal zone (-61)
[   46.883846] iwlwifi :02:00.0 wlp2s0: renamed from wlan0
[   47.016727] EXT4-fs (sda2): mounted filesystem with ordered data mode.