Bug#859054: libpam-ssh: Please migrate to openssl1.1 in buster

[Jerome BENOIT]

Thanks for the remainder, I will have a look this week-end,
Jerome

On 19/12/2018 05:32, John Stamp wrote:
> On 05/22/18 08:52 PM, Jerome BENOIT wrote:
>> Hello,
>>
>>
>>
>> On 22/05/18 23:52, Moritz Muehlenhoff wrote:
>>> Hi Jerome,
>>>
>>> On Fri, Oct 13, 2017 at 07:05:26PM +0400, Jerome BENOIT wrote:
 Dear Sebastian, thanks for your warning.

 The amount of change might be too heavy for me.
 Second, pam_ssh seems no more maintained.

 I have just contacted the upstream maintainer.
>>>
>>> Did you get a reply?
>>
>> No.
>>
>> I will have a look if time permit.
>> And, of course, any patch is welcome.
>>
>> Cheers,
>> Jerome
> 
> OpenSUSE has an OpenSSL 1.1 patch in their package:
> 
>   
> https://build.opensuse.org/package/view_file/openSUSE:Factory/pam_ssh/pam_ssh-openssl11.patch
> 
> Changelog here:
> 
>   https://build.opensuse.org/request/show/547009
> 
> I'm attaching the patch.  It will try to modify `configure' which isn't
> in Debian's source tarball, but if you remove that bit, it applies
> cleanly.  It seems to work OK on my locally-built package.
> 
> John
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B



signature.asc
Description: OpenPGP digital signature

Bug#890117: bedtools FTBFS on big endian: Tools failing: bamtobed bamtofastq coverage genomecov groupby intersect jaccard map merge multicov negativecontrol

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/arq5x/bedtools2/issues/676


-- 
http://fam-tille.de

Bug#916827: clamav UTF8 filenames

[Dmitriy Sidorov]

Package: clamav

Version: 0.100.2+dfsg-0+deb9u1

Severity: important

Tags: upstream

 

ClamAV didn’t do correct decode of complex UTF-8 filename from MHTML
container. Debug output

 

LibClamAV debug: rfc2047 returns 'Content-Disposition: attachment;
filename="Пакет документов Ð ´ля оплаты
декабрь  .gz"'

LibClamAV debug: parseMimeHeader: cmd='Content-Disposition', arg='
attachment; filename="Пакет документов Ð ´ля
оплаты декабрь  .gz"'

LibClamAV debug: messageAddArgument, arg='filename="Пакет
документов Ð  ´ля оплаты декабрь  .gz"'

LibClamAV debug: Multipart 0: End of header information

LibClamAV debug: Part 0 has 4108 lines, rc = 1

LibClamAV debug: Mixed message part 0 is of type 1

LibClamAV debug: messageToFileblob

LibClamAV debug: messageExport: numberOfEncTypes == 1

LibClamAV debug: messageExport: enctype 0 is 2

LibClamAV debug: blobSetFilename: "P.P0P:P5Q. P4P>P:Q.PP2 P
4P;Q. P>P?P;P0Q.Q. P4P5P:P0P1Q

LibClamAV debug: fileblobSetFilename: file
_P_P0P_P5Q__P4P_P_Q_P_P5P_Q_P_P2_P_4P_Q__P_P_P_P0Q_Q__P4P5P_P0P1Q saved to
……

 

…..

 

LibClamAV debug: Exported 234078 bytes using enctype 2

LibClamAV debug: 2 trailing bytes to export

LibClamAV debug: base64chars = 2 (@ @ @)

LibClamAV debug:
CDBNAME:CL_TYPE_MHTML:234079:_P_P0P_P5Q__P4P_P_Q_P_P5P_Q_P_P2_P_4P_Q__P_P_P_
P0Q_Q__P4P5P_P0P1Q:234079:234079:0:0:0:(nil)

LibClamAV debug: in cli_magic_scandesc (reclevel: 1/16)

LibClamAV debug: Recognized GZip file

 

Is it bug? Russian UTF8 filename ≪Пакет документов для
оплаты декабрь.gz≫  was decoded as some junk. KOI-8r works
fine.

In email the section header for attachment look like:

 

Content-Type: application/octet-stream; name="=?utf-
8?B?0J/QsNC60LXRgiDQtNC+0LrRg9C80LXQvdGC0L7QsiDQ?=

=?utf-8?B?tNC70Y8g0L7Qv9C70LDRgtGLINC00LXQutCw0LHRgNGM?=

=?utf-8?B?Lmd6?="

Content-Transfer-Encoding: base64

Content-Disposition: attachment; filename="=?utf-
8?B?0J/QsNC60LXRgiDQtNC+0LrRg9C80LXQvdGC0L7QsiDQ?=

=?utf-8?B?tNC70Y8g0L7Qv9C70LDRgtGLINC00LXQutCw0LHRgNGM?=

=?utf-8?B?Lmd6?="

 

 

-- Package-specific info:

--- configuration ---

Checking configuration files in /etc/clamav

 

Config file: clamd.conf

---

BlockMax disabled

PreludeEnable disabled

PreludeAnalyzerName disabled

LogFile = "/var/log/clamav/clamav.log"

LogFileUnlock disabled

LogFileMaxSize = "4294967295"

LogTime = "yes"

LogClean disabled

LogSyslog disabled

LogFacility = "LOG_LOCAL6"

LogVerbose disabled

LogRotate = "yes"

ExtendedDetectionInfo = "yes"

PidFile disabled

TemporaryDirectory disabled

DatabaseDirectory = "/var/lib/clamav"

OfficialDatabaseOnly disabled

LocalSocket = "/var/run/clamav/clamd.ctl"

LocalSocketGroup = "clamav"

LocalSocketMode = "666"

FixStaleSocket = "yes"

TCPSocket disabled

TCPAddr disabled

MaxConnectionQueueLength = "64"

StreamMaxLength = "26214400"

StreamMinPort = "1024"

StreamMaxPort = "2048"

MaxThreads = "64"

ReadTimeout = "300"

CommandReadTimeout = "5"

SendBufTimeout = "200"

MaxQueue = "128"

IdleTimeout = "30"

ExcludePath disabled

MaxDirectoryRecursion = "15"

FollowDirectorySymlinks disabled

FollowFileSymlinks disabled

CrossFilesystems = "yes"

SelfCheck = "3600"

DisableCache disabled

VirusEvent disabled

ExitOnOOM disabled

AllowAllMatchScan = "yes"

Foreground disabled

Debug disabled

LeaveTemporaryFiles disabled

User disabled

Bytecode = "yes"

BytecodeSecurity = "TrustSigned"

BytecodeTimeout = "6"

BytecodeUnsigned disabled

BytecodeMode = "Auto"

DetectPUA = "yes"

ExcludePUA disabled

IncludePUA = "Spy", "Script", "Server"

AlgorithmicDetection = "yes"

ScanPE = "yes"

ScanELF = "yes"

DetectBrokenExecutables disabled

ScanMail = "yes"

ScanPartialMessages disabled

PhishingSignatures = "yes"

PhishingScanURLs = "yes"

PhishingAlwaysBlockCloak disabled

PhishingAlwaysBlockSSLMismatch disabled

PartitionIntersection disabled

HeuristicScanPrecedence disabled

StructuredDataDetection disabled

StructuredMinCreditCardCount = "3"

StructuredMinSSNCount = "3"

StructuredSSNFormatNormal = "yes"

StructuredSSNFormatStripped disabled

ScanHTML = "yes"

ScanOLE2 = "yes"

OLE2BlockMacros disabled

ScanPDF = "yes"

ScanSWF = "yes"

ScanXMLDOCS = "yes"

ScanHWP3 = "yes"

ScanArchive = "yes"

ArchiveBlockEncrypted disabled

ForceToDisk disabled

MaxScanSize = "157286400"

MaxFileSize = "47185920"

MaxRecursion = "8"

MaxFiles = "1"

MaxEmbeddedPE = "20971520"

MaxHTMLNormalize = "15728640"

MaxHTMLNoTags = "2097152"

MaxScriptNormalize = "10485760"

MaxZipTypeRcg = "1048576"

MaxPartitions = "50"

MaxIconsPE = "100"

MaxRecHWP3 = "16"

PCREMatchLimit = "10"

PCRERecMatchLimit = "5000"

PCREMaxFileSize = "26214400"

ScanOnAccess disabled

OnAccessMountPath disabled

OnAccessIncludePath disabled

OnAccessExcludePath disabled

OnAccessExcludeRootUID disabled

OnAccessExcludeUID disabled

OnAccessMaxFileSize = "5242880"

OnAccessDisableDDD disabled

OnAccessPrevention 

Bug#890116: bedtools FTBFS on 32bit: Tools failing: coverage intersect negativecontrol reldist shuffle split

[Andreas Tille]

Control: tags -1 help
Control: tags -1 upstream
Control: forwarded -1 https://github.com/arq5x/bedtools2/issues/675


-- 
http://fam-tille.de

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

[Scott Kitterman]

On December 19, 2018 7:18:42 AM UTC, Paul Wise  wrote:
>On Wed, 19 Dec 2018 01:00:43 +0100 Chris Lamb wrote:
>
>> Nobody is doubting the value here, one just has to square that with
>> the idea that Lintian being too pedantic, noisy or making the wrong
>> priority choices is bad for effectiveness of tool in its entirity. :)
>
>There are only 50 packages affected by this tag, is it really that big
>of a problem for it to be at warning level?
>
>https://lintian.debian.org/tags/appstream-metadata-missing-modalias-provide.html
>
>Downgrading it to info level means that almost no-one will know about
>it, so you might as well just delete the tag instead.
>
>Looking at the package list there are only a few packages where the tag
>might not apply (like zfsutils-linux) and some of the overrides are
>definitely bogus.
>
>The package that Scott maintains that is affected by this tag
>(libnitrokey-common) contains udev rules for a specific set of USB
>devices, so it or another package (like nitrokey-app) definitely needs
>to have the modalias metadata declared so that users can easily find
>software for the Nitrokey and other devices when they plug them in.

I'm not arguing it's a bad idea to have the check, but personally, I get tired 
of looking at it.  If this is important, get it in Policy as a should and then 
I think warning would be appropriate.

Why don't I just fix it?  I read the referenced material on what needs doing 
and concluded I don't have the spare mental cycles to learn all about this for 
one package.

It'd be much more efficient for someone who both understands what needs doing 
and cares to run through the affected packages and submit patches.

In the meantime, I think info is the right level.

Scott K

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

[Paul Wise]

On Wed, 19 Dec 2018 01:00:43 +0100 Chris Lamb wrote:

> Nobody is doubting the value here, one just has to square that with
> the idea that Lintian being too pedantic, noisy or making the wrong
> priority choices is bad for effectiveness of tool in its entirity. :)

There are only 50 packages affected by this tag, is it really that big
of a problem for it to be at warning level?

https://lintian.debian.org/tags/appstream-metadata-missing-modalias-provide.html

Downgrading it to info level means that almost no-one will know about
it, so you might as well just delete the tag instead.

Looking at the package list there are only a few packages where the tag
might not apply (like zfsutils-linux) and some of the overrides are
definitely bogus.

The package that Scott maintains that is affected by this tag
(libnitrokey-common) contains udev rules for a specific set of USB
devices, so it or another package (like nitrokey-app) definitely needs
to have the modalias metadata declared so that users can easily find
software for the Nitrokey and other devices when they plug them in.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Thorsten Glaser]

Howard Chu dixit:

>Thanks to the wonderful geniuses at Microsoft, not all the world
>uses LP64. IL32 is a thing. And this code works on those platforms.

These changes do not break LLP64 (this is the correct name
for the 64-bit Windows model).

>If you're going to submit a patch, submit a correct one. It's that

The buffer size is a separate issue from this. Feel free
to fix it, now that you found it.

The patch I submit fixed your software on systems where
time_t doesn’t fit into a long, all of them, and that
*will* include 64-bit Windows at least in 2038, except
some architectures need these fixes right now. They don’t
break anything else before 2038, and afterwards, nothing
new is broken worsely either.

>simple. If you refuse to do that, then go away.

You know what, I’ll just do that and leave you to fix
your software on your own, clearly you are oh so utterly
competent in doing that.

//mirabilos
-- 
“It is inappropriate to require that a time represented as
 seconds since the Epoch precisely represent the number of
 seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2

Bug#916773: r-base: CRAN packages fail to install.

[Emmanuel Charpentier]

Dear Dirk,

the brute-force appears to be effective for R 3.5.1.

Le mardi 18 décembre 2018 à 15:37 -0600, Dirk Eddelbuettel a écrit :

[ Snip... ]


> > It's more complicated than that. reinstalling rstan, or even Rcpp
> > the
> > rstan, isn't sufficient to install brms.
> 
> There are more C++ parts than rstan and Rcpp. I would try to
> reinstall them.

Finding them all is not trivial : one may (recursively) find brms's
ancestors, but finding the C++ parts is not.

Furthermore, the search for a package's ancestors is not, as far as I
know, in an existing package. It should be written and debugged. To my
(limited) abilities, the brute force approach is faster in terms of
human time (a couple minutes at most). The (impressive) machine time is
less of a concern : I happen to have other fish to fry (e. g.
biological/psychological necessities shch as sleeping)...


> > You did the right thing to file it here:
>   https://github.com/paul-buerkner/brms/issues/573
> Until we know more it should stay there.

This issue has been annotated to point to the present bug.

> BTW there you write 'running as root' -- don't do that. I added
> myself to
> group staff as it is the group on /usr/local/lib/R/site-library.  Now 
> I can
> (and do) runn eg littler's 'install.r' as me.  Been doing that for
> years.

Good idea. I didn't know that group belonging was enough for this. Is
that true also for routine Debian package management ?

> To sum up, if a binary is in Debian itself chances are it gets
> updated when
> it needs to. 

Modulo some Debian delay, which might be not inconsiderable (consider
emacs... and don't get me started on ELPA packages...).

> When we install "outside of the distro package manager" directly
> from CRAN things like this can happen. Maybe it was glibc. Maybe it
> was a
> change in g++.  Maybe it was something else.  Paul was correct in
> pointing to
> CRAN and the positive test results there.  When nothing changes the
> package
> remains happy...

Some "interesting" R packages are not in Debian packaging of CRAN (some
aren't even on CRAN : I had to install some of them in order to
collaborate with Paul Buekner on a paper). So out-of-Debian may be a
(regrettable) necessity...

Cordially yours,

--
Emmanuel Charpentier

Bug#916825: debian-goodies: checkrestart flags dovecot for restart due to deleted dovecot.index files

[Christopher David Howie]

Package: debian-goodies
Version: 0.69.1

Output of checkrestart -v:

--
[DEBUG] Process /usr/lib/dovecot/imap (PID: 26432)
List of deleted files in use:
/var/vmail/chrishowie.com/me/Maildir/dovecot.index (deleted)
--

dovecot.index should probably not cause dovecot to be flagged for restart.

-- 
Chris Howie
http://www.chrishowie.com
http://en.wikipedia.org/wiki/User:Crazycomputers

If you correspond with me on a regular basis, please read this document:
http://www.chrishowie.com/email-preferences/

PGP fingerprint: 2B7A B280 8B12 21CC 260A DF65 6FCE 505A CF83 38F5


IMPORTANT INFORMATION/DISCLAIMER

This document should be read only by those persons to whom it is
addressed.  If you have received this message it was obviously addressed
to you and therefore you can read it.

Additionally, by sending an email to ANY of my addresses or to ANY
mailing lists to which I am subscribed, whether intentionally or
accidentally, you are agreeing that I am "the intended recipient," and
that I may do whatever I wish with the contents of any message received
from you, unless a pre-existing agreement prohibits me from so doing.

This overrides any disclaimer or statement of confidentiality that may
be included on your message.



signature.asc
Description: OpenPGP digital signature

Bug#916510: duplicate

[Buck Huppmann]

On Sat, 15 Dec 2018 09:26:29 +0100 Patrik Kluba  wrote:
> Sorry, just noticed that this report duplicates several other reported bugs.
> But also found a suspected solution elsewhere:
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=108984
> https://bugs.freedesktop.org/show_bug.cgi?id=108850

thanks for finding those

i take it from the commit mentioned in the latter at

https://bugs.freedesktop.org/show_bug.cgi?id=108850#c1

that this is fixed in 4.19

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v4.19=d9d117e40d4ffc03438177eeac83d96dfeee76be

but i have no idea if 4.19 is going to get into testing, which is what
i'm running, before the buster release or if the kernel version has
settled on 4.18

on the other hand, the commit mentioned in this comment

https://bugs.freedesktop.org/show_bug.cgi?id=108850#c6

seems to indicate it fixes the same issue for 4.18.20 but i don't know
how that finds its way into the next stable release thereof, or how
long that would take to make it into testing

anybody know?

Bug#916824: sssd: CVE-2018-16883: Information leak in infopipe due to an improper uid restriction

[Salvatore Bonaccorso]

Source: sssd
Version: 1.16.3-3
Severity: important
Tags: security upstream
Control: found -1 1.15.0-3

Hi,

The following vulnerability was published for sssd.

CVE-2018-16883[0]:
Information leak in infopipe due to an improper uid restriction

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-16883
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-16883
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1659862

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#916134: linux-image-4.18.0-3-amd64: 4.18.0-3 fails to boot, 0-2 works.

[Buck Huppmann]

i've got the same problem, i think, as you and this guy:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916510

Lenovo Thinkpad with "Intel Corporation Core Processor Integrated
Graphics Controller", in my case

Bug#916193: [20181211] ftp.harukasan.org: unreachable

[Jongmin Kim]

Hello,

Our mirror service, ftp.harukasan.org, is now in service.

We're serving following repositories:
  /debian/
  /debian-archive/
  /debian-cd/
  /debian-ports/

Thank you!


On Tue, Dec 11, 2018 at 09:18:01PM +0900, Jongmin Kim wrote:
> On Tue, Dec 11, 2018 at 09:09:13AM +, Peter Palfrader wrote:
> > Hi!
> > 
> > it seems
> > http://ftp.harukasan.org/debian/
> > is unavailable since a few days ago.
> > 
> > https://mirror-master.debian.org/status/mirror-info/ftp.harukasan.org.html
> > 
> > Please investigate.
> 
> 
> Hello,
> 
> Our mirror servce, ftp.harukasan.org, is under maintenance.
> 
> Some repositories are in service, however, Debian-related repos
> (following) are not available until this weekends.
>   /debian/
>   /debian-archive/
>   /debian-cd/
>   /debian-ports/
> 
> I'll send an update when we're back in service.
> 
> Sorry for inconvenience.
> 
> 
> -- 
> Jongmin Kim
> 
> OpenPGP key located at
> https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
> OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8



-- 
Jongmin Kim

OpenPGP key located at
https://jmkim-pgp.github.io/keys/pubkey.D39D8D29BAF36DF8.Jongmin_Kim.asc
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


signature.asc
Description: PGP signature

Bug#916817: transition: remove python3.6

[Matthias Klose]

that's what I used for Ubuntu:

title = "Drop Python3.6 compiled extensions";
is_affected = .build-depends ~ /python3(-all)?-dev|python3|python3.6|python3.7/;
is_good = .depends ~ /python3 \(>= 3\.7\~\)/ | .depends ~ /libpython3\.7/  |
.depends ~ /python3\.7/;
is_bad = .depends ~ /python3 \(>= 3\.6\~\)/ | .depends ~ /libpython3\.6/  |
.depends ~ /python3\.6/;

Bug#874683: fixed in mumble 1.3.0~2868~g44b9004+dfsg-1

[Chris Knadle]

Roland Hieber:
> reopen 874683
> notfixed 874683 1.2.19-3
> found 874683 1.2.19-3
> thanks

Ah.  Very good that works and fixes the graph of fixed and notfixed versions.
Thanks.

  -- Chris

-- 
Chris Knadle
chris.kna...@coredump.us

Bug#863675: libmariadbd-dev: fails to upgrade from 'sid' - trying to overwrite /usr/bin/mysql_config

[Andreas Beckmann]

Followup-For: Bug #863675

And another conflict:

  Preparing to unpack .../libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb ...
  Unpacking libmariadb-dev:amd64 (1:10.3.11-1~exp2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb (--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libmysqlservices.a', which is 
also in package libmysqld-dev 5.7.24-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb


Andreas

Bug#863675: libmariadbd-dev: fails to upgrade from 'sid' - trying to overwrite /usr/bin/mysql_config

[Andreas Beckmann]

Followup-For: Bug #863675
Control: found -1 1:10.3.11-1~exp2

  Preparing to unpack .../libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb ...
  Unpacking libmariadb-dev:amd64 (1:10.3.11-1~exp2) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb (--unpack):
   trying to overwrite '/usr/share/aclocal/mysql.m4', which is also in package 
libmysqlclient-dev 5.7.24-2
  Errors were encountered while processing:
   /var/cache/apt/archives/libmariadb-dev_1%3a10.3.11-1~exp2_amd64.deb

The following files are in both libmysqlclient-dev/sid and 
libmariadb-dev/experimental:

usr/share/aclocal/mysql.m4
usr/share/man/man1/mysql_config.1.gz


Andreas

Bug#916496: xcom-ufo: cannot build package from GOG 2.0.0.4 installer

[Timothy Allen]

On Sat, 2018-12-15 at 11:37 +, Simon McVittie wrote:
> On Sat, 15 Dec 2018 at 15:22:18 +1100, Timothy Allen wrote:
> > I discovered the "game-data-packager make-template" command;
> > attached
> > is the output from:
> > 
> > game-data-packager make-template --base xcom-ufo \
> > setup_xcom_ufo_defense_2.0.0.4.exe
> 
> Does openxcom work if you have the SOUND/ROLAND.CAT from
> setup_xcom_ufo_defense_2.0.0.4.exe instead of the (much smaller) one
> from the current file list, and if you don't have the other files
> listed in "assets not in setup_xcom_ufo_defense_2.0.0.4.exe"?

I extracted the installer with innoextract, and manually copied the
directories listed for Nightly builds in the OpenXcom documentation[1]
to the place where OpenXcom looks, and successfully began a new game
and played a mission. I don't know how exhaustively OpenXcom checks its
datafiles at startup, but it seemed good to me.

I'm not sure how to interpret the "assets not in
setup_xcom_ufo_defense_2.0.0.4.exe" section. For example, it starts off
looking for a file named "GEODATA/BIGLETS.DAT" with an MD5 of 6a2b1...
and it's correct that such a file doesn't exist. The setup file's
BIGLETS.DAT has an MD5 of 9f20e... and the generated manifest maps that
MD5sum to the name "GEODATA/BIGLETS.DAT?orig". In fact, all the "assets
not in setup..." other than ROLAND.CAT are all in the "obsolete" group
with the "?orig" suffix.

[1]: https://www.ufopaedia.org/index.php?title=Installing_(OpenXcom)

> Are any of the other files listed in "remaining contents of
> setup_xcom_ufo_defense_2.0.0.4.exe" required?

If I delete the SOUND/* files and UFOINTRO/* files listed in "remaining
contents..." (other than SOUND/ROLAND.CAT) then OpenXcom still works,
so I guess they're not required.

None of the other "remaining contents..." are mentioned in the OpenXcom
docs, so I guess they're irrelevant.

Bug#916823: libmeep12: missing Breaks+Replaces: libmeep8

[Andreas Beckmann]

Package: libmeep12
Version: 1.7.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'sid' to 'experimental'.
It installed fine in 'sid', then the upgrade to 'experimental' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

>From the attached log (scroll to the bottom...):

  Preparing to unpack .../libmeep12_1.7.0-1_amd64.deb ...
  Unpacking libmeep12 (1.7.0-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/libmeep12_1.7.0-1_amd64.deb (--unpack):
   trying to overwrite '/usr/share/meep/casimir.scm', which is also in package 
libmeep8 1.3-4+b4
  Errors were encountered while processing:
   /var/cache/apt/archives/libmeep12_1.7.0-1_amd64.deb


cheers,

Andreas


libmeep8=1.3-4+b4_libmeep12=1.7.0-1.log.gz
Description: application/gzip

Bug#874683: fixed in mumble 1.3.0~2868~g44b9004+dfsg-1

[Roland Hieber]

reopen 874683
notfixed 874683 1.2.19-3
found 874683 1.2.19-3
thanks

On Mon, Dec 17, 2018 at 12:06:06PM +, Chris Knadle wrote:
> notfixed 874683 1.2.19-3
> thanks
> 
> Roland Hieber:
> > 
> > Hi,
> > 
> > is it correct that this bug is fixed in mumble_1.2.19-3, or was there a
> > mixup in the changelog of that version, as it decends from the 1.3.0
> > changelog?
> > 
> > Cheers,
> > Roland
> 
> Sorry for the confusion.
> To try to help clarify:
> 
> Mumble 1.3.0~2868~g44b9004+dfsg-1 in Debian Experimental is built with Qt 5.
> 
> Mumble 1.2.19-3 in Debian Unstable and Testing can only be built with Qt 4.
> (All Mumble 1.2.x versions can only be built with Qt 4.)  It looks like this 
> bug
> is incorrectly marked as fixed for 1.2.19-3; I'll see if I can change that to
> 'notfixed' via the email interface for the BTS.

It doesn't seem so. I'll try to phrase that a bit more insistently.

Thanks for the clarification!

 - Roland

Bug#859054: libpam-ssh: Please migrate to openssl1.1 in buster

[John Stamp]

On 05/22/18 08:52 PM, Jerome BENOIT wrote:
> Hello,
> 
> 
> 
> On 22/05/18 23:52, Moritz Muehlenhoff wrote:
> > Hi Jerome,
> > 
> > On Fri, Oct 13, 2017 at 07:05:26PM +0400, Jerome BENOIT wrote:
> >> Dear Sebastian, thanks for your warning.
> >>
> >> The amount of change might be too heavy for me.
> >> Second, pam_ssh seems no more maintained.
> >>
> >> I have just contacted the upstream maintainer.
> > 
> > Did you get a reply?
> 
> No.
> 
> I will have a look if time permit.
> And, of course, any patch is welcome.
> 
> Cheers,
> Jerome

OpenSUSE has an OpenSSL 1.1 patch in their package:

  
https://build.opensuse.org/package/view_file/openSUSE:Factory/pam_ssh/pam_ssh-openssl11.patch

Changelog here:

  https://build.opensuse.org/request/show/547009

I'm attaching the patch.  It will try to modify `configure' which isn't
in Debian's source tarball, but if you remove that bit, it applies
cleanly.  It seems to work OK on my locally-built package.

John

===
Index: pam_ssh-2.1/cipher.c
===
--- pam_ssh-2.1.orig/cipher.c	2015-05-03 13:30:39.0 +0200
+++ pam_ssh-2.1/cipher.c	2017-11-30 15:31:05.770390639 +0100
@@ -326,26 +326,26 @@ cipher_init(struct sshcipher_ctx *cc, co
 	return SSH_ERR_INVALID_ARGUMENT;
 #else
 	type = (*cipher->evptype)();
-	EVP_CIPHER_CTX_init(>evp);
-	if (EVP_CipherInit(>evp, type, NULL, (u_char *)iv,
+	cc->evp = EVP_CIPHER_CTX_new();
+	if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv,
 	(do_encrypt == CIPHER_ENCRYPT)) == 0) {
 		ret = SSH_ERR_LIBCRYPTO_ERROR;
 		goto bad;
 	}
 	if (cipher_authlen(cipher) &&
-	!EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_SET_IV_FIXED,
+	!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_SET_IV_FIXED,
 	-1, (u_char *)iv)) {
 		ret = SSH_ERR_LIBCRYPTO_ERROR;
 		goto bad;
 	}
-	klen = EVP_CIPHER_CTX_key_length(>evp);
+	klen = EVP_CIPHER_CTX_key_length(cc->evp);
 	if (klen > 0 && keylen != (u_int)klen) {
-		if (EVP_CIPHER_CTX_set_key_length(>evp, keylen) == 0) {
+		if (EVP_CIPHER_CTX_set_key_length(cc->evp, keylen) == 0) {
 			ret = SSH_ERR_LIBCRYPTO_ERROR;
 			goto bad;
 		}
 	}
-	if (EVP_CipherInit(>evp, NULL, (u_char *)key, NULL, -1) == 0) {
+	if (EVP_CipherInit(cc->evp, NULL, (u_char *)key, NULL, -1) == 0) {
 		ret = SSH_ERR_LIBCRYPTO_ERROR;
 		goto bad;
 	}
@@ -358,14 +358,14 @@ cipher_init(struct sshcipher_ctx *cc, co
 			ret = SSH_ERR_ALLOC_FAIL;
 			goto bad;
 		}
-		ret = EVP_Cipher(>evp, discard, junk, cipher->discard_len);
+		ret = EVP_Cipher(cc->evp, discard, junk, cipher->discard_len);
 		explicit_bzero(discard, cipher->discard_len);
 		free(junk);
 		free(discard);
 		if (ret != 1) {
 			ret = SSH_ERR_LIBCRYPTO_ERROR;
  bad:
-			EVP_CIPHER_CTX_cleanup(>evp);
+			EVP_CIPHER_CTX_cleanup(cc->evp);
 			return ret;
 		}
 	}
@@ -412,33 +412,33 @@ cipher_crypt(struct sshcipher_ctx *cc, u
 		if (authlen != cipher_authlen(cc->cipher))
 			return SSH_ERR_INVALID_ARGUMENT;
 		/* increment IV */
-		if (!EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_IV_GEN,
+		if (!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_IV_GEN,
 		1, lastiv))
 			return SSH_ERR_LIBCRYPTO_ERROR;
 		/* set tag on decyption */
 		if (!cc->encrypt &&
-		!EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_SET_TAG,
+		!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_SET_TAG,
 		authlen, (u_char *)src + aadlen + len))
 			return SSH_ERR_LIBCRYPTO_ERROR;
 	}
 	if (aadlen) {
 		if (authlen &&
-		EVP_Cipher(>evp, NULL, (u_char *)src, aadlen) < 0)
+		EVP_Cipher(cc->evp, NULL, (u_char *)src, aadlen) < 0)
 			return SSH_ERR_LIBCRYPTO_ERROR;
 		memcpy(dest, src, aadlen);
 	}
 	if (len % cc->cipher->block_size)
 		return SSH_ERR_INVALID_ARGUMENT;
-	if (EVP_Cipher(>evp, dest + aadlen, (u_char *)src + aadlen,
+	if (EVP_Cipher(cc->evp, dest + aadlen, (u_char *)src + aadlen,
 	len) < 0)
 		return SSH_ERR_LIBCRYPTO_ERROR;
 	if (authlen) {
 		/* compute tag (on encrypt) or verify tag (on decrypt) */
-		if (EVP_Cipher(>evp, NULL, NULL, 0) < 0)
+		if (EVP_Cipher(cc->evp, NULL, NULL, 0) < 0)
 			return cc->encrypt ?
 			SSH_ERR_LIBCRYPTO_ERROR : SSH_ERR_MAC_INVALID;
 		if (cc->encrypt &&
-		!EVP_CIPHER_CTX_ctrl(>evp, EVP_CTRL_GCM_GET_TAG,
+		!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_GET_TAG,
 		authlen, dest + aadlen + len))
 			return SSH_ERR_LIBCRYPTO_ERROR;
 	}
@@ -471,7 +471,7 @@ cipher_cleanup(struct sshcipher_ctx *cc)
 	else if ((cc->cipher->flags & CFLAG_AESCTR) != 0)
 		explicit_bzero(>ac_ctx, sizeof(cc->ac_ctx));
 #ifdef WITH_OPENSSL
-	else if (EVP_CIPHER_CTX_cleanup(>evp) == 0)
+	else if (EVP_CIPHER_CTX_cleanup(cc->evp) == 0)
 		return SSH_ERR_LIBCRYPTO_ERROR;
 #endif
 	return 0;
@@ -518,7 +518,7 @@ cipher_get_keyiv_len(const struct sshcip
 		ivlen = 0;
 #ifdef WITH_OPENSSL
 	else
-		ivlen = EVP_CIPHER_CTX_iv_length(>evp);
+		ivlen = EVP_CIPHER_CTX_iv_length(cc->evp);
 #endif /* WITH_OPENSSL */
 	return (ivlen);
 }
@@ -544,7 +544,7 @@ 

Bug#916822: installation-reports: A20-OLinuXino-Lime2 Rev. K: Fails to boot installer from SD card

[James Valleroy]

Package: installation-reports
Severity: normal

Dear Maintainer,

I tried to run testing installer on A20-OLinuXino-Lime2 Rev. K board,
and it failed to boot the installer. The same installer image works ok
(with no issues) on a Lime2 Rev. C board.

Serial console log:
---

U-Boot SPL 2018.11+dfsg-1 (Nov 14 2018 - 21:32:35 +)
DRAM: 1024 MiB
CPU: 91200Hz, AXI/AHB/APB: 3/2/2
Trying to boot from MMC1


U-Boot 2018.11+dfsg-1 (Nov 14 2018 - 21:32:35 +) Allwinner Technology

CPU:   Allwinner A20 (SUN7I)
Model: Olimex A20-OLinuXino-LIME2
I2C:   ready
DRAM:  1 GiB


Nothing else was shown on the serial console after this point.


-- Package-specific info:

Boot method: SD card
Image version:
https://get.debian.org/debian/dists/testing/main/installer-armhf/20181206/images/netboot/SD-card-images/
partition.img.gz and firmware.A20-OLinuXino-Lime2.img.gz from 2018-12-05
Date: 2018-12-18

Machine: A20-OLinuXino-Lime2 Rev. K

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [E]
Detect network card:[ ]
Configure network:  [ ]
Detect CD:  [ ]
Load installer modules: [ ]
Clock/timezone setup:   [ ]
User/password setup:[ ]
Detect hard drives: [ ]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]



signature.asc
Description: OpenPGP digital signature

Bug#916821: python-numpy: please drop build-dep on python3.6

[Mattia Rizzolo]

Source: python-numpy
Version: 1:1.15.4-2
Severity: important

In the effort to completely switch to python3.7 for buster, please drop
your direct (build-)dep to python3.6.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#916819: stop using python 3.6

[Mattia Rizzolo]

Source: kdevelop-python
Version: 5.2.4-1

This is going to become RC soon, as we are trying to remove python 3.6.

I see the experimental changelog move to 3.7 with these lines in dch:

  * Update the Python (build) dependencies according to the new supported
version:
- switch the python3.6-dev build dependency to python3.7-dev
- switch the python3.6 dependency to python3.7


I wonder why you can't just use the default python3 version instead of
doing these changes.  At any rate, I urge you to switch over in unstable
as well soon.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#916820: kytos-utils: please drop the build-dep on python3.6

[Mattia Rizzolo]

Source: kytos-utils
Version: 2017.2b1-2
Severity: important
Tags: patch

We are going to remove python3.6 soon, so please remove the build-dep.
apparently it's totally unneeded, so just removing it will do.

Accordingly, this bug will become RC in a few weeks.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#916285: RFS: extsmail/2.2-1 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

On Thu, 13 Dec 2018 16:15:40 +0100 Adam Borowski 
wrote:
> Alas, it doesn't build:  http://ix.io/1vVp
> 
> common.c:37:10: fatal error: conf_parser.tab.h: No such file or directory
>  #include "conf_parser.tab.h"
>   ^~~
> 
> (I didn't review further.)

Hi Adam,

(...)
dh_auto_build: make V=1 -j6 returned exit code 2

It's a parallel build issue, most likely due to missing Makefile
dependencies, upstream is aware of this.

It compiles fine with 4 cores, more may produce bugs.

Thanks,

--
Olivier



signature.asc
Description: OpenPGP digital signature

Bug#916285: RFS: extsmail/2.2-1 -- enables the robust sending of e-mail to external commands

[Olivier Girondel]

On Thu, 13 Dec 2018 23:47:00 + Dmitry Bogatov 
wrote:
> 
> [2018-12-12 17:38] Olivier Girondel 
> > Severity: normal
> > 
> >   Dear mentors,
> > 
> >   I am looking for a sponsor for my package "extsmail"
> > 
> >  * Package name: extsmail
> >Version : 2.2-1
> >Upstream Author : Laurence Tratt 
> >  * URL : https://tratt.net/laurie/src/extsmail/
> >  * License : BSD/MIT
> >Section : mail
> > 
> >   It builds this binary package:
> > 
> > extsmail   - enables the robust sending of e-mail to external commands
> > 
> >   The package appears to be lintian-clean
> > 
> >   To access further information about this package, please visit the
> > following URL:
> > 
> >   https://mentors.debian.net/package/extsmail
> 
> Seems you have Vcs-* fields in `debian/control' wrong. They must point
> to debianization Git, not to upstream Git.

Hi Dmitry,

I use this repository to host the debian/ directory usesd to build the
package: https://github.com/oliv3/extsmail-debian

Is this url correct/enough to replace the current Vcs-Git url ?
Or should I just drop Vcs-Git ?

Thanks,

--
Olivier



signature.asc
Description: OpenPGP digital signature

Bug#916818: rustc: Compiler regression results in generated code with unaligned access

[John Paul Adrian Glaubitz]

Source: rustc
Version: 1.31.0+dfsg1-2
Severity: normal
Tags: upstream
User: debian-sp...@lists.debian.org
Usertags: sparc64

Hi!

The build of rustc fails on sparc64 due to a compiler regression with multiple
bus errors meaning that an unaligned access has occurred [1].

The upstream commit which introduced the regression can be found in [2]. It can
simply be reverted for 1.31.0 to fix the problem. I have reported the issue
upstream as [3].

Adrian

> [1] 
> https://buildd.debian.org/status/fetch.php?pkg=rustc=sparc64=1.31.0%2Bdfsg1-2=1545047706=0
> [2] https://github.com/rust-lang/rust/pull/54547
> [3] https://github.com/rust-lang/rust/issues/56927

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#890680: [Reportbug-maint] Bug#890680: reportbug: python3-reportbug submodules are not well documented

[Nis Martensen]

Hey Sandro,

There has been no feedback on the docstrings in the last 10 months. I'm
sure dumping everything in a large MR was a bad idea to try to get this
going...

So how can we make this more review-friendly?

I'm planning to submit the changes step by step again over the next few
weeks/months. Each MR will be limited to just a few functions from a
single submodule, and accompanied by improvements to the test suite
(concerning the same functions).

Step 1:
https://salsa.debian.org/reportbug-team/reportbug/merge_requests/11

Is this better? What would be the ideal MR strategy from your
perspective? What do you think?



On 21/02/2018 23.17, Nis Martensen wrote:
> On 20-02-2018 06:02, Sandro Tosi wrote:
>> On Sun, Feb 18, 2018 at 5:03 AM, Nis Martensen  wrote:
>>> Extending the test suite is actually the goal here. It's just hard to
>>> add tests for functions of which you don't know what they're supposed to
>>> do exactly. So reading the code and taking notes is the first step.
>>
>> oh great to hear we're one the same page on that! :)
> 
> I doubt it's going to be easy, though - many bugs are like
> "proxy-related command line options don't work well" or "does not
> interact nicely with my mua" or "crashes when user's homedir does not
> exist".  Not sure how those can be covered with unit tests. But let's go
> step by step to figure out what's possible.
> 
> 
>> i was more thinking of tools external to debian, like scripts from
>> operators using those functions
> 
> Hm. Are you aware of people having done that? Would the switch from py2
> to py3 not already have broken such tools?
> 
> 
>>> Are you planning to move reportbug to salsa in the future?  It might
>>> make this kind of review easier.
>>
>> i just did and migrated reportbug to
>> https://salsa.debian.org/reportbug-team/reportbug - wanna try the
>> merge request thing ah! :)
> 
> Here you go:
> https://salsa.debian.org/reportbug-team/reportbug/merge_requests/1
> 

Bug#916817: transition: remove python3.6

[Mattia Rizzolo]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: transition

Hi,

We would like to go ahead with removing python3.6 from the supported
python3 versions.

I don't think we are ready yet, but I'm filing this bug for tracking
purposes.

I'd also welcome if somebody could come up with a ben tracker.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#914112: galera-3 FTBFS: error: no matching function for call to 'asio::ssl::context::context(asio::io_service&, asio::ssl::context_base::method)'

[Logan Rosen]

Control: tags -1 patch

Dear Maintainer,

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: Use bundled asio, since system asio is too new (> 1.10.8).
  * debian/control: Remove build-dependency of libasio-dev (for now).

Thanks for considering the patch.

Logan

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

Kernel: Linux 4.18.0-12-generic (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru galera-3-25.3.24/debian/control galera-3-25.3.24/debian/control
--- galera-3-25.3.24/debian/control 2018-10-15 09:23:16.0 -0400
+++ galera-3-25.3.24/debian/control 2018-11-17 20:37:31.0 -0500
@@ -6,7 +6,6 @@
 Standards-Version: 4.2.1
 Build-Depends: check,
debhelper (>= 9.20151219~),
-   libasio-dev,
libboost-dev (>= 1.41),
libboost-program-options-dev (>= 1.41),
libssl-dev,
diff -Nru galera-3-25.3.24/debian/rules galera-3-25.3.24/debian/rules
--- galera-3-25.3.24/debian/rules   2018-10-15 04:27:36.0 -0400
+++ galera-3-25.3.24/debian/rules   2018-11-17 20:36:49.0 -0500
@@ -3,6 +3,9 @@
 DPKG_EXPORT_BUILDFLAGS = 1
 include /usr/share/dpkg/default.mk
 
+# Use bundled asio, since system asio is too new (> 1.10.8)
+SCONS_ARGS += system_asio=0
+
 # Parallel build support as adviced
 # at 
https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules-options
 ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))

Bug#574950: fixed in bash-completion 1:2.1-3

[Gabriel F. T. Gomes]

On Wed, 19 Mar 2014 11:03:30 + David Paleino  wrote:
> Source: bash-completion
> Source-Version: 1:2.1-3
> 
> We believe that the bug you reported is fixed in the latest version of
> bash-completion, which is due to be installed in the Debian FTP archive.
>
> [...]
>
>  - disable_avahi_browse.patch: slow, and doesn't scale to big
>networks, thanks to Chris Jones (Closes: #574950, LP: #510591)

I'm removing this patch from Debian [1], because completion with
avahi-browse was never enabled by default (in order to enable it, one
has to set the COMP_KNOWN_HOSTS_WITH_HOSTFILE environment variable, as
described in the documentation [2]), so the patch is only making it
impossible for people who actually want to complete with avahi-browse
to enabled it.

If this starts to cause trouble to people again, then we'll have to
investigate what is actually going on.

Kind regards,
Gabriel

[1] 
https://salsa.debian.org/debian/bash-completion/commit/872a16c290d2798a0abfe1c2f135b34c71cd1e5f
[2] 
https://github.com/scop/bash-completion/blob/master/doc/bash_completion.txt#L49-L55

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Howard Chu]

Thorsten Glaser wrote:
> Howard Chu dixit:
> 
>> This patch of yours *introduces a bug*. If you wanted to actually *fix*
>> something you should have made sure the malloc'd buffer - which only happens
>> 2 lines above the lines you change - was large enough to store a long long.
> 
> That’s not a new bug, then.

> That’s a completely separate Y2038 issue of *yours* that
> will happen on all platforms, and has nothing to do with
> long vs. long long, since a long on an LP64 platform *is*
> already as wide as a long long.

Thanks to the wonderful geniuses at Microsoft, not all the world
uses LP64. IL32 is a thing. And this code works on those platforms.
Far more machines than have ever or ever will run X32. If you want
patches for your obscure system adopted, you have to make sure not
to break anything else.

> In addition to that, use of snprintf will prevent this
> from being worse than a mere truncation.

If you're going to submit a patch, submit a correct one. It's that simple.
If you refuse to do that, then go away.

-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Bug#916816: firmware-amd-graphics: AMDGPU lacks recent firmwares fro 4.19 based kernel, not usable.

[Kyuma Ohta]

Package: firmware-amd-graphics
Version: 20180825+dfsg-1
Severity: important

Dear Maintainer,

At head of December, firmwares for AMDGPU were updated at upstream repositry.
And, recent linux 4.19 based kernel using these, not using older firmware.
So, Deb's 4.19.0-1-amd64 kernel makes freeze screen at change to EFIFB
to AMDGPU DRIFB at booting sequence with below log (at RADEON RX560 based 
graphic board):
---
Dec 18 14:48:21 melchior kernel: [3.049376] amdgpu :09:00.0: No more 
image in the PCI ROM
Dec 18 14:48:21 melchior kernel: [3.049393] ATOM BIOS: 113-C9812101_100
Dec 18 14:48:21 melchior kernel: [3.049417] [drm] vm size is 64GB, 2 
levels, block size is 10-bit, fragment size is 9-bit
Dec 18 14:48:21 melchior kernel: [3.049431] amdgpu :09:00.0: firmware: 
failed to load amdgpu/polaris11_k_mc.bin (-2)
Dec 18 14:48:21 melchior kernel: [3.049433] firmware_class: See 
https://wiki.debian.org/Firmware for information about missing firmwar
e
Dec 18 14:48:21 melchior kernel: [3.049436] amdgpu :09:00.0: Direct 
firmware load for amdgpu/polaris11_k_mc.bin failed with error 
-2
Dec 18 14:48:21 melchior kernel: [3.049438] mc: Failed to load firmware 
"amdgpu/polaris11_k_mc.bin"
Dec 18 14:48:21 melchior kernel: [3.049490] [drm:gmc_v8_0_sw_init [amdgpu]] 
*ERROR* Failed to load mc firmware!
Dec 18 14:48:21 melchior kernel: [3.049536]
[drm:amdgpu_device_init.cold.28 [amdgpu]] *ERROR* sw_init of IP block 
 failed -2
Dec 18 14:48:21 melchior kernel: [3.049539] amdgpu :09:00.0: 
amdgpu_device_ip_init failed
Dec 18 14:48:21 melchior kernel: [3.049541] amdgpu :09:00.0: Fatal 
error during GPU init
Dec 18 14:48:21 melchior kernel: [3.049543] [drm] amdgpu: finishing device.
Dec 18 14:48:21 melchior kernel: [3.049637] amdgpu: probe of :09:00.0 
failed with error -2
---
Another part of kernel (and systemd) works seem to fine,but screen
freezes.
Please update firmwares to this package.

Regards,
Ohta.

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/12 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to ja_JP.UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to ja_JP.UTF-8 shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

fi rmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.132

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/firmware/amdgpu/carrizo_ce.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/carrizo_me.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/carrizo_mec.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/carrizo_mec2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/carrizo_pfp.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/fiji_vce.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_k_smc.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_mc.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_mec2_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_mec_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_pfp_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_smc.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris10_smc_sk.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris11_mec2_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris11_mec_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris11_pfp_2.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/polaris11_smc_sk.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/raven_asd.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/raven_rlc.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/raven_sdma.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/tonga_ce.bin (from 
firmware-amd-graphics package)
debsums: changed file /lib/firmware/amdgpu/tonga_me.bin (from 
firmware-amd-graphics package)
debsums: changed file 

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Thorsten Glaser]

Howard Chu dixit:

>This patch of yours *introduces a bug*. If you wanted to actually *fix*
>something you should have made sure the malloc'd buffer - which only happens
>2 lines above the lines you change - was large enough to store a long long.

That’s not a new bug, then.

That’s a completely separate Y2038 issue of *yours* that
will happen on all platforms, and has nothing to do with
long vs. long long, since a long on an LP64 platform *is*
already as wide as a long long.

In addition to that, use of snprintf will prevent this
from being worse than a mere truncation.

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.   -- Andreas Bogk über boehm-gc in d.a.s.r

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Howard Chu]

Thorsten Glaser wrote:
> I know my way *very* well around the time_t issue because
> I’ve been having them on MirBSD/i386 years before x32 even
> existed, and am experienced in how to fix them.

>From here it only looks like you're experienced in how to break things.

This patch of yours *introduces a bug*. If you wanted to actually *fix*
something you should have made sure the malloc'd buffer - which only happens
2 lines above the lines you change - was large enough to store a long long.

That's just plain sloppy. It's as careless as submitting a patch to
fix a no-op, and just wasting my time.

+--- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
 b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
+@@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd(
+   keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+   keys[0].bv_len = snprintf(keys[0].bv_val,
+   LDAP_PVT_INTTYPE_CHARS(long),
+-  "%ld", slap_get_time());
++  "%lld", (long long)slap_get_time());
+   BER_BVZERO( [1] );
+
+   ml->sml_desc = ad_sambaPwdLastSet;
+@@ -627,7 +627,7 @@ static int smbk5pwd_exop_passwd(
+   keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+   keys[0].bv_len = snprintf(keys[0].bv_val,
+   LDAP_PVT_INTTYPE_CHARS(long),
+-  "%ld", slap_get_time() + pi->smb_must_change);
++  "%lld", (long long)slap_get_time() + (long 
long)pi->smb_must_change);
+   BER_BVZERO( [1] );
+
+   ml->sml_desc = ad_sambaPwdMustChange;
+@@ -650,7 +650,7 @@ static int smbk5pwd_exop_passwd(
+   keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
+   keys[0].bv_len = snprintf(keys[0].bv_val,
+   LDAP_PVT_INTTYPE_CHARS(long),
+-  "%ld", slap_get_time() + pi->smb_can_change);
++  "%lld", (long long)slap_get_time() + (long 
long)pi->smb_can_change);
+   BER_BVZERO( [1] );
+
+   ml->sml_desc = ad_sambaPwdCanChange;




-- 
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Bug#916735: lintian: appstream-metadata-missing-modalias-provide should be info, not warn

[Chris Lamb]

Petter Reinholdtsen wrote:

> For this to work well, the appstream modalias data set need to be up
> to date, complete and correct.

Nobody is doubting the value here, one just has to square that with
the idea that Lintian being too pedantic, noisy or making the wrong
priority choices is bad for effectiveness of tool in its entirity. :)


Best wishes,

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

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Dominik George]

>> We had volatile, which, redefined properly, could help. I am trying
>to draft such a definition.
>
>Did you get a chance to work on it?

I do have this on my todo list for around Christmas.

People who know me that I deliberately leave out the year, but my intentions 
are 2018 ;).

-nik

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Aurelien Jarno]

On 2018-12-18 22:11, Aurelien Jarno wrote:
> On 2018-12-18 21:34, Aurelien Jarno wrote:
> > Hi,
> > 
> > On 2018-12-18 15:15, Tim Ruehsen wrote:
> > > Package: libc6-armhf-cross
> > > Version: 2.28-2cross2
> > > Severity: normal
> > > 
> > > Dear Maintainer,
> > > 
> > > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > > 
> > > The expected errno value would be either EINVAL or not touching errno
> > > at all.
> > > 
> > > This behavior is relatively new and causes some CI cross builds to fail.
> > > The failing test is a gnulib test (test-strerror.c).
> > > 
> > 
> > I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> > qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> > hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> > think it's a qemu bug.
> 
> Hmm, I am wrong, I can actually reproduce it with qemu-user-static
> version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

It seems to have been caused by this upstream patch:

| commit 1294b1892e19d70e9e4dca0a2f3e39497f262a42
| Author: Wilco Dijkstra 
| Date:   Thu Mar 15 17:57:03 2018 +
| 
| Add support for sqrt asm redirects
| 
| This patch series cleans up the many uses of  __ieee754_sqrt(f/l) in 
GLIBC.
| The goal is to enable GCC to do the inlining, and if this fails call the
| __ieee754_sqrt function.  This is done by internally declaring sqrt with 
asm
| redirects.  The compat symbols and sqrt wrappers need to disable the 
redirect.
| The redirect is also disabled if there are already redirects defined when
| using -ffinite-math-only.
| 
| All math functions (but not math tests, non-library code and libnldbl) are
| built with -fno-math-errno which means GCC will typically inline sqrt as a
| single instruction.  This means targets are no longer forced to add a 
special
| inline for sqrt.
| 
| * include/math.h (sqrt): Declare with asm redirect.
| (sqrtf): Likewise.
| (sqrtl): Likewise.
| (sqrtf128): Likewise.
| * Makeconfig: Add -fno-math-errno for libc/libm, but build 
testsuite,
| nonlib and libnldbl with -fmath-errno.
| * math/w_sqrt_compat.c: Define NO_MATH_REDIRECT.
| * math/w_sqrt_template.c: Likewise.
| * math/w_sqrtf_compat.c: Likewise.
| * math/w_sqrtl_compat.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt.c: Likewise.
| * sysdeps/i386/fpu/w_sqrt_compat.c: Likewise.
| * sysdeps/generic/math-type-macros-float128.h: Remove math.h and
| complex.h.

And more precisely by building libc with -fno-math-errno.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Thorsten Glaser]

Howard Chu dixit:

>You might have correctly identified a Y2038 issue. You certainly have not
>written a correct fix for it.

Please drop this condescending attitude.

I may or may not have discovered a Y2038 issue, but I do know
for sure I’ve correctly fixed a problem on all architectures
in which a time_t does not fit into a long.

Consider this:

#ifdef TEST1
typedef long foo_t;
#else
typedef long long foo_t;
#endif
foo_t bla = 1L;
printf("%ld, %ld\n", bla, 2L);

This is _supposed_ to display “1, 2” but will display “1, 0”
on little endian platforms (big endian being worse off).

I know my way *very* well around the time_t issue because
I’ve been having them on MirBSD/i386 years before x32 even
existed, and am experienced in how to fix them.

bye,
//mirabilos
-- 
16:47⎜«mika:#grml» .oO(mira ist einfach gut)  23:22⎜«mikap:#grml»
mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich
finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann
gleich mal auf usb-stick installieren   -- Michael Prokop über MirOS bsd4grml

Bug#916815: Please make fabric package available also for python3

[Yaroslav Halchenko]

Package: fabric
Version: 1.14.0-1
Severity: normal

Although fabric is known as a cmdline tool, it is also a Python package which
provides useful public interfaces.  ATM there is only fabric package, which
contains fabric python module made available only for python2.7.  Ideally there
could be python{2,3}-fabric or approach taken e.g. by patool could be used to
just ship both python2 and python3 packages within the same package.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (600, 'unstable'), (300, 'experimental'), (100, 
'unstable-debug'), (100, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.17.0-1-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)
LSM: AppArmor: enabled

Versions of packages fabric depends on:
ii  libjs-sphinxdoc   1.7.7-1
ii  python2.7.14-4
ii  python-crypto 2.6.1-8
ii  python-paramiko   2.4.0-1
ii  python-pkg-resources  38.5.2-1

fabric recommends no packages.

fabric suggests no packages.

-- debconf-show failed

Bug#916695: grub-efi-arm 2.02+dfsg1-9 fails to boot Debian Buster

[Vagrant Cascadian]

On 2018-12-19, Heinrich Schuchardt wrote:
> I have reinstalled grub-efi-arm 2.02+dfsg1-9.
...
> What it takes is a U-Boot v2018.11 with these additional patches:
>
> * Revert "efi_loader: remove efi_exit_caches()"
> * efi_loader: Ensure memory allocations are page aligned

The above two appear present in u-boot 2019.01-rc2, which I hope to
upload soon.


> * lib: crc32: mark static variable as __efi_runtime_data
>   (not relevant for Tinker Board)

This one doesn't.

Tinker is also not present in Debian's u-boot packages, FWIW.


live well,
  vagrant

Bug#916814: cacti: [1.2.0 Beta 4] Spike Kill not working (missing file)

[jay.slovak]

Package: cacti
Version: 1.2.0~beta4+ds1-1
Severity: normal

Dear Maintainer,

Spike Kill functionality is not working. Clicking on dry run generates an error 
message "Could not open input file: /usr/share/cacti/site/cli/removespikes.php".

Problem was reported upstream, but they have suggested this is a packaging bug 
https://github.com/Cacti/cacti/issues/2218

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

Kernel: Linux 4.16.0-2-amd64 (SMP w/2 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 cacti depends on:
ii  dbconfig-common   2.0.11
ii  dbconfig-mysql2.0.11
ii  debconf [debconf-2.0] 1.5.69
ii  fonts-dejavu-core 2.37-1
ii  fonts-dejavu-extra2.37-1
ii  fonts-font-awesome5.0.10+really4.7.0~dfsg-1
ii  javascript-common 11
ii  libapache2-mod-php2:7.3+68
ii  libapache2-mod-php7.3 [libapache2-mod-ph  7.3.0-1
ii  libjs-c3  0.4.11+dfsg-2
ii  libjs-chartjs 1.0.2-1
ii  libjs-d3  3.5.17-2
ii  libjs-jquery  3.2.1-1
ii  libjs-jquery-colorpicker  1.2.17-1
ii  libjs-jquery-cookie   12-1.1
ii  libjs-jquery-hotkeys  0~20130707+git2d51e3a9+dfsg-2
ii  libjs-jquery-jstree   3.3.7+dfsg1-1
ii  libjs-jquery-metadata 12-1.1
ii  libjs-jquery-tablesorter  1:2.31.1+dfsg1-1
ii  libjs-jquery-timepicker   1.2-1
ii  libjs-jquery-ui   1.12.1+dfsg-5
ii  libjs-jquery-ui-theme-smoothness  1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-south-street1.12.1+dfsg-1
ii  libjs-jquery-ui-theme-ui-darkness 1.12.1+dfsg-1
ii  libjs-jquery-ui-touch-punch   0.0~git20141218.2.4bc0091+dfsg1-2
ii  libphp-phpmailer  5.2.14+dfsg-2.4
ii  perl  5.28.1-3
ii  php-gd2:7.3+68
ii  php-ldap  2:7.3+68
ii  php-mbstring  2:7.3+68
ii  php-mysql 2:7.3+68
ii  php-php-gettext   1.0.12-0.1
ii  php-phpseclib 2.0.12-1
ii  php-snmp  2:7.3+68
ii  php-twig  2.5.0-1
ii  php-xml   2:7.3+68
ii  php7.3-cli [php-cli]  7.3.0-1
ii  php7.3-gd [php-gd]7.3.0-1
ii  php7.3-json [php-json]7.3.0-1
ii  php7.3-ldap [php-ldap]7.3.0-1
ii  php7.3-mbstring [php-mbstring]7.3.0-1
ii  php7.3-snmp [php-snmp]7.3.0-1
ii  php7.3-xml [php-xml]  7.3.0-1
ii  rrdtool   1.7.0-1+b3
ii  snmp  5.7.3+dfsg-4+b1
ii  ucf   3.0038

Versions of packages cacti recommends:
ii  apache2 [httpd] 2.4.37-1
ii  default-mysql-server1.0.4
ii  iputils-ping3:20180629-2
ii  logrotate   3.14.0-4
ii  mariadb-server-10.1 [virtual-mysql-server]  1:10.1.37-3
ii  php-gmp 2:7.3+68
ii  php7.3-gmp [php-gmp]7.3.0-1

Versions of packages cacti suggests:
pn  cacti-spine  
pn  moreutils
pn  snmpd

-- debconf information excluded

Bug#905237: Fwd: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Thorsten Glaser]

-- Forwarded message --
From: Howard Chu 
Message-ID: 
Date: Tue, 18 Dec 2018 23:02:49 +
Subject: Re: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

t...@debian.org wrote:
> Full_Name: mirabilos
> Version: 2.4.46
> OS: Debian
> URL: 
> Submission from: (NULL) (2a01:4f8:150:946c::42:3)
> 
> 
> I’ve just managed to unbreak the build of openldap on x32
> (basically amd64ilp32: a 64-bit x86 architecture using 32-bit
> “long” and pointers) by fixing a couple of simple GCC warnings.
> 
> Original bugreport: https://bugs.debian.org/905237
> 
> Please find the attached patches (pretty machinal, so not
> copyright-relevant) and include them in your next release.
> Thanks!
> 
> --- a/clients/tools/common.c
> +++ b/clients/tools/common.c
> @@ -2326,7 +2326,7 @@ void tool_print_ctrls(
>   /* known controls */
>   for ( j = 0; tool_ctrl_response[j].oid != NULL; j++ ) {
>   if ( strcmp( tool_ctrl_response[j].oid, 
> ctrls[i]->ldctl_oid ) == 0 ) {
> - if ( !tool_ctrl_response[j].mask & tool_type ) {
> + if ( !(tool_ctrl_response[j].mask & tool_type) 
> ) {
>   /* this control should not appear
>* with this tool; warning? */
>   }

This is patching an if statement with an empty body - it is a pure no-op that
the compiler will optimize away. There's no point in changing this other than
to shut up stupid static analyzer tools. But since you're not the first person
to run a stupid static analyzer tool and point this out, I've merged this "fix."

The following 3 patches are valid and have been merged.
> --- a/servers/slapd/backend.c
> +++ b/servers/slapd/backend.c
> @@ -1500,7 +1500,7 @@ fe_acl_group(
>* or if filter parsing fails.
>* In the latter case,
>* we should give up. */
> - if ( ludp->lud_filter != NULL && 
> ludp->lud_filter != '\0') {
> + if ( ludp->lud_filter != NULL && 
> ludp->lud_filter[0] != '\0') {
>   filter = str2filter_x( op, 
> ludp->lud_filter );
>   if ( filter == NULL ) {
>   /* give up... */
> --- a/servers/slapd/overlays/constraint.c
> +++ b/servers/slapd/overlays/constraint.c
> @@ -446,7 +446,7 @@ constraint_cf_gen( ConfigArgs *c )
>   }
>  
>   if ( ap.restrict_lud->lud_attrs 
> != NULL ) {
> - if ( 
> ap.restrict_lud->lud_attrs[0] != '\0' ) {
> + if ( 
> ap.restrict_lud->lud_attrs[0] != NULL ) {
>   snprintf( 
> c->cr_msg, sizeof( c->cr_msg ),
>   "%s %s: 
> attrs not allowed in restrict URI %s\n",
>   
> c->argv[0], c->argv[1], arg);
> --- a/servers/slapd/syntax.c
> +++ b/servers/slapd/syntax.c
> @@ -219,8 +219,8 @@ syn_add(
>   }
>  
>   assert( (*lsei)->lsei_values != NULL );
> - if ( (*lsei)->lsei_values[0] == '\0'
> - || (*lsei)->lsei_values[1] != '\0' )
> + if ( (*lsei)->lsei_values[0] == NULL
> + || (*lsei)->lsei_values[1] != NULL )
>   {
>   Debug( LDAP_DEBUG_ANY, "syn_add(%s): exactly 
> one substitute syntax must be
> present\n",
>   ssyn->ssyn_syn.syn_oid, 0, 0 );

This chunk no longer exists in the repo, so it's been omitted.
> --- a/tests/progs/slapd-addel.c
> +++ b/tests/progs/slapd-addel.c
> @@ -173,7 +173,7 @@ main( int argc, char **argv )
>  
>   }
>  
> - if (( attrs == NULL ) || ( *attrs == '\0' )) {
> + if (( attrs == NULL ) || ( *attrs == NULL )) {
>  
>   fprintf( stderr, "%s: invalid attrs in file \"%s\".\n",
>   argv[0], filename );

This patch is trying to cast to a long long and print the result into a buffer
that is explicitly sized for a long. That's clearly a bug. The remaining format
patches for debug statements will have no impact on the correctness of
execution or output. This and all of the following patches are being rejected.
> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd(
>   keys[0].bv_val = ch_malloc( 

Bug#905237: (ITS#8890) Bug fix patches unbreaking the build on x32 systems

[Thorsten Glaser]

Howard Chu dixit:

>The remaining format patches for debug statements will have no impact
>on the correctness of execution or output. This and all of the
>following patches are being rejected.

There are multiple systems on which sizeof(time_t) > sizeof(long),
with more expected as 2038 dawns.

Are you saying you want to prohibit users on these platforms from
debugging OpenLDAP?

>> --- a/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
>> +++ b/contrib/slapd-modules/smbk5pwd/smbk5pwd.c
>> @@ -605,7 +605,7 @@ static int smbk5pwd_exop_passwd(
>>  keys[0].bv_val = ch_malloc( LDAP_PVT_INTTYPE_CHARS(long) );
>>  keys[0].bv_len = snprintf(keys[0].bv_val,
>>  LDAP_PVT_INTTYPE_CHARS(long),
>> -"%ld", slap_get_time());
>> +"%lld", (long long)slap_get_time());
>>  BER_BVZERO( [1] );

This doesn’t look like debugging output to me.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general

Bug#544651: lvm2: lvm issues warnings about not finding volumes, on a system with LUKS encryption + lvm

[Smo Oey]

Went into console at partman part of minimal iso installer... did
fdisk and was setting everything up with fdisk and went to do command:
cryptsetup luksFormat /dev/sda2 and oops, error... cryptsetup command
not found. Is there anything in debian that works for this stuff? lol
Or should I use gparted, or cfdisk, or something else?

Bug#916695: grub-efi-arm 2.02+dfsg1-9 fails to boot Debian Buster

[Heinrich Schuchardt]

I have reinstalled grub-efi-arm 2.02+dfsg1-9.

With my current U-Boot and a custom built the 4.18.20 kernel I am able
to boot.

The stock Debian kernel does not boot.

What it takes is a U-Boot v2018.11 with these additional patches:

* Revert "efi_loader: remove efi_exit_caches()"
* efi_loader: Ensure memory allocations are page aligned
* lib: crc32: mark static variable as __efi_runtime_data
  (not relevant for Tinker Board)

and a kernel with Ard's patch

43b2ceb0d4e0147b114cb1d0112a988cbb81ecbc
efi/arm: Revert deferred unmap of early memmap mapping

This patch is available since Linux v4.19.6.

Best regards

Heinrich

Bug#916768: libelogind-dev-doc: missing Breaks+Replaces: libelogind-dev (<< 239.1+20181115-1)

[Mark Hindley]

Package: libelogind-dev-doc
Tags: pending

On Tue, Dec 18, 2018 at 01:21:47PM +0100, Andreas Beckmann wrote:
> Package: libelogind-dev-doc
> Version: 239.3-3+debian1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'testing'.
> It installed fine in 'testing', then the upgrade to 'sid' fails
> because it tries to overwrite other packages files without declaring a
> Breaks+Replaces relation.

Andreas,

Many thanks. I have queued a fix for this.

> PS: please use a normal debian revision in the version, i.e. only number

This is deliberate: Devuan is the defacto packaging upstream for these packages
and therefore has the plain number only revision. We need to distinguish the
versions that include the Debian specific packaging.

Mark

Bug#908632: linux-image-4.19.0-rc3-amd64-unsigned: kernel 4.19 fails to load amdgpu driver on R9 270X.

[aguilar . sanchez . antonio]

Hi!

This also happens to me with an amd 290 card, radeonsi and kernel
options to force amdgpu driver on /etc/default/grub:
GRUB_CMDLINE_LINUX_DEFAULT="quiet radeon.si_support=0
radeon.cik_support=0 amdgpu.si_support=1 amdgpu.cik_support=1"

I'm running Debian unstable and it was working fine until I upgraded
today to kernel 4.19.9-1. 

dmesg shows:

6.084494] [drm] vm size is 128 GB, 2 levels, block size is 10-bit,
fragment size is 9-bit
[6.084520] amdgpu :0a:00.0: firmware: failed to load
amdgpu/hawaii_mc.bin (-2)
[6.084525] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
[6.084529] amdgpu :0a:00.0: Direct firmware load for
amdgpu/hawaii_mc.bin failed with error -2
[6.084531] cik_mc: Failed to load firmware "amdgpu/hawaii_mc.bin"
[6.084608] [drm:gmc_v7_0_sw_init [amdgpu]] *ERROR* Failed to load
mc firmware!
[6.084685] [drm:amdgpu_device_init.cold.28 [amdgpu]] *ERROR*
sw_init of IP block  failed -2
[6.084688] amdgpu :0a:00.0: amdgpu_device_ip_init failed
[6.084691] amdgpu :0a:00.0: Fatal error during GPU init

I have the correct firmwares installed:

find / -name hawaii* 
/usr/share/zenity/clothes/hawaii-shirt.png
/usr/share/stellarium/skycultures/hawaiian_starlines
/usr/share/proj/hawaii
/lib/firmware/radeon/hawaii_ce.bin
/lib/firmware/radeon/hawaii_k_smc.bin
/lib/firmware/radeon/hawaii_mc.bin
/lib/firmware/radeon/hawaii_me.bin
/lib/firmware/radeon/hawaii_mec.bin
/lib/firmware/radeon/hawaii_pfp.bin
/lib/firmware/radeon/hawaii_rlc.bin
/lib/firmware/radeon/hawaii_sdma.bin
/lib/firmware/radeon/hawaii_sdma1.bin
/lib/firmware/radeon/hawaii_smc.bin
/lib/firmware/radeon/hawaii_uvd.bin
/lib/firmware/radeon/hawaii_vce.bin
find: ‘/run/user/1000/gvfs’: Permiso denegado

On Tue, 23 Oct 2018 16:03:06 -0300 felipe  wrote:
> Hi!
> 
> Did as you suggested:
> 
>   # apt purge firmware-amd-graphics
>   # rm -rf /lib/firmware/amdgpu
>   # apt install firmware-amd-graphics
> 
> Then I copied file by file, restarting the system between each copy
until I got a working graphical environment.
> 
> The files needed for me are:
> 
>   pitcairn_mc.bin
>   pitcairn_smc.bin
>   pitcairn_pfp.bin
>   pitcairn_me.bin
>   pitcairn_ce.bin
>   pitcairn_rlc.bin
> 
> Would you like me to test anything else?
> 
> 
> Regards,
> Felipe.
> 
> On 23/10/2018 15:41, Romain Perier wrote:
> > Hello,
> > 
> > ...
> > 
> > Yeah that's introduced by commit 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8eaf2b1faaf4358c6337785f2192055c6ef41e0d
> > 
> > Instead of copying all the content of /lib/firmware/radeon into
> > /lib/firmware/amdgpu, could you:
> > 
> > 1. Uninstall firmware-amd-graphics properly so /lib/firmware/radeon
and
> > /lib/firmware/amdgpu are empty
> > 2. Re-install firmware-amd-graphics properly from archives (so,
> > basically, these two steps undo your changes)
> > 3. Copy only /lib/firmware/radeon/pitcairn_mc.bin to
> > /lib/firmware/amdgpu/pitcairn_mc.bin
> > 
> > Does this work for you ? Otherwise try to find messages in dmesg
> > complaining about missing firmware for your amdgpu driver, then
> > copy the right missing firmwares from /lib/firmware/radeon to
> > /lib/firmware/amdgpu and then once it works, please paste a list
here.
> > 
> > Thanks in advance,
> > Regards,
> > Romain
> 
> 

Bug#916813: lintian: Port .travis.yml to .gitlab-ci.yml

[Chris Lamb]

Package: lintian
Version: 2.5.117
Severity: wishlist

Hi,

We currently have a .travis.yml; we should also have a .gitlab-ci.yml.


Regards,

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

Bug#856505: Bug#911443: linux-image-4.18.0-2-arm64: wlan0 no longer present

[Santiago Garcia Mantinan]

> I just added the commit from v4.20-rc7 that fixes this problem to the
> Linux package git repository. It will be part of the next upload of
> v4.19.x to unstable.

And could we have the patch I sent on #856505 to enable sound on this
machines applied as well?

I sent this to the lkml as you sugested but with little luck, it looks like
nobody cares.

For me it would be good to recover not only the wifi but also the audio.

Regards...
-- 
Manty/BestiaTester -> http://manty.net

Bug#916606: (no subject)

[bitfreak25]

Hi,

I've tried to create a backtrace for further investigation. This was done by 
setting a breakpoint at function client_set_pause() where the bug must occur. 
Then I've started the game an tried to reproduce the bug (the unwanted pause).

After I've got into the bug I must kill the lbreakout2 process through tty. 
Otherwise I've got a freezing display.

The created backtrace is attached.


Kind regards,
bitfreak25
GNU gdb (Debian 8.2-1) 8.2
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lbreakout2...Reading symbols from 
/usr/lib/debug/.build-id/da/ba5499ea59ec74b5eaf7ee7da4a82f7069d508.debug...done.
done.
(gdb) break game.c:529
Breakpoint 1 at 0x1c410: file game.c, line 530.
(gdb) run
Starting program: /usr/games/lbreakout2 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7f1a98f2d700 (LWP 1762)]
[New Thread 0x7f1a944a8700 (LWP 1763)]
[Thread 0x7f1a944a8700 (LWP 1763) exited]
[New Thread 0x7f1a944a8700 (LWP 1764)]
Keine Schreibberechtigung fuer "/var/games/lbreakout2.hscr".
Kann Bestenliste unter "/var/games" nicht oeffnen!
Versuche Einstellungsverzeichnis "/home/user/.lgames" zu verwenden.

Thread 1 "lbreakout2" hit Breakpoint 1, client_set_pause (pause=1)
at game.c:531
531 game.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  client_set_pause (pause=1) at game.c:531
#1  0x56091057dd6a in handle_default_key (abort=, 
key=) at game.c:628
#2  client_game_run () at game.c:1161
Backtrace stopped: Cannot access memory at address 0x7ffd162af6b8
(gdb) bt full
#0  client_set_pause (pause=1) at game.c:531
No locals.
#1  0x56091057dd6a in handle_default_key (abort=, 
key=) at game.c:628
buffer = 
buffer = 
#2  client_game_run () at game.c:1161
ms = 1
frame_delay = 1
button_clicked = 0
key_pressed = 
event = 
abort = 0
i = 
j = 
penalty = 
frames = 24822
frame_time = 
Backtrace stopped: Cannot access memory at address 0x7ffd162af6b8

Bug#916800: phybin: FTBFS with newer GHC

[Andreas Tille]

Hi Joachim,

On Tue, Dec 18, 2018 at 10:57:15PM +0100, Joachim Breitner wrote:
> Would not be hard to fix, but is there a chance that upstream could just 
> release a version that works with a current compiler?

I'm afraid upstream is not very active but would be happy about a patch.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Dmitry Smirnov]

On Wednesday, 19 December 2018 9:17:51 AM AEDT Thorsten Glaser wrote:
> Did you mean: in an unstable-like “volatile” repo?

Yes perhaps more like "unstable".
I'm saying that IMHO we should have only one common/shared "PPA" for "stable" 
users. I do not want many personal/individual archives.


> Backports have a defined mission, which has nothing to do
> with the “volatile” proposal. What you were referring to,
> integration- and checks-wise, is, I think what you get in
> *any* repository maintained by ftpmasters, so it’d be more
> like sid, except only a partial distribution (add-on).

I also think that we could just relax official "backports" criteria but that 
would be so hard that it seem easier to arrange another "volatile" repo...

-- 
Regards,
 Dmitry Smirnov.

---

Success consists of going from failure to failure without loss of enthusiasm.
-- Winston Churchill


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

Bug#916796: IEEEfull.bib: cannot be read in encoding 'utf8' by biber

[Hilmar Preuße]

Am 18.12.2018 um 18:20 teilte Damir R. Islamov mit:

Hi Damir,


The file /usr/share/texlive/texmf-dist/bibtex/bib/IEEEtran/IEEEfull.bib 
contains a symbol
`á' in ISO-8859-1 8bit charset:
line 23, see `Nicolás Barabino' name.

This character breakes biblatex+biber.

Recoding from ISO-8859-1 to UTF-8 charset fixes the issue.

Unfortunately the most active member from the Debian TeX group stopped 
working for Debian. So if you expect to get a solution for that problem 
in a foreseeable time frame please be so kind to contact upstream author 
yourself.


Thanks,
  Hilmar
--
#206401 http://counter.li.org

Bug#916808: hydra-el: FTBFS with Emacs 26.1: tests fail

[Sean Whitton]

Hello,

On Tue 18 Dec 2018 at 10:22pm GMT, Sean Whitton wrote:

> Full log attached.

Whoops, not attached, and now deleted.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#916812: paredit: FTBFS with Emacs 26.1: trailing garbage following expression

[Sean Whitton]

Source: paredit
Version: 24-2
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

make[1]: Entering directory '/<>'
sh genhtml.sh
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Trailing garbage following expression:

make[1]: *** [debian/rules:7: override_dh_installdocs] Error 255

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


paredit-el_i386-2018-12-18T18:20:45Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#916811: weechat-el: FTBFS with Emacs 26.1

[Sean Whitton]

Source: weechat-el
Version: 0.5.0-1
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

Creating documentation: README.html
Loading /etc/emacs/site-start.d/00debian.el (source)...
Loading /etc/emacs/site-start.d/50autoconf.el (source)...
Loading /etc/emacs/site-start.d/50cmake-data.el (source)...
Please install htmlize from https://github.com/hniksic/emacs-htmlize
make[2]: *** [Makefile:50: README.html] Error 255

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


weechat-el_i386-2018-12-18T19:43:00Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#916808: hydra-el: FTBFS with Emacs 26.1: tests fail

[Sean Whitton]

Source: hydra-el
Version: 0.14-2
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

Ran 38 tests, 36 results as expected, 2 unexpected (2018-12-18 
14:10:02+)

2 unexpected results:
   FAILED  hydra-format-5
   FAILED  hydra-format-6

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Thorsten Glaser]

On Wed, 19 Dec 2018, Dmitry Smirnov wrote:

> trust - a something we can only have in backports-like "volatile" repo.

Did you mean: in an unstable-like “volatile” repo?

Backports have a defined mission, which has nothing to do
with the “volatile” proposal. What you were referring to,
integration- and checks-wise, is, I think what you get in
*any* repository maintained by ftpmasters, so it’d be more
like sid, except only a partial distribution (add-on).

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

Bug#916807: haskell-mode: FTBFS with Emacs 26.1: tests fail

[Sean Whitton]

Source: haskell-mode
Version: 0.4-1
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

Ran 513 tests, 509 results as expected, 4 unexpected (2018-12-18 13:48:40+)
123 expected failures

4 unexpected results:
   FAILED  haskell-cabal-compute-checksum-1
   FAILED  haskell-cabal-compute-next-prev-section-1
   FAILED  haskell-cabal-enum-targets-1
   FAILED  haskell-cabal-get-field-1

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


haskell-mode_i386-2018-12-18T13:47:24Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#916806: dash-functional-el: FTBFS with Emacs 26.1: tests fail

[Sean Whitton]

Source: dash-functional-el
Version: 0.4-1
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

Ran 148 tests, 147 results as expected, 1 unexpected (2018-12-18 
12:20:51+)

1 unexpected results:
   FAILED  -prodfn

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


dash-functional-el_i386-2018-12-18T12:19:59Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#916805: assess-el: FTBFS with Emacs 26.1: tests fail

[Sean Whitton]

Source: assess-el
Version: 0.4-1
Severity: important
User: debian-emac...@lists.debian.org
Usertags: emacs26-ftbfs
Tags: ftbfs

Dear maintainer,

This package fails to build against Emacs 26.1, currently in
experimental.  It does not fail against Emacs 25.2, currently in sid.
Full log attached.

Ran 45 tests, 43 results as expected, 2 unexpected (2018-12-18 
11:35:32+)

2 unexpected results:
   FAILED  explanation-extraction-from-result
   FAILED  plist-extraction

This bug will likely become RC before the upcoming transitions freeze,
as we expect to ship Emacs 26.1 in buster.

-- 
Sean Whitton


assess-el_i386-2018-12-18T11:34:30Z.build
Description: Binary data


signature.asc
Description: PGP signature

Bug#915050: (gitlab) Re: Bug#915050: Keep out of testing

[Dmitry Smirnov]

On Wednesday, 19 December 2018 2:11:43 AM AEDT Holger Levsen wrote:
> instead of volatile we need PPAs.

I think concept of "volatile" is better, stronger.
PPA allows people to ship whatever they want without cooperating in policy 
compliant (official) repo. This is the Debian way where many people work 
together in one centralized resource.
Many people working in many places (PPA) will undermine cooperativeness and 
trust - a something we can only have in backports-like "volatile" repo.

-- 
Cheers,
 Dmitry Smirnov.

---

The great enemy of the truth is very often not the lie -- deliberate,
contrived and dishonest, but the myth, persistent, persuasive, and
unrealistic. Belief in myths allows the comfort of opinion without the
discomfort of thought.
-- John F Kennedy


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

Bug#916114: xawtv FTBFS with glibc 2.28

[Juhani Numminen]

Control: tags -1 + fixed-upstream

On Mon, 10 Dec 2018 12:29:10 +0200 Adrian Bunk  wrote:
> Source: xawtv
> Version: 3.104-1
> Severity: serious
> Tags: ftbfs
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/xawtv.html
> ...
> ./common/get_media_devices.c:522: undefined reference to `major'
> /usr/bin/ld: ./common/get_media_devices.c:523: undefined reference to `minor'

Looks like there is an upstream commit to fix this:
https://git.linuxtv.org/xawtv3.git/commit/?id=65a71c3a0f36287402c0a959475fc0bc2eb46586

--
Juhani

Bug#916800: phybin: FTBFS with newer GHC

[Joachim Breitner]

Hi,

Would not be hard to fix, but is there a chance that upstream could just 
release a version that works with a current compiler?

Cheers, Joachim



Am 18. Dezember 2018 22:36:26 MEZ schrieb Andreas Tille :
>Control: tags -1 help
>
>Hi,
>
>unfortunately I have no idea how to fix this.
>
>Kind regards, Andreas.
>
>On Tue, Dec 18, 2018 at 08:32:22PM +0200, Ilias Tsitsimpis wrote:
>> Package: phybin
>> Version: 0.3-2
>> Severity: serious
>> Justification: fails to build from source (but built successfully in
>the past)
>> 
>> Dear maintainer,
>> 
>> phybin FTBFS with newer versions of GHC (>= 8.4) with the following
>error:
>> 
>>  [1 of 9] Compiling Bio.Phylogeny.PhyBin.CoreTypes (
>Bio/Phylogeny/PhyBin/CoreTypes.hs,
>dist-ghc/build/test-phybin/test-phybin-tmp/Bio/Phylogeny/PhyBin/CoreTypes.o
>)
>> 
>>  Bio/Phylogeny/PhyBin/CoreTypes.hs:112:35: error:
>>  Ambiguous occurrence `<>'
>>  It could refer to either `Prelude.<>',
>>   imported from 
>> `Prelude' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>>   (and 
>> originally defined in `GHC.Base')
>>or 
>> `Text.PrettyPrint.HughesPJClass.<>',
>>   imported from 
>> `Text.PrettyPrint.HughesPJClass' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>>   (and 
>> originally defined in
>`pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>>  |
>>  112 | displayDefaultTree orig = loop tr <> ";"
>>  |   ^^
>> 
>>  Bio/Phylogeny/PhyBin/CoreTypes.hs:120:27: error:
>>  Ambiguous occurrence `<>'
>>  It could refer to either `Prelude.<>',
>>   imported from 
>> `Prelude' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>>   (and 
>> originally defined in `GHC.Base')
>>or 
>> `Text.PrettyPrint.HughesPJClass.<>',
>>   imported from 
>> `Text.PrettyPrint.HughesPJClass' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>>   (and 
>> originally defined in
>`pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>>  |
>>  120 |  Just val -> base <> text ":[" <> text (show val) <>
>text "]"
>>  |   ^^
>> 
>>  Bio/Phylogeny/PhyBin/CoreTypes.hs:120:40: error:
>>  Ambiguous occurrence `<>'
>>  It could refer to either `Prelude.<>',
>>   imported from 
>> `Prelude' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>>   (and 
>> originally defined in `GHC.Base')
>>or 
>> `Text.PrettyPrint.HughesPJClass.<>',
>>   imported from 
>> `Text.PrettyPrint.HughesPJClass' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>>   (and 
>> originally defined in
>`pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>>  |
>>  120 |  Just val -> base <> text ":[" <> text (show val) <>
>text "]"
>>  |^^
>> 
>>  Bio/Phylogeny/PhyBin/CoreTypes.hs:120:59: error:
>>  Ambiguous occurrence `<>'
>>  It could refer to either `Prelude.<>',
>>   imported from 
>> `Prelude' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>>   (and 
>> originally defined in `GHC.Base')
>>or 
>> `Text.PrettyPrint.HughesPJClass.<>',
>>   imported from 
>> `Text.PrettyPrint.HughesPJClass' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>>   (and 
>> originally defined in
>`pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>>  |
>>  120 |  Just val -> base <> text ":[" <> text (show val) <>
>text "]"
>>  |   ^^
>> 
>>  Bio/Phylogeny/PhyBin/CoreTypes.hs:121:47: error:
>>  Ambiguous occurrence `<>'
>>  It could refer to either `Prelude.<>',
>>   imported from 
>> `Prelude' at
>Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>> 

Bug#892031: marked as done (stretch-pu: package wayland/1.12.0-1)

[Adam D. Barratt]

Control: reopen -1

On Tue, 2018-12-18 at 20:42 +, Debian Bug Tracking System wrote:
> Your message dated Tue, 18 Dec 2018 20:41:35 +
> with message-id 
> and subject line Bug#892031: fixed in wayland 1.12.0-1+deb9u1
> has caused the Debian Bug report #892031,
> regarding stretch-pu: package wayland/1.12.0-1
> to be marked as done.

   * debian/patches/CVE-2017-16612.patch: (Closes: #889681, #892031)

Please don't do that. The release.d.o bug will be closed once the
updated package is in stable, not before - and certainly not simply
because the upload reached p-u.

Regards,

Adam

Bug#916804: libinput-bin: Provide a NEWS.gz file

[Eugen Dedu]

Package: libinput-bin
Version: 1.12.4-1
Severity: wishlist

Dear Maintainer,

It would be useful to have a NEWS.gz file to see the release notes.  For
1.12.4 it could have the lines from
https://lists.freedesktop.org/archives/wayland-devel/2018-December/039782.html.
Generally, the information is at
https://www.freedesktop.org/wiki/Software/libinput/ (not yet available 
for 1.12.4).


Best regards,
Eugen

Bug#916773: r-base: CRAN packages fail to install.

[Dirk Eddelbuettel]

On 18 December 2018 at 22:13, Emmanuel Charpentier wrote:
| Dear Dirk,
| 
| Le mardi 18 décembre 2018 à 12:00 -0600, Dirk Eddelbuettel a écrit :
| > Emmanuel,
| > 
| > I ran this by Kurt Hornik (CC'ed) who is a Debian user too and one
| > who
| > updates frequently.  He has hit the issue as well as says that it
| > seems to
| > stem from rstan
| 
| It's more complicated than that. reinstalling rstan, or even Rcpp the
| rstan, isn't sufficient to install brms.

There are more C++ parts than rstan and Rcpp. I would try to reinstall them.

| >  and that updating "everything" seems to fix it,
| 
| I checked that by reinstalling Sage's R (3.4.4 ATM) an my whole slate
| of 493-29=464 packages + updates). Takes about 93 minutes, but seems to
| work.

Well neither Kurt nor I suggested to update ~500 packages but if you're happy
now, so be it.
 
| I'll do that for my systemwide R installation. I'll yell if something
| goes wrong, of course...
| 
| >  just as I
| > suggested to you as "qualified guess".  We have no idea yet whose ABI
| > changed.
| > 
| > With that I think we can close this as a bug against the r-base
| > package. It
| > appears to be a bystander here.
| 
| Indeed (with the proviso that I want to see that with R 3.5.1...).
| 
| But I wonder how many potential bystanders are in Debian, and what
| measures should be taken to retrieve the real source of the problem.
| 
| Do you thing I should file a bug against glibc ?

No because we have no minimally reproducible issue here. It wasn't an r-base
either (and I am still inclined to close this).

You did the right thing to file it here:
  https://github.com/paul-buerkner/brms/issues/573
Until we know more it should stay there.

BTW there you write 'running as root' -- don't do that. I added myself to
group staff as it is the group on /usr/local/lib/R/site-library.  Now I can
(and do) runn eg littler's 'install.r' as me.  Been doing that for years.

To sum up, if a binary is in Debian itself chances are it gets updated when
it needs to. When we install "outside of the distro package manager" directly
from CRAN things like this can happen. Maybe it was glibc. Maybe it was a
change in g++.  Maybe it was something else.  Paul was correct in pointing to
CRAN and the positive test results there.  When nothing changes the package
remains happy...

Best, Dirk

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

Bug#916800: phybin: FTBFS with newer GHC

[Andreas Tille]

Control: tags -1 help

Hi,

unfortunately I have no idea how to fix this.

Kind regards, Andreas.

On Tue, Dec 18, 2018 at 08:32:22PM +0200, Ilias Tsitsimpis wrote:
> Package: phybin
> Version: 0.3-2
> Severity: serious
> Justification: fails to build from source (but built successfully in the past)
> 
> Dear maintainer,
> 
> phybin FTBFS with newer versions of GHC (>= 8.4) with the following error:
> 
>   [1 of 9] Compiling Bio.Phylogeny.PhyBin.CoreTypes ( 
> Bio/Phylogeny/PhyBin/CoreTypes.hs, 
> dist-ghc/build/test-phybin/test-phybin-tmp/Bio/Phylogeny/PhyBin/CoreTypes.o )
> 
>   Bio/Phylogeny/PhyBin/CoreTypes.hs:112:35: error:
>   Ambiguous occurrence `<>'
>   It could refer to either `Prelude.<>',
>imported from 
> `Prelude' at Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>(and 
> originally defined in `GHC.Base')
> or 
> `Text.PrettyPrint.HughesPJClass.<>',
>imported from 
> `Text.PrettyPrint.HughesPJClass' at Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>(and 
> originally defined in `pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>   |
>   112 | displayDefaultTree orig = loop tr <> ";"
>   |   ^^
> 
>   Bio/Phylogeny/PhyBin/CoreTypes.hs:120:27: error:
>   Ambiguous occurrence `<>'
>   It could refer to either `Prelude.<>',
>imported from 
> `Prelude' at Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>(and 
> originally defined in `GHC.Base')
> or 
> `Text.PrettyPrint.HughesPJClass.<>',
>imported from 
> `Text.PrettyPrint.HughesPJClass' at Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>(and 
> originally defined in `pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>   |
>   120 |  Just val -> base <> text ":[" <> text (show val) <> text 
> "]"
>   |   ^^
> 
>   Bio/Phylogeny/PhyBin/CoreTypes.hs:120:40: error:
>   Ambiguous occurrence `<>'
>   It could refer to either `Prelude.<>',
>imported from 
> `Prelude' at Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>(and 
> originally defined in `GHC.Base')
> or 
> `Text.PrettyPrint.HughesPJClass.<>',
>imported from 
> `Text.PrettyPrint.HughesPJClass' at Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>(and 
> originally defined in `pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>   |
>   120 |  Just val -> base <> text ":[" <> text (show val) <> text 
> "]"
>   |^^
> 
>   Bio/Phylogeny/PhyBin/CoreTypes.hs:120:59: error:
>   Ambiguous occurrence `<>'
>   It could refer to either `Prelude.<>',
>imported from 
> `Prelude' at Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>(and 
> originally defined in `GHC.Base')
> or 
> `Text.PrettyPrint.HughesPJClass.<>',
>imported from 
> `Text.PrettyPrint.HughesPJClass' at Bio/Phylogeny/PhyBin/CoreTypes.hs:40:1-58
>(and 
> originally defined in `pretty-1.1.3.6:Text.PrettyPrint.HughesPJ')
>   |
>   120 |  Just val -> base <> text ":[" <> text (show val) <> text 
> "]"
>   |   ^^
> 
>   Bio/Phylogeny/PhyBin/CoreTypes.hs:121:47: error:
>   Ambiguous occurrence `<>'
>   It could refer to either `Prelude.<>',
>imported from 
> `Prelude' at Bio/Phylogeny/PhyBin/CoreTypes.hs:7:8-37
>(and 
> originally defined in `GHC.Base')
> or 
> `Text.PrettyPrint.HughesPJClass.<>',
>imported from 
> 

Bug#916773: r-base: CRAN packages fail to install.

[Emmanuel Charpentier]

Dear Dirk,

Le mardi 18 décembre 2018 à 12:00 -0600, Dirk Eddelbuettel a écrit :
> Emmanuel,
> 
> I ran this by Kurt Hornik (CC'ed) who is a Debian user too and one
> who
> updates frequently.  He has hit the issue as well as says that it
> seems to
> stem from rstan

It's more complicated than that. reinstalling rstan, or even Rcpp the
rstan, isn't sufficient to install brms.

>  and that updating "everything" seems to fix it,

I checked that by reinstalling Sage's R (3.4.4 ATM) an my whole slate
of 493-29=464 packages + updates). Takes about 93 minutes, but seems to
work.

I'll do that for my systemwide R installation. I'll yell if something
goes wrong, of course...

>  just as I
> suggested to you as "qualified guess".  We have no idea yet whose ABI
> changed.
> 
> With that I think we can close this as a bug against the r-base
> package. It
> appears to be a bystander here.

Indeed (with the proviso that I want to see that with R 3.5.1...).

But I wonder how many potential bystanders are in Debian, and what
measures should be taken to retrieve the real source of the problem.

Do you thing I should file a bug against glibc ?

Cordially yours,

--
Emmanuel Charpentier
 
> 
> Best,  Dirk
> 

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Aurelien Jarno]

On 2018-12-18 21:34, Aurelien Jarno wrote:
> Hi,
> 
> On 2018-12-18 15:15, Tim Ruehsen wrote:
> > Package: libc6-armhf-cross
> > Version: 2.28-2cross2
> > Severity: normal
> > 
> > Dear Maintainer,
> > 
> > currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> > 
> > The expected errno value would be either EINVAL or not touching errno
> > at all.
> > 
> > This behavior is relatively new and causes some CI cross builds to fail.
> > The failing test is a gnulib test (test-strerror.c).
> > 
> 
> I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
> qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
> hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
> think it's a qemu bug.

Hmm, I am wrong, I can actually reproduce it with qemu-user-static
version 1:2.12+dfsg-3+b1. But I can't reproduce it on real hardware.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#916803: mdocml: HTML output uses block elements for inline text, causing bad rendering

[Thorsten Glaser]

Package: mandoc
Version: 1.14.4-1
Severity: normal
Tags: upstream

Steps to do:

$ zcat /usr/share/man/man1/lksh.1.gz | mandoc -Thtml >lksh.htm
$ lynx lksh.htm

This is on a Debian system with the mksh package installed.
Upstream developers can achieve the same with:

$ cvs -d _anon...@anoncvs.mirbsd.org:/cvs get -p mksh/lksh.1 | mandoc -Thtml 
>lksh.htm
$ lynx lksh.htm


The rendered output, in lynx(1), looks like this:

[2]SYNOPSIS

   lksh [
   -+abCefhiklmnprUuvXx
   ] [
   -+o opt
   ] [
   -c string | -s | file [
   args ...
   ]
   ]


The cause lies in the HTML:

[-+abCefhiklmnprUuvXx]

Blindly replacing _all_ div with span isn’t right either, but proves
that using span for inline markup is correct:

   [2]SYNOPSIS

   lksh [-+abCefhiklmnprUuvXx] [-+o opt] [-c string | -s | file [args ...]]

HTML:

  [-+oopt]


So, please use inline markup (span) instead of block markup (div) if you
wish to not produce linebreaks. Thanks!

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages mandoc depends on:
ii  libc6   2.28-2
ii  zlib1g  1:1.2.11.dfsg-1

mandoc recommends no packages.

mandoc suggests no packages.

-- no debconf information

Bug#885638: GBonds Modernization

[Richard Laager]

I have a new version of the gbonds package prepared and sent to my
sponsor for upload.

The vast majority of the credit for this upload goes to Yavor Doganov
who submitted a series of patches to modernize the gbonds code, porting
it to GTK+ 3, GIO, and GSettings and restoring printing support! This
resolves the serious bugs which would have otherwise required the
removal of gbonds prior to the Buster release.

I am extremely grateful for this generous contribution of coding time
and skill!

Yavor Doganov: I made the following changes to your patches in the
process of accepting them:

Port to GTK+ 3 and GIO:
  - Dropped spurious diff header changes to other files
  - Folded in the remainder of debian/patches/libgnomeprint

^ These changes were cosmetic in nature.


Port to GSettings:
  - Install the schema and setting files into gbonds-data

^ These files were required. I simply added them to
  debian/gbonds-data.install so they ended up in the package.


I tested this with my usual real-world data file and usage. I also
tested downloading new redemption data from the Treasury. I tested the
printing functionality to the point of a Preview. It looks great to me!

-- 
Richard

Bug#916595: vlc: program doesn't close its process in some cases

[bitfreak25]

Hi,

@Bernard I've tried your recommended debug backtrace. The output is attached in 
vlc_*.txt. I coudn't find all packages with debug-symbols but I hope there 
enough. If somethings missing, please ask.

Kind regards,
bitfreak25
Attaching to process 1662
[New LWP 1663]
[New LWP 1664]
[New LWP 1665]
[New LWP 1668]
[New LWP 1670]
[New LWP 1672]
[New LWP 1673]
[New LWP 1674]
[New LWP 1675]
[New LWP 1676]
[New LWP 1677]
[New LWP 1678]
[New LWP 1679]
[New LWP 1680]
[New LWP 1681]
[New LWP 1682]
[New LWP 1683]
[New LWP 1684]
[New LWP 1685]
[New LWP 1686]
[New LWP 1687]
[New LWP 1688]
[New LWP 1689]
[New LWP 1690]
[New LWP 1691]
[New LWP 1692]
[New LWP 1693]
[New LWP 1694]
[New LWP 1707]
[New LWP 1708]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x7f7a837df485 in __GI___pthread_timedjoin_ex (threadid=140164093331200, 
thread_return=thread_return@entry=0x0, abstime=abstime@entry=0x0, 
block=block@entry=true) at pthread_join_common.c:89
89  pthread_join_common.c: Datei oder Verzeichnis nicht gefunden.

Thread 31 (Thread 0x7f79cb4be700 (LWP 1708)):
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x7f79c003c570) at 
../sysdeps/unix/sysv/linux/futex-internal.h:88
__ret = -512
oldtype = 0
err = 
oldtype = 
err = 
__ret = 
resultvar = 
__arg4 = 
__arg3 = 
__arg2 = 
__arg1 = 
_a4 = 
_a3 = 
_a2 = 
_a1 = 
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x7f79c003c520, 
cond=0x7f79c003c548) at pthread_cond_wait.c:502
spin = 0
buffer = {__routine = 0x7f7a837e3d60 <__condvar_cleanup_waiting>, __arg 
= 0x7f79cb4bdd80, __canceltype = 576, __prev = 0x0}
cbuffer = {wseq = 0, cond = 0x7f79c003c548, mutex = 0x7f79c003c520, 
private = 0}
rt = 
err = 
g = 0
flags = 
g1_start = 
signals = 
result = 0
wseq = 0
seq = 0
private = 0
maxspin = 
err = 
result = 
wseq = 
g = 
seq = 
flags = 
private = 
signals = 
g1_start = 
spin = 
buffer = 
cbuffer = 
rt = 
s = 
#2  __pthread_cond_wait (cond=0x7f79c003c548, mutex=0x7f79c003c520) at 
pthread_cond_wait.c:655
No locals.
#3  0x7f7a435d5cfb in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
No symbol table info available.
#4  0x7f7a435d5a27 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
No symbol table info available.
#5  0x7f7a837ddfa3 in start_thread (arg=) at 
pthread_create.c:486
ret = 
pd = 
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140161078519552, 
-6302034852034311783, 140161085136622, 140161085136623, 140161078519552, 34, 
6231075497269070233, 6232887647007607193}, mask_was_saved = 0}}, priv = {pad = 
{0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 
#6  0x7f7a8370988f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
No locals.

Thread 30 (Thread 0x7f79cbb0f700 (LWP 1707)):
#0  0x7f7a836febd9 in __GI___poll (fds=fds@entry=0x7f79cbb0e8d8, 
nfds=nfds@entry=1, timeout=timeout@entry=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
resultvar = 18446744073709551100
sc_cancel_oldtype = 0
sc_ret = 
#1  0x7f7a7f64fcf7 in poll (__timeout=-1, __nfds=1, __fds=0x7f79cbb0e8d8) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
No locals.
#2  _xcb_conn_wait (c=c@entry=0x7f79c02d3c00, cond=cond@entry=0x7f79c0292cc8, 
vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:479
ret = 
fd = {fd = 34, events = 1, revents = 0}
#3  0x7f7a7f651a0a in xcb_wait_for_special_event (c=0x7f79c02d3c00, 
se=0x7f79c0292ca0) at ../../src/xcb_in.c:795
special = {se = 0x7f79c0292ca0, next = 0x0}
event = 
#4  0x7f7a48b54f6b in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
No symbol table info available.
#5  0x7f7a48b56158 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
No symbol table info available.
#6  0x7f7a48b575e8 in ?? () from /usr/lib/x86_64-linux-gnu/libGLX_mesa.so.0
No symbol table info available.
#7  0x7f7a436d13da in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
No symbol table info available.
#8  0x7f7a434db37a in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
No symbol table info available.
#9  0x7f7a434db3b0 in ?? () from 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so
No symbol table info available.
#10 0x7f79cb9fd73e in ?? () from 
/usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libgl_plugin.so
No symbol table info available.
#11 0x7f79cba0663b in ?? () from 
/usr/lib/x86_64-linux-gnu/vlc/plugins/video_output/libgl_plugin.so
No symbol table info available.
#12 

Bug#544651: lvm2: Volume group not found, unable to find LVM during boot

[Smo Oey]

On Tue, 18 Dec 2018 15:19:19 -0500 Smo Oey  wrote:
> On Wed, 08 Jun 2016 17:24:18 +0300 Teemu Likonen  wrote:
> > Ertuğrul Harman [2015-08-08 23:51:11+03] wrote:
> >
> > > During every boot time after a fresh installation of debian jessie, I
> > > get following errors after grub screen passes:
> > >
> > > Volume group "ert-debian-vg" not found.
> > > Skipping volume group "ert-debian-vg"
> > > Unable to find LVM "volume ert-debian-vg/root"
> > > Volume group "ert-debian-vg" not found
> > > Skipping volume group "ert-debian-vg"
> > > Unable to find LVM "volume ert-debian-vg/swap_1"
> > > Please unlock disk sd3_crypt:
> > >
> > > I enter my password and boot continues.
> >
> > Just another user here. This cosmetic bug has always been in Debian.
> > LVM inside encrypted partition causes those errors.
> >
> > It seems that bugs #794971 and #544651 are the same.
> >
> > I guess the error message can be removed just by removing one echo
> > command from file /usr/share/initramfs-tools/scripts/local-top/lvm2.
>
> I was very much wanting to come over to the world of Debian, but this
> guy's reply is a huge turn off. Sweeping a bug or hiding a "bug" isn't
> fixing it... I just tried installing Debian 9.6 with Luks on LVM and
> got similar error /warning message. I've been searching like crazy to
> find proper guides (without graphical installer) on how to setup the
> luks on lvm and most are foreign speaking people and can't understand
> nothing. Then to find this shit in bug reports... come on man. Forget
> Debian then, I'll use another linux distro where people actually fix
> bugs, not sweep them under rug or hide them.
>
>
For record, basically my message was this but this isn't MY message..
it's from another user with similar issue. Just in case someone on dev
team that actually cares about fixing known issues /bugs is set on
fixing it... not ones that hide/mask the bugs and claim they're fixed.
lol
https://www.debian-fr.org/t/warning-lors-du-demarrage-failed-to-connect-to-lvmetad/75575

WARNING: Failed to connect to lvmetad. Falling back to device
scanning. Volume group "compaqdebian-vg" not found Cannot process
volume group compaqdebian-vg WARNING: Failed to connect to lvmetad.
Falling back to device scanning. Volume group "compaqdebian-vg" not
found Cannot process volume group compaqdebian-vg

Ensuite le message suivant apparait :
Please unlock disk sda5_crypt:

Bug#916779: libc6-armhf-cross: strerror(-3) sets errno to ENOMEM

[Aurelien Jarno]

Hi,

On 2018-12-18 15:15, Tim Ruehsen wrote:
> Package: libc6-armhf-cross
> Version: 2.28-2cross2
> Severity: normal
> 
> Dear Maintainer,
> 
> currently strerror(-3) sets errno unexpectedly to ENOMEM (12).
> 
> The expected errno value would be either EINVAL or not touching errno
> at all.
> 
> This behavior is relatively new and causes some CI cross builds to fail.
> The failing test is a gnulib test (test-strerror.c).
> 

I can reproduce the issue with libc6-armhf-cross 2.28-2cross2 and
qemu-arm-static 1:3.1+dfsg-1, but not with the same binary on real
hardware nor on qemu-user-static 1:2.12+dfsg-3+b1. I would therefore
think it's a qemu bug.

Do you have some other tests showing it's linked to the new upstream
glibc version?

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net

Bug#916468: Conflict over /usr/bin/dune

[Philipp Kern]

Am 18.12.2018 um 18:48 schrieb Ian Jackson:
> But overall I think this, plus the history of the ocaml program's
> name, does demonstrate that the ocaml program's claim to the overall
> software name `dune', and the command name `dune' is incredibly weak.
> 
> I just checked and `odune' seems to be available.  For a build tool a
> reasonably short name is justified.  The `o' prefix is often used with
> ocaml and though there is of course a risk of clashes with both
> individual programs and with some suites like the old OpenStep stuff,
> it seems that `/usr/bin/odune', odune(1) et al, are not taken.

But then again it's a build tool that actually needs to be called its
name on the console (just like the node mess). whitedune is a GUI
program that could have any name as long as it's obvious from the
desktop metadata and in fact its webpage disappeared and it hasn't seen
a new upstream version since 2011. And the C++ library doesn't seem to
have a CLI name claim at all.

I suppose it's mostly the point that we package all free software on the
planet that we become an arbiter of names. But we should try not to be
that if we can avoid it.

Kind regards
Philipp Kern

Bug#916678: systemd: Caught , dumped core as pid 2097

[Cristian Ionescu-Idbohrn]

On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
> 
> Hello Cristian Ionescu-Idbohrn,
> following is what I get from a buster amd64 qemu VM,
> with explicitly downgraded systemd packages to 239-13:
> 
> It has quite a similarity to upstream bug [1].
> And upstream received a fix for that just a few days ago,
> and is therefore not yet contained in an upstream release.

Thanks.  So, this bug is present in 239-15 too and can bite again, 
isn't it?

> [1] https://github.com/systemd/systemd/issues/10716
> 
> (gdb) bt
> #0  0x7f2d9386bb37 in kill () at ../sysdeps/unix/syscall-template.S:78
> #1  0x561672b85436 in crash (sig=11) at ../src/core/main.c:183
> #2  
> #3  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:93
> #4  0x7f2d93680cb7 in message_append_basic (m=m@entry=0x561674c79870, 
> type=, p=0x, stored=stored@entry=0x0) at 
> ../src/basic/string-util.h:36
> #5  0x7f2d936812ab in sd_bus_message_append_basic 
> (m=m@entry=0x561674c79870, type=, p=) at 
> ../src/libsystemd/sd-bus/bus-message.c:1565
> #6  0x7f2d93681719 in sd_bus_message_appendv (m=0x561674c79870, 
> types=, ap=ap@entry=0x7ffcabd85950) at 
> ../src/libsystemd/sd-bus/bus-message.c:2358
> #7  0x7f2d93681cf9 in sd_bus_message_append (m=, 
> types=) at ../src/libsystemd/sd-bus/bus-message.c:2473
> #8  0x561672b01daf in send_removed_signal (bus=0x561674bb3130, 
> userdata=0x561674c144f0) at ../src/core/job.c:1565
> #9  0x561672b71dbf in bus_foreach_bus (m=0x561674ab5830, subscribed2=0x0, 
> send_message=0x561672b01d00 , userdata=0x561674c144f0) 
> at ../src/core/dbus.c:1187
> #10 0x561672b03f78 in bus_job_send_removed_signal (j=, 
> j=) at ../src/core/dbus-job.c:225
> #11 0x561672b8300e in manager_flush_finished_jobs (m=) at 
> ../src/core/manager.c:3359
> #12 manager_reload (m=0x561674ab5830) at ../src/core/manager.c:3477
> #13 invoke_main_loop (m=0x561674ab5830, ret_reexecute=0x7ffcabd85c2a, 
> ret_retval=0x7ffcabd85c2c, ret_shutdown_verb=, 
> ret_fds=0x7ffcabd85c30, ret_switch_root_dir=0x7ffcabd85c58, 
> ret_switch_root_init=0x7ffcabd85c50, ret_error_message=0x7ffcabd85c40) at 
> ../src/core/main.c:1661
> #14 0x561672ae4620 in main (argc=, argv=0x7ffcabd85f08) at 
> ../src/core/main.c:2415


Cheers,

-- 
Cristian

Bug#916678: systemd: Caught , dumped core as pid 2097

[Bernhard Übelacker]

Hello Cristian Ionescu-Idbohrn,
following is what I get from a buster amd64 qemu VM,
with explicitly downgraded systemd packages to 239-13:

It has quite a similarity to upstream bug [1].
And upstream received a fix for that just a few days ago,
and is therefore not yet contained in an upstream release.

Kind regards,
Bernhard


[1] https://github.com/systemd/systemd/issues/10716

(gdb) bt
#0  0x7f2d9386bb37 in kill () at ../sysdeps/unix/syscall-template.S:78
#1  0x561672b85436 in crash (sig=11) at ../src/core/main.c:183
#2  
#3  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:93
#4  0x7f2d93680cb7 in message_append_basic (m=m@entry=0x561674c79870, 
type=, p=0x, stored=stored@entry=0x0) at 
../src/basic/string-util.h:36
#5  0x7f2d936812ab in sd_bus_message_append_basic 
(m=m@entry=0x561674c79870, type=, p=) at 
../src/libsystemd/sd-bus/bus-message.c:1565
#6  0x7f2d93681719 in sd_bus_message_appendv (m=0x561674c79870, 
types=, ap=ap@entry=0x7ffcabd85950) at 
../src/libsystemd/sd-bus/bus-message.c:2358
#7  0x7f2d93681cf9 in sd_bus_message_append (m=, 
types=) at ../src/libsystemd/sd-bus/bus-message.c:2473
#8  0x561672b01daf in send_removed_signal (bus=0x561674bb3130, 
userdata=0x561674c144f0) at ../src/core/job.c:1565
#9  0x561672b71dbf in bus_foreach_bus (m=0x561674ab5830, subscribed2=0x0, 
send_message=0x561672b01d00 , userdata=0x561674c144f0) at 
../src/core/dbus.c:1187
#10 0x561672b03f78 in bus_job_send_removed_signal (j=, 
j=) at ../src/core/dbus-job.c:225
#11 0x561672b8300e in manager_flush_finished_jobs (m=) at 
../src/core/manager.c:3359
#12 manager_reload (m=0x561674ab5830) at ../src/core/manager.c:3477
#13 invoke_main_loop (m=0x561674ab5830, ret_reexecute=0x7ffcabd85c2a, 
ret_retval=0x7ffcabd85c2c, ret_shutdown_verb=, 
ret_fds=0x7ffcabd85c30, ret_switch_root_dir=0x7ffcabd85c58, 
ret_switch_root_init=0x7ffcabd85c50, ret_error_message=0x7ffcabd85c40) at 
../src/core/main.c:1661
#14 0x561672ae4620 in main (argc=, argv=0x7ffcabd85f08) at 
../src/core/main.c:2415


# buster amd64 qemu VM



apt update
apt dist-upgrade

apt install gdb 




root@debian:~# gdb -q --pid 1
Attaching to process 1
...
(gdb) generate-core-file 
Saved corefile core.1
(gdb) detach
Detaching from program: /lib/systemd/systemd, process 1
[Inferior 1 (process 1) detached]
(gdb) q




root@debian:~# gdb -q -ex "set pagination off" -ex "info share" -ex quit 
/sbin/init --core core.1 2>&1 | grep libc.so.6
0x7f5a8f5a8320  0x7f5a8f6ee7ab  Yes 
/lib/x86_64-linux-gnu/libc.so.6





root@debian:~# gdb -q -ex "set pagination off" -ex "disassemble 
0x7f5a8f5a8320,0x7f5a8f6ee7ab" -ex quit /sbin/init --core core.1 2>&1 | 
grep 0x.647
# 64 possible locations ...




root@debian:~# gdb -q -ex "set pagination off" -ex "find /b 0x7f5a8f5a8320, 
0x7f5a8f6ee7ab, 
0xc5,0xfd,0x74,0x0f,0xc5,0xfd,0xd7,0xc1,0xd3,0xf8,0x85,0xc0,0x74,0x1b,0xf3,0x0f,0xbc,0xc0,0x48,0x01,0xf8,0x48"
 -ex quit /sbin/init --core core.1
Reading symbols from /sbin/init...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init'.
#0  0x7f5a8f67fb77 in epoll_wait (epfd=4, events=0x7ffc0f899920, 
maxevents=52, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30  ../sysdeps/unix/sysv/linux/epoll_wait.c: Datei oder Verzeichnis nicht 
gefunden.
0x7f5a8f6de7a7 <__rawmemchr_avx2+55>
0x7f5a8f6e2647 <__strlen_avx2+55>
warning: Unable to access 1487 bytes of target memory at 0x7f5a8f6ee1dd, 
halting search.
2 patterns found.




root@debian:~# gdb -q -ex "set pagination off" -ex "x/64bx 0x7f5a8f6e2647-42" 
-ex "disassemble 0x7f5a8f6e2647-42,0x7f5a8f6e2647+22" /sbin/init --core core.1
Reading symbols from /sbin/init...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 1]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/sbin/init'.
#0  0x7f5a8f67fb77 in epoll_wait (epfd=4, events=0x7ffc0f899920, 
maxevents=52, timeout=-1) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30
30  ../sysdeps/unix/sysv/linux/epoll_wait.c: Datei oder Verzeichnis nicht 
gefunden.
0x7f5a8f6e261d <__strlen_avx2+13>:  0xf90x200x770x1f0xc5
0xfd0x740x0f
0x7f5a8f6e2625 <__strlen_avx2+21>:  0xc50xfd0xd70xc10x85
0xc00x0f0x85
0x7f5a8f6e262d <__strlen_avx2+29>:  0xdf0x000x000x000x48
0x830xc70x20
0x7f5a8f6e2635 <__strlen_avx2+37>:  0x830xe10x1f0x480x83
0xe70xe00xeb
0x7f5a8f6e263d <__strlen_avx2+45>:  0x360x660x900x830xe1
0x1f0x480x83
0x7f5a8f6e2645 <__strlen_avx2+53>:  0xe7

Bug#916678: systemd: Caught , dumped core as pid 2097

[Bernhard Übelacker]

Hello Cristian Ionescu-Idbohrn,

Am 18.12.2018 um 09:35 schrieb Cristian Ionescu-Idbohrn:
> On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
>>
>> Hello Cristian Ionescu-Idbohrn,
>> following is what I get from a buster amd64 qemu VM,
>> with explicitly downgraded systemd packages to 239-13:
>>
>> It has quite a similarity to upstream bug [1].
>> And upstream received a fix for that just a few days ago,
>> and is therefore not yet contained in an upstream release.
> 
> Thanks.  So, this bug is present in 239-15 too and can bite again, 
> isn't it?

If this is really the same issues I assume yes.
Nothing in the changelog entries for -14 and -15 sound related.

I can assume this backtrace contains no private information and
could be forwarded to the bug?

>> [1] https://github.com/systemd/systemd/issues/10716
>>
>> (gdb) bt
>> #0  0x7f2d9386bb37 in kill () at ../sysdeps/unix/syscall-template.S:78
>> #1  0x561672b85436 in crash (sig=11) at ../src/core/main.c:183
>> #2  
>> #3  __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:93
>> #4  0x7f2d93680cb7 in message_append_basic (m=m@entry=0x561674c79870, 
>> type=, p=0x, stored=stored@entry=0x0) at 
>> ../src/basic/string-util.h:36
>> #5  0x7f2d936812ab in sd_bus_message_append_basic 
>> (m=m@entry=0x561674c79870, type=, p=) at 
>> ../src/libsystemd/sd-bus/bus-message.c:1565
>> #6  0x7f2d93681719 in sd_bus_message_appendv (m=0x561674c79870, 
>> types=, ap=ap@entry=0x7ffcabd85950) at 
>> ../src/libsystemd/sd-bus/bus-message.c:2358
>> #7  0x7f2d93681cf9 in sd_bus_message_append (m=, 
>> types=) at ../src/libsystemd/sd-bus/bus-message.c:2473
>> #8  0x561672b01daf in send_removed_signal (bus=0x561674bb3130, 
>> userdata=0x561674c144f0) at ../src/core/job.c:1565
>> #9  0x561672b71dbf in bus_foreach_bus (m=0x561674ab5830, 
>> subscribed2=0x0, send_message=0x561672b01d00 , 
>> userdata=0x561674c144f0) at ../src/core/dbus.c:1187
>> #10 0x561672b03f78 in bus_job_send_removed_signal (j=, 
>> j=) at ../src/core/dbus-job.c:225
>> #11 0x561672b8300e in manager_flush_finished_jobs (m=) at 
>> ../src/core/manager.c:3359
>> #12 manager_reload (m=0x561674ab5830) at ../src/core/manager.c:3477
>> #13 invoke_main_loop (m=0x561674ab5830, ret_reexecute=0x7ffcabd85c2a, 
>> ret_retval=0x7ffcabd85c2c, ret_shutdown_verb=, 
>> ret_fds=0x7ffcabd85c30, ret_switch_root_dir=0x7ffcabd85c58, 
>> ret_switch_root_init=0x7ffcabd85c50, ret_error_message=0x7ffcabd85c40) at 
>> ../src/core/main.c:1661
>> #14 0x561672ae4620 in main (argc=, argv=0x7ffcabd85f08) 
>> at ../src/core/main.c:2415

Kind regards,
Bernhard

Bug#916678: systemd: Caught , dumped core as pid 2097

[Cristian Ionescu-Idbohrn]

On Tue, 18 Dec 2018, Michael Biebl wrote:
> 
> first, thanks a lot Bernhard for providing a properly annotated 
> backtrace! It does indeed look very similar to the one in [1]

Agreed.

> Am 18.12.18 um 18:45 schrieb Bernhard Übelacker:
> > Am 18.12.2018 um 09:35 schrieb Cristian Ionescu-Idbohrn:
> >> On Mon, 17 Dec 2018, Bernhard Übelacker wrote:
> >>>
> >>> Hello Cristian Ionescu-Idbohrn,
> >>> following is what I get from a buster amd64 qemu VM,
> >>> with explicitly downgraded systemd packages to 239-13:
> >>>
> >>> It has quite a similarity to upstream bug [1].
> >>> And upstream received a fix for that just a few days ago,
> >>> and is therefore not yet contained in an upstream release.
> >>
> >> Thanks.  So, this bug is present in 239-15 too and can bite again, 
> >> isn't it?
> > 
> > If this is really the same issues I assume yes.
> > Nothing in the changelog entries for -14 and -15 sound related.
> 
> Correct. The PR fixing #10716 has not been backported.
> It's quite invasive, so I wouldn't really feal comfortable doing that
> and it would be quite some effort.

Still, your choice.  As said, it might bite us again :(

> > I can assume this backtrace contains no private information and
> > could be forwarded to the bug?
> 
> Would be great to have this private discussion added to the bug report.

Please, feel free to do that.


Cheers,

-- 
Cristian

Bug#910084: please update to caja release 1.20.3 as it apparently does remove some of the segfaults and memory leaks.

[shirish शिरीष]

Dear Maintainer,

See 
https://github.com/mate-desktop/caja/commit/56d9ca7e79e7f3ccf2f43d9b4ee9911d593055a1

Specifically these parts seem to be interesting -

* Fix segfault on stopping USB hard drives
* fm-properties-window: Fix memory leaks
* caja-desktop-link-monitor: Fix memory leak

At the very least it would caja usable on linux and should also
improve the life of existing external drives. Currently it doesn't
save files cleanly due to the segfault.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#916267: libgtk-3-0: Cannot print to IPP printers from the GTK dialog

[Brian Potkin]

severity 916267 wishlist
thanks


On Wed 12 Dec 2018 at 12:11:16 +, Brian Potkin wrote:

> On Wed 12 Dec 2018 at 11:28:41 +, Simon McVittie wrote:
> 
> > Control: severity -1 important
> > 
> > On Wed, 12 Dec 2018 at 11:20:04 +, Brian Potkin wrote:
> > > Justification: renders IPP printers unusable without other packages (CUPS 
> > > and cups-browsed)
> > 
> > This sounds like an important bug, but it does not make GTK+ entirely
> > useless (you can still use graphical applications that don't involve
> > printing, or print via CUPS), so it isn't grave.
> 
> Fair enough.

Gtk can detect IPP printers and display one of them with rp=ipp/print in
the TXT record. The issue is whether GTK is designed to print to such a
printer. From my point of view it obviously is not. Hence reducing the
severity.

Rather a shame these days considering the prevelance of IPP printers on
the market.

Cheers,

Brian.

Bug#915061: Why does Debian even change the version compared to upstream?

[Max Horn]

> Am 18.12.2018 um 20:59 schrieb Bill Allombert :
> 
>> On Tue, Dec 18, 2018 at 05:07:14PM +0100, Max Horn wrote:
>> Hi Bill,
>> 
>>> GAP used 4rxpy as version number for a long time.
>> 
>> I can not find any evidence supporting this. Even GAP 2 and 3 used
>> x.y.z, as can be seen e.g. here:
>>  or here
>> .
>> 
>> As fas as I know, the only place the r and p were ever used was in the
>> archive names. And I am pretty sure the reason for this was that on
>> the Atari ST, the TOS file system (which essentially was FAT)
>> restricted file names to 8.3 format, with no periods allowed in the
>> filename, other than for the file extension. Hence the substitution,
>> eg to gap3r4p4.zoo which fits exactly into the 8.3 limit.
> 
> Looking at my archives, it seems I am actually responsible for the error. 
> The confusion stem from the archive file which was named gap4r3n3 (with a n)
> that unpacked to a directory 'gap4r3'.
> 
> i will fix that for GAP 4.11.

Awesome, thank you!
> 
> I assume it is the same for GAP packages versions ?

Yes, indeed.

Cheers,
Max

> 
> Cheers,
> -- 
> Bill. 
> 
> Imagine a large red swirl here. 
> 

Bug#544651: lvm2: Volume group not found, unable to find LVM during boot

[Smo Oey]

On Wed, 08 Jun 2016 17:24:18 +0300 Teemu Likonen  wrote:
> Ertuğrul Harman [2015-08-08 23:51:11+03] wrote:
>
> > During every boot time after a fresh installation of debian jessie, I
> > get following errors after grub screen passes:
> >
> > Volume group "ert-debian-vg" not found.
> > Skipping volume group "ert-debian-vg"
> > Unable to find LVM "volume ert-debian-vg/root"
> > Volume group "ert-debian-vg" not found
> > Skipping volume group "ert-debian-vg"
> > Unable to find LVM "volume ert-debian-vg/swap_1"
> > Please unlock disk sd3_crypt:
> >
> > I enter my password and boot continues.
>
> Just another user here. This cosmetic bug has always been in Debian.
> LVM inside encrypted partition causes those errors.
>
> It seems that bugs #794971 and #544651 are the same.
>
> I guess the error message can be removed just by removing one echo
> command from file /usr/share/initramfs-tools/scripts/local-top/lvm2.

I was very much wanting to come over to the world of Debian, but this
guy's reply is a huge turn off. Sweeping a bug or hiding a "bug" isn't
fixing it... I just tried installing Debian 9.6 with Luks on LVM and
got similar error /warning message. I've been searching like crazy to
find proper guides (without graphical installer) on how to setup the
luks on lvm and most are foreign speaking people and can't understand
nothing. Then to find this shit in bug reports... come on man. Forget
Debian then, I'll use another linux distro where people actually fix
bugs, not sweep them under rug or hide them.

Bug#896811: icinga2 2.6.0-2+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

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

Thanks for your contribution!

Upload details
==

Package: icinga2
Version: 2.6.0-2+deb9u1

Explanation: fix timestamps being stored as local time in PostgreSQL

Bug#892031: wayland 1.12.0-1+deb9u1 flagged for acceptance

[Adam D Barratt]

Control: tags -1 + pending

Hi,

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

Thanks for your contribution!

Upload details
==

Package: wayland
Version: 1.12.0-1+deb9u1

Explanation: fix possible integer overflow [CVE-2017-16612]

Bug#906982: sysbench: FTBFS on armhf

[JCF Ploemen]

Meanwhile the package built successfully on ubuntu disco armhf, see
https://launchpad.net/ubuntu/+source/sysbench/1.0.15+ds-1/+build/15588300


pgpANDW5AqePq.pgp
Description: OpenPGP digital signature

Bug#915061: Why does Debian even change the version compared to upstream?

[Bill Allombert]

On Tue, Dec 18, 2018 at 05:07:14PM +0100, Max Horn wrote:
> Hi Bill,
> 
> > GAP used 4rxpy as version number for a long time.
> 
> I can not find any evidence supporting this. Even GAP 2 and 3 used
> x.y.z, as can be seen e.g. here:
>  or here
> .
> 
> As fas as I know, the only place the r and p were ever used was in the
> archive names. And I am pretty sure the reason for this was that on
> the Atari ST, the TOS file system (which essentially was FAT)
> restricted file names to 8.3 format, with no periods allowed in the
> filename, other than for the file extension. Hence the substitution,
> eg to gap3r4p4.zoo which fits exactly into the 8.3 limit.

Looking at my archives, it seems I am actually responsible for the error. 
The confusion stem from the archive file which was named gap4r3n3 (with a n)
that unpacked to a directory 'gap4r3'.

i will fix that for GAP 4.11.

I assume it is the same for GAP packages versions ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#911443: linux-image-4.18.0-2-arm64: wlan0 no longer present

[Uwe Kleine-König]

Control: tag 911443 + pending

I just added the commit from v4.20-rc7 that fixes this problem to the
Linux package git repository. It will be part of the next upload of
v4.19.x to unstable.

https://deb.li/lpFA

Best regards
Uwe

Bug#915006: theme-d: Please switch to guile-2.2

[Jeremy Bicha]

On 29.11.2018 14:21, Jeremy Bicha wrote:
> Please build with guile-2.2 instead of guile-2.0. The guile maintainer
> would eventually like to remove guile-2.0 from Debian.
>
> Once you have uploaded the change, we'll need to file a bug to remove
> the armel binaries like https://bugs.debian.org/915000

Tommi, could you file a bug like that for theme-d now? It is necessary
for the armel package to be removed for your package to migrate to
Testing.

Feel free to use "ROM" (request of maintainer) instead of "RoQA" in
the subject line. The subject line's syntax is important because it is
used to automatically update
https://ftp-master.debian.org/removals.html

Thanks,
Jeremy Bicha

Bug#916306: gitlab: Error during gitlab installation

[Pranith Kumar]

On Mon, Dec 17, 2018 at 11:45 PM Pirate Praveen
 wrote:

>
> I think it is trying to use the previous bundler configuration. Try
> purging gitlab and reinstall (make sure /var/lib/gitlab and
> /usr/share/gitlab* are really removed).
>

This doesn't work. I purged gitlab and removed gitlab-shell directory
in /usr/share. However, it still asks for sudo password.

-- 
Pranith

Bug#915975: please package and release new version of telegram desktop version 1.4.8

[Коля Гурьев]

Control: retitle -1 please package and release new version of telegram desktop 
version 1.5.2
Control: tag -1 pending

John Preston has released a new version of Telegram Desktop last week.
Now a merge request[1] with update is under review. And I hope it will
be uploaded soon.

 [1]: https://salsa.debian.org/debian/telegram-desktop/merge_requests/5

Bug#914286: new stable upstream version 1.3 available

[Kevin Otte]

I just saw the news post about the Installer Buster Alpha 4 release.
Does this mean the freeze is coming soon? Do we need an NMU of this
package to make sure we don't have yet another Debian release with an
alpha/beta version of Opus in it?

Bug#916802: RM: kvpm -- RoQA; unmaintained, requires to-be-removed library

[Bastian Blank]

Package: ftp.debian.org
Severity: normal

Please remove kvpm from unstable.  It is NMU maintained while maintainer
is also upstream.  Last upstream change was two years ago.  It depends
on liblvm2app, which is going away pretty soon, see #915690.

Regards,
Bastian

Bug#916801: manpages-fr: mistranslation in sincos(3)

[Nicolas Cavallari]

Package: manpages-fr
Version: 3.65d1p1-1
Severity: minor
Tags: patch l10n

sincos(3) says:
"If x is a NaN, a NaN is returned in *sin and *cos."
it is translated as:
"Si x n'est pas un NaN, un NaN est renvoyé dans *sin et *cos."

which means the opposite: "If x is not a NaN, a NaN is returned..."

(In addition, the alioth links in the 'TRADUCTION' section are dead)

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

Kernel: Linux 4.18.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to fr_FR.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

manpages-fr depends on no packages.

manpages-fr recommends no packages.

Versions of packages manpages-fr suggests:
ii  man-db [man-browser]  2.8.4-3
ii  manpages-fr-dev   3.65d1p1-1
ii  manpages-fr-extra 20151231

-- no debconf information
--- a/perkamon-fr/po4a/math/po/fr.po
+++ b/perkamon-fr/po4a/math/po/fr.po
@@ -9614,7 +9614,7 @@
 #. type: Plain text
 #: build/C/man3/sincos.3:15
 msgid "If I is a NaN, a NaN is returned in I<*sin> and I<*cos>."
-msgstr "Si I n'est pas un NaN, un NaN est renvoyé dans I<*sin> et I<*cos>."
+msgstr "Si I est un NaN, un NaN est renvoyé dans I<*sin> et I<*cos>."
 
 #. type: Plain text
 #: build/C/man3/sincos.3:16

Bug#916683: libgnutls30: breaks msmtp 1.6.7-1

[Andreas Metzler]

On 2018-12-17 Jonas Smedegaard  wrote:
> Quoting Andreas Metzler (2018-12-17 19:37:05)
[msmtp / GnuTLS 3.6 breaks]
>> FWIW I have had successful connections against exim4 (gnutls 3.5 and 
>> 3.6). Which host are you trying to connect to?

> Sorry for exaggerating!

Not at all.

> The hosts I experienced problems with are mail.jones.dk and 
> mail.homebase.dk - both running Postfix on Debian stable (which made me 
> rule out them as cause for blame, but...) both of them managed by myself 
> with various attempts at tightening security, so I realize now that I 
> may possibly have exposed bugs in unusual setups rather than common 
> ones.

It might be the other way round, GnuTLS servers the only ones not
triggering the issue.

> Both systems are running in production so I am not happy doing drastic 
> experiments on them - but on the other hand they are public accessible 
> so available for testing this bug if needed.

Thanks! FWIW as a temporary workaround you can invoke msmtp with
--tls-priorities=NORMAL:-VERS-TLS1.3

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#916791: [Pkg-utopia-maintainers] Bug#916791: firewalld: nftables backend not happy with --set-log-denied={unicast, broadcast, multicast}

[Michael Biebl]

Hi Sam!


Am 18.12.18 um 17:08 schrieb Sam Morris:
> 
> firewalld doesn't seem to be happy with any log setting other than 'all'
> and 'off'.
> 
> # firewall-cmd --set-log-denied=unicast
> # journalctl -u firewalld -e

This sounds a lot like
https://github.com/firewalld/firewalld/pull/410

This was committed post v0.6.3.
If it's urgent, I can make a cherry-pick for this fix, otherwise I'd
just wait for the 0.6.4 release.


Regards,
Michael




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#916764: znc-backlog: overly strict dependency on znc?

[Andreas Beckmann]

On 2018-12-18 18:13, Felipe Sateler wrote:
> Hi,
> On Tue, Dec 18, 2018 at 8:33 AM Andreas Beckmann  wrote:
> 
>> Package: znc-backlog
>> Version: 0.20170713-1
>> Severity: serious
>>
> 
> Hmm, not sure this is warranted.

It's currently uninstallable in sid.
Instead of requesting a binNMU (and doing so everytime znc changes), I
asked this question here.

>> do you really need a dependency on the exact binary version of znc
>> available at the build time of znc-backlog? I.e., every time znc
>> gets uploaded *or binNMUed*, a binNMU of znc-backlog is needed, too.
>> Wouldn't a dependency computed from the upstream version be sufficient?
>> E.g. znc (>= ${znc:upstreamversion}), znc (<< ${znc:upstreamversion}+)
>>
>>
> I'm using the same as the znc plugins shipped by znc itself. AFAIK, the znc
> ABI is not stable, so backporting an upstream patch could potentially break
> other plugins.

But that's unlikely to happen on binNMUs, isn't it?

> Perhaps znc could Provide: znc-plugin-$somenumber, which could be used by
> out-of-tree plugins? Adding the znc maintainers to the loop for their input

That's being used successfully by some packages ...


Andreas