Bug#886383: bugwarrior: phabricator import fails due to no issues found (= undefined 'issue' dict)

[Nicolas Schier]

Package: bugwarrior
Version: 1.5.1-2
Severity: normal
Tags: patch

Dear maintainer(s),

I have added these lines to my ~/.config/bugwarrior/bugwarriorrc
attempting to import my issues from our phabricator instance (even
though I still not have any):

[phabricator]
phabricator.only_if_assigned = PHID-USER-7yut3lpslyc2mmm5mxuj,NSchier
phabricator.user_phids = PHID-USER-7yut3lpslyc2mmm5mxuj
#phabricator.project_phids = PHID-PROJ-wak4hlhspgyjxgx4ibsg
service = phabricator

(The 'project_phids' setting is disabled, as the local installation does
not provide the required API (that could make up yet another bug report,
as the error is not catched).)

When running 'bugwarrior-pull', I get this output:

$ bugwarrior-pull --dry-run
INFO:bugwarrior.db:Service-defined UDAs exist: you can optionally use 
the `bugwarrior-uda` command to export a list of UDAs you can add to your 
taskrc file.
INFO:bugwarrior.services:Starting to aggregate remote issues.
INFO:bugwarrior.services:Spawning 1 workers.
INFO:bugwarrior.services:Working on [phabricator]
INFO:bugwarrior.services.phab:Found 0 issues
INFO:bugwarrior.services.phab:Found 39 differentials
ERROR:bugwarrior.services:Worker for [phabricator] failed: local 
variable 'issue' referenced before assignment
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/bugwarrior/services/__init__.py", line 506, in 
_aggregate_issues
for issue in service.issues():
  File "/usr/lib/python3/dist-packages/bugwarrior/services/phab.py", 
line 147, in issues
project = projects.get(issue['projectPHIDs'][0], project)
UnboundLocalError: local variable 'issue' referenced before assignment
INFO:bugwarrior.services:Done with [phabricator] in 0.116974s
INFO:bugwarrior.services:Terminating workers
'type': 'issue',
CRITICAL:bugwarrior.command:Aborted (critical error in target 
'phabricator')

Without really knowing what I'm doing, I simply patched the
'bugwarrior/services/phab.py' and can now import the stuff I want to
have:

$ bugwarrior-pull
INFO:bugwarrior.db:Service-defined UDAs exist: you can optionally use 
the `bugwarrior-uda` command to export a list of UDAs you can add to your 
taskrc file.
INFO:bugwarrior.services:Starting to aggregate remote issues.
INFO:bugwarrior.services:Spawning 1 workers.
INFO:bugwarrior.services:Working on [phabricator]
INFO:bugwarrior.services.phab:Found 0 issues
INFO:bugwarrior.services.phab:Found 39 differentials
INFO:bugwarrior.services:Done with [phabricator] in 0.119559s
INFO:bugwarrior.services:Done aggregating remote issues.
INFO:bugwarrior.db:Adding 2 tasks
INFO:bugwarrior.db:Adding task (bw)PR#D3625 - ARM: etc/scripts/p...
INFO:bugwarrior.db:Adding task (bw)PR#D3448 - Reduce compilation 
warnings
INFO:bugwarrior.db:Updating 0 tasks
INFO:bugwarrior.db:Closing 0 tasks

I don't know, if the patch breaks something, when there are issues
found...  but for me it works with that patch, currently.

Kind regards,
Nicolas


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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=nb:nn:dk:se:de:en:C, LC_CTYPE=nb:nn:dk:se:de:en:C (charmap=UTF-8) 
(ignored: LC_ALL set to nb_NO.UTF-8), LANGUAGE=nb_NO.UTF-8 (charmap=UTF-8) 
(ignored: LC_ALL set to nb_NO.UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages bugwarrior depends on:
ii  libjs-sphinxdoc1.6.5-4
ii  python33.6.4-1
ii  python3-click  6.7-2
ii  python3-dateutil   2.6.1-1
ii  python3-dogpile.cache  0.6.2-5
ii  python3-future 0.15.2-4
ii  python3-jinja2 2.10-1
ii  python3-lockfile   1:0.12.2-2
ii  python3-requests   2.18.1-1
ii  python3-six1.11.0-1
ii  python3-taskw  1.2.0-1
ii  python3-tz 2017.2-2

Versions of packages bugwarrior recommends:
ii  python3-keyring  10.5.1-1
ii  python3-phabricator  0.7.0-1

bugwarrior suggests no packages.

-- no debconf information
diff --git a/bugwarrior/services/phab.py b/bugwarrior/services/phab.py
index 37155fa..bca942d 100644
--- a/bugwarrior/services/phab.py
+++ b/bugwarrior/services/phab.py
@@ -97,6 +97,7 @@ class PhabricatorService(IssueService):
 
 log.info("Found %i issues" % len(issues))
 
+issue = {'projectPHIDs': []}
 for phid, issue in issues:
 
 project = self.target  # a sensible default

Bug#802919: version bump to unison-2.48.4

[Benda Xu]

Benda Xu  writes:

> Thank you for your comments and diagnosis.  But the bug does not go away
> by itself.  If you are too busy to bump it, please speak out explicitly.
> We are willing to help maintaining unison.

Sorry I have overlooked the upload of unison-2.48.4 on 30 Oct 2017.  The
version 2.48.4 works well.  Thanks for your efforts, Stéphane.

Shall we close this bug?

Yours,
Benda

Bug#886382: Coming updates for meltdown/spectre

[Louis-Philippe Véronneau]

Package: amd64-microcode
Severity: grave

It seems AMD cpus are also affected by the meltdown/spectre bugs.

Do you know if AMD plans to release microcode updates and if so, will it
be packaged here?

(intel bug, for ref):

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

-- 
pollo



signature.asc
Description: OpenPGP digital signature

Bug#886343: lintian: missing-notice-file-for-apache-license false positives

[Ferenc Wágner]

Chris Lamb  writes:

> Thanks for the report. I have fixed this in Git:
>   
> https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=28028299a402eb8d87176a537facc437ab89b6c6

Wow, that was quick!
-- 
Thanks,
Feri

Bug#886362: openmw FTBFS on armel/armhf: error: 'GL_AMBIENT' was not declared in this scope

[bret curtis]

We've been wrestling with this for ages now, because libqt5opengl5-dev
behaves differently on arm64 than on armel, can you guarantee that
changing the dep to libqt5opengl5-desktop-dev will force to build
against opengl and not gles2?

If that is the case, then we can also begin shipping openmw-cs against
on armel. :)

Cheers,
Bret

On Thu, Jan 4, 2018 at 10:55 PM, Adrian Bunk  wrote:
> Source: openmw
> Version: 0.43.0-2
> Severity: important
>
> https://buildd.debian.org/status/package.php?p=openmw=sid
>
> ...
> /<>/components/sceneutil/lightmanager.cpp: In member function 
> 'void SceneUtil::LightStateAttribute::applyLight(GLenum, const osg::Light*) 
> const':
> /<>/components/sceneutil/lightmanager.cpp:78:34: error: 
> 'GL_AMBIENT' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   ^~
> /<>/components/sceneutil/lightmanager.cpp:78:34: note: suggested 
> alternative: 'GL_BLEND'
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>   ^~
>   GL_BLEND
> /<>/components/sceneutil/lightmanager.cpp:78:13: error: 
> 'glLightfv' was not declared in this scope
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>  ^
> /<>/components/sceneutil/lightmanager.cpp:78:13: note: suggested 
> alternative: 'mLights'
>  glLightfv( lightNum, GL_AMBIENT,   
> light->getAmbient().ptr() );
>  ^
>  mLights
> ...
>
>
> Ideally it should be made working to build when Qt is using
> OpenGL ES, bug if that is not possible it would be better to
> avoid the FTBFS by changing the build dependency from
> libqt5opengl5-dev to libqt5opengl5-desktop-dev.

Bug#880407: #880407 xterm: font issue with FreeType 2.8; should not use the rounded ascender and descender

[Vincent Lefevre]

Control: reopen -1
Control: found -1 331-1
Control: tags -1 - fixed-upstream

On 2017-12-30 14:53:27 -0500, Thomas Dickey wrote:
> I investigated, found that it is a defect in FreeType.
> None of the comments in 
> 
>   https://savannah.nongnu.org/bugs/?52165
> 
> were helpful (some of the information is incorrect).
> 
> I made a workaround for this problem in patch #331.

It still has the same problems: xterm higher than before for the
same number of text lines, and a black line between text lines.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#802919: version bump to unison-2.48.4

[Benda Xu]

severity 802919 important
thanks

Hello Stéphane (the *uploader* of unison),

Regarding this bug has actually rendered unison unusable without manual
compilation, and unison-2.48.4 has been released, could *you* please
bump unison to 2.48.4?  This will give us a rebuild of latest unison
against ocaml-4.05.

Thank you for your comments and diagnosis.  But the bug does not go away
by itself.  If you are too busy to bump it, please speak out explicitly.
We are willing to help maintaining unison.

Cheers,
Benda

Bug#886374: texlive-latex-extra and emboss: error when trying to install together

[Norbert Preining]

> dpkg: error processing archive 
> /var/cache/apt/archives/texlive-latex-extra_2017.20180103-1_all.deb 
> (--unpack):
>  trying to overwrite '/usr/bin/wordcount', which is also in package emboss 
> 6.6.0+dfsg-6+b1

I renamed the TeX wordcount to
  latex-wordcount

Norbert

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

Bug#886264: firefox-esr: FTBFS on ppc64el

[Mike Hommey]

reassign 886264 binutils
thanks

On Fri, Jan 05, 2018 at 12:03:32PM +0900, Mike Hommey wrote:
> On Wed, Jan 03, 2018 at 03:45:45PM +, Julian Gilbey wrote:
> > Package: firefox-esr
> > Version: 52.5.3esr-1
> > 
> > This is the second version of firefox-esr in a row which has a
> > build-failure on ppc64el, meaning that this package cannot migrate to
> > testing.  There was a security fix in 52.5.2esr-1, so it would be very
> > good to attempt to address this.
> > 
> > Sadly, I don't have any idea how the firefox build works or what might
> > be causing the problem, so I don't know how to help fix this one.
> 
> The part of the build that's broken is running parts of Firefox. That
> suggests firefox would not work even if the build succeeded (like, if we
> skipped that part).
> 
> Now, there hasn't been code changes in Firefox since the last time it
> built successfully that could explain this. However, the two failures
> are with a newer version of GCC, which apparently touched PPC codegen.
> 
> IOW, this could be a legitimate GCC bug. Or this could be a legitimate
> GCC bug fix that breaks Firefox somehow. I'm trying to reproduce on a
> porterbox to try and see which it might be (sadly can't install older
> versions of GCC, though).

Another variation is a difference in binutils version, which also has
ppc64 changes.

As for what's crashing, it's happening in one of the first static
initializers (second entry in .init_array).

The code looks like this:
01322050 <._GLOBAL__sub_I_Unified_cpp_media_libstagefright1.cpp>:
 1322050:   7c 08 02 a6 mflrr0
 1322054:   f8 01 00 10 std r0,16(r1)
 1322058:   fb c1 ff f0 std r30,-16(r1)
 132205c:   fb e1 ff f8 std r31,-8(r1)
 1322060:   f8 21 ff 81 stdur1,-128(r1)
 1322064:   3f c2 00 05 addis   r30,r2,5
 1322068:   3b de 25 b8 addir30,r30,9656
 132206c:   7f c3 f3 78 mr  r3,r30
 1322070:   48 02 57 ad bl  134781c 
<._ZN11stagefright9AAtomizerC2Ev>
(snip)

0134781c <._ZN11stagefright9AAtomizerC2Ev>:
 134781c:   7c 08 02 a6 mflrr0
 1347820:   49 11 10 11 bl  2458830 <0008b362._restgpr0_15>
(snip)

02458830 <0008b362._restgpr0_15>:
 2458830:   e9 e1 ff 78 ld  r15,-136(r1)

02458834 <0008b362._restgpr0_16>:
 2458834:   ea 01 ff 80 ld  r16,-128(r1)

02458838 <0008b362._restgpr0_17>:
 2458838:   ea 21 ff 88 ld  r17,-120(r1)

0245883c <0008b362._restgpr0_18>:
 245883c:   ea 41 ff 90 ld  r18,-112(r1)

02458840 <0008b362._restgpr0_19>:
 2458840:   ea 61 ff 98 ld  r19,-104(r1)

02458844 <0008b362._restgpr0_20>:
 2458844:   ea 81 ff a0 ld  r20,-96(r1)

02458848 <0008b362._restgpr0_21>:
 2458848:   ea a1 ff a8 ld  r21,-88(r1)

0245884c <0008b362._restgpr0_22>:
 245884c:   ea c1 ff b0 ld  r22,-80(r1)

02458850 <0008b362._restgpr0_23>:
 2458850:   ea e1 ff b8 ld  r23,-72(r1)

02458854 <0008b362._restgpr0_24>:
 2458854:   eb 01 ff c0 ld  r24,-64(r1)

02458858 <0008b362._restgpr0_25>:
 2458858:   eb 21 ff c8 ld  r25,-56(r1)

0245885c <0008b362._restgpr0_26>:
 245885c:   eb 41 ff d0 ld  r26,-48(r1)

02458860 <0008b362._restgpr0_27>:
 2458860:   eb 61 ff d8 ld  r27,-40(r1)

02458864 <0008b362._restgpr0_28>:
 2458864:   eb 81 ff e0 ld  r28,-32(r1)

02458868 <0008b362._restgpr0_29>:
 2458868:   e8 01 00 10 ld  r0,16(r1)
 245886c:   eb a1 ff e8 ld  r29,-24(r1)
 2458870:   7c 08 03 a6 mtlrr0
 2458874:   eb c1 ff f0 ld  r30,-16(r1)
 2458878:   eb e1 ff f8 ld  r31,-8(r1)
 245887c:   4e 80 00 20 blr

The crash occurs on that blr, because lr has a wrong value once here. I
don't know much of ppc, but it seems this is due to the combination of
  2458868:   e8 01 00 10 ld  r0,16(r1)
and
  2458870:   7c 08 03 a6 mtlrr0

It seems the ld r0,16(r1) is out of place there.

Now, the interesting thing is that the .o the
._ZN11stagefright9AAtomizerC2Ev function comes from looks like:

 <._ZN11stagefright9AAtomizerC1Ev>:
   0:   7c 08 02 a6 mflrr0
   4:   48 00 00 01 bl  4 <._ZN11stagefright9AAtomizerC1Ev+0x4>
4: R_PPC64_REL24_savegpr0_28

and that has a different address:
02458814 l   .text    
0008b362._savegpr0_28

And the code there looks like:
02458814 <0008b362._savegpr0_28>:
 2458814:   fb 81 ff e0 std r28,-32(r1)

02458818 <0008b362._savegpr0_29>:
 2458818:   fb a1 ff e8 std r29,-24(r1)

0245881c <0008b362._savegpr0_30>:
 245881c:   fb c1 ff f0 std r30,-16(r1)

02458820 <0008b362._savegpr0_31>:
 2458820:   

Bug#886381: update for spectre/meltdown (57.0.4)

[Daniel Baumann]

Package: firefox
Severity: important

Hi,

mozilla released firefox 57.0.4 to somewhat mitigate the recent
spectre/meltdown CPU bugs. It would be nice if you could upgrade the
package to that version.

Regards,
Daniel

Bug#884230: texlive-base: cmbcsc10 moved to texlive-fonts-extra

[Norbert Preining]

> Oh dear:

> Need to get 336 MB/343 MB of archives.
> After this operation, 960 MB of additional disk space will be used.

I know. The problem is old and known, namely that many TeX documents
search fonts not via fontconfig but via file name, and thus the fonts
have to be in the texmf tree (at least as links to the actual files).
THis *has* losts of advantages because fontconfig often messes up font
selection when large sets of fonts (osc, expert, ...) are available.

I am contemplating a different solution now (separate package
texlive-fontlinks that ships the links and dependencies, but is not
automatically installed).

Norbert

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

Bug#882247:

[Marco d'Itri]

On Jan 05, Mike Hommey  wrote:

> There is something wrong with the default locale. Try installing a
> locale package (even firefox-l10n-en-gb) or downgrade to 57.
Confirmed, this fixes it.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#867081: autopkgtest: @ no longer pulls in packages with versioned Provides

[gregor herrmann]

On Mon, 31 Jul 2017 23:59:04 +0300, Niko Tyni wrote:

> > As seen on ci.debian.net with for instance libhttp-tiny-perl and
> > libcpan-meta-perl, autopkgtest gets confused about versioned Provides
> > that were introduced in sid recently with perl_5.24.1-5.
> > 
> > It looks like "Depends: @" will no longer pull in the binary packages
> > to be tested if the same name is also Provided by installed packages
> > with a version.
> > 
> > My reading of the autopkgtest code is that it synthesizes a dependency
> > on 'package (>= 0~)', where the versioning is assumed to guarantee that
> > only a real package gets pulled in. This assumption no longer holds with
> > versioned Provides.
> 
> Oh, I'd mostly forgotten about #761003 which introduced the '(>= 0~)'
> thing three years ago and where we predicted that this will break with
> versioned Provides.
> 
> The solution we discussed there was to insert an additional explicit
>  apt-get install 
> phase to the autopkgtest-satdep.deb installation (which unpacks a
> temporary package and then calls 'apt-get --fix-missing' to have apt solve
> the dependencies.)
> 
> This explicit call prefers real packages to virtual ones (at least in
> all my tests though I can't find this documented; possibly this should
> be checked with the apt maintainers.)
> 
> Is this approach something you would consider now that the versioned
> Provides issue has materialized in practice?

Hi autopkgtest maintainers!

AFAIK, this bug is the last blocker for using versioned provides in
the perl world, which would be a big help for us.

Did you have a chance to take a look? Is there anything we could do
to help?


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Element Of Crime: Die Hoffnung die du bringst


signature.asc
Description: Digital Signature

Bug#886380: stretch-pu: package opendmarc/1.3.2-2+deb9u1

[Scott Kitterman]

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

As released, opendmarc doesn't read it's configuration file which
substantially limits the packages usefullness as packaged/released.  The
attached debdiff changes the service file so the configuration file is
actually used and adjusts the configuration file to match the option values
previously hard coded in the service file.

This is very similar to a change I needed to make in opendkim that has gone
well as a stable update, so I believe this is very low risk.

The package is built and ready for upload.

Scott K
diff -u opendmarc-1.3.2/debian/changelog opendmarc-1.3.2/debian/changelog
--- opendmarc-1.3.2/debian/changelog
+++ opendmarc-1.3.2/debian/changelog
@@ -1,3 +1,12 @@
+opendmarc (1.3.2-2+deb9u1) stretch; urgency=medium
+
+  * Update opendmarc service file so changes in opendmarc.conf are used and
+update opendmarc.conf to match values previously hard-coded in the service
+file (Closes: #863612)
+- Thanks to Jack Bates for the patch
+
+ -- Scott Kitterman   Thu, 04 Jan 2018 20:47:48 -0500
+
 opendmarc (1.3.2-2) unstable; urgency=medium
 
   * Do not remove /etc/default/opendkim on upgrade since it is a conffile
diff -u opendmarc-1.3.2/debian/opendmarc.conf opendmarc-1.3.2/debian/opendmarc.conf
--- opendmarc-1.3.2/debian/opendmarc.conf
+++ opendmarc-1.3.2/debian/opendmarc.conf
@@ -12,13 +12,28 @@
 ##
 # FailureReports false
 
-PidFile /var/run/opendmarc.pid
+PidFile /var/run/opendmarc/opendmarc.pid
 
 ##  RejectFailures { true | false }
 ##  	default "false"
 ##
 RejectFailures false
 
+##  Socket socketspec
+##  	default (none)
+##
+##  Specifies the socket that should be established by the filter to receive
+##  connections from sendmail(8) in order to provide service.  socketspec is
+##  in one of two forms: local:path, which creates a UNIX domain socket at
+##  the specified path, or inet:port[@host] or inet6:port[@host] which creates
+##  a TCP socket on the specified port for the appropriate protocol family.
+##  If the host is not given as either a hostname or an IP address, the
+##  socket will be listening on all interfaces.  This option is mandatory
+##  either in the configuration file or on the command line.  If an IP
+##  address is used, it must be enclosed in square brackets.
+#
+Socket local:/var/run/opendmarc/opendmarc.sock
+
 ##  Syslog { true | false }
 ##  	default "false"
 ##
@@ -65,7 +80,7 @@
 ##  The process will be assigned all of the groups and primary group ID of
 ##  the named userid unless an alternate group is specified.
 #
-UserID opendmarc:opendmarc
+UserID opendmarc
 
 ## Path to system copy of PSL (needed to determine organizational domain)
 #
diff -u opendmarc-1.3.2/debian/opendmarc.service opendmarc-1.3.2/debian/opendmarc.service
--- opendmarc-1.3.2/debian/opendmarc.service
+++ opendmarc-1.3.2/debian/opendmarc.service
@@ -7,7 +7,7 @@
 Type=forking
 PIDFile=/var/run/opendmarc/opendmarc.pid
 User=opendmarc
-ExecStart=/usr/sbin/opendmarc -p local:/var/run/opendmarc/opendmarc.sock  -u opendmarc -P /var/run/opendmarc/opendmarc.pid
+ExecStart=/usr/sbin/opendmarc
 Restart=on-failure
 ExecReload=/bin/kill -USR1 $MAINPID
 

Bug#882247:

[Mike Hommey]

There is something wrong with the default locale. Try installing a
locale package (even firefox-l10n-en-gb) or downgrade to 57.

Mike

Bug#886379: imx-usb-loader: FTBFS on hurd-i386: PATH_MAX undeclared

[Aaron M. Ucko]

Source: imx-usb-loader
Version: 0~git20171026.138c0b25-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of imx-usb-loader for hurd-i386 (admittedly not a release
architecture) failed:

  imx_sdp.c:158:11: error: 'PATH_MAX' undeclared (first use in this function); 
did you mean 'INT8_MAX'?

The Hurd notoriously has no static PATH_MAX.  Best practice is
dynamically accommodating whatever you actually encounter, since
preallocated buffers are liable either to waste memory or to risk
truncation (or, worse, overflows).  However, if that's infeasible for
some reason, you can also look up _PC_PATH_MAX via pathconf or supply
a fallback constant definition (traditionally 4096).

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#886378: i2pd: FTBFS on m68k and sh4: -maes and -mavx unrecognized

[Aaron M. Ucko]

Source: i2pd
Version: 2.17.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-...@lists.debian.org
Usertags: m68k

Builds of i2pd for m68k and sh4 (admittedly not release architectures)
have been failing:

  g++ -g -O2 -fdebug-prefix-map=/<>=. 
-specs=/usr/share/dpkg/pie-compile.specs -fstack-protector-strong -Wformat 
-Werror=format-security -std=c++11 -fPIC -Ilibi2pd -Ilibi2pd_client  -maes 
-DAESNI -mavx -c -o obj/libi2pd/TunnelGateway.o libi2pd/TunnelGateway.cpp
  g++: error: unrecognized command line option '-maes'
  g++: error: unrecognized command line option '-mavx'

(On sh4, g++ suggests that -maes may have been a typo for the vaguely
similar-looking -m2e.)

Please refrain from using either flag on *any* architecture, since
they limit the portability of the resulting binaries.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#886377: i2pd: FTBFS (Hurd, kFreeBSD?): winsock2.h: No such file or directory

[Aaron M. Ucko]

Source: i2pd
Version: 2.17.0-1
Severity: important
Tags: upstream
Justification: fails to build from source
User: debian-h...@lists.debian.org
Usertags: hurd-i386

The build of i2pd for hurd-i386 (admittedly not a release
architecture) failed:

  g++ -Os -D_MT -DWIN32 -D_WINDOWS -DWIN32_LEAN_AND_MEAN -DWIN32_APP -std=c++11 
-Ilibi2pd -Ilibi2pd_client -Idaemon -I. -msse -c -o obj/libi2pd/TunnelGateway.o 
libi2pd/TunnelGateway.cpp
  [...]
  /usr/include/boost/asio/detail/socket_types.hpp:38:11: fatal error: 
winsock2.h: No such file or directory

The kFreeBSD autobuilders appear to be out of commission at the
moment, but I wouldn't be surprised if kFreeBSD builds turned out to
fail in the same fashion.

Could you please arrange to predefine WIN32 et al. only when actually
building for Windows?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#886264: firefox-esr: FTBFS on ppc64el

[Mike Hommey]

On Wed, Jan 03, 2018 at 03:45:45PM +, Julian Gilbey wrote:
> Package: firefox-esr
> Version: 52.5.3esr-1
> 
> This is the second version of firefox-esr in a row which has a
> build-failure on ppc64el, meaning that this package cannot migrate to
> testing.  There was a security fix in 52.5.2esr-1, so it would be very
> good to attempt to address this.
> 
> Sadly, I don't have any idea how the firefox build works or what might
> be causing the problem, so I don't know how to help fix this one.

The part of the build that's broken is running parts of Firefox. That
suggests firefox would not work even if the build succeeded (like, if we
skipped that part).

Now, there hasn't been code changes in Firefox since the last time it
built successfully that could explain this. However, the two failures
are with a newer version of GCC, which apparently touched PPC codegen.

IOW, this could be a legitimate GCC bug. Or this could be a legitimate
GCC bug fix that breaks Firefox somehow. I'm trying to reproduce on a
porterbox to try and see which it might be (sadly can't install older
versions of GCC, though).

Mike

Bug#886376: i2pd: FTBFS: undefined references to __atomic_{load,fetch_add}_8

[Aaron M. Ucko]

Source: i2pd
Version: 2.17.0-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of i2pd for several architectures (listed below) have been
failing with multiple occurrences each of

  /usr/include/c++/7/bits/atomic_base.h:396: undefined reference to 
`__atomic_load_8'

and

  /usr/include/c++/7/bits/atomic_base.h:312: undefined reference to 
`__atomic_fetch_add_8'

Linking against -latomic should address these errors.  To avoid a
formal runtime dependency on this library on the remaining
architectures, you can either add this library conditionally or
precede it with -Wl,--as-needed.  (In the unlikely event that this
flag breaks anything, you can keep it from affecting any other
libraries by adding --Wl,--no-as-needed after -latomic.)

FTR, these errors have been occurring on armel, mips, mipsel, and the
non-release architectures powerpc and powerpcspe, but I suspect builds
for a couple of non-release architectures that are currently failing
with compilation errors would also be affected if they got far enough.

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#882247:

[Tom Marble]

Mike:

There is something wrong with the default locale. Try installing a
> locale package (even firefox-l10n-en-gb) or downgrade to 57.


Turns out I can't install that from unstable (depends on firefox <<
57.0.3-1),
however I installed it from experimental (58.0~b4-1) and now firefox
works!!!

Thank you!

--Tom

Bug#886375: klystrack: FTBFS (32-bit): error: cast to pointer from integer of different size

[Aaron M. Ucko]

Source: klystrack
Version: 0.20171212-1
Severity: important
Tags: upstream
Justification: fails to build from source

Builds of klystrack for most 32-bit architectures (with the notable
exception of *i386, which I presume it special-cases) have been
failing with

  ../klystron/src/macros.h:97:21: error: cast to pointer from integer of 
different size [-Werror=int-to-pointer-cast]
   #define MAKEPTR(x) ((void*)(Uint64)(x))

in multiple contexts.

Could you please take a look?  I'd suggest using uintptr_t for an
unsigned integral type that's the same width as a pointer.

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#877884:

[Phan Kien]

Bug#881597: krb5-multidev: Please make the package multi-arch installable

[Sam Hartman]

Hi.

I like the approach of  making krb5-config not dynamic, but I'd prefer
to discover the behavior of the compiler rather than to  base our
interactions on its filename.


My plan is to use the following:
CC=${CC-cc}
tripple=`$CC -print-multiarch 2>/dev/null|| ( $CC -dumpmachine | sed 's/-pc//' 
)`
if [ x$tripple = x ]; then
echo >&2 Failed to find installation architecture
exit 2
fi


Expect an upload shortly; let me know how it works for you.

Bug#886374: texlive-latex-extra and emboss: error when trying to install together

[Ralf Treinen]

Package: emboss,texlive-latex-extra
Version: emboss/6.6.0+dfsg-6+b1
Version: texlive-latex-extra/2017.20180103-1
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2018-01-04
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Unpacking texlive-base (2017.20180103-1) ...
Selecting previously unselected package texlive-latex-base.
Preparing to unpack .../texlive-latex-base_2017.20180103-1_all.deb ...
Unpacking texlive-latex-base (2017.20180103-1) ...
Selecting previously unselected package texlive-latex-recommended.
Preparing to unpack .../texlive-latex-recommended_2017.20180103-1_all.deb ...
Unpacking texlive-latex-recommended (2017.20180103-1) ...
Selecting previously unselected package texlive-pictures.
Preparing to unpack .../texlive-pictures_2017.20180103-1_all.deb ...
Unpacking texlive-pictures (2017.20180103-1) ...
Selecting previously unselected package texlive-latex-extra.
Preparing to unpack .../texlive-latex-extra_2017.20180103-1_all.deb ...
Unpacking texlive-latex-extra (2017.20180103-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/texlive-latex-extra_2017.20180103-1_all.deb (--unpack):
 trying to overwrite '/usr/bin/wordcount', which is also in package emboss 
6.6.0+dfsg-6+b1
Processing triggers for libc-bin (2.26-1) ...
Processing triggers for man-db (2.7.6.1-4) ...
Processing triggers for install-info (6.5.0.dfsg.1-1) ...
Errors were encountered while processing:
 /var/cache/apt/archives/texlive-latex-extra_2017.20180103-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/bin/wordcount

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.

Bug#886373: ITP: json-tricks -- Python module with extra features for JSON files

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: json-tricks
  Version : 3.11.0
  Upstream Author : Mark V 
* URL : https://github.com/mverleg/pyjson_tricks
* License : Revised BSD License (BSD-3)
  Programming Lang: Python
  Description : Python module with extra features for JSON files

 The json_tricks Python module provides extra features for handling JSON
 files from Python:
   - Store and load numpy arrays  in human-readable format
   - Store and load class instances  both generic and customized
   - Store and load date/times  as a dictionary (including timezone)
   - Preserve map order  OrderedDict
   - Allow for comments   in json files by starting lines with #
   - Sets, complex numbers, Decimal, Fraction, enums, compression, duplicate
 keys, ...

 Needed for psychopy

Bug#885525: [Pkg-utopia-maintainers] Bug#885525: better log output

[russell]

On 2017-12-28 15:31, Michael Biebl wrote:

Control: tags -1 + moreinfo

Please install dbgsym packages for at least libnm0, libnma0 and
network-manager-gnome to get a more useful backtrace.
https://wiki.debian.org/HowToGetABacktrace



This is the output of gdb after installing a bunch of -dbgsym packages 
(including glib2.0-0). Let me know if I can get more info.


(gdb) run
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/nm-applet
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".

[New Thread 0x7fffeb8e0700 (LWP 5086)]
[New Thread 0x7fffeb0df700 (LWP 5087)]
[New Thread 0x7fffea037700 (LWP 5088)]
[New Thread 0x7fffe955f700 (LWP 5089)]
double free or corruption (out)

Thread 1 "nm-applet" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51

#1  0x74afecf7 in __GI_abort () at abort.c:90
#2  0x74b3ff87 in __libc_message (action=action@entry=do_abort,
fmt=fmt@entry=0x74c45bd8 "%s\n") at 
../sysdeps/posix/libc_fatal.c:181

#3  0x74b4627a in malloc_printerr (
str=str@entry=0x74c47828 "double free or corruption (out)") at 
malloc.c:5354

#4  0x74b47fd0 in _int_free (av=0x74e79c20 ,
p=0x74e79cf0 , have_lock=) at 
malloc.c:4278

#5  0x75108449 in g_strfreev (str_array=0x55926b10)
at ../../../../glib/gstrfuncs.c:2497
#6  0x750cb45b in g_datalist_clear (datalist=)
at ../../../../glib/gdataset.c:273
#7  0x753c5ea2 in g_object_unref (_object=0x5587e280)
at ../../../../gobject/gobject.c:3330
#8  0x750d5e41 in g_hash_table_foreach_remove_or_steal 
(hash_table=0x557ee360,
func=func@entry=0x76347010 <_setting_release>, 
user_data=0x55976720,

notify=notify@entry=1) at ../../../../glib/ghash.c:1500
#9  0x750d6cec in g_hash_table_foreach_remove 
(hash_table=,
func=func@entry=0x76347010 <_setting_release>, 
user_data=)

at ../../../../glib/ghash.c:1544
#10 0x76347187 in nm_connection_private_free 
(priv=0x559758e0)

at libnm-core/nm-connection.c:2711
#11 0x750cb45b in g_datalist_clear (datalist=)
at ../../../../glib/gdataset.c:273
#12 0x753c5ea2 in g_object_unref (_object=0x55976720)
at ../../../../gobject/gobject.c:3330
#13 0x5556a29c in applet_secrets_request_free 
(req=req@entry=0x559dab80)

at src/applet.c:2852
#14 0x5556d8fc in child_finished_cb (
pid=,
status=, 
user_data=0x559dab80,
user_data@entry=out>)

at src/applet-vpn-request.c:117
#15 0x750e4724 in g_child_watch_dispatch 
(source=source@entry=0x55bc93a0,
callback=, user_data=) at 
../../../../glib/gmain.c:5282

#16 0x750e7e15 in g_main_dispatch (context=0x5580ba20)
at ../../../../glib/gmain.c:3148
#17 g_main_context_dispatch (context=context@entry=0x5580ba20)
at ../../../../glib/gmain.c:3813
#18 0x750e81e0 in g_main_context_iterate 
(context=context@entry=0x5580ba20,
block=block@entry=1, dispatch=dispatch@entry=1, self=out>)

at ../../../../glib/gmain.c:3886
#19 0x750e826c in g_main_context_iteration 
(context=context@entry=0x5580ba20,

may_block=may_block@entry=1) at ../../../../glib/gmain.c:3947
#20 0x756a5bed in g_application_run (application=0x557f02b0,
---Type  to continue, or q  to quit---
argc=, argv=) at 
../../../../gio/gapplication.c:2401
#21 0x555641b1 in main (argc=, argv=out>) at src/main.c:81

Bug#750732: libanyevent-perl: Intermittent build failures on various architectures

[gregor herrmann]

On Mon, 01 Jan 2018 18:56:52 +0200, Niko Tyni wrote:

> The issue seems mostly specific to armel and hurd, although
> tests.reproducible-builds.org does have some failures on i386 (but no
> logs so those could be just testbed glitches or transient sid issues.)
> I don't know what happened in Ubuntu but it clearly built later.

Yup, it seems a bit undeterministic.
 
> Currently we have a build failure on armel that's blocking testing
> migration of this package. Given the number of reverse dependencies,
> I suppose we need to solve this one way or other.

Ack.
 
> Disregarding hurd-i386, the problematic test seems to be
> t/66_ioasync_03_signals.t, 

t/66_ioasync_02_signals.t or t/66_ioasync_03_child.t?
Anyway, IIRC we've seen failures in different tests over time.

> which is using AnyEvent::Impl::IOAsync
> which uses IO::Async. 

Ack, that's the whole t/66_ioasync_*.t block.

> I see the AnyEvent::Impl::IOAsync docs have some
> reservations about IO::Async, this in particular:

That, and more comments in the code and documentation about IO::Async.
 
> I'm not sure what to make of this. Maybe disarm this particular test somehow
> for now and see how it fares otherwise?

Which one exactly? :)
I tend to disable the whole t/66_ioasync_*.t group.
Or maybe not:


And, lo and behold, I could reproduce a test failure, on one of my
raspis, running Raspbian Buster (and under some load). There the test
suite was just hanging here:

t/66_ioasync_03_child.t 
1..50
ok 1
ok 2 # child 15124
ok 3 # 15124 == 15124
ok 4 # 3 == 768 >> 8 (768)
ok 5 # 15126 == 15126
ok 6 # 7 == 1792 >> 8 (1792)
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12 # child 15127


Of course this only happened once over the time I run the tests in a
loop so far ...


On 
https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.140-1=1505267718=0
it was

t/66_ioasync_02_signals.t .. 
1..5
ok 1
ok 2
ok 3
ok 4
ok 5
ok
Bailout called.  Further testing stopped:  No child exit detected. This is 
either a bug in AnyEvent or a bug in your Perl (mostly some windows 
distributions suffer from that): child watchers might not work properly on this 
platform. You can force installation of this module if you do not rely on child 
watchers, or you could upgrade to a working version of Perl for your platform.

(Does this mean that t/66_ioasync_02_signals.t failed or the
following t/66_ioasync_03_child.t ?)


Some other failures:
https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.120-1%2Bb1=1474787791=0
https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=armel=7.120-1%2Bb1=1474805578=0
same as above

https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=sparc64=7.130-1=1476943760=0
t/66_ioasync_02_signals.t .. 
1..5
ok 1
ok 2
ok 3
ok 4
ok 5
ok
E: Caught signal ‘Terminated’: terminating immediatelydebian/rules:13: recipe 
for target 'override_dh_auto_test' failed

So basically the same.

https://buildd.debian.org/status/fetch.php?pkg=libanyevent-perl=x32=7.070-3=1411189350=0
t/66_ioasync_02_signals.t .. ok
Bailout called.  Further testing stopped:  No child exit detected. This is 
either a bug in AnyEvent or a bug in your Perl (mostly some windows 
distributions suffer from that): child watchers might not work properly on this 
platform. You can force installation of this module if you do not rely on child 
watchers, or you could upgrade to a working version of Perl for your platform.

Same again.

Looks like t/66_ioasync_03_child.t is our candidate, if I'm
interpreting this correctly.


Oh, and I have another hang on my Raspi:

t/66_ioasync_03_child.t  
1..50
ok 1
ok 2 # child 22400
ok 3 # 22400 == 22400
ok 4 # 3 == 768 >> 8 (768)
ok 5 # 22401 == 22401
ok 6 # 7 == 1792 >> 8 (1792)
ok 7
ok 8
ok 9
ok 10
ok 11
ok 12 # child 22402
ok 13 # 22402 == 22402
ok 14 # 3 == 768 >> 8 (768)
ok 15 # 22403 == 22403
ok 16 # 7 == 1792 >> 8 (1792)
ok 17
ok 18
ok 19
ok 20
ok 21
ok 22 # child 22404
ok 23 # 22404 == 22404
ok 24 # 3 == 768 >> 8 (768)
ok 25 # 22405 == 22405
ok 26 # 7 == 1792 >> 8 (1792)
ok 27
ok 28
ok 29
ok 30
ok 31
ok 32 # child 22406
ok 33 # 22406 == 22406
ok 34 # 3 == 768 >> 8 (768)
ok 35 # 22407 == 22407
ok 36 # 7 == 1792 >> 8 (1792)
ok 37
ok 38
ok 39
ok 40
ok 41
ok 42 # child 22408


Commit pushed to alioth, feedback welcome before I upload.


Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#750732: Pending fixes for bugs in the libanyevent-perl package

[pkg-perl-maintainers]

tag 750732 + pending
thanks

Some bugs in the libanyevent-perl package are closed in revision
b8e06b0cb8fe01a4451564a05dfec86db120b7d0 in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libanyevent-perl.git/commit/?id=b8e06b0

Commit message:

Skip t/66_ioasync_03_child.t during build and autopkgtest

as it seems to suffer from a race condition.

Closes: #750732

Bug#886367: partial fix uploaded

[Henrique de Moraes Holschuh]

Intel has released several updates already, but not all of them AFAIK.

These microcode updates are of little impact until the kernel changes to
activate the new MSRs are deployed.  But they do mess with conditional
jumps and LFENCE.

Anyway, uploading a partial, unofficial set of updates to unstable to
close the bug.  Several processors are still missing.  I expect an
official release from Intel soon, hopefully with updates for everything.

Everyone should look for firmware updates, the usual good vendors
already have them out, or will have them out by the end of the next
week.

-- 
  Henrique Holschuh

Bug#886335: addendum

[SZABO Zsolt]

I think, that the bug is related to the utility gstoraster as described 
here (it does not recognise PJL encapsulated, PostScript document text

starting with "\033%-12345X@PJL JOB"):

https://www.linuxquestions.org/questions/slackware-14/slackware-cups-can%27t-detect-file-type-4175605111/

As a dirty hack I replaced the last line of the gstopdf script (in 
/usr/lib/cups/filter) calling gstoraster for


/usr/bin/ps2pdf - -

and it works. (However, some options like jobid, user, copies, 
peculiar options etc. are not passed, so some more complex print jobs may

not so be processed as expected.)

And I have not tested the local printings yet (from the linux host)...

--
Zsolt

Bug#886372: tracker.debian.org: Failed to handle Vcs-git: -b situation

[Boyuan Yang]

Package: tracker.debian.org
Severity: normal

Take a look at Vcs: field in:
https://tracker.debian.org/pkg/aptitude

For Vcs-Git, the hyperlink yields:

https://anonscm.debian.org/git/aptitude/aptitude.git%20-b%20debian-sid

Which is definitely wrong and will leads to 404.

Regards,
Boyuan Yang



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

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

Bug#886371: php-http looses ca-file-path

[Andreas Sachs]

Package: php-http
Version: 3.1.0+2.6.0-4

As soon as you set ssl-options the default cainfo/capath get's lost.

Error:
Peer certificate cannot be authenticated with given CA certificates; SSL
certificate problem: unable to get local issuer certificate

If I don't set any ssl options I see the following with strace:
open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 4
open("/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = 4
open("/tmp/phpOi2cQV", O_RDWR|O_CREAT|O_EXCL, 0600) = 4

To reproduce:
$httpOptions = array(
'ssl' => array(
'verifypeer' => 1,
'verifyhost' => 1,
),
'timeout' => 5
);


$request = new \http\Client\Request('GET','https://pear.horde.org/');
$client = new \http\Client('curl');
$client->setOptions($httpOptions);
$client->enqueue($request);
try {
  $client->send();
 $httpResponse = $client->getResponse($request);
 print_r($httpResponse);
} catch (\http\Exception $e) {
print_r($e);
}

  I am using Debian 9.3

Bug#886367: intel-microcode: more meltdown/spectre info

[Matt Taggart]

I read that RHEL is already issuing microcode updates for RHEL7.
I read it second hand at
https://lists.bufferbloat.net/pipermail/cerowrt-devel/2018-January/08.html

But maybe there is an official URL somewhere?
I found the following pages
https://access.redhat.com/security/vulnerabilities/speculativeexecution
https://access.redhat.com/articles/3311301

But I couldn't find any reference to microcode versions.

--
Matt Taggart
tagg...@debian.org

Bug#886370: alpine: stops parsing /etc/mailcap when invalid entry found

[Matt Roberds]

Package: alpine
Version: 2.20+dfsg1-7
Severity: normal

Dear Maintainer,

Quick version:

alpine seems to quit reading /etc/mailcap when it hits an invalid entry.
This may keep alpine from launching an application to read an attachment,
if the MIME type for the attachment appears after the invalid entry in
/etc/mailcap.

I think alpine should be more lenient when parsing /etc/mailcap .  Or, it
should warn the user somehow that it stopped parsing /etc/mailcap due to
an invalid entry, to give the user a chance to fix the problem.

Long version:

What happened:

Someone sent me an email with a Microsoft Word document attached, with
MIME type application/msword .  I opened the email in alpine, selected
(V)iew, went down to the attachment, hit Enter, and alpine told me it
didn't know how to open application/msword files.  This wasn't what I
expected; I expected alpine to launch a program to show the attachment.

I have LibreOffice installed and working, and there were entries to
launch LibreOffice for application/msword files in /etc/mailcap , so I
wasn't quite sure why alpine said it didn't know what to do.

I used alpine's debug output (-d 5), which shows how alpine parses
/etc/mailcap line by line, and noticed that alpine didn't make it all
the way to the end of the file.  Eventually, I figured out that a bug
in another package had caused a poorly-formatted line to be written to
/etc/mailcap , as follows:

---
application/vnd.comicbook+zip; evince %s; test=test -n "$DISPLAY"
application/x-ext-cb7; evince %s; test=test -n "$DISPLAY"
; evince %s; test=test -n "$DISPLAY"
application/oxps; evince %s; test=test -n "$DISPLAY"
application/vnd.ms-xpsdocument; evince %s; test=test -n "$DISPLAY"
---

alpine stopped reading /etc/mailcap when it got to the line starting
with '; evince'.  The application/msword entry that launches
LibreOffice for a Word document appeared further down in the file, so
alpine never got to it.  The poorly-formatted entry was on line 326,
out of 769 lines total, so alpine was not seeing over half of the
entries in the file.

(The bug was #885864 against evince, which has since been fixed.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885864 )

What I did to fix it:

I edited that poorly-formatted line out of /etc/mailcap and tried again.
alpine was able to parse /etc/mailcap until it found the relevant
application/msword line and launch LibreOffice, so I could view the
attachment.

What I think should be different:

I think alpine should have kept on reading after it hit the invalid
entry in /etc/mailcap.  If it's looking for the ';' as a field
separator, it shouldn't stop parsing if the first field ends up null.
It might be appropriate to warn the user, or possibly print an entry
in the alpine debug log, if alpine has to skip a poorly-formatted
entry.

If the thinking is that it's still better to just stop parsing mailcap
when alpine sees a poorly-formatted line, then I think alpine should
warn the user somehow.  This would help make the distinction between
"I looked through all of your mailcap and couldn't find anything that
matched" and "I didn't look at all of your mailcap because your mailcap
file has a problem" clearer to the user.

The built-in debug option (-d switch) to alpine was helpful in finding
this problem, so... keep that functionality around!  :)

Thanks!

Matt Roberds

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

Kernel: Linux 4.9.0-4-amd64 (SMP w/2 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: sysvinit (via /sbin/init)

Versions of packages alpine depends on:
ii  libc6 2.24-11+deb9u1
ii  libgssapi-krb5-2  1.15-1+deb9u1
ii  libkrb5-3 1.15-1+deb9u1
ii  libldap-2.4-2 2.4.44+dfsg-5+deb9u1
ii  libpam0g  1.1.8-3.6
ii  libssl1.0.2   1.0.2l-2+deb9u2
ii  libtinfo5 6.0+20161126-1+deb9u1
ii  mlock 8:2007f~dfsg-5

Versions of packages alpine recommends:
ii  alpine-doc  2.20+dfsg1-7

Versions of packages alpine suggests:
ii  aspell 0.60.7~20110707-3+b2
ii  exim4-daemon-light [mail-transport-agent]  4.89-2+deb9u2

-- no debconf information

Bug#886363: libdatetime-locale-perl: After upgrade from Jessie to Stretch, Can't locate DateTime/Locale/en_US.pm in @INC

[gregor herrmann]

On Fri, 05 Jan 2018 00:22:59 +0100, Reiner Buehl wrote:

> my script does not use DateTime::Locale directly. I only use DateTime. This
> is the script I use:
> 
> #!/usr/bin/perl
> use Net::Twitter;
> use Scalar::Util 'blessed';
> use DateTime;
> use Storable qw(retrieve nstore);
> use LWP::Simple;
> 
> # Variable definitions
> my $configfile = "/home/reiner/.FollowTwitterStream";
> my $path = "/home/reiner/Twitter";
> my $consumer_key = 'xx';
> my $consumer_secret = '';
> my $token = '';
> my $token_secret = 'xxx';
> my $high_water = 429901897936674816;
> my $dt;
> my $DEBUG = 0;
> 
> # Kill script after 59 min to avoid hanging
> alarm(3540);
> 
> # Read config
> if (-r $configfile) {
> $dt = retrieve("$configfile");
> }
[..]

Looking back at the error you got:

> Can't locate DateTime/Locale/en_US.pm in @INC (you may need to install the 
> DateTime::Locale::en_US module) (@INC contains: /etc/perl
> /usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
> /usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5
> /usr/lib/i386-linux-gnu/perl/5.24 /usr/share/perl/5.24 
> /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at
> /usr/lib/i386-linux-gnu/perl/5.24/Storable.pm line 389,  line 1.
> BEGIN failed--compilation aborted,  line 1, at 
> /home/reiner/bin/FollowTwitterStream.pl line 24.

/home/reiner/bin/FollowTwitterStream.pl line 24 is
| $dt = retrieve("$configfile");

and the error before also refers to 
/usr/lib/i386-linux-gnu/perl/5.24/Storable.pm

So it seems that you are loading something from
my $configfile = "/home/reiner/.FollowTwitterStream";
which doesn't work anymore.

I'd probably add something like
| use Data::Dumper; print STDERR Dumper $dt; exit;
after line 24 to see what's in this $configfile.
 
[... end of script ...]
> $dt = DateTime->now;
> nstore $dt, "$configfile";

Well, if it's only the current time which is stored there, the file
can probably also deleted without much harm ...



Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#886182: transition: glibc 2.26

[Simon McVittie]

On Thu, 04 Jan 2018 at 21:52:32 +0100, Michael Biebl wrote:
> Am 04.01.2018 um 20:05 schrieb Simon McVittie:
> > (In particular, I'm trying to release ostree to fix a RC bug, but it now
> > fails to build due to a hilarious dependency chain involving
> > gjs -> libgtk-3-0 -> dconf-gsettings-backend -> dconf-service ->
> > dbus-user-session -> libpam-systemd -> systemd-shim -> cgmanager -> libnih1
> > due to CTTE decision #746578 preferring systemd-shim over systemd-sysv.)
> 
> See related #883573.
> Fwiw, after pondering about this for a while, I consider dropping the
> Depends: systemd-shim | systemd-sysv
> from libpam-systemd altogether.

This would result in there being no way for a package to declare "I need
a working systemd-logind" and get the relevant packages installed, which
seems like a regression. If people who don't like systemd as pid 1 get
round to packaging elogind (a fork of logind with reduced functionality
and no systemd dependency), then we'd need a virtual package or something
anyway, but until then libpam-systemd is the official way to declare
that dependency.

> So for the few users who actually want to use sysvinit + a
> full blown desktop I would leave it up to them to install systemd-shim
> manually.

I don't think it's a desirable outcome for those users to be filing RC
bugs of the form "gnome-control-center: missing dependencies",
particularly when systemd-related issues make everyone extra-adversarial.

> This would also avoid pulling an init system for packages
> which build-depend on dbus for dbus-run-session (which would also fix
> your particular problem)

I feel as though something is wrong in this dependency chain, but
I'm not sure what - most of the dependencies are defensible. Perhaps
libgtk-3-common should only have a Recommends on dconf-gsettings-backend,
as part of the principle that libraries don't generally hard-depend
on services? (But that would require modifying dh_installgsettings.)

> I'd be happy to make a systemd upload dropping this dependency to
> unblock ostree.

I've turned off the tests that use gjs for now, and I'll probably
propose a patch upstream to make it possible to package the JS
installed-tests without having gjs present at build-time.

smcv

Bug#884953: vlc: bad window redraw: black lines

[Luca Boccassi]

Control: tags -1 upstream

On Thu, 4 Jan 2018 11:47:34 +0100 Vincent Lefevre 
wrote:
> On 2018-01-04 11:14:57 +0100, Sebastian Ramacher wrote:
> > On 2018-01-03 23:59:26, Vincent Lefevre wrote:
> > > On 2018-01-03 21:11:20 +0100, Sebastian Ramacher wrote:
> > > > This looks more like a graphics driver bug to me. I cannot
reproduce
> > > > it on any of my machine. Please let us know your GPU and driver
and
> > > > we can reassign it there.
> > > 
> > > NVIDIA Corporation GK208GLM [Quadro K610M] with the nvidia driver
> > > (Debian packages version 384.98-3).
> > 
> > Thank you, reassigning accordingly.
> 
> Note that I can reproduce this issue only with VLC, not with other
> Qt applications such as gnuplot-qt and wireshark.

Hi,

I would recommend reporting this upstream:

https://devtalk.nvidia.com/default/board/98/linux/
or
linux-b...@nvidia.com

Given it's most likely an issue with the binary blobs, that's the best
way to get some support. If it's due to the blobs there's not much we
can do unfortunately.
If you post to the forum report back the link and I'll tag the bug.

Kind regards,
Luca Boccassi

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

Bug#886369: easytag: remove mentioned OGG support from package description

[James Cowgill]

Package: easytag
Version: 2.4.3-2
Severity: minor
Tags: patch
X-Debbugs-CC: Bruno Kleinert 
Control: submitter -1 Bruno Kleinert 

Hi,

On 04/01/18 12:02, Bruno Kleinert wrote:
> Am Mittwoch, den 03.01.2018, 16:50 + schrieb James Cowgill:
>> Control: clone -1 -2
>> Control: notfound -2 2.4.3-1
>> Control: found -2 2.4.3-2
>> Control: severity -2 normal
>> Control: tags -2 - pending
>> Control: retitle -2 easytag: re-enable ogg after corruption bug is
>> fixed
>>
>> Hi,
>>
>> On 16/02/17 01:02, Samuele Battarra wrote:
>>> Package: easytag
>>> Version: 2.4.3-1
>>> Severity: normal
>>>
>>> Dear Maintainer,
>>> I have a ogg file encoded from a live cd, I split it to single
>>> tracks with oggsplt and then tag the tracks with easytag.
>>> When I play the files I hear a click at file change.
>>> The click is not present in files before the tagging and if I tag
>>> with kid3.
>>
>> As you might have noticed, I have decided that the best way to fix
>> this
>> is to disable support for OGG and related media types in easytag for
>> the
>> time being. Solving this bug is apparently quite complex and while
>> the
>> upstream bug has been open for over a year, there has not been much
>> progress on it. I think it is better to have some version in buster
>> (which does not mangle your media files) than nothing at all.
>>
>> I have cloned this bug to remind me to re-enable ogg support once the
>> corruption bug is fixed.
>>
>> Thanks,
>> James
> 
> Hi James,
> 
> I suggest to remove the mentioned OGG support from the description of
> the package for the time being, and suggest alternative packages to
> users instead. Feel free to use and adapt the attached patch!

Yes I overlooked altering the package description to remove mentions of
ogg. I'm not sure the description is the right place to be suggesting
alternative packages though.

James
diff --git a/debian/changelog b/debian/changelog
index a8df5e1..4cae9d8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+easytag (2.4.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Do not mention OGG support in package description. Instead, suggest
+alternative packages to edit OGG file tags.
+
+ -- Bruno "Fuddl" Kleinert   Thu, 04 Jan 2018 12:52:46 +0100
+
 easytag (2.4.3-2) unstable; urgency=medium
 
   * debian/control:
diff --git a/debian/control b/debian/control
index 6e53796..36cabb6 100644
--- a/debian/control
+++ b/debian/control
@@ -49,9 +49,8 @@ Description: GTK+ editor for audio file tags
  .
  Currently EasyTAG supports the following:
   - View, edit, write tags of MP3, MP2 files (ID3 tag), FLAC files (FLAC Vorbis
-tag), Ogg Opus, Ogg Speex and Ogg Vorbis files (Ogg Vorbis tag),
-MP4/M4A/AAC files (MPEG-4 Part 10 tag), and MusePack, Monkey's Audio files
-(APE tag);
+tag), MP4/M4A/AAC files (MPEG-4 Part 10 tag), and MusePack, Monkey's Audio
+files (APE tag);
   - Auto tagging: parse file and directory names using masks to automatically
 fill in tag fields;
   - Cover art support for all formats;
@@ -71,6 +70,10 @@ Description: GTK+ editor for audio file tags
   - A playlist generator window;
   - A file searching window;
   - Simple and explicit interface.
+ .
+ OGG support is currently disabled in this package because of a data corruption
+ bug. To edit tags in OGG files you may consider one of these packages: exfalso,
+ puddletag, kid3-qt, entagged.
 
 Package: easytag-nautilus
 Architecture: any


signature.asc
Description: OpenPGP digital signature

Bug#886363: libdatetime-locale-perl: After upgrade from Jessie to Stretch, Can't locate DateTime/Locale/en_US.pm in @INC

[Reiner Buehl]

Hi,

my script does not use DateTime::Locale directly. I only use DateTime. This is 
the script I use:


#!/usr/bin/perl
use Net::Twitter;
use Scalar::Util 'blessed';
use DateTime;
use Storable qw(retrieve nstore);
use LWP::Simple;

# Variable definitions
my $configfile = "/home/reiner/.FollowTwitterStream";
my $path = "/home/reiner/Twitter";
my $consumer_key = 'xx';
my $consumer_secret = '';
my $token = '';
my $token_secret = 'xxx';
my $high_water = 429901897936674816;
my $dt;
my $DEBUG = 0;

# Kill script after 59 min to avoid hanging
alarm(3540);

# Read config
if (-r $configfile) {
$dt = retrieve("$configfile");
}

# Connect to Twitter
my $twitter = Net::Twitter->new(
traits   => [qw/API::RESTv1_1/],
consumer_key=> $consumer_key,
consumer_secret => $consumer_secret,
access_token=> $token,
access_token_secret => $token_secret,
ssl => 1,
);

eval {
my $statuses = $twitter->home_timeline({ -since => $dt, count => 100 });
for my $status ( @$statuses ) {
print "$status->{id} $status->{created_at} 
<$status->{user}{screen_name}> $status->{text}\n" if $DEBUG;

my $medialist = $status->{entities}->{media};
foreach my $media ( @$medialist ) {
my $url = $media->{media_url};
my $file = (URI->new($url)->path_segments)[-1];
if ($url =~ /twimg\.com/ ) {
$url .= ":large";
}
print "Get $url as $path/$status->{user}{screen_name}$file\n" if 
$DEBUG;

getstore("$url", "$path/$status->{user}{screen_name}$file");
}
$high_water = "$status->{id}";
}
};
if ( my $err = $@ ) {
die $@ unless blessed $err && $err->isa('Net::Twitter::Error');

warn "HTTP Response Code: ", $err->code, "\n",
 "HTTP Message..: ", $err->message, "\n",
 "Twitter error.: ", $err->error, "\n";
}

$dt = DateTime->now;
nstore $dt, "$configfile";


On Thu, 4 Jan 2018, gregor herrmann wrote:


On Thu, 04 Jan 2018 22:51:21 +0100, Reiner Buehl wrote:


after upgrading my system from Jessie to Stretch, I get the
following error messages from a perl skript that used to work fine
before the upgrade:

Can't locate DateTime/Locale/en_US.pm in @INC (you may need to install the 
DateTime::Locale::en_US module) (@INC contains: /etc/perl 
/usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
/usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5 /usr/lib/i386-linux-gnu/perl/5.24 
/usr/share/perl/5.24 /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at 
/usr/lib/i386-linux-gnu/perl/5.24/Storable.pm line 389,  line 1.
BEGIN failed--compilation aborted,  line 1, at 
/home/reiner/bin/FollowTwitterStream.pl line 24.


Could you please show us how you use DateTime::Locale in your script?


The upstream changelog shows some thing around en_US and en-US but I
can't reproduce the problem in my quick naïve try:

% perl -MDateTime::Locale -E '$locale = DateTime::Locale->load("en-US"); say 
$locale->native_name;'
English United States
% perl -MDateTime::Locale -E '$locale = DateTime::Locale->load("en_US"); say 
$locale->native_name;'
English United States


And regarding your error message about a missing
"DateTime/Locale/en_US.pm":

/usr/share/perl5/DateTime/Locale/en_US.pm has indeed existed some
versions ago, then the whole thing has been restructured; cf. the
section "0.90 2015-09-27" in
/usr/share/doc/libdatetime-locale-perl/changelog.gz.


So my suspicion is that you are using what is called the "old API" in
the upstream changelog and need to update your script.


Cheers,
gregor

--
.''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
: :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
`. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
  `-   NP: Sinéad O'Connor: Jealous




Gruß,
Reiner.

--
Reiner Buehl Internet:
Karlstrasse 3rei...@buehl.net
70771 Leinfelden-Echterdingen
Germany
--

Bug#884858: mutt: q and $ fail with: rename: No such file or directory (errno = 2)

[Adam Borowski]

> Sometimes, quite rarely, operations that would commit operations on a
> directory (such as q or $) fail with:
> rename: No such file or directory (errno = 2)
> with no way to save changes.  This results in doubled mails that were moved
> elsewhere, restoration of deleted mails and similar loss of status updates.

A workaround for when there's enough state that its loss would be painful:
if I send myself a mail, such a stuck mutt will allow deletion of this new
dummy mail, and work normally then.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#886368: intel-microcode: copyright URLs out of date

[Matt Taggart]

Package: intel-microcode
Version: 3.20171117.1
Severity: wishlist

The two upstream download URLs listed in the copyright file no longer 
work (and are also http URLs). Searching I found the following


https://downloadcenter.intel.com/download/27337/Linux-Processor-Microcode-Data-File

but I suspect that URL might be specific to the 20171117 version.
Hopefully you can find a more generic URL for the latest version.

Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#882833: (no subject)

[Thomas Preud'homme]

I've also had issues with kontact and my .xsession-errors contained the 
following lines:

org.kde.pim.akonadiserver: database server stopped unexpectedly 

org.kde.pim.akonadiserver: stderr: "mysqld: [ERROR] Could not open required 
defaults file: 
$HOME/.local/share/akonadi/mysql.conf\nmysqld: [ERROR] Fatal error in defaults 
hand


Where $HOME and $USER are substitution of my own to mask my home directory and 
username.

I've noticed some DENIED lines in dmesg that seem related:

audit: type=1400 audit(1515103889.923:49): apparmor="DENIED" operation="open" 
profile="/
usr/sbin/mysqld" name="$HOME/.local/share/akonadi/mysql.conf" pid=2655 
comm="mysqld" requested_mask="r" denied_mask="r" fsuid=1000 

== Successful attempt ==


Trying to launch the mysqld command mentioned in .xsession-errors but using 
mysqld-
akonadi instead (which seems to have special treatment for 
$HOME/.local/share/akonadi) 
and relaunching akonadi and then kontact seems to have worked (am writing this 
from that 
very kontact process).

Best regards,

Thomas


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

Bug#886367: intel-microcode: coming updates for meltdown/spectre

[Matt Taggart]

Package: intel-microcode
Version: 3.20171117.1
Severity: grave

It's been rumored that Intel will be releasing microcode updates to 
(partially?) mitigate some of the effects of meltdown and spectre. It 
appears that the latest version on the website is still 20171117.


Any news of what this will be and when it will happen?

Thanks,

--
Matt Taggart
tagg...@debian.org

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Pierre-Elliott Bécue]

Le jeudi 04 janvier 2018 à 23:23:01+0100, Thomas Schmitt a écrit :
> Hi,
> 
> Pierre-Elliott Bécue wrote:
> > I pushed a patch to have the tracker behaving in a proper way even though
> > javascript is disabled.
> 
> That's great news. Since today i began to ponder whether pointing to
>   
> https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript
> would be appropriate. (I yet fail to see how the time measurement part
> of the exploit can be done via JavaScript. But up to yesterday i failed
> to see how one could spy on the host kernel out of a VM.)

I guess this question would better be addressed in a separate bug, or via
mail on the QA list.

> As for the optical impression: it looks ok with 1 item as on
>   https://tracker.debian.org/pkg/libisoburn
> but a bit overcrowded with 8 items on
>   https://tracker.debian.org/pkg/systemd

Yes, unfortunately that is the counterpart of having everything unfolded.

> My local Iceweasel 31.7.0 with JavaScript enabled does not toggle anything
> by the "v" link, which on mouse-over says "Toggle details". The items stay
> expanded.

Actually the toggle details is no longer relying on javascript but on a
HTML5 tag (TitleContent. Maybe
Iceweasel 31.7.0 does not support such a tag?

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2


signature.asc
Description: PGP signature

Bug#885864: This bug also affected evince.thumbnailer and probably /etc/mailcap

[Matt Roberds]

All,

This report is just for documentation; there is probably no action
needed on the part of the maintainers.

I have 3.22.1-3+deb9u1 installed on my system, and the evince.thumbnailer
file has the same double-semicolon problem in the same location as the
evince.desktop file originally reported.

I downloaded the source package for evince-3.26.0-2 and verified that
both evince.thumbnailer and evince.desktop have been fixed - the double
semicolon is gone from both - so that is OK.

However, I also wanted to note that the double semicolon was probably
also causing an incorrect entry in /etc/mailcap to be created when
evince was installed, which was causing another application (alpine) to
have trouble reading /etc/mailcap.

An excerpt of my /etc/mailcap follows:

---
application/vnd.comicbook+zip; evince %s; test=test -n "$DISPLAY"
application/x-ext-cb7; evince %s; test=test -n "$DISPLAY"
; evince %s; test=test -n "$DISPLAY"
application/oxps; evince %s; test=test -n "$DISPLAY"
application/vnd.ms-xpsdocument; evince %s; test=test -n "$DISPLAY"
---

alpine was looking for a mailcap entry that was further down in the
mailcap file, but it stopped searching when it hit the line starting
with "; evince".  It's probably alpine's baby to handle poorly-
formatted mailcap lines better, but it's also good to not put poorly-
formatted lines in mailcap.

Again, I am pretty sure the mailcap entries were generated from one of
the two files that were fixed, so future installs of evince should write
correctly-formatted lines to /etc/mailcap.

Thanks!

Matt Roberds

Bug#886363: libdatetime-locale-perl: After upgrade from Jessie to Stretch, Can't locate DateTime/Locale/en_US.pm in @INC

[gregor herrmann]

On Thu, 04 Jan 2018 22:51:21 +0100, Reiner Buehl wrote:

> after upgrading my system from Jessie to Stretch, I get the
> following error messages from a perl skript that used to work fine
> before the upgrade:
> 
> Can't locate DateTime/Locale/en_US.pm in @INC (you may need to install the 
> DateTime::Locale::en_US module) (@INC contains: /etc/perl 
> /usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
> /usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5 
> /usr/lib/i386-linux-gnu/perl/5.24 /usr/share/perl/5.24 
> /usr/local/lib/site_perl /usr/lib/i386-linux-gnu/perl-base) at 
> /usr/lib/i386-linux-gnu/perl/5.24/Storable.pm line 389,  line 1.
> BEGIN failed--compilation aborted,  line 1, at 
> /home/reiner/bin/FollowTwitterStream.pl line 24.

Could you please show us how you use DateTime::Locale in your script?
 

The upstream changelog shows some thing around en_US and en-US but I
can't reproduce the problem in my quick naïve try:

% perl -MDateTime::Locale -E '$locale = DateTime::Locale->load("en-US"); say 
$locale->native_name;' 
English United States
% perl -MDateTime::Locale -E '$locale = DateTime::Locale->load("en_US"); say 
$locale->native_name;' 
English United States


And regarding your error message about a missing
"DateTime/Locale/en_US.pm":

/usr/share/perl5/DateTime/Locale/en_US.pm has indeed existed some
versions ago, then the whole thing has been restructured; cf. the
section "0.90 2015-09-27" in
/usr/share/doc/libdatetime-locale-perl/changelog.gz.


So my suspicion is that you are using what is called the "old API" in
the upstream changelog and need to update your script.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Sinéad O'Connor: Jealous


signature.asc
Description: Digital Signature

Bug#886366: linux-headers-4.15.0-rc5-amd64: missing tools/objtool in /lib/modules/foo/build breaks DKMS modules builds

[Luca Boccassi]

Package: src:linux
Version: 4.15~rc5-1~exp1
Severity: important

Dear Maintainer,

The new tools/ directory is currently symlinked from linux-kbuild-4.15
into linux-headers-common-4.15.0-rc5 (directory: /usr/src/linux-
headers-4.15.0-rc5-common/tools ) but not into linux-headers-4.15.0-
rc5-amd64 like scripts/ is.

This means objtool is available under /lib/modules/4.15.0-rc5-
amd64/source but not under /lib/modules/4.15.0-rc5-amd64/build which
means kernel modules builds via DKMS fail with:

/bin/sh: 1: ./tools/objtool/objtool: not found

Manually adding the symlink fixes the problem.

If this is indeed the right thing to do, I guess the dh_link that was
added for the -common stanza in debian/rules.real in commit
392435021b7fbec should also be added for the _$(ARCH one):

--- a/debian/rules.real
+++ b/debian/rules.real
@@ -348,6 +348,7 @@ install-headers_$(ARCH)_$(FEATURESET)_$(FLAVOUR): 
$(STAMPS_DIR)/build_$(ARCH)_$(
@echo ' @:' >> $(DIR)/Makefile
 
dh_link /usr/lib/$(PACKAGE_NAME_KBUILD)/scripts $(BASE_DIR)/scripts
+   dh_link /usr/lib/$(PACKAGE_NAME_KBUILD)/tools $(BASE_DIR)/tools
 
mkdir -p $(PACKAGE_DIR)/lib/modules/$(REAL_VERSION)
ln -s /usr/src/$(PACKAGE_NAME) 
$(PACKAGE_DIR)/lib/modules/$(REAL_VERSION)/build


Kind regards,
Luca Boccassi

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

Bug#885185: Can't get gscan2pdf to work properly (i.e. give even half-decent output)

[Jeff]

On 04/01/18 17:59, Jeff wrote:
> Sure. Perhaps I should point people at the reportbug utility, which
> makes it easier to report bugs in Debian packages.

I have added a sentence about the reportbug utility to the docs. You
should see this in the next release.



signature.asc
Description: OpenPGP digital signature

Bug#885423: [Pkg-opencl-devel] Bug#885423: Beignet: self-test failed: (3, 7, 5) + (5, 7, 3) returned (6, 7, 5)

[Rebecca N. Palmer]

Control: tags -1 patch

Description: Fix self-test fail in Darktable

Reverts upstream 81755054c4c19d821e58456a1a7d601806e60e92

Author: Rebecca N. Palmer 
Bug-Debian: https://bugs.debian.org/885423
Forwarded: todo

diff --git b/backend/src/backend/gen_insn_selection_optimize.cpp a/backend/src/backend/gen_insn_selection_optimize.cpp
index 07547ec4..d2e0fb9b 100644
--- b/backend/src/backend/gen_insn_selection_optimize.cpp
+++ a/backend/src/backend/gen_insn_selection_optimize.cpp
@@ -74,7 +74,8 @@ namespace gbe
   const GenRegister& replacement) :
   insn(insn), intermedia(intermedia), replacement(replacement)
   {
-assert(insn.opcode == SEL_OP_MOV || insn.opcode == SEL_OP_ADD);
+assert(insn.opcode == SEL_OP_MOV);
+assert(&(insn.src(0)) == );
 assert(&(insn.dst(0)) == );
 this->elements = CalculateElements(intermedia, insn.state.execWidth);
 replacementOverwritten = false;
@@ -101,7 +102,6 @@ namespace gbe
 void doReplacement(ReplaceInfo* info);
 bool CanBeReplaced(const ReplaceInfo* info, const SelectionInstruction& insn, const GenRegister& var);
 void cleanReplaceInfoMap();
-void doNegAddOptimization(SelectionInstruction );
 
 SelectionBlock 
 const ir::Liveness::LiveOut& liveout;
@@ -159,13 +159,8 @@ namespace gbe
 
   void SelBasicBlockOptimizer::addToReplaceInfoMap(SelectionInstruction& insn)
   {
-assert(insn.opcode == SEL_OP_MOV || insn.opcode == SEL_OP_ADD);
-GenRegister  = insn.src(0);
-if (insn.opcode == SEL_OP_ADD) {
-  if (src.file == GEN_IMMEDIATE_VALUE)
-src = insn.src(1);
-}
-
+assert(insn.opcode == SEL_OP_MOV);
+const GenRegister& src = insn.src(0);
 const GenRegister& dst = insn.dst(0);
 if (src.type != dst.type || src.file != dst.file)
   return;
@@ -254,29 +249,10 @@ namespace gbe
 
   if (insn.opcode == SEL_OP_MOV)
 addToReplaceInfoMap(insn);
-
-  doNegAddOptimization(insn);
 }
 cleanReplaceInfoMap();
   }
 
-  /* LLVM transform Mad(a, -b, c) to
- Add b, -b, 0
- Mad val, a, b, c
- for Gen support negtive modifier, mad(a, -b, c) is native suppoted.
- Also it can be used for the same like instruction sequence.
- Do it just like a:  mov b, -b, so it is a Mov operation like LocalCopyPropagation
-  */
-  void SelBasicBlockOptimizer::doNegAddOptimization(SelectionInstruction ) {
-if (insn.opcode == SEL_OP_ADD) {
-  GenRegister src0 = insn.src(0);
-  GenRegister src1 = insn.src(1);
-  if ((src0.negation && src1.file == GEN_IMMEDIATE_VALUE && src1.value.f == 0.0f) ||
-  (src1.negation && src0.file == GEN_IMMEDIATE_VALUE && src0.value.f == 0.0f))
-addToReplaceInfoMap(insn);
-}
-  }
-
   void SelBasicBlockOptimizer::run()
   {
 for (size_t i = 0; i < MaxTries; ++i) {

Bug#886365: override: kdewebdev:metapackages/optional, kde-baseapps:metapackages/optional

[Pino Toscano]

Package: ftp.debian.org
Severity: normal

Hi,

kdewebdev, and kde-baseapps have been metapackages for long time, but
not properly set with their priority; now they are, so please adjust
the overrides according to that.

Thanks,
-- 
Pino

Bug#838178: tracker.debian.org: "action needed" details show only with Javascript enabled

[Thomas Schmitt]

Hi,

Pierre-Elliott Bécue wrote:
> I pushed a patch to have the tracker behaving in a proper way even though
> javascript is disabled.

That's great news. Since today i began to ponder whether pointing to
  
https://www.react-etc.net/entry/exploiting-speculative-execution-meltdown-spectre-via-javascript
would be appropriate. (I yet fail to see how the time measurement part
of the exploit can be done via JavaScript. But up to yesterday i failed
to see how one could spy on the host kernel out of a VM.)

As for the optical impression: it looks ok with 1 item as on
  https://tracker.debian.org/pkg/libisoburn
but a bit overcrowded with 8 items on
  https://tracker.debian.org/pkg/systemd

My local Iceweasel 31.7.0 with JavaScript enabled does not toggle anything
by the "v" link, which on mouse-over says "Toggle details". The items stay
expanded.
Is that link now obsolete ?


Have a nice day :)

Thomas

Bug#886364: valgrind: epoll_pwait can have a NULL sigmask

[Lukas Slebodnik]

Package: valgrind
Version: 1:3.13.0-1
Severity: normal
Tags: upstream patch

Dear Maintainer,

glibc was recently updates in debian unstable to 2.26-1 and revealed bug
in valgrind. Fortunatelly it is already fixed in valgrind upstream.
https://bugs.kde.org/show_bug.cgi?id=381289

I would appreaciate if you could backport related patch to debian
unstable.


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

Kernel: Linux 4.13.12-200.fc26.x86_64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages valgrind depends on:
ii  libc6  2.26-1
ii  libc6-dbg  2.26-1

Versions of packages valgrind recommends:
pn  gdb   
pn  valgrind-dbg  

Versions of packages valgrind suggests:
pn  alleyoop  
pn  kcachegrind   
pn  valgrind-mpi  
pn  valkyrie  

-- no debconf information

Bug#886238: Please introduce official nosystemd build profile

[Marco d'Itri]

On Jan 04, Hleb Valoshka <375...@gmail.com> wrote:

> "anti-systemd zealots" Steve, when did you join LP fanclub? When
> Ubuntu decided to throw away your upstart and use systemd instead?
Classy...

> Do we have runtime systemd detection in all software linked against
> libsystemd so it will work properly in absence of systemd? To rebuild
Yes, because it is built-in in libsystemd.
Please file bugs if you can find any counterexamples.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#881985: [request-tracker-maintainers] Bug#881985: Bug#881985: request-tracker4: Correctly set RT version in configure if a Debian epoch is used

[Andrew Ruthven]

On Thu, 2018-01-04 at 21:57 +, Dominic Hargreaves wrote:
> Hi Andrew,
> 
> I actually committed essentially that change a while ago but didn't
> feel it warranted an upload by itself. Sorry that wasn't clear -
> I should have commented at the same time as tagging pending.

Ah, no worries. I just thought I should clean up the patch since I was
doing other RT work.

Thanks for commiting it.

-- 
Andrew Ruthven, Wellington, New Zealand
Data Centre Manager
MIITP

At work: andrew.ruth...@catalyst.net.nz
At home: and...@etc.gen.nz
Card   : http://qr.catalyst.net.nz/907675e1
Cloud  : NZs only real cloud - https://catalyst.net.nz/cloud
GPG fpr: C603 FC4E 600F 1CEC D1C8  D97C 4B53 D931 E4D3 E863
LCA2018: Just a little bit of history repeating - http://linux.conf.au

Bug#886363: libdatetime-locale-perl: After upgrade from Jessie to Stretch, Can't locate DateTime/Locale/en_US.pm in @INC

[Reiner Buehl]

Package: libdatetime-locale-perl
Version: 1:1.17-1
Severity: important

Dear Maintainer,

after upgrading my system from Jessie to Stretch, I get the following error 
messages from a perl skript that used to work fine before the upgrade:

Can't locate DateTime/Locale/en_US.pm in @INC (you may need to install the 
DateTime::Locale::en_US module) (@INC contains: /etc/perl 
/usr/local/lib/i386-linux-gnu/perl/5.24.1 /usr/local/share/perl/5.24.1 
/usr/lib/i386-linux-gnu/perl5/5.24 /usr/share/perl5 
/usr/lib/i386-linux-gnu/perl/5.24 /usr/share/perl/5.24 /usr/local/lib/site_perl 
/usr/lib/i386-linux-gnu/perl-base) at 
/usr/lib/i386-linux-gnu/perl/5.24/Storable.pm line 389,  line 1.
BEGIN failed--compilation aborted,  line 1, at 
/home/reiner/bin/FollowTwitterStream.pl line 24.

I tried to upgrade the libdatetime-locale-perl package to the 1.17-1 version 
from Testing but the problem stays the same. Is there a way to fix this?



-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages libdatetime-locale-perl depends on:
ii  libfile-sharedir-perl  1.104-1
ii  libnamespace-autoclean-perl0.28-1
ii  libparams-validationcompiler-perl  0.23-1
ii  libscalar-list-utils-perl  1:1.47-1
ii  libspecio-perl 0.33-1
ii  perl   5.24.1-3+deb9u2
ii  perl-base [libscalar-list-utils-perl]  5.24.1-3+deb9u2

libdatetime-locale-perl recommends no packages.

libdatetime-locale-perl suggests no packages.

-- no debconf information

Bug#881985: [request-tracker-maintainers] Bug#881985: Bug#881985: request-tracker4: Correctly set RT version in configure if a Debian epoch is used

[Dominic Hargreaves]

On Wed, Jan 03, 2018 at 02:24:27PM +1300, Andrew Ruthven wrote:
> Update patch to only strip the epoch off the version is attached.

Hi Andrew,

I actually committed essentially that change a while ago but didn't
feel it warranted an upload by itself. Sorry that wasn't clear -
I should have commented at the same time as tagging pending.

Cheers,
Dominic.

Bug#886343: lintian: missing-notice-file-for-apache-license false positives

[Chris Lamb]

tags 886343 + pending
thanks

Ferenc,

Thanks for the report. I have fixed this in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=28028299a402eb8d87176a537facc437ab89b6c6


Regards,

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

Bug#873006: libgtk3-webkit2-perl: autopkgtest failures

[gregor herrmann]

On Mon, 01 Jan 2018 13:24:34 +0200, Niko Tyni wrote:

> > libgtk3-webkit2-perl fails autopkgtest-pkg-perl's use.t:
> 
> > # Typelib file for namespace 'WebKit2', version '4.0' not found at 
> > /usr/lib/x86_64-linux-gnu/perl5/5.26/Glib/Object/Introspection.pm line 108.
> > # BEGIN failed--compilation aborted.
> > not ok 1 -  /usr/bin/perl -w -M"Gtk3::WebKit2" -e 1 2>&1 exited successfully
> 
> > Not sure if this is an indication of an even more serious (sic!)
> > problem in the package ...
> 
> strace shows
> 
> 7243  open("/usr/lib/girepository-1.0/WebKit2-4.0.typelib", O_RDONLY) = -1 
> ENOENT (No such file or directory)
> 
> The file is found in the gir1.2-webkit2-4.0 package. Looks like the
> module is unusable without that, so raising the severity.
> 
> The build time tests pass because of the build-dep on
> libwebkit2gtk-4.0-dev (which pulls in gir1.2-webkit2-4.0); perhaps that's
> the right thing to do for runtime as well?

Yeah, worth a try.

Unfortunately trying in git is not so easy, as the repo has the wrong
contents in the pristine-tar branch [0] and no tags.

Mike, could you (fix and/or) push please?


Cheers,
gregor

[0]

gbp:info: Tarballs 'libgtk3-webkit2-perl_0.06.orig.tar.gz' not found at 
'../tarballs/'
gbp:info: Creating 
/home/gregoa/src/git-pkg-perl/meta/packages/build-area/libgtk3-webkit2-perl_0.06.orig.tar.gz
gbp:error: Error creating libgtk3-webkit2-perl_0.06.orig.tar.gz: Pristine-tar 
couldn't checkout "libgtk3-webkit2-perl_0.06.orig.tar.gz": fatal: Path 
'libgtk3-webkit2-perl_0.06.orig.tar.gz.delta' does not exist in 
'refs/heads/pristine-tar'
pristine-tar: git show 
refs/heads/pristine-tar:libgtk3-webkit2-perl_0.06.orig.tar.gz.delta failed


And the existant files are:
libgtk3-webkit-perl_0.06.orig.tar.gz.delta  
libgtk3-webkit-perl_0.06.orig.tar.gz.id


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


signature.asc
Description: Digital Signature

Bug#886362: openmw FTBFS on armel/armhf: error: 'GL_AMBIENT' was not declared in this scope

[Adrian Bunk]

Source: openmw
Version: 0.43.0-2
Severity: important

https://buildd.debian.org/status/package.php?p=openmw=sid

...
/<>/components/sceneutil/lightmanager.cpp: In member function 
'void SceneUtil::LightStateAttribute::applyLight(GLenum, const osg::Light*) 
const':
/<>/components/sceneutil/lightmanager.cpp:78:34: error: 
'GL_AMBIENT' was not declared in this scope
 glLightfv( lightNum, GL_AMBIENT,   
light->getAmbient().ptr() );
  ^~
/<>/components/sceneutil/lightmanager.cpp:78:34: note: suggested 
alternative: 'GL_BLEND'
 glLightfv( lightNum, GL_AMBIENT,   
light->getAmbient().ptr() );
  ^~
  GL_BLEND
/<>/components/sceneutil/lightmanager.cpp:78:13: error: 
'glLightfv' was not declared in this scope
 glLightfv( lightNum, GL_AMBIENT,   
light->getAmbient().ptr() );
 ^
/<>/components/sceneutil/lightmanager.cpp:78:13: note: suggested 
alternative: 'mLights'
 glLightfv( lightNum, GL_AMBIENT,   
light->getAmbient().ptr() );
 ^
 mLights
...


Ideally it should be made working to build when Qt is using
OpenGL ES, bug if that is not possible it would be better to
avoid the FTBFS by changing the build dependency from
libqt5opengl5-dev to libqt5opengl5-desktop-dev.

Bug#886343: lintian: missing-notice-file-for-apache-license false positives

[Chris Lamb]

tags 886343 + pending
thanks

Ferenc,

Thanks for the report. I have fixed this in Git:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=28028299a402eb8d87176a537facc437ab89b6c6


Regards,

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

Bug#885525: [Pkg-utopia-maintainers] Bug#885525: Bug#885525: better log output

[Sean DuBois]

And here is the patch!

Feel free to change anything, but I rebuilt locally and everything seems
to be working 100% for me. This is the exact code upstream is using, but
should be good enough until they release a new version.

thanks
From: Sean DuBois 
Date: Thu, 04 Jan 2018 15:42:41 +0600
Subject: Fix segfault on VPN connect

Refactor in VPN applet introduced double free, this was fixed
upstream with
a52ccb2fe170558fc0aab4dd1d15ba8808b10951

Closes: #815313

Index: network-manager-applet-1.8.10/shared/nm-utils/nm-compat.c
===
--- network-manager-applet-1.8.10.orig/shared/nm-utils/nm-compat.c
+++ network-manager-applet-1.8.10/shared/nm-utils/nm-compat.c
@@ -40,30 +40,37 @@ _get_keys (NMSettingVpn *setting,
 {
 	guint len;
 	const char **keys = NULL;
-	gs_unref_ptrarray GPtrArray *a = NULL;
+	GPtrArray *a;

 	nm_assert (NM_IS_SETTING_VPN (setting));

-	a = g_ptr_array_new ();
+	if (is_secrets)
+		len = nm_setting_vpn_get_num_secrets (setting);
+	else
+		len = nm_setting_vpn_get_num_data_items (setting);
+
+	a = g_ptr_array_sized_new (len + 1);
+
 	if (is_secrets)
 		nm_setting_vpn_foreach_secret (setting, _get_keys_cb, a);
 	else
 		nm_setting_vpn_foreach_data_item (setting, _get_keys_cb, a);
-	len = a->len;

-	if (a->len) {
+	len = a->len;
+	if (len) {
 		g_ptr_array_sort (a, nm_strcmp_p);
 		g_ptr_array_add (a, NULL);
-		keys = (const char **) g_ptr_array_free (g_steal_pointer (), FALSE);
+		keys = g_memdup (a->pdata, a->len * sizeof (gpointer));

 		/* we need to cache the keys *somewhere*. */
 		g_object_set_qdata_full (G_OBJECT (setting),
 		 is_secrets
 		 ? NM_CACHED_QUARK ("libnm._nm_setting_vpn_get_secret_keys")
 		 : NM_CACHED_QUARK ("libnm._nm_setting_vpn_get_data_keys"),
-		 keys,
+		 g_ptr_array_free (a, FALSE),
 		 (GDestroyNotify) g_strfreev);
-	}
+	} else
+		g_ptr_array_free (a, TRUE);

 	NM_SET_OUT (out_length, len);
 	return keys;

Bug#885525: [Pkg-utopia-maintainers] Bug#885525: Bug#885525: better log output

[Sean DuBois]

On Wed, 3 Jan 2018 20:49:01 +0100 Michael Biebl  wrote:
> Control: tags -1 + fixed-upstream patch
> 
> Am 03.01.2018 um 20:29 schrieb Sean DuBois:
> > Hey Michael,
> > 
> > This is fixed upstream
> > https://git.gnome.org/browse/network-manager-applet/commit/?id=a52ccb2fe170558fc0aab4dd1d15ba8808b10951
> 
> Thanks you, Sean!
> 
> I've marked the bug accordingly
> 
> 
> -- 
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> 

Bug#886360: please provide a stable backport

[Jeremy Bicha]

On Thu, Jan 4, 2018 at 4:27 PM, W. Martin Borgert  wrote:
> Hi, thanks for this package. It is already used by Gajim (XMPP
> chat client) and some users would like to use emoji also in the
> Gajim backport. Which means, they need this as backport, too!

Could you test whether it works in Stretch? The color emoji support
advertised in GNOME 3.26 requires a newer cairo, pango, gtk3, and
fontconfig than exist in Stretch. (That's why Ubuntu 17.10 didn't get
the feature because it only had some of those pieces.)

Thanks,
Jeremy Bicha

Bug#886361: apertium: frequent parallel FTBFS

[Adrian Bunk]

Source: apertium
Version: 3.4.2~r68466-3
Severity: serious
Tags: patch

https://tests.reproducible-builds.org/debian/history/apertium.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/apertium.html
https://buildd.debian.org/status/package.php?p=apertium=sid

...
/bin/bash ../libtool  --tag=CXX   --mode=link g++  -Wall -Wextra -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security  -Wl,-z,relro -Wl,-z,now -o apertium-filter-ambiguity 
apertium_filter_ambiguity.o -llttoolbox3 -lxml2 -lpcre -lapertium3 -lpcreposix 
-lpcre -lpcrecpp -llttoolbox3 -lxml2 -lpcre
libtool: link: g++ -Wall -Wextra -g -O2 "-fdebug-prefix-map=/<>=." 
-fstack-protector-strong -Wformat -Werror=format-security -Wl,-z -Wl,relro 
-Wl,-z -Wl,now -o apertium-filter-ambiguity apertium_filter_ambiguity.o  
-lapertium3 -lpcreposix -lpcrecpp -llttoolbox3 -lxml2 -lpcre
/usr/bin/ld: cannot find -lapertium3
collect2: error: ld returned 1 exit status
Makefile:1056: recipe for target 'apertium-filter-ambiguity' failed
make[3]: *** [apertium-filter-ambiguity] Error 1


This was triggered by dh comat >= 10 defaulting to parallel building.

Fix attached.
Description: Fix parallel FTBFS
 Tell automake that libapertium3 is a self-built library
 so that proper dependencies are added.
Author: Adrian Bunk 

--- apertium-3.4.2~r68466.orig/apertium/Makefile.am
+++ apertium-3.4.2~r68466/apertium/Makefile.am
@@ -226,7 +226,7 @@ apertium_DATA = deformat.xsl reformat.xs
 
 apertium_pretransfer_SOURCES = apertium_pretransfer.cc
 apertium_multiple_translations_SOURCES = apertium-multiple-translations.cc
-apertium_multiple_translations_LDADD = $(APERTIUM_LIBS) 
-lapertium$(GENERIC_MAJOR_VERSION)
+apertium_multiple_translations_LDADD = $(APERTIUM_LIBS) libapertium3.la
 apertium_destxt_SOURCES = apertium_destxt.cc
 apertium_retxt_SOURCES = apertium_retxt.cc
 apertium_deshtml_SOURCES = apertium_deshtml.cc
@@ -249,55 +249,55 @@ apertium_repptx_SOURCES = apertium_reppt
 apertium_desmediawiki_SOURCES = apertium_desmediawiki.cc
 apertium_remediawiki_SOURCES = apertium_remediawiki.cc
 apertium_prelatex_SOURCES = apertium_prelatex.cc
-apertium_prelatex_LDADD= $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_prelatex_LDADD= $(APERTIUM_LIBS) libapertium3.la
 apertium_postlatex_SOURCES = apertium_postlatex.cc
-apertium_postlatex_LDADD= $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_postlatex_LDADD= $(APERTIUM_LIBS) libapertium3.la
 apertium_postlatex_raw_SOURCES = apertium_postlatex_raw.cc
-apertium_postlatex_raw_LDADD= $(APERTIUM_LIBS) 
-lapertium$(GENERIC_MAJOR_VERSION)
+apertium_postlatex_raw_LDADD= $(APERTIUM_LIBS) libapertium3.la
 
 apertium_tagger_SOURCES = apertium_tagger.cc
-apertium_tagger_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_tagger_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_tmxbuild_SOURCES = apertium_tmxbuild.cc
-apertium_tmxbuild_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_tmxbuild_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_preprocess_transfer_SOURCES = transferpp.cc
 apertium_preprocess_transfer_LDADD = $(APERTIUM_LIBS) \
- -lapertium$(GENERIC_MAJOR_VERSION)
+ libapertium3.la
 
 apertium_filter_ambiguity_SOURCES = apertium_filter_ambiguity.cc
 apertium_filter_ambiguity_LDADD = $(APERTIUM_LIBS) \
-  -lapertium$(GENERIC_MAJOR_VERSION)
+  libapertium3.la
 
 apertium_transfer_SOURCES = apertium_transfer.cc
-apertium_transfer_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_transfer_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_interchunk_SOURCES = apertium_interchunk.cc
-apertium_interchunk_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_interchunk_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_postchunk_SOURCES = apertium_postchunk.cc
-apertium_postchunk_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+apertium_postchunk_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 ###apertium_lextor_SOURCES = apertium_lextor.cc
-###apertium_lextor_LDADD = $(APERTIUM_LIBS) -lapertium$(GENERIC_MAJOR_VERSION)
+###apertium_lextor_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 #apertium_lextor_eval_SOURCES = apertium-lextor-eval.C
-#apertium_lextor_eval_LDADD = $(APERTIUM_LIBS) 
-lapertium$(GENERIC_MAJOR_VERSION)
+#apertium_lextor_eval_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_tagger_apply_new_rules_SOURCES = apertium_tagger_apply_new_rules.cc
-apertium_tagger_apply_new_rules_LDADD = $(APERTIUM_LIBS) 
-lapertium$(GENERIC_MAJOR_VERSION)
+apertium_tagger_apply_new_rules_LDADD = $(APERTIUM_LIBS) libapertium3.la
 
 apertium_tagger_readwords_SOURCES = apertium_tagger_readwords.cc
-apertium_tagger_readwords_LDADD = $(APERTIUM_LIBS) 
-lapertium$(GENERIC_MAJOR_VERSION)
+apertium_tagger_readwords_LDADD = 

Bug#886355: Pending fixes for bugs in the libpar-packer-perl package

[pkg-perl-maintainers]

tag 886355 + pending
thanks

Some bugs in the libpar-packer-perl package are closed in revision
c8b6951552e57ae9e090344577c6b0b00ea5e01d in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libpar-packer-perl.git/commit/?id=c8b6951

Commit message:

debian/rules: disable parallel building.

Thanks: Adrian Bunk for the bug report and the patch.
Closes: #886355

Bug#863108: closed by Tobias Frost <t...@debian.org> (Re: RFS: minecraft-installer/0.1-2 [ITP] -- Unofficial way to easily install Minecraft game)

[Carlos Donizete Froes]

Hi,

> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
> 
> #863108: RFS: minecraft-installer/0.1-1 [ITP] -- Unofficial way to easily 
> install Minecraft game
> 
> It has been closed by Tobias Frost .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Tobias Frost 
>  by
> replying to this email.
> 

You can remove my 'minecraft-installer' project from Debian Bug. I am no longer 
developing this
software.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#864165: closed by Tobias Frost <t...@debian.org> (Re: RFS: stendhal-installer/0.1-1 [ITP] -- Unofficial way to easily install game)

[Carlos Donizete Froes]

Hi, 

> This is an automatic notification regarding your Bug report
> which was filed against the sponsorship-requests package:
> 
> #864165: RFS: stendhal-installer/0.1-2 [ITP] -- Unofficial way to easily 
> install Stendhal game
> 
> It has been closed by Tobias Frost .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Tobias Frost 
>  by
> replying to this email.

You can remove my 'stendhal-installer' project from Debian Bug. I am no longer 
developing this
software.

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#886360: please provide a stable backport

[W. Martin Borgert]

Package: fonts-noto-color-emoji
Version: 0~20171204-1
Severity: wishlist

Hi, thanks for this package. It is already used by Gajim (XMPP
chat client) and some users would like to use emoji also in the
Gajim backport. Which means, they need this as backport, too!
Thanks for considering!

Bug#886359: infinipath-psm FTBFS on i386: missing symbol ipath_dwordcpy_safe

[Adrian Bunk]

Source: infinipath-psm
Version: 3.3+20.604758e7-3
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=infinipath-psm=i386=3.3%2B20.604758e7-3=1515071279=0

...
   dh_makeshlibs -a -O--parallel
dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols 
file: see diff output below
dpkg-gensymbols: warning: no debian/symbols file used as basis for generating 
debian/libpsm-infinipath1/DEBIAN/symbols
--- new_symbol_file (libpsm-infinipath1_3.3+20.604758e7-3_i386)
+++ dpkg-gensymbolscQjnKE   2018-01-04 13:07:52.434415479 +
@@ -32,7 +32,7 @@
  ipath_context_open@Base 3.3+7.gec1d6d2
  ipath_disarm_bufs@Base 3.3+7.gec1d6d2
  ipath_dwordcpy@Base 3.3+7.gec1d6d2
- ipath_dwordcpy_safe@Base 3.3+7.gec1d6d2
+#MISSING: 3.3+20.604758e7-3# ipath_dwordcpy_safe@Base 3.3+7.gec1d6d2
  ipath_event_ack@Base 3.3+7.gec1d6d2
  ipath_flash_csum@Base 3.3+7.gec1d6d2
  ipath_flush_egr_bufs@Base 3.3+7.gec1d6d2
dh_makeshlibs: failing due to earlier errors
debian/rules:15: recipe for target 'binary-arch' failed
make: *** [binary-arch] Error 2

Bug#878021: patches to update gnome-commander packaging to 1.8.0

[Jeremy Bicha]

On Thu, Jan 4, 2018 at 3:55 PM, Andreas Henriksson  wrote:
> The packaging can be updated by applying the attached patches:

Just a heads up that that I uploaded an NMU recently and just pushed
my finalized debian/changelog to git now so please rebase. Sorry about
that.

Thanks,
Jeremy Bicha

Bug#848674: O: f3 -- test real flash memory capacity

[Mathieu Malaterre]

> I'm interested in taking over this package. I've worked with upstream
> and I use it from time to time. I'll monitor upstream which I hope will
> produce a new release soon and then I'll switch maintainership.

v7.0 has just been released \o/

https://github.com/AltraMayor/f3/releases/tag/v7.0

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Hi Tobias,

> Control: tags -1 moreinfo
> 
> Hi Carlos,
> 
> you saw the reject from the FTP masters already, I guess.
> Please update d/copyright and then ping me again.
> 
> Tobi

I have made copyright changes in 'd/copyright'

Please check mentors.d.n

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

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#884740: RFS: pokemmo/1.4.2-1 [ITP] -- Multiplayer online game based on the Pokemon universe

[Carlos Donizete Froes]

Hi Tobias,

> Control: tags -1 moreinfo
> 
> Hi Carlos,
> 
> you saw the reject from the FTP masters already, I guess.
> Please update d/copyright and then ping me again.
> 
> Tobi

I have made copyright changes in 'd/copyright'

Please check mentors.d.n

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

Thanks!

-- 
⢀⣴⠾⠻⢶⣦⠀ Carlos Donizete Froes [a.k.a coringao]
⣾⠁⢠⠒⠀⣿⡁ - https://wiki.debian.org/coringao
⢿⡄⠘⠷⠚⠋⠀ GPG: 4096R/B638B780
⠈⠳⣄⠀⠀⠀   2157 630B D441 A775 BEFF  D35F FA63 ADA6 B638 B780

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

Bug#886182: transition: glibc 2.26

[Aurelien Jarno]

On 2018-01-02 22:47, Emilio Pozuelo Monfort wrote:
> Control: tags -1 confirmed
> 
> On 02/01/18 22:37, Aurelien Jarno wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > I would like to get a transition slot for glibc 2.26. It is available in
> > experimental for one month and a half, and there is no known regression.
> > It has been built successfully on all release architectures, and most
> > other architectures besides kfreebsd-* which do not have build daemons
> > anymore. The failures on hurd-i386 and hppa are being worked on and can
> > be fixed in the upload to sid or later, so I don't think we should block
> > the transition on that.
> > 
> > As the glibc is using symbol versioning, there is no soname change. That
> > said a few packages are using libc internal symbols and have to be
> > rebuilt for this transition:
> >  - apitrace
> >  - bro
> >  - dante
> >  - libnih
> >  - libnss-db
> >  - p11-kit
> >  - unscd
> > 
> > Here is the corresponding ben file:
> >   title = "glibc";
> >   is_affected = .depends ~ /libc[0-9.]* \(< >   is_good = .depends ~ /libc[0-9.]* \(<< 2.27\)/;
> >   is_bad = .depends ~ /libc[0-9.]* \(<< 2.26\)/;
> > 
> > In addition a few new symbols have been added that might prevent a few
> > other packages to migrate to testing until glibc migrates if they pick
> > up the new symbols. That's mostly the case for libm.so, which added
> > 128-bit floating point support on amd64, i386, and ppc64el. On the
> > libc.so side the new functions are reallocarray, preadv2 and pwritev2,
> > which should not be widely used so far.
> > 
> > Thanks for considering
> 
> Please go ahead.

Thanks. I uploaded it yesterday and it has now been built on all
official architectures.

Aurelien

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


signature.asc
Description: PGP signature

Bug#878021: patches to update gnome-commander packaging to 1.8.0

[Andreas Henriksson]

Control: tags -1 + patch

Hello!

After importing the new (1.8.0) upstream release using:
gbp import-orig --uscan --pristine-tar

The packaging can be updated by applying the attached patches:
git am $ATTACHED_PATCHES

And updating debian/changelog:
gbp dch --auto
dch -r

HTH.

Regards,
Andreas Henriksson
>From d40c220668c7812a0e74893d4047f436e1cb614e Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Thu, 4 Jan 2018 21:19:57 +0100
Subject: [PATCH 1/4] Update debian/changelog

---
 debian/changelog | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 10e4805..bacb302 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,11 +1,15 @@
-gnome-commander (1.4.8-1.1) UNRELEASED; urgency=medium
+gnome-commander (1.8.0-1) UNRELEASED; urgency=medium
 
+  [ Jeremy Bicha ]
   * Non-maintainer upload.
   * Build-Depend on python3-scour to fix build failure with latest scour
   * Drop obsolete Build-Depends on rarian-compat (Closes: #885640)
   * Don't suggest gnome-user-guide (Closes: #879561) (LP: #1691867)
 
- -- Jeremy Bicha   Thu, 28 Dec 2017 14:02:42 -0500
+  [ Andreas Henriksson ]
+  * New upstream release (Closes: #878021)
+
+ -- Andreas Henriksson   Thu, 04 Jan 2018 21:17:54 +0100
 
 gnome-commander (1.4.8-1) unstable; urgency=medium
 
-- 
2.15.1

>From 9b1cbfe2f5c9e83070e69de4a63c9e735f5bcd89 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Thu, 4 Jan 2018 21:20:06 +0100
Subject: [PATCH 2/4] Update build-dependencies according to upstream changes

- drop intltool and gnome-doc-utils
- add yelp-tools
- bump version of glib and gtk+

Gbp-Dch: Full
---
 debian/control | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/debian/control b/debian/control
index 172f11e..fd30484 100644
--- a/debian/control
+++ b/debian/control
@@ -7,14 +7,13 @@ Uploaders:
 Build-Depends:
  debhelper (>= 9~),
  dh-autoreconf,
- gnome-doc-utils,
- intltool,
+ yelp-tools,
  libexiv2-dev (>= 0.14),
- libglib2.0-dev (>= 2.0),
+ libglib2.0-dev (>= 2.44.0),
  libgnome2-dev (>= 2.0),
  libgnomeui-dev (>= 2.4),
  libgnomevfs2-dev (>= 2.0),
- libgtk2.0-dev (>= 2.8),
+ libgtk2.0-dev (>= 2.18.0),
  libpoppler-glib-dev,
  libssl-dev,
  libtag1-dev (>= 1.4),
-- 
2.15.1

>From dbd578f33d07d21d58c411cef26c839c98d2be7a Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Thu, 4 Jan 2018 21:42:30 +0100
Subject: [PATCH 3/4] Add recommends on gnome-icon-theme

If gnome-icon-theme is not installed:

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-home' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-home' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-home' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-network' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-network' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-network' not present in theme

** (gnome-commander:27014): CRITICAL **: void load_devices(const gchar*): assertion 'keyfile != NULL' failed

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme

** (gnome-commander:27014): WARNING **: Couldn't load icon: Icon 'gnome-fs-ftp' not present in theme
---
 debian/control | 1 +
 1 file changed, 1 insertion(+)

diff --git a/debian/control b/debian/control
index fd30484..571a82b 100644
--- a/debian/control
+++ b/debian/control
@@ -34,6 +34,7 @@ Depends:
  ${misc:Depends},
  ${python:Depends},
  ${shlibs:Depends}
+Recommends: gnome-icon-theme
 Suggests:
  libgnomevfs2-extra,
  meld
-- 
2.15.1

>From 3b12885a1d16606e51931eb416e6c9c447b52038 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Thu, 4 Jan 2018 21:44:20 +0100
Subject: [PATCH 4/4] Drop gnome-commander-dbg and do dbgsym migration

Automatic dbgsym packages are built these days and having
dedicated -dbg packages is deprecated. Drop the -dbg
package and tell debhelper (dh_strip) to insert the
proper migration code.
---
 debian/control | 14 --
 debian/rules   |  2 +-
 2 files changed, 1 insertion(+), 15 deletions(-)

diff --git a/debian/control b/debian/control
index 571a82b..b4d2c5e 100644
--- a/debian/control
+++ b/debian/control
@@ -59,17 +59,3 @@ Description: Data 

Bug#886182: transition: glibc 2.26

[Michael Biebl]

Am 04.01.2018 um 20:05 schrieb Simon McVittie:
> (In particular, I'm trying to release ostree to fix a RC bug, but it now
> fails to build due to a hilarious dependency chain involving
> gjs -> libgtk-3-0 -> dconf-gsettings-backend -> dconf-service ->
> dbus-user-session -> libpam-systemd -> systemd-shim -> cgmanager -> libnih1
> due to CTTE decision #746578 preferring systemd-shim over systemd-sysv.)

See related #883573.
Fwiw, after pondering about this for a while, I consider dropping the
Depends: systemd-shim | systemd-sysv
from libpam-systemd altogether.
The vast majority of users using systemd as PID1 will not be affected at
all, users of sysvinit are usually the ones avoiding policykit-1, dbus
etc anyway. So for the few users who actually want to use sysvinit + a
full blown desktop I would leave it up to them to install systemd-shim
manually. This would also avoid pulling an init system for packages
which build-depend on dbus for dbus-run-session (which would also fix
your particular problem)

WDYT? I'd be happy to make a systemd upload dropping this dependency to
unblock ostree.

Cheers,
Michael





signature.asc
Description: OpenPGP digital signature

Bug#886358: chromium: Enable Hangouts screensharing extension

[Tommi Vainikainen]

Package: chromium
Version: 63.0.3239.84-1~deb9u1
Severity: wishlist

Currently debian/rules:52 disables hangouts services (which includes
screenshare feature). I didn't test it, but based on information
elsewhere, simply enabling the flag should make Google Hangouts
screensharing work with Chromium.

Bug#886357: ITP: lamarc -- Likelihood Analysis with Metropolis Algorithm using Random Coalescence

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: lamarc
  Version : 2.1.10.1
  Upstream Author : Mary K. Kuhner, Peter Beerli, and Joseph Felsenstein
* URL : http://evolution.gs.washington.edu/lamarc/
* License : Apache 2.0
  Programming Lang: C++
  Description : Likelihood Analysis with Metropolis Algorithm using Random 
Coalescence
 LAMARC is a program which estimates population-genetic parameters such
 as population size, population growth rate, recombination rate, and
 migration rates. It approximates a summation over all possible
 genealogies that could explain the observed sample, which may be
 sequence, SNP, microsatellite, or electrophoretic data. LAMARC and its
 sister program Migrate are successor programs to the older programs
 Coalesce, Fluctuate, and Recombine, which are no longer being supported.
 The programs are memory-intensive but can run effectively on
 workstations; we support a variety of operating systems.


Remark: This program was distributed with BioLinux which is orphaned now.
The Debian Med team tries to fullfil the gap and take over all free
projects once beeing distributed by BioLinux.  The packaging will be
maintained at
https://anonscm.debian.org/git/debian-med/lamarc.git

Bug#885967: #885967: FTBFS: FAILED test of gethostid ENOENT

[Adam Borowski]

} PATH=`pwd`/bin:$PATH /bin/sh test/07/t0705a.sh
} 2,3c2,3
} < (ENOENT) because there is no "hostid" regular file in the pathname "/etc"
} < directory; did you mean the "hosts" regular file instead?
} ---
} > (ENOENT) because there is no "hostid" regular file in the pathname
} > "/etc" directory
} FAILED test of gethostid ENOENT

Adrian Bunk wrote:
> /etc/hosts is created in the postinst of the netbase package,
> so "missing build dependency on netbase" would be another way
> to describe the problem.

Not sure if this is the best way to fix the failure, although it _would_
make the error message find /etc/hosts there so it can be suggested.

This test is fragile, though -- if you have a file named /etc/hosting or
such, it'll be picked instead of "hosts".

The root cause, though, is that libexplain knows about gethostid, thus it
can rule out an user making a typo -- the function looks for /etc/hostid and
hothing else.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#885963: FTBFS: failed to open /etc/hosts

[Adam Borowski]

On Thu, Jan 04, 2018 at 08:14:31PM +0200, Adrian Bunk wrote:
> On Mon, Jan 01, 2018 at 01:13:57AM +0100, Adam Borowski wrote:
> >...
> > And indeed, in a chroot created with debootstrap --variant=buildd there is
> > no such file anymore.  But, I see that the package doesn't actually need
> > /etc/hosts but just the testsuite uses it as a random file it -thinks- will
> > be always there.  Thanks to our efforts to unbloat the default install, this
> > is no longer true.  Thus, you'd need to pick something else.
> >...
> 
> /etc/hosts is created in the postinst of the netbase package,
> so "missing build dependency on netbase" would be another way
> to describe the problem.

For a generic lack of /etc/hosts, yeah, it'd be the best solution.
In this case, though, I'd rather patch "random text file that's always
present" to something else.


Thanks for enlightening us about /etc/hosts coming from netbase, though!
There's more than just these two bugs where its lack appears.


Meow!
-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#886356: transition: ilmbase

[Matteo F. Vescovi]

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

Dear Release Team,

I'm filing this bug report for a new transition of ilmbase package.

On December 30, 2017 a testing-purpose package has been uploaded to
experimental and it was tested building all its 25 reverse dependencies
on the Deb-o-Matic infrastructure on amd64 architecture.

Following the auto-ilmbase checklist[1], here is the list of source
packages depending on ilmbase and the results of the builds:

  * field3d_1.7.2-1 => OK
  * openexr_2.2.0-11.1 => OK
  * pink-pony_1.4.1-2.1 => OK
  * aqsis_1.8.2-8 => OK
  * calligra_1:3.0.1+dfsg-2 => OK
  * darktable_2.4.0-1 => OK
  * exactimage_1.0.1-1 => OK
  * freeimage_3.17.0+ds1-5 => OK
  * kimageformats_5.37.0-2 => OK
  * krita_1:3.3.2.1+dfsg-1 => OK
  * libvigraimpex_1.10.0+git20160211.167be93+dfsg-5 => OK
  * luminance-hdr_2.4.0-9 => OK
  * nvidia-texture-tools_2.0.8-1+dfsg-8.1 => OK
  * opencv_3.2.0+dfsg-4 => OK
  * openexr-viewers_1.0.1-6 => OK
  * openvdb_5.0.0-1 => OK
  * pfstools_2.1.0-3 => OK
  * povray_1:3.7.0.4-2 => OK
  * synfig_1.0.2-1 => OK
  * vips_8.4.5-1 => OK
  * gmic_1.7.9+zart-4 => OK
  * gst-plugins-bad1.0_1.12.4-2 => OK
  * hugin_2017.0.0+dfsg-1 => OK
  * openimageio_1.8.6~dfsg0-4 => OK
  * blender_2.79+dfsg0-3 => OK

Thanks for your time and patience.

mfv


[1] https://release.debian.org/transitions/html/auto-ilmbase.html

Ben file:

title = "ilmbase";
is_affected = .depends ~ "libilmbase12" | .depends ~ "libilmbase23";
is_good = .depends ~ "libilmbase23";
is_bad = .depends ~ "libilmbase12";


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

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


signature.asc
Description: PGP signature

Bug#886355: libpar-packer-perl: frequent parallel FTBFS

[Adrian Bunk]

Source: libpar-packer-perl
Version: 1.041-1
Severity: serious

https://buildd.debian.org/status/package.php?p=libpar-packer-perl=sid

...
dh_auto_build
make -j6
make[2]: Entering directory '/<>'
cp script/par.pl blib/script/par.pl
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/par.pl
make[3]: Entering directory '/<>/myldr'
Makefile:855: warning: overriding recipe for target '.c.o'
Makefile:336: warning: ignoring old recipe for target '.c.o'
cp script/pp blib/script/pp
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/pp
cp script/tkpp blib/script/tkpp
"/usr/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/tkpp
"/usr/bin/perl" par_pl2c.pl my_par_pl < ../script/par.pl > my_par_pl.c 
"/usr/bin/perl" sha1.c.PL
Can't locate PAR/Filter/PodStrip.pm in @INC (you may need to install the 
PAR::Filter::PodStrip module) (@INC contains: 
/<>/myldr/../blib/arch /<>/myldr/../blib/lib 
/etc/perl /usr/local/lib/aarch64-linux-gnu/perl/5.26.1 
/usr/local/share/perl/5.26.1 /usr/lib/aarch64-linux-gnu/perl5/5.26 
/usr/share/perl5 /usr/lib/aarch64-linux-gnu/perl/5.26 /usr/share/perl/5.26 
/usr/local/lib/site_perl /usr/lib/aarch64-linux-gnu/perl-base .) at par_pl2c.pl 
line 7.
BEGIN failed--compilation aborted at par_pl2c.pl line 7.
Makefile:879: recipe for target 'my_par_pl.c' failed
make[3]: *** [my_par_pl.c] Error 2


This is due to dh compat 10 defaulting to parallel building.

Ideally the build should be fixed to work with parallel building,
but if that's not easily possible the following patch to go back
to non-parallel building is sufficient to fix the bug:

--- debian/rules.old2018-01-04 20:32:58.184625753 +
+++ debian/rules2018-01-04 20:33:08.360625656 +
@@ -10,7 +10,7 @@
 ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
 
 %:
-   dh $@
+   dh $@ --no-parallel
 
 override_dh_auto_build:
dh_auto_build

Bug#884441: [Pkg-d-devel] Bug#884441: dh-dlang requires neon on armhf

[Matthias Klumpp]

2018-01-04 21:23 GMT+01:00 Adrian Bunk :
> [...]
>
> Is this something that still has to be addressed in ldc, or was that
> already addressed back in 2016 in ldc 1:1.1.0git20161002.78c0d69-3
> (and the make snippet in dh-dlang wasn't required at all)?

No. This is issue https://github.com/ldc-developers/ldc/issues/1752
which can't/won't be fixed in LDC for now.
Also, it was kind of agreed on in this report to go with the DFLAGS
solution in Debian for now.

Cheers,
Matthias

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

Bug#886352: tar: garbage instead of owner set in TAR_OPTIONS

[Jakub Wilk]

* Jakub Wilk , 2018-01-04, 21:01:

$ export TAR_OPTIONS='--owner root --group root --mode go-r'
$ tar -cvvf foo.tar /dev/null
tar: Removing leading `/' from member names
crw--w--w- `/dev/null   1,3 2018-01-04 18:42 /dev/null


Valgrind suggests it's a use-after-free:

   Invalid read of size 1
  at 0x48323D8: strlen (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  by 0x14DBD9: xstrdup (xmalloc.c:121)
  by 0x116616: start_header (create.c:944)
  by 0x118070: dump_file0 (create.c:1951)
  by 0x118070: dump_file (create.c:1981)
  by 0x118C43: create_archive (create.c:1438)
  by 0x10E2DA: main (tar.c:2752)
Address 0x4b07280 is 0 bytes inside a block of size 5 free'd
  at 0x4830478: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  by 0x13A222: wordsplit_free_words (wordsplit.c:1551)
  by 0x13A2D9: wordsplit_free (wordsplit.c:1561)
  by 0x10D6AB: parse_default_options (tar.c:2226)
  by 0x10D6AB: decode_options (tar.c:2331)
  by 0x10D6AB: main (tar.c:2726)
Block was alloc'd at
  at 0x482F2BC: malloc (in 
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
  by 0x13AA45: wordsplit_finish (wordsplit.c:557)
  by 0x13AA45: wordsplit_len (wordsplit.c:1529)
  by 0x13AC22: wordsplit (wordsplit.c:1537)
  by 0x10D68C: parse_default_options (tar.c:2217)
  by 0x10D68C: decode_options (tar.c:2331)
  by 0x10D68C: main (tar.c:2726)

--
Jakub Wilk

Bug#884441: [Pkg-d-devel] Bug#884441: dh-dlang requires neon on armhf

[Adrian Bunk]

On Fri, Dec 15, 2017 at 03:13:57PM +0100, Matthias Klumpp wrote:
> 2017-12-15 15:05 GMT+01:00 Matthias Klose :
> > Control: reopen -1
> > Control: reassign -1 ldc
> >
> > On 15.12.2017 13:53, Matthias Klumpp wrote:
> >> 2017-12-15 9:46 GMT+01:00 Matthias Klose :
> >>> [...]
> >
> > ok, but then the issue is in ldc, so you should change the default over 
> > there,
> > like it's done by every other compiler in the distro.
> 
> That's fair enough - the default wasn't changed because upstream
> didn't want user-compiled code to run slower on their machine, and
> Markos, the LDC maintainer, also didn't like this at all.
> Therefore, we change this for Debian packaging only now, as some kind
> of compromise.
> 
> In any case, that's indeed something to be addressed by the LDC
> package, so it makes sense to have the issue report there.

Is this something that still has to be addressed in ldc, or was that 
already addressed back in 2016 in ldc 1:1.1.0git20161002.78c0d69-3
(and the make snippet in dh-dlang wasn't required at all)?

> Cheers,
> Matthias

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Bug#886354: transition: ros-bond-core

[Jochen Sprickerhof]

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

Dear release team,

I would like to transition ros-bond-core to unstable. I tested the
reverse dependencies and found no problems.

Cheers Jochen

Ben file:

title = "ros-bond-core";
is_affected = .depends ~ /\b(libbondcpp0d)\b/ | .depends ~ /\b(libbondcpp1d)\b/;
is_good = .depends ~ /\b(libbondcpp1d)\b/;
is_bad = .depends ~ /\b(libbondcpp0d)\b/;


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

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

Bug#884116: linux-image-4.9.0-3-amd64: screen artifacts then crash without anyway to revert to console

[Mathias Bavay]

Package: src:linux
Followup-For: Bug #884116

Dear Maintainer,

Since sometimes between mid-November and mid-December, my whole system crashes 
within 
a few minutes after boot (90% of the time after less than 2 minutes). The screen
gets various artifacts and the whole system is gone. There is no way to ssh
to the system or switch to a console. No logs are written out (either as
kernel logs, dmesg or Xorg.log). I've tried (binary) linux-image-4.9.0-3-amd64
as well as linux-image-4.9.0-4-amd64, this makes no difference. I've tried
updating the cpu microcode, forcing re-install of the (binary) kernels,
reinstalling mesa, nothing has changed. However, using an older Debian stretch 
live image
on a usb stick worked fine. I'm now using the linux-image-4.14.0 backport and
this works perfectly fine. 

I am using Kde with a theme that relies heavily on transparency and I guess this
makes things worse (I had in the past every now and then warnings that
the driver could not support the proper functions and it would automatically
tunr transparency effects off, a reboot would be enough to fix it). Enabling 
a theme with less transparency effects makes the system work longer before 
crashing.

Finally, I turned off the OpenGL rendering in Kde's settings (switching to
Xrender), but this did not change anything (still crashing as fast).

Feel free to ask me for more informations / tests if needed,
Regards,
Mathias Bavay

-- Package-specific info:
** Version:
Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.9.30-2+deb9u5 (2017-09-19)

** Command line:
BOOT_IMAGE=/vmlinuz-4.9.0-3-amd64 root=/dev/mapper/dorfberg--vg-root ro quiet 
initcall_debug apic=debug

** Not tainted

** Kernel log:
[   10.813637] vgaarb: device changed decodes: 
PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[   10.821546] ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
[   10.821728] input: Video Bus as 
/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input8
[   10.821784] [drm] Initialized i915 1.6.0 20160919 for :00:02.0 on minor 0
[   10.821830] initcall i915_init+0x0/0x54 [i915] returned 0 after 71551 usecs
[   10.821893] IOAPIC[0]: Set routing entry (2-22 -> 0x52 -> IRQ 22 Mode:1 
Active:1 Dest:15)
[   10.821919] initcall azx_driver_init+0x0/0xfd8 [snd_hda_intel] returned 0 
after 70228 usecs
[   10.822802] initcall intel_uncore_init+0x0/0xeac [intel_uncore] returned 0 
after 66742 usecs
[   10.823511] calling  cstate_pmu_init+0x0/0xf56 [intel_cstate] @ 346
[   10.824717] initcall cstate_pmu_init+0x0/0xf56 [intel_cstate] returned 0 
after 1173 usecs
[   10.825062] fbcon: inteldrmfb (fb0) is primary device
[   10.834876] calling  generic_driver_init+0x0/0x1000 [snd_hda_codec_generic] 
@ 404
[   10.834893] initcall generic_driver_init+0x0/0x1000 [snd_hda_codec_generic] 
returned 0 after 13 usecs
[   10.835442] calling  vmx_init+0x0/0x3c3 [kvm_intel] @ 343
[   10.835694] initcall vmx_init+0x0/0x3c3 [kvm_intel] returned 0 after 240 
usecs
[   10.836310] calling  realtek_driver_init+0x0/0x1000 [snd_hda_codec_realtek] 
@ 404
[   10.836968] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC269VB: 
line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker
[   10.836969] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   10.836970] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x21/0x0/0x0/0x0/0x0)
[   10.836970] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   10.836970] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   10.836971] snd_hda_codec_realtek hdaudioC0D0:  Internal Mic=0x19
[   10.836972] snd_hda_codec_realtek hdaudioC0D0:  Mic=0x18
[   10.837527] calling  coretemp_init+0x0/0x1000 [coretemp] @ 334
[   10.837613] initcall coretemp_init+0x0/0x1000 [coretemp] returned 0 after 80 
usecs
[   10.838057] calling  powerclamp_init+0x0/0x1000 [intel_powerclamp] @ 334
[   10.838087] initcall powerclamp_init+0x0/0x1000 [intel_powerclamp] returned 
0 after 26 usecs
[   10.838583] calling  pkg_temp_thermal_init+0x0/0x1000 [x86_pkg_temp_thermal] 
@ 346
[   10.838624] initcall pkg_temp_thermal_init+0x0/0x1000 [x86_pkg_temp_thermal] 
returned 0 after 37 usecs
[   10.838825] calling  acpi_cpufreq_init+0x0/0x1000 [acpi_cpufreq] @ 346
[   10.838827] initcall acpi_cpufreq_init+0x0/0x1000 [acpi_cpufreq] returned 
-17 after 0 usecs
[   10.839555] calling  rapl_init+0x0/0x1000 [intel_rapl] @ 341
[   10.839557] intel_rapl: Found RAPL domain package
[   10.839558] intel_rapl: Found RAPL domain core
[   10.839559] intel_rapl: Found RAPL domain uncore
[   10.839561] intel_rapl: Found RAPL domain dram
[   10.839564] intel_rapl: RAPL package 0 domain package locked by BIOS
[   10.839572] intel_rapl: RAPL package 0 domain dram locked by BIOS
[   10.839728] initcall rapl_init+0x0/0x1000 [intel_rapl] returned 0 after 166 
usecs
[   10.845882] initcall realtek_driver_init+0x0/0x1000 [snd_hda_codec_realtek] 

Bug#801331: jdresolve: diff for NMU version 0.6.1-5.1

[Frederic Peters]

Hi,

> I've prepared an NMU for jdresolve (versioned as 0.6.1-5.1) and uploaded 
> it to DELAYED/5. Please feel free to tell me if I should cancel it.

It's totally fine; thank you.


Fred

Bug#886353: ITP: libmail-box-pop3-perl -- POP3 handler for Mail::Box

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-box-pop3-perl
  Version : 3.003
  Upstream Author : Mark Overmeer 
* URL : https://metacpan.org/release/Mail-Box-POP3
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : POP3 handler for Mail::Box

Mail::Box::POP3 maintains a folder which has its messages stored on a remote
server.  The communication between the client application and the server is
implemented using the POP3 protocol.  This class uses
Mail::Transport::POP3 to hide the transport of information, and focusses
solely on the correct handling of messages within a POP3 folder.
~~

This was part of libmail-box-perl befor eversion 3.

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

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

Bug#886352: tar: garbage instead of owner set in TAR_OPTIONS

[Jakub Wilk]

Package: tar
Version: 1.29b-2

$ export TAR_OPTIONS='--owner root --group root --mode go-r'
$ tar -cvvf foo.tar /dev/null
tar: Removing leading `/' from member names
crw--w--w- `/dev/null   1,3 2018-01-04 18:42 /dev/null


-- System Information:
Architecture: i386

Versions of packages tar depends on:
ii  libacl1  2.2.52-3+b1
ii  libc62.26-1
ii  libselinux1  2.7-2

--
Jakub Wilk

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/3/18, Steve Langasek  wrote:

> Moreover, defining an official nosystemd profile in Debian signals that we
> are willing to support it, which means any maintainers who refuse such
> patches will immediately become the targets of abuse from anti-systemd
> zealots.

"anti-systemd zealots" Steve, when did you join LP fanclub? When
Ubuntu decided to throw away your upstart and use systemd instead?
Should I remind your votes in CTTE?

Please take your Ubuntu employee hat off and speak as DD.


> Building a derivative around the exclusion of libsystemd from the
> filesystem is not technically defensible.

Do we have runtime systemd detection in all software linked against
libsystemd so it will work properly in absence of systemd? To rebuild
software without libsystemd is the only reliable way to ensure that
non-systemd code pathes are in use.

> This is a purely political fork, and it's
> politics that we should stay entirely clear of.

Steve, you much, much better than anybody else know that the only
political decision made it's a systemd as a default pid 1. Should I
remind how many votes were held until the result satisfying
pro-systemd party was achieved?

Bug#886351: Wide character in print at /usr/bin/gitlab-api-v4 line 106

[Jakub Wilk]

Package: libgitlab-api-v4-perl
Version: 0.02-1

$ gitlab-api-v4 --url=http://gitlab.com/api/v4 groups
Wide character in print at /usr/bin/gitlab-api-v4 line 106.


-- System Information:
Architecture: i386

Versions of packages libgitlab-api-v4-perl depends on:
ii  perl5.26.1-3
ii  libclass-method-modifiers-perl  2.12-1
ii  libconst-fast-perl  0.014-1
ii  libdata-serializer-perl 0.60-2
ii  liblog-any-adapter-screen-perl  0.13-1
ii  liblog-any-perl 1.704-1
ii  libmoo-perl 2.003004-1
ii  libnamespace-clean-perl 0.27-1
ii  librole-rest-client-perl0.22-1
ii  libstrictures-perl  2.03-1
ii  libtry-tiny-perl0.30-1
ii  libtype-tiny-perl   1.002001-1
ii  liburi-perl 1.72-2
ii  libyaml-perl1.24-1

--
Jakub Wilk

Bug#886350: gnucash: Can't do SEPA Transactions via online-banking

[mechtilde]

Package: gnucash
Version: 1:2.6.18-1
Severity: important

I try to fill out the dialog for SEPA transactions and get the following
message at each character I input:

"Your local bank account does not yet have the SEPA account information "
"stored. We are sorry, but in this development version one additional step is "
"necessary which has not yet been implemented directly in gnucash. Please "
"execute the command line program \"aqhbci-tool\" for your account, as "
"follows: aqhbci-tool4 getaccsepa -b %s -a %s"

I also execute the command line program  as described but no success.



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

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

Versions of packages gnucash depends on:
ii  gnucash-common 1:2.6.18-1
ii  guile-2.0  2.0.13+1-4+b1
ii  guile-2.0-libs 2.0.13+1-4+b1
ii  libaqbanking35 5.7.6beta-2
ii  libaqbanking35-plugins 5.7.6beta-2
ii  libc6  2.25-5
ii  libcairo2  1.15.8-3
ii  libcrypt-ssleay-perl   0.73.04-2+b2
ii  libdate-manip-perl 6.60-1
ii  libdbi10.9.0-5
ii  libfinance-quote-perl  1.47-1
ii  libgdk-pixbuf2.0-0 2.36.11-1
ii  libglib2.0-0   2.54.2-5
ii  libgnomecanvas2-0  2.30.3-3
ii  libgoffice-0.8-8   0.8.17-8
ii  libgtk2.0-02.24.31-5
ii  libgwengui-gtk2-0  4.18.0-1
ii  libgwenhywfar604.18.0-1
ii  libhtml-tableextract-perl  2.15-1
ii  libhtml-tree-perl  5.07-1
ii  libktoblzcheck1v5  1.49-4
ii  libofx71:0.9.12-1
ii  libpango-1.0-0 1.40.14-1
ii  libpangocairo-1.0-01.40.14-1
ii  libpython2.7   2.7.14-4
ii  libsecret-1-0  0.18.5-5
ii  libwebkitgtk-1.0-0 2.4.11-3
ii  libwww-perl6.31-1
ii  libx11-6   2:1.6.4-3
ii  libxml22.9.4+dfsg1-5.2
ii  libxslt1.1 1.1.29-5
ii  perl   5.26.1-3
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages gnucash recommends:
ii  dbus1.12.2-1
ii  dbus-x111.12.2-1
ii  gnucash-docs2.6.17-1
ii  python-gnucash  1:2.6.18-1
ii  yelp3.26.0-2

Versions of packages gnucash suggests:
ii  libdbd-mysql0.9.0-5
ii  libdbd-pgsql0.9.0-5
pn  libdbd-sqlite3  

-- no debconf information

Bug#886349: initramfs-tools: Missing vmd driver in hook-functions

[Mario.Limonciello]

Package: initramfs-tools
Version: 0.130
Severity: important

Dear Maintainer,

initramfs-tools is missing the Intel Volume Management Device (vmd.ko)
that was included in kernel 4.9 and later.

This sets up NVME disks in a separate PCI domain and is needed to access
them when the system is configured this way.  It must be available in
the initramfs to locate the root disk if configured as boot.

This can be fixed with the following trivial patch:
--- hook-functions.old  2018-01-04 13:58:03.256828153 -0500
+++ hook-functions  2017-10-13 15:09:26.0 -0400
@@ -583,7 +583,7 @@
block)
copy_modules_dir kernel/drivers/block
copy_modules_dir kernel/drivers/nvme
-   modules="$modules"
+   modules="$modules vmd"
;;
ubi)
modules="$modules deflate zlib lzo ubi ubifs"

Bug#886342: systemd-networkd: Unknown section 'Tap'. Ignoring.

[Wolfgang Walter]

Hello Michael,

thanks for your answer.

On Thursday, 4 January 2018 19:54:41 CET Michael Biebl wrote:
> Am 04.01.2018 um 19:30 schrieb Wolfgang Walter:
> > Package: systemd
> > Version: 236-2
> > 
> > Problem: since upgrading to 236-1 I get the following error:
> > 
> > systemd-networkd:[810]: /etc/systemd/network/tunnel.netdev: :5: Unknown
> > section 'Tap'. Ignoring.
> Please share the complete file.
> 
> Have you rebooted after upgrading to v236?

Yes. Several times. Indeed I just rebooted a couple of times since 18.12.2017 
different machines and they every time logged these things.

Example #1:
==
[NetDev]
Name=int
Kind=vlan

[VLAN]
Id=2567
==

Example #2:
==
[NetDev]
Name=mail
Kind=macvtap

[MACVTAP]
Mode=bridge
==

Example #3:
==
[NetDev]
Name=tunnel
Kind=tap

[Tap]
User=otunnel
Group=otunnel
==


Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts

Bug#886238: Please introduce official nosystemd build profile

[Johannes Schauer]

Quoting Hleb Valoshka (2018-01-04 19:35:28)
> On 1/3/18, Andrew Shadura  wrote:
> > Do we really need systemd-less builds? I'm not convinced this is something
> > relevant to Debian.
> [...]
> https://wiki.debian.org/BuildProfileSpec#Derivative_specific_profiles
> 
> At least some DD have a different POV.

The fact that I gave that example on that wiki page does *not* imply that I
would be in favour of build profiles being used for this purpose. I was merely
making an example of what could be technically possible. I gladly switch this
example for another.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#883573: Reevaluate libpam-systemd systemd-sysv dependency ordering (746578)

[Simon McVittie]

On Tue, 05 Dec 2017 at 12:26:43 +0100, Julian Andres Klode wrote:
> More importantly, several packages now require just systemd-sysv. If
> apt is told to install libpam-systemd and such a package in the same
> operation (especially in a chroot I'd say, since that's where neither
> shim nor sysv is installed), it may fail to resolve dependencies
> because it picks systemd-shim first and fails to replace it with
> systemd-sysv later.

Another fun failure mode is that if a dependency chain in a buildd
chroot involves libpam-systemd (the one I experienced today was GTK+ 3
pulling in dconf-service, which depends on a working D-Bus session bus,
and our recommended implementation of one of those depends on systemd),
you'll currently get systemd-shim. This depends on several orphaned or
undermaintained packages, one of which (libnih) uses glibc internal
symbols that make it uninstallable-until-binNMU'd with every new
version of glibc. Again, the current apt resolver commits to installing
systemd-shim and doesn't unwind far enough to be able to replace it with
systemd-sysv when systemd-shim turns out to be uninstallable.

As a general goal, it seems bad to have orphaned packages with no upstream
developer be in the critical path for building unrelated software.

smcv

Bug#886238: Please introduce official nosystemd build profile

[Hleb Valoshka]

On 1/3/18, Ansgar Burchardt  wrote:

> I think there is only one distribution which wants builds without
> libsystemd: the one that formed around MikeeUSA's call to action.

1) Even Wikipedia knows 43 distributions, much more can be found on
http://without-systemd.org/wiki/index.php/Main_Page#GNU.2FLinux_distributions,
some of them are still Debian based (but migrate to Devuan).

2) Please provide proofs for relationship between MikeeUSA and Devuan project.

> What does Debian gain from supporting a distribution whose developers
> are unfriendly to Debian developers (accusing Debian to "vandalize"
> open source by supporting systemd) and other people (calling a systemd
> developer a cancer)?

1) Proofs please. DDG & Google find only your words.

2) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069
After this I have switched to Devuan.

> Let me quote Devuan's IRC's infobot fact:

Of course this is lie and LP & his fans are very pleasant people.

Bug#886348: ITP: libmail-box-imap4-perl -- perl module for handling of IMAP4 folders as client

[Damyan Ivanov]

Package: wnpp
Owner: Damyan Ivanov 
Severity: wishlist
X-Debbugs-CC: debian-de...@lists.debian.org, debian-p...@lists.debian.org

* Package name: libmail-box-imap4-perl
  Version : 3.002
  Upstream Author : Mark Overmeer 
* URL : https://metacpan.org/release/Mail-Box-IMAP4
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : perl module for handling of IMAP4 folders as client

Mail::Box::IMAP4 maintains a folder which has its messages stored on a remote
server. The communication between the client application and the server is
implemented using the IMAP4 protocol.
~
This was part of libmail-box-perl before version 3.

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

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