Bug#873012: not working live migration in qemu ( vm's block storage is LVM )

[Andreas Herrmann]

Live migration with local storage (ZFS) is working again in testing.

libvirt-clients3.0.0-4+deb9u1
libvirt-daemon 3.0.0-4+deb9u1
libvirt-daemon-system  3.0.0-4+deb9u1
libvirt0   3.0.0-4+deb9u1
qemu-kvm   1:2.10.0+dfsg-2
qemu-system-common 1:2.10.0+dfsg-2
qemu-system-x861:2.10.0+dfsg-2

Bug#882743: Debian mirror ftp.cica.es: upstream mirror, large arch exclude list, ftpsync version

[Soporte CICA]

El 14/12/17 a las 07:34, Bastian Blank escribió:

It looks like this is fixed.

As your mirror is not pushed, please use the ftpsync-cron wrapper script
(or at least adjust the frequency to match the master at four times a
day).

Regards,
Bastian


Hi Bastian,

We have configured ftpsync-cron script in CICA FTP servers and we have 
recently adjusted the check frequency to 15 minutes.


Greetings.

--
Ignacio Bocanegra Gondán
Administrador de Sistemas y Supercomputación

Servicio de Operación de Sistemas y Redes para el CICA
Centro Informático Científico de Andalucía
AV. Reina Mercedes S/N , Edificio CICA, 41012 Sevilla.
Teléfono: 955 130 384

Bug#884116: linux-image-4.9.0-4-amd64: Similar artefacts with the following crash when I try to play a movie audio channel throwgh HDMI.

[Warlock]

Package: src:linux
Version: 4.9.65-3
Followup-For: Bug #884116

Dear Maintainer,

I have a similar issue with the artefacts (but without a following crash) when 
I switch between virtual desktops with a VLC player opened on one of them.

And I have such artefacts _with_ the following crash when I connect HDMI cable 
and try to play a movie audio channel through HDMI.

-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: Dell Inc.
product_name: Latitude 3560
product_version: 
chassis_vendor: Dell Inc.
chassis_version: 
bios_vendor: Dell Inc.
bios_version: A02
board_vendor: Dell Inc.
board_name: 08T86W
board_version: A00

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Broadwell-U Host Bridge -OPI 
[8086:1604] (rev 09)
Subsystem: Dell Broadwell-U Host Bridge -OPI [1028:06f1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: bdw_uncore

00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 5500 
[8086:1616] (rev 09) (prog-if 00 [VGA controller])
Subsystem: Dell HD Graphics 5500 [1028:06f1]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915
Kernel modules: i915

00:03.0 Audio device [0403]: Intel Corporation Broadwell-U Audio Controller 
[8086:160c] (rev 09)
Subsystem: Dell Broadwell-U Audio Controller [1028:06f1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:14.0 USB controller [0c03]: Intel Corporation Wildcat Point-LP USB xHCI 
Controller [8086:9cb1] (rev 03) (prog-if 30 [XHCI])
Subsystem: Dell Wildcat Point-LP USB xHCI Controller [1028:06f1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation Wildcat Point-LP MEI 
Controller #1 [8086:9cba] (rev 03)
Subsystem: Dell Wildcat Point-LP MEI Controller [1028:06f1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1b.0 Audio device [0403]: Intel Corporation Wildcat Point-LP High Definition 
Audio Controller [8086:9ca0] (rev 03)
Subsystem: Dell Wildcat Point-LP High Definition Audio Controller 
[1028:06f1]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #1 [8086:9c90] (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.2 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #3 [8086:9c94] (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.3 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #4 [8086:9c96] (rev e3) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:1c.4 PCI bridge [0604]: Intel Corporation Wildcat Point-LP PCI Express Root 
Port #5 [8086:9c98] (rev e3) 

Bug#884003: FDT overlay support

[Andre Heider]

The patches need a bit more work.

But before I do that, I'd like some feedback if this would be 
desirable/acceptable at all.


Let me know what you think,
Andre

Bug#884757: getmail: version 5.5 available upstream

[Daniel Kahn Gillmor]

Package: getmail
Version: 5.4-2
Severity: wishlist

version 5.5 of getmail was just released upstream.  it would be great
to have it in debian unstable, since it resolves #833190.

Thanks for your work packaging getmail for debian!

   --dkg

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

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

Versions of packages getmail depends on:
ii  python  2.7.14-3

getmail recommends no packages.

getmail suggests no packages.

Bug#884756: cacti can not install missing dependency

[ISHIKAWA Mutsumi]

Package: cacti
Version: 1.1.28+ds1-2
Severity: grave

cacti depends libjs-jquery-colorpicker (<< 1.2.13.0~) and
libjs-jquery-colorpicker (>= 1.2.13).

But currently only available libjs-jquery-colorpicker_1.2.14-1 on sid.

So, cacti can not install.

-- 
ISHIKAWA Mutsumi
  , 

Bug#884752: [Pkg-ime-devel] Bug#884752: RFS: fcitx-skk/0.1.4-0.2 [NMU]

[Aron Xu]

Please don't update for only a maintainer change, it's kinda a waste
of resource.


-- 
Regards,
Aron Xu

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Michael Biebl]

Am 19.12.2017 um 02:18 schrieb Martin-Éric Racine:
> 2017-12-19 2:02 GMT+02:00 Michael Biebl :
>> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
>>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
 Hi,

 I just uploaded v236 today. Before we try to debug this further, it
 would be great if you can give this version a try. Maybe your issue is
 already fixed.
 If not, we'll have to involve upstream at some point by filing an
 upstream bug report. But let's first wait for your results with 236-1
>>>
>>> The issue is not fixed. Something fails at communicating with dbus,
>>> and it messes up everything else.
>>
>> Just to be sure, have you rebooted your system after upgrading to 236-1?
> 
> Yes I have, but this required issuing "exec reboot -f" to bypass init
> entirely, otherwise it fails due to the lack of dbus connection.

Sure, if PID 1 has crashed, it will freeze itself and no longer respond
to any (D-Bus) requests.

When exactly does systemd crash? Is it immediately during boot or after
you've been using the system for a while?
I assume it works at least for a while, otherwise no other services
would be started and you would not be able to log in.
When systemd crashes, you should get an entry in the kernel log (dmesg)
respectively the journal.

It would be great if you can follow the instructions at [1] to boot with
debug logging enabled and then provide a journal log which shows such a
crash.


Michael

[1] https://freedesktop.org/wiki/Software/systemd/Debugging/
-- 
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#883922: sandykseven,your recent order48183

[Sandy Drinkwater]

I don't understand thisWhat is the Amazon offer? It says "recent order
48183
What does this mean?

On Sat, Dec 9, 2017 at 10:00 AM, AmazonOffer  wrote:

> we would like to Thankyou
>
>
> 
>
>
> 
>
>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Your message dated Sat, 09 Dec 2017 15:58:31 + with message-id and
> subject line Bug#883922: fixed in evolution-data-server 3.26.2.1-1.1 has
> caused the Debian Bug report #883922, regarding libical3-dev: libical-dev
> provides should be versioned to be marked as done. This means that you
> claim that the problem has been dealt with. If this is not the case it is
> now your responsibility to reopen the Bug report if necessary, and/or fix
> the problem forthwith. (NB: If you are a system administrator and have no
> idea what this message is talking about, this may indicate a serious mail
> system misconfiguration somewhere. Please contact ow...@bugs.debian.org
> immediately.) -- 883922: 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=883922
> Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
>
> -- Forwarded message --
> From: Matthias Klose 
> To: Debian Bug Tracking System 
> Cc:
> Bcc:
> Date: Sat, 9 Dec 2017 13:23:25 +0100
> Subject: fix dependencies for libical3
> Package: src:evolution-data-server
> Version: 3.26.2.1
> Severity: serious
> Tags: sid buster patch
>
> please fix the (build)dependencies for libical3, by either dropping the
> versioned libical-dev dependency, or by introducing an alternative
> libical3-dev
> dependency.
>
>
>
>
> -- Forwarded message --
> From: Matthias Klose 
> To: 883922-cl...@bugs.debian.org
> Cc:
> Bcc:
> Date: Sat, 09 Dec 2017 15:58:31 +
> Subject: Bug#883922: fixed in evolution-data-server 3.26.2.1-1.1
> Source: evolution-data-server
> Source-Version: 3.26.2.1-1.1
>
> We believe that the bug you reported is fixed in the latest version of
> evolution-data-server, which is due to be installed in the Debian FTP
> archive.
>
> A summary of the changes between this version and the previous one is
> attached.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 883...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Debian distribution maintenance software
> pp.
> Matthias Klose  (supplier of updated
> evolution-data-server package)
>
> (This message was generated automatically at their request; if you
> believe that there is a problem with it please contact the archive
> administrators by mailing ftpmas...@ftp-master.debian.org)
>
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Format: 1.8
> Date: Sat, 09 Dec 2017 13:52:27 +0100
> Source: evolution-data-server
> Binary: evolution-data-server evolution-data-server-common
> evolution-data-server-tests evolution-data-server-dev
> evolution-data-server-doc libedataserver-1.2-22 libedataserver1.2-dev
> gir1.2-edataserver-1.2 libedataserverui-1.2-1 libedataserverui1.2-dev
> gir1.2-edataserverui-1.2 libcamel-1.2-60 libcamel1.2-dev gir1.2-camel-1.2
> libebook-1.2-19 libebook1.2-dev gir1.2-ebook-1.2 libedata-book-1.2-25
> libedata-book1.2-dev gir1.2-ebookcontacts-1.2 libebook-contacts-1.2-2
> libebook-contacts1.2-dev libecal-1.2-19 libecal1.2-dev libedata-cal-1.2-28
> libedata-cal1.2-dev libebackend-1.2-10 libebackend1.2-dev
> Architecture: source
> Version: 3.26.2.1-1.1
> Distribution: unstable
> Urgency: medium
> Maintainer: Debian Evolution Maintainers  lists.alioth.debian.org>
> Changed-By: Matthias Klose 
> Description:
>  evolution-data-server - evolution database backend server
>  evolution-data-server-common - architecture independent files for
> Evolution Data Server
>  evolution-data-server-dev - Development files for evolution-data-server
> (metapackage)
>  evolution-data-server-doc - Documentation files for the Evolution Data
> Server libraries
>  evolution-data-server-tests - Installed tests for the evolution database
> backend server
>  gir1.2-camel-1.2 - GObject introspection for the Camel library
>  gir1.2-ebook-1.2 - GObject introspection for the EBook library
>  gir1.2-ebookcontacts-1.2 - GObject introspection for the EBook Contacts
> library
>  gir1.2-edataserver-1.2 - GObject introspection for the EDataServer library
>  gir1.2-edataserverui-1.2 - GObject introspection for the EDataServerUI
> library
>  libcamel-1.2-60 - Evolution MIME message handling library
>  libcamel1.2-dev - Development files for libcamel
>  libebackend-1.2-10 

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Michael Biebl]

Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>> Hi,
>>
>> I just uploaded v236 today. Before we try to debug this further, it
>> would be great if you can give this version a try. Maybe your issue is
>> already fixed.
>> If not, we'll have to involve upstream at some point by filing an
>> upstream bug report. But let's first wait for your results with 236-1
> 
> The issue is not fixed. Something fails at communicating with dbus,
> and it messes up everything else.
> 
> Googling up the issue, I found this:
> 
> https://answers.launchpad.net/ubuntu/+source/systemd/+question/287454
> 
> As to whether this is the exact issue we're seeing, I wouldn't know.
> 

I don't think this is related. The issue above talks above the systemd
--user instance. Your issue seems to be about systemd PID 1 crashing.


-- 
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#884754: bls: detect dpkg-gencontrol: warning: unused/unknown substitution variable

[Paul Wise]

Package: qa.debian.org
Severity: wishlist
User: qa.debian@packages.debian.org 
Usertags: bls
Control: clone -1 -2
Control: reassign -2 bls-standalone

It would be nice to warn about present but unused or used but unknown
dpkg-gencontrol substitution variables. Here is an example of these:

https://buildd.debian.org/status/fetch.php?pkg=python-backports-shutil-get-terminal-size=all=1.0.0-3=1469703308=0

dpkg-gencontrol: warning: Depends field of package 
python-backports-shutil-get-terminal-size: unknown substitution variable 
${python-Depends}
dpkg-gencontrol: warning: package python-backports-shutil-get-terminal-size: 
unused substitution variable ${python:Versions}
dpkg-gencontrol: warning: package python-backports-shutil-get-terminal-size: 
unused substitution variable ${python:Depends}
dpkg-gencontrol: warning: package python-backports-shutil-get-terminal-size: 
unused substitution variable ${python:Provides}

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#884753: virt-sandbox: crash (SIGSEGV) when starting two instances at the same time

[Paul Wise]

Package: virt-sandbox
Version: 0.5.1+git20160404-1
Severity: normal
Usertags: crash

When I start two instances of virt-sandbox at the same time, the second
one of them crashes and the first one gets an error. The error message
is different depending on how long the second one waits to start. It
seems like each instance is using shared resources but shouldn't be.

pabs@chianamo ~ $ virt-sandbox echo true & virt-sandbox echo false &
[1] 22705
[2] 22706
pabs@chianamo ~ $ 
[2]+  Segmentation fault  (core dumped) virt-sandbox echo false
pabs@chianamo ~ $ 

[1]+  Stopped virt-sandbox echo true
pabs@chianamo ~ $ 
pabs@chianamo ~ $ fg
virt-sandbox echo true
Unable to attach sandbox console: Unable to open console: Domain not found: no 
domain with matching uuid '85f03b0f-e936-42d6-bb26-9ba1bd1a80e5' (sandbox)
pabs@chianamo ~ $ find /var/crash/ -ls
  1316655  4 drwxrwxrwt   4 root root 4096 Dec  4 13:40 
/var/crash/
  1341853  4 drwx--   2 pabs root 4096 Dec 19 13:11 
/var/crash/1000
  1315542  19132 -rw---   1 pabs pabs  19591168 Dec 19 13:11 
/var/crash/1000/22706-1000-1000-11-1513660305-chianamo--usr-bin-virt-sandbox.core
$ gdb -batch -n -ex 'set pagination off' -ex bt -ex 'thread apply all bt full' 
--core 
/var/crash/1000/22706-1000-1000-11-1513660305-chianamo--usr-bin-virt-sandbox.core
 /usr/bin/virt-sandbox
[New LWP 22706]
[New LWP 22750]
[New LWP 22752]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `virt-sandbox echo false'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  gvir_sandbox_builder_clean_post_stop (builder=builder@entry=0x55705395ec20, 
config=config@entry=0x55705395d8d0, statedir=statedir@entry=0x55705398bb40 
"/home/pabs/.cache/libvirt-sandbox/sandbox", error=error@entry=0x0) at 
libvirt-sandbox-builder.c:753
753 libvirt-sandbox-builder.c: No such file or directory.
[Current thread is 1 (Thread 0x7fdefeae5f80 (LWP 22706))]
#0  0x7fdefcfee3b0 in gvir_sandbox_builder_clean_post_stop 
(builder=builder@entry=0x55705395ec20 [GVirSandboxBuilderMachine], 
config=config@entry=0x55705395d8d0 [GVirSandboxConfigInteractive], 
statedir=statedir@entry=0x55705398bb40 
"/home/pabs/.cache/libvirt-sandbox/sandbox", error=error@entry=0x0) at 
libvirt-sandbox-builder.c:753
#1  0x7fdefcff5c8b in gvir_sandbox_context_clean_post_stop 
(ctxt=ctxt@entry=0x5570539450f0 [GVirSandboxContextInteractive], 
builder=builder@entry=0x55705395ec20 [GVirSandboxBuilderMachine], 
error=error@entry=0x0) at libvirt-sandbox-context-interactive.c:166
#2  0x7fdefcff616a in gvir_sandbox_context_interactive_start 
(ctxt=0x5570539450f0 [GVirSandboxContextInteractive], error=0x7ffe394c9320) at 
libvirt-sandbox-context-interactive.c:282
#3  0x557051818949 in main (argc=, argv=) at 
virt-sandbox.c:282

Thread 3 (Thread 0x7fdef0e79700 (LWP 22752)):
#0  0x7fdefcb04a5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fdefdbfc119 in g_main_context_poll (priority=, 
n_fds=2, fds=0x557053975900, timeout=, context=0x557053979bc0) 
at ../../../../glib/gmain.c:4187
ret = 
errsv = 
poll_func = 0x7fdefdc0b610 
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x557053975900
#2  0x7fdefdbfc119 in g_main_context_iterate (context=0x557053979bc0, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../../glib/gmain.c:3881
max_priority = 2147483647
timeout = -1
some_ready = 
nfds = 2
allocated_nfds = 2
fds = 0x557053975900
#3  0x7fdefdbfc4b2 in g_main_loop_run (loop=0x55705397aec0) at 
../../../../glib/gmain.c:4082
__func__ = "g_main_loop_run"
#4  0x7fdefe428ad6 in gdbus_shared_thread_func (user_data=0x557053979b90) 
at ../../../../gio/gdbusprivate.c:275
data = 0x557053979b90
#5  0x7fdefdc235f5 in g_thread_proxy (data=0x55705395ecf0) at 
../../../../glib/gthread.c:784
thread = 0x55705395ecf0
#6  0x7fdefcdcc519 in start_thread (arg=0x7fdef0e79700) at 
pthread_create.c:456
__res = 
pd = 0x7fdef0e79700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140595501176576, 
5740434195331275689, 140729859738366, 140729859738367, 140595716830624, 
140595501176576, -5757852451810452567, -5757878765191570519}, mask_was_saved = 
0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, 
canceltype = 0}}}
not_first_call = 
#7  0x7fdefcb0ea4f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:97

Thread 2 (Thread 0x7fdef167a700 (LWP 22750)):
#0  0x7fdefcb04a5d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fdefdbfc119 in g_main_context_poll (priority=, 
n_fds=1, fds=0x557053968230, timeout=, context=0x557053968460) 
at ../../../../glib/gmain.c:4187

Bug#884752: RFS: fcitx-skk/0.1.4-0.2 [NMU]

[Boyuan Yang]

Package: sponsorship-requests
Severity: normal
X-Debbugs-CC: pkg-ime-de...@lists.alioth.debian.org yyat...@debian.or.jp 
d...@debian.org

Dear mentors,

I am looking for a sponsor for package "fcitx-skk" as an NMU.

This NMU would move package fcitx-skk under pkg-ime team. It has been approved 
by its original maintainer, see [1].

[1] 
https://lists.alioth.debian.org/pipermail/pkg-ime-devel/2017-December/006719.html

 * Package name: fcitx-skk
   Version : 0.1.4-0.2
   Upstream Author : Weng Xuetian 
 * URL : https://github.com/fcitx/fcitx-skk
 * License : GPL-2+
   Section : utils

  It builds those binary packages:

fcitx-skk  - Japanese SKK input engine for Fcitx

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

  https://mentors.debian.net/package/fcitx-skk


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/fcitx-skk/fcitx-skk_0.1.4-0.2.dsc

  Git packaging repository:

http://anonscm.debian.org/git/collab-maint/fcitx-skk.git

  Plain diff:

commit 0e217f89ece547c5c00857a1eb6d9cb21aa82091
Author: Boyuan Yang <073p...@gmail.com>
Date:   Mon Dec 18 19:28:48 2017 +0800

debian: Prepare NMU to switch pkg into pkg-ime team

diff --git a/debian/changelog b/debian/changelog
index bbdaf6d..f7ee608 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+fcitx-skk (0.1.4-0.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Put package into pkg-ime team with maintainer's approval.
+
+ -- Boyuan Yang <073p...@gmail.com>  Mon, 18 Dec 2017 19:27:51 +0800
+
 fcitx-skk (0.1.4-0.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/control b/debian/control
index 4f75f3d..dd0b1c3 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,9 @@
 Source: fcitx-skk
 Section: utils
 Priority: optional
-Maintainer: Yusuke YATSUO 
+Maintainer: IME Packaging Team 
+Uploaders:
+ Yusuke YATSUO ,
 Build-Depends: cmake,
debhelper (>= 9),
fcitx-bin (>= 1:4.2.6),

  Changes since the last upload:

fcitx-skk (0.1.4-0.2) unstable; urgency=medium

  * Non-maintainer upload.
  * Put package into pkg-ime team with maintainer's approval.

 -- Boyuan Yang <073p...@gmail.com>  Mon, 18 Dec 2017 19:27:51 +0800

Regards,
Boyuan Yang

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

Bug#884751: RM: kscope -- RoQA; Dead upstream, Unmaintained in Debian, Qt4 unported, FTBFS with new QScintilla2

[Scott Kitterman]

Package: ftp.debian.org
Severity: normal

No one has touched this package since I fixed it FTBFS'ing in 2011.  It's
dead upstream, so it'll have to go with Qt4.  We should go ahead and remove it
now to move it out of the way of the QSCintilla2 transition.  While it's easy
enough to fix for this transition, it's not worth even the minimal effort.

Scott K

Bug#884741: sudo-ldap: Lacking support for SSSD

[Bdale Garbee]

Thore  writes:

> Package: sudo-ldap
> Version: 1.8.19p1-2.1
> Severity: wishlist
>
> Good evening,
> while trying to integrate SSSD for LDAP authentication the sudo provider
> constantly failed.
> After a while of searching for a reason I came across this:
>
> sudo -V
> Sudo version 1.8.19p1
> Configure options: --prefix=/usr -v --with-all-insults --with-pam
> --with-ldap --with-fqdn --with-logging=syslog --with-logfac=authpriv
> --with-env-editor --with-editor=/usr/bin/editor
> --with-exampledir=/usr/share/doc/sudo-ldap/examples --with-timeout=15
> --with-password-timeout=0 --with-passprompt=[sudo] password for %p:
> --disable-root-mailer --disable-setresuid
> --with-sendmail=/usr/sbin/sendmail --with-rundir=/var/lib/sudo
> --with-ldap-conf-file=/etc/sudo-ldap.conf --mandir=/usr/share/man
> --libexecdir=/usr/lib/sudo --with-selinux --with-linux-audit
>
>
> It's simply not compiled with support for sssd. Would it be possible to
> ship the package build with the `--with-sssd` flag?

Oh, I see, I added the sssd support options to the sudo package, but
not to the sudo-ldap package.  Easy enough to add it to the sudo-ldap
package too.  Thanks for pointing this out!

Bdale


signature.asc
Description: PGP signature

Bug#764636: Badblocks does not support large disks

[Matt Taggart]

There is a similar bug in Red Hat Bugzilla,

https://bugzilla.redhat.com/show_bug.cgi?id=1306522

which is "CLOSED WONTFIX" and indicates that upstream doesn't support 
badblocks on large devices (maybe doesn't support badblocks at all?)


Maybe #76636 should do the same?

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

Bug#884750: happy: stage1 build profile FTBFS

[Daniel Schepler]

Source: happy
Version: 1.19.8-1
Severity: normal

>From my pbuilder build log, trying to bootstrap the package with a
tsage1 build profile:

...
 fakeroot debian/rules clean
CDBS WARNING:  copyright-check disabled - touch debian/copyright_hints
to enable.
test -x debian/rules
cp -a dist/build/happy/happy-tmp/*.hs src/
cp: cannot stat 'dist/build/happy/happy-tmp/*.hs': No such file or directory
debian/rules:20: recipe for target 'cleanbuilddir/happy' failed
make: *** [cleanbuilddir/happy] Error 1
dpkg-buildpackage: error: fakeroot debian/rules clean subprocess
returned exit status 2
-- 
Daniel Schepler

Bug#884094: Impact on NFS shared

[Ben Hutchings]

On Mon, 2017-12-18 at 13:18 +0100, Louis Chanouha wrote:
> Here are the results:
> 
> root@xxx:~# uname -v
> #1 SMP Debian 4.9.51-1 (2017-09-28)

So you are running the old kernel version...

> root@xxx:~# dpkg -l linux-image-4.9.0-4-amd64
> ii  linux-image-4.9.0-4-amd644.9.65-3 
>amd64   Linux 4.9 for 64-bit PCs

...and the new kernel and modules are installed...

> root@video-test:~# debsums -c linux-image-4.9.0-4-amd64
> /boot/System.map-4.9.0-4-amd64
> /boot/config-4.9.0-4-amd64
> /boot/vmlinuz-4.9.0-4-amd64
[...]

...but /boot doesn't match what was in the package.

So you still have files from the old package in /boot.  Perhaps you
changed which device is used as /boot at some point.

Anyway, if the kernel isn't properly installed that's not a kernel bug.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#884641: ITP: lwip -- small implementation of the TCP/IP protocol suite

[Ben Hutchings]

On Mon, 2017-12-18 at 01:44 +0100, Samuel Thibault wrote:
> Ben Hutchings, on lun. 18 déc. 2017 00:37:48 +, wrote:
> > On Mon, 2017-12-18 at 00:12 +0100, Samuel Thibault wrote:
> > > It can be used as a maintained user-land TCP/IP stack.
> > 
> > Why would this be useful for Debian systems, which already have a much
> > better performing TCP/IP stack?
> 
> But the kernel-provided stack can't be manipulated by userland for
> e.g. VPNs, ppp, etc. without having to be root.
[...]

Not quite.  On Linux you need CAP_NET_ADMIN in some user namespace.  To
use lwip you would presumably need raw access to a network device,
which also requires a privileged capability.

If you enable unprivileged user namespaces in Linux then any user is
allowed to create a new user namespace, and a net namespace owned by
it, and then to create and configure various kinds of virtual device
within that net namespace.  (In Debian this feature is guarded by a
sysctl that's off by default, as a security mitigation.)

Even if that's disabled, a privileged container manager can create a
new user namespace and start a container within that namespace with the
CAP_NET_ADMIN capability.

Ben.

-- 
Ben Hutchings
73.46% of all statistics are made up.



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

Bug#884749: plasma-workspace: ksmserver-logout-greeter crashes stopping shutdown

[Harrison Metzger]

Package: plasma-workspace
Version: 4:5.10.5-2+b1
Severity: normal

Dear Maintainer,

I was attempting to logout to reboot my computer and
ksmserver-logout-greeter crashed. This stopped shtudown and KDE seems
where I left it. Here is the backtrace after installing the dbg
packages:

Application: ksmserver-logout-greeter (ksmserver-logout-greeter), signal: 
Aborted
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f33a43c6940 (LWP 22085))]

Thread 4 (Thread 0x7f3389ed0700 (LWP 22088)):
#0  0x7f339fce4a6d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f33988d2119 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f33988d222c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f33a060710b in QEventDispatcherGlib::processEvents 
(this=0x7f3388c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7f33a05ac2aa in QEventLoop::exec (this=this@entry=0x7f3389ecfc40, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x7f33a03cb35a in QThread::exec (this=this@entry=0x55f2fbb2f190) at 
thread/qthread.cpp:515
#6  0x7f33a25ce0a5 in QQmlThreadPrivate::run (this=0x55f2fbb2f190) at 
qml/ftw/qqmlthread.cpp:147
#7  0x7f33a03d022d in QThreadPrivate::start (arg=0x55f2fbb2f190) at 
thread/qthread_unix.cpp:368
#8  0x7f339a8ce519 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f339fceea5f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 3 (Thread 0x7f338a6d1700 (LWP 22087)):
#0  0x7f339fce4a6d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f33988d2119 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x7f33988d222c in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f33a060710b in QEventDispatcherGlib::processEvents 
(this=0x7f337c0008c0, flags=...) at kernel/qeventdispatcher_glib.cpp:425
#4  0x7f33a05ac2aa in QEventLoop::exec (this=this@entry=0x7f338a6d0c30, 
flags=..., flags@entry=...) at kernel/qeventloop.cpp:212
#5  0x7f33a03cb35a in QThread::exec (this=) at 
thread/qthread.cpp:515
#6  0x7f33a118ae45 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7f33a03d022d in QThreadPrivate::start (arg=0x7f33a13fdd60) at 
thread/qthread_unix.cpp:368
#8  0x7f339a8ce519 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f339fceea5f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 2 (Thread 0x7f338c215700 (LWP 22086)):
#0  0x7f339fce4a6d in poll () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7f339af30150 in poll (__timeout=-1, __nfds=1, __fds=0x7f338c214b60) 
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x55f2fbae8e90, cond=cond@entry=0x55f2fbae8ed0, 
vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:479
#3  0x7f339af31ee9 in xcb_wait_for_event (c=0x55f2fbae8e90) at 
../../src/xcb_in.c:693
#4  0x7f338e377029 in QXcbEventReader::run (this=0x55f2fbaf5260) at 
qxcbconnection.cpp:1330
#5  0x7f33a03d022d in QThreadPrivate::start (arg=0x55f2fbaf5260) at 
thread/qthread_unix.cpp:368
#6  0x7f339a8ce519 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
#7  0x7f339fceea5f in clone () from /lib/x86_64-linux-gnu/libc.so.6

Thread 1 (Thread 0x7f33a43c6940 (LWP 22085)):
[KCrash Handler]
#6  0x7f339fc35a70 in raise () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x7f339fc3719a in abort () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x7f33a03bb0c7 in qt_message_fatal (context=..., message=...) at global/qlogging.cpp:1690
#9  QMessageLogger::fatal (this=this@entry=0x7fff8a300a20, 
msg=msg@entry=0x7f33a2e6e5fd "%s") at global/qlogging.cpp:796
#10 0x7f33a2c9d137 in QSGRenderLoop::handleContextCreationFailure 
(this=this@entry=0x55f2fbb34020, window=0x55f2fbb39f20, isEs=) 
at scenegraph/qsgrenderloop.cpp:274
#11 0x7f33a2c9e105 in QSGGuiThreadRenderLoop::renderWindow 
(this=this@entry=0x55f2fbb34020, window=) at 
scenegraph/qsgrenderloop.cpp:368
#12 0x7f33a2c9ed2a in QSGGuiThreadRenderLoop::exposureChanged 
(this=0x55f2fbb34020, window=) at 
scenegraph/qsgrenderloop.cpp:477
#13 0x7f33a0b19f95 in QWindow::event (this=this@entry=0x55f2fbb39f20, 
ev=ev@entry=0x7fff8a300ed0) at kernel/qwindow.cpp:2264
#14 0x7f33a2d12b05 in QQuickWindow::event (this=0x55f2fbb39f20, 
e=0x7fff8a300ed0) at items/qquickwindow.cpp:1606
#15 0x55f2fb0eefd1 in KSMShutdownDlg::event (this=0x55f2fbb39f20, 
e=0x7fff8a300ed0) at ./ksmserver/shutdowndlg.cpp:240
#16 0x7f33a175759c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x7f33a175ee64 in QApplication::notify(QObject*, QEvent*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x7f33a05ae258 in QCoreApplication::notifyInternal2 
(receiver=receiver@entry=0x55f2fbb39f20, event=event@entry=0x7fff8a300ed0) at 

Bug#833719: firefox: NS_ERROR_NET_INADEQUATE_SECURITY on Google & Facebook

[Bob Bib]

Package: firefox-esr
Version: 52.5.2esr-1

* firefox-esr depends on libnss3 (>= 2:3.28);

* with installed libnss3 2:3.33-1,
Google sites (e. g., https://translate.google.com/)
produce "NS_ERROR_NET_INADEQUATE_SECURITY";

* after upgrading to libnss3 2:3.34-1,
the problem disappears.

---
Architecture: amd64 (x86_64)
---
Best wishes,
Bob

Bug#883547: flash-kernel: please allow flavourless kernels

[Adam Borowski]

On Mon, Dec 18, 2017 at 03:08:08PM -0800, Vagrant Cascadian wrote:
> I think the following patch should work for this, by setting:
> 
> Kernel-Flavor: any

> The patch significantly refactors the use of the check_kflavor function,

> I haven't done extensive testing yet, but I could go ahead any push this
> myself once I've done more tests, if nobody objects.

Works for me on Odroid-U2 (armhf).

I'll try on Pine64 once a kernel is built, in the morning (it takes two ages
and three aeons).


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

Bug#884748: u-boot-menu: uses systemd.unit=rescue.target instead of single

[Adam Borowski]

Package: u-boot-menu
Version: 2
Severity: normal

Hi!
The "rescue" menu entry created by u-boot-menu appends
"systemd.unit=rescue.target".  Obviously, this is systemd specific,
and has no effect whatsoever if any modular init+rc pair is used instead.

Grub uses "single" which works on all schemes supported by Debian (systemd,
sysv-rc, openrc).

Thus, could you please go with "single" as well?


Meow!
-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.15.0-rc4-00065-g20ec520876da (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages u-boot-menu depends on:
ii  linux-base  4.5

u-boot-menu recommends no packages.

u-boot-menu suggests no packages.

-- no debconf information

Bug#884747: fails to start when .config is a symlink, with misleading error message about permissions

[Joey Hess]

Package: libreoffice
Version: 1:5.4.3-4+b1
Severity: normal

  The application cannot be started.
  LibreOffice user installation could not be processed due to missing
  access rights. Please make sure that you have sufficient access rights
  for the following location and restart LibreOfflice:
  
  /home/joey/.etc/.config/libreoffice/4

My .config is a symlink to .etc/.config. The files in .etc/.config/libreoffice
were created by the same libreoffice process that then displayed that
error dialog. There are no permissions problems.

joey@darkstar:~>ls -ld .config .etc .etc/.config .etc/.config/libreoffice 
.etc/.config/libreoffice/4
lrwxrwxrwx  1 joey joey   12 Dec 18 22:33 .config -> .etc/.config/
drwxr-xr-x 10 joey joey 4096 Dec 11 11:50 .etc/
drwx-- 70 joey joey 4096 Dec 18 22:50 .etc/.config/
drwxr-xr-x  3 joey joey 4096 Dec 18 22:50 .etc/.config/libreoffice/
drwx--  3 joey joey 4096 Dec 18 22:50 .etc/.config/libreoffice/4/

joey@darkstar:~>tree -pld .etc/.config/libreoffice
.etc/.config/libreoffice
└── [drwx--]  4
└── [drwxr-xr-x]  user
├── [drwxr-xr-x]  autotext
├── [drwxr-xr-x]  config
└── [drwxr-xr-x]  extensions

Libreoffice appears to be doing some kind of permissions check that
doesn't handle symlinks correctly. I had to replace the .config
symlink with .etc/.config temporariy to edit a document.

I have had .config be a symlink for many years with no problems,
including using libreoffice before. I have reasons of personal
organization to want to keep it that way; in any case the error message
is wrong and the limitation that it not be a symlink seems pointless.

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

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

Versions of packages libreoffice depends on:
ii  libreoffice-avmedia-backend-gstreamer  1:5.4.3-4+b1
ii  libreoffice-base   1:5.4.3-4+b1
ii  libreoffice-calc   1:5.4.3-4+b1
ii  libreoffice-core   1:5.4.3-4+b1
ii  libreoffice-draw   1:5.4.3-4+b1
ii  libreoffice-impress1:5.4.3-4+b1
ii  libreoffice-math   1:5.4.3-4+b1
ii  libreoffice-report-builder-bin 1:5.4.3-4+b1
ii  libreoffice-writer 1:5.4.3-4+b1
ii  python3-uno1:5.4.3-4+b1

Versions of packages libreoffice recommends:
ii  fonts-crosextra-caladea 20130214-2
ii  fonts-crosextra-carlito 20130920-1
ii  fonts-dejavu2.37-1
ii  fonts-linuxlibertine5.3.0-4
ii  fonts-open-sans 1.11-1
ii  fonts-sil-gentium-basic 1.1-7
ii  libreoffice-java-common 1:5.4.3-4
ii  libreoffice-librelogo   1:5.4.3-4
ii  libreoffice-nlpsolver   0.9+LibO5.4.3-4
ii  libreoffice-ogltrans1:5.4.3-4+b1
ii  libreoffice-report-builder  1:5.4.3-4
ii  libreoffice-script-provider-bsh 1:5.4.3-4
ii  libreoffice-script-provider-js  1:5.4.3-4
ii  libreoffice-script-provider-python  1:5.4.3-4
ii  libreoffice-sdbc-postgresql 1:5.4.3-4+b1
ii  libreoffice-wiki-publisher  1.2.0+LibO5.4.3-4

Versions of packages libreoffice suggests:
pn  cups-bsd
ii  default-jre [java6-runtime] 2:1.8-59
ii  firefox 57.0.1-1
ii  ghostscript 9.22~dfsg-1
pn  gpa 
ii  gstreamer1.0-libav  1.12.4-1
ii  gstreamer1.0-plugins-bad1.12.3-2
ii  gstreamer1.0-plugins-base   1.12.4-1
ii  gstreamer1.0-plugins-good   1.12.4-1
ii  gstreamer1.0-plugins-ugly   1.12.3-1+b1
ii  hunspell-en-us [hunspell-dictionary]1:2017.08.24
pn  hyphen-hyphenation-patterns 
ii  imagemagick 8:6.9.7.4+dfsg-16
ii  imagemagick-6.q16 [imagemagick] 8:6.9.7.4+dfsg-16
ii  libgl1  1.0.0-1
ii  libreoffice-gnome   1:5.4.3-4+b1
pn  libreoffice-grammarcheck
pn  libreoffice-help
pn  libreoffice-l10n
pn  libreoffice-officebean  
ii  libsane 1.0.25-4.1
ii  libxrender1 1:0.9.10-1
pn  

Bug#866211: firefox: trying to connect to wikipedia results in Error code: NS_ERROR_NET_INADEQUATE_SECURITY

[Bob Bib]

IMHO, it looks very similar to bug #833719, caused by libnss3 version mismatch.
Perhaps, should be merged.

--
Best wishes,
Bob

Bug#881663: closed by Mattia Rizzolo <mat...@debian.org> (Re: Bug#881663: Missing build on mips64el and mipsel)

[Nicholas D Steeves]

Hi Mattia, Sylvestre, and Emilio,

On Mon, Dec 18, 2017 at 09:18:06AM +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the llvm-toolchain-5.0 package:
> 
> #881663: llvm-toolchain-5.0: FTBFS on mips64el: slow tests?
> 
> It has been closed by Mattia Rizzolo .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Mattia Rizzolo 
>  by
> replying to this email.
> 

Thank you for fixing this so quickly!  Please feel free to file a bug
against irony-mode if I take too long to transition it to clang-5.0
and/or to get its Debian CI tests working.

Kind regards,
Nicholas



signature.asc
Description: PGP signature

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[John Allwine]

Maybe I'm using an old version that doesn't pick that up? Or I'm not
naming it correctly? Here's the script that I run in an unbuntu docker
image: 
https://github.com/AllwineDesigns/build_stlcmd_deb/blob/master/build_stlcmd.sh
( (If you have docker installed you can clone that repo and do a
docker build . to try it out)
You can see at line 11 that I'm downloading the .asc file (right after
downloading the .orig file). At the bottom I'm using debuild to build
the package, but it's not picking up the .asc file.

On Mon, Dec 18, 2017 at 6:41 PM, Adam Borowski  wrote:
> On Mon, Dec 18, 2017 at 06:36:00PM -0700, John Allwine wrote:
>> Thanks Adam! I really appreciate you taking the time to look through
>> this. I'm still unclear on how to include the .asc file in my upload.
>> The dput command takes the .changes file, which determines which files
>> are uploaded, so how do I include the .asc file since it's not listed?
>> Do I manually edit the .changes file? Is there another method with
>> more control over what I upload?
>
> Just have it in the parent directory when you build the source (with
> dpkg-buildpackage -S or a wrapper which calls it), next to .orig.
>
>
> Meow!
> --
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets.  Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#873283: fixed in qupzilla 2.2.2~dfsg1-2

[Paul Wise]

On Mon, 2017-12-18 at 19:06 +, Georges Khaznadar wrote:

>* added a "Provides: falkon" clause in debian/control, which
>  Closes: #873283

I think it would have been more appropriate to rename both the source
and binary packages to falkon and provide transitional binary
packages for the qupzilla name.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#882116: reopening RFS: sqlcl-package/0.1.0 [ITP]

[Lazarus Long]

As requested by Chris Lamb a justification of why the package should
be native was added to the changelog, hence it needs sponsoring again
to be uploaded back to the NEW queue.

Thank you very much,

-- 
Lazarus

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[Adam Borowski]

On Mon, Dec 18, 2017 at 06:36:00PM -0700, John Allwine wrote:
> Thanks Adam! I really appreciate you taking the time to look through
> this. I'm still unclear on how to include the .asc file in my upload.
> The dput command takes the .changes file, which determines which files
> are uploaded, so how do I include the .asc file since it's not listed?
> Do I manually edit the .changes file? Is there another method with
> more control over what I upload?

Just have it in the parent directory when you build the source (with
dpkg-buildpackage -S or a wrapper which calls it), next to .orig.


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

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

[Russ Allbery]

Ian Jackson  writes:

> So, my discoveries and some other facts:

> The file
> debian/patches/0008-Add-support-for-Subversion-svnserve.patch
> says
> diff --git a/conf_convert b/conf_convert
> new file mode 100755
> index 000..a47ecba

> gbp pq import uses git to apply patches.  git honours the file mode.
> This results in a git tree object containing an executable
> conf_convert.

> dpkg-source does not use git.  It does not honour the file mode (at
> least in the version I have here).  So the source package, when
> unpacked with dpkg-source, produces a non-executable conf_convert.

Aha!  Yes, that explains everything, and now I feel wry about this because
I noticed the same problem in a different context and papered around it
with a chmod in debian/rules and then promptly forgot about it.

I probably should just stuff that file in the debian directory, although
I was vaguely trying to make it usable for upstream (who won't ever take
it, but ah well).  I'll fix it to be consistently broken about the mode
instead.

Thank you for your investigation!

Does this also explain the errors that I got in the initial message that I
opened this bug with, when trying to build the package with gbp?  Those
were odd -- attempts to touch files in non-existent subdirectories of
.git.  I wasn't sure what to make of that.

-- 
Russ Allbery (r...@debian.org)   

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Martin-Éric Racine]

2017-12-19 2:02 GMT+02:00 Michael Biebl :
> Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
>> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>>> Hi,
>>>
>>> I just uploaded v236 today. Before we try to debug this further, it
>>> would be great if you can give this version a try. Maybe your issue is
>>> already fixed.
>>> If not, we'll have to involve upstream at some point by filing an
>>> upstream bug report. But let's first wait for your results with 236-1
>>
>> The issue is not fixed. Something fails at communicating with dbus,
>> and it messes up everything else.
>
> Just to be sure, have you rebooted your system after upgrading to 236-1?

Yes I have, but this required issuing "exec reboot -f" to bypass init
entirely, otherwise it fails due to the lack of dbus connection.

Martin-Éric

Bug#884746: RFP: marionette.js -- application framework for Backbone.js

[Ben Finney]

Package: wnpp
Severity: wishlist

* Package name: marionette.js
  Version : 3.5.1
  Upstream Author : Marionette.js developers 
* URL : https://marionettejs.com/
* License : Expat
  Programming Lang: JavaScript
  Description : application framework for Backbone.js

  Marionette is a composite application library for the
  Backbone.js library. Marionette that aims to simplify the
  construction of large scale JavaScript applications. It is a
  collection of common design and implementation patterns found in
  applications.

-- 
 \   “The generation of random numbers is too important to be left |
  `\to chance.” —Robert R. Coveyou |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#884745: libjs-sinon: new upstream version “4.1.3”

[Ben Finney]

Package: libjs-sinon
Version: 1.9.0-1
Severity: wishlist

The SinonJS project lists the latest release as “v4.1.3”
.

Please package a current SinonJS release in Debian.

-- 
 \  “The entertainment industry calls DRM "security" software, |
  `\ because it makes them secure from their customers.” —Cory |
_o__) Doctorow, 2014-02-05 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[John Allwine]

> Well, how else can uscan verify it?
> It's also used to verify the orig tarball once it's in the archive.
The watch file describes how to download the upstream tar ball and its
signature file. I'm not sure what to do here. Right now I do a debsign
on the .changes file and it signs the .dsc file as well. Then I use
dput which uploads all the files listed in the changes file to
mentors.debian.net. Do I manually sign the .orig file before that?

> Usually, UNRELEASED means the package is not yet ready for uploading.  This
> obviously conflicts with a request to upload the package to the official
> archive.  I can change this myself, but it's better to ask.
I changed this to unstable.

> Both the fork and the original have plausibly looking statements on their
> front pages on GitHub.  That is:
>
> Copyright (c) 2012 Joost Nieuwenhuijse (jo...@newhouse.nl)
> Copyright (c) 2011 Evan Wallace (http://madebyevan.com/)
> License: MIT

I added those as well as 2017 @jscad, which is listed in the LICENSE
file in its github repo.

As for the help2man issues. I added help2man to the Build-Depends
field in debian/control, is that all I need to do? How do I test that
it works?

My latest changes are up: https://mentors.debian.net/package/stlcmd

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

[Ian Jackson]

Ian Jackson writes ("Re: Bug#884646: No commands in dgit-maint-gbp appear to 
work with 3.0 (quilt) packages"):
> More when I have figured out what is going on.

So, my discoveries and some other facts:

The file
debian/patches/0008-Add-support-for-Subversion-svnserve.patch
says
diff --git a/conf_convert b/conf_convert
new file mode 100755
index 000..a47ecba

gbp pq import uses git to apply patches.  git honours the file mode.
This results in a git tree object containing an executable
conf_convert.

dpkg-source does not use git.  It does not honour the file mode (at
least in the version I have here).  So the source package, when
unpacked with dpkg-source, produces a non-executable conf_convert.

dgit --quilt=gbp build-source uses gbp pq import to generate the
"dgit view".

dgit push checks that the dgit view is identical to the .dsc, and
fails.

A hint was given by this series of messages:
 warning: dgit: gbp-pq import and dpkg-source disagree!
 dgit:  gbp-pq import gave commit 51b9594715c59e98e17207918996edbc160f5762
 dgit:  gbp-pq import gave tree a2f3c6124e1176af8e5eebcd7b1a378818f991f6
 dgit:  dpkg-source --before-build gave tree 
dc66d4bce760602ff12f5894baaf931caa2c01fa



Things that I think are wrong:

* Your package contains a patch which produces different results from
  dpkg-source to gbp pq import.  This is clearly undesirable and I
  think it is reasonable for dgit to fail here.  (In some cases this
  would mean the maintainer sending an unbuildable package to the
  archive, which builds when gbp pq import applies the patches, but
  not when using dpkg-source and no git tools.)

* dgit push printed this
dgit: HEAD specifies a different tree to rssh_2.3.4-6.dsc:
dgit:  conf_convert | 0
dgit:  1 file changed, 0 insertions(+), 0 deletions(-)
  which is a terribly obtuse way of reporting a permission
  difference.

* dgit push printed this
dgit:   ... To see a full diff, run
dgit:   git diff dc66d4bce760602ff12f5894baaf931caa2c01fa HEAD
  but that is completely wrong and produces a bunch of irrelevant
  stuff.

  I think the bug is that the message says HEAD but of course the
  relevant diff is between the .dsc and the dgit view, not between the
  .dsc and HEAD, in split brain mode.  If I do this
 git diff dc66d4bce760602ff12f5894baaf931caa2c01fa 
4dcfadb60855855fa909fb1544c22af63084b4c0
  I get only the expected mention of the mode of conf_convert.
  (that hash came from "dgit view: found cached (commit id...)")

* dgit push printed this
see dgit(7) for some hints
  but dgit(7) mentions nothing about this kind of problem.


I think if you fix the first problem (eg by manually editing the patch
to specify 644 as the mode, or with gbp pq and chmod and git-commit -a
--amend) you will be able to use dgit in future.

The others are problems with dgit.  I'll wait a bit to see what
everyone says, and then do some bug gardening and/or docs work.


I make no comment about the behaviour of dpkg-source, except to say
that having dpkg-source change, now, to honour the file mode, would be
undesirable, because it would change the meaning of existing source
packages.


Thanks,
Ian.


-- 
Ian Jackson    These opinions are my own.

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

Bug#870001: [PKG-Openstack-devel] Bug#870001: openvswitch-switch: switch takes a very long time to start or fails without upstream's SYSTEMCTL_SKIP_REDIRECT=yes

[Michael Biebl]

Am 19.12.2017 um 01:06 schrieb Nigel Kukard:

> One of the challenges here is when OVS is started up, it may create
> network devices, which triggers ifup ... if this happens during the
> start of networking you have a problem, it is also a problem because the
> ifup script tries to start the service if its not running. Under stretch
> this collides horribly causing a very very long startup delay, OVS
> starts starting, brings up a network device, ifup is run, which in turn
> tries to start OVS while its already starting.

Starting the service from the ifup hook looks like very bad design as
this is prone to deadlocks.



-- 
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#884744: gpsd grabs cp2102 usb-serial converter

[Fabian Inostroza]

Package: gpsd
Version: 3.17-3
Severity: important

Dear Maintainer,

I use a USB-Serial converter with a cp2102 chip (product id 0x10c4 
and device id 0xea60), when I connect the adapter to the USB port 
gpsd inmediately grabs the device, as per the udev rule in 60-gpsd.rules.

The pair of product/device id corresponds to a generic USB-Serial adapter, 
it is not specific to a gps receiver, please disable this udev rule. The same 
has been done for the FTDI adapters.

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

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

Versions of packages gpsd depends on:
ii  adduser3.116
ii  libbluetooth3  5.47-1
ii  libc6  2.25-3
ii  libdbus-1-31.12.2-1
ii  libgps23   3.17-3
ii  libusb-1.0-0   2:1.0.21-2
ii  lsb-base   9.20170808
ii  netbase5.4
ii  systemd-sysv   235-3

Versions of packages gpsd recommends:
ii  python  2.7.14-3
ii  udev235-3

Versions of packages gpsd suggests:
ii  dbus  1.12.2-1
ii  gpsd-clients  3.17-3

-- no debconf information

Bug#884742: ITP: gajim-plugininstaller -- Gajim plugin to install plugins from gajim.org

[Jonas Smedegaard]

Quoting W. Martin Borgert (2017-12-19 00:56:21)
> Package: wnpp
> Severity: wishlist
> Owner: "W. Martin Borgert" 
> 
> * Package name: gajim-plugininstaller
>   Version : 0.20.0
>   Upstream Author : Gajim authors
> * URL : 
> https://dev.gajim.org/gajim/gajim-plugins/wikis/PluginInstallerPlugin
> * License : GPL3
>   Programming Lang: Python
>   Description : Gajim plugin to install plugins from gajim.org
> 
> You will be able to easily install and upgrade new plugins from Gajim's FTP 
> server.

I believe such package should be in contrib (not main).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#884654: glib2.0: FTBFS on amd64 buildd: gdbus-peer test: assertion 'source->ref_count > 0' failed

[Simon McVittie]

Control: found -1 2.54.1-1

On Mon, 18 Dec 2017 at 18:18:41 +, Simon McVittie wrote:
> On Mon, 18 Dec 2017 at 09:17:46 +, Simon McVittie wrote:
> > The failure on the buildd is new, although I think I might have seen it
> > before in local testing (but never reproducibly). It's probably some
> > rarely-hit race condition?
> 
> I can reproduce this by running the gdbus-peer test in a loop (this is
> with GLib git master, not Debian's GLib, but that's close enough).

I can also reproduce it by building 2.54.1-1 or 2.54.2-2 and re-running
that test in a loop, but not easily (running 100 times in a loop often
succeeds). Having looked at the history of the code involved, I think
this is a long-standing race condition; so this isn't a regression,
and shouldn't block testing migration.

smcv

Bug#870001: [PKG-Openstack-devel] Bug#870001: openvswitch-switch: switch takes a very long time to start or fails without upstream's SYSTEMCTL_SKIP_REDIRECT=yes

[Nigel Kukard]

On 18/12/17 16:11, Thomas Goirand wrote:
> On 12/18/2017 12:41 AM, Michael Biebl wrote:
>> Am 17.12.2017 um 23:37 schrieb Thomas Goirand:
>>
>>> I've taken the maintenance of OpenVSwitch only very recently, I was not
>>> the one that wrote this. What does SYSTEMCTL_SKIP_REDIRECT does? I will
>>> indeed remove it as I trust you, but I'd like to understand first.
>> It's not really important what it does. The important thing is that it's
>> an internal implementation detail of the systemd lsb hook
>> /lib/lsb/init-functions.d/40-systemd which governs the redirection of
>> services and not a public API.
>> If you fiddle with that, /etc/init.d/foo start|stop|restart will no
>> longer be properly redirected to systemctl and the service is no longer
>> under systemd supervision.
>>
>>> Also, I tried to add some systemd service files, taking them from
>>> Ubuntu, but quickly reverted, as it failed badly. Michael, could you
>>> help me to write something better? Here's the commit reverting the
>>> previous addition of Ubuntu's .service files:
>>>
>>> https://anonscm.debian.org/cgit/openstack/third-party/openvswitch.git/commit/?id=02178a600660694bd9886652642e23952b9f93ac
>>>
>>> Any comment here?
>> If you have more specific questions, I might be able to help.
>>
>>
> Well, I guess the main question is, why do we have the problem as
> described in #880498 if I add the .service files.

The /etc/init.d/*.init files need to be modified, if I recall right the
if-*{up,down}.d scripts too, there is some subtle changes needed to
implement the method Ubuntu uses.

>
> Another question would be: do think doing 2 .service files like in
> Ubuntu a good idea? Wouldn't it be more simple to do one?

Ubuntu has pretty good Openstack implementation, how Open vSwitch is
basically fired up is if a network interface is onlined before OVS
starts, OVS is started. OVS is started after the networking service.

The openvswitch-switch.service file prevents the running on
/etc/init.d/openvswitch-switch during startup.

One of the challenges here is when OVS is started up, it may create
network devices, which triggers ifup ... if this happens during the
start of networking you have a problem, it is also a problem because the
ifup script tries to start the service if its not running. Under stretch
this collides horribly causing a very very long startup delay, OVS
starts starting, brings up a network device, ifup is run, which in turn
tries to start OVS while its already starting.

This is the reason why SYSTEMCTL_SKIP_REDIRECT is used.

There is also the other Open vSwitch services, and quite a few of them
depending on what you're doing. For instance on a controller,
ovsdb-server is started 3 times, once for SB, once for NB and once for
vswitchd to manage each of the databases.

-N

Bug#884646: No commands in dgit-maint-gbp appear to work with 3.0 (quilt) packages

[Ian Jackson]

Russ Allbery writes ("Bug#884646: No commands in dgit-maint-gbp appear to work 
with 3.0 (quilt) packages"):
> URL: ssh://git.debian.org/git/collab-maint/rssh.git -b debian/master
> Commit: a7f1fde3ca55be0a01a36f3c9399243e4b86ff7c
> 
> (Presumably the HTTP URL would work as well, but that's the exact URL that
> I've been using.)  Thanks for taking a look!

Thanks.  I have repro'd the behaviour you see with these runes:

  dgit clone rssh
  cd rssh
  git-remote add rra ssh://git.debian.org/git/collab-maint/rssh.git
  git-fetch rra
  git-checkout a7f1fde3ca55be0a01a36f3c9399243e4b86ff7c
  dgit --quilt=gbp --overwrite -wgf build-source
  dgit --quilt=gbp --overwrite --damp-run push

More when I have figured out what is going on.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#884743: debian-installer: grub-install fail because "bios_grub" flag gets removed if i use RAID partition on GPT

[Jan Němeček]

Package: debian-installer
Version: 20170615+deb9u2
Severity: normal

Dear Maintainer,

I have following configuration:

Disk /dev/sda: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Disklabel type: gpt

/dev/sda12048  20479  184329M BIOS boot
/dev/sda2   20480 5839863807 5839843328  2.7T Linux RAID
/dev/sda3  5839863808 5860532223   20668416  9.9G Linux swap

Disk /dev/sdb: 2.7 TiB, 3000592982016 bytes, 5860533168 sectors
Disklabel type: gpt

/dev/sdb1   2048  20479  184329M BIOS boot
/dev/sdb2  20480 5839863807 5839843328  2.7T Linux RAID

Disk /dev/md0: 2.7 TiB, 2989865566208 bytes, 5839581184 sectors 

In the part of installation grub-install i got error "This GPT 
partition label has no BIOS Boot Partition"

I was fix that by switch to terminal and use this procedure:

- bind /dev /proc and etc to /target
- chroot /target
- install parted
- set 1 bios_grub on (by parted on both disks)
- grub-install /dev/sda
- grub-install /dev/sdb


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

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

Bug#883877: rsyslog: fails to configure, dpkg --configure exits with error

[Michael Biebl]

Am 18.12.2017 um 20:07 schrieb Martin-Éric Racine:
> 2017-12-18 2:08 GMT+02:00 Michael Biebl :
>> Hi,
>>
>> I just uploaded v236 today. Before we try to debug this further, it
>> would be great if you can give this version a try. Maybe your issue is
>> already fixed.
>> If not, we'll have to involve upstream at some point by filing an
>> upstream bug report. But let's first wait for your results with 236-1
> 
> The issue is not fixed. Something fails at communicating with dbus,
> and it messes up everything else.

Just to be sure, have you rebooted your system after upgrading to 236-1?


-- 
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#884742: ITP: gajim-plugininstaller -- Gajim plugin to install plugins from gajim.org

[W. Martin Borgert]

Package: wnpp
Severity: wishlist
Owner: "W. Martin Borgert" 

* Package name: gajim-plugininstaller
  Version : 0.20.0
  Upstream Author : Gajim authors
* URL : 
https://dev.gajim.org/gajim/gajim-plugins/wikis/PluginInstallerPlugin
* License : GPL3
  Programming Lang: Python
  Description : Gajim plugin to install plugins from gajim.org

You will be able to easily install and upgrade new plugins from Gajim's FTP 
server.

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[Adam Borowski]

On Mon, Dec 18, 2017 at 04:00:53PM -0700, John Allwine wrote:
> The signing-key.asc is for uscan when checking for updates in the watch. 
> Am I supposed to sign the orig tar ball?

Well, how else can uscan verify it?
It's also used to verify the orig tarball once it's in the archive.

On the other hand, signed tarballs are far less useful when maintainer is
the same person as upstream -- you don't need to rely on any untrusted
paths.

> I left it as UNRELEASED as that was suggested in the walkthrough I went
> through.  I can change it to unstable.

Usually, UNRELEASED means the package is not yet ready for uploading.  This
obviously conflicts with a request to upload the package to the official
archive.  I can change this myself, but it's better to ask.

> Will add the original license of CSG.js as well.

Both the fork and the original have plausibly looking statements on their
front pages on GitHub.  That is:

Copyright (c) 2012 Joost Nieuwenhuijse (jo...@newhouse.nl)
Copyright (c) 2011 Evan Wallace (http://madebyevan.com/)
License: MIT


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

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Markus Koschany]

Hi,

Am 18.12.2017 um 23:37 schrieb Jonathan Nieder:
> Hi Markus,
> 
> Markus Koschany wrote:
>> Am 16.12.2017 um 15:55 schrieb Sean Whitton:
>>> On Wed, Dec 13 2017, Markus Koschany wrote:
> 
 If the Policy editors cannot make a decision with regards to
 debian/copyright then we should ask the DPL to seek legal advice and
 when necessary start a GR for reasons of legitimacy.
>>>
>>> If we think this issue is important enough to spend money on that.  I am
>>> not convinced it is.
>>
>> Then we need a GR. Simply claiming that something violates the law
>> without proof cannot be the right way for a large project like Debian.
>> This is a very important topic because writing debian/copyright is not
>> optional in Debian. I simply believe that most people appreciate doing
>> something meaningful in their free time.
> 
> You are of course free to initiate a GR at any time.
> 
> I have no opinion about this particular proposal (allowing specifying
> common licenses with only the identifier).  But I am worried at how
> black and white you are describing the world to be.

I don't think there is a reason to be worried. But I do have an opinion
and I am expressing it. I believe I am not the only one who feels that
we need to rethink debian/copyright.

> Debian has long had a practice of being extra careful to respect the
> wishes of free software authors as expressed in the licenses they
> choose.  This goes beyond the minimum legal requirements of license
> compliance.  It is not because the project is afraid of being sued but
> because at least some in the project consider it to be the right thing
> to do.

This is the argument that comes up whenever someone tries to change
something in regard to d/copyright. We have always done it this way and
we do more than legally required because we are Debian. I believe that
most free software authors are also happy with the way Fedora or FreeBSD
are respecting their works and if you say that some in the project
consider the Debian way the right thing to do, then let me say that
there are also other people who think we can improve d/copyright without
sacrificing accuracy and still meet all legal requirements.

> Here Sean pointed out that just a license name with too little
> accompanying text does not appear to be particularly clear to end
> users.  That means end users may not know what their rights are, so it
> seems worth thinking about.  Fortunately DEP-5 copyright files contain
> 
>  Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
> 
> so perhaps some information in the copyright-format would be good
> enough to help those end users.  Perhaps not.  But I am puzzled that
> you seem to think there is only one possible right answer and that it
> should be obvious to everybody.

Well, that was exactly my point. Our debian/copyright file which uses
copyright format 1.0 contains this line

 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

a link to the specification. There can be a short license name like

License: GPL-2 or License: GPL-2+.

I was pointing out that it is already common practice to write those
license short names and point to /usr/share/common/licenses/GPL-2 with
another sentence. I don't share Sean's concerns but they can be remedied
by clarifying our copyright format document. In addition we could reduce
boilerplate by allowing an even shorter version than

License: GPL-2+
 On Debian system the full license text of the GNU General Public
 License 2 can be found in /usr/share/common-licenses/GPL-2

namely

License: [GPL-2+]

If we document that brackets around the short license name have the same
meaning than our common paragraph from above, we have gained a new
concise way of documenting a license without sacrificing accuracy. I'm
not sure why you think this is not obvious.

> The way you describe the experience of writing a debian/copyright file
> is foreign to my own experience.  It sounds like making the process of
> generating /usr/share/doc/{package}/copyright using *automated tools*
> in a smoother way will be a good avenue for addressing the developer
> experience issues you are mentioning.  Then you'd be in a better
> position to come up with what the appropriate content of that file
> should be to serve end users.

In my opinion the creation of automated tools like cme is evidence that
our current approach of writing debian/copyright is in parts wrong.
Instead of doing the obvious and referencing existing license texts we
duplicate them. We should not need an automated tool to write
debian/copyright. I believe the proposal in this bug report can be
implemented quite easily without conflating the automated tools idea.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#880883: FTBFS on arm64: test suite times out (on arm-arm-04)

[Simon McVittie]

On Fri, 17 Nov 2017 at 18:37:42 +0100, Emilio Pozuelo Monfort wrote:
> I gave it back again, and it again got picked by arm-arm-04. With the help 
> from
> jcristau (as I don't have access to that machine) I determined that the build
> gets killed while running the closures test, which gets executed by is way too
> slow on that machine (it'd take around 200 minutes to complete it).

In 2.54.2-3 I've cut that test down to 1% of the usual repetitions on
arm64, which seems like enough to prove that this functionality does
basically work. The fact that it's far slower than on other CPUs is
still a bug, but hopefully one that can be downgraded to important.

smcv

Bug#884659: glib2.0: sometimes FTBFS on reproducible-builds: gwakeup, gwakeup-fallback tests terminated by SIGALRM

[Simon McVittie]

On Mon, 18 Dec 2017 at 10:17:54 +, Simon McVittie wrote:
> The thread count, number of tokens and token TTL are probably also completely
> arbitrary, and could be reduced, at the cost of being less likely to
> detect bugs (unfortunately this sort of threading stress-test is usually
> probabilistic).

In 2.54.2-3 I've reduced the number of threads and the TTL, both by a
factor of 10. I don't think this is really a correct solution (it's now
less likely to find bugs), but it'll let us see what happens. If the
builds succeed I'll drop this bug down to a non-RC severity.

smcv

Bug#884662: glib2.0: sometimes FTBFS on reproducible-builds: tar: ./usr/share/locale/en_??/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a directory

[Simon McVittie]

On Mon, 18 Dec 2017 at 09:17:46 +, Simon McVittie wrote:
> [#884662] (a build failure inside dpkg-builddeb, not a test failure)
> I don't know what is going on, and it doesn't seem particularly likely
> to be a GLib bug - GLib just puts files in a tree like any other package,
> so I'm not sure how it would trigger this particular failure. It can be
> seen in these logs:
> https://tests.reproducible-builds.org/debian/rbuild/buster/i386/glib2.0_2.54.1-1.rbuild.log
> https://tests.reproducible-builds.org/debian/rbuild/unstable/armhf/glib2.0_2.54.2-2.rbuild.log
> (not build2, so we presumably can't blame disorderfs either).

tar and dpkg maintainers: does this look at all familiar to you, or
can you think of anything that GLib might be doing strangely with its
translations that would somehow make tar think it needed to treat the
regular file glib20.mo as a directory? It's an ordinary GNU gettext .gmo
file, with nothing GLib-specific that I'm aware of, and in particular
File::StripNondeterminism was able to open and rewrite it like a
regular file.

This is on the reproducible-builds infrastructure, so if there are any
oddities implied by that, they apply here (for example I think it's a
tmpfs - although I've been able to build GLib in a large tmpfs on my
laptop without problems).

I don't know whether it's significant or just coincidence that the two
languages affected in the failing builds that I've seen are the only two
of the form en_??.

Unfortunately this is pbuilder, not sbuild, so the log doesn't list the
versions of tar and dpkg used.

The most relevant bits of the (armhf + all) build log (the i386 + all
failure is similar, but en_GB is the one that fails there):

make[4]: Entering directory '/build/1st/glib2.0-2.54.2/debian/build/deb/po'
mkdir -p /build/1st/glib2.0-2.54.2/debian/tmp/usr/share; \
catalogs='af.gmo am.gmo an.gmo ar.gmo as.gmo ast.gmo az.gmo be.gmo 
b...@latin.gmo bg.gmo bn.gmo bn_IN.gmo bs.gmo ca.gmo c...@valencia.gmo cs.gmo 
cy.gmo da.gmo de.gmo dz.gmo el.gmo en_CA.gmo en_GB.gmo e...@shaw.gmo eo.gmo 
es.gmo et.gmo eu.gmo fa.gmo fi.gmo fr.gmo fur.gmo ga.gmo gd.gmo gl.gmo gu.gmo 
he.gmo hi.gmo hr.gmo hu.gmo hy.gmo id.gmo is.gmo it.gmo ja.gmo ka.gmo kk.gmo 
kn.gmo ko.gmo ku.gmo lt.gmo lv.gmo mai.gmo mg.gmo mk.gmo ml.gmo mn.gmo mr.gmo 
ms.gmo nb.gmo nds.gmo ne.gmo nl.gmo nn.gmo oc.gmo or.gmo pa.gmo pl.gmo ps.gmo 
pt.gmo pt_BR.gmo ro.gmo ru.gmo rw.gmo si.gmo sk.gmo sl.gmo sq.gmo sr.gmo 
s...@latin.gmo s...@ije.gmo sv.gmo ta.gmo te.gmo tg.gmo th.gmo tl.gmo tr.gmo 
ug.gmo tt.gmo uk.gmo vi.gmo wa.gmo xh.gmo yi.gmo zh_CN.gmo zh_HK.gmo 
zh_TW.gmo'; \
for cat in $catalogs; do \
  cat=`basename $cat`; \
  case "$cat" in \
*.gmo) destdir=/usr/share/locale;; \
*) destdir=/usr/lib/arm-linux-gnueabihf/locale;; \
  esac; \
  lang=`echo $cat | sed 's/\.gmo$//'`; \
  dir=/build/1st/glib2.0-2.54.2/debian/tmp$destdir/$lang/LC_MESSAGES; \
  mkdir -p $dir; \
  if test -r $cat; then \
/usr/bin/install -c -m 644 $cat $dir/glib20.mo; \
echo "installing $cat as $dir/glib20.mo"; \
  else \
/usr/bin/install -c -m 644 ../../../../po/$cat $dir/glib20.mo; \
echo "installing ../../../../po/$cat as" \
 "$dir/glib20.mo"; \
  fi; \
...
installing ../../../../po/af.gmo as 
/build/1st/glib2.0-2.54.2/debian/tmp/usr/share/locale/af/LC_MESSAGES/glib20.mo
... and the same for many more languages ...
   dh_strip_nondeterminism
...
Normalized 
debian/libglib2.0-data/usr/share/locale/dz/LC_MESSAGES/glib20.mo
... and the same for many more languages ...
...
   dh_builddeb
...
dpkg-deb: building package 'libglib2.0-data' in 
'../libglib2.0-data_2.54.2-2_all.deb'.
tar: ./usr/share/locale/en_CA/LC_MESSAGES/glib20.mo/: Cannot savedir: Not a 
directory
tar: Exiting with failure status due to previous errors
...
dpkg-deb: error: tar -cf subprocess returned error exit status 2
dh_builddeb: dpkg-deb --build debian/libglib2.0-data .. returned exit code 2

Thanks,
smcv

Bug#884741: sudo-ldap: Lacking support for SSSD

[Thore]

Package: sudo-ldap
Version: 1.8.19p1-2.1
Severity: wishlist

Good evening,
while trying to integrate SSSD for LDAP authentication the sudo provider
constantly failed.
After a while of searching for a reason I came across this:

sudo -V
Sudo version 1.8.19p1
Configure options: --prefix=/usr -v --with-all-insults --with-pam
--with-ldap --with-fqdn --with-logging=syslog --with-logfac=authpriv
--with-env-editor --with-editor=/usr/bin/editor
--with-exampledir=/usr/share/doc/sudo-ldap/examples --with-timeout=15
--with-password-timeout=0 --with-passprompt=[sudo] password for %p:
--disable-root-mailer --disable-setresuid
--with-sendmail=/usr/sbin/sendmail --with-rundir=/var/lib/sudo
--with-ldap-conf-file=/etc/sudo-ldap.conf --mandir=/usr/share/man
--libexecdir=/usr/lib/sudo --with-selinux --with-linux-audit


It's simply not compiled with support for sssd. Would it be possible to
ship the package build with the `--with-sssd` flag?

Best regards
Thore

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

Kernel: Linux 4.9.0-3-amd64 (SMP w/1 CPU core)
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)

Versions of packages sudo-ldap depends on:
ii  libaudit1   1:2.6.7-2
ii  libc6   2.24-11+deb9u1
ii  libldap-2.4-2   2.4.44+dfsg-5+deb9u1
ii  libpam-modules  1.1.8-3.6
ii  libpam0g1.1.8-3.6
ii  libselinux1 2.6-3+b3
ii  lsb-base9.20161125

sudo-ldap recommends no packages.

sudo-ldap suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

Bug#883241: chrony: daemon doesn't automatically start

[Andres Salomon]

On Tue, 12 Dec 2017 01:46:08 +0100
Vincent Blut  wrote:

> Hi Andres,
> 
> First of all, I would like to apologize for not having answered
> earlier, but I’m very busy these days.

No worries.  At this point, should we enlist help upstream?  I'm kind
of at a loss for what to do next.


pgpn9VVUlIIMa.pgp
Description: OpenPGP digital signature

Bug#883547: flash-kernel: please allow flavourless kernels

[Vagrant Cascadian]

Control: tag 883547 +patch
On 2017-12-04, Adam Borowski wrote:
> If for whatever reason you want or need to build your own kernels, the
> preferred way these days is "make bindeb-pkg".  It is also a good idea
> to use CONFIG_LOCALVERSION_AUTO=y, which marks the exact tree used to
> build the kernel.
>
> However, with this option, the version is _appended_ after local version,
> thus making it hard to add that "-armmp" string.
...
> Just allowing an empty string flavour doesn't work, as it'll still want a -
> after the version.

I think the following patch should work for this, by setting:

Kernel-Flavor: any

or even an empty value:

Kernel-Flavor:

(though, if that device has existing value in all.db, it will not be
overridden by the empty value).

The patch significantly refactors the use of the check_kflavor function,
and the one place it is called. Essentially, rather than trying to
derive the suffix from file, comparing that against a known list of good
suffixes, it merely checks if the targeted kernel version ends with one
of the good suffixes.

I haven't done extensive testing yet, but I could go ahead any push this
myself once I've done more tests, if nobody objects.


live well,
  vagrant


diff --git a/functions b/functions
index b2ae5be..8dc542d 100644
--- a/functions
+++ b/functions
@@ -86,17 +86,17 @@ mtdsize() {
 }
 
 check_kflavors() {
-   local kfile_suffix="$1"
-   shift
-
-   if [ -z "$kfile_suffix" ]; then
+   local kvers="$1"
+   local kflavor="$2"
+   if [ "$kflavor" = "any" ]; then
+   return 0
+   fi
+   # count flavor+ as valid
+   kvers=${kvers%%+}
+   if [ "${kvers}" != "${kvers%%$kflavor}" ]; then
+   # kernel version ended with flavor
return 0
fi
-   for kflavor; do
-   if [ "$kfile_suffix" = "$kflavor" ] || [ "$kfile_suffix" = 
"$kflavor+" ]; then
-   return 0
-   fi
-   done
return 1
 }
 
@@ -764,18 +764,16 @@ if ! check_supported "$machine"; then
error "Unsupported platform."
 fi
 
-if kflavors="$(get_machine_field "$machine" "Kernel-Flavors")"; then
-   kfile_suffix=""
-   while [ "$kfile_suffix" != "$kfile" ] ; do
-   kfile_suffix=$(get_kfile_suffix "$kfile" "$kfile_suffix")
-
-   if check_kflavors "$kfile_suffix" $kflavors; then
-   break
-   fi
-   done
-fi
+kfile_suffix=""
+kflavors=$(get_machine_field "$machine" "Kernel-Flavors")
+for kflavor in ${kflavors:-"any"} ; do
+   if check_kflavors "$kvers" "$kflavor" ; then
+   kfile_suffix="$kflavor"
+   break
+   fi
+done
 
-if [ "$kfile_suffix" = "$kfile" ]; then
+if [ -z "$kfile_suffix" ]; then
echo "Kernel $kfile does not match any of the expected flavors 
($kflavors), therefore not writing it to flash." >&2
exit 0
 fi
diff --git a/test_functions b/test_functions
index e75b089..eeea52f 100755
--- a/test_functions
+++ b/test_functions
@@ -116,34 +116,26 @@ add_test test_mtdsize
 test_check_kflavors() {
 (
 . "$functions"
-if check_kflavors "ksuffix" "kflavor1" "kflavor2"; then
+if check_kflavors "4.14.0-1-armmp" "armmp-lpae"; then
 echo "Expected check_kflavors to fail with kernel suffix not in 
expected flavors, but it succeeded" >&2
 exit 1
 fi
-if ! check_kflavors "foo" "kflavor1" "foo" "kflavor3"; then
+if ! check_kflavors "4.14.0-1-armmp-lpae" "armmp-lpae"; then
 echo "Expected check_kflavors to succeed with kernel suffix in 
expected flavors, but it failed" >&2
 exit 1
 fi
-if ! check_kflavors "kflavor1-suffix" "klavor1" "kflavor1-suffix" 
"kflavor2"; then
-echo "Expected check_kflavours to succeed with double-barrelled 
kernel suffix in expected flavours, but it failed" >&2
-exit 1
-fi
-if check_kflavors "kflavor1-suffix" "klavor1" "kflavor2"; then
-echo "Expected check_kflavours to fail with double-barrelled 
kernel suffix not in expected flavours, but it succeeded" >&2
-exit 1
-fi
-if ! check_kflavors "" "kflavor1" "kflavor2" "kflavor3"; then
-echo "Expected check_kflavors to succeed with empty kernel suffix, 
but it failed" >&2
-exit 1
-fi
-if check_kflavors "ksuffix+" "kflavor1" "kflavor2"; then
+if check_kflavors "4.14.0-1-armp-lpae+" "armmp"; then
 echo "Expected check_kflavors to fail with kernel suffix (with 
additional +) not in expected flavors, but it succeeded" >&2
 exit 1
 fi
-if ! check_kflavors "foo+" "kflavor1" "foo" "kflavor2"; then
+if ! check_kflavors "4.14.0-1-armmp-lpae+" "armmp-lpae"; then
 echo "Expected check_kflavours to succeed with kernel suffix (with 
additional +) in expected flavors, but it failed" >&2
 exit 

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[John Allwine]

Thanks Adam!

Ack, I just introduced that help2man issue fixing the lintian warnings about 
man pages. Will reorganize a bit to fix that.

The signing-key.asc is for uscan when checking for updates in the watch. Am I 
supposed to sign the orig tar ball?

I left it as UNRELEASED as that was suggested in the walkthrough I went 
through. I can change it to unstable.

Will add the original license of CSG.js as well.

John Allwine
Owner of Allwine Designs
http://www.allwinedesigns.com

> On Dec 18, 2017, at 3:29 PM, Adam Borowski  wrote:
> 
>> On Sun, Dec 17, 2017 at 09:54:10PM -0700, John Allwine wrote:
>> * Package name: stlcmd
>>   Version : 1.0-1
> 
>>  stlcmd - Suite of commands for generating, inspecting and
>> manipulating STL files.
> 
> Alas, it fails to build:
> /bin/sh: 2: help2man: not found
> 
> I also don't see any copyright data for src/csgjs/ which obviously comes
> from a different set of authors.
> 
> The .orig tarball's signature seems to be missing -- despite you apparently
> wanting it to be signed (debian/upstream/signing-key.asc is present).
> 
> The target distribution is set to UNRELEASED, I assume you wanted unstable
> instead, right?
> 
> 
> Meow!
> -- 
> // If you believe in so-called "intellectual property", please immediately
> // cease using counterfeit alphabets.  Instead, contact the nearest temple
> // of Amon, whose priests will provide you with scribal services for all
> // your writing needs, for Reasonable And Non-Discriminatory prices.

Bug#884730: arp-scan: get-oui/get-iab errors: "Wide character in print"

[Hilko Bengen]

Control: tag -1 pending

* Reiner Herrmann:

> # get-oui
> Wide character in print at /usr/sbin/get-oui line 136.
> [...]
> # get-iab
> Wide character in print at /usr/sbin/get-iab line 149.

I have applied a patch to git that fixes this by opening the output file
in UTF-8 mode.

Cheers,
-Hilko

Bug#833190: Please provide an option to not add X-getmail-retrieved-from-mailbox header

[Daniel Kahn Gillmor]

On Mon 2017-12-18 16:00:34 -0600, Charles Cazabon wrote:
> Daniel Kahn Gillmor  wrote:
>>  b) sometimes, i find myself forwarding messages to other people.
>> Depending on the account i'm mailing from, I generally prefer to
>> minimize the amount of automatically-published information about my
>> system setup.
>
> Ok.  I'm a bit of a privacy nut myself, so this seems like a legitimate
> problem that you need a solution for (well, that you created a solution
> for...).  Thanks very much for the patch; that definitely reduced the time I
> needed to find to do this.
>
> I've released getmail v.5.5 with this addion, except I shortened the parameter
> name to record_mailbox.

great, thank you very much!

> One thing from your report, however:
>
>> entirely instead, except for the effect it has on %(mailbox) in the
>> external MDA case.  If you have a solution for that problem, then a fix
>> to just remove the X-getmail-retrieved-from-mailbox header entirely
>> would probably be simpler and involve less maintenance and support going
>> forward.
>
> The added header and the %(mailbox) substitution in external command arguments
> are unrelated; other than using the same source for their data, there's no
> connection between them.  Turning the header off does not break %(mailbox)
> substitution in MDA_external aguments in my testing.
>
> If you can show me how to reproduce this problem, I'll take a look at it.

hm, i found this a while ago, and i don't think i have a reproducer for
it.  I'm not sure what i was thinking.  I'm happy to hear that it
doesn't seem to be a problem!  If i find anything similar, i'll be sure
to mention it on-list here.

Regards,

   --dkg

PS is the getmail development published under any form of revision
   control?  I can work with downloaded tarballs, but if you're using
   git or svn or hg, i might be better able to send you patches that
   align with your current development in the odd case where i come up
   with any clever ideas :)


signature.asc
Description: PGP signature

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

[Carlos Donizete Froes]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pokemmo
   Version : 1.4.2-1
   Upstream Author : Carlos Donizete Froes 
 * URL : https://github.com/coringao/pokemmo
 * License : GPL-3.0+
   Section : contrib/games

  It builds those binary packages:

  pokemmo - Online game based on the Pokemon universe

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/contrib/p/pokemmo/pokemmo_1.4.2-1.dsc

  More information about PokeMMO can be obtained from https://pokemmo.eu.

  Regards,
   Carlos Donizete Froes

Bug#884739: O: python-restless -- lightweight REST miniframework for Python

[W. Martin Borgert]

Package: wnpp
Severity: normal

I orphaning python-restless, because I don't use it anymore.
My team moved to python-djangorestframework instead.

Bug#806500: [Pkg-kde-extras] Bug#806500: Bug#884652: quassel-client: connection password stored in plan Ascii in a chmod 644 file

[Heinrich Schuchardt]

On 12/18/2017 11:33 PM, Diederik de Haas wrote:

On maandag 18 december 2017 23:27:54 CET Heinrich Schuchardt wrote:

Storing the password in the KDE wallet manager would mean that the
password could only be retrieved when the wallet is open.


Problem with that is that it creates a dependency on KDE, while quassel only
needs QT



Another option would be to GPG encrypt the password and ask for the GPK 
private key password when the application is opened. Essentially that is 
what Kwallet does internally.


Best regards

Heinrich

Bug#550360: Very Urgent

[Nadège COQUART]

I am pleased to inform you about an urgent Transaction I have for you, kindly 
contact my Gmail: mrsaliceche...@gmail.com
 For more details.

Best Regards

Bug#883950: debian-policy: allow specifying common licenses with only the identifier

[Jonathan Nieder]

Hi Markus,

Markus Koschany wrote:
> Am 16.12.2017 um 15:55 schrieb Sean Whitton:
>> On Wed, Dec 13 2017, Markus Koschany wrote:

>>> If the Policy editors cannot make a decision with regards to
>>> debian/copyright then we should ask the DPL to seek legal advice and
>>> when necessary start a GR for reasons of legitimacy.
>>
>> If we think this issue is important enough to spend money on that.  I am
>> not convinced it is.
>
> Then we need a GR. Simply claiming that something violates the law
> without proof cannot be the right way for a large project like Debian.
> This is a very important topic because writing debian/copyright is not
> optional in Debian. I simply believe that most people appreciate doing
> something meaningful in their free time.

You are of course free to initiate a GR at any time.

I have no opinion about this particular proposal (allowing specifying
common licenses with only the identifier).  But I am worried at how
black and white you are describing the world to be.

Debian has long had a practice of being extra careful to respect the
wishes of free software authors as expressed in the licenses they
choose.  This goes beyond the minimum legal requirements of license
compliance.  It is not because the project is afraid of being sued but
because at least some in the project consider it to be the right thing
to do.

Here Sean pointed out that just a license name with too little
accompanying text does not appear to be particularly clear to end
users.  That means end users may not know what their rights are, so it
seems worth thinking about.  Fortunately DEP-5 copyright files contain

 Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

so perhaps some information in the copyright-format would be good
enough to help those end users.  Perhaps not.  But I am puzzled that
you seem to think there is only one possible right answer and that it
should be obvious to everybody.

The way you describe the experience of writing a debian/copyright file
is foreign to my own experience.  It sounds like making the process of
generating /usr/share/doc/{package}/copyright using *automated tools*
in a smoother way will be a good avenue for addressing the developer
experience issues you are mentioning.  Then you'd be in a better
position to come up with what the appropriate content of that file
should be to serve end users.

Thanks and hope that helps,
Jonathan

Bug#806500: [Pkg-kde-extras] Bug#806500: Bug#884652: quassel-client: connection password stored in plan Ascii in a chmod 644 file

[Diederik de Haas]

On maandag 18 december 2017 23:27:54 CET Heinrich Schuchardt wrote:
> Storing the password in the KDE wallet manager would mean that the
> password could only be retrieved when the wallet is open.

Problem with that is that it creates a dependency on KDE, while quassel only 
needs QT


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

Bug#884651: RFS: stlcmd/1.0-1 [ITP]

[Adam Borowski]

On Sun, Dec 17, 2017 at 09:54:10PM -0700, John Allwine wrote:
>  * Package name: stlcmd
>Version : 1.0-1

>   stlcmd - Suite of commands for generating, inspecting and
> manipulating STL files.

Alas, it fails to build:
/bin/sh: 2: help2man: not found

I also don't see any copyright data for src/csgjs/ which obviously comes
from a different set of authors.

The .orig tarball's signature seems to be missing -- despite you apparently
wanting it to be signed (debian/upstream/signing-key.asc is present).

The target distribution is set to UNRELEASED, I assume you wanted unstable
instead, right?


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

Bug#806500: [Pkg-kde-extras] Bug#884652: quassel-client: connection password stored in plan Ascii in a chmod 644 file

[Heinrich Schuchardt]

On 12/18/2017 09:08 PM, Felix Geyer wrote:

On Mon, 18 Dec 2017 18:04:19 +0100 Heinrich Schuchardt  
wrote:

Not encoding the password means that any user application can fetch it
and send it to the internet even if ~/.config is chmod 700.

Can anything be worse?


Well, that's the unfortunate state of security on the Linux desktop (and other 
major desktop OSes).
Largely there is no privilege separation between applications.
They all run in the same context so they can't really keep secrets from each 
other.
Technologies like Flatpak and Snappy are trying to solve this by sandboxing 
applications [0].

Felix

[0] https://github.com/flatpak/flatpak/wiki/Sandbox

Storing the password in the KDE wallet manager would mean that the 
password could only be retrieved when the wallet is open.


This is not perfect security but better than having the password 
available at all times.


Best regards

Heinrich

Bug#884595: kernel recognizes keyboards and mice as joysticks

[Markus Koschany]

Am 18.12.2017 um 22:59 schrieb Stephen Kitt:
> On Mon, 18 Dec 2017 17:55:21 +0100, Markus Koschany  wrote:
>> Preliminary work is already available at:
>>
>> https://github.com/denilsonsa/udev-joystick-blacklist
>>
>> If the udev maintainers don't want to create and maintain such a
>> blacklist, then please mark this bug report as "wontfix" accordingly.
>> Please don't reassign it back to affected games and applications.
>> Whether I or someone else wants to provide a patch should not be the
>> criterion for bug assignment.
> 
> ... and the joystick package includes the blacklist linked above. Installing
> that should fix many of this issues.
> 
> Regards,
> 
> Stephen

Alas the joystick package is only optional while udev is priority
important. It is rather unlikely that someone will have it installed
already. The issue is that those people would not even think about a
joystick, they just assume the game/application is broken. It's rather
strange to recommend the installation of joystick when you want to play
a game without one. This issue should be solved in packages which are
guaranteed to be installed on a default desktop computer like udev.




signature.asc
Description: OpenPGP digital signature

Bug#856701: closed by Alf Gaida <aga...@siduction.org> (Bug#856701: fixed in lxqt-metapackages 17)

[Alf Gaida]

Now really done. Thanks.

Bug#884557: diffoscope: please support Android ROM boot.img introspection

[Simon Josefsson]

Yay that was quick, thank you!  I look forward to test it through 
backports once version 89 is released.


/Simon

Bug#884557: diffoscope: please support Android ROM boot.img introspection

[Chris Lamb]

tags 884557 + pending
thanks

Thanks for your help, I've fixed this in Git:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=18364f495ead8352325ac4783a3f35ebcf0297fb


Regards,

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

Bug#833190: Please provide an option to not add X-getmail-retrieved-from-mailbox header

[Charles Cazabon]

Daniel Kahn Gillmor  wrote:
>  b) sometimes, i find myself forwarding messages to other people.
> Depending on the account i'm mailing from, I generally prefer to
> minimize the amount of automatically-published information about my
> system setup.

Ok.  I'm a bit of a privacy nut myself, so this seems like a legitimate
problem that you need a solution for (well, that you created a solution
for...).  Thanks very much for the patch; that definitely reduced the time I
needed to find to do this.

I've released getmail v.5.5 with this addion, except I shortened the parameter
name to record_mailbox.  One thing from your report, however:

> entirely instead, except for the effect it has on %(mailbox) in the
> external MDA case.  If you have a solution for that problem, then a fix
> to just remove the X-getmail-retrieved-from-mailbox header entirely
> would probably be simpler and involve less maintenance and support going
> forward.

The added header and the %(mailbox) substitution in external command arguments
are unrelated; other than using the same source for their data, there's no
connection between them.  Turning the header off does not break %(mailbox)
substitution in MDA_external aguments in my testing.

If you can show me how to reproduce this problem, I'll take a look at it.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---

Bug#884595: kernel recognizes keyboards and mice as joysticks

[Stephen Kitt]

On Mon, 18 Dec 2017 17:55:21 +0100, Markus Koschany  wrote:
> Preliminary work is already available at:
> 
> https://github.com/denilsonsa/udev-joystick-blacklist
> 
> If the udev maintainers don't want to create and maintain such a
> blacklist, then please mark this bug report as "wontfix" accordingly.
> Please don't reassign it back to affected games and applications.
> Whether I or someone else wants to provide a patch should not be the
> criterion for bug assignment.

... and the joystick package includes the blacklist linked above. Installing
that should fix many of this issues.

Regards,

Stephen


pgpONpNKlaC1d.pgp
Description: OpenPGP digital signature

Bug#847611: Patch

[Ian Beckwith]

Hi,

On Mon, Dec 18, 2017 at 09:42:17PM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-12-17 18:35:17 [+0100], Hilko Bengen wrote:
> > Control: tag -1 patch -fixed-upstream
> > 
> > I don't see where the direct struct access issues have been fixed
> > upstream, the source code snapshot available from
> > http://www.kermitproject.org/ckdaily.html still has lots of those.

I'm shamefully MIA at the moment but upstream is active and worth contacting:

f...@columbia.edu

thanks for your help!

Ian.

-- 
Ian Beckwith - i...@debian.org - i...@erislabs.net - http://erislabs.net/ianb/
New key: 4096R/A796 3918 B66A A6DD CFC5  EFF2 17D7 13AD 62E8 8618

Bug#856701: closed by Alf Gaida <aga...@siduction.org> (Bug#856701: fixed in lxqt-metapackages 17)

[Jeremy Bicha]

On Tue, Jul 4, 2017 at 4:57 PM, Debian Bug Tracking System
 wrote:
>  lxqt-metapackages (17) unstable; urgency=medium
>  .
>* Removed the gksu alternative to lxqt-sudo (Closes: #856701)

This was fixed for lxqt-core but not for lxqt which still recommends
lxqt-sudo | gksu

Thanks,
Jeremy Bicha

Bug#884734: Please build with liblua5.3-dev

[Gunnar Hjalmarsson]

Patch attached.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

>From 6d319076c8da3239b4aca14dbe31cbf9243ca9f2 Mon Sep 17 00:00:00 2001
From: Gunnar Hjalmarsson 
Date: Mon, 18 Dec 2017 22:08:06 +0100
Subject: [PATCH] Build with liblua5.3-dev

https://bugs.debian.org/884734
---
 debian/control | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index 0814bd0..4c23370 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ Build-Depends: debhelper (>= 9),
intltool,
libgtk-3-dev,
libibus-1.0-dev (>= 1.4.99.20120917),
-   liblua5.1-dev,
+   liblua5.3-dev,
libpinyin7-dev (>= 1.2.91),
libsqlite3-dev,
libtool,
-- 
2.14.1

Bug#828557: Patch for sslsniff, request for review

[Hilko Bengen]

* Sebastian Andrzej Siewior:

> It is not back compatible with openssl 1.0.2

Aware of that. Chose to ignore backwards compatibility for now.

I took care of the const issue and eliminated the leaks using a
stack-allocated buffer. New patch attached.

Cheers,
-Hilko
Index: sslsniff/SessionCache.cpp
===
--- sslsniff.orig/SessionCache.cpp
+++ sslsniff/SessionCache.cpp
@@ -47,7 +47,9 @@ void SessionCache::removeSessionId(unsig
 }
 
 int SessionCache::setNewSessionId(SSL *s, SSL_SESSION *session) {
-  return setNewSessionId(s, session, session->session_id, session->session_id_length);
+  unsigned int id_length;
+  const unsigned char *id = SSL_SESSION_get_id(session, _length);
+  return setNewSessionId(s, session, (unsigned char*)id, id_length);
 }
 
 int SessionCache::setNewSessionId(SSL *s, SSL_SESSION *session, 
@@ -94,7 +96,7 @@ int SessionCache::setNewSessionId(SSL *s
   return 1;  
 }
 
-SSL_SESSION * SessionCache::getSessionId(SSL *s, unsigned char *id, int idLength, int *ref) {
+SSL_SESSION * SessionCache::getSessionId(SSL *s, const unsigned char *id, int idLength, int *ref) {
   int i;
   unsigned char *b;
 
@@ -117,7 +119,7 @@ SSL_SESSION * SessionCache::getSessionId
 
 // Trampoline Functions.  Yay C.
 
-SSL_SESSION * SessionCache::getSessionIdTramp(SSL *s, unsigned char *id, int idLength, int *ref) {
+SSL_SESSION * SessionCache::getSessionIdTramp(SSL *s, const unsigned char *id, int idLength, int *ref) {
   return SessionCache::getInstance()->getSessionId(s, id, idLength, ref);
 }
 
Index: sslsniff/certificate/Certificate.hpp
===
--- sslsniff.orig/certificate/Certificate.hpp
+++ sslsniff/certificate/Certificate.hpp
@@ -92,7 +92,8 @@ private:
   }
 
   void parseCommonName(X509 *cert) {
-std::string distinguishedName(cert->name);
+char buf[4096];
+std::string distinguishedName(X509_NAME_oneline(X509_get_subject_name(cert), buf, sizeof(buf)));
 std::string::size_type cnIndex = distinguishedName.find("CN=");
 
 if (cnIndex == std::string::npos) throw BadCertificateException();
Index: sslsniff/certificate/TargetedCertificateManager.cpp
===
--- sslsniff.orig/certificate/TargetedCertificateManager.cpp
+++ sslsniff/certificate/TargetedCertificateManager.cpp
@@ -115,8 +115,9 @@ void TargetedCertificateManager::getCert
 
 void TargetedCertificateManager::dump() {
   std::list::iterator i;
+  char buf[4096];
 
   for(i=certificates.begin(); i != certificates.end(); ++i) 
-std::cout << "Certificate: " << (*i)->getCert()->name << std::endl;
+std::cout << "Certificate: " << X509_NAME_oneline(X509_get_subject_name((*i)->getCert()), buf, sizeof(buf)) << std::endl;
 
 }
Index: sslsniff/SessionCache.hpp
===
--- sslsniff.orig/SessionCache.hpp
+++ sslsniff/SessionCache.hpp
@@ -49,12 +49,12 @@ class SessionCache {
 
 public:
   static SessionCache* getInstance();
-  static SSL_SESSION * getSessionIdTramp(SSL *s, unsigned char *id, int idLength, int *ref);
+  static SSL_SESSION * getSessionIdTramp(SSL *s, const unsigned char *id, int idLength, int *ref);
   static int setNewSessionIdTramp(SSL *s, SSL_SESSION *session);
 
   int setNewSessionId(SSL *s, SSL_SESSION *session);
   int setNewSessionId(SSL *s, SSL_SESSION *session, unsigned char *id, int idLength);
-  SSL_SESSION * getSessionId(SSL *s, unsigned char *id, int idLength, int *ref);
+  SSL_SESSION * getSessionId(SSL *s, const unsigned char *id, int idLength, int *ref);
 
 private:
   static SessionCache *sessionCache;

Bug#884738: openjpeg2: CVE-2017-17480: stack-based buffer overflow in pgxtovolume function in jp3d/convert.c

[Salvatore Bonaccorso]

Source: openjpeg2
Version: 2.1.0-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/uclouvain/openjpeg/issues/1044

Hi,

the following vulnerability was published for openjpeg2.

CVE-2017-17480[0]:
| In OpenJPEG 2.3.0, a stack-based buffer overflow was discovered in the
| pgxtovolume function in jp3d/convert.c. The vulnerability causes an
| out-of-bounds write, which may lead to remote denial of service or
| possibly remote code execution.

Note there is as well the CVE-2017-17479 assignment, for the
jpwl/convert.c part. But AFAICS the Debian packagagins has overall
BUILD_JPWL:BOOL=OFF, so that one can be considered unimportant since
only present as in the source, but not in the resulting binary
packages. Though if upstream fixes the both issues, then fixes could
be applied.

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-2017-17480
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17480
[1] https://github.com/uclouvain/openjpeg/issues/1044

Regards,
Salvatore

Bug#884737: aptitude(8) man page is not documenting the exit code

[H.-Dirk Schmitt]

Package: aptitude 
Version: 0.8.9-1

Checked in ubuntu (xenial) and on https://manpages.debian.org/unstable/
aptitude/aptitude.8.en.html I couldn't find any informations about the
exit (return) codes of the aptitude program.

Please extend/complete the documentation

Bug#806500: [Pkg-kde-extras] Bug#806500: Bug#884652: quassel-client: connection password stored in plan Ascii in a chmod 644 file

[Diederik de Haas]

On maandag 18 december 2017 21:08:46 CET Felix Geyer wrote:
> Well, that's the unfortunate state of security on the Linux desktop (and
> other major desktop OSes). Largely there is no privilege separation between
> applications.
> They all run in the same context so they can't really keep secrets from each
> other.

That is true.
Even though the file is protected by the security of ~/.config, I see no 
reason why the file itself isn't 600 or 660.

But the real problem is that the password is stored in plaintext and I find 
that inexcusable.

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

Bug#884736: python-policy: Documents wrong location for Python 3 local modules

[Dmitry Shachnev]

Source: python3-defaults
Version: 3.6.4~rc1-2
Severity: minor

Dear maintainers,

The Python Policy (version 0.10.1.1) mentions wrong directory to use for
local Python 3 modules. I think it needs this fix:

--- old/debian/python-policy.dbk2017-09-01 06:29:49 +
+++ new/debian/python-policy.dbk2017-12-18 20:31:10 +
@@ -368,7 +368,7 @@

  A special directory is dedicated to public Python modules
  installed by the local administrator,
- /usr/lib/python3/dist-packages for all Python 3 
versions,
+ /usr/local/lib/python3/dist-packages for all 
Python 3 versions,
  
/usr/local/lib/python2.Y/dist-packages
 for
  Python 2.


Note that the patch is against python-defaults, since the version of policy
in python3-defaults is terribly outdated. However filing the bug here as
requested by the maintainer.

Also, it is not clear what is the difference in purpose between this paragraph
(dist-packages) and the next paragraph (site-packages). Maybe it should be
mentioned that the latter is for compatibility with some upstream tools.

Finally, the last two paragraphs about architecture-independent modules can
probably be dropped as they are no longer different from normal modules.

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#884735: libsndfile: CVE-2017-17456 CVE-2017-17457

[Salvatore Bonaccorso]

Source: libsndfile
Version: 1.0.28-4
Severity: important
Tags: security upstream
Forwarded: https://github.com/erikd/libsndfile/issues/344

Hi,

the following vulnerabilities were published for libsndfile.

CVE-2017-17456[0]:
| The function d2alaw_array() in alaw.c of libsndfile 1.0.29pre1 may lead
| to a remote DoS attack (SEGV on unknown address 0x), a
| different vulnerability than CVE-2017-14245.

CVE-2017-17457[1]:
| The function d2ulaw_array() in ulaw.c of libsndfile 1.0.29pre1 may lead
| to a remote DoS attack (SEGV on unknown address 0x), a
| different vulnerability than CVE-2017-14246.

Note, as mentioned in the CVE assingments, that are different from
CVE-2017-14245 and CVE-2017-14246, crash poc files are attaced to
upstream bug report and demostrable with e.g. an ASAN build of
libsndfile.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2017-17456
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17456
[1] https://security-tracker.debian.org/tracker/CVE-2017-17457
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-17457

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#884734: Please build with liblua5.3-dev

[Gunnar Hjalmarsson]

Package: src:ibus-libpinyin
Version: 1.7.3-2

ibus-libpinyin currently includes the rather old package liblua5.1-dev 
in the build dependencies. Please change it to liblua5.3-dev.


I successfully built the package with that change. It probably works 
because of 0002-fixes-lua-5.2-compile.patch.


--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj

Bug#884733: dirb - request for features (patch included)

[Philippe Thierry]

Package: dirb
Version: 2.22+dfsg-2
Severity: wishlist
Tags: patch

See attached message for more info. 


 Message d'origine 
De : Mathieu BAEUMLER 
Envoyé : 13 décembre 2017 10:26:59 GMT+01:00
À : "p...@reseau-libre.net" 
Objet : dirb - request for features (patch included)

Hello,

One of the tools I happen to use sometimes on Kali is dirb. In two specific 
cases, I needed two options from the libcurl:

-  CURLOPT_PATH_AS_IS : don't squash/merge /../ ./ sequences in the 
path, useful when there is a directory traversal vulnerability

-  CURLOPT_SSLCERT : use a client certificate

I implemented the needed changes, with the resulting two quilt patches 
(path-as-is.patch to be applied before client_cert.patch).

Could you include them in the debian/kali package?

Regards,

--
Mathieu Baeumler

-- 
 O   Philippe Thierry. 
/Y\/   GPG: 7010 9a3c e210 763e 6341 4581 c257 b91b cdaf c1ea
o#o

client_cert.patch
Description: Binary data


path-as-is.patch
Description: Binary data


series
Description: Binary data

Bug#878674: [Pkg-javascript-devel] Bug#878674: Bug#878674: nodejs segfaults when building d3-* with webpack

[Jérémy Lal]

2017-11-14 10:35 GMT+01:00 Jérémy Lal :

>
>
> 2017-11-14 8:51 GMT+01:00 Pirate Praveen :
>
>> On ചൊവ്വ 14 നവംബര്‍ 2017 03:51 രാവിലെ, Jérémy Lal wrote:
>> > Using only debian packages (and no npm-installed module) I can't
>> > reproduce the segfault in debian/sid:
>> >
>> > dev:~/Software/debian/node-d3-zoom/node-d3-zoom master$ webpack
>> --config
>> > debian/webpack.config.js index.js build/d3-zoom.js --target=web
>> > --output-library=d3-zoom --output-library-target=umd --module-bind
>> > 'js=babel-loader'
>>
>> [...]
>>
>> > WARNING in ./src/zoom.js
>> > 235:4-11 "export 'default' (imported as 'noevent') was not found in
>> > './noevent'
>> >
>> > WARNING in ./src/zoom.js
>> > 260:6-13 "export 'default' (imported as 'noevent') was not found in
>> > './noevent'
>> >
>> > WARNING in ./src/zoom.js
>> > 272:6-13 "export 'default' (imported as 'noevent') was not found in
>> > './noevent'
>> >
>> > WARNING in ./src/zoom.js
>> > 285:4-11 "export 'default' (imported as 'noevent') was not found in
>> > './noevent'
>> >
>> > WARNING in ./src/zoom.js
>> > 335:4-11 "export 'default' (imported as 'noevent') was not found in
>> > './noevent'
>> >
>> > WARNING in ./src/zoom.js
>> > 377:74-82 "export 'default' (imported as 'constant') was not found in
>> > './constant'
>> >
>> > WARNING in ./src/zoom.js
>> > 381:70-78 "export 'default' (imported as 'constant') was not found in
>> > './constant'
>> >
>> > WARNING in ./src/zoom.js
>> > 385:73-81 "export 'default' (imported as 'constant') was not found in
>> > './constant'
>> >
>> > WARNING in ./src/zoom.js
>> > 389:70-78 "export 'default' (imported as 'constant') was not found in
>> > './constant'
>> > dev:~/Software/debian/node-d3-zoom/node-d3-zoom master$
>> >
>>
>> It seems you are not using the .babelrc, do an quilt push -a and rerun
>> the command.
>>
>
> Right ! Now i reproduce the segfault.
> I tried with nodejs 6.12.0, uv 1.15.0, zlib1g 1.2.11 without success.
> Now i'm trying with embedded copies of uv and zlib... if you see it not
> crashing with nodesource, i'll eventually find what's causing it.
>
>
Good news: i don't get this segfault using nodejs 8.9.3 that i just
uploaded to experimental.

Jérémy

Bug#833190: Please provide an option to not add X-getmail-retrieved-from-mailbox header

[Daniel Kahn Gillmor]

Hi Charles--

On Mon 2017-12-18 10:23:03 -0600, Charles Cazabon wrote:
> i.e. what is the reason/justification for the feature?  What problems is the
> presence of this header field causing?

I have two reasons i care about it:

 a) i prefer to have the local copy of my message have the exact same
bytestream as the copy on the server.  Depending on the filesystems
on the server, this allows me to make comparisons with tools like
sha256sum or rsync when evaluating who has what file.  The
X-getmail-retrieved-from-mailbox changes the bytestream, which makes
these techniques fail.

 b) sometimes, i find myself forwarding messages to other people.
Depending on the account i'm mailing from, I generally prefer to
minimize the amount of automatically-published information about my
system setup.  In particular, i think we should generally discourage
mail user agents from publishing User-Agent: or equivalent headers,
and we should discourage tools like GnuPG from injecting presence or
version information in message parts that they're involved in
generating.

if X-getmail-retrieved-from-mailbox is present in the forwarded
message, it leaks some information about the toolchain in use that
doesn't need to be leaked.

> I ask because every added feature has added costs for me in terms of
> maintenance and support, and for users, in terms of initial setup and
> configuration.

I sympathize with this concern.  sorry the original report wasn't
clearer about it.

I would have submitted a simplifying patch to just remove the header
entirely instead, except for the effect it has on %(mailbox) in the
external MDA case.  If you have a solution for that problem, then a fix
to just remove the X-getmail-retrieved-from-mailbox header entirely
would probably be simpler and involve less maintenance and support going
forward.

let me know if that makes sense, or if you have any other questions.

 --dkg


signature.asc
Description: PGP signature

Bug#638753: libhdf5-serial-1.8.7: threadsafe memory leaks

[Gilles Filippini]

Control: tags -1 + moreinfo

Hi,

On Sun, 21 Aug 2011 17:35:26 +0200 Jerome BENOIT 
wrote:
> Package: libhdf5-serial-1.8.7
> Severity: wishlist
> 
> Hello:
> 
> Since a while I have noticed via valgrind some memory leaks let by the 
> function `H5Zfilter_avail':
> the following Code reproduce the issue:
> 
> --8><---
> // gcc -o test_H5Zfilter_avail test_H5Zfilter_avail.c -lhdf5
> // valgrind --leak-check=yes --leak-check=full --show-reachable=yes 
> ./test_H5Zfilter_avail
> //
> 
> #include 
> #include 
> 
> // http://wiki.hdfgroup.org
> #ifndef H5Z_BZIP2
> #define H5Z_BZIP2 307
> #endif
> 
> int main(int nargs, char *args[]) {
> 
>   fprintf(stderr,
>   "filter with identifier `%d' is %s registered\n",
>   H5Z_BZIP2,
>   (H5Zfilter_avail(H5Z_BZIP2))?"already":"not"
>   );
> 
>   return (0); }
> --><8-
> 
> A closer look shows that the memory leakes are let by the threadsafe 
> machinery.

When trying to reproduce this bug I only get 'still reachable' class
memory leaks, with the very same small memory footprint no matter how
many times H5Zfilter_avail was called. Is that what you experienced?
I tend to consider 'still reachable' memory leaks not leaks. Especially
when there're stable.

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature

Bug#884732: ITP: pypostal -- Python bindings to libpostal for fast international address parsing/normalisation

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura 

* Package name: pypostal
  Version : 1.0
  Upstream Author : openvenues, MapZen
* URL : https://github.com/openvenues/pypostal/
* License : MIT
  Programming Lang: C
  Description : Python bindings to libpostal for fast international address 
parsing/normalisation

Official Python bindings to https://github.com/openvenues/libpostal,
a fast statistical parser/normaliser for street addresses anywhere in
the world.

Bug#847611: Patch

[Sebastian Andrzej Siewior]

On 2017-12-17 18:35:17 [+0100], Hilko Bengen wrote:
> Control: tag -1 patch -fixed-upstream
> 
> I don't see where the direct struct access issues have been fixed
> upstream, the source code snapshot available from
> http://www.kermitproject.org/ckdaily.html still has lots of those.
> 
> I have prepared a patch that fixes building with OpenSSL 1.1 and would
> appreciate a review.

>Index: ckermit-302/ck_ssl.c
>===
>--- ckermit-302.orig/ck_ssl.c
>+++ ckermit-302/ck_ssl.c
>@@ -975,13 +981,15 @@ static DH *
> get_dh1536()
> {
> DH *dh=NULL;
>+BIGNUM *p, *g;
> 
> if ((dh=DH_new()) == NULL)
> return(NULL);
>-dh->p=BN_bin2bn(dh1536_p,sizeof(dh1536_p),NULL);
>-dh->g=BN_bin2bn(dh1536_g,sizeof(dh1536_g),NULL);
>-if ((dh->p == NULL) || (dh->g == NULL))
>+p=BN_bin2bn(dh1536_p,sizeof(dh1536_p),NULL);
>+g=BN_bin2bn(dh1536_g,sizeof(dh1536_g),NULL);
>+if ((p == NULL) || (g == NULL))
> return(NULL);
>+DH_set0_pqg(dh, p, NULL, g);
> return(dh);

Those DH values should not be static / compiled in (e.g. the same on
every server) but not the scope of the patch…

> }
> 
>@@ -1457,13 +1468,15 @@ the build.\r\n\r\n");
> 
> #ifdef ZLIB
> cm = COMP_zlib();
>-if (cm != NULL && cm->type != NID_undef) {
>+if (cm != NULL && SSL_COMP_get_id(cm) != NID_undef) {
> SSL_COMP_add_compression_method(0xe0, cm); /* EAY's ZLIB ID */
> }
> #endif /* ZLIB */
>+#if 0 /* COMP_rle has apparently been removed in OpenSSL 1.1 */
> cm = COMP_rle();
> if (cm != NULL && cm->type != NID_undef)
> SSL_COMP_add_compression_method(0xe1, cm); /* EAY's RLE ID */
>+#endif
yes, but that ZLIB in the above shouldn't work since it should not be
compiled in :) Anyway, a check for OpenSSL version instead that if0
would be better.

>@@ -2583,7 +2598,7 @@ ssl_anonymous_cipher(ssl) SSL * ssl;
> int
> ssl_verify_crl(int ok, X509_STORE_CTX *ctx)
> {
>-X509_OBJECT obj;
>+X509_OBJECT *obj = X509_OBJECT_new();
this may be NULL

> X509_NAME *subject = NULL;
> X509_NAME *issuer = NULL;
> X509 *xs = NULL;
>@@ -2649,11 +2664,10 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
>  * Try to retrieve a CRL corresponding to the _subject_ of
>  * the current certificate in order to verify it's integrity.
>  */

and before that where were two return statemens where you would leak
`obj'.

>-memset((char *), 0, sizeof(obj));
> X509_STORE_CTX_init(store_ctx, crl_store, NULL, NULL);
>-rc = X509_STORE_get_by_subject(store_ctx, X509_LU_CRL, subject, );
>+rc = X509_STORE_get_by_subject(store_ctx, X509_LU_CRL, subject, obj);
> X509_STORE_CTX_cleanup(store_ctx);
>-crl = obj.data.crl;
>+crl = X509_OBJECT_get0_X509_CRL(obj);
> if (rc > 0 && crl != NULL) {
> /*
>  * Verify the signature on this CRL
>@@ -2661,7 +2675,7 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
> if (X509_CRL_verify(crl, X509_get_pubkey(xs)) <= 0) {
> fprintf(stderr, "Invalid signature on CRL!\n");
> X509_STORE_CTX_set_error(ctx, X509_V_ERR_CRL_SIGNATURE_FAILURE);
>-X509_OBJECT_free_contents();
>+X509_OBJECT_free(obj);
> X509_STORE_CTX_free(store_ctx);
> return 0;
> }
>@@ -2674,7 +2688,7 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
> fprintf(stderr, "Found CRL has invalid nextUpdate field.\n");
> X509_STORE_CTX_set_error(ctx,
> 
> X509_V_ERR_ERROR_IN_CRL_NEXT_UPDATE_FIELD);
>-X509_OBJECT_free_contents();
>+X509_OBJECT_free();
> X509_STORE_CTX_free(store_ctx);
> return 0;
> }
>@@ -2683,11 +2697,11 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
> "Found CRL is expired - revoking all certificates until you get updated 
> CRL.\n"
> );
> X509_STORE_CTX_set_error(ctx, X509_V_ERR_CRL_HAS_EXPIRED);
>-X509_OBJECT_free_contents();
>+X509_OBJECT_free();
> X509_STORE_CTX_free(store_ctx);
> return 0;
> }
>-X509_OBJECT_free_contents();
>+X509_OBJECT_free();

I *think* that this won't work. You free `obj' here and in the next hunk
you use it again.

> }
> 
> /*
>@@ -2698,7 +2712,7 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
> X509_STORE_CTX_init(store_ctx, crl_store, NULL, NULL);
> rc = X509_STORE_get_by_subject(store_ctx, X509_LU_CRL, issuer, );
> X509_STORE_CTX_free(store_ctx);   /* calls 
> X509_STORE_CTX_cleanup() */
>-crl = obj.data.crl;
>+crl = X509_OBJECT_get0_X509_CRL(obj);
> if (rc > 0 && crl != NULL) {
> /*
>  * Check if the current certificate is revoked by this CRL
>@@ -2706,19 +2720,19 @@ ssl_verify_crl(int ok, X509_STORE_CTX *c
> n = sk_X509_REVOKED_num(X509_CRL_get_REVOKED(crl));
> for (i = 0; i < n; i++) {
> revoked 

Bug#884731: ITP: libpostal -- parse and normalise street addresses around the world

[Andrew Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrew Shadura 

* Package name: libpostal
  Version : 1.0.0
  Upstream Author : openvenues, Mapzen
* URL : https://github.com/openvenues/libpostal
* License : MIT
  Programming Lang: C
  Description : parse and normalise street addresses around the world

libpostal is a C library for parsing/normalizing street addresses around
the world using statistical NLP and open data. The goal of this project
is to understand location-based strings in every language, everywhere.

libpostal's international address parser uses machine learning
(Conditional Random Fields) and is trained on over 1 billion addresses
in every inhabited country on Earth. It uses use OpenStreetMap and
OpenAddresses as sources of structured addresses, and the OpenCage
address format templates to construct the training data, supplementing
with containing polygons, and generating sub-building components like
apartment/floor numbers and PO boxes.

-- 
Cheers,
  Andrew

Bug#882082: that patch has been packaged a month ago

[Joseph Herlant]

Hi,

As showed https://mentors.debian.net/package/gnome-shell-pomodoro or
explained https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882005 the new
version has been packaged and uploaded to Mentors about 1 month ago.
It conains that fix already.
I haven't heard about my usual sponsor those last few weeks so I don't know
when it's going to be pushed, but it's already packaged.

Joseph

Bug#884730: arp-scan: get-oui/get-iab errors: "Wide character in print"

[Reiner Herrmann]

Package: arp-scan
Version: 1.9-3

Dear Maintainer,

the get-oui and get-iab tools included in arp-scan are printing error
messages while running.
At first I thought that they were no longer working at all,
but the files are still downloaded, they just print confusing messages:

# get-oui
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
Wide character in print at /usr/sbin/get-oui line 136.
# get-iab
Wide character in print at /usr/sbin/get-iab line 149.


Kind regards,
  Reiner


signature.asc
Description: PGP signature

Bug#854518: opensp : multiarch support

[Christoph Berg]

Control: severity -1 important

Re: jhcha54008 2017-02-07 <20170207223525.GB3598@debirf-dominicain>
> Package: opensp
> Version: 1.5.2-13
> Severity: wishlist
> 
> Hi,
> 
> I wonder if multiarch support could be added to opensp
> (perhaps a field Multi-Arch: foreign).
> 
> It would make package cross-compilation easier (some packages
> build-depends on opensp, e.g. aboot should)

postgresql-10 would need M-A: foreign in opensp as well. (Or else we
need to paper over it by using B-D: opensp:native.)

Thanks,
Christoph

Bug#884725: gnome-shell-pomodoro: New upstream 0.13.4

[Joseph Herlant]

Hi Richard,

As showed https://mentors.debian.net/package/gnome-shell-pomodoro or
explained https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882005 the new
version has been packaged and uploaded to Mentors about 1 month ago.
I haven't heard about my usual sponsor those last few weeks so I don't know
when it's going to be pushed, but it's already packaged.

Joseph

Bug#884354: game-data-packager: [doom] default behaviour of downloading and packaging e1m{4, 8}b is wrong

[Fabian Greffrath]

Am Freitag, den 15.12.2017, 22:31 + schrieb Simon McVittie:
> I've marked them as activated_by both the PWAD and the downloadable
> archive, so that supplying either one on the command-line, supplying a
> directory containing either one, or having the PWAD installed will all
> cause the package to be built.

Thank you very much for this!

 - Fabian


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

Bug#828557: Patch for sslsniff, request for review

[Sebastian Andrzej Siewior]

On 2017-12-17 19:32:52 [+0100], Hilko Bengen wrote:
> Control: tag -1 patch
> 
> Hi,
> 
> here's a patch that fixes the OpenSSL-1.1-related FTBFS for sslsniff.
> 
> I'd appreciate a review of the patch.

It is not back compatible with openssl 1.0.2

>Index: sslsniff/SessionCache.cpp
>===
>--- sslsniff.orig/SessionCache.cpp
>+++ sslsniff/SessionCache.cpp
>@@ -47,7 +47,9 @@ void SessionCache::removeSessionId(unsig
> }
> 
> int SessionCache::setNewSessionId(SSL *s, SSL_SESSION *session) {
>-  return setNewSessionId(s, session, session->session_id, 
>session->session_id_length);
>+  unsigned int id_length;
>+  const unsigned char *id = SSL_SESSION_get_id(session, _length);
>+  return setNewSessionId(s, session, (unsigned char*)id, id_length);
> }
> 
> int SessionCache::setNewSessionId(SSL *s, SSL_SESSION *session, 
>@@ -117,8 +119,8 @@ SSL_SESSION * SessionCache::getSessionId
> 
> // Trampoline Functions.  Yay C.
> 
>-SSL_SESSION * SessionCache::getSessionIdTramp(SSL *s, unsigned char *id, int 
>idLength, int *ref) {
>-  return SessionCache::getInstance()->getSessionId(s, id, idLength, ref);
>+SSL_SESSION * SessionCache::getSessionIdTramp(SSL *s, const unsigned char 
>*id, int idLength, int *ref) {
>+  return SessionCache::getInstance()->getSessionId(s, (unsigned char*)id, 
>idLength, ref);

since you propage that `const' to getSessionIdTramp(), you could propage it
further and drop that cast.

> }
> 
> int SessionCache::setNewSessionIdTramp(SSL *s, SSL_SESSION *session) {
>Index: sslsniff/SessionCache.hpp
>===
>--- sslsniff.orig/SessionCache.hpp
>+++ sslsniff/SessionCache.hpp
>@@ -49,7 +49,7 @@ class SessionCache {
> 
> public:
>   static SessionCache* getInstance();
>-  static SSL_SESSION * getSessionIdTramp(SSL *s, unsigned char *id, int 
>idLength, int *ref);
>+  static SSL_SESSION * getSessionIdTramp(SSL *s, const unsigned char *id, int 
>idLength, int *ref);
>   static int setNewSessionIdTramp(SSL *s, SSL_SESSION *session);
> 
>   int setNewSessionId(SSL *s, SSL_SESSION *session);
>Index: sslsniff/certificate/Certificate.hpp
>===
>--- sslsniff.orig/certificate/Certificate.hpp
>+++ sslsniff/certificate/Certificate.hpp
>@@ -92,7 +92,7 @@ private:
>   }
> 
>   void parseCommonName(X509 *cert) {
>-std::string distinguishedName(cert->name);
>+std::string 
>distinguishedName(X509_NAME_oneline(X509_get_subject_name(cert), NULL, 0));

X509_NAME_oneline() allocates memory which you leak.

> std::string::size_type cnIndex = distinguishedName.find("CN=");

That part grabs the hostname from the CN= part of the subject. I haven't
look *why* this is done but usually one wants to check the "subject
alternative name" extension and the content may conttain an asterisk.

> if (cnIndex == std::string::npos) throw BadCertificateException();
>Index: sslsniff/certificate/TargetedCertificateManager.cpp
>===
>--- sslsniff.orig/certificate/TargetedCertificateManager.cpp
>+++ sslsniff/certificate/TargetedCertificateManager.cpp
>@@ -117,6 +117,6 @@ void TargetedCertificateManager::dump()
>   std::list::iterator i;
> 
>   for(i=certificates.begin(); i != certificates.end(); ++i) 
>-std::cout << "Certificate: " << (*i)->getCert()->name << std::endl;
>+std::cout << "Certificate: " << 
>X509_NAME_oneline(X509_get_subject_name((*i)->getCert()), NULL, 0) << 
>std::endl;

also a leak.

> 
> }

> Cheers,
> -Hilko

Sebastian

Bug#806500: [Pkg-kde-extras] Bug#884652: quassel-client: connection password stored in plan Ascii in a chmod 644 file

[Felix Geyer]

On Mon, 18 Dec 2017 18:04:19 +0100 Heinrich Schuchardt  
wrote:
> Not encoding the password means that any user application can fetch it 
> and send it to the internet even if ~/.config is chmod 700.
> 
> Can anything be worse?

Well, that's the unfortunate state of security on the Linux desktop (and other 
major desktop OSes).
Largely there is no privilege separation between applications.
They all run in the same context so they can't really keep secrets from each 
other.
Technologies like Flatpak and Snappy are trying to solve this by sandboxing 
applications [0].

Felix

[0] https://github.com/flatpak/flatpak/wiki/Sandbox

Bug#800503: Bug#884354: game-data-packager: [doom] default behaviour of downloading and packaging e1m{4, 8}b is wrong

[Fabian Greffrath]

Am Freitag, den 15.12.2017, 21:48 + schrieb Simon McVittie:
> There's already a feature request,
> .
> It will need non-free game code from https://github.com/yquake2/zaero
> to be compiled on-demand, similar to the two official expansions (but
> unlike CTF, for which the game-code is GPL, so I just bundled it into
> yquake2).

Ah, right, I forgot that "mods" are actually shared libraries in Quake
2.

 - Fabian


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

Bug#856439: fakeroot doesn't detect and handle message queue and semaphore id collision

[Martin Dorey]

On Fri, 3 Mar 2017 02:13:08 + Martin Dorey  wrote: 
> I see a flaw in my patch that could lead to it closing the same id twice if 
> it has to retry twice - I should have reset the ids after cleanup().

Please find the fixed patch belatedly attached.  The problem fixed by this 
patch - the id collision - definitely wasn't what was causing my original 
problem.  Indeed, I convinced myself by experiment that the id collision is as 
vanishingly rare in practice as you might expect in theory.  My original 
problem continues unabated in Debian Stretch - sufficiently frequently to be 
annoying but not frequently enough to be tractable.  On at least one occasion, 
the failure struck a semaphore-using program of our own devising that wasn't 
fakeroot, making me think that I won't be back here with a final answer.  In 
order to stop wasting time on this, I've just given in to the temptation of 
putting a retry loop round the failing operation.


faked.c.patch2
Description: faked.c.patch2

Bug#884695: transition: dpdk

[Luca Boccassi]

On Mon, 2017-12-18 at 18:42 +, Luca Boccassi wrote:
> On Mon, 2017-12-18 at 19:33 +0100, Emilio Pozuelo Monfort wrote:
> > Control: tags -1 confirmed
> > 
> > On 18/12/17 13:16, Luca Boccassi wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: transition
> > > 
> > > Dear release team,
> > > 
> > > We would like to move the new DPDK LTS release 17.11-2 from
> > > experimental to unstable. This breaks the various libraries ABI
> > > compat,
> > > so a transition is needed.
> > > 
> > > https://tracker.debian.org/pkg/dpdk
> > > 
> > > Reverse build dependency source package:
> > > 
> > > collectd
> > > 
> > > The reverse dependency builds fine with the new version of DPDK
> > > without
> > > any source changes. Note that it currently FTBS due to a
> > > different
> > > and
> > > unrelated build-dep [1]. Tested by disabling that other plugin
> > > and
> > > rebuilding with the new DPDK version.
> > > 
> > > The new DPDK packages are all in experimental, having passed the
> > > NEW
> > > queue, and have built on all supported architectures.
> > > 
> > > Note that from this release we started to follow a boost-like
> > > model, so
> > > the ABI revision is named after the upstream major version (eg:
> > > librte-
> > > eal3 -> librte-eal17.11). This is done because most libraries
> > > built
> > > from DPDK break ABI compat on every single major release.
> > 
> > There are no rdeps so no transition tracker... Since you confirm
> > the
> > only
> > build-rdep is fine, please go ahead.
> > 
> > Emilio
> 
> Ah I see, I though reverse-recommends needed a transition as well.
> Thanks!

The upload to unstable is done. Thanks!

-- 
Kind regards,
Luca Boccassi

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

Bug#884729: libgctp FTCBFS: uses the build architecture compiler during make install

[Helmut Grohne]

Source: libgctp
Version: 2.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libgctp fails to cross build from source, because it runs the build
architecture compiler during make install. dh_auto_build passes a
suitable CC to make, but dh_auto_install doesn't. Presumably, the
makefile has missing dependencies. Rather than fixing the dependencies,
the attached patch opts to simply pass CC to make_install as well.
Please consider applying it.

Helmut
diff --minimal -Nru libgctp-2.0/debian/changelog libgctp-2.0/debian/changelog
--- libgctp-2.0/debian/changelog2017-07-28 16:23:28.0 +0200
+++ libgctp-2.0/debian/changelog2017-12-18 20:47:38.0 +0100
@@ -1,3 +1,10 @@
+libgctp (2.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Also pass CC to make install. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Dec 2017 20:47:38 +0100
+
 libgctp (2.0-2) unstable; urgency=medium
 
   * Move to Standards-Version: 4.0.0; no changes required
diff --minimal -Nru libgctp-2.0/debian/rules libgctp-2.0/debian/rules
--- libgctp-2.0/debian/rules2014-05-15 20:19:59.0 +0200
+++ libgctp-2.0/debian/rules2017-12-18 20:47:37.0 +0100
@@ -3,6 +3,8 @@
 # Comment out this line for debugging
 #export DH_VERBOSE:=1
 
+-include /usr/share/dpkg/buildtools.mk
+
 # The magic rule for debhelper
 %:
dh $@ --sourcedirectory=source
@@ -19,7 +21,7 @@
 override_dh_auto_install:
sed -e 's/@libdir@/$(LIBDIR)/' < gcpt.pc | \
sed -e 's/@VERSION@/$(VERSION)/' > gctp.pc
-   dh_auto_install
+   dh_auto_install -- 'CC=$(CC)'
mkdir -p debian/libgctp0d/$(LIBDIR)
cp source/libgctp.so.0d debian/libgctp0d/$(LIBDIR)
dh_link -p libgctp-dev $(LIBDIR)/libgctp.so.0d  $(LIBDIR)/libgctp.so

Bug#884728: xmount FTCBFS: does not pass cross flags to cmake

[Helmut Grohne]

Source: xmount
Version: 0.7.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

xmount fails to cross build from source, because it does not pass cross
flags to cmake. After deferring that task to dh_auto_configure, xmount
cross builds successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru xmount-0.7.3/debian/changelog xmount-0.7.3/debian/changelog
--- xmount-0.7.3/debian/changelog   2015-07-03 01:50:16.0 +0200
+++ xmount-0.7.3/debian/changelog   2017-12-18 20:41:47.0 +0100
@@ -1,3 +1,10 @@
+xmount (0.7.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_configure pass cross flags to cmake. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Dec 2017 20:41:47 +0100
+
 xmount (0.7.3-1) unstable; urgency=medium
 
   * [adaf426] Imported new upstream release 0.7.3
diff --minimal -Nru xmount-0.7.3/debian/rules xmount-0.7.3/debian/rules
--- xmount-0.7.3/debian/rules   2015-07-03 01:49:24.0 +0200
+++ xmount-0.7.3/debian/rules   2017-12-18 20:41:45.0 +0100
@@ -15,4 +15,4 @@
dh $@
 
 override_dh_auto_configure:
-   cmake -DCMAKE_C_FLAGS="$(CMAKE_C_FLAGS)" -DCMAKE_BUILD_TYPE=Release 
-DCMAKE_INSTALL_PREFIX=/usr
+   dh_auto_configure -- -DCMAKE_C_FLAGS="$(CMAKE_C_FLAGS)" 
-DCMAKE_BUILD_TYPE=Release

Bug#884727: sc FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: sc
Version: 7.16-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sc fails to cross build from source, because it passes the build
architecture compiler to make. Deferring the choice of CC to
dh_auto_build fixes the cross build. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru sc-7.16/debian/changelog sc-7.16/debian/changelog
--- sc-7.16/debian/changelog2014-05-18 22:13:43.0 +0200
+++ sc-7.16/debian/changelog2017-12-18 20:37:39.0 +0100
@@ -1,3 +1,10 @@
+sc (7.16-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass a suitable CC to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 18 Dec 2017 20:37:39 +0100
+
 sc (7.16-4) unstable; urgency=low
 
   * debian/patches/function_definitions
diff --minimal -Nru sc-7.16/debian/rules sc-7.16/debian/rules
--- sc-7.16/debian/rules2014-05-18 22:11:00.0 +0200
+++ sc-7.16/debian/rules2017-12-18 20:37:35.0 +0100
@@ -28,7 +28,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) all sc.1 psc.1 CC=gcc CFLAGS="-O2 -Wall -DSYSV3 -ffloat-store"
+   dh_auto_build -- all sc.1 psc.1 CFLAGS="-O2 -Wall -DSYSV3 -ffloat-store"
#/usr/bin/docbook-to-man debian/sc.sgml > sc.1
 
touch build-stamp