Bug#886040: [Pkg-sugar-devel] Bug#886041: sugar: raising severity of gconf dependency bug

[James Cameron]

Upstream has begun patch review for moving away from gconf.

The patches are in pull requests linked from a GitHub project;

https://github.com/orgs/sugarlabs/projects/2

-- 
James Cameron
http://quozl.netrek.org/

Bug#894181: rakarrack: handling of cpu extensions

[Paul Wise]

On Tue, 27 Mar 2018 06:49:22 +0200 Helmut Grohne wrote:

> From a Debian pov, this whole autodetection should be removed and
> replaced by a concious maintainer choice documented in debian/rules
> (as is done with sse for i386 already).

The correct thing to do would be to detect the available instructions
at runtime and then use the right code based on that. This can be
achieved using GCC FMV or glibc hwcaps or manual detection.

https://gcc.gnu.org/wiki/FunctionMultiVersioning
https://lwn.net/Articles/691932/
https://manpages.debian.org/stretch/manpages/ld.so.8.en.html#Hardware_capabilities

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#894183: libexif: outdated Homepage, moved to github

[Paul Wise]

Source: libexif
Severity: minor

libexif has an outdated Homepage field, it moved to github:

https://libexif.github.io/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#894182: O: calife

[Christian Perrier]

Package: wnpp
Severity: normal

I just orphaned this package, in preparation of /me slowly decreasing
my activity in Debian.

Bug#882934: Crash debugging

[Dima Kogan]

Joe  writes:

> On Fri, 16 Mar 2018 16:42:43 -0700
> Dima Kogan  wrote:
>
>> Can you try to run pcb without hardware acceleration? You can do this
>> with
>>
>>  LIBGL_ALWAYS_SOFTWARE=true pcb-gtk
>
> Yes, that fixes it. A quick test suggests it is running OK.
>
> OK, it does look like the graphics driver, then. I don't play games, so
> I've never worried about it, and it looks like I'm using the
> xserver-xorg-video-radeon driver. firmware-amd-graphics is installed.
>
> Should I try getting hold of the AMD binary driver? It's onboard
> graphics on a Gigabyte MB, about seven years old.

That's interesting; glad we narrowed down the problem. I don't have any
ATI hardware, so can't reproduce this. I'm assuming no other
applications crash like this? I'm wondering if pcb is doing something
different from other programs.

Can I please get the versions of your graphics driver packages (ones you
mentioned above), and the hardware IDs:

  lspci -nn | grep VGA

Not entirely sure what I can do with that, but it'd be good to have.
I'll try to chase down some ATI hardware. Otherwise you'll be running
experiments for me for a long time.

Bug#894180: Fwd: Bug#894180: Acknowledgement (util-linux: Possible still present Bug on "Debian 7/Wheezy" w/ dmesg command on a "SE-208DB/TSBS" External ODD)

[Luis Henrique]

Dear Maintainer


Was missing the rest of the files (I'm not experienced Reporting Bugs for
Debian Project, this is my first one):

The reportbug gtk2 was working correctly at the moment of the upload of
attachments.

Follows on this e-mail the another files that I wanted to share with the
Developers here


*Note: *Forget the duplicated upload, this was an mistake mine (the
Graphical Interface of "*reportbug*" was not clear about what was being
uploaded).


Thanks.


Best Regards.

Luis, Brazil.
3.2.0-4-686-pae
00:00.0 RAM memory [0500]: NVIDIA Corporation MCP61 Host Bridge [10de:03e2] 
(rev a1)
Subsystem: ASRock Incorporation Device [1849:03e2]
Flags: bus master, 66MHz, fast devsel, latency 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Capabilities: [dc] HyperTransport: MSI Mapping Enable+ Fixed-

00:01.0 ISA bridge [0601]: NVIDIA Corporation MCP61 LPC Bridge [10de:03e1] (rev 
a2)
Subsystem: ASRock Incorporation Device [1849:03e1]
Flags: bus master, 66MHz, fast devsel, latency 0
I/O ports at 0900 [size=256]

00:01.1 SMBus [0c05]: NVIDIA Corporation MCP61 SMBus [10de:03eb] (rev a2)
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03eb]
Flags: 66MHz, fast devsel, IRQ 11
I/O ports at 0e00 [size=64]
I/O ports at 0600 [size=64]
I/O ports at 0700 [size=64]
Capabilities: [44] Power Management version 2
Kernel driver in use: nForce2_smbus

00:01.2 RAM memory [0500]: NVIDIA Corporation MCP61 Memory Controller 
[10de:03f5] (rev a2)
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03eb]
Flags: 66MHz, fast devsel

00:02.0 USB controller [0c03]: NVIDIA Corporation MCP61 USB 1.1 Controller 
[10de:03f1] (rev a3) (prog-if 10 [OHCI])
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03f1]
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 23
Memory at efeff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Kernel driver in use: ohci_hcd

00:02.1 USB controller [0c03]: NVIDIA Corporation MCP61 USB 2.0 Controller 
[10de:03f2] (rev a3) (prog-if 20 [EHCI])
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03f2]
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at efefec00 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port: BAR=1 offset=0098
Capabilities: [80] Power Management version 2
Kernel driver in use: ehci_hcd

00:04.0 PCI bridge [0604]: NVIDIA Corporation MCP61 PCI bridge [10de:03f3] (rev 
a1) (prog-if 01 [Subtractive decode])
Flags: bus master, 66MHz, fast devsel, latency 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: e000-efff [size=4K]
Memory behind bridge: eff0-efff [size=1M]
Prefetchable memory behind bridge: None
Capabilities: [b8] Subsystem: ASRock Incorporation 939NF6G-VSTA Board 
[1849:03f3]
Capabilities: [8c] HyperTransport: MSI Mapping Enable- Fixed-

00:05.0 Audio device [0403]: NVIDIA Corporation MCP61 High Definition Audio 
[10de:03f0] (rev a2)
Subsystem: ASRock Incorporation Device [1849:0397]
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 22
Memory at efef8000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Capabilities: [50] MSI: Enable- Count=1/1 Maskable+ 64bit+
Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: snd_hda_intel

00:06.0 IDE interface [0101]: NVIDIA Corporation MCP61 IDE [10de:03ec] (rev a2) 
(prog-if 8a [Master SecP PriP])
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03ec]
Flags: bus master, 66MHz, fast devsel, latency 0
[virtual] Memory at 01f0 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 03f0 (type 3, non-prefetchable)
[virtual] Memory at 0170 (32-bit, non-prefetchable) [size=8]
[virtual] Memory at 0370 (type 3, non-prefetchable)
I/O ports at ffa0 [size=16]
Capabilities: [44] Power Management version 2
Kernel driver in use: pata_amd

00:07.0 Bridge [0680]: NVIDIA Corporation MCP61 Ethernet [10de:03ef] (rev a2)
Subsystem: ASRock Incorporation 939NF6G-VSTA Board [1849:03ef]
Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 43
Memory at efefd000 (32-bit, non-prefetchable) [size=4K]
I/O ports at d080 [size=8]
Capabilities: [44] Power Management version 2
Capabilities: [50] MSI: Enable+ Count=1/8 Maskable+ 64bit+
Capabilities: [6c] HyperTransport: MSI Mapping Enable- Fixed+
Kernel driver in use: forcedeth

00:08.0 IDE interface [0101]: NVIDIA Corporation MCP61 SATA Controller 
[10de:03f6] (rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: 

Bug#893936: gitlab: pkg_resources.DistributionNotFound: The 'python-gitlab==1.3.0' distribution was not found

[Paul Wise]

On Mon, 2018-03-26 at 23:14 -0400, Jeremy Bicha wrote:

> So you just want this package to Depend on python3-gitlab (>= 1:1.3.0) ?

That doesn't correspond to what the code requires:

$ grep __requires__ /usr/bin/gitlab
__requires__ = 'python-gitlab==1.3.0'

This would be the correct dependency:

Depends: python3-gitlab (= 1:1.3.0-1)

Or this for slightly more flexibility:

Depends: python3-gitlab (>= 1:1.3.0~), python3-gitlab (<< 1:1.3.1~)

Alternatively the upstream requirements could be relaxed.

> I mean users should install updates and shouldn't keep the older
> version around, which makes me think you might be overstating the
> severity of this bug, but ok…

Agreed for the first part. The severity is valid if you take into
account the upstream version requirements and future releases.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#894181: rakarrack: handling of cpu extensions

[Helmut Grohne]

Source: rakarrack
Version: 0.6.1-4
Severity: wishlist
User: helm...@debian.org
Usertags: rebootstrap

I looked into cross building rakarrack and found that it would pass
-msse2 to an arm compiler. That's bad. So while it might not be useful
to cross build rakarrack, I think it still is useful to reconsider the
handling of cpu extensions in rakarrack.

One thing to note is that it enables altivec on powerpc, which is above
the port base line. I suggest adding "altivec-support [any-powerpc]" to
rakarrack's Depends to at least document this behaviour.

I think this build time detection is problematic on its own, because the
behaviour of the package depends on the builder's capabilities rendering
the package unreproducible. From a Debian pov, this whole autodetection
should be removed and replaced by a concious maintainer choice
documented in debian/rules (as is done with sse for i386 already).

Incidentally, that would not only fix reproducibility, but also cross
compilation.

Helmut

Bug#894180: util-linux: Possible still present Bug on "Debian 7/Wheezy" w/ dmesg command on a "SE-208DB/TSBS" External ODD

[Luis Henrique]

Package: util-linux
Version: 2.20.1-5.3
Severity: minor

Dear Maintainer,

Hi the designated Security Team of Debian-LTS and Debian Developers!

  The Bug that I'm here referring, I know that existed since I have discovered
the same, near the release of the latest point release "7.11" in middle of
2016. Here goes the problem:

[  107.499489] Initializing USB Mass Storage driver...
[  107.499661] scsi6 : usb-storage 1-4:1.0
[  107.499834] usbcore: registered new interface driver usb-storage
[  107.499840] USB Mass Storage support registered.
[  108.498825] scsi 6:0:0:0: CD-ROMTSSTcorp CDDVDW SE-208DB  MF00
PQ: 0 ANSI: 0
[  108.532433] sr1: scsi3-mmc drive: 62x/24x writer dvd-ram cd/rw xa/form2 cdda
tray
[  108.58] sr 6:0:0:0: Attached scsi CD-ROM sr1
[  108.534611] sr 6:0:0:0: Attached scsi generic sg2 type 5
[  118.728693] ISO 9660 Extensions: Microsoft Joliet Level 3
[  118.750699] ISOFS: changing to secondary root

/*[  107.284078] usb 1-4: new high-speed USB device number 4 using ehci_hcd
[  107.421154] usb 1-4: New USB device found, idVendor=0e8d, idProduct=1806
[  107.421165] usb 1-4: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[  107.421172] usb 1-4: Product: MT1887
[  107.421177] usb 1-4: Manufacturer: MediaTek Inc
[  107.421182] usb 1-4: SerialNumber: R8X76YAF301KKV */

Follows here the original log from an installation of Debian 7.7 with the
filename:

( file: dmesg_(SE-208DB_-_TSBS).txt )

It's impossible to have a Read Speed Rate of "62X".

The version of the dmesg that I've for now on my Debian 7 32-bits "Wheezy"
installation is:

$ dmesg --version
dmesg de util-linux 2.20.1

The Debian 8 codename "Jessie" and the current stable "Stretch" (latest current
stable in 2018) doesn't both have this Bug in any form.

Any other needed information from me to provide here, for the Developers be
able to do a better handling of this possibly that is still present Bug on
Debian 7 (only Debian 7 GNU / Linux I've seen this problem)?

Note: The Ubuntu Distribution, in the last version that carried the Kernel
3.2-0.x, the version "12.04.1", doesn't have the same bug.

Here goes the relevant part of the log output for the Ubuntu version "12.04.1"
(codename "Precise Pangolin"), with the same Kernel as the Debian 7:

[4.480600] scsi 0:0:0:0: CD-ROMTSSTcorp CDDVDW SE-208DB  MF00
PQ: 0 ANSI: 0
[4.489968] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda
tray
[4.489972] cdrom: Uniform CD-ROM driver Revision: 3.20
[4.490086] sr 0:0:0:0: Attached scsi CD-ROM sr0
[4.490155] sr 0:0:0:0: Attached scsi generic sg1 type 5

, and comes together of the same, the complete log made on this mentioned
Ubuntu release, and which that doesn't contains that issue.

(file: dmesg_test.txt )

Threre many other variants of "TSST Corp. SE-208 (XX)" External Optical Disc
Drives (ODDs) Manufactured and sold on the Market. Here is the list of what I
found searching on the Internet (maybe the variants also have this clear Bug):


• SE-208DB/CHBS
*( Color Black -- Only (Black) - Chinese Model )

• SE-208GB/RSBS
*( Black )

• SE-208DB/BRBS
*( Black (Brazilian Model) )

• SE-208BW-BRDS
*( Black )

• SE-208AB/BRBSA
*( Black (Brazilian Model) )

• SE-208AB/TSBS
*( Black (Chinese Model (?) )

• SE-208GB/IDBS
*( Black )

• SE-208GB/RSWD
*( White )

• SE-208GB/RSBD
*( Black )

• SE-208GB/RSLD
*( Blue )

• SE-208AB/TSWS
*( Glossy White )

• SE-208AB/TSLS
*( Blue )

• SE-208DB/TSLS
*( Blue )

• SE-208DB/TSRS
*( Red )

• SE-208DB/TSWS
*( White )

• SE-208GB/RSRD
*( Red )

 Comes here together the original file with the Report, and the websites where
I encountered the reference of the Models.

Please, Developers, fix this issue on Wheezy (the Archived versions, I've not
tested yet, but don't matter here, since are not more supportted, as Wheezy
(Ubuntu 11.04, the last based on Debian Lenny, also does not have this Bug) ),
before the Debian 7 Wheezy be archived, and when the same still have the
possibility of be still fixed.


I'm sorry if I decided to make a Report of this Bug too late.. but last year I
don't was very well for to do it until December.

Question: Can Debian "borrow" the Kernel compilation for this Driver from
Ubuntu? I've a register on Launchpad.net to ask this for the Ubuntu developers,
if needed. I don't knows how the Developers will handle this Bug, I'm only
suggestioning a hypothetical possible way, if is this really a valid
possibility, indeed

Also follows a considerable portion of my Hardware Configuration (a Motherboard
ASRock N68-S3 FX and with and AMD Processor Sempron Socket 145). If requested,
I'll do a further and deep Report of my Hardware Configuration.


Best Regards.

Luis, Brazil.



-- System Information:
Debian Release: 7.7
  APT prefers oldoldstable-updates
  APT policy: (500, 'oldoldstable-updates'), (500, 'oldoldstable-proposed-
updates'), (500, 'oldoldstable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)

Bug#880771: libdwarf/dwarfdump cross compile

[Helmut Grohne]

Hi David,

On Mon, Mar 26, 2018 at 01:28:53PM -0700, David Anderson wrote:
> I figured out a simple way to cross-build while
> completely separating build-time objects from target
> objects. Using AC_PATH_PROG as Helmut suggested.
> 
> Nothing complicated about it. Simple 'make'.

Cool. Before we continue, could you do a brief terminology check? Both
autotols and Debian (dpkg) use GNU terminology[1] for build/host/target.
This notably differs from mozilla terminology and tends to cause
confusion. Please stick with GNU terminology, because it is the one that
autotools use and it is more expressive than mozilla terminology.

> Tested with --host=gcc-arm-linux-gnueabihf

This is not a supported host architecture for Debian. It's the cross
compiler package name. The value to pass to --host should be just
arm-linux-gnueabihf.

> which generates libdwarf as arm fine, but
> the dwarfdump final link fails because
> AC_TRY_COMPILE looks for -lz and looks
> in the build machine location, not the cross area.

If AC_TRY_COMPILE checks build aspects rather than host aspects,
something is seriously wrong. You likely need to check for a bad CC
variable or like that in config.status.

> Because the cross area does not have -lz,
> while the build environment does I need
> to find out at build time about
> that target library.

If you need a libz for arm, you need to install it of course. You can
install regular arm packages on your amd64 machine. For doing so, you
enable armhf as an foreign architecture (dpkg --add-architecture armhf),
update your package cache and install zlib1g-dev:armhf.

> I'm not sure how to fix this part, cannot
> find anything on the web but words admitting it is
> a problem.

If all else fails, we can simply wait for Fabian to upload your changes
(even if that takes months). When doing so he'll close this bug, which
triggers a test rebuild on my cross buildd (and has done so previously,
the process works!) and will likely result in me sending patches again.

I have still plenty (like 1) packages to fix. ;) Thus I aim for
throughput, not low latency.

> Any suggestions to detect -lz in the target
> libraries?

There are too many strange aspects above to say something useful. Maybe
I can say more after addressing those points.

Helmut

[1] https://gcc.gnu.org/onlinedocs/gccint/Configure-Terms.html

Bug#893024: Manual entry into UI date widget is broken

[Jeff]

On 26/03/18 21:53, martin f krafft wrote:
> 2.0.2 suffers from a different, but probably related problem:
> entering 2018-03-15 makes the date then appear as 0015-00-00.

Grrr. Yes. Sorry for being stupid. Fixed in 2.0.3.



signature.asc
Description: OpenPGP digital signature

Bug#894179: exiv2: CVE-2018-8977

[Salvatore Bonaccorso]

Source: exiv2
Version: 0.26-1
Severity: grave
Tags: security upstream
Justification: user security hole
Forwarded: https://github.com/Exiv2/exiv2/issues/247

Hi,

The following vulnerability was published for exiv2, which affects in
Debian only the exerimental version.

CVE-2018-8977[0]:
| In Exiv2 0.26, the Exiv2::Internal::printCsLens function in
| canonmn_int.cpp allows remote attackers to cause a denial of service
| (invalid memory access) via a crafted file.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-8977
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8977
[1] https://github.com/Exiv2/exiv2/issues/247

Regards,
Salvatore

Bug#894178: default-d-compiler is missing the epoch on the gdc dependency

[Matthias Klose]

Package: default-d-compiler
Version: 0.5

default-d-compiler is missing the epoch on the gdc dependency.

$ apt-cache show gdc|grep Version
Version: 4:8-20180321-1

Bug#894177: python-gitlab: Please drop the Python2 package

[Jeremy Bicha]

Package: python-gitlab
Version: 1:1.3.0-1
Severity: important

Please drop the python-gitlab package. It is the python2 version and
it's not needed by the gitlab-cli package or anything else in Debian.
It is better for developers and users to get used to the python3
packages since python2 is obsolete and will eventually be removed from
Debian.

Thanks,
Jeremy Bicha

Bug#893936: gitlab: pkg_resources.DistributionNotFound: The 'python-gitlab==1.3.0' distribution was not found

[Jeremy Bicha]

So you just want this package to Depend on python3-gitlab (>= 1:1.3.0) ?

I mean users should install updates and shouldn't keep the older
version around, which makes me think you might be overstating the
severity of this bug, but ok…

Thanks,
Jeremy Bicha

Bug#894176: gmtp: Don't Build-Depend on gconf

[Jeremy Bicha]

Source: gmtp
Version: 1.3.10-1
Severity: serious
User: pkg-gnome-maintain...@lists.alioth.debian.org
Usertags: oldlibs gconf
Tags: sid buster

Your package build-depends on libgconf2-dev, but gconf will be removed from 
Debian soon.

gconf's last release was about 5 years ago. It has been replaced by
gsettings (provided in Debian by source glib2.0 )

I think the configure.ac script is broken. Since it provides gsettings schemas 
for the gtk3 build and doesn't install the gconf schemas, it should be able to 
build without gconf present.

References
--
https://developer.gnome.org/gio/stable/ch34.html
https://developer.gnome.org/gio/stable/GSettings.html
https://lists.debian.org/debian-devel/2018/02/msg00169.html

On behalf of the Debian GNOME team,
Jeremy Bicha

Bug#894072: gitlab: postinst fails with "/var/lib/gitlab/yarn/node_modules/.bin/yarn: not found"

[Dmitry Smirnov]

Hi Praveen,

> This bug appears from uploading from 9.5.4 installation. If you do a
> purge && reinstall, it solves the problem.

But I need to upgrade from 9.5.4 and "purge" is destructive...
I don't want to risk losing configs, projects and what not.

Please take care of upgrade path from 9.5. Purge should not be necessary.

I tried "cd /var/lib/gitlab/yarn && npm install yarn" (as gitlab user)
but it did not work:


npm WARN package.json compression-webpack-plugin@0.3.2 No license field.
npm WARN package.json dropzone@4.3.0 No license field.
npm WARN package.json jszip-utils@0.0.2 license should be a valid SPDX
license expression
npm WARN package.json select2@3.5.2-browserify No license field.
yarn@1.5.1 ../node_modules/yarn


After that the following folders remain empty

  /var/lib/gitlab/yarn

and attempt to reconfigure GitLab fails exactly the same.

What did help is the following command:

  cd /var/lib/gitlab/yarn && npm install --prefix=. yarn

But you may have other ideas how to fix the problem properly...

Regards,
  Dmitry.

Bug#894175: ddccontrol: Please drop gksu dependency on Ubuntu

[Jeremy Bicha]

Source: ddccontrol
Version: 0.4.3-1
Severity: important

Your 0.4.3-1 upload accidentally dropped my 0.4.2-11 changes. In
particular this change is needed by Ubuntu since Ubuntu may be trying
to drop gksu for 18.04 LTS.

  "Drop Ubuntu-specific gksu dependency and patch.
   gksu will be removed from Debian and Ubuntu soon."

Thanks,
Jeremy Bicha

Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1

[Paul Wise]

On Tue, Mar 27, 2018 at 5:19 AM, Alexis Murzeau wrote:

> https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.11.0+dfsg-1~bpo9+1.dsc

Unfortunately the package FTBFS in my stretch pbuilder, one test
failure in tests/test_plugins.py, it looks like it tries to load the
plugins in ASCII encoding but some of them are UTF-8 encoding. To
reproduce, set LC_ALL=C and LANG=C and rebuild. The C.UTF-8 locale
seems to be a workaround, but I think the code should be changed to
always load in UTF-8 encoding.

Also, when I build twice in a row, I get a different failure:

dpkg-source: info: local changes detected, the modified files are:
 streamlink-0.11.0+dfsg/.cache/v/cache/lastfailed
dpkg-source: error: aborting due to unexpected upstream changes, see
/tmp/streamlink_0.11.0+dfsg-1~bpo9+1.diff.TRf3Wk

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#894174: gcalcli: --nodeclined error

[Brian May]

Package: gcalcli
Version: 3.4.0-1
Severity: normal

This only happens with --nodeclined:

Traceback (most recent call last):
  File "/usr/bin/gcalcli", line 2649, in 
BowChickaWowWow()
  File "/usr/bin/gcalcli", line 2499, in BowChickaWowWow
gcal.AgendaQuery()
  File "/usr/bin/gcalcli", line 1737, in AgendaQuery
self._IterateEvents(start, eventList, yearDate=False)
  File "/usr/bin/gcalcli", line 1556, in _IterateEvents
attendee = [a for a in event['attendees'] if a['email'] == 
event['gcalcli_cal']['id']][0]
IndexError: list index out of range

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

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

Versions of packages gcalcli depends on:
ii  python2.7.13-2
ii  python-dateutil   2.5.3-2
ii  python-gflags 1.5.1-2
ii  python-googleapi  1.5.5-1

Versions of packages gcalcli recommends:
ii  gxmessage 3.4.3-1
ii  python-parsedatetime  2.1-3
ii  python-simplejson 3.10.0-1
ii  python-vobject0.9.3-3

gcalcli suggests no packages.

-- no debconf information

Bug#893980: www.debian.org: Many mirrors have no or untrusted HTTPS certificates

[Paul Wise]

On Mon, Mar 26, 2018 at 10:11 PM, Rhonda D'Vine wrote:

>  Right, but DNS for the primary ones, and pointing them towards a server
> that isn't under their control would mean that they'd have to carry a
> *.debian.org wildcard certificate.  Which won't happen for non-DSA
> operated infrastructure.

Martin was talking about tracking https availability for the secondary
mirrors, which don't have an associated ftp.*.debian.org DNS record.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#893759: variety: launching variety gives quite a few python 2.7 warnings

[James Lu]

Hello,

This actually looks like three different bugs.

The first traceback (relating to
/usr/share/images/desktop-base/desktop-background) seems to involve
misdetecting image file formats somewhere. To help debug this further,
could you reply with the output of:

ls /etc/alternatives/desktop-background -lah

For the second error (cannot identify image file), I suspect a corrupt
image file. Does the file it mentions
(/home/shirish/.config/variety/Downloaded/flickr_user_www_flickr_com_photos_peter_levi__user_id_93647178_N00_/7527884976_7d72041417_o.jpg)
seem like a working JPEG? If not, try deleting it and see if the issue
disappears.

The "unary operator expected" issue is a mistake on my part and will be
fixed in the next upstream release (0.6.7)

Hope this helps,
James




signature.asc
Description: OpenPGP digital signature

Bug#893051: Pending fixes for bugs in the prometheus-mysqld-exporter package

[pkg-go-maintainers]

tag 893051 + pending
thanks

Some bugs in the prometheus-mysqld-exporter package are closed in
revision 605c06a7c284dc1858d1717678f292a89febd86c in branch
'debian/sid' by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus-mysqld-exporter.git/commit/?id=605c06a

Commit message:

Fix FTBFS in 32bits arches. Closes: #893051

Bug#894172: python-virtualenv-clone: Conflicts with virtualenv-clone

[Alok Singh]

Package: python-virtualenv-clone
Version: 0.3.0-1.1
Severity: normal

Dear Maintainer,

While dist-upgrading, virtualenv-clone pulled in python-virtualenv-clone
and the following happened:

Preparing to unpack .../39-python-virtualenv-clone_0.3.0-1.1_all.deb ...
Unpacking python-virtualenv-clone (0.3.0-1.1) ...
dpkg: error processing archive
/tmp/apt-dpkg-install-YAqdAR/39-python-virtualenv-clone_0.3.0-1.1_all.deb
(--unpack):
 trying to overwrite '/usr/bin/virtualenv-clone', which is also in package
virtualenv-clone 0.2.5-1

Purging virtualenv-clone (and virtualenvwrapper which depends on it)
allowed me to continue.

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

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

Versions of packages python-virtualenv-clone depends on:
ii  python  2.7.14-4

python-virtualenv-clone recommends no packages.

python-virtualenv-clone suggests no packages.

-- no debconf information

-- 
Alok

Bug#894067: Patch to fix problem

[Peter.Chubb]

Turns out there are two issues:
 1. A snapshot isn't activated automatically --- one needs to supply
the -K flag to lvcreate to have the snapshot usable immediately.
 2. The kernel really doesn't like not having unique UUIDs when
mounting filesystems, so the snapshot needs to have its UUID
 reset.

This patch fixes both these issues, at least for ext[234] and XFS.
---
 src/lxc/storage/lvm.c |   24 ++--
 1 file changed, 22 insertions(+), 2 deletions(-)

Index: lxc-2.0.9/src/lxc/storage/lvm.c
===
--- lxc-2.0.9.orig/src/lxc/storage/lvm.c
+++ lxc-2.0.9/src/lxc/storage/lvm.c
@@ -267,9 +267,9 @@ int lvm_snapshot(const char *orig, const
 
(void)setenv("LVM_SUPPRESS_FD_WARNINGS", "1", 1);
if (!ret) {
-   ret = execlp("lvcreate", "lvcreate", "-s", "-L", sz, "-n", lv, 
orig, (char *)NULL);
+   ret = execlp("lvcreate", "lvcreate", "-K", "-s", "-L", sz, 
"-n", lv, orig, (char *)NULL);
} else {
-   ret = execlp("lvcreate", "lvcreate", "-s", "-n", lv, orig, 
(char *)NULL);
+   ret = execlp("lvcreate", "lvcreate", "-K", "-s", "-n", lv, 
orig, (char *)NULL);
}
 
free(pathdup);
@@ -347,6 +347,26 @@ int lvm_clonepaths(struct lxc_storage *o
ERROR("could not create %s snapshot of %s", new->src, 
orig->src);
return -1;
}
+   if (!strcmp(fstype, "xfs") || !strncmp(fstype, "ext", 3)) {
+   int kidpid = fork();
+   switch (kidpid) {
+   case 0:
+   if (fstype[0] == 'x')
+   execlp("xfs_admin", "xfs_admin", "-U", 
"generate", new->src, (char *)NULL);
+   else
+   execlp("tune2fs", "tune2fs", "-U", 
"random", new->src, (char *)NULL);
+   SYSERROR("execlp");
+   exit(EXIT_FAILURE);
+   ;;
+   case -1:
+   SYSERROR("fork");
+   return -1;
+   ;;
+   default:
+   wait_for_pid(kidpid);
+   ;;
+   }
+   }
} else {
if (do_lvm_create(new->src, size, 
lxc_global_config_value("lxc.bdev.lvm.thin_pool")) < 0) {
ERROR("Error creating new lvm blockdev");



-- 
Dr Peter Chubb Tel: +61 2 9490 5852  http://ts.data61.csiro.au/
Trustworthy Systems Group   Data61 (formerly NICTA)

Bug#894171: barbican-common: Configuring barbican-common fails while running /var/lib/dpkg/info/barbican-common.config

[aradian]

Package: barbican-common
Version: 1:6.0.0-1
Severity: normal

Dear Maintainer,

While installing packages barbican-api barbican-keystone-listener 
barbican-worker, configuration of barbican-common fails with message 
("DEBUG" line added by me):



PKG-Openstack now calling: dbc_go barbican-common configure
Determining localhost credentials from /etc/mysql/debian.cnf: succeeded.
=== DEBUG ===  pkgos_add_directive( 
/etc/barbican/barbican-api-paste.ini, keystone_authtoken, password =, # 
Password for auth. )
/var/lib/dpkg/info/barbican-common.config: 84: 
/var/lib/dpkg/info/barbican-common.config: arithmetic expression: 
expecting primary

: "70 - "
dpkg: error processing package barbican-common (--configure):
 installed barbican-common package post-installation script subprocess 
returned error exit status 2

dpkg: dependency problems prevent configuration of barbican-worker:
 barbican-worker depends on barbican-common (= 1:6.0.0-1); however:
  Package barbican-common is not configured yet.


Seems like it's looking for section "keystone_authtoken" in 
barbican-api-paste.ini, which doesn't exist.



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

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages barbican-common depends on:
ii  adduser3.117
ii  dbconfig-common2.0.9
ii  debconf [debconf-2.0]  1.5.66
ii  python33.6.4-1
ii  python3-barbican   1:6.0.0-1

barbican-common recommends no packages.

barbican-common suggests no packages.

-- debconf information:
* barbican/configure_ksat: true
  barbican-common/remote/port:
  barbican-common/db/basepath: /var/lib/barbican
  barbican-common/dbconfig-remove: true
  barbican-common/pgsql/admin-user: postgres
* barbican/ksat-admin-project-name: default
  barbican-common/pgsql/changeconf: false
  barbican-common/install-error: abort
  barbican-common/mysql/method: Unix socket
* barbican/rabbit-host: 192.168.2.90
* barbican-common/mysql/admin-user: root
* barbican/ksat-service-username: barbican
  barbican-common/internal/skip-preseed: false
  barbican-common/pgsql/authmethod-user: password
  barbican-common/passwords-do-not-match:
  barbican-common/dbconfig-upgrade: true
* barbican/ksat-admin-username: admin
  barbican-common/pgsql/method: TCP/IP
  barbican-common/db/dbname: barbicandb
* barbican/ksat-region: RegionOne
* barbican/rabbit-userid: openstack
  barbican-common/pgsql/authmethod-admin: ident
* barbican-common/dbconfig-install: true
  barbican-common/dbconfig-reinstall: false
* barbican/ksat-create-service-user: true
  barbican-common/pgsql/manualconf:
  barbican-common/purge: false
  barbican-common/internal/reconfiguring: false
  barbican-common/missing-db-package-error: abort
* barbican/configure_db: true
  barbican-common/upgrade-error: abort
* barbican-common/database-type: mysql
* barbican/ksat-service-project-name: service
  barbican-common/db/app-user: barbican-common@localhost
* barbican/configure_rabbit: true
* barbican/ksat-admin-url: http://192.168.2.90:35357
  barbican-common/upgrade-backup: true
  barbican-common/remote/newhost:
  barbican-common/remote/host: localhost
  barbican-common/remove-error: abort
* barbican/ksat-public-url: http://192.168.2.90:5000
  barbican-common/pgsql/no-empty-passwords:

Bug#892057: Fwd: Re: TS-x09 fails to boot when obtaining MAC

[Andrew Lunn]

On Tue, Mar 27, 2018 at 12:50:04AM +0200, Martin Michlmayr wrote:
> The fix is in Linus' tree since v.16-rc5:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=13a55372b64e00e564a08d785ca87bd9d454ba30
> 
> I don't see it in 4.9 stable or the stable queue.  Will Greg pick it
> up automatically because of the Fixes: info or do we have to let him
> know?

Hi Dave

This is one of your own patches. Please could you add it to stable, if
it is not already.

Thanks
Andrew

Bug#894170: apt: man apt_preferences: please document per-package pins

[Adam Borowski]

Package: apt
Version: 1.6~beta1
Severity: wishlist


Hi!
It would be nice if you could document, preferably by an example, how to
affect _all_ possible copies of a package, no matter where they come from.

This is useful in at least two cases:
* someone wants to prevent a package from being installed despite notorious
  Recommends (bash-completion, a *cough* certain init implementation, etc)
* someone wants a particular _architecture_ kept from being installed

I just had the latter case: x32 doesn't ship its kernel but uses one from
amd64 (similar to i386, except that there's no "native" kernel at all), and
the kernel package keeps insisting on replacing native irqbalance, apparmor
and so on with :amd64 versions.

Too bad, the documentation is lacking (or perhaps it's me not reading it
well enough), and I wasted quite a few minutes looking how to produce such a
rule.  Turns out, a missing Pin: line doesn't work, neither does "Pin: *".
You need to pick a dummy but valid field, and asterisk that.
Ie, "Pin: origin *" or "Pin: release *".

There's also no mention that you can limit the rule to a specific arch, but
fortunately my guess was correct.

Thus. please include one of the following examples:

.
Package: irqbalance:amd64
Pin: origin *
Pin-Priority: -1
`
which blocks irqbalance:amd64 but not irqbalance:x32, or

.
Package: libc6:amd64
Pin: origin *
Pin-Priority: -1
`
which is a big hammer that blocks all regular foreign userland code,
allowing the kernel and static stuff.


Meow!
-- Package-specific info:

-- /etc/apt/preferences.d/no-amd64 --

Package: libc6:amd64
Pin: origin *
Pin-Priority: -1

-- /etc/apt/sources.list --

#deb http://apt.angband.pl:3142/ftp.debian-x32.org/debian/ jessie main contrib 
non-free
#deb-src http://apt.angband.pl:3142/ftp.pl.debian.org/debian/ jessie main 
contrib non-free

# jessie-updates, previously known as 'volatile'
#deb http://apt.angband.pl:3142/ftp.debian-x32.org/debian/ jessie-updates main 
contrib non-free
#deb-src http://apt.angband.pl:3142/ftp.debian-x32.org/debian/ jessie-updates 
main contrib non-free

# jessie-backports, previously on backports.debian.org
#deb http://apt.angband.pl:3142/ftp.debian-x32.org/debian/ jessie-backports 
main contrib non-free
#deb-src http://apt.angband.pl:3142/ftp.debian-x32.org/debian/ jessie-backports 
main contrib non-free

deb http://angband.pl/debian sid main

deb [arch=amd64] http://apt.angband.pl:3142/debian unstable main contrib 
non-free
deb [arch=x32] http://apt.angband.pl:3142/ftp.debian-ports.org/debian unstable 
main
deb [arch=x32] http://apt.angband.pl:3142/ftp.debian-ports.org/debian 
unreleased main
deb-src http://apt.angband.pl:3142/debian unstable main contrib non-free

-- (no /etc/apt/sources.list.d/* present) --


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

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

Versions of packages apt depends on:
ii  adduser 3.117
ii  debian-archive-keyring  2017.7
ii  gpgv2.2.5-1
ii  libapt-pkg5.0   1.6~beta1
ii  libc6   2.27-2
ii  libgcc1 1:8-20180321-1
ii  libgnutls30 3.5.18-1
ii  libseccomp2 2.3.1-2.1
ii  libstdc++6  8-20180321-1

Versions of packages apt recommends:
ii  ca-certificates  20170717

Versions of packages apt suggests:
pn  apt-doc 
ii  aptitude0.8.10-6
ii  dpkg-dev1.19.0.5
ii  gnupg   2.2.5-1
ii  powermgmt-base  1.33

-- no debconf information

Bug#858327: ITP: python-face-recognition -- Recognize and manipulate faces from Python

[Hugo Lefeuvre]

Hi,

Package is ready to upload[0], but there are still some blockers at the moment:
 - face_recognition_models[1] needs to be packaged (planning to do it in the
   next days)
 - dlib[2] is not up to date and version > 19.3.0 is required (planning to get
   it updated some way)

Cheers,
 Hugo

[0] https://salsa.debian.org/hle/python-face-recognition
[1] https://github.com/ageitgey/face_recognition_models
[2] https://packages.debian.org/source/sid/misc/dlib

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


signature.asc
Description: PGP signature

Bug#893765: transition: ruby2.3

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 22/03/18 03:38, Antonio Terceiro wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> ruby2.5 has been made the default and the ruby2.5 transition has been
> finished succesfully. there is a pending issue with graphviz on armel,
> but that is beyond what we can do ATM.
> 
> So I would like to remove ruby2.3 now.

Go ahead.

Emilio

Bug#847613: TAG: nextcloud-client -- desktop client for nextcloud

[Michael Biebl]

Hi Lev

On Wed, 03 May 2017 22:04:53 -0700 Lev Lazinskiy  wrote:
> Owner: l...@levlaz.org
> Control: retitle -1 ITP: nextcloud-client -- desktop client for nextcloud

Any news on this ITP? Are you still interested in/working on this package?

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



signature.asc
Description: OpenPGP digital signature

Bug#894169: Error during 'Install base system':

[Charles Brent]

Package: installation-reports

Boot method: DVD
Image version: 
https://cdimage.debian.org/debian-cd/current/amd64/iso-dvd/debian-9.4.0-amd64-DVD-1.iso
Date:2018/3/26

Machine: ESPRIMO E5615 (Fujitsu-Siemens)
Processor: AMD ATHLON 64
Memory: 2x512M
Partitions: Single partition (+1G swap)

Output of lspci -knn (or lspci -nn):

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

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

Comments/Problems:

Install starts as expected, it 
Retrieves/extracts packages from the CD...then messages say
Unpacking...
Configuring...
Unpacking the base system etc
Configuring
Configuring APTsources...
Preparing linux-image-4.9.0-6-amd64...

Then ERROR
"Unable to install the selected kernel
An error was returned while trying to install the kernel into the target system.
Kernel package: 'linux-image-amd64'.
Check /var/log/syslog or see virtual console 4 for the details.
"

Note: I am fairly inexperienced installing a Debian instance - so
chances are I have done something incorrectly, though I read right
through the installation guide and I don't think I have missed
something obvious. Have tended to follow the 'recommended' set-up as
indicated in the GUI installer.

Thanks and regards,

Charles

Bug#894168: 2to3: uninstallable in unstable (requires newer python3-lib2to3)

[Simon McVittie]

Package: 2to3
Version: 3.6.5~rc1-1
Severity: grave
Justification: renders package unusable

2to3/3.6.5~rc1-1 depends on python3-lib2to3 (>= 3.6.5~rc1-3~) which
doesn't seem to exist yet. piuparts demonstrates this failing:
https://piuparts.debian.org/sid/source/p/python3-defaults.html

Looking at its source code, it seems that this is a versioned dependency
on @UPSTRVER@, which is assumed to be a version number that is valid for
src:python@VER@ and its binary packages. However, 2to3 uses @UPSTRVER@
as a version qualifier for python3-lib2to3, which is built by
src:python3-stdlib-extensions and so cannot be assumed to have exactly
the same versioning scheme as python@VER@.

python3's Suggests on python3-tk has the same bug, but much less
seriously because it's only a Suggests.

Putting key packages through piuparts before upload would probably be
a good idea, particularly when there are transitions going on around them.

smcv

Bug#893046: transition: evolution-data-server 3.28

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 17/03/18 03:13, Jeremy Bicha wrote:
> The gnome-desktop3/libgweather/mutter transitions are done now.

Go ahead.

Emilio

Bug#892802: transition: efl

[Emilio Pozuelo Monfort]

On 24/03/18 16:21, Andreas Metzler wrote:
> On 2018-03-13 Emilio Pozuelo Monfort  wrote:
>> Control: tags -1 confirmed
> 
>> On 13/03/18 08:15, Ross Vandegrift wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
> 
>>> Hello,
> 
>>> I'd like to request a transition for efl from experimental -> unstable.  
>>> This
>>> release takes over a few other source packages.  It also reverses some
>>> Debian-local ABI & soname deviations from the upstream releases.
> [...]
>> It looks good. Please go ahead and upload the affected packages to unstable,
>> then I'll schedule the binNMUs for the "bad" packages listed in
> 
>> https://release.debian.org/transitions/html/auto-efl.html
> 
> Hello Emilio,
> 
> efl has been built on all archs it is going build[1], could you please
> trigger the first run of binnmus?
> 
> FWIW the auto-efl tracker does not seem to work at all, I guess because
> "good" and "bad" are not disjunct.

Scheduled now. Note that efl is bd-uninstallable on s390x because luajit is not
available there. That's going to be a blocker, and needs action, whether by
removing efl and rdeps from s390x, or preferably by making efl build (which can
happen by disabling lua support, assuming that's an option, or by fixing 
luajit).

Cheers,
Emilio

Bug#893866: stretch-pu: package systemd/232-25+deb9u3

[Michael Biebl]

Am 26.03.2018 um 18:54 schrieb Adam D. Barratt:
> Control: tags -1 + confirmed
> 
> On Fri, 2018-03-23 at 14:15 +0100, Michael Biebl wrote:
>> The last stable upload of systemd introduced a rather nasty
>> regression
>> in networkd, which broke IPv6 support for lots of users.
>>
>> KiBi was so kind to dig out the relevant upstream commit which fixes
>> this and got confirmation from the bug reporter(s) that with this
>> patch applied, networkd behaves properly.
> 
> Please go ahead.

Uploaded

>> I thus would like to get this
>> update into stable as quickly as possible.
> 
> As per the earlier IRC discussion, I assume you mean "into stable-
> updates" here (or "available to users of stable"), which we'll
> endeavour to get sorted. The update can't actually make it in to stable
> any sooner than the next point release, as that's the only time that
> stable changes.

I did indeed mean "available to users of stable". Sorry for not using
the proper nomenclature.

Regards,
Michael


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



signature.asc
Description: OpenPGP digital signature

Bug#894144: libmutter-2.so.0: undefined symbol: glFramebufferTexture2D

[Simon McVittie]

Control: reassign -1 libmutter-2-0 3.28.0-2
Control: tags -1 upstream
Control: forwarded -1 https://gitlab.gnome.org/GNOME/mutter/issues/92

On Mon, 26 Mar 2018 at 16:11:29 -0400, Christopher Sasarak wrote:
> Shelby is the virtualbox guest. I will file a new bug report if I find 
> something else.
> 
> I'm using the vboxvideo driver with guest additions on virtualbox 5.27.

Where did you get these guest additions? Are they from Debian's
https://tracker.debian.org/pkg/virtualbox-guest-additions-iso or upstream's
equivalent binary release?

I assume you meant 5.2.7 rather than 5.27?

>   libGL.so.1 => /var/lib/VBoxGuestAdditions/lib/libGL.so.1 
> (0x7f1062e12000)

On my (real hardware) Debian system, libgl1 and libglx-mesa0 provide
the glFramebufferTexture2D function. I think the problem here is
probably that libmutter assumes all implementations of libGL.so.1
have this symbol, but in fact not all do, and in particular
VirtualBox's guest driver doesn't. I've reported this upstream at
.

Regards,
smcv

Bug#894166: cinnamon-desktop: Empty debian/tests/control confuses autopkgtest runners

[Jeremy Bicha]

Source: cinnamon-desktop
Version: 3.6.2-1
Severity: important
X-Debbugs-CC: m...@debian.org

Please don't comment out all the lines in debian/tests/control

This confuses the autopkgtest runners which treats this as a test
failure and therefore a regression.

Instead, it's better to remove debian/tests/ if you don't want the
autopkgtests to be attempted to be run. Since it's stored in git, you
can always go back and retrieve it later if you want it.

References
---
https://salsa.debian.org/cinnamon-team/cinnamon-desktop/blob/master/debian/tests/control
https://autopkgtest.ubuntu.com/packages/c/cinnamon-desktop/bionic/amd64

Thanks,
Jeremy Bicha

Bug#894167: Please package a newer version of lexicon

[Brad Warren]

Package: python3-lexicon
Version: 2.1.21-1

Over the weekend, lexicon released version 2.2.1 which adds support for 
multiple TXT records on the same domain. This functionality is needed in 
plugins for Certbot like python3-certbot-dns-dnsimple. Future versions of this 
and other Certbot plugins will rely on lexicon>=2.2.1. Can lexicon be updated?

The changes here and the reason Certbot needs this functionality are documented 
in more detail at https://github.com/AnalogJ/lexicon/issues/182 
.

Bug#893185: Pending fixes for bugs in the dnssecjava package

[pkg-java-maintainers]

tag 893185 + pending
thanks

Some bugs in the dnssecjava package are closed in revision
b31f06f3038450f7113f0e09e78b8014f9fa84c3 in branch 'master' by Ingo
Bauersachs

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/dnssecjava.git/commit/?id=b31f06f

Commit message:

Disable tests to build on Java 9 (Closes: #893185)

Bug#894130: Pending fixes for bugs in the prometheus-blackbox-exporter package

[pkg-go-maintainers]

tag 894130 + pending
thanks

Some bugs in the prometheus-blackbox-exporter package are closed in
revision da343da1124da8d8ce707baa35ec5026c8de2948 in branch 'master'
by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/prometheus-blackbox-exporter.git/commit/?id=da343da

Commit message:

New upstream release. Closes: #894130

Bug#894081: Libvirt debug symbols not available for latest version

[Andreas Beckmann]

Control: reassign -1 security.debian.org

On Mon, 26 Mar 2018 13:27:34 +0300 Mathieu Tarral  
wrote:
> Package: libvirt-daemon-system-dbgsym
> Version: 3.0.0-4+deb9u2

> i would like to install the debug symbols for libvirt-demon-system
> (and other libvirt packages),
> but it seems that they are not up to date in the stable-debug repositories.

Looks like they are available from proposed-updates-debug
but there does not seem to be a -debug repository
corresponding to stable/updates.

libvirt-daemon-system| 1.2.9-9+deb8u2~bpo70+1 | wheezy-backports
   | amd64
libvirt-daemon-system| 1.2.9-9+deb8u4 | oldstable   
   | amd64
libvirt-daemon-system| 1.2.9-9+deb8u5 | 
oldstable-proposed-updates | amd64
libvirt-daemon-system| 3.0.0-4+deb9u2~bpo8+1  | jessie-backports
   | amd64
libvirt-daemon-system| 3.0.0-4+deb9u2 | stable  
   | amd64
libvirt-daemon-system| 3.0.0-4+deb9u3 | proposed-updates
   | amd64
libvirt-daemon-system| 4.1.0-2| testing 
   | amd64
libvirt-daemon-system| 4.1.0-2| unstable
   | amd64
libvirt-daemon-system-dbgsym | 3.0.0-4+deb9u2 | stable-debug
   | amd64
libvirt-daemon-system-dbgsym | 3.0.0-4+deb9u3 | proposed-updates-debug  
   | amd64
libvirt-daemon-system-dbgsym | 4.1.0-2| testing-debug   
   | amd64
libvirt-daemon-system-dbgsym | 4.1.0-2| unstable-debug  
   | amd64


Andreas

Bug#894158: libogg: new upstream release 1.3.3

[Simon McVittie]

On Tue, 27 Mar 2018 at 07:45:27 +1030, Ron wrote:
> There's actually some more interesting fixes after the 1.3.3 tag, so I
> should probably nudge upstream toward a 1.3.4 tag sometime soon and pull
> in the corner case patch with those.

Sure, I'm in no rush to see 1.3.3.

Updating to a new upstream release would probably also be a good
opportunity to catch up on 3½ years of packaging best-practice (lose
the -dbg package, move Vcs-* off Alioth, fix Lintian warnings, that sort
of thing), and rebuilding with newer gcc defaults might well produce
better-hardened binaries.

smcv

Bug#882121: patch

[Aurélien COUDERC]

tags: patch

Stumbled upon this so if it’s of any help here’s a patch.


Cheers,
--
Aurélien
diff --git a/debian/sysctl.conf b/debian/sysctl.conf
index ad73592..e446560 100644
--- a/debian/sysctl.conf
+++ b/debian/sysctl.conf
@@ -63,7 +63,10 @@
 # Magic system request Key
 # 0=disable, 1=enable all, >1 bitmask of sysrq functions
 # Debian kernels have this set to 438 which is the OR of:
-#  64 = enable signalling of processes
+#2 = enable control of console logging level
+#4 = enable control of keyboard (SAK, unraw)
+#   16 = enable sync command
+#   32 = enable remount read-only
 #  128 = allow reboot/poweroff
 #  256 = allow nicing of all RT tasks
 #

Bug#894106: jabref: fails to start with java-8-openjdk-amd64

[gregor herrmann]

Control: forcemerge 893251 -1

On Mon, 26 Mar 2018 15:36:10 +0200, Stefan Laufmann wrote:

> to work around the issue as described in #893138 I tried starting jabref with
> $> JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64/ jabref
> 
> This helped overcoming the java 9 incompability at first but jabref did not
> launched.
> Instead I got prompted with a NoSuchMethodError Exception.

Right, this is unfortunately another problem, which is already
tracked as #893251.
 
> Thanks for your work on the package. I hope there is a way to fix this issue.
> :)

I share your hope :)
 

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: Ben Weaver: Stay With Me


signature.asc
Description: Digital Signature

Bug#894165: libadios-bin: adios_config -v returns an empty string

[Kyle Edwards]

Package: libadios-bin
Version: 1.13.0-2
Severity: normal

Dear Maintainer,

While attempting to build VTK on Debian, it failed to find libadios due
to a problem with adios_config: it does not return a version string.
Looking through the adios_config script, I see:

v) echo "$VERSIONSTRING"; exit 0;;

But it doesn't look like this value gets set anywhere in the file.
Please fix this so that software that checks the adios version can find
it.


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

Kernel: Linux 4.15.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.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libadios-bin depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.27-2
ii  libglib2.0-0 2.56.0-4
ii  libhdf5-100  1.10.0-patch1+docs-4
ii  libhdf5-openmpi-100  1.10.0-patch1+docs-4
ii  libibverbs1  17.1-1
ii  libnetcdf13  1:4.6.1-1
ii  libopenmpi2  2.1.1-8
ii  libsz2   1.0.2-1
ii  python   2.7.14-4
ii  python2.72.7.14-7
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages libadios-bin recommends:
ii  libadios-dev  1.13.0-2

libadios-bin suggests no packages.

-- no debconf information

Bug#894164: brightd uses 'char' for storing brightness, making it choke on levels over 127

[Raphael Wimmer]

Package: brightd
Version: 0.4.1-1+b1
Severity: important

Dear Maintainer,

brightd saves the current brightness in the variables 'char beforeFade' and 
'char savedLevel'.
On hardware where brightness values get higher than 127, the variable overflows 
(on an HP x360 1030 G2, the max value is 7500). This results in brightd 
'restoring' the brightness to a value that is much too low.
Changing both variables to 'int' solves the problem.

All the best,
Raphael Wimmer

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

[Sean Whitton]

Hello,

On Mon, Mar 26 2018, James R Barlow wrote:

> Thanks for the information. That's a worryingly high wall to climb and
> I'm concerned about implications for other platforms as well.
>
> I would appreciate if you can see about getting an exception, but I
> think I will change PyMuPDF to an optional but recommended dependency
> fairly soon.

That would be great in the meantime.

> I haven't made a major investment in it as yet with new code, but it
> does provide some powerful features that would be a major engineering
> effort to replicate and are likely not going to materialize in another
> open source library anytime soon. (Specifically: incremental updates,
> safe editing of PDF/A, PDF object garbage collection, fast
> rasterizing, robust text extraction.) The most commonly used Python
> PDF library, PyPDF2, is essentially unmaintained and in poor shape.

Having thought some more, I think our best bet will be to try to get
pymupdf to support linking against the static version of mupdf.  We have
techniques in Debian to deal with security updates in that case (called
binNMUs if you want to look them up).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#894158: libogg: new upstream release 1.3.3

[Ron]

Hi Simon,

On Mon, Mar 26, 2018 at 09:03:09PM +0100, Simon McVittie wrote:
> Source: libogg
> Version: 1.3.2-1
> Severity: wishlist
> 
> While updating ioquake3 I noticed that the upstream developer now bundles
> libogg-1.3.3, which is newer than the version in Debian.

FSVO "newer" ...  I was pretty sure there was actually nothing at all in
that one for us - but reviewing all the commits again, I see there is a
one-character typo fix in the docs (accurred -> occurred), and a one
line patch for a corner case that I'm not sure anything actually trips
over in practice.

The 1.3.3 release was mostly all futzing about in the build system for
Visual Studio, MacOS, and CI testing so it had been on my Meh Not For Us
list.

There's actually some more interesting fixes after the 1.3.3 tag, so I
should probably nudge upstream toward a 1.3.4 tag sometime soon and pull
in the corner case patch with those.


> Please consider also adding a debian/watch file for uscan, which would
> have caused Debian's QA infrastructure to pick this up automatically.

Automatically, yes - but usefully perhaps not so much.  Especially since
I'll generally get a poke directly from *upstream* if there is something
important in these which we are missing - and what is in git is usually
more interesting than what is in a tarball on the download site.

But thanks for the poke to review this again and note the current status
where people who aren't following git might see it.

  Cheers,
  Ron

Bug#894163: RFS: streamlink/0.11.0+dfsg-1~bpo9+1

[Alexis Murzeau]

Package: sponsorship-requests
Severity: wishlist
X-Debbugs-CC: debian-backpo...@lists.debian.org

Dear mentors and backports developers,

I am looking for a sponsor for my package "streamlink" into Debian
stretch-backports repository.

 * Package name: streamlink
   Version : 0.11.0+dfsg-1~bpo9+1
   Upstream Author : Streamlink Team
 * URL : https://streamlink.github.io/
 * License : BSD-2-clause, Apache-2.0, MIT/Expat, SIL-OFL-1.1
   Section : python

It builds those binary packages:

  livestreamer - transitional package - streamlink
  python3-streamlink - Python module for extracting video streams from
various websites
  python3-streamlink-doc - CLI for extracting video streams from various
websites (documenta
  streamlink - CLI for extracting video streams from various websites to
a video

To access further information about this package, please visit the
following URL:
  https://mentors.debian.net/package/streamlink


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

  dget -x
https://mentors.debian.net/debian/pool/main/s/streamlink/streamlink_0.11.0+dfsg-1~bpo9+1.dsc

More information about streamlink can be obtained from
https://streamlink.github.io/

Changes since the last upload:
streamlink (0.11.0+dfsg-1~bpo9+1) stretch-backports; urgency=low

  * Rebuild for stretch-backports.

 -- Alexis Murzeau   Sat, 10 Mar 2018 00:46:13 +0100

streamlink (0.11.0+dfsg-1) unstable; urgency=low

  * Fix comments in d/rules.
  * Use streamlink's own donation page instead of opencollective one.
  * Fix random test failure caused by hexdump output optimization with
 wildcards.
  * Add example directory.
  * New upstream version 0.11.0+dfsg.
  * python3-socks is now required as a build dependency.

 -- Alexis Murzeau   Fri, 09 Mar 2018 00:12:49 +0100


Differences from testing package (0.11.0+dfsg-1):
  * Use debhelper 10 as 11 is not available.
  * pycountry: add patch to support stable provided version (1.8)
  * d/control: require pycountry <= 1.15


Regards,
--
 Alexis Murzeau
 PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F









signature.asc
Description: OpenPGP digital signature

Bug#894162: tmuxinator: Please switch BD to ruby-factory-bot

[Georg Faerber]

Source: tmuxinator
Version: 0.9.0-2
Tags: patch upstream
Forwarded: https://github.com/tmuxinator/tmuxinator/pull/604

Hi,

factory_girl got recently renamed to factory_bot, as the former name was
problematic to some people. I've introduced ruby-factory-bot in Debian.

Additionally, I've prepared the change upstream, and pushed a commit to
the Debian git in branch bd-ruby-factory-bot.

Cheers,
Georg


signature.asc
Description: Digital signature

Bug#883529: Buildbot maintenance by PAPT

[Piotr Ożarowski]

[Robin Jarry, 2018-02-27]
> after some discussions on https://bugs.debian.org/883529, Martin Borgert
> suggested that buildbot becomes maintained by the Python Applications
> Packaging Team.
> 
> That sounds like a good thing to have more than one person able to work
> on this package.
> 
> I am currently working on buildbot (both upstream dev and Debian
> packaging), I have read the Debian Python Policy and I'm not sure how to
> proceed for joining the PAPT.

great, just let me know if you accept our policy and I'll hit the button
(BTW, dh-python should be ready for builbot now, let me know if you need
more changes)
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Bug#894157: pkgconf FTBFS: kyua: command not found

[Andrej Shadura]

On 26 March 2018 at 21:56, Adrian Bunk  wrote:
> Source: pkgconf
> Version: 1.4.2-1
> Severity: serious
>
> https://buildd.debian.org/status/package.php?p=pkgconf=sid
>
> ...
> make[2]: Leaving directory '/<>'
> kyua --config=none test --kyuafile='./Kyuafile' \
> --build-root='.'
> /bin/bash: kyua: command not found
> make[1]: *** [Makefile:1394: check] Error 127

Ugh. I shouldn't be building packages with DEB_BUILD_OPTIONS=nocheck locally…

-- 
Cheers,
  Andrej

Bug#894161: tcpdump: drop no longer needed 'capability sys_module' rule

[Jamie Strandboge]

Package: tcpdump
Version: 4.9.2-2
Severity: normal
Tags: patch modify-profile
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu bionic ubuntu-patch

Dear Maintainer,

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

  * debian/usr.sbin.tcpdump: drop 'capability sys_module' since we already
have 'net_admin' and network module loading (which happens with -D) is
allowed with 'net_admin' (LP: #1759029)

Thanks for considering the patch.


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

Kernel: Linux 4.15.0-12-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tcpdump-4.9.2/debian/control tcpdump-4.9.2/debian/control
--- tcpdump-4.9.2/debian/control2018-02-05 10:54:46.0 -0600
+++ tcpdump-4.9.2/debian/control2018-03-26 15:28:20.0 -0500
@@ -1,8 +1,7 @@
 Source: tcpdump
 Section: net
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Romain Francoise 
+Maintainer: Romain Francoise 
 Build-Depends: debhelper (>= 8.9.4~),
dh-apparmor,
dh-autoreconf,
diff -Nru tcpdump-4.9.2/debian/usr.sbin.tcpdump 
tcpdump-4.9.2/debian/usr.sbin.tcpdump
--- tcpdump-4.9.2/debian/usr.sbin.tcpdump   2017-12-31 08:48:36.0 
-0600
+++ tcpdump-4.9.2/debian/usr.sbin.tcpdump   2018-03-26 15:28:20.0 
-0500
@@ -1,6 +1,4 @@
 # vim:syntax=apparmor
-# Last Modified: Wed Feb  3 07:58:30 2009
-# Author: Jamie Strandboge 
 #include 
 
 /usr/sbin/tcpdump {
@@ -16,7 +14,6 @@
   network packet,
 
   # for -D
-  capability sys_module,
   @{PROC}/bus/usb/ r,
   @{PROC}/bus/usb/** r,
 

Bug#894160: gwyddion binary-all FTBFS: mv: cannot stat 'debian/libgwyddion20-dev/usr/lib/*/gwyddion/include/*'

[Adrian Bunk]

Source: gwyddion
Version: 2.50-1
Severity: serious

https://buildd.debian.org/status/fetch.php?pkg=gwyddion=all=2.50-1=1522065557=0

...
make[1]: Entering directory '/<>'
dh_install
find debian -name "*.la" -o -name "*.pyc" -o -name "*.pyo" | xargs -r rm -f
chrpath -d debian/tmp/usr/bin/gwyddion*
mv debian/libgwyddion20-dev/usr/lib/*/gwyddion/include/* 
debian/libgwyddion20-dev/usr/include/gwyddion
mv: cannot stat 'debian/libgwyddion20-dev/usr/lib/*/gwyddion/include/*': No 
such file or directory
make[1]: *** [debian/rules:25: override_dh_install] Error 1

Bug#894138: gitlab: 10.5.6 Problem compiling assets on post-install

[Er_Maqui]

Hi,

Problem appears on first instance on 9.5.4 version.

Same problem appears on 10.5.5+dfsg-3

After uninstall - purge - reinstall, same problem (with 10.5.5+dfsg-3)

Updating 10.5.5 to 10.5.6, same problem too.


Thanks,

https://maqui.darkbolt.net/
Linux registered user ~#363219
PGP keys avaiables at KeyServ. ID: 0x4233E9F2
Los hombres somos esclavos de la historia

Bug#894129: [pkg-go] Bug#894129: prometheus: Please backport Prometheus 2.2.1 to stretch.

[Martín Ferrari]

On 26/03/18 17:24, Daniel Swarbrick wrote:

> Please backport Prometheus 2.2.1 to stretch.

It is in my plans, but it has to reach testing first :-)

-- 
Martín Ferrari (Tincho)

Bug#894159: transition: icu

[GCS]

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

Hi RMs,

 While I've packaged new ICU releases, those were uploaded only to
experimental. It's really time to change this, especially that some
packages already need ICU 60.1+.
It will need a quick bootstrap. It needs to build without the Layout
Engine API, then the support library (icu-le-hb). Only then ICU can be
built with the Layout Engine API as the two libraries tied together.

Local rebuild of dependent packages[1] on amd64 revealed the good, the
bad and the ugly. Level 1 rebuilt OK and as level 1.5 I've rebuilt
boost1.62 and boost1.63 normally.

For level 2 I could rebuilt the following packages with a small patch:
389-adminutil
389-ds-base
an
dwdiff
ibus-qt
open-vm-tools
pyicu
yaz

Package aegisub FTBFS for a know issue, #873327 [2], fixed upstream
but the maintainer doesn't respond for six months now. :(
I've a patch for dee, but it FTBFS for a know problem, #876594 [3].
While I've a patch for grcompiler too and it builds, its self tests
are failing. It's a highly outdated package. :( The first Debian
revision of the current package version (v4.2) is uploaded on 2012,
26th of June. But its upstream is more or less still active[4] and has
a much newer version (v5.0.2).
The package libsimpleini compiles fine, but its symbols change with
the new ICU version.
Two packages, pyicu and yaz are highly outdated by the way, I may
overtake the former.

For level 3 two packages need a patch: 389-dsgw and libfolia. Others
build correctly.

Level 4 is a bit more complicated. I've a patch for the following packages:
ucto
php7.0
php7.1
php7.2

Two packages FTBFS for other reasons:
cyrus-imapd for #883951 [5] which is fixed upstream, but maintainer
doesn't respond for four months.
yi is an other example, the problem is reported as #868637 [6] without
any action for nine months. :( Upstream maybe solved the problem, at
least there are more upstream releases out there.

About level 5, only frog needs a patch. There's a failing package,
kbibtex and it's reason is filed as #893538 [7].

Some patches are simply adding '--with-icu=/usr' to the configure
invocation in debian/rules. Others are for ICU detection in the
configuration phase. No code change is needed in the packages.
If it matters, Ubuntu already transitioned with a bit different method.

I hope this transition can be authorized and/or please tell me if any
more information is needed.

Thanks in advance,
Laszlo/GCS
[1] https://release.debian.org/transitions/html/auto-icu.html
[2] https://bugs.debian.org/873327
[3] https://bugs.debian.org/876594
[4] https://github.com/silnrsi/grcompiler/commits/master
[5] https://bugs.debian.org/883951
[6] https://bugs.debian.org/868637
[7] https://bugs.debian.org/893538

Bug#880771: libdwarf/dwarfdump cross compile

[David Anderson]

I figured out a simple way to cross-build while
completely separating build-time objects from target
objects. Using AC_PATH_PROG as Helmut suggested.

Nothing complicated about it. Simple 'make'.

Tested with --host=gcc-arm-linux-gnueabihf
which generates libdwarf as arm fine, but
the dwarfdump final link fails because
AC_TRY_COMPILE looks for -lz and looks
in the build machine location, not the cross area.
Because the cross area does not have -lz,
while the build environment does I need
to find out at build time about
that target library.

I'm not sure how to fix this part, cannot
find anything on the web but words admitting it is
a problem.

Pushed this stuff to sourceforge
so it at least actually builds libdwarf
and gets dwarfdump objects built
though the final link fails on the -lz
issue.

Any suggestions to detect -lz in the target
libraries?

David Anderson

Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.

[Martín Ferrari]

Hi Daniel,

On 26/03/18 20:34, Daniel Swarbrick wrote:

> I was a bit too hasty in my previous reply. It appears that Alertmanager
> compresses and encodes all the web UI assets a Go "blob"
> (https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go).
> Elm libraries are only needed if you intend to hack / develop the web UI.

Exactly. Prometheus itself does the same thing.

The approach I took was to remove the blob and patch the web serving
code to read the files directly from disk, and then to do al the JS
processing at build time from source.

I would do the same for alertmanager, but for that I need a working Elm
stack to generate the JS from source, otherwise it is a serious
violation of Debian policy.

> I just built a fully functional alertmanager binary from a git clone,
> with no Elm or Haskell or Node.js anywhere to be seen on my system. This
> is why I mistakenly thought that the aforementioned RPMs had stripped
> the UI completely, when in fact it is simply compiled into the
> alertmanager binary.
> 
> Does this simplify things somewhat? I suppose it just leaves the
> vendored Go libs as a possible sticking point.

Vendoring Go libs would not be a direct violation of policy, but it is
something we try hard to avoid as it becomes a maintenance problem.
Vendoring pre-generated pre-minified code, on the other hand, is not
possible in Debian, and that's how we ended in the current situation :-)

It is because of this that I thought of stripping the UI away, and
replacing it with something bare-bones. This would not be that difficult
to do, it is just a matter of writing some html and JS.

If you could help me with that, I would take care of integrating the
replacement UI, and I could get a new release out of the door pretty
quickly.


-- 
Martín Ferrari (Tincho)

Bug#891799: openssl1.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

2018-03-26 21:01 GMT+02:00 Sebastian Andrzej Siewior :
> On 2018-02-28 23:38:44 [+0100], Manuel A. Fernandez Montecelo wrote:
>> Hello,
> Hi,
>
>> We need support in this package for RISC-V, to bootstrap the riscv64
>> architecture.
>
> Please be aware that we plan to get rid of this.

Yep, but there are still more than a hundred dependencies, incl.
important things like openssh and curl...


>> I am attaching a patch that allowed me to cross-compile the package.  I am 
>> not
>> completely sure if all of the options are the most correct or the best choice
>> (more optimised), for example I used DES_RISC2 because the MIPS family uses
>> those and it's probably the closest to RISC-V, so it's my best-guess.  But if
>> you spot something fishy, please tell.
>
> for the reason above I would care too much about this package on your
> side. Make sure the test suite passes and you should be good.

True.  Yeah, the test suite ran fine :)


>> It would be great if you could include these changes and release a new 
>> version
>> for unstable.
>
> There should be a new upstream version this week. This change should be
> part of it.

Great timing, we just added the arch to debian-ports, so maybe we
don't even need to upload to "unreleased".


>> If we can do something to speed-up this process, please let me/us know.
>
> I do accept a bribe.

:)

-- 
Manuel A. Fernandez Montecelo 

Bug#894144: libmutter-2.so.0: undefined symbol: glFramebufferTexture2D

[Christopher Sasarak]

Shelby is the virtualbox guest. I will file a new bug report if I find 
something else.

I'm using the vboxvideo driver with guest additions on virtualbox 5.27.

The host hardware is integrated graphics, Intel HD Graphics 630.

Here is the output of ldd:

linux-vdso.so.1 (0x7ffec9d93000)
libGL.so.1 => /var/lib/VBoxGuestAdditions/lib/libGL.so.1 
(0x7f1062e12000)
libEGL.so.1 => /usr/lib/x86_64-linux-gnu/libEGL.so.1 
(0x7f1062821000)
libupower-glib.so.3 => /usr/lib/x86_64-linux-gnu/libupower-glib.so.3 
(0x7f10625f9000)
libgnome-desktop-3.so.17 => 
/usr/lib/x86_64-linux-gnu/libgnome-desktop-3.so.17 (0x7f10623be000)
libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1 
(0x7f10621bb000)
libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 
(0x7f1061fb1000)
libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1 
(0x7f1061dae000)
libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 
(0x7f1061ba8000)
libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x7f1061998000)
libxkbfile.so.1 => /usr/lib/x86_64-linux-gnu/libxkbfile.so.1 
(0x7f1061772000)
libxkbcommon-x11.so.0 => 
/usr/lib/x86_64-linux-gnu/libxkbcommon-x11.so.0 (0x7f106156a000)
libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 
(0x7f106132a000)
libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 
(0x7f106112)
libX11-xcb.so.1 => /usr/lib/x86_64-linux-gnu/libX11-xcb.so.1 
(0x7f1060f1e000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 
(0x7f1060cf6000)
libxcb-randr.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-randr.so.0 
(0x7f1060ae6000)
libxcb-res.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-res.so.0 
(0x7f10608e2000)
libstartup-notification-1.so.0 => 
/usr/lib/x86_64-linux-gnu/libstartup-notification-1.so.0 (0x7f10606d8000)
libcanberra-gtk3.so.0 => 
/usr/lib/x86_64-linux-gnu/libcanberra-gtk3.so.0 (0x7f10604d3000)
libcanberra.so.0 => /usr/lib/x86_64-linux-gnu/libcanberra.so.0 
(0x7f10602c1000)
libgtk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 
(0x7f105f9ad000)
libgdk-3.so.0 => /usr/lib/x86_64-linux-gnu/libgdk-3.so.0 
(0x7f105f6b5000)
libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0 
(0x7f105f468000)
libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2 
(0x7f105f14b000)
libgdk_pixbuf-2.0.so.0 => 
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x7f105ef27000)
libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0 
(0x7f105eb89000)
libwacom.so.2 => /usr/lib/x86_64-linux-gnu/libwacom.so.2 
(0x7f105e97e000)
libgirepository-1.0.so.1 => 
/usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1 (0x7f105e74a000)
libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 
(0x7f105e53f000)
libSM.so.6 => /usr/lib/x86_64-linux-gnu/libSM.so.6 (0x7f105e337000)
libICE.so.6 => /usr/lib/x86_64-linux-gnu/libICE.so.6 
(0x7f105e11a000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 
(0x7f105dddc000)
libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 
(0x7f105dbca000)
libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 
(0x7f105d9c7000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f105d634000)
libdrm.so.2 => /usr/lib/x86_64-linux-gnu/libdrm.so.2 
(0x7f105d422000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 
(0x7f105d19b000)
libinput.so.10 => /usr/lib/x86_64-linux-gnu/libinput.so.10 
(0x7f105cf61000)
libgudev-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0 
(0x7f105cd56000)
libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 
(0x7f105cb02000)
libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 
(0x7f105c7ec000)
libgbm.so.1 => /usr/lib/x86_64-linux-gnu/libgbm.so.1 
(0x7f105c5dd000)
libmutter-clutter-2.so => 
/usr/lib/x86_64-linux-gnu/mutter/libmutter-clutter-2.so (0x7f105c273000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 
(0x7f105c055000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f105bc9b000)
VBoxOGLcrutil.so => /usr/lib/x86_64-linux-gnu/VBoxOGLcrutil.so 
(0x7f105baac000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 
(0x7f105b7f6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f105b5f2000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f105b3d4000)
libseccomp.so.2 => /lib/x86_64-linux-gnu/libseccomp.so.2 
(0x7f105b18f000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f105af87000)
libxcb-xkb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb-xkb.so.1 

Bug#893377: RFS: taptempo/1.2.1-1 [ITP]

[François Mazen]

Hi Lumin,

thanks a lot for your help. I'll try to fix everything.

> 1. Why is the package on mentors newer than that on github repo?
> Could you please keep the packaging repo up-to-date?

I've manually changed the timestamp of the changelog file from the
original repo, and I haven't check that the date was wrong. I can
update the changelog file.

> 
> 2. Where is your public key? no such key on keyserver.
> 
> 86A5ABD6FFDB0A0C7F5057D34797FA721C351C9E

The public key is published on the sks-keyservers network. Should I
sent it to debian keyring or other keyserver?

http://hkps.pool.sks-keyservers.net/pks/lookup?search=0x86A5ABD6FFDB0A0C7F5057D34797FA721C351C9E


> 
> 3. There are still many problems related to package, let's
> discuss on that once we have a synced git repository
> to talk about.

Should I submit a new revision of the package (1.2.1-2) or re-upload
with the current revision number (1.2.1-1)?

Regards,
François

Bug#894158: libogg: new upstream release 1.3.3

[Simon McVittie]

Source: libogg
Version: 1.3.2-1
Severity: wishlist

While updating ioquake3 I noticed that the upstream developer now bundles
libogg-1.3.3, which is newer than the version in Debian.

Please consider also adding a debian/watch file for uscan, which would
have caused Debian's QA infrastructure to pick this up automatically.

smcv

Bug#845222: openssh-client: ssh-copy-id creates ~/.ssh with wrong permissions

[Philip Hands]

tags -1 + moreinfo unreproducible
thanks

I note that the code that should be doing what is requested in this bug,
has been present since 2010.  Namely the umask 077 before the mkdir.

That being the case, I assume that there was something unusual about the
target system that caused the umask not to work as expected for some
reason.

It's a shame that I didn't notice this bug when it was reported, and
therefore didn't ask for additional information in a timely manner.
Sorry about that.

Cheers, Phil.

P.S. I imagine that the target system will have changed enough to make
  the bug unreproducible by now.  That being the case I'll mark it as
  needing additional information, and would suggest closing the bug if
  none turns up within a month or two.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#894157: pkgconf FTBFS: kyua: command not found

[Adrian Bunk]

Source: pkgconf
Version: 1.4.2-1
Severity: serious

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

...
make[2]: Leaving directory '/<>'
kyua --config=none test --kyuafile='./Kyuafile' \
--build-root='.'
/bin/bash: kyua: command not found
make[1]: *** [Makefile:1394: check] Error 127

Bug#894155: openjdk-9-jre: "Minecraft.jar" no longer running via binfmt misc

[Ian Campbell]

Package: openjdk-9-jre
Version: 9.0.4+12-2
Severity: important

Dear Maintainer,

After a recent upgrade I am now seeing:

$ ./Minecraft.jar 
can't locate java: No such file or directory

At the weekend I updated my (slightly out of date) Buster system, picking up
new versions of many Java packages including:

$ grep -iE 'jdk|jre' /var/log/dpkg.log | grep upgrade\\b
2018-03-25 13:18:30 upgrade default-jdk:amd64 2:1.8-59 2:1.9-62
2018-03-25 13:18:31 upgrade default-jdk-headless:amd64 2:1.8-59 2:1.9-62
2018-03-25 13:18:31 upgrade default-jre:amd64 2:1.8-59 2:1.9-62
2018-03-25 13:18:31 upgrade default-jre-headless:amd64 2:1.8-59 2:1.9-62
2018-03-25 13:18:32 upgrade openjdk-8-jdk:amd64 8u151-b12-1 8u162-b12-1
2018-03-25 13:18:32 upgrade openjdk-8-jre:amd64 8u151-b12-1 8u162-b12-1
2018-03-25 13:18:32 upgrade openjdk-8-jdk-headless:amd64 8u151-b12-1 
8u162-b12-1
2018-03-25 13:18:34 upgrade openjdk-8-jre-headless:amd64 8u151-b12-1 
8u162-b12-1

(and a whole load of lib*-java too). I seem to have jdk 9 as the default for
relevant looking things:

$ sudo update-alternatives --display java
java - auto mode
  link best version is /usr/lib/jvm/java-9-openjdk-amd64/bin/java
  link currently points to /usr/lib/jvm/java-9-openjdk-amd64/bin/java
  link java is /usr/bin/java
  slave java.1.gz is /usr/share/man/man1/java.1.gz
/usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java - priority 1081
  slave java.1.gz: /usr/lib/jvm/java-8-openjdk-amd64/jre/man/man1/java.1.gz
/usr/lib/jvm/java-9-openjdk-amd64/bin/java - priority 1091
  slave java.1.gz: /usr/lib/jvm/java-9-openjdk-amd64/man/man1/java.1.gz
$ sudo update-alternatives --display jexec
jexec - auto mode
  link best version is /usr/lib/jvm/java-9-openjdk-amd64/lib/jexec
  link currently points to /usr/lib/jvm/java-9-openjdk-amd64/lib/jexec
  link jexec is /usr/bin/jexec
  slave jexec-binfmt is /usr/share/binfmts/jar
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jexec - priority 1081
  slave jexec-binfmt: /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jar.binfmt
/usr/lib/jvm/java-9-openjdk-amd64/lib/jexec - priority 1091
  slave jexec-binfmt: /usr/lib/jvm/java-9-openjdk-amd64/lib/jar.binfmt

I've tried fiddling with the update-java-alternatives selection but without any
luck.

Manually invoking the jdk8 jexec I get:

$ /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/jexec Minecraft.jar 
invalid file (bad magic number): Exec format error

Manually invoking the jdk9 jexec I get:

$ /usr/lib/jvm/java-9-openjdk-amd64/lib/jexec Minecraft.jar 
can't locate java: No such file or directory

Possibly also of interest:

$ strace /usr/lib/jvm/java-9-openjdk-amd64/lib/jexec Minecraft.jar
execve("/usr/lib/jvm/java-9-openjdk-amd64/lib/jexec", 
["/usr/lib/jvm/java-9-openjdk-amd6"..., "Minecraft.jar"], 0x7ffee6c16608 /* 52 
vars */) = 0
brk(NULL)   = 0x55ccf1504000
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
access("/etc/ld.so.preload", R_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=278790, ...}) = 0
mmap(NULL, 278790, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f97611e4000
close(3)= 0
access("/etc/ld.so.nohwcap", F_OK)  = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, 
"\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\240\33\2\0\0\0\0\0"..., 832) = 
832
fstat(3, {st_mode=S_IFREG|0755, st_size=1800248, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x7f97611e2000
mmap(NULL, 3906368, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0x7f9760c4b000
mprotect(0x7f9760dfc000, 2093056, PROT_NONE) = 0
mmap(0x7f9760ffb000, 24576, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1b) = 0x7f9760ffb000
mmap(0x7f9761001000, 15168, PROT_READ|PROT_WRITE, 
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f9761001000
close(3)= 0
arch_prctl(ARCH_SET_FS, 0x7f97611e3500) = 0
mprotect(0x7f9760ffb000, 16384, PROT_READ) = 0
mprotect(0x55ccf13eb000, 4096, PROT_READ) = 0
mprotect(0x7f9761229000, 4096, PROT_READ) = 0
munmap(0x7f97611e4000, 278790)  = 0
lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=73728, ...}) = 0
lstat("/usr/lib/jvm", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/usr/lib/jvm/java-9-openjdk-amd64", {st_mode=S_IFDIR|0755, 
st_size=4096, ...}) = 0
lstat("/usr/lib/jvm/java-9-openjdk-amd64/jre", 0x7ffe41b91f10) = -1 ENOENT 
(No such file or directory)
dup(2)  = 3
fcntl(3, F_GETFL) 

Bug#894144: libmutter-2.so.0: undefined symbol: glFramebufferTexture2D

[Simon McVittie]

Thanks for splitting this out to a separate bug.

On Mon, 26 Mar 2018 at 14:52:03 -0400, Christopher Sasarak wrote:
> This also happened inside a VirtualBox session

In the bug you reported, there are syslog entries from a machine named
"shelby". What is that machine? VirtualBox, or real hardware, or what?

> I will try to check my home machine which is not a virtual machine
> later tonight. To see if the same problem exists there.

Please answer the questions below for each differently-configured machine
where you see this bug.

If GNOME Shell crashes in a different way (without the symbol lookup
error for glFramebufferTexture2D), please report that as a separate bug,
and not as part of this one.

> Mar 26 12:20:36 shelby org.gnome.Shell.desktop[1451]: /usr/bin/gnome-shell: 
> symbol lookup error: /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined 
> symbol: glFramebufferTexture2D

What graphics hardware do you have?

Which 3D driver (libGL implementation) are you using? (NVIDIA
proprietary? Mesa? fglrx? Virtualbox precompiled guest driver? etc.)

> Mar 26 12:20:36 shelby org.gnome.Shell.desktop[1472]: /usr/bin/gnome-shell: 
> symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined symbol: 
> glFramebufferTexture2D

If you run this command:

ldd /usr/lib/x86_64-linux-gnu/libmutter-2.so.0

what do you get?

Thanks,
smcv

Bug#894154: telepathy-qt: missing build dependecy on libxml2-dev

[Adrian Bunk]

Source: telepathy-qt
Version: 0.9.7-3
Severity: serious

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

...
-- Checking for module 'libxml-2.0'
--   No package 'libxml-2.0' found
-- Could NOT find LibXml2 (missing: LIBXML2_LIBRARIES LIBXML2_INCLUDE_DIR) 
...
   dh_install
dh_install: Cannot find (any matches for) 
"usr/lib/*/libtelepathy-qt5-farstream.so.0*" (tried in ., debian/tmp)

dh_install: libtelepathy-qt5-farstream0 missing files: 
usr/lib/*/libtelepathy-qt5-farstream.so.0*
dh_install: missing files, aborting
make: *** [debian/rules:13: binary] Error 25

Bug#893024: Manual entry into UI date widget is broken

[martin f krafft]

found 893024 2.0.2-1
reopen 893024
kthxbye

also sprach Jeffrey Ratcliffe  [2018-03-16 21:32 +0100]:
> Thanks for the report. Fixed in the next release.

2.0.2 suffers from a different, but probably related problem:
entering 2018-03-15 makes the date then appear as 0015-00-00.

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
above all, we should not wish to divest
our existence of its rich ambiguity.
 --friedrich nietzsche


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#894156: bedops FTBFS on mips/mipsel: Memory exhausted

[Adrian Bunk]

Source: bedops
Version: 2.4.32+dfsg-1
Severity: serious
Tags: patch

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

...
mkdir -p ../bin && g++ -o ../bin/bedmap-typical -g -O2 
-fdebug-prefix-map=/<>/bedops-2.4.32+dfsg=. -fstack-protector-strong 
-Wformat -Werror=format-security   -s -Wall -pedantic -O3 -std=c++11  
objects_typical/NaN.o objects_typical/starchConstants.o 
objects_typical/starchFileHelpers.o objects_typical/starchHelpers.o 
objects_typical/starchMetadataHelpers.o objects_typical/unstarchHelpers.o 
objects_typical/starchSha1Digest.o objects_typical/starchBase64Coding.o  
-iquote../../../../interfaces/general-headers -Wl,-z,relro -Wl,-z,now -ljansson 
-lz -lbz2 Bedmap.cpp
/tmp/ccY7Hd7w.s: Assembler messages:
/tmp/ccY7Hd7w.s: Fatal error: can't close /tmp/cc9LiHfl.o: Memory exhausted
make[4]: *** [Makefile:51: ../bin/bedmap-typical] Error 1


Fix:

--- debian/rules.old2018-03-26 14:39:37.624272779 +
+++ debian/rules2018-03-26 15:22:42.490793752 +
@@ -10,6 +10,15 @@
 
 include /usr/share/dpkg/default.mk
 
+include /usr/share/dpkg/architecture.mk
+
+# less debug info to avoid running
+# out of address space
+ifneq (,$(filter $(DEB_HOST_ARCH), mips mipsel))
+  export DEB_CFLAGS_MAINT_APPEND = -g1
+  export DEB_CXXFLAGS_MAINT_APPEND = -g1
+endif
+
 docpkg := $(DEB_SOURCE)-doc
 
 %:

Bug#893969: maxima: fails to load operatingsystem package

[Federico Beffa]

The attached patch solved the problem for me. The patch is the
difference between the file installed by the Debian package and the
file currently distributed with maxima 5.41.
--- operatingsystem.lisp.orig	2018-03-26 21:31:40.003350426 +0200
+++ operatingsystem.lisp	2018-03-26 21:31:52.475471997 +0200
@@ -19,7 +19,7 @@
   #+clisp (ext:cd dir)
   #+cmu (setf (ext:default-directory) dir)
   #+cormanlisp (ccl:set-current-directory dir)
-  #+gcl (si:chdir dir)
+  #+gcl (si::chdir dir)
   #+lispworks (hcl:change-directory dir)
   #+lucid (lcl:working-directory dir)
   #+sbcl (sb-posix:chdir dir)
@@ -87,4 +87,4 @@
   (let ((buf (make-array 4096 :element-type (stream-element-type input-stream
 (loop for pos = (read-sequence buf input-stream)
while (plusp pos)
-   do (write-sequence buf output-stream :end pos))
\ No newline at end of file
+   do (write-sequence buf output-stream :end pos))

Bug#894153: libreoffice-common: crash on writer, calc and impress when entering unicode codes with Ctrl-U, even for ASCII characters

[Luc Maisonobe]

Package: libreoffice-common
Version: 1:6.0.2-1
Severity: normal

Dear Maintainer,

Since version 6, all libreoffice programs crash immediately when trying
to enter characters using their unicode encoding with a Ctrl-U sequence.

I used this a lot for entering greek letters in scientific documents
(Ctrl-U 0 3 B 1 gives alpha: α for example) or for some typesettings
characters (Ctrl-U 2 0 2 6 gives the ellipsis …). The Ctrl-U encoding
still works on all applications, like terminal or event reportbug as
I just used it above), but now it crashes libreoffice immediately.

How to reproduce:

 1) from the command line, run "libreoffice"
 2) in the window, select "Create: writer document"
 3) in the body of the empty "Untitled 1" document,
type Ctrl-U 6 1
 4) libreoffice crashes and propose to attempt recovery
of the untitled document
 5) after recovery, the document is still empty

The hexadecimal code given in the procedure above 0x61, represents
the ASCII character 'a', so it is not a problem of encoding or
fonts or anything like this.

The crash occurs for all characters I tried.

I tried to see if it was linked to the non-ASCII characters, but
this is not the case. If I type the codes above, even for greek
or typesettings characters in a terminal window and then copy-paste
the character in Libreoffice, the character is displayed correctly.

The crash seems related to the fact I enter them from keyboard
with the Ctrl-U prefix, which is pretty much standard nowadays
for other Debian applications.



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

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

Versions of packages libreoffice-common depends on:
ii  libreoffice-style-tango  1:6.0.2-1
ii  ure  6.0.2-1+b1

Versions of packages libreoffice-common recommends:
ii  fonts-liberation2   2.00.1-5
ii  libexttextcat-data  3.4.5-1
ii  python3-uno 1:6.0.2-1+b1
ii  xdg-utils   1.1.2-2

Versions of packages libreoffice-common suggests:
ii  libreoffice-style-galaxy [libreoffice-style]  1:6.0.2-1
ii  libreoffice-style-tango [libreoffice-style]   1:6.0.2-1

Versions of packages python3-uno depends on:
ii  libc6 2.27-2
ii  libgcc1   1:8-20180312-2
ii  libpython3.6  3.6.5~rc1-1
ii  libreoffice-core  1:6.0.2-1+b1
ii  libstdc++68-20180312-2
ii  python3   3.6.4-1
ii  python3.6 3.6.5~rc1-1
ii  uno-libs3 6.0.2-1+b1
ii  ure   6.0.2-1+b1

-- no debconf information

Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.

[Daniel Swarbrick]

Martin,

I was a bit too hasty in my previous reply. It appears that Alertmanager
compresses and encodes all the web UI assets a Go "blob" (
https://github.com/prometheus/alertmanager/blob/master/ui/bindata.go). Elm
libraries are only needed if you intend to hack / develop the web UI.

I just built a fully functional alertmanager binary from a git clone, with
no Elm or Haskell or Node.js anywhere to be seen on my system. This is why
I mistakenly thought that the aforementioned RPMs had stripped the UI
completely, when in fact it is simply compiled into the alertmanager binary.

Does this simplify things somewhat? I suppose it just leaves the vendored
Go libs as a possible sticking point.

Best,
Daniel

Bug#894077: lintian: False positive spelling-error-in-manpage information

[Chris Lamb]

tags 894077 + pending
thanks

Thanks Patrick .. fixed in Git, pending upload: :)

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=8782e00c8717c22b942f35b94b98041a9c299b30


Regards,

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

Bug#886949: xfce4-indicator-plugin: Not all indicator icons are being shown. Please, help to debug.

[Mike Gabriel]

Hi once more,

On  Mo 26 Mär 2018 19:21:46 CEST, Sophoklis Goumas wrote:


Package: xfce4-indicator-plugin
Version: 2.3.3-1.1
Followup-For: Bug #886949

Mike, I applied the mentioned patch to the package but unfortunately
the problem still remains, no improvements done. Did it resolve this for you?

Sophoklis


for the new xfce4-indicator-applet implementation, make sure that  
indicator-application is not installed (or rather, does not start on  
XFCE session startup). Also check, that ayatana-indicator-application  
_is_ running after the session has come up.


Thanks,
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpo1jv4bC83z.pgp
Description: Digitale PGP-Signatur

Bug#894151: openvdb FTBFS with libblosc-dev 1.14.2+ds1-1

[Adrian Bunk]

Source: openvdb
Version: 5.0.0-1
Severity: serious

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

...
g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-security 
-Wdate-time -D_FORTIFY_SOURCE=2 -fvisibility=hidden -fvisibility-inlines-hidden 
-pthread -g -I . -I .. -I /usr/include -I /usr/include/OpenEXR -I /usr/include 
-I /usr/include -I /usr/include -DOPENVDB_USE_BLOSC -DOPENVDB_USE_LOG4CPLUS 
-DOPENVDB_USE_GLFW_3 -I /usr/include -fPIC -o unittest/TestFile.o 
unittest/TestFile.cc
unittest/TestFile.cc: In member function 'void TestFile::testBlosc()':
unittest/TestFile.cc:2555:54: error: invalid conversion from 'char**' to 'const 
char**' [-fpermissive]
 if (0 > blosc_compcode_to_compname(compcode, )) continue;
  ^
In file included from unittest/TestFile.cc:62:0:
/usr/include/blosc.h:348:18: note:   initializing argument 2 of 'int 
blosc_compcode_to_compname(int, const char**)'
 BLOSC_EXPORT int blosc_compcode_to_compname(int compcode, const char 
**compname);
  ^~
make[2]: *** [Makefile:873: unittest/TestFile.o] Error 1

Bug#894152: O: trac-codecomments -- code comments and review plugin for Trac

[W. Martin Borgert]

Package: wnpp
Severity: normal

I intend to orphan the trac-codecomments package,
because I do not use it anymore.
There is no visible upstream activity since 2015-07.

The package description is:
 This plugin allows you to leave comments on top of files, changesets,
 and attachments. Once you've added all of your comments, you can send
 them to tickets. These include links to these comments and their
 description.
  * Comments on files – you can comment on every file in the
repository.
  * Inline comments on files – comment on a specific line. The
comments appears in context, below the line in question.
  * Comments on changesets – useful when doing code reviews of
incoming commits.
  * Comments on attachment pages – useful when reviewing patches.
  * Wiki Markup – you can use the standard Trac wiki markup inside
your comments.
  * Instant preview – to make sure you get the formatting right.
  * Sending comments to tickets – you can select arbitrary number of
comments and create a new ticket out of them. The text of the
ticket defaults to links to the comments and their text, but you
can edit these before saving the ticket.
  * Comments/ticket cross-reference – to remember which comments are
already in tickets and which are not.


signature.asc
Description: PGP signature

Bug#886949: xfce4-indicator-plugin: Not all indicator icons are being shown. Please, help to debug.

[Mike Gabriel]

Hi,

On  Mo 26 Mär 2018 19:21:46 CEST, Sophoklis Goumas wrote:


Package: xfce4-indicator-plugin
Version: 2.3.3-1.1
Followup-For: Bug #886949

Mike, I applied the mentioned patch to the package but unfortunately
the problem still remains, no improvements done. Did it resolve this for you?

Sophoklis


maybe the issue is of a different source. See  
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891927


For Qt4 applications, try installing sni-qt. Also, I have heard about  
Python / gir1.2 related packages that fail, if they use the old  
gir1.2-appindicator package.


Can you please provide a more precise list of what works and what not?  
Could you possibly test other applications, that you don't use  
regularly?


Thanks!
Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpJljdJku1q1.pgp
Description: Digitale PGP-Signatur

Bug#894150: tlp: Consider reducing the association between TLP and smartmontools

[David Mohammed]

Package: tlp
Version: 1.1-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

TLP currently recommends smartmontools.

Strictly speaking it does not actually need smartmontools to operate.

Filed separately is a bug report to split smartmontools into two binaries -
smartctl which TLP can use if its installed and smartd which is really a server
based daemon that emails and administrator.  TLP does not need this part.

Thus - could we for the moment lessen the association between the two packages
- reduce from Recommends: to Suggests:



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

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

Versions of packages tlp depends on:
ii  hdparm9.54+ds-1
ii  iw4.14-0.1
ii  lsb-base  9.20170808
ii  pciutils  1:3.5.2-1
ii  rfkill2.31.1-0.5
ii  usbutils  1:007-4+b1

Versions of packages tlp recommends:
ii  ethtool 1:4.11-1
ii  linux-cpupower  4.15.11-1
ii  smartmontools   6.5+svn4324-1
ii  tlp-rdw 1.1-1

Versions of packages tlp suggests:
pn  acpi-call-dkms  
pn  tp-smapi-dkms   

-- no debconf information

Bug#894149: buzztrax FTBFS with gstreamer 1.14

[Adrian Bunk]

Source: buzztrax
Version: 0.10.2-4
Severity: serious
Tags: buster sid

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

...
src/gst/dec/bt-dec.c:956:14: error: expected '=', ',', ';', 'asm' or 
'__attribute__' before '-' token
 buzztrax - dec,
  ^

Bug#894148: O: python-pyld -- implementation of the JSON-LD API

[W. Martin Borgert]

Package: wnpp
Severity: normal

I intend to orphan the python-pyld package, because I do not use it anymore.

The package description is:
 This library is an implementation of the JSON-LD specification in Python.
 .
 This package provides the Python 2.x module.

Upstream is active and recently released version 1.0.3.

Bug#894147: postfix: Postfix debconf should default to "Local Only" to not expose a security risk

[David Mohammed]

Source: postfix
Version: debconf question for postfix should be "Local only"
Severity: wishlist
Tags: upstream

Dear Maintainer,

When installing Postfix, the debconf question defaults to "Internet Site" -
this is not logical since this will potentially expose the unwary installer to
a security issue where port 25 is left open.

Logically "Local only" should be used as the default debconf answer to ensure
the daemon binds to the loopback interface only.



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

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

Bug#894146: smartmontools: Split the smart daemon from the command line based smartctl

[David Mohammed]

Package: smartmontools
Version: 6.5+svn4324-1
Severity: wishlist
Tags: upstream

Dear Maintainer,

TLP recommends smartmontools. Smartmontools also installs a mail server.

TLP actually only needs smartctl which is the command line utility.  The daemon
smartd is the only bit that needs to send email to an administrator.

Thus, please can smartmontools be split into two binary packages to allow TLP
and other related tools to recommend smartctl without needing to install a mail
server as well.



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

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

Versions of packages smartmontools depends on:
ii  debianutils  4.8.4
ii  init-system-helpers  1.51
ii  libc62.27-2
ii  libcap-ng0   0.7.7-3.1+b1
ii  libgcc1  1:8-20180321-1
ii  libselinux1  2.7-2+b1
ii  libstdc++6   8-20180321-1
ii  lsb-base 9.20170808

Versions of packages smartmontools recommends:
ii  mailutils [mailx]  1:3.4-1

Versions of packages smartmontools suggests:
pn  gsmartcontrol   
pn  smart-notifier  

-- no debconf information

Bug#894054: radeontop: New upstream version, needed for VEGA support.

[Boyd Stephen Smith Jr.]

On Monday, March 26, 2018 7:06:08 AM CDT John Paul Adrian Glaubitz wrote:
> Please ask upstream to release a new upstream release first.
> 
> > [1] https://github.com/clbr/radeontop/releases

Just for us:

https://github.com/clbr/radeontop/releases/tag/v1.1
-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#894145: {ruby,python}-gitlab: both ship /usr/share/man/man1/gitlab.1.gz

[Andreas Beckmann]

Package: ruby-gitlab,python-gitlab
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite
Control: found -1 1:1.3.0-1
Control: found -1 4.2.0-1

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:

  Selecting previously unselected package python-gitlab.
  Preparing to unpack .../8-python-gitlab_1%3a1.3.0-1_all.deb ...
  Unpacking python-gitlab (1:1.3.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-TxBJCy/8-python-gitlab_1%3a1.3.0-1_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/gitlab.1.gz', which is also in 
package ruby-gitlab 4.2.0-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-TxBJCy/8-python-gitlab_1%3a1.3.0-1_all.deb

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/share/man/man1/gitlab.1.gz

This bug is assigned to 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
also register in the BTS that the other package is affected by the bug.

Cheers,

Andreas

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


ruby-gitlab=4.2.0-1_python-gitlab=1%1.3.0-1.log.gz
Description: application/gzip

Bug#894139: extra-license-file false positive

[Chris Lamb]

tags 894139 + pending
thanks

Thanks :)  Fixed in Git, pending upload:

  
https://anonscm.debian.org/git/lintian/lintian.git/commit/?id=12b05def244907f9624424504b44e0a6658ca3f9


Regards,

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

Bug#894131: [pkg-go] Bug#894131: prometheus-alertmanager: New upstream release 0.14.0 available. Please package and backport to stretch.

[Daniel Swarbrick]

Hi Martin,

I just had a quick look at the docs for build Elm from source, and it looks
like a pretty direct journey to npm hell. I'm pretty out of touch with
modern web development, so I'm not sure how much help I can be be in terms
of packaging Elm.

I can suggest a couple of alternatives. One would be to ship Alertmanager
without any UI whatsoever, as has been done in the unofficial RPMs at
https://packagecloud.io/prometheus-rpm/release. This obviously affects the
end user experience quite substantially, but ultimately does not detract
from Alertmanager's main functionality.

The other option would be to bundle the necessary Elm libs with
Alertmanager itself, but I suspect this violates Debian packaging policy.

Even if somebody were able to package Elm and make it a dependency of the
Alertmanager package, those JS libs need to somehow be served by the
integrated web server in Alertmanager. I would normally expect to see an
Apache or Nginx config snippet or .htaccess with some kind of directory
alias, but obviously that won't fly in this case. Symlinks to directories?
I don't think I've seen many (if any) Debian packages do that.

Best,
Daniel

Bug#893488: gnome-shell 3.28 crashes on Radeon R9: Failed to create texture 2d due to size/format constraints

[Simon McVittie]

Control: retitle -1 gnome-shell 3.28 crashes on Radeon R9: Failed to create 
texture 2d due to size/format constraints

I'm retitling this based on my best guess at the root cause to stop
others thinking it's an appropriate place to report different crashes.
I think we'd prefer to err on the side of having different reports and
merging them, rather than having one report for multiple crashes and
having to disentangle which is which.

On Mon, 19 Mar 2018 at 12:05:42 +0100, Matteo Settenvini wrote:
> I am attaching also a core file appearing in my home folder,
> apparently it is for Xwayland.

This core probably isn't helpful: it's part of the symptom, not the
cause. If the Wayland compositor (in this case gnome-shell) crashes,
Xwayland will crash too: that's (currently) an expected thing.

> Looking at the journal I see:

To help with interpretation:

Process 1402 looks like the gdm "greeter" GNOME Shell process (uid 117).

Process 1925 looks like your GNOME Shell (uid 1000).

> mar 19 11:46:42 rosebud gnome-shell[1402]: g_array_free: assertion 'array' 
> failed

This means something isn't quite right, a long way before what I
think is probably the actual root cause. If you can run GNOME Shell
with G_DEBUG=fatal-criticals and get a backtrace from the resulting
crash (systemd-coredump is probably the easiest way), that might be
helpful; but this isn't likely to be the root cause.

> mar 19 11:46:44 rosebud gnome-shell[1402]: JS WARNING: 
> [resource:///org/gnome/shell/ui/main.js 332]: reference to undefined property 
> "MetaStage"
> mar 19 11:46:44 rosebud gnome-shell[1402]: JS WARNING: 
> [resource:///org/gnome/shell/ui/layout.js 220]: reference to undefined 
> property "MetaWindowGroup"
> mar 19 11:46:44 rosebud gnome-shell[1402]: JS WARNING: 
> [resource:///org/gnome/shell/ui/osdMonitorLabeler.js 59]: reference to 
> undefined property "MetaDBusDisplayConfigSkeleton"

This stuff is probably harmless.

> mar 19 11:46:45 rosebud gnome-shell[1402]: _cogl_buffer_gl_map_range: 
> assertion 'data != ((void *)0)' failed
> mar 19 11:46:45 rosebud gnome-shell[1402]: g_error_free: assertion 'error != 
> NULL' failed
> mar 19 11:46:45 rosebud gnome-shell[1402]: _cogl_buffer_bind_no_create: 
> assertion 'ctx->current_buffer[buffer->last_target] != buffer' failed
> mar 19 11:46:45 rosebud gnome-shell[1402]: Failed to create texture for 
> background
> mar 19 11:46:45 rosebud gnome-shell[1402]: Failed to create texture for 
> background

Something is already going wrong with OpenGL drawing in gdm's gnome-shell,
but unlike yours, it didn't crash.

Did you notice that in GNOME Shell 3.28, you don't get the grey "noise"
background texture that you should? In GNOME Shell 3.26, do you get the
"noise" texture correctly?

(This one:
https://askubuntu.com/questions/534187/where-is-the-login-screen-wallpaper-for-gdm-stored)

> mar 19 11:51:50 rosebud gnome-shell[1925]: GNOME Shell started at Mon Mar 19 
> 2018 11:51:46 GMT+0100 (CET)
> mar 19 11:51:52 rosebud gnome-shell[1925]: _cogl_buffer_gl_map_range: 
> assertion 'data != ((void *)0)' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: g_error_free: assertion 'error != 
> NULL' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: _cogl_buffer_bind_no_create: 
> assertion 'ctx->current_buffer[buffer->last_target] != buffer' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: _cogl_buffer_gl_map_range: 
> assertion 'data != ((void *)0)' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: g_error_free: assertion 'error != 
> NULL' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: _cogl_buffer_bind_no_create: 
> assertion 'ctx->current_buffer[buffer->last_target] != buffer' failed

Again, this isn't right, and backtraces from these assertion failures
might be interesting, but it probably isn't the whole story.

There might also be some bugs in the error-handling.

> mar 19 11:51:52 rosebud gnome-shell[1925]: Failed to allocate texture: Failed 
> to create texture 2d due to size/format constraints
> mar 19 11:51:52 rosebud gnome-shell[1925]: cogl_object_ref: assertion 'object 
> != ((void *)0)' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: clutter_texture_set_cogl_texture: 
> assertion 'cogl_is_texture (cogl_tex)' failed
> mar 19 11:51:52 rosebud gnome-shell[1925]: CoglError set over the top of a 
> previous CoglError or uninitialized memory.
> mar 19 11:51:52 rosebud gnome-shell[1925]: clutter_texture_set_cogl_texture: 
> assertion 'cogl_is_texture (cogl_tex)' failed
> mar 19 11:51:52 rosebud kernel: gnome-shell[1925]: segfault at 1 ip 
> 7fae6a9a7509 sp 7fffdb1a0d30 error 4 in 
> libglib-2.0.so.0.5600.0[7fae6a93e000+113000]

I think "Failed to create texture 2d due to size/format constraints"
might be the root cause here. We've had similar Shell crashes in the past,
but I don't know what caused them.

There's also some wrong error-handling, unfortunately.

smcv

Bug#891799: openssl1.0: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Sebastian Andrzej Siewior]

On 2018-02-28 23:38:44 [+0100], Manuel A. Fernandez Montecelo wrote:
> Hello,
Hi,

> We need support in this package for RISC-V, to bootstrap the riscv64
> architecture.

Please be aware that we plan to get rid of this.

> I am attaching a patch that allowed me to cross-compile the package.  I am not
> completely sure if all of the options are the most correct or the best choice
> (more optimised), for example I used DES_RISC2 because the MIPS family uses
> those and it's probably the closest to RISC-V, so it's my best-guess.  But if
> you spot something fishy, please tell.

for the reason above I would care too much about this package on your
side. Make sure the test suite passes and you should be good.

> It would be great if you could include these changes and release a new version
> for unstable.

There should be a new upstream version this week. This change should be
part of it.

> If we can do something to speed-up this process, please let me/us know.

I do accept a bribe.

Sebastian

Bug#893767: qemu: Enable support for riscv64 targets

[Vagrant Cascadian]

On 2018-03-21, Vagrant Cascadian  wrote:
> Attached is a patch that enables the riscv64 targets for
> qemu-system-misc and qemu-user-static/qemu-user/qemu-binfmt.

I forgot to patch qemu-debootstrap:

diff --git a/debian/qemu-debootstrap b/debian/qemu-debootstrap
index 72d41b7fed..17c243eafc 100755
--- a/debian/qemu-debootstrap
+++ b/debian/qemu-debootstrap
@@ -134,7 +134,7 @@ fi
 
 qemu_arch=""
 case "$deb_arch" in
-  
alpha|arm|armeb|i386|m68k|mips|mipsel|mips64el|ppc64|sh4|sh4eb|sparc|sparc64|s390x)
+  
alpha|arm|armeb|i386|m68k|mips|mipsel|mips64el|ppc64|sh4|sh4eb|sparc|sparc64|s390x|riscv64)
 qemu_arch="$deb_arch"
   ;;
   amd64)


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#894143: bedops-doc: fails to upgrade from 'testing' - trying to overwrite /usr/share/doc/bedops/html/_downloads/Frequencies-DHSs.bed.starch.gz

[Andreas Beckmann]

Package: bedops-doc
Version: 2.4.32+dfsg-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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

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

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

  Selecting previously unselected package bedops-doc.
  Preparing to unpack .../bedops-doc_2.4.32+dfsg-1_all.deb ...
  Unpacking bedops-doc (2.4.32+dfsg-1) ...
  dpkg: error processing archive 
/var/cache/apt/archives/bedops-doc_2.4.32+dfsg-1_all.deb (--unpack):
   trying to overwrite 
'/usr/share/doc/bedops/html/_downloads/Frequencies-DHSs.bed.starch.gz', which 
is also in package bedops 2.4.26+dfsg-1
  Errors were encountered while processing:
   /var/cache/apt/archives/bedops-doc_2.4.32+dfsg-1_all.deb


cheers,

Andreas


bedops=2.4.26+dfsg-1_bedops-doc=2.4.32+dfsg-1.log.gz
Description: application/gzip

Bug#894144: libmutter-2.so.0: undefined symbol: glFramebufferTexture2D

[Christopher Sasarak]

Package: gnome-shell
Version: 3.28.0-1
Severity: important

Dear Maintainer,
I upgraded gnome-shell and found that GDM3 wouldn't display anything. I
installed lightdm to see if that would behave differently and was able
to login. Gnome's session started (empathy showed up) but with no
gnome-shell activity bar and the empathy window had no top-bar.

I looked at the log and it looks like there's a problem somewhere
between gnome-shell/libmutter. 

Mar 26 12:20:36 shelby org.gnome.Shell.desktop[1451]: /usr/bin/gnome-shell: 
symbol lookup error: /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined 
symbol: glFramebufferTexture2D
Mar 26 12:20:36 shelby gnome-session[1341]: gnome-session-binary[1341]: 
WARNING: App 'org.gnome.Shell.desktop' exited with code 127
Mar 26 12:20:36 shelby gnome-session-binary[1341]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 127
Mar 26 12:20:36 shelby org.gnome.Shell.desktop[1472]: /usr/bin/gnome-shell: 
symbol lookup error:
/usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined symbol: 
glFramebufferTexture2D
Mar 26 12:20:36 shelby gnome-session[1341]: gnome-session-binary[1341]: 
WARNING: App 'org.gnome.Shell.desktop' exited with code 127
Mar 26 12:20:36 shelby gnome-session[1341]: gnome-session-binary[1341]: 
WARNING: App 'org.gnome.Shell.desktop' respawning too quickly
Mar 26 12:20:36 shelby gnome-session-binary[1341]: WARNING: App 
'org.gnome.Shell.desktop' exited with code 127
Mar 26 12:20:36 shelby gnome-session-binary[1341]: Unrecoverable failure in 
required component org.gnome.Shell.desktop
Mar 26 12:20:36 shelby gnome-session-binary[1341]: WARNING: App 
'org.gnome.Shell.desktop' respawning too quickly
Mar 26 12:20:36 shelby gnome-session[1341]: Unable to init server: Could not 
connect: Connection refused
Mar 26 12:20:36 shelby gnome-session-f[1477]: Cannot open display:

This also happened inside a VirtualBox session, I will try to check my home 
machine which is not a virtual machine later tonight. To see if the same 
problem exists there.

-Chris

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

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

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.1-3
ii  evolution-data-server3.26.5-2
ii  gir1.2-accountsservice-1.0   0.6.45-1
ii  gir1.2-atspi-2.0 2.28.0-1
ii  gir1.2-freedesktop   1.56.0-2
ii  gir1.2-gcr-3 3.28.0-1
ii  gir1.2-gdesktopenums-3.0 3.28.0-1
ii  gir1.2-gdm-1.0   3.28.0-1
ii  gir1.2-geoclue-2.0   2.4.7-1
ii  gir1.2-glib-2.0  1.56.0-2
ii  gir1.2-gnomebluetooth-1.03.28.0-2
ii  gir1.2-gnomedesktop-3.0  3.28.0-1
ii  gir1.2-gtk-3.0   3.22.29-1
ii  gir1.2-gweather-3.0  3.28.0-2
ii  gir1.2-ibus-1.0  1.5.17-3
ii  gir1.2-mutter-2  3.28.0-2
ii  gir1.2-nm-1.01.10.6-2
ii  gir1.2-nma-1.0   1.8.10-2
ii  gir1.2-pango-1.0 1.40.14-1
ii  gir1.2-polkit-1.00.105-18
ii  gir1.2-rsvg-2.0  2.40.20-2
ii  gir1.2-soup-2.4  2.62.0-1
ii  gir1.2-upowerglib-1.00.99.7-2
ii  gjs  1.52.0-2
ii  gnome-backgrounds3.28.0-1
ii  gnome-settings-daemon3.28.0-1
ii  gnome-shell-common   3.28.0-1
ii  gsettings-desktop-schemas3.28.0-1
ii  libatk-bridge2.0-0   2.26.2-1
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-2
ii  libcairo21.15.10-1
ii  libcanberra-gtk3-0   0.30-6
ii  libcanberra0 0.30-6
ii  libcroco30.6.12-2
ii  libecal-1.2-19   3.26.5-2
ii  libedataserver-1.2-223.26.5-2
ii  libgcr-base-3-1  3.28.0-1
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libgirepository-1.0-11.56.0-2
ii  libgjs0g [libgjs0-libmozjs-52-0] 1.52.0-2
ii  libglib2.0-0 2.56.0-2
ii  libglib2.0-bin   2.56.0-2
ii  libgstreamer1.0-0

Bug#894142: galternatives: Cannot start

[Alexander Klaus]

Package: galternatives
Version: 0.92.2
Severity: important

When will start /usr/sbin/galternatives from root terminal, no reaction but 
with this traceback:

# /usr/sbin/galternatives
Traceback (most recent call last):
  File "/usr/sbin/galternatives", line 5, in 
runpy.run_module('galternatives', run_name='__main__', alter_sys=True)
  File "/usr/lib/python3.6/runpy.py", line 205, in run_module
return _run_module_code(code, init_globals, run_name, mod_spec)
  File "/usr/lib/python3.6/runpy.py", line 96, in _run_module_code
mod_name, mod_spec, pkg_name, script_name)
  File "/usr/lib/python3.6/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/galternatives/__main__.py", line 9, in 

from galternatives.app import GAlternativesApp
  File "/usr/lib/python3/dist-packages/galternatives/app.py", line 5, in 

from .gui import MainWindow, AboutDialog
  File "/usr/lib/python3/dist-packages/galternatives/gui.py", line 12, in 

from distutils import spawn
ImportError: cannot import name 'spawn'



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

Kernel: Linux 4.15.13-towo.1-siduction-amd64 (SMP w/4 CPU cores; PREEMPT)
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)

Versions of packages galternatives depends on:
ii  gir1.2-gtk-3.0  3.22.29-2
ii  python3 3.6.5~rc1-1
ii  python3-gi  3.28.1-1

Versions of packages galternatives recommends:
ii  policykit-1  0.112-5.3.1~really-0.105-8
ii  python3-xdg  0.25-4

galternatives suggests no packages.

-- no debconf information

Bug#894068: ocrmypdf: New dependency on PyMuPDF for v6.0.0

[James R Barlow]

Thanks for the information. That's a worryingly high wall to climb and I'm
concerned about implications for other platforms as well.

I would appreciate if you can see about getting an exception, but I think I
will change PyMuPDF to an optional but recommended dependency fairly soon.
I haven't made a major investment in it as yet with new code, but it does
provide some powerful features that would be a major engineering effort to
replicate and are likely not going to materialize in another open source
library anytime soon. (Specifically: incremental updates, safe editing of
PDF/A, PDF object garbage collection, fast rasterizing, robust text
extraction.) The most commonly used Python PDF library, PyPDF2, is
essentially unmaintained and in poor shape.


On Mon, 26 Mar 2018 at 10:32 Sean Whitton  wrote:

> control: reassign -1 wnpp
> control: forcemerge 841404 -1
>
> Dear James,
>
> On Mon, Mar 26 2018, James R. Barlow wrote:
>
> > In v6.0.0, which addresses and hopefully fixes #888917, I have
> introduced a
> > new dependency on PyMuPDF (Python bindings for MuPDF).  Unfortunately
> PyMuPDF
> > isn't available in Debian as yet (I have checked there is no
> python3-pymupdf).
>
> Thank you for working on that bug!
>
> > The build procedure should go like this:
> >
> >   - download/unpack MuPDF to mupdf/
> >   - download/unpar PyMuPDF to pymupdf/
> >   - cp pymupdf/fitz/_mupdf_config.h mupdf/include/mupdf/fitz/config.h
> >   - export CFLAGS=-fPIC
> >   - make HAVE_X11=no HAVE_GLFW=no HAVE_GLUT=no
> >   - patch pymupdf/setup.py to point library_dirs and include_dirs to the
> > output of mupdf/ build
> >
> > The reason for this circumlocution is that the vendor of MuPDF, Artifex,
> > does not provide or support dynamic libraries or a stable ABI, and
> > compiling the Python bindings requires a dynamic library.  Perhaps as a
> way
> > to warn people about their stance, they don't enable -fPIC by default and
> > link their application statically.
> >
> > This means that unfortunately, one cannot link to libmupdf-dev (and
> > actually, I'm not sure if libmupdf-dev serves any purpose at all, unless
> > it were rebuilt with -fPIC).  Certainly if the maintainers of this
> > package could be persuaded to build it with -fPIC that would make this
> > much easier.
> >
> > I did try to build with it with Debian sid against the libmupdf-dev
> > library. The error, as with Ubuntu, is:
> >   relocation R_X86_64_PC32 against symbol `fz_empty_irect' can not be
> > used when making a shared object; recompile with -fPIC
>
> If we followed this build procedure then there would be two copies of
> mupdf in Debian: in the mupdf package and in the pymypdf package.  This
> is disallowed by Debian Policy 4.13 because it makes it harder to apply
> security updates.  And for any libraries that read PDFs, security is a
> real concern (see the mupdf bug list: there have been several CVEs).
>
> Further, Policy 10.2 explicitly forbids building static libraries with
> -fPIC, unless an exception thought warranted in discussion on our main
> development mailing list.
>
> I think this might be a case where we can argue for that exception, but
> I'm going to need to do some reading before I can be sure that that's
> what we should do.  So unfortunately OCRmyPDF is probably going to be
> out-of-date in Debian for a while.
>
> > I'm happy to help with the packaging of this dependency, and I got it the
> > process working for Python binary wheels already.  However, I don't
> really
> > know much about Debian processes and policy.
>
> Thanks.  The best place to start would probably be our libraries policy,
> section 10.2 of Debian Policy.[1]  And the following relevant bugs:
> #617253, #719351, #841403.
>
> [1]  https://www.debian.org/doc/debian-policy/
>
> --
> Sean Whitton
>

Bug#893488: gnome-shell 3.27.92 and 3.28 always crash on start

[Simon McVittie]

On Mon, 26 Mar 2018 at 12:48:08 -0400, Christopher Sasarak wrote:
> I upgraded gnome-shell and found that GDM3 wouldn't display anything.
...
> I looked at the log and it looks like there's a problem somewhere
> between gnome-shell/libmutter. 
> 
> Mar 26 12:20:36 shelby org.gnome.Shell.desktop[1451]: /usr/bin/gnome-shell: 
> symbol lookup error: /usr/lib/x86_64-linux-gnu/libmutter-2.so.0: undefined 
> symbol: glFramebufferTexture2D
...
>  I'm not sure if this is the same bug as the original one, but it seems 
> similar/related.

This looks different to me. Please open a separate bug, and mention
"libmutter-2.so.0: undefined symbol: glFramebufferTexture2D" in the
bug's subject.

(I don't know a solution to either of these crashes.)

smcv

Bug#607178: ioquake3-server: Seg fault caused by code/botlib/be_aas_route.c:1860

[pbrochart]

Hi,

I had reproduce this bug with the same map oa_dm1 on FreeBSD.
Now it's fixed for me with i suppose this commit on official github
repository:

https://github.com/ioquake/ioq3/commi/fc16ac6bd2d05cba8a2d057994b097e95bae28a0

Now, the server running since two months without crashing.

Regards,
Pascal

Bug#894141: f3 FTCBFS: uses the build architecture compiler for the extra build

[Helmut Grohne]

Source: f3
Version: 7.0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

f3 fails to cross build from source, because it does not pass cross
compilers to "make extra". Using dh_auto_build, f3 cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru f3-7.0/debian/changelog f3-7.0/debian/changelog
--- f3-7.0/debian/changelog 2018-01-06 16:08:16.0 +0100
+++ f3-7.0/debian/changelog 2018-03-26 20:31:02.0 +0200
@@ -1,3 +1,10 @@
+f3 (7.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 26 Mar 2018 20:31:02 +0200
+
 f3 (7.0-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru f3-7.0/debian/rules f3-7.0/debian/rules
--- f3-7.0/debian/rules 2018-01-06 16:08:16.0 +0100
+++ f3-7.0/debian/rules 2018-03-26 20:31:00.0 +0200
@@ -8,7 +8,7 @@
 
 override_dh_auto_build:
dh_auto_build
-   $(MAKE) extra
+   dh_auto_build -- extra
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr

Bug#894140: perl: Stack Exhaustion in current perl stable

[Dongliang Mu]

Package: perl
Version: 5.26.1-5
Severity: normal
Tags: upstream

A stack exhaustion issue was discovered in Perl 5.26.1. Stack Exhaustion occurs
in checking regular expression for a "()" pair. When Perl interprets one "(",
it will allocate four stack frames (S_reg, S_regbranch, S_regpiece, S_regatom).
If the next character is still '(' other than ')', it will continue to allocate
four stack frames the stack trace. When there are over 3314 '(', it will
segment fault and crash.

The stack trace for the crash is as follows,

Program received signal SIGSEGV, Segmentation fault.
0x005d005b in S_reg (pRExC_state=0x7fffd5c0, paren=2,
flagp=0x7f7ff3a0,
depth=) at regcomp.c:10574
10574   {
(gdb) info stack
#0  0x005d005b in S_reg (pRExC_state=0x7fffd5c0, paren=2,
flagp=0x7f7ff3a0,
depth=) at regcomp.c:10574
#1  0x0061ebc0 in S_regatom (pRExC_state=0x7fffd5c0,
flagp=0x7f7ff7a0,
depth=) at regcomp.c:12565
#2  0x005fde20 in S_regpiece (pRExC_state=,
flagp=,
depth=) at regcomp.c:11669
#3  S_regbranch (pRExC_state=, flagp=0x7f7ff9a0,
first=,
depth=) at regcomp.c:11594
#4  0x005d3476 in S_reg (pRExC_state=,
paren=,
flagp=0x7f7ffd80,
depth=) at regcomp.c:11332
#5  0x0061ebc0 in S_regatom (pRExC_state=0x7fffd5c0,
flagp=0x7f800180,
depth=) at regcomp.c:12565
#6  0x005fde20 in S_regpiece (pRExC_state=,
flagp=,
depth=) at regcomp.c:11669
#7  S_regbranch (pRExC_state=, flagp=0x7f800380,
first=,
depth=) at regcomp.c:11594
#8  0x005d3476 in S_reg (pRExC_state=,
paren=,
flagp=0x7f800760,
depth=) at regcomp.c:11332
#9  0x0061ebc0 in S_regatom (pRExC_state=0x7fffd5c0,
flagp=0x7f800b60,
depth=) at regcomp.c:12565
#10 0x005fde20 in S_regpiece (pRExC_state=,
flagp=,
depth=) at regcomp.c:11669
..



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

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

Versions of packages perl depends on:
ii  dpkg   1.19.0.5
ii  libperl5.265.26.1-5
ii  perl-base  5.26.1-5
ii  perl-modules-5.26  5.26.1-5

Versions of packages perl recommends:
ii  netbase  5.4

Versions of packages perl suggests:
pn  libterm-readline-gnu-perl | libterm-readline-perl-perl  
ii  make4.1-9.1
pn  perl-doc

-- no debconf information

Bug#891721: Upload coming soon

[Scott Kitterman]

There are a few changes that still need merged for the next upload.  It would 
be better to include those and upload once.  No need to autoremove now though.

Scott K