Bug#941263: gcc-9: ICE in mips_split_move when compiling qtwebengine-opensource-src on mipsel

[Matthias Klose]

On 27.09.19 12:48, Dmitry Shachnev wrote:

It looks like it is already fixed upstream:

https://gcc.gnu.org/viewcvs/gcc?view=revision=273174

So please backport that change to the Debian package.


The Debian MIPS maintainers should get this backported upstream, then it get's 
updated in the package.


Matthias

Bug#941333:

[Clinton H]

The new user might assume their wifi device is not supported. The new
user might not realize that their device is supported, but their
manual wifi switch is set to OFF.

Bug#941340: sooperlooper: Should sooperlooper be removed from Debian?

[Olly Betts]

Source: sooperlooper
Version: 1.7.3~dfsg0-3
Severity: normal

I think it's time to remove the sooperlooper package:

* last upstream release was nearly 5 years ago
* last package update was more than 2.5 years ago
* has low popcon - inst:223 vote:20
* has no reverse dependencies (according to dak rm)
* 4 open bugs, only the one from 2010 has any maintainer response
* a blocker for the current wxwidgets3.0-gtk3 transition.

If there are no objections within two weeks, I'll turn this into an RM
bug.

Cheers,
Olly

Bug#941339: delaboratory: Should delaboratory be removed from Debian?

[Olly Betts]

Source: delaboratory
Version: 0.8-2+b2
Severity: normal

I think it's time to remove the delaboratory package:

* upstream is inactive (last upstream activity seems to be 2013)
* package has only ever been uploaded twice, most recently 5.5 years ago
* low popcon - inst:105 vote:16
* blocker for the current wxwidgets3.0-gtk3 transition
* maintainer seems unresponsive

If there are no objections within two weeks, I'll turn this into an RM
bug.

Cheers,
Olly

Bug#941338: spek: Should spek be removed from Debian?

[Olly Betts]

Source: spek
Version: 0.8.2-4
Severity: normal

I think it's time to remove the spek package:

* last upstream release was 6.5 years ago 
* last package update was 3.5 years ago
* has low popcon - inst:331 vote:57
* has no reverse dependencies (according to dak rm)
* 2 open bugs, neither with any maintainer response
* I had to NMU for the last wxWidgets transition 5 years ago, and
  it's now a blocker for the current wxwidgets3.0-gtk3 transition.

If there are no objections within two weeks, I'll turn this into an RM
bug.

Cheers,
Olly

Bug#523513: rdate: should not set time if network delay is too big

[Eriberto Mota]

Control: fixed 523513 upstream/1.10

Dear maintainer,

The suggested patch was applied in 1.10 version[1].

[1] 
https://github.com/resurrecting-open-source-projects/openrdate/commit/45f494e9edcd2c78ea8bbe62e5f3daeff67c457e

Please, consider closing this bug in next Debian revision.

Regards,

Eriberto

Bug#935931: Re: Bug#935931: debian-installer: Reinstalling Debian on a current Debian installation without erasing or fomatting the home folder

[Daniel]

Hi Nicholas,

thanks for your reply, I really appreciated your constructive approach.

I use Debian since 2007 and I did a lot of installation, I personally 
use a FrankenDebian (testing with pinning toward SID and Experimental) 
however when I install Debian on other machines I install definitely the 
current stable available. I have been performing exclusively desktop 
installations and while I consider the best option separating /home 
recently I found myself not able to get the right balance between "/", 
"/home" and "swap". The default "/" assigned is often too small while 
sometimes I wasted gigabyte never used. The "swap" with the amount of 
ram available today is always more accessory and with the SSD disk the 
trend is to reduce its use the most. Eventually I stopped to create a 
"swap" partition in favor of a "swap-file" (like Raspian e.g.); hence I 
also stopped to create "/" and "/home" but just "/" and still as LVM; at 
this point you don't have anymore issue with the space and if you need 
you can add all the disks you want because it is still a LVM partition.


Now the case I am figuring out is the one you didn't separe "/" and 
"/home" (however the installer is still creating "swap") but you need to 
reinstall Debian because you screwed it up for some reason. Now a smart 
installer before to start everything takes its time to check the disk 
and discovers that you have, along a crypted disk and a LVM group, also 
a previous version of Debian hence check the users and it asks you if 
you want keep all the users, just one, etc... and then it reinstalls the 
system and recovers the setting from the user(s) you selected, without 
creating a FrankenDebian but just a fresh and **smart** installation.


This leads in my opinion in creating a further voice for the Debian 
install: **the desktop installation**; Standard and Advanced are 
eventually too generic and do not target properly the desktop cases. If 
the D-I was properly able to read LUKS and LVM during the installation 
time, and if was also able to perform a smart installation as described 
in the paragraph above, a Desktop installation should be:


1. Create an encrypted partition by default (LUKS + LVM);

2. install everything in / ;

3. not create a "swap partition" but a swap-file.

I also add that:

4. should deactivate root user by default, which is now considering a 
best practice;


5. should deactivate the source repos and asking to activate the 
"contrib" and "non-free" repos (like in Advanced Mode).



I don't see any complicated tasks to achieve, others Linux distro 
already started to move in this direction while other *nix operative 
systems already do that since a long time.


The only issues I see here are the resistance to the changes and the 
fact that actually the D-I has some issue to recognize the encrypted 
partitions and if you want reinstall Debian you can't preserve any of 
the partitions you want because it will consider the encrypted disks as 
blanks.



Best regards,

Daniel




On 9/28/19 12:01 AM, Nicholas D Steeves wrote:

Geert Stappers  writes:


On Fri, Sep 27, 2019 at 05:19:06PM -0400, Daniel wrote:

Holger Wansing wrote:

The debian-installer supports similar use case via the "separate
partition for /home" approach.

to reinstall Debian on top of itself without overwriting the home partition.

Yes, that is what Holger is telling.

I think Daniel is requesting an option that does something like this:

   find /install-target -maxdepth 1 | grep -v 'home\|lost+found' | xargs rm -rf

Maybe this way isn't robust enough, but active mounts shouldn't have
their mount points removed, because

   rm: cannot remove '/install-target/foo': Device or resource busy

BTW, Daniel, you can decruft your system with "apt purge --autoremove
foo", which also deletes config in /etc and will notify you if any files
remain in /var.  One of the greatest strengths of Debian is that unlike
other operating systems, smooth upgrades between stable versions are
taken seriously...gravely seriously...so one never needs to reinstall.
The only things that I've seen that have ever required action are
packages that needed manual configuration updates in /etc (equally
solvable by apt purge), and obsolete/broken configuration in /home/user
(not solved if this feature request is implemented).  What problem is
this feature request intended to solve?  FrankenDebian?

   https://wiki.debian.org/DontBreakDebian


Cheers,
Nicholas

P.S. apt install installation-birthday  :-)

Bug#941337: ITP: golang-github-pascaldekloe-goe -- enterprise tooling library for Golang

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 consul

   Package name: golang-github-pascaldekloe-goe
Version: 0.1.0
Upstream Author: Pascal S. de Kloe
License: CC0-1.0 (a.k.a. "Public Domain")
URL: https://github.com/pascaldekloe/goe
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-pascaldekloe-goe
Description: enterprise tooling library for Golang
 Common enterprise features for Golang.


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

Bug#929475: "webext-privacy-badger" should only recommend "fonts-open-sans"

[Protesilaos Stavrou]

Markus Koschany  writes:

> On Fri, 24 May 2019 11:33:04 +0300 Protesilaos Stavrou
>  wrote:
>> Package: webext-privacy-badger
>> Version: 2019.2.19-1
>> Severity: wishlist
>>
>> Dear Maintainer,
>>
>> I believe the package "webext-privacy-badger" in Buster should not
>> depend on "fonts-open-sans".  The latter can be defined as a recommended
>> package instead.
>>
>> Looking at Privacy Badger's source code (via `apt download`) it appears
>> that "Open Sans" is only used on "firstRun.html".  That font is defined
>> in /usr/share/webext/privacy-badger/skin/css/firstRun.css
>>
>> A fallback "sans-serif" font is specified as well, meaning that the text
>> will be displayed properly even without package "fonts-open-sans".
>>
>> Thank you for your attention!
>>
>> Best regards,
>> Protesilaos
>
> The open-sans fonts is used by upstream and shipped with the upstream
> sources. We just replace it with a system fonts to reduce the fonts
> duplication in Debian. The intention is really to display the firstRun
> page with this fonts and not with something else and to ensure that we
> have to depend on fonts-open-sans. This is not a bug.
>
> Regards,
>
> Markus Koschany

Dear Markus,

Thank you for the clarification!

All the best,
Protesilaos

Bug#941335: COLUMNS ignored too

[積丹尼 Dan Jacobson]

At least
$ COLUMNS=88 lynx URL #works. But
$ COLUMNS=88 w3m  URL #doesn't.

Bug#940701: nautilus-dropbox: diff for NMU version 2019.02.14-0.1

[Luke Faraone]

On Thu, 19 Sep 2019 at 08:24, Laurent Bigonville  wrote:
> I've prepared an NMU for nautilus-dropbox (versioned as 2019.02.14-0.1) and
> uploaded it to DELAYED/10. Please feel free to tell me if I
> should delay it longer.

Hi,

Please cancel this NMU. I'm unable to upload because this includes a
new orig.tar.bz. Note that I was engaging with Unit 193 on Mentors,
please check that before NMUing next time.

Cheers,
Luke Faraone

Bug#941336: nvidia-legacy-340xx-kernel-dkms: Kernel module nvidia-legacy-340xx can't be loaded

[Paul Vojta]

Package: nvidia-legacy-340xx-kernel-dkms
Version: 340.107-6
Severity: normal

Dear Maintainer,

The kernel module nvidia-legacy-340xx cannot be loaded.

When running kernel 4.19.0-6, the screen goes black when I boot, at around
the time when I'd normally see a login prompt from getty (I log in the
old-fashioned way with getty, then run startx to start up X, with the fvwm
window manager).

I am able to log in remotely, however.  The output of "lsmod | grep nvidia",
for example, is:

nvidia  10584064  4
drm   495616  2 nvidia

both before and after running "modprobe nvidia-legacy-340xx" (no idea where
the nvidia module is coming from -- it's not in /lib/modules).
This modprobe command returns status 0, produces no output, and doesn't
produce any output in syslog.

When I run kernel 4.19.0-5, I am able to log in on the console but can't
start up X:

(EE) [drm] Failed to open DRM device for pci::05:00.0: -19
(EE) open /dev/dri/card0: No such file or directory

(full Xorg.0.log available upon request).  The command "lsmod | grep nvidia"
produces no output.  The command "modprobe nvidia-legacy-340xx" produces the
output

modprobe: ERROR: could not insert 'nvidia_legacy_340xx': Exec format 
error

and the following line in syslog:

Sep 28 18:33:58 tashkent kernel: [  244.081593] module: x86/modules: 
Skipping invalid relocation target, existing value is nonzero for type 1, loc 
36d97521, val c18215f9

I am able to run under the nouveau driver, but xdvi is really slow (comparable
to a 300-baud terminal from the 1970s).

The hardware is MacMini 4,1.


-- Package-specific info:
uname -a:
Linux tashkent 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20) 
x86_64 GNU/Linux

/proc/version:
Linux version 4.19.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.67-2+deb10u1 (2019-09-20)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  340.107  Thu May 24 21:54:01 
PDT 2018
GCC version:  gcc version 8.3.0 (Debian 8.3.0-6) 

lspci 'display controller [030?]':
05:00.0 VGA compatible controller [0300]: NVIDIA Corporation MCP89 [GeForce 
320M] [10de:08a4] (rev a2) (prog-if 00 [VGA controller])
Subsystem: Apple Inc. MCP89 [GeForce 320M] [106b:00c0]
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: nvidia
Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw 1 root video 226,   0 Sep 28 18:41 /dev/dri/card0
crw-rw-rw- 1 root root  195,   0 Sep 28 18:41 /dev/nvidia0
crw-rw-rw- 1 root root  195, 255 Sep 28 18:41 /dev/nvidiactl

/dev/dri/by-path:
total 0
lrwxrwxrwx 1 root root 8 Sep 28 18:41 pci-:05:00.0-card -> ../card0
video:x:44:vojta

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Sep 27 18:45 /etc/alternatives/glx -> 
/usr/lib/nvidia
lrwxrwxrwx 1 root root   42 Sep 27 18:45 
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   44 Sep 27 18:45 
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   41 Sep 27 18:45 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Sep 27 18:45 
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Sep 27 18:45 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Sep 27 18:45 
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   48 Sep 27 18:45 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   48 Sep 27 18:45 
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Sep 27 18:45 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Sep 27 18:45 
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu -> 
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   45 Sep 27 18:45 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   45 Sep 27 18:45 
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu -> 
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Sep 27 18:45 
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu -> 

Bug#941335: make -cols work when browsing too

[積丹尼 Dan Jacobson]

Package: w3m
Version: 0.5.3-37+b1
X-Debbugs-Cc: yama...@jpl.org

Man page says:

   Browser options
   -cols num
  with stdout as destination; HTML is rendered to lines of num 
characters


Well it should work also for

$ w3m -cols 88   
https://www.nytimes.com/2019/09/25/opinion/huawei-internet-security.html

not just for

$ w3m -cols 88 -dump 
https://www.nytimes.com/2019/09/25/opinion/huawei-internet-security.html

Why can't I browse the article at the width I want? Why do I have to
-dump first and then use "less" or "more" to read the article?

In fact it isn't even a "Browser option" if one cannot use it when
browsing.

And it doesn't even die with an error when it is being ignored.

Bug#688481: [copyright-format] Clarify that trailing slashes in directory names are invalid.

[Russ Allbery]

Nicolas Boulenguez  writes:

> --- a/copyright-format-1.0.xml
> +++ b/copyright-format-1.0.xml
> @@ -659,6 +659,17 @@
>  Exclusions are only supported by adding Files
>  paragraphs to override the previous match.
>
> +  
> +This syntax does not distinguish file names from directory
> +names; a trailing slash in a pattern will never match any
> +actual path. A whole directory tree may be selected with a
> +pattern like "foo/*".
> +  
> +  
> +The space character, used to separate patterns, cannot be
> +escaped with a backslash. A path like "foo bar" may be
> +selected with a pattern like "foo?bar".
> +  
>  
>  
>

Seconded, thanks.

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

Bug#941198: initscripts: packages should ship systemd units

[Russ Allbery]

Sean Whitton  writes:

> I don't currently have any reason to doubt we have a project consensus
> that systemd unit files should be included in packages in addition to
> sysvinit scripts, so I hope we can make this change.

I agree.  This seems entirely reasonable to me.  Both the behavior and the
inherent documentation are better with unit files, and systemd is the
default init system so that's an advantage for a lot of our users.

That said, if anyone does object to this, please do speak up and explain
why this would be a problem.

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

Bug#941334: ITP: golang-github-zclconf-go-cty -- type system for dynamic values in Golang applications

[Dmitry Smirnov]

Package: wnpp
Severity: wishlist
Owner: Dmitry Smirnov 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Control: affects -1 nomad

   Package name: golang-github-zclconf-go-cty
Version: 1.1.0
Upstream Author: Martin Atkins
License: Expat
URL: https://github.com/zclconf/go-cty
Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-github-zclconf-go-cty
Description: type system for dynamic values in Golang applications
 cty (pronounced "see-tie") is a dynamic type system for applications
 written in Go that need to represent user-supplied values without losing
 type information. The primary intended use is for implementing
 configuration languages, but other uses may be possible too.


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

Bug#941333: Wifi network detection during installation. Suggested improvement.

[Andy Simpkins]

Right now you would get a "no network device found" / "no netwirk found" / 
"unable obtain an IP address" message.

Is this not sufficiant?

You are given the option to go back and try again.  Please remember that it is 
also possible that no wifi device wiuld have been detected either.

Lets face it if you do happen to have a wifi adapter that has been detected (or 
you have loaded non free firmware for) and it does not detect the network AND 
offer you any other wifi ssid to pick from, then you are already going to 
notice that somthing isn't right.

/Andy


On 28 September 2019 23:38:48 BST, Clinton H <49studeba...@gmail.com> wrote:
>Package: cdrom
>
>If no wifi networks are detected, could you display a "If using a
>laptop, check that the manual wifi switch is set to ON." warning
>message and then retry detecting wifi networks. If the manual wifi
>switch is set to OFF, then wifi networks will not be detected.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#941332: Corrupt package during installation from CD ISO. Suggested improvements

[Clinton H]

Package: cdrom

During the "base install" of Debian from a CD ISO I got an error that
the vim package was corrupt. Could you do the following:

1) Add a "skip" package button. The installer could skip installation
of the package and then download and install the package after
installation of the OS. Display a warning message that the OS may be
unstable.

2) Add a "retry" button. A user could download and save the package
and the correct folder structure to a separate cd or usb drive. The
installer would then install the non-corrupt package.

3) If the user selected a network connection that has internet access,
the installer could download and then install a replacement package.

If one package is corrupt, the user can not continue installation.
Downloading an entire new ISO is a waste of bandwidth, if one package
is corrupt.

Bug#941333: Wifi network detection during installation. Suggested improvement.

[Clinton H]

Package: cdrom

If no wifi networks are detected, could you display a "If using a
laptop, check that the manual wifi switch is set to ON." warning
message and then retry detecting wifi networks. If the manual wifi
switch is set to OFF, then wifi networks will not be detected.

Bug#936099: rust-num-traits: test failure on i386

[Gianfranco Costamagna]

control: tags -1 patch

On Fri, 30 Aug 2019 08:57:01 +0200 Gianfranco Costamagna 
 wrote:
> Source: rust-num-traits
> Version: 0.2.8-1
> Severity: serious
> Forwarded: https://github.com/rust-num/num-traits/issues/124
> 
> Hello, looks like enabling the testsuite resulted in a failure on i386 
> architecture.
> Could you please have a look?
> thanks
> 
> Gianfranco
> 

Patch upstream

G.
> 

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Adam Borowski]

On Sat, Sep 28, 2019 at 02:53:56AM +0200, Thorsten Glaser wrote:
> On Fri, 27 Sep 2019, Mark Hindley wrote:
> 
> > Thanks. The aim of preventing accidental removal of systemd is very
> > reasonable. However, using this approach the hurdle you create even to a 
> > user
> > who really wants to uninstall is pretty high. Few people will continue 
> > having
> > seen the 'You are about to do something potentially harmful' warning.
> 
> And isn’t that precisely the goal? To prevent most users from
> “just hitting Enter” to switch away from the default?

That's for when you're knowingly doing something very unusual, that in
normal circumstances breaks your whole system.

Using a different supported init system is not something that counts here.

> I’d assume people wanting to install elogind to proceed
> according to documentation telling them that this message
> is expected (but to still review what APT wants to do!)
> (or just have enough of a clue about Debian to do this
> anyway) so this is what I’d suggested, independent even
> of the rest of the discussion.

You might be comfortable with overriding all safety barriers, but that's not
something for regular users.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol,
⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month.
⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake,
⠈⠳⣄ etc), let the drink age at least 3-6 months.

Bug#941036: cacti: CVE-2019-16723

[Salvatore Bonaccorso]

Hi Paul,

On Tue, Sep 24, 2019 at 09:02:58PM +0200, Paul Gevers wrote:
> Hi,
> 
> Although not 100% sure yet, I seriously doubt that old stable is
> affected as version 1.0.0 has this:
> 
> -feature: New Graph Permissions system designed to make permissions
> simple to manage
> 
> So I believe the affected code was only introduced then.

I tried to get an idea here, but still I'm not sure 100%. Isn't for
instance the is_graph_allowed check missing in e.g. graph_xport.php,
so before accessing the graph_info, there is no check for if the user
is allowed to access the graph. For other parts this is done in
0.8.8h.

When in doupt, I rather would prefer to "wrongly" mark something as
affected rather than triage it as not-affected, and later to be turned
wrong.

Although the CVE assignment is somehow specific to the graph_json.php
part, which is not present in 0.8.8h I'm raising still the above, as
upstream has at least decided to cover the other changes for
permission checks in the two related commits.

Is upstream available to check and to confirm the stretch version is
not affected despite the potential missing permission checks there?

Regards,
Salvatore

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Thorsten Glaser]

On Fri, 27 Sep 2019, Mark Hindley wrote:

> Thanks. The aim of preventing accidental removal of systemd is very
> reasonable. However, using this approach the hurdle you create even to a user
> who really wants to uninstall is pretty high. Few people will continue having
> seen the 'You are about to do something potentially harmful' warning.

And isn’t that precisely the goal? To prevent most users from
“just hitting Enter” to switch away from the default?

I’d assume people wanting to install elogind to proceed
according to documentation telling them that this message
is expected (but to still review what APT wants to do!)
(or just have enough of a clue about Debian to do this
anyway) so this is what I’d suggested, independent even
of the rest of the discussion.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Thorsten Glaser]

On Fri, 27 Sep 2019, Adam Borowski wrote:

> > The "init" package has the "Important: yes" control field which as I

> That flag is not for "without an explicit user choice".  It's for "you're
> breaking the packaging system, far more than ignoring dependencies".

This is wrong.

> It's the biggest hammer dpkg has.

This is wrong; the biggest hammer is Conflicts without Replaces,
or Pre-Depends.

bye,
//mirabilos
-- 
Sometimes they [people] care too much: pretty printers [and syntax highligh-
ting, d.A.] mechanically produce pretty output that accentuates irrelevant
detail in the program, which is as sensible as putting all the prepositions
in English text in bold font.   -- Rob Pike in "Notes on Programming in C"

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Thorsten Glaser]

On Fri, 27 Sep 2019, Julien Cristau wrote:

> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.

I’ve proposed to suggest to the systemd maintainers to add
Important: yes to libsystemd0. (On a different level, adding
it to systemd instead would… probably… have the same effect.)

I think that should fully solve this concern; I’ve got quite
the number of personal packages using Important: yes and have
experience with it.

bye,
//mirabilos
-- 
15:41⎜ Somebody write a testsuite for helloworld :-)

Bug#933582: BD on texlive-generic-extra which isn't build anymore and isn't in bullseye

[Steve Langasek]

Package: python-pymzml
Followup-For: Bug #933582
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

This can be fixed by replacing texlive-generic-extra with a build-dependency
on texlive-plain-extra which replaces it.

In the process of fixing this in Ubuntu, I also found that python-pymzml
FTBFS due to use of an obsolete sphinx extension, so I've included a fix for
that as well in the attached patch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru python-pymzml-0.7.6-dfsg/debian/control 
python-pymzml-0.7.6-dfsg/debian/control
--- python-pymzml-0.7.6-dfsg/debian/control 2018-02-02 16:42:13.0 
-0800
+++ python-pymzml-0.7.6-dfsg/debian/control 2019-09-27 17:21:35.0 
-0700
@@ -12,7 +12,7 @@
dpkg-dev (>= 1.16.1~)
 Build-Depends-Indep: doxygen (>= 1.8.1.2), 
  latexmk,
- texlive-generic-extra, 
+ texlive-plain-extra,
  texlive-extra-utils, 
  texlive-latex-extra, 
  texlive-latex-recommended,
diff -Nru python-pymzml-0.7.6-dfsg/debian/patches/series 
python-pymzml-0.7.6-dfsg/debian/patches/series
--- python-pymzml-0.7.6-dfsg/debian/patches/series  2015-11-25 
10:28:46.0 -0800
+++ python-pymzml-0.7.6-dfsg/debian/patches/series  2019-09-27 
17:21:35.0 -0700
@@ -1,2 +1,3 @@
 doc-config.patch
 remove-shebang-line.patch
+sphinx-imgmath.patch
diff -Nru python-pymzml-0.7.6-dfsg/debian/patches/sphinx-imgmath.patch 
python-pymzml-0.7.6-dfsg/debian/patches/sphinx-imgmath.patch
--- python-pymzml-0.7.6-dfsg/debian/patches/sphinx-imgmath.patch
1969-12-31 16:00:00.0 -0800
+++ python-pymzml-0.7.6-dfsg/debian/patches/sphinx-imgmath.patch
2019-09-27 17:21:35.0 -0700
@@ -0,0 +1,17 @@
+Description: replace obsoleted sphinx.ext.pngmath with sphinx.ext.imgmath
+Author: Steve Langasek 
+Last-Updated: 2019-09-27
+
+Index: python-pymzml-0.7.6-dfsg/Documentation_src/source/conf.py
+===
+--- python-pymzml-0.7.6-dfsg.orig/Documentation_src/source/conf.py
 python-pymzml-0.7.6-dfsg/Documentation_src/source/conf.py
+@@ -30,7 +30,7 @@
+ extensions = [
+ 'sphinx.ext.autodoc',
+ 'sphinx.ext.todo',
+-'sphinx.ext.pngmath'#,
++'sphinx.ext.imgmath'#,
+ # 'sphinx.ext.napoleon',
+ # 'sphinx.ext.viewcode'
+ ]

Bug#941331: rubocop: new upstream release 0.74.0

[Gabriel Filion]

Package: rubocop
Version: 0.52.1+dfsg-1
Severity: normal

Hello,

There's been multiple upstream releases since the currently packaged version.
The current latest release is 0.74.0.

version 0.52 was released on december 12th 2017

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

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

Versions of packages rubocop depends on:
ii  ruby1:2.5.1
ii  ruby-parallel   1.12.1-2
ii  ruby-powerpack  0.1.1-4
ii  ruby-progressbar1.9.0-2
ii  ruby-rainbow3.0.0-2
ii  ruby-unicode-display-width  1.1.3-1
ii  ruby-whitequark-parser  2.4.0.2-1

rubocop recommends no packages.

rubocop suggests no packages.

-- no debconf information

Bug#929475: "webext-privacy-badger" should only recommend "fonts-open-sans"

[Markus Koschany]

On Fri, 24 May 2019 11:33:04 +0300 Protesilaos Stavrou
 wrote:
> Package: webext-privacy-badger
> Version: 2019.2.19-1
> Severity: wishlist
> 
> Dear Maintainer,
> 
> I believe the package "webext-privacy-badger" in Buster should not 
> depend on "fonts-open-sans".  The latter can be defined as a recommended 
> package instead.
> 
> Looking at Privacy Badger's source code (via `apt download`) it appears 
> that "Open Sans" is only used on "firstRun.html".  That font is defined 
> in /usr/share/webext/privacy-badger/skin/css/firstRun.css
> 
> A fallback "sans-serif" font is specified as well, meaning that the text 
> will be displayed properly even without package "fonts-open-sans".
> 
> Thank you for your attention!
> 
> Best regards,
> Protesilaos

The open-sans fonts is used by upstream and shipped with the upstream
sources. We just replace it with a system fonts to reduce the fonts
duplication in Debian. The intention is really to display the firstRun
page with this fonts and not with something else and to ensure that we
have to depend on fonts-open-sans. This is not a bug.

Regards,

Markus Koschany





signature.asc
Description: OpenPGP digital signature

Bug#941330: undocumented limitation/dependency in dh_elpa_test

[Nicholas D Steeves]

Package: dh-elpa
Version: 2.0.2~bpo10+2
Severity: normal

dh-elpa-test appears to have an undocumented hard dependency on
(ert-run-test-batch-and-exit), specifically "-and-exit", and this
one-function expression must appear as the final line of the defined
ert_helper.

Steps to reproduce:

d/elpa-test: ert_helper = debian/ert-helper.el
debian/ert-helper.el: (ert-run-tests-batch)
Then run "dh_elpa_test" in a src:pkg with failing tests.

Result:

ERT test output failure, but there's no big block of
"dh_elpa_test…exit code 1" in the shell, and the exit code is 0 (PASS).

Expected result:

Big block of "dh_elpa_test: emacs -batch…-l debian/ert-helper.el returned exit 
code 1" with an exit code 2 in the shell (FAIL).
--

If this is a documentation bug, then the above requirement should be 
documented, plus it would be nice to have an example snippet of how to kill 
emacs from within ert-helper.el in such a way that status FAILED is correctly 
passed through.


Regards,
Nicholas

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

Kernel: Linux 4.19.72-rt25 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_USER  <- I have to disable an i915 feature due to 
buggy BIOS
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dh-elpa depends on:
ii  debhelper   12.1.1
ii  dh-make-perl0.105
ii  emacs   1:26.1+1-3.2+deb10u1
ii  emacs-gtk [emacs]   1:26.1+1-3.2+deb10u1
ii  libarray-utils-perl 0.5-1
ii  libconfig-tiny-perl 2.23-1
ii  libdebian-source-perl   0.105
ii  libdpkg-perl1.19.7
ii  libfile-find-rule-perl  0.34-1
ii  libtext-glob-perl   0.10-1
ii  perl5.28.1-6

dh-elpa recommends no packages.

dh-elpa suggests no packages.

-- no debconf information

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Thorsten Glaser]

On Sat, 28 Sep 2019, Cristian Ionescu-Idbohrn wrote:

> 1. install sysvinit-core; that removes systemd-sysv but nothing else 
>systemd related

> Souldn't that work?

It would, if but for libpam-systemd having a (somewhat questionable
but understandable) dependency on systemd-sysv. This is basically
what spawned this thread.

So we’ll not be going there.

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!

Bug#941329: /usr/bin/grep-excuses: grep-excuses: Mention --autopkgtests switch as well in usage output

[Salvatore Bonaccorso]

Package: devscripts
Version: 2.19.6
Severity: minor
File: /usr/bin/grep-excuses

Hi

grep-excuses manpage documents the --autopkgtests whilst this is
missing in the usage text from grep-excuses.

Regards,
Salvatore

Bug#941328: [curl] A lot of new puzzling and seemingly useless output in "verbose"

[Roman Mamedov]

Package: curl
Version: 7.64.0-4
Severity: normal

Up until now "curl -v" was reasonably useful for debugging a connection issue
or for posting to others to demonstrate issues with their website.

But currently its signal to noise ration has plummeted -- what is all this
"Expire in" garbage, and is it really useful for anything?

Seems more like leftovers of debug output useful only to developers of curl
itself, not for any real-world usage.

Stretch version 7.52.1-5+deb9u9 not affected.

# curl -Iv4 ya.ru
* Expire in 0 ms for 6 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 0 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 1 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 2 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 3 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 3 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 4 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 5 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 5 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 6 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 6 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 10 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 10 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 8 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 11 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 11 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 14 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 14 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 15 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 15 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 16 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
* Expire in 50 ms for 1 (transfer 0x55cb96de7d00)
*   Trying 87.250.250.242...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55cb96de7d00)
* Connected to ya.ru (87.250.250.242) port 80 (#0)
> HEAD / HTTP/1.1
> Host: ya.ru
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 302 Found
HTTP/1.1 302 Found
< Location: https://ya.ru/
Location: 

Bug#941128: xorg-server FTBFS

[Niels Thykier]

Control: reassign -1 xorg-server
Control: retitle -1 xorg-server: build target must depend on build-*
Control: tags -1 ftbfs

Timo Aaltonen:
> Package: debhelper
> Severity: important
> 
> Hi, debhelper 12.4 was fine but the current one broke xorg-server build,
> build-indep isn't run at all. With the old version it was run right in
> the beginning:
> 
> dh build --with quilt,autoreconf --parallel
>debian/rules build-indep
> make[1]: Entering directory '/<>'
> mkdir -p build-source
> tar \
> --owner=0 --group=0 \
> --transform 's,^,xorg-server/,' \
> --exclude=debian \
> --exclude=autom4te.cache \
> -cf - * | xz > build-source/xorg-server.tar.xz
> tar: build-source/xorg-server.tar.xz: file changed as we read it
>> build-source-stamp
> dh build-indep --with quilt,autoreconf --parallel
>dh_quilt_patch -i -O--parallel
> Applying patch 001_fedora_extramodes.patch
> patching file hw/xfree86/common/extramodes
> ...
> 
> but now it's skipped:
> 
> dh build --with quilt,autoreconf --parallel
>dh_quilt_patch -O--parallel
> Applying patch 001_fedora_extramodes.patch
> patching file hw/xfree86/common/extramodes
> ...
> 
> 
> 

Hi,

This problem is fundamentally caused by xorg-server's "build" target not
invoking build-arch and build-indep (eventually).  The xorg-server
package is assumed to invoke all relevant build steps as a part of the
build target itself but it fails to do the build-arch and build-indep
steps as a part of its build target.

Previous debhelper behaviour just happened to work around that issue.

Thanks,
~Niels

Bug#941327: ruby-rspec-puppet: new upstream release 2.7.5

[Gabriel Filion]

Package: ruby-rspec-puppet
Version: 2.6.1-1
Severity: normal

Hi,

The version of rspec-puppet that's currently in sid is quite old: it dates
back to 2017. Upstream has seen a good number of releases since then and it
would be nice to have a fresher version of this code in unstable.

Cheers!


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

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

Versions of packages ruby-rspec-puppet depends on:
ii  puppet-common  5.5.10-4
ii  ruby   1:2.5.1
ii  ruby-rspec 3.8.0c0e1m0s0-1

ruby-rspec-puppet recommends no packages.

ruby-rspec-puppet suggests no packages.

-- no debconf information

Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful

[Mark Hindley]

On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote:
> On Fri, Sep 27, 2019 at 09:19:10AM -0400, Sam Hartman wrote:
> So one thing I think we should ensure is we don't end up uninstalling
> systemd without an explicit user choice.

Julien,

I appreciate that you are suggesting some additional protection is required
against this. However, it appears that the way APT handles the current
dependencies already require explicit user choice to be made.

Testing on a basic sid desktop install with systemd as pid 1 I get the following
behaviour:

 - apt install libelogind0

   Generates the apt "You are about to do something potentially harmful.  To
   continue type in the phrase 'Yes, do as I say!'" warning.

 - apt install elogind
 - apt install libpam-elogind

   For both of these APT fails to find a solution.

   The only way make it find an solution is to explicitly request installation
   of sysvinit-core such as 'apt install libpam-elogind sysvinit-core'

So I am not sure any changes are required in order to enforce explicit
instruction before attempting removal of systemd.

Is this sufficient?

Mark
test@DebianUnstable: ~test@DebianUnstable:~$ dpkg -l systemd*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name  Version  Architecture Description
+++-=---===
ii  systemd   242-7amd64system and service manager
un  systemd-container   (no description available)
un  systemd-shim(no description available)
ii  systemd-sysv  242-7amd64system and service manager - 
SysV links
test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install libelogind0
Reading package lists... Done
Building dependency tree... 
Reading state information... Done
The following packages were automatically installed and are no longer required:
  acl avahi-daemon colord-data gir1.2-matemenu-2.0 gnome-accessibility-themes 
gnome-themes-extra gnome-themes-extra-data gtk2-engines-pixbuf libargon2-1 
libavahi-core7
  libayatana-appindicator3-1 libayatana-ido3-0.4-0 libayatana-indicator3-7 
libcolorhug2 libcryptsetup12 libdaemon0 libdbusmenu-glib4 libdbusmenu-gtk3-4 
libgd3
  libgphoto2-6 libgphoto2-l10n libgphoto2-port12 libgusb2 libieee1284-3 
libindicator3-7 liblightdm-gobject-1-0 libmate-menu2 libmate-panel-applet-4-1
  libmateweather-common libmateweather1 libnss-mdns libplymouth4 librda-common 
librda0 libsane libsane-common libsnmp-base libsnmp30 lightdm-gtk-greeter 
mate-menus
  mate-panel-common mate-polkit-common menu menu-xdg sane-utils update-inetd
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  colord init libnss-systemd libpam-systemd libsystemd0 lightdm mate-panel 
mate-polkit plymouth plymouth-label policykit-1 policykit-1-gnome systemd 
systemd-sysv xiccd
The following NEW packages will be installed:
  libelogind0
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
  init systemd-sysv (due to init)
0 upgraded, 1 newly installed, 15 to remove and 0 not upgraded.
Need to get 224 kB of archives.
After this operation, 20.1 MB disk space will be freed.
You are about to do something potentially harmful.
To continue type in the phrase 'Yes, do as I say!'
 ?] n
Abort.
test@DebianUnstable: ~test@DebianUnstable:~$ sudo apt-get install elogind
Reading package lists... Done
Building dependency tree...
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 elogind : Depends: libelogind0 (= 241.3-1+debian1) but it is not going to be 
installed
E: Unable to correct problems, you have held broken packages.

Bug#556893: #556893,say which 'defaults' are which better

[Jesse Smith]

This has been addressed upstream in insserv by allowing the program to
accept changes like this silently. All we need now is for update-rc.d to
be updated to use the new behaviour (enabled with the -q flag) and this
issue can be closed.

- Jesse

Bug#941319: debian-installer: Volume group 'LVM1' not found

[Heinrich Schuchardt]

The root of the problem is that the Debian installer does not install
package cryptsetup-initramfs.

Bug#941315: atomix: Please update to 3.34.0

[Markus Koschany]

Am 28.09.19 um 20:11 schrieb Jeremy Bicha:
> On Sat, Sep 28, 2019 at 1:58 PM Markus Koschany  wrote:
>> Am 28.09.19 um 16:47 schrieb Jeremy Bicha:
>>> Source: atomix
>>> Version: 3.32.1-1
>>> Severity: wishlist
>>>
>>> atomix 3.34.0 has been released. Please upload this version to Unstable.
>>>
>>> https://gitlab.gnome.org/GNOME/atomix/blob/master/NEWS
>>> https://gitlab.gnome.org/GNOME/atomix/commits/master
>>>
>>> Thanks,
>>> Jeremy Bicha
>>
>> They just bumped the version again without making a significant change
>> but I can update the package for the new watch file.
> 
> I haven't run the new version but the NEWS file does indicate there
> are some bug fixes (in 3.33.92) compared to 3.32.
> 
> Thanks,
> Jeremy

Nope.

https://salsa.debian.org/games-team/atomix/commit/e6c4b4a970f5bd4ea5dcf703952a57083424fbec

Usually the changes for atomix are rather small because the game is
feature complete and in some cases like this one, they just seem to keep
the versioning in sync with other GNOME projects.



signature.asc
Description: OpenPGP digital signature

Bug#934938: [cargo-docs] missing files

[Ximin Luo]

Oleg Kostyuchenko:
> Hi,
> 
> So you actually removed the cargo book from the package. I'd say that made 
> the package plain unusable.
> 
> If you are not able to ship the cargo book infrastructure now, why did you 
> remove the book from the package in the first place, instead of sticking with 
> the old working version?

I'm a volunteer with limited amounts of free time. The rust upstream project 
changed how they the structure docs in the rust source code package, and I 
didn't notice this. So Debian build scripts were still working according to the 
old structure.

I don't personally have time to fix this. If you want this to be fixed, either 
do it yourself or find someone else with time to fix it.

> 
> In addition, the users have a poor indication of what's currently happening 
> with the package. There is no "index.html" with a disclaimer "we cannot ship 
> cargo book anymore", or a relevant entry in the changelog, or anything.
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#941315: atomix: Please update to 3.34.0

[Jeremy Bicha]

On Sat, Sep 28, 2019 at 1:58 PM Markus Koschany  wrote:
> Am 28.09.19 um 16:47 schrieb Jeremy Bicha:
> > Source: atomix
> > Version: 3.32.1-1
> > Severity: wishlist
> >
> > atomix 3.34.0 has been released. Please upload this version to Unstable.
> >
> > https://gitlab.gnome.org/GNOME/atomix/blob/master/NEWS
> > https://gitlab.gnome.org/GNOME/atomix/commits/master
> >
> > Thanks,
> > Jeremy Bicha
>
> They just bumped the version again without making a significant change
> but I can update the package for the new watch file.

I haven't run the new version but the NEWS file does indicate there
are some bug fixes (in 3.33.92) compared to 3.32.

Thanks,
Jeremy

Bug#941315: atomix: Please update to 3.34.0

[Markus Koschany]

Am 28.09.19 um 16:47 schrieb Jeremy Bicha:
> Source: atomix
> Version: 3.32.1-1
> Severity: wishlist
> 
> atomix 3.34.0 has been released. Please upload this version to Unstable.
> 
> https://gitlab.gnome.org/GNOME/atomix/blob/master/NEWS
> https://gitlab.gnome.org/GNOME/atomix/commits/master
> 
> Thanks,
> Jeremy Bicha

They just bumped the version again without making a significant change
but I can update the package for the new watch file.

Regards,

Markus





signature.asc
Description: OpenPGP digital signature

Bug#941326: libterm-readline-gnu-perl: segfault with shadow_redisplay

[Jakub Wilk]

Package: libterm-readline-gnu-perl
Version: 1.36-2

This used to work in buster (and earlier), but now it crashes:

  $ perl test-shadow-redisplay
  Password: **Segmentation fault

Backtrace:

#0  0xf74d2eba in _rl_update_final () at ./display.c:2972
#1  0xf74da11d in rl_newline (count=1, key=13) at ./text.c:1105
#2  0xf74bb42d in _rl_dispatch_subseq (key=13, map=0xf74f96e0 
, got_subseq=0) at ./readline.c:852
#3  0xf74bb8a7 in _rl_dispatch (key=13, map=0xf74f96e0 ) 
at ./readline.c:798
#4  0xf74bb98c in readline_internal_char () at ./readline.c:632
#5  0xf74bc21d in readline_internal_charloop () at ./readline.c:659
#6  readline_internal () at ./readline.c:671
#7  readline (prompt=0x57399d80 "\001\033[4m\002Password: \001\033[24m\002") at 
./readline.c:377
#8  0xf75159ac in XS_Term__ReadLine__Gnu__XS_rl_readline (my_perl=0x57379160, 
cv=0x574a5388) at Gnu.xs:1813
#9  0x5669007c in Perl_pp_entersub (my_perl=0x57379160) at pp_hot.c:5232
#10 0x56686009 in Perl_runops_standard (my_perl=0x57379160) at run.c:42
#11 0x565fd911 in S_run_body (oldscope=, my_perl=) at perl.c:2694
#12 perl_run (my_perl=0x57379160) at perl.c:2617
#13 0x565d23f4 in main (argc=, argv=, env=) at perlmain.c:122


-- System Information:
Architecture: i386

Versions of packages libterm-readline-gnu-perl depends on:
ii  perl5.28.1-6
ii  libc6   2.29-2
ii  libreadline88.0-3
ii  libtinfo6   6.1+20190803-1

--
Jakub Wilk
#!/usr/bin/perl
use Term::ReadLine;
my $term = Term::ReadLine->new('');
my $attr = $term->Attribs;
$attr->{redisplay_function} = $attr->{shadow_redisplay};
my $passwd = $term->readline('Password: ');

Bug#930634: [Pkg-javascript-devel] Bug#930634: Build failures with rollup 0.56

[Pirate Praveen]

On Sat, Sep 28, 2019 at 16:12, Xavier  wrote:

help.pm is probably filtered. Overwrite in debian/nodejs/files


I think the root cause is incompatibility with rollup-plugin-string 
(they want 2.x and we already have 3.x).


I did some ugly hacks to move forward and now I get

$ rollup -c
/usr/share/nodejs/rollup/dist/rollup.js:6030
exports.__esModule = true;
  ^

TypeError: Cannot assign to read only property '__esModule' of object 
'#'
   at Object. 
(/usr/share/nodejs/rollup/dist/rollup.js:6030:20)

   at Module._compile (internal/modules/cjs/loader.js:778:30)
   at Object.Module._extensions..js 
(internal/modules/cjs/loader.js:789:10)

   at Module.load (internal/modules/cjs/loader.js:653:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
   at Function.Module._load (internal/modules/cjs/loader.js:585:3)
   at Module.require (internal/modules/cjs/loader.js:692:17)
   at require (internal/modules/cjs/helpers.js:25:18)
   at Object. 
(/usr/share/nodejs/rollup/bin/src/run/loadConfigFile.js:5:14)

   at Module._compile (internal/modules/cjs/loader.js:778:30)

Bug#941312: wmcliphist FTCBFS: uses the build architecture pkg-config

[Jeremy Sowden]

On 2019-09-28, at 13:04:54 +0200, Helmut Grohne wrote:
> wmcliphist fails to cross build from source, because the upstream
> Makefile hard codes the build architecture pkg-config. Please consider
> applying the attached patch to make it substitutable.

I've applied the patch, made a few other changes and pushed them to
Salsa.  Andreas, would you mind reviewing them when you have time?

Thanks,

J.


signature.asc
Description: PGP signature

Bug#922214: libpng12-0: libpng12.so.0 can not be installed, file or directory not found

[Bastian Germann]

You can use version 1.2.49-3 which is the last version that does not
add the conflicting symbolic links.

Bug#932379: Duplicate

[Bastian Germann]

This is a duplicate of #932112.

Bug#941035: closed by Kartik Mistry (Bug#941035: fixed in xdaliclock 2.44+debian-2)

[Helmut Grohne]

Control: reopen -1

On Tue, Sep 24, 2019 at 02:45:09PM +, Debian Bug Tracking System wrote:
>  + Added patch to fix FTBFS with cross compilation. Thanks to Helmut 
> Grohne.
>(Closes: #941035)

You applied the patch to configure.in, but failed to update configure.
The bug is still present there. Please regenerate configure at build
time (e.g. dh_autoreconf) or regenerate it at upload time.

Helmut

Bug#930890: [Pkg-electronics-devel] Bug#930890: Bug#930890: ghdl: Debian ghdl.wrapper prevents build when GHDL is not already installed.

[Jonathan McDowell]

On Sat, Sep 28, 2019 at 07:02:31AM +0200, Gianfranco Costamagna wrote:
> control: severity -1 serious
> control: found -1 0.35+git20181129+dfsg-3
> 
> I know this isn't the right bug, but since this bug is about a non-existing 
> version that FTBFS, lets recycle it :)

I think you wanted to alter #923190 instead, which is about adding LLVM
8 support.

J.

-- 
... 101 things you can't have too much of : 38 - clean underwear.

Bug#941325: libretro-bsnes-mercury FTCBFS: uses build architecture compiler via non-standard variable

[Helmut Grohne]

Source: libretro-bsnes-mercury
Version: 094+git20160126-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libretro-bsnes-mercury fails to cross build from source, because it uses
the build architecture compiler. While debhelper passes it as CXX,
libretro-bsnes-mercury expects it in compiler. Renaming the variable is
enough to make it cross build. Please consider applying the attached
patch.

Helmut
diff --minimal -Nru libretro-bsnes-mercury-094+git20160126/debian/changelog 
libretro-bsnes-mercury-094+git20160126/debian/changelog
--- libretro-bsnes-mercury-094+git20160126/debian/changelog 2019-02-04 
17:37:17.0 +0100
+++ libretro-bsnes-mercury-094+git20160126/debian/changelog 2019-09-28 
19:14:28.0 +0200
@@ -1,3 +1,10 @@
+libretro-bsnes-mercury (094+git20160126-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Rename CXX to compiler. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 28 Sep 2019 19:14:28 +0200
+
 libretro-bsnes-mercury (094+git20160126-2) unstable; urgency=medium
 
   * Team upload.
diff --minimal -Nru libretro-bsnes-mercury-094+git20160126/debian/rules 
libretro-bsnes-mercury-094+git20160126/debian/rules
--- libretro-bsnes-mercury-094+git20160126/debian/rules 2019-02-04 
17:35:00.0 +0100
+++ libretro-bsnes-mercury-094+git20160126/debian/rules 2019-09-28 
19:14:18.0 +0200
@@ -15,9 +15,9 @@
dh $@
 
 override_dh_auto_build:
-   dh_auto_build -- profile=accuracy ui=target-libretro $(ARM)
-   dh_auto_build -- profile=balanced ui=target-libretro $(ARM)
-   dh_auto_build -- profile=performance ui=target-libretro $(ARM)
+   dh_auto_build -- profile=accuracy ui=target-libretro compiler='$$(CXX)' 
$(ARM)
+   dh_auto_build -- profile=balanced ui=target-libretro compiler='$$(CXX)' 
$(ARM)
+   dh_auto_build -- profile=performance ui=target-libretro 
compiler='$$(CXX)' $(ARM)
 
 override_dh_auto_test:
 

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Sean Whitton]

Hello,

On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote:

> Reasonable. Then let's drop part about Depends:
>
>   [ ... All packages with daemons must provide init.d scripts ...],
>   unless software is only usable, by upstream's design, when
>   pid1 is provided by some other init system.

I think this would work.  What do you think, David?

Dmitry, perhaps you could work up a patch against policy.git.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941324: irism FTCBFS: upstream hard codes build architecture ld

[Helmut Grohne]

Source: irsim
Version: 9.7.101-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

irsim fails to cross build from source, because the upstream build
system hard codes the build architecture ld. It also correctly detects
the host architecture ld, but fails to use it in one occasion. The
attached patch fixes that. Please consider applying it.

Helmut
--- irsim-9.7.101.orig/scripts/defs.mak.in
+++ irsim-9.7.101/scripts/defs.mak.in
@@ -52,8 +52,8 @@
 CP = cp
 AR = ar
 ARFLAGS= crv
-LINK   = ld -r
 LD = @LD@
+LINK   = $(LD) -r
 M4		   = @M4@
 RANLIB = @RANLIB@
 SHDLIB_EXT = @SHDLIB_EXT@

Bug#940862: closed by Birger Schacht (Bug#940862: fixed in sway 1.2-1)

[Rob Browning]

"Debian Bug Tracking System"  writes:

> Source: sway
> Architecture: source
> Version: 1.2-1
> Distribution: experimental
> Urgency: medium
> Maintainer: Sway and related packages team 
> Changed-By: Birger Schacht 
> Closes: 940862
> Changes:
>  sway (1.2-1) experimental; urgency=medium
>  .
>* New upstream version (Closes: #940862)

Thanks much!
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#934938: [cargo-docs] missing files

[Oleg Kostyuchenko]

Hi,

So you actually removed the cargo book from the package. I'd say that made the 
package plain unusable.

If you are not able to ship the cargo book infrastructure now, why did you 
remove the book from the package in the first place, instead of sticking with 
the old working version?

In addition, the users have a poor indication of what's currently happening 
with the package. There is no "index.html" with a disclaimer "we cannot ship 
cargo book anymore", or a relevant entry in the changelog, or anything.

Bug#928473: [PATCH 2/2] Terminology: Change "rewind" to "rewrite" where appropriate

[Sean Whitton]

Hello,

Reviewed-by: Sean Whitton 

(or Acked-by if you prefer)

On Thu 05 Sep 2019 at 11:30AM +01, Ian Jackson wrote:

> Signed-off-by: Ian Jackson 
> ---
>  dgit| 2 +-
>  dgit.1  | 4 ++--
>  git-debrebase.1.pod | 3 ++-
>  infra/dgit-repos-server | 2 +-
>  4 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/dgit b/dgit
> index fde8d615..bd594c24 100755
> --- a/dgit
> +++ b/dgit
> @@ -4577,7 +4577,7 @@ END
>   " of the archive's version.\n".
>   "To overwrite the archive's contents,".
>   " pass --overwrite[=VERSION].\n".
> - "To rewind history, if permitted by the archive,".
> + "To rewrite history, if permitted by the archive,".
>   " use --deliberately-not-fast-forward.";
>   }
>  }
> diff --git a/dgit.1 b/dgit.1
> index 2c224294..29f7a22d 100644
> --- a/dgit.1
> +++ b/dgit.1
> @@ -791,7 +791,7 @@ The meanings of
>  understood in the context of Debian are discussed below:
>  .TP
>  .BR --deliberately-not-fast-forward
> -Declare that you are deliberately rewinding history.
> +Declare that you are deliberately rewriting history.
>  This could be because your branch is not fast forward from the
>  dgit server history,
>  or not fast forward from a locally-synthesised dsc import.
> @@ -823,7 +823,7 @@ never-accepted) versions in the git history of your 
> current push, were
>  rejected by ftpmaster for copyright or redistributability reasons.
>  .TP
>  .BR --deliberately-fresh-repo
> -Declare that you are deliberately rewinding history and want to
> +Declare that you are deliberately rewriting history and want to
>  throw away the existing repo.  Not relevant when pushing to Debian,
>  as the Debian server will do this automatically when necessary.
>  .TP
> diff --git a/git-debrebase.1.pod b/git-debrebase.1.pod
> index d1b4507f..bc1fdd64 100644
> --- a/git-debrebase.1.pod
> +++ b/git-debrebase.1.pod
> @@ -129,7 +129,8 @@ You should consider using B or B 
> instead.
>  =item git-debrebase scrap
>
>  Throws away all the work since the branch was last stitched.
> -This is done by rewinding you to ffq-prev.
> +This is done by resetting you to ffq-prev
> +and discarding all working tree changes.
>
>  If you are in the middle of a git-rebase, will abort that too.
>
> diff --git a/infra/dgit-repos-server b/infra/dgit-repos-server
> index f94315af..bbf1aa21 100755
> --- a/infra/dgit-repos-server
> +++ b/infra/dgit-repos-server
> @@ -784,7 +784,7 @@ sub checktagnoreplay () {
>  # current head for the suite (there must be at least one).
>  #
>  # This prevents any tag implying a NOFFCHECK push being
> -# replayed to rewind from a different head.
> +# replayed to overwrite a different head.
>  #
>  # The possibility of an earlier ff-only push being replayed is
>  # eliminated as follows: the tag from such a push would still

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941323: dgit(1): Improve description of --new, and be more encouraging

[Sean Whitton]

Package: dgit
Version: 9.9

Hello,

On Sat 28 Sep 2019 at 09:25AM -07, Sean Whitton wrote:

> [updating CC to point to the correct bug, not #928473]

Hmm, that bug is closed.

This patch hasn't made it to master and I think that it should.  So,
filing a new bug.

> Acked-by: / Reviewed-by: Sean Whitton 
>
> This is a nice change.
>
> On Thu 05 Sep 2019 at 02:57PM +01, Ian Jackson wrote:
>
>> Closes: #935443
>> Signed-off-by: Ian Jackson 
>> ---
>>  dgit.1 | 13 +
>>  1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/dgit.1 b/dgit.1
>> index 8969e2f2..c270b303 100644
>> --- a/dgit.1
>> +++ b/dgit.1
>> @@ -630,11 +630,16 @@ fails even on ignored untracked files.
>>  This could perhaps be used to detect bugs in your rules clean target.
>>  .TP
>>  .BR -N " | " --new
>> -The package is or may be new in this suite.  Without this, dgit will
>> +The package is, or may be, new in this suite.  Without this, dgit will
>>  refuse to push.
>> -It may (for Debian, will) be unable to access the git
>> -history for any packages which have been newly pushed and have not yet
>> -been published.
>> +Needing --new is not unusual; for example,
>> +it is frequently needed for uploading to Debian experimental.
>> +
>> +Note that dgit may be unable to access the git
>> +history for an entirely new package which has not been accepted by
>> +the archive.
>> +So for an entirely new package you need to properly coordinate
>> +with anyone else who might upload.
>>  .TP
>>  .BR --include-dirty
>>  Do not complain if the working tree does not match your git HEAD,

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928473: [PATCH 1/2] dgit(1): Cover more cases of --overwrite and --deliberately

[Sean Whitton]

Hello,

On Thu 05 Sep 2019 at 11:30AM +01, Ian Jackson wrote:

> +It can also be useful when an intermediate upload was not done with dgit.

It would be nicer to users not to use the terminology "intermediate
upload", but instead just describe such a thing.

It can also be useful when there was an upload made without dgit
since the most recent upload made with dgit.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#935443: Bug#928473: [PATCH] dgit(1): Improve description of --new, and be more encouraging

[Sean Whitton]

[updating CC to point to the correct bug, not #928473]

Acked-by: / Reviewed-by: Sean Whitton 

This is a nice change.

On Thu 05 Sep 2019 at 02:57PM +01, Ian Jackson wrote:

> Closes: #935443
> Signed-off-by: Ian Jackson 
> ---
>  dgit.1 | 13 +
>  1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/dgit.1 b/dgit.1
> index 8969e2f2..c270b303 100644
> --- a/dgit.1
> +++ b/dgit.1
> @@ -630,11 +630,16 @@ fails even on ignored untracked files.
>  This could perhaps be used to detect bugs in your rules clean target.
>  .TP
>  .BR -N " | " --new
> -The package is or may be new in this suite.  Without this, dgit will
> +The package is, or may be, new in this suite.  Without this, dgit will
>  refuse to push.
> -It may (for Debian, will) be unable to access the git
> -history for any packages which have been newly pushed and have not yet
> -been published.
> +Needing --new is not unusual; for example,
> +it is frequently needed for uploading to Debian experimental.
> +
> +Note that dgit may be unable to access the git
> +history for an entirely new package which has not been accepted by
> +the archive.
> +So for an entirely new package you need to properly coordinate
> +with anyone else who might upload.
>  .TP
>  .BR --include-dirty
>  Do not complain if the working tree does not match your git HEAD,

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#940590: git-debpush: error message unclear

[Sean Whitton]

Hello,

On Tue 17 Sep 2019 at 04:13PM +01, Ian Jackson wrote:

> Andrej Shadura writes ("Bug#940590: git-debpush: error message unclear"):
>> Package: git-debpush
>> Version: 9.9
>> Severity: minor
> ...
>> Sometimes git-debpush complains about things, and it’s not clear what
>> exactly it complains about.
>
> 11:33  I think it might be worth disabling those git
>  warnings

Agreed.

> 11:33  And maybe changing the wording of the check.
> 11:33  Eg it could say   git-debpush: check failed: blah blah
> 11:34  and then when it says "some check(s) failed" you'd be cued to
>recognise the two messages as going together, even in the
>presence of other noise

Agreed.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941322: runit: bring back test about forced-rescan feature

[Dmitry Bogatov]

Source: runit
Version: 2.1.2-35
Severity: normal

Dear Maintainer,

do not forget to debug properly #941273 and make sure, that
forced-rescan test works as expected on sbuild and salsa.


pgp83W469Oy8G.pgp
Description: PGP signature

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Dmitry Bogatov]

[2019-09-26 17:48] Ansgar 
> On Thu, 2019-09-26 at 15:26 +, Dmitry Bogatov wrote:
> > If this is the case, I'd propose wording like following:
> > 
> >   [ ... All packages with daemons must provide init.d scripts ...],
> >   unless software is only usable, by upstream's design, when pid1 is
> >   provided by some alternative init system. In such case, it must Depend
> >   on that alternative system (e.g binary package, that provides
> >   corresponding version of /sbin/init).
>
> Such a dependency shouldn't be added as one can run software in
> containers or so and talk to the outside systemd instance.  Note that
> iptables doesn't depend on the linux kernel package either.

Reasonable. Then let's drop part about Depends:

[ ... All packages with daemons must provide init.d scripts ...],
unless software is only usable, by upstream's design, when
pid1 is provided by some other init system.

> Also sysvinit would be an "alternative init system" given the current
> default.

As you wish. s/alternative/other/.
-- 
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.

Bug#940461: [PATCH v2] Add imap-dl, a simple imap downloader

[Sean Whitton]

Hello dkg,

On Tue 17 Sep 2019 at 09:31AM -04, Daniel Kahn Gillmor wrote:

> getmail upstream appears to have no plans to convert to python3 in the
> near future.
>
> Some of us use only a minimal subset of features of getmail, and it
> would be nice to have something simpler, with the main complexity
> offloaded to the modern python3 stdlib.

This is a cool idea.

I read through the script and I'm a bit apprehensive about the
complexity involved in talking to the IMAP server, because it renders
imap-dl significantly more complicated than anything else in
mailscripts:

> +# these objects are weirdly structured. i don't know why
> +# these trailing close-parens show up.  so this is very
> +# ad-hoc and nonsense

In general, it seems to me that mailscripts should fairly strongly
favour simplicity over features, so that the scripts in mailscripts can
be useful fixed points around which to build more complex (and perhaps
more fragile) systems.

Of course, imap-dl *is* simple in terms of its features, so I hope we
can mitigate the risks of this IMAP complexity somehow.

Would you consider writing an integration test suite for imap-dl?  I
would like it to be possible for us to be completely confident that
imap-dl won't ever lose any user messages.

> +=head1 DESCRIPTION
> +
> +If you use getmail to reach an IMAP server as though it was POP
> +(retrieving from the server, storing it in a maildir and optionally
> +deleting), you can point this script to the getmail config and it
> +should do the same thing.
> +
> +It tries to ensure that the configuration file is of the expected
> +type, and will terminate raising an exception, and it should not lose
> +messages.
> +
> +If there's any interest in supporting other use cases for getmail,
> +patches are welcome.

I'm not keen on introducing imap-dl as a getmail replacement.
Hopefully, in the future, the majority of imap-dl's users won't be
people who ever used getmail.  It would be good for the docs to
introduce imap-dl without reference to getmail, and then explain later
how it can be a getmail replacement.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941319: debian-installer: Volume group 'LVM1' not found

[Heinrich Schuchardt]

I retried with the guided partioning. Same result.

The generated initramfs does not contain dm-crypt.ko.

Bug#941321: anthy: adding entries to src-diclib/u2e.h

[Nobutaka Mantani]

Package: anthy
Version: 1:0.4-2
Severity: normal

anthy-0.4 fails to convert from "から" (kara) to "〜" (WAVE DASH)
and converted character becomes "〓" (GETA MARK).

The attached patch adds the following entries to the UTF-8 - EUC-JP
conversion table in src-diclib/u2e.h and it fixes the issue.

UnicodeUnicode   EUC-JP
U+301C WAVE DASH-> U+FF5E FULLWIDTH TILDE0xA1C1
U+2014 EM DASH  -> U+2015 HORIZONTAL BAR 0xA1BD
U+2016 DOUBLE VERTICAL LINE -> U+2225 PARALLEL TO0xA1C2
U+2212 MINUS SIGN   -> U+FF0D FULLWIDTH HYPHEN-MINUS 0xA1DD

Regards,

--
Nobutaka Mantani
nobut...@freebsd.org, nobut...@nobutaka.org
--- src-diclib/u2e.h.orig   2019-07-05 02:37:13 UTC
+++ src-diclib/u2e.h
@@ -55,7 +55,7 @@ static const int u2e_8[] = {0x0,0xa7a7,0x8fa7c2,0x8fa7
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0};
 static const int u2e_64[] = 
{0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
-0xa1be,0x0,0x0,0x0,0x0,0xa1bd,0x0,0x0,0xa1c6,0xa1c7,0x0,0x0,0xa1c8,0xa1c9,0x0,0x0,
+0xa1be,0x0,0x0,0x0,0xa1bd,0xa1bd,0xa1c2,0x0,0xa1c6,0xa1c7,0x0,0x0,0xa1c8,0xa1c9,0x0,0x0,
 0xa2f7,0xa2f8,0x0,0x0,0x0,0xa1c5,0xa1c4,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
 0xa2f3,0x0,0xa1ec,0xa1ed,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xa2a8,0x0,0x0,0x0,0x0,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
@@ -79,7 +79,7 @@ static const int u2e_67[] = {0x0,0x0,0x0,0x0,0x0,0x0,0
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0};
 static const int u2e_68[] = 
{0xa2cf,0x0,0xa2df,0xa2d0,0x0,0x0,0x0,0xa2e0,0xa2ba,0x0,0x0,0xa2bb,0x0,0x0,0x0,0x0,
-0x0,0xadf4,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xa2e5,0x0,0x0,0xa2e7,0xa1e7,0xadf8,
+0x0,0xadf4,0xa1dd,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xa2e5,0x0,0x0,0xa2e7,0xa1e7,0xadf8,
 
0xa2dc,0x0,0x0,0x0,0x0,0xa1c2,0x0,0xa2ca,0xa2cb,0xa2c1,0xa2c0,0xa2e9,0xa2ea,0x0,0xadf3,0x0,
 0x0,0x0,0x0,0x0,0xa1e8,0xa2e8,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xa2e6,0x0,0x0,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
@@ -135,7 +135,7 @@ static const int u2e_76[] = {0x0,0x0,0x0,0x0,0x0,0xa1f
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xa2f6,0x0,0x0,0xa2f5,0x0,0xa2f4,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0};
 static const int u2e_96[] = 
{0xa1a1,0xa1a2,0xa1a3,0xa1b7,0x0,0xa1b9,0xa1ba,0xa1bb,0xa1d2,0xa1d3,0xa1d4,0xa1d5,0xa1d6,0xa1d7,0xa1d8,0xa1d9,
-0xa1da,0xa1db,0xa2a9,0xa2ae,0xa1cc,0xa1cd,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0xade0,0x0,0xade1,
+0xa1da,0xa1db,0xa2a9,0xa2ae,0xa1cc,0xa1cd,0x0,0x0,0x0,0x0,0x0,0x0,0xa1c1,0xade0,0x0,0xade1,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
 0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,0x0,
 
0x0,0xa4a1,0xa4a2,0xa4a3,0xa4a4,0xa4a5,0xa4a6,0xa4a7,0xa4a8,0xa4a9,0xa4aa,0xa4ab,0xa4ac,0xa4ad,0xa4ae,0xa4af,

Bug#688481: [copyright-format] Clarify that trailing slashes in directory names are invalid.

[Sean Whitton]

Hello,

On Wed 21 Aug 2019 at 02:19PM +02, Nicolas Boulenguez wrote:

> @@ -659,6 +659,17 @@
>  Exclusions are only supported by adding Files
>  paragraphs to override the previous match.
>
> +  
> +This syntax does not distinguish file names from directory
> +names; a trailing slash in a pattern will never match any
> +actual path. A whole directory tree may be selected with a
> +pattern like "foo/*".
> +  
> +  
> +The space character, used to separate patterns, cannot be
> +escaped with a backslash. A path like "foo bar" may be
> +selected with a pattern like "foo?bar".
> +  
>  
>
>

Seconded.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941194: initscripts: remove some implementation details

[Sean Whitton]

Hello,

On Thu 26 Sep 2019 at 09:01AM +02, Ansgar Burchardt wrote:

> Control: reassign -1 debian-policy
>
> The section on initscripts has too much implementation details about
> /etc/rcn.d; these are better explained by external documentation.

Are you saying that they are *currently* better explained by actually
existing external documentation, or that it would be better to have them
explained by external documentation instead of the Policy Manual?  If
the former, could you point to that documentation, please?

> Also the rationale for why `DISABLED=yes` (or similar) fits better
> into a footnote than the main text (IMHO).

I'm inclined to agree with you, but since Russ is keen to reduce the
number of footnotes in Policy, it would be good to hear from him here.

> (Policy also should say something about LSB headers in "Writing the
> scripts", but that will be a different patch.)

That would be great.

Thank you for taking the time to work on the readability of Policy.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941320: stlink FTCBFS: skips stlink-gui when cross building

[Helmut Grohne]

Source: stlink
Version: 1.5.1+ds-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

stlink fails to cross build from source, because the upstream build
system decided that cross compiling shouldn't build the gui and the
packaging errors out about that. Cross building the gui just works once
you enable it. Checking for cross building is not a sane thing to do.
Maybe upstream wants a separate flag for inhibiting the gui. In the mean
time, please consider applying the attached patch.

Helmut
--- stlink-1.5.1+ds.orig/CMakeLists.txt
+++ stlink-1.5.1+ds/CMakeLists.txt
@@ -39,7 +39,7 @@
 # Dependencies
 ###
 find_package(LibUSB REQUIRED)
-if (NOT APPLE AND NOT WIN32 AND NOT CMAKE_CROSSCOMPILING)
+if (NOT APPLE AND NOT WIN32)
 	find_package(PkgConfig)
 	pkg_check_modules(gtk gtk+-3.0)
 endif ()

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Sean Whitton]

Hello,

On Wed 25 Sep 2019 at 02:33PM -04, David Steele wrote:

> On Wed, Sep 25, 2019 at 2:00 PM Ansgar  wrote:
>>
>> Well, the Policy Editors currently see no consensus; so to change it one
>> would need to convince them, involve the tech-ctte or a GR.
>>
>
> The Policy needs to either explicitly discourage the use of
> systemd-specific features, or recognize the sysv-init incompatibility of
> packages that use them,
>
> For my part, I have no interest in participating in the init wars. I just
> want clear guidance on how to avoid an AUTORM-level bug report.
> Right now the Policy is pretty much telling me to add an init script
> with calls to systemctl. I'd like a different answer.

I think we can achieve this.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941198: initscripts: packages should ship systemd units

[Sean Whitton]

Hello,

On Fri 27 Sep 2019 at 09:26AM +02, Ansgar wrote:

> Sean Whitton writes:
>>> +Packages that include system services should include ``systemd`` units
>>> +to start or stop services.
>>> +
>>>  Packages that include daemons for system services should place scripts
>>>  in ``/etc/init.d`` to start or stop services at boot time or during a
>>>  change of runlevel. These scripts should be named
>>
>> The text now has both "Packages that include system services ..." and
>> "Packages that include daemons for system services".  Do you take these
>> to refer to different things?  Surely we can combine the language somehow.
>
> No.  I just wanted to have a simple initial proposal to start with.

Okay.

I don't currently have any reason to doubt we have a project consensus
that systemd unit files should be included in packages in addition to
sysvinit scripts, so I hope we can make this change.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required

[Sean Whitton]

Hello,

On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote:

>> Candidate language attached. It adds "Also excepted are packages which 
>> require a
>> feature of an alternate init system which is not available in SysV-Style
>> init systems.". Thoughts?
>
> Imho, it opens loophole. Sysvinit does not provide equivalent of
> sd_notify("SD_READY=1"), so any service that links to libsystemd for
> that exactly call can be argued as "requiring feature [...] which is not
> available [...]".
>
> As real life example I recall Avahi-related bug (can't find number right
> now, sorry). Two inter-dependent services, where second fails to start
> unless first is already ready to listen.
>
> I'd argue this is bug in design, but if we consider design is written in
> stone, this is a bug in init.d script that must be worked around
> somehow.
>
> With your change in place, avahi maintainers would be able to drop
> sysvinit support instead of fixing init.d script.
>
> Very strong -1.

Okay, so what we want to express here is the idea that there is an
exception for a package which uses a feature of systemd, where something
equivalent cannot be achieved by using a sysvinit script?  Such as
something to access the systemd dbus interface.

I'm not sure how to express that right now, but I think it can be done.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#941319: debian-installer: Volume group 'LVM1' not found

[Heinrich Schuchardt]

Package: debian-installer
Version: 2019-09-23
Severity: important

Dear Maintainer,

I installed from debian-testing-amd64-netinst.iso (bullseye) dated
2019-09-23 on my NVME drive

partition 1: efi
partition 2: boot
partition 3: encrypted volume

On encrypted volume: logical volume group LVM1
volume 1: root
volume 2: swap
volume 3: home

Upon booting:

Volume group "LVM1" not found
Cannot process volume group LVM1

So I am left with an unusable system.

Best regards

Heinrich

Bug#917455: rpi key error

[Elan Ruusamäe]

the rpi key error is likely from this line:


```
root@acai /etc/apt# cat sources.list|grep rpi
deb http://raspbian.raspberrypi.org/raspbian/ buster main contrib 
non-free rpi
#deb-src http://raspbian.raspberrypi.org/raspbian/ buster main contrib 
non-free rpi


```

Bug#941318: alsamixergui: add a French comment on the desktop item file

[Olivier Humbert]

Package: alsamixergui
Version: 0.9.0rc2-1-10+b1

Dear debian maintainers,

Please, add the line:
Comment[fr]=Mélangeur/mixeur audio graphique
in the debian/alsamixergui desktop for the French locale users to get a 
comment in French when mouseovering in the menu.


HTH
Olivier

--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#941316: atomix; Update debian/watch

[Jeremy Bicha]

Source: atomix
Version: 3.32.1-1

Atomix is affiliated with GNOME. The GNOME Github mirror isn't the
authoritative source for atomix. Here's what the Debian GNOME team
uses for a watch file for many of its packages. This only watches for
stable releases like 3.32.* (odd number "minor" versions like 3.31.90
are development releases).


version=4
https://download.gnome.org/sources/@PACKAGE@/([\d\.]+[02468])/ \
@PACKAGE@@ANY_VERSION@\.tar\.xz


Thanks,
Jeremy Bicha

Bug#941317: Gdigi : making a new release?

[Olivier Humbert]

Package: gdigi
Version: 0.4.0-1+b2

Dear debian maintainers,

there are 23 new commits from this version, see 
https://github.com/desowin/gdigi/releases/tag/0.4.0
Some of those commits allows uses of more hardware which is great for 
users.


If upstream doesn't make a new release, what about making a 
"0.4.0+gitXXX" one ?


HTH
Olivier


--
Site web : https://librazik.tuxfamily.org/
Donation : https://liberapay.com/LibraZiK/
Diaspora : 
https://framasphere.org/people/8c184af0c9450134f6682a053625

Mastodon : https://mastodon.xyz/@LibraZiK

Bug#941314: m17n-db: EWTS table contains errors

[Norbert Preining]

Package: m17n-db
Version: 1.8.0-1
Severity: important

Dear all,

the EWTS table for Tibetan input contains two errors:
* The ligature "rn" gives an extra space when entered:
("rn" "རྣ ")
  should be
("rn" "རྣ")
* The ligature "ld" gives "sd" instead of "ld"
("ld" "སྡ")
  should be
("ld" "ལྡ")

I already reported this also upstream to m17n mailing list.

I attach a patch against current git repository that fixes these two
issues.

Best

Norbert


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

Kernel: Linux 5.3.1 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

m17n-db depends on no packages.

Versions of packages m17n-db recommends:
ii  libm17n-0  1.8.0-2

Versions of packages m17n-db suggests:
ii  gawk   1:4.2.1+dfsg-1.1
pn  m17n-docs  

-- no debconf information
diff --git a/debian/changelog b/debian/changelog
index 66e2e05..3d08eb9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+m17n-db (1.8.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix EWTS input table errors (extra space after rn, wrong ld)
+
+ -- Norbert Preining   Sat, 28 Sep 2019 23:42:19 +0900
+
 m17n-db (1.8.0-1) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/fix-ewts b/debian/patches/fix-ewts
new file mode 100644
index 000..11550c7
--- /dev/null
+++ b/debian/patches/fix-ewts
@@ -0,0 +1,24 @@
+---
+ MIM/bo-ewts.mim |4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- m17n-db.orig/MIM/bo-ewts.mim
 m17n-db/MIM/bo-ewts.mim
+@@ -94,7 +94,7 @@ If 0, generate only decomposed character
+   ("rny" "རྙ")
+   ("rt" "རྟ")
+   ("rd" "རྡ")
+-  ("rn" "རྣ ")
++  ("rn" "རྣ")
+   ("rb" "རྦ")
+   ("rm" "རྨ")
+   ("rts" "རྩ")
+@@ -105,7 +105,7 @@ If 0, generate only decomposed character
+   ("lc" "ལྕ")
+   ("lj" "ལྗ")
+   ("lt" "ལྟ")
+-  ("ld" "སྡ")
++  ("ld" "ལྡ")
+   ("lp" "ལྤ")
+   ("lb" "ལྦ")
+   ("lh" "ལྷ")
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..7f73ae5
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+fix-ewts

Bug#941315: atomix: Please update to 3.34.0

[Jeremy Bicha]

Source: atomix
Version: 3.32.1-1
Severity: wishlist

atomix 3.34.0 has been released. Please upload this version to Unstable.

https://gitlab.gnome.org/GNOME/atomix/blob/master/NEWS
https://gitlab.gnome.org/GNOME/atomix/commits/master

Thanks,
Jeremy Bicha

Bug#917455: rasbian

[Elan Ruusamäe]

i've also hit the problem on fresh install.

and the problem here was not because of permissions, but that database 
just does not exist.


and running update-command-not-found that the initial message suggests, 
does not work, because the script expects /var/lib/apt/lists/*Contents* 
to exist. which i did not


```

root@acai /etc/sudoers.d# getgid
Could not find the database of available applications, run 
update-command-not-found as root to fix this

Sorry, command-not-found has crashed! Please file a bug report at:
http://www.debian.org/Bugs/Reporting
Please include the following information with the report:

command-not-found version: 0.3
Python version: 3.7.3 final 0
Distributor ID:    Raspbian
Description:    Raspbian GNU/Linux 10 (buster)
Release:    10
Codename:    buster
Exception information:

local variable 'cnf' referenced before assignment
Traceback (most recent call last):
  File "/usr/share/command-not-found/CommandNotFound/util.py", line 23, 
in crash_guard

    callback()
  File "/usr/lib/command-not-found", line 93, in main
    if not cnf.advise(args[0], options.ignore_installed) and not 
options.no_failure_msg:

UnboundLocalError: local variable 'cnf' referenced before assignment

```


the command does absolutely nothing if apt db not present:


```

root@acai /etc/sudoers.d# update-command-not-found --verbose --debug

root@acai /etc/sudoers.d#

```


finally running apt update yields again error

```


root@acai /etc/sudoers.d# apt update
Get:3 http://archive.raspberrypi.org/debian buster InRelease [25.1 kB]
Get:4 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Get:5 http://raspbian.raspberrypi.org/raspbian buster/main armhf 
Packages [13.0 MB]
Get:6 http://archive.raspberrypi.org/debian buster/main armhf Packages 
[234 kB]
Get:7 http://archive.raspberrypi.org/debian buster/main armhf Contents 
(deb) [961 kB]
Get:8 http://raspbian.raspberrypi.org/raspbian buster/main armhf 
Contents (deb) [39.8 MB]
Get:9 http://raspbian.raspberrypi.org/raspbian buster/contrib armhf 
Contents (deb) [211 kB]
Get:10 http://raspbian.raspberrypi.org/raspbian buster/non-free armhf 
Contents (deb) [780 kB]
Get:11 http://raspbian.raspberrypi.org/raspbian buster/rpi armhf 
Contents (deb) [328 B]

Traceback (most recent call last):
  File "/usr/lib/cnf-update-db", line 26, in 
    col.create(db)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 94, in create

    self._fill_commands(con)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 132, in _fill_commands

    self._parse_single_contents_file(con, f, fp.stdout)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 271, in _parse_single_contents_file

    priority = component_priorities[component]
KeyError: 'rpi'
Reading package lists... Done
E: The repository 'http://glen.alkohol.ee/okas/dist ./ Release' does not 
have a Release file.
N: Updating from such a repository can't be done securely, and is 
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user 
configuration details.
E: Problem executing scripts APT::Update::Post-Invoke-Success 'if 
/usr/bin/test -w /var/lib/command-not-found/ -a -e 
/usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi'

E: Sub-process returned an error code

```


the command itself invoked gives:

```
root@acai /etc/sudoers.d# update-command-not-found --verbose
Traceback (most recent call last):
  File "/usr/sbin/update-command-not-found", line 26, in 
    col.create(db)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 94, in create

    self._fill_commands(con)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 132, in _fill_commands

    self._parse_single_contents_file(con, f, fp.stdout)
  File "/usr/share/command-not-found/CommandNotFound/db/creator.py", 
line 271, in _parse_single_contents_file

    priority = component_priorities[component]
KeyError: 'rpi'

```

Bug#933469: mrpt: Please rebuild against wxWidgets GTK 3 package

[José Luis Blanco-Claraco]

> I think the reason it doesn't show on the list on the front page of
> mentors.d.n is that only packages with "Yes" for "Needs a sponsor?"
> show up there.

Oops! So stupid... thanks!

I'll ask first to me usual uploader to check if he is still available
and wanting to upload this new version.

Thanks for all the help.

Cheers,
JL

Bug#941308: fetchmail: Fail to start with buffer overflow detected

[Christian Marillat]

On 28 sept. 2019 16:17, Matthias Andree  wrote:

> Control: tags -1 upstream fixed-upstream confirmed
> Control: severity -1 grave
>
> Christian, thanks for the report. It is a known issue that happens with
> fortifying compilers.
> Please use either the former rc3, rc4 or the upcoming 6.4.1. László
> (gcs@) is aware of it.

Thanks. I've already downgraded to rc4-2

Christian

Bug#814836:

[Albert Khanukaev]

Good day , my name is Albert Khanukaev , i sent you a mail and there
was no response , please confirm that you did get this mail for more
details.

Regards.

Albert Khanukaev

Bug#941308: fetchmail: Fail to start with buffer overflow detected

[Matthias Andree]

Control: tags -1 upstream fixed-upstream confirmed
Control: severity -1 grave

Christian, thanks for the report. It is a known issue that happens with
fortifying compilers.
Please use either the former rc3, rc4 or the upcoming 6.4.1. László
(gcs@) is aware of it.

Bug#941312: wmcliphist FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: wmcliphist
Version: 2.1-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

wmcliphist fails to cross build from source, because the upstream
Makefile hard codes the build architecture pkg-config. Please consider
applying the attached patch to make it substitutable.

Helmut
--- wmcliphist-2.1.orig/Makefile
+++ wmcliphist-2.1/Makefile
@@ -1,10 +1,11 @@
 srcCC ?= gcc
+PKG_CONFIG ?= pkg-config
 INSTALL = install
 PREFIX = /usr/local
 BINDIR = $(PREFIX)/bin
 DATADIR = $(PREFIX)/share/wmcliphist
 MAN1DIR = $(PREFIX)/share/man/man1
-INCLUDES = `pkg-config --cflags gtk+-3.0 x11`
+INCLUDES = `$(PKG_CONFIG) --cflags gtk+-3.0 x11`
 
 # for normal use
 CFLAGS += -Wall -ansi -pedantic $(INCLUDES) -DDATADIR=\"$(DATADIR)\"
@@ -16,7 +17,7 @@
 #CFLAGS += -Wall -g -ansi $(INCLUDES) -DFNCALL_DEBUG
 #DEBUG = debug.o
 
-LIBS = `pkg-config --libs gtk+-3.0 x11`
+LIBS = `$(PKG_CONFIG) --libs gtk+-3.0 x11`
 
 OBJECTS = wmcliphist.o clipboard.o gui.o rcconfig.o history.o hotkeys.o utils.o $(DEBUG)
 TARGET = wmcliphist

Bug#941313: windowlab FTCBFS: upstream Makefile hard codes the build architecture pkg-config

[Helmut Grohne]

Source: windowlab
Version: 1.40-3
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

windowlab fails to cross build from source, because it hard codes the
build architecture pkg-config. Please consider applying the attached
patch to make it substitutable.

Helmut
--- windowlab-1.40.orig/Makefile
+++ windowlab-1.40/Makefile
@@ -1,5 +1,7 @@
 # Makefile for WindowLab
 
+PKG_CONFIG ?= pkg-config
+
 # Comment out to remove shape support (for X11R5 or just a tiny bin)
 DEFINES += -DSHAPE
 EXTRA_LIBS += -lXext
@@ -35,8 +37,8 @@
 # Uncomment to add freetype support (requires XFree86 4.0.2 or later)
 # This needs -lXext above, even if you have disabled shape support
 DEFINES += -DXFT
-EXTRA_INC += `pkg-config --cflags xft`
-EXTRA_LIBS += `pkg-config --libs xft`
+EXTRA_INC += `$(PKG_CONFIG) --cflags xft`
+EXTRA_LIBS += `$(PKG_CONFIG) --libs xft`
 
 # Uncomment for debugging info (abandon all hope, ye who enter here)
 #DEFINES += -DDEBUG

Bug#930634: [Pkg-javascript-devel] Bug#930634: Build failures with rollup 0.56

[Xavier]

help.pm is probably filtered. Overwrite in debian/nodejs/files

Le 28 septembre 2019 15:53:02 GMT+02:00, Pirate Praveen 
 a écrit :
>On Sat, 28 Sep 2019 18:55:38 +0530 Pirate Praveen
> wrote:
>> Next error is,
>> 
>> src/node-entry.js → dist/rollup.js, dist/rollup.es.js...
>> [!] Error: Illegal reassignment to import 'commonjsHelpers'
>> ../../../../../../../usr/lib/nodejs/base/utils.js (5:0)
>> 3: var utils = require('lazy-cache')(require);
>> 4: var fn = require;
>> 5: require = utils; // eslint-disable-line
>>^
>> 6:
>> 7: /**
>
>Fixed by using node-snapdragon from experimental, which does not depend
>on node-base.
>
>Now rollup builds fine, but gives the following error when running,
>
>$ rollup --help
>internal/modules/cjs/loader.js:638
>throw err;
>^
>
>Error: Cannot find module 'help.md'
>at Function.Module._resolveFilename
>(internal/modules/cjs/loader.js:636:15)
>at Function.Module._load (internal/modules/cjs/loader.js:562:25)
>at Module.require (internal/modules/cjs/loader.js:692:17)
>at require (internal/modules/cjs/helpers.js:25:18)
>at Object. (/usr/share/nodejs/rollup/bin/rollup:6:17)
>at Module._compile (internal/modules/cjs/loader.js:778:30)
>at Object.Module._extensions..js
>(internal/modules/cjs/loader.js:789:10)
>at Module.load (internal/modules/cjs/loader.js:653:32)
>at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
>at Function.Module._load (internal/modules/cjs/loader.js:585:3)
>
>-- 
>Pkg-javascript-devel mailing list
>pkg-javascript-de...@alioth-lists.debian.net
>https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma 
brièveté.

Bug#941311: [zfs-linux]

[Antonio Russo]

Package: zfs-dkms
Version: 0.8.2-1
Severity: minor

--- Please enter the report below this line. ---

Upstream has identified a zpool warning issue [1], that can be mitigated
by reverting

25f06d677 Fix /etc/hostid on root pool deadlock

At a minimum this can serve as an alert for people running into this problem.

[1] https://github.com/zfsonlinux/zfs/issues/9367

Bug#930634: Build failures with rollup 0.56

[Pirate Praveen]

On Sat, 28 Sep 2019 18:55:38 +0530 Pirate Praveen
 wrote:
> Next error is,
> 
> src/node-entry.js → dist/rollup.js, dist/rollup.es.js...
> [!] Error: Illegal reassignment to import 'commonjsHelpers'
> ../../../../../../../usr/lib/nodejs/base/utils.js (5:0)
> 3: var utils = require('lazy-cache')(require);
> 4: var fn = require;
> 5: require = utils; // eslint-disable-line
>^
> 6:
> 7: /**

Fixed by using node-snapdragon from experimental, which does not depend
on node-base.

Now rollup builds fine, but gives the following error when running,

$ rollup --help
internal/modules/cjs/loader.js:638
throw err;
^

Error: Cannot find module 'help.md'
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:636:15)
at Function.Module._load (internal/modules/cjs/loader.js:562:25)
at Module.require (internal/modules/cjs/loader.js:692:17)
at require (internal/modules/cjs/helpers.js:25:18)
at Object. (/usr/share/nodejs/rollup/bin/rollup:6:17)
at Module._compile (internal/modules/cjs/loader.js:778:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
at Module.load (internal/modules/cjs/loader.js:653:32)
at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
at Function.Module._load (internal/modules/cjs/loader.js:585:3)

Bug#941310: xfce4: Some buttons do not work in XFCE4 with a touchscreen

[Sleipnir]

Package: xfce4
Version: 4.12.5
Severity: normal

Hello,

When using a touchscreen clicking on any button in the logout screen only
selects that button, nothing is executed.
Likewise touching a tab in Firefox has no effect.

Gnome is not affected by this problem.



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

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

Versions of packages xfce4 depends on:
ii  gtk2-engines-xfce3.2.0-4
ii  libxfce4ui-utils 4.12.1-3
ii  thunar   1.8.4-1
ii  xfce4-appfinder  4.12.0-2
ii  xfce4-panel  4.12.2-1
ii  xfce4-pulseaudio-plugin  0.4.1-1
ii  xfce4-session4.12.1-6
ii  xfce4-settings   4.12.4-1
ii  xfconf   4.12.1-1
ii  xfdesktop4   4.12.4-2
ii  xfwm44.12.5-1

Versions of packages xfce4 recommends:
ii  desktop-base  10.0.2
ii  tango-icon-theme  0.8.90-7
ii  thunar-volman 0.9.1-1
ii  xfce4-notifyd 0.4.3-1
ii  xorg  1:7.7+19

Versions of packages xfce4 suggests:
pn  gtk3-engines-xfce
ii  xfce4-goodies4.12.6
ii  xfce4-power-manager  1.6.1-1

-- no debconf information

Bug#941300: finish-install: write random seed to correct location for chosen init system

[Ben Hutchings]

On Sat, 2019-09-28 at 17:20 +0800, Paul Wise wrote:
> Package: finish-install
> Version: 2.56
> Severity: important
> Tags: security
> Control: found -1 2.81
> Control: found -1 2.100
> Control: found -1 2.101
> 
> finish-install creates a random seed in the location used by the
> urandom init script from the initscripts package. On systemd based
> systems, systemd-random-seed.service overrides the urandom init script
> but uses a different location for its random seed file. Consequently on
> first boot of systemd based systems there is no random seed file so the
> amount of entropy available is lower.
[...]

This should improve the randomness of /dev/urandom.  However, the last
time I checked, the systemd service does not change the kernel's
entropy accounting.  (And there was a small risk of using the seed
twice, which would need to be fixed before changing that.)  So this
does not help with the problem of slow boots due to the kernel not
accounting enough entropy.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.




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

Bug#930634: Build failures with rollup 0.56

[Pirate Praveen]

On Sat, 28 Sep 2019 13:53:42 +0530 Pirate Praveen
 wrote:
> On Sat, 28 Sep 2019 13:02:49 +0530 Pirate Praveen
>  wrote:
> > These errors are now fixed with help from Jishnu.
> 
> Now rollup -c brings this error,
> 
> 
> $ rollup -c
> 
> src/node-entry.ts → dist/rollup.js, dist/rollup.es.js...
> [!] (commonjs plugin) SyntaxError: Unexpected token (44:51) in
> /usr/share/nodejs/micromatch/index.js
> ../../usr/share/nodejs/micromatch/index.js (44:51)
> 42:
> 43:   for (let i = 0; i < patterns.length; i++) {
> 44: let isMatch = picomatch(String(patterns[i]), { ...options,
> onResult }, true);
>^
> 45: let negated = isMatch.state.negated || isMatch.state.negatedExtglob;
> 46: if (negated) negatives++;
> 
> 
> 

I was able to fix this by using
babel-plugin-transform-object-rest-spread, but I wonder why these are
present in these modules in the first place. Do debian's nodejs disable
these syntax?

Next error is,

src/node-entry.js → dist/rollup.js, dist/rollup.es.js...
[!] Error: Illegal reassignment to import 'commonjsHelpers'
../../../../../../../usr/lib/nodejs/base/utils.js (5:0)
3: var utils = require('lazy-cache')(require);
4: var fn = require;
5: require = utils; // eslint-disable-line
   ^
6:
7: /**

Bug#800038: ipmi-locate shouldn't probe legacy smbios address on ARM

[Fabio Fantoni]

Hi, in what version is solved? I did a fast search in git without find it.

Bug#941309: node-browserify-lite: unreproducible dependency map order

[Rebecca N. Palmer]

Package: node-browserify-lite
Version: 0.5.0-8
Control: tags -1 upstream patch
Control: affects -1 theano jssip libjs-webrtc-adapter
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain fileordering
X-Debbugs-Cc: reproducible-bui...@alioth-lists.debian.net

My #918631 patch didn't completely fix 
randomness_in_browserify_lite_output / 
nondeterminstic_output_from_uglifyjs (sorry): while it did fix the order 
in which the input files are numbered and output, it doesn't fix the 
order of the dependency map produced for each input file.

The below patch (which *replaces* the existing reproducibility patch)
attempts to fix this.

I think this is a file system ordering issue (rather than internal
(pseudo)randomness) as it previously didn't show up in testing multiple
builds from the same source tree, but this patch deliberately doesn't
assume this.

Testing done:
- theano (dagre-d3/graphviz-dot) - builds, appears functional in 
Firefox, code looks like it has sorted dependency maps
- node-debug, node-timers-browserify - builds, passes autopkgtests 
(these are already reproducible as they have <=1 entry in each map)

A proper reproducibility test was *not* done, as reprotest/disorderfs 
fails on my system (I apparently don't have a fuse group even though the 
fuse package is installed; I don't know why).

Description: Ease reproducible build

Sort module list and dependency lists in order to be reproducible

Author: Rebecca N. Palmer 
Forwarded: https://github.com/andrewrk/browserify-lite/issues/12

Index: node-browserify-lite/index.js
===
--- node-browserify-lite.orig/index.js
+++ node-browserify-lite/index.js
@@ -79,6 +79,8 @@ function renderBundle(options, cb) {
 
   function render(entrySourcePath, cb) {
 var modules = Object.keys(sources);
+// for reproducibility
+modules.sort();
 var aliases = {};
 modules.forEach(function(canonicalSourcePath, index) {
   aliases[canonicalSourcePath] = index;
@@ -116,7 +118,17 @@ function renderBundle(options, cb) {
 out += "module.exports = ";
   }
   out += sources[canonicalSourcePath];
-  out += "\n}, " + JSON.stringify(depMap[canonicalSourcePath]) + "],";
+  out += "\n}, {";
+  // for reproducibility, as JSON.stringify(depMap[canonicalSourcePath]) 
does not guarantee order - 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify
+  var depMapKeys = Object.keys(depMap[canonicalSourcePath]);
+  depMapKeys.sort();
+  depMapKeys.forEach(function(depPath, index) {
+  if (index != 0) {
+  out += ",\n"; // separate to not have a trailing comma
+  }
+  out += "\"" + depPath + "\": " + 
depMap[canonicalSourcePath][depPath];
+  });
+  out += "\n}],";
 });
 
 out += "}, {}, " + aliases[entrySourcePath] + ");\n";

Bug#941308: fetchmail: Fail to start with buffer overflow detected

[Christian Marillat]

Package: fetchmail
Version: 6.4.0-1
Severity: Serious

Dear Maintainer,

After upgrading from 6.4.0~rc4-2 to 6.4.0-1 fetchmail doesn't start

insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' 
overrides LSB defaults (0 1 6).
Job for fetchmail.service failed because the control process exited with error 
code.
See "systemctl status fetchmail.service" and "journalctl -xe" for details.
invoke-rc.d: initscript fetchmail, action "restart" failed.
● fetchmail.service - LSB: init-Script for system wide fetchmail daemon
   Loaded: loaded (/etc/init.d/fetchmail; generated)
   Active: failed (Result: exit-code) since Sat 2019-09-28 14:57:12 CEST; 6ms 
ago
 Docs: man:systemd-sysv-generator(8)
  Process: 9706 ExecStart=/etc/init.d/fetchmail start (code=exited, 
status=1/FAILURE)

sept. 28 14:57:12 christian.marillat.net systemd[1]: Starting LSB: init-Script 
for system wide fetchmail daemon...
sept. 28 14:57:12 christian.marillat.net fetchmail[9706]: Starting mail 
retriever agent: fetchmail*** buffer overflow detected ***: /usr/bin/fetchmail 
terminated
sept. 28 14:57:12 christian.marillat.net fetchmail[9706]: Aborted
sept. 28 14:57:12 christian.marillat.net fetchmail[9706]:  failed!
sept. 28 14:57:12 christian.marillat.net systemd[1]: fetchmail.service: Control 
process exited, code=exited, status=1/FAILURE
sept. 28 14:57:12 christian.marillat.net systemd[1]: fetchmail.service: Failed 
with result 'exit-code'.
sept. 28 14:57:12 christian.marillat.net systemd[1]: Failed to start LSB: 
init-Script for system wide fetchmail daemon.
dpkg: erreur de traitement du paquet fetchmail (--configure) :
 installed fetchmail package post-installation script subprocess returned error 
exit status 1

Christian

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

Kernel: Linux 4.19.75 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fetchmail depends on:
ii  adduser   3.118
ii  debianutils   4.9
ii  libc6 2.29-2
ii  libcom-err2   1.45.4-1
ii  libgssapi-krb5-2  1.17-6
ii  libkrb5-3 1.17-6
ii  libssl1.1 1.1.1d-1
ii  lsb-base  11.1.0

Versions of packages fetchmail recommends:
ii  ca-certificates  20190110

Versions of packages fetchmail suggests:
ii  exim4-daemon-heavy [mail-transport-agent]  4.92.2-3
pn  fetchmailconf  
pn  resolvconf 

-- Configuration Files:
/etc/default/fetchmail [Errno 13] Permission non accordée: 
'/etc/default/fetchmail'
/etc/ppp/ip-up.d/fetchmail changed [not included]

-- no debconf information

Bug#941305: Please activate Module jacoco-maven-plugin

[Emmanuel Bourg]

Contro: tags -1 + wontfix

Hi Mechtilde,

Le 28/09/2019 à 12:57, Mechtilde Stehmann a écrit :

> I want to build vinnie (ITP #939609) which is a dependency of JVerein
> (ITP 929477)
> 
> Therefore I nedd jacoco-maven-plugin.

No you don't need this plugin. Jacoco is a code coverage tool, you can
safely disable it to build JVerein.

Emmanuel Bourg

Bug#934038: ASSERT: "mImg == qImg->constBits()" in file common.cpp, line 63

[Fenix]

Package: kdenlive
Version: 19.08.1-2
Followup-For: Bug #934038

Dear Maintainer,

I'm be able to reproduce this error following the OP steps:

1.- Open Kdenlive.
2.- Add a title clip.
3.- Create a text label.
4.- Press OK

I get the same error and Kdenlive die.

I attach debug info and backtrace:

---
:~$ gdb kdenlive
GNU gdb (Debian 8.3-1) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from kdenlive...
Reading symbols from /usr/lib/debug/.build-
id/98/a3e4a1cb2ea19fe8b08e997af4a2532590b1fb.debug...
(gdb) run
Starting program: /usr/bin/kdenlive
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
[New Thread 0xabda0b40 (LWP 5927)]
[New Thread 0xaaba3b40 (LWP 5928)]
[New Thread 0xa9299b40 (LWP 5929)]
[New Thread 0xa88ffb40 (LWP 5930)]
[New Thread 0xa78ebb40 (LWP 5931)]
WARNING : Fails to parse  "avcolour_space"
WARNING : Fails to parse  "avcolor_space"
WARNING : Fails to parse  "avdeinterlace"
WARNING : Fails to parse  "swscale"
"avfilter.abench" is blacklisted
"avfilter.acompressor" is blacklisted
"avfilter.adelay" is blacklisted
"avfilter.aecho" is blacklisted
"avfilter.aemphasis" is blacklisted
"avfilter.aeval" is blacklisted
"avfilter.afade" is blacklisted
"avfilter.afftfilt" is blacklisted
"avfilter.agate" is blacklisted
"avfilter.ametadata" is blacklisted
"avfilter.arealtime" is blacklisted
"avfilter.ashowinfo" is blacklisted
"avfilter.channelmap" is blacklisted
"avfilter.chorus" is blacklisted
"avfilter.earwax" is blacklisted
"avfilter.volume" is blacklisted
"avfilter.volumedetect" is blacklisted
"avfilter.ass" is blacklisted
"avfilter.atadenoise" is blacklisted
"avfilter.avgblur" is blacklisted
"avfilter.bbox" is blacklisted
"avfilter.bench" is blacklisted
"avfilter.blackdetect" is blacklisted
"avfilter.blackframe" is blacklisted
"avfilter.boxblur" is blacklisted
"avfilter.bwdif" is blacklisted
"avfilter.chromakey" is blacklisted
"avfilter.colorkey" is blacklisted
"avfilter.colormatrix" is blacklisted
"avfilter.colorspace" is blacklisted
"avfilter.convolution" is blacklisted
"avfilter.crop" is blacklisted
"avfilter.cropdetect" is blacklisted
"avfilter.curves" is blacklisted
"avfilter.datascope" is blacklisted
"avfilter.dctdnoiz" is blacklisted
"avfilter.deband" is blacklisted
"avfilter.deflate" is blacklisted
"avfilter.deinterlace_vaapi" is blacklisted
"avfilter.deshake" is blacklisted
"avfilter.despill" is blacklisted
"avfilter.doubleweave" is blacklisted
"avfilter.drawbox" is blacklisted
"avfilter.drawgraph" is blacklisted
"avfilter.drawgrid" is blacklisted
"avfilter.drawtext" is blacklisted
"avfilter.elbg" is blacklisted
"avfilter.eq" is blacklisted
"avfilter.fade" is blacklisted
"avfilter.field" is blacklisted
"avfilter.fieldhint" is blacklisted
"avfilter.fieldorder" is blacklisted
"avfilter.find_rect" is blacklisted
"avfilter.floodfill" is blacklisted
"avfilter.fspp" is blacklisted
"avfilter.gblur" is blacklisted
"avfilter.geq" is blacklisted
"avfilter.hflip" is blacklisted
"avfilter.hqdn3d" is blacklisted
"avfilter.hqx" is blacklisted
"avfilter.hue" is blacklisted
"avfilter.hwdownload" is blacklisted
"avfilter.idet" is blacklisted
"avfilter.il" is blacklisted
"avfilter.lenscorrection" is blacklisted
"avfilter.loop" is blacklisted
"avfilter.lumakey" is blacklisted
"avfilter.lut" is blacklisted
"avfilter.lutrgb" is blacklisted
"avfilter.lutyuv" is blacklisted
"avfilter.mcdeint" is blacklisted
"avfilter.metadata" is blacklisted
"avfilter.negate" is blacklisted
"avfilter.nlmeans" is blacklisted
"avfilter.nnedi" is blacklisted
"avfilter.owdenoise" is blacklisted
"avfilter.pad" is blacklisted
"avfilter.perspective" is blacklisted
"avfilter.phase" is blacklisted
"avfilter.pixscope" is blacklisted
"avfilter.pp" is blacklisted
"avfilter.pp7" is blacklisted
"avfilter.prewitt" is blacklisted
"avfilter.realtime" is blacklisted
"avfilter.removegrain" is blacklisted
"avfilter.removelogo" is blacklisted
"avfilter.roberts" is blacklisted
"avfilter.rotate" is blacklisted
"avfilter.scale_vaapi" is blacklisted
"avfilter.showinfo" is blacklisted
"avfilter.shuffleframes" is blacklisted
"avfilter.sidedata" is blacklisted
"avfilter.signalstats" is blacklisted
"avfilter.sobel" is blacklisted
"avfilter.stereo3d" is blacklisted
"avfilter.super2xsai" is blacklisted
"avfilter.swapuv" is blacklisted

Bug#941185: hunspell: CVE-2019-16707

[Salvatore Bonaccorso]

Hi Rene,

On Sat, Sep 28, 2019 at 01:58:21PM +0200, Rene Engelhard wrote:
> forwarded 941185 https://github.com/hunspell/hunspell/issues/624
> thanks
> 
> Hi,
> 
> On Thu, Sep 26, 2019 at 06:37:42AM +0200, Salvatore Bonaccorso wrote:
> > CVE-2019-16707[0]:
> > | Hunspell 1.7.0 has an invalid read operation in
> > | SuggestMgr::leftcommonsubstring in suggestmgr.cxx.
> > [1] https://github.com/butterflyhack/hunspell-crash
> 
> Looks like https://github.com/hunspell/hunspell/issues/624

Ack, thank you for checking.

Regards,
Salvatore

Bug#941185: hunspell: CVE-2019-16707

[Rene Engelhard]

forwarded 941185 https://github.com/hunspell/hunspell/issues/624
thanks

Hi,

On Thu, Sep 26, 2019 at 06:37:42AM +0200, Salvatore Bonaccorso wrote:
> CVE-2019-16707[0]:
> | Hunspell 1.7.0 has an invalid read operation in
> | SuggestMgr::leftcommonsubstring in suggestmgr.cxx.
> [1] https://github.com/butterflyhack/hunspell-crash

Looks like https://github.com/hunspell/hunspell/issues/624

Regards,

Rene
> 

Bug#941277: dispatch function missing in header file generated for RPC service

[Simon Richter]

Hi,

On 27.09.19 22:30, Florian Weimer wrote:

> Ugh, can you describe exactly what is missing?  Then I can file it
> here (or just submit a patch):

If you compile a service description for the server side, e.g.

rpcgen -m /usr/include/rpcsvc/mount.x

you get the dispatch function that takes an incoming request and calls
the appropriate server function. For single-service programs, you would
normally generate the main function as well, using

rpcgen -s tcp /usr/include/rpcsvc/mount.x

This way, the dispatch function is adequately registered. If you need to
provide your own main function (i.e. the RPC service is part of a larger
program), you need to call svc_register yourself, so you need a
declaration of this function, for the mount service that would be

void mountprog_1(struct svc_req *rqstp, register SVCXPRT *transp);

That function is absent from the header generated using

rpcgen -h /usr/include/rpcsvc/mount.x

If you generate dispatch tables using -T, the table is declared in the
header, so I'd also expect the dispatch function to be declared.

   Simon



signature.asc
Description: OpenPGP digital signature

Bug#941241: firejail-profiles: Profile for ffplay makes it unusable -> 'Could not initialize SDL - No available video device'

[Reiner Herrmann]

Control: tags -1 + fixed-upstream

Hi Jan,

thanks for the report.
I was able to reproduce it and submitted your suggested changes
and some additional ones upstream [0].

Kind regards,
  Reiner

[0] https://github.com/netblue30/firejail/commit/6ba4db7


signature.asc
Description: PGP signature

Bug#941307: RFS: dmagnetic/0.17-1 -- Play classic textadventures from Magnetic Scrolls in glorious ANSI Art.

[dettus]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

* Package name : dmagnetic
Version : 0.17-1
Upstream Author : Thomas Dettbarn 
* URL : http://www.dettus.net/dMagnetic/
* License : BSD-2-Clause
* Vcs : http://www.github.com/dettus/ports_and_packages/Debian
Section : games

It builds those binary packages:

dmagnetic - Play classic textadventures from Magnetic Scrolls in 
glorious ANSI Art.


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


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

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

dget -x 
https://mentors.debian.net/debian/pool/main/d/dmagnetic/dmagnetic_0.17-1.dsc


Changes since the last upload:

* Update to release 0.17.
* Removed some warnings from the mentors.debian.net site.
* Changed the compat level to 12.

Regards,

Thomas Dettbarn


What I actually need is somebody to give my package the final boost, to
get it into the offical Debian Build System, and hopefully, into the debian
package repository. My project is an awesome interpreter for Magnetic
Scrolls textadventures. They used pretty beautiful graphics back then, and
I always wanted to play them when I was a child.

With my interpreter, it is possible to play them in any terminal window,
even over SSH or on UART terminals. The graphcis are being rendered in
glorious ANSI Art, or even ASCII Art, if preferred.

Just look at the screenshots on my website http://www.dettus.net/dMagnetic.
Or see for yourself:


Stone Bridge

XXXxxX@x#X$xxX@x@XXX
XXX**@x**@#**@x*#XXX
XXX***x***x*#XXX
XXX*#XXX
$@**x*+**x**=*#@@x**x@$$$#***x*+
*x*x***-*=++:..***x*=--+*+***::.-+*-*+**
***+=:=*-..xx***x***++=*+*-++==:==**
*+:+...**==*+*=--***+:+*.=**++=*
x*:-...*===*x=:=**=-***:+-+=-:**+=+*
***x***--..-*x*-xxx***:=*+*+=**:=+=+*--++==*
**x***x*-:.+**+:*++:**x*++==++*==+:-=++=++===-=-
=-:***=-***=+:-+=+**-:++::**+**:+*+:
+*=*=*-*+*=-*x+-++**=:=*+:++.+*+::-+++:+++*+
-**-+==+x**+-*+*+==-=:-++:+-*:-=--=*+=-=+==**=**
=++**+==*#+=xx*++=-===*##xx*+-::--+++-::=:-**-:=*+**+:**
+=*+++:-**+:=***+==++x#x*+==::-=--:-+::=-:::++*+--+*
***-**:.-=*++*xx+=*+===*x###x***=:-:-:=+***++:::-=**==**
+*-+**=--*xx*x***++-+=x##**+x=---:---+=-+=:--+==
++-.:+*+=:.+***+=++-**###x**++*--=:.:-==+++=+-+-
=+*##++-+++*##x++---.:-::-=+
xxx##xx++:*-++**++-==:+-:---=+**
x#xx**-=+:*=*##x*#++*:*=:--=+***
xx*+-=:=+:**x#x#x***++**#:==-*-:-=+*
*+-.+=:+x-*#x***+**##-*-:*::x::-
--:-++:+*+x##x***+++*+x+-=:-*::=
*+==:=+-=x=*###x##x**x#*-*--+.-*=::-
-:+-:=*-=*+*##x**+***#--=.-*=::+
-:+-:=x++#x#***x##+-*.-==.=+
-.--.:=--===+=-:*.:::.:*

You are  near the  edge of  a cliff.  To the  east, a stone
bridge spans a  deep ravine at  the bottom of  which runs  a
fast  flowing  river.  Westward  leads  onto  an extensive,
grassy plain.


> GO EAST


The same scene, but inverted:


Stone Bridge

...==.-==.:==.-=-...
...++-=++-=++-=+=...
...+++=+++=+=...
...+=...
:-*+=*x++=++x+=--=*+=-:::=***=*x**++
+=+=++*#*xxx$XX+++=+x#*+**#x+x+++$$X#x*#*x+*
++*xx$x*#XX==+++=+++xxx*x*#xx*+++xx$x***+x**
+x$xXXX+*xx*x*x##*++x$x*Xx+*xxx*
=*$#XXX+++**xxx+=x$x**x#***$x#xx#$**xxx*
+++=+++*++*##XX+++*#+=+#===+**$x*x*xx**$*##*
++=+++=+++**#$Xx++x$+xx$*+=+xx*xxx$#x#x#
+*+*x#$*++x#+**x*+++x$#xxx**#$xx$$**x**$x*x$
x*x**++*x*#+x+x#*=x#xx++x$x*x$xxXx*x$$#xxx$xxx+x
#**#xxxx=++x#*x*xxx#x$#xx$x#*$#x##x*xx#**x**
xxx**xxx+=++*+xx==+xxx#xxx+*x#$$##xxx#$$x$#**#$x*x**x$+*
xx*xxx$#*+++**x$x*++x===*xxx$$#x##$#x$$x#$$$xx*x##x*
*+*#**$X#x*xx*==xx*+=***x$#$#$xx***xx$$$#x**xx**
x*#x+*x##*==+=+**xx#xx===+*x=x###$###xx#xx$#+***#xxx
xx#X$x*xx$Xx***#++**xx+##x$X$#xxx#x#
xx*==+***xx#xxx*===xx###X$#$$#xx*+++

Bug#941306: LLVMExports.cmake references lit-cpuid that does not exist

[Roman Lebedev]

Package: llvm-9-dev
Version: 1:9-1
Severity: important
Tags: upstream

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Halide/build$ CC=clang-9 CXX=clang++-9 dpkg-depcheck -d cmake 
-DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_JOB_POOLS:STRING="link_pool=1" 
-DCMAKE_JOB_POOL_LINK:STRING="link_pool" -DLLVM_PATH=/usr/lib/llvm-9/ 
-DCMAKE_PREFIX_PATH=/usr/lib/llvm-9/ -DHALIDE_REQUIRE_LLVM_VERSION=90 ../
HALIDE_REQUIRE_LLVM_VERSION 90
Looking for LLVM version 9.0
CMake Error at /usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake:1326 (message):
  The imported target "lit-cpuid" references the file

 "/usr/lib/llvm-9/bin/lit-cpuid"

  but this file does not exist.  Possible reasons include:

  * The file was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and contained

 "/usr/lib/llvm-9/lib/cmake/llvm/LLVMExports.cmake"

  but not all the files it references.


According to https://packages.debian.org/sid/amd64/lldb-9/filelist
only the lldb-9 installs said binary.
I'm not sure what the proper solution here is, maybe lit-cpuid should be
put into llvm-tools package?

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

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

Versions of packages llvm-9-dev depends on:
ii  libc6  2.29-2
ii  libffi-dev 3.2.1-9
ii  libgcc11:9.2.1-8
ii  libllvm9   1:9-1
ii  libncurses-dev [libtinfo-dev]  6.1+20190803-1
ii  libstdc++6 9.2.1-8
ii  libtinfo-dev   6.1+20190803-1
ii  llvm-9 1:9-1
ii  llvm-9-tools   1:9-1

llvm-9-dev recommends no packages.

llvm-9-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAl2PQeQACgkQCDw+u0oW
ieCKXA/6AmhZsn5WyBCZ+xtbSEZ0unqTS/JIX1OzEDtxWjRV0C/jZaKbbKZA+ua4
+T8RAApQeuy6l7owpl7Q9Cv3VAvGP7TAiaBRWb5yjbKOH/WZjMlNFUVXDs2zQlb0
867ZenpURa6DQSvP5ffQynE4PBFdEXyELjEj7Tom70k6CNFAJDvRMsvVyB+eIYCp
HJY64GcuZ5OOdmyC27gcTtHPsm3DnpCnSOAq8g8xh0AwuJmqFqolkeuWjrhfVRv4
yNXaKIZyFOve2EjLR/hbfBmn4VLjGVczgjFU3jkqeU9W4nuqu8neLlO5IBbxGhiI
LKtm7QshbOeFWGcqwd9uJGv/7+Q4+QWBOoAJ+l+6riz9W5mOEo2l+JFywjhrYKU0
enfGxA6MmxqxuFt7qZnqHJadjazzF9q5bbxNnwe8bmflRG5eJ5JNKEiRYSF4+voo
ol3ckOmcSgP6s/XGc8FXNprnB/YdyifkPvUV3H+wNsRCmj3fCDzBuTngj5ZPF5jF
y4EATcqM0geILgEs99d05JM4MsSeB6i1nG43nkBZy6TCtb7TZBHoCb6wEhguzROc
jf4zQfdqFo1wfGy9IeYu4/fOBGropcY54I1rcOpqWTF8t3IVlDWAfebfwOSuNBex
b1cngmSUjF3HzhzXZawEJa/e2zHLPPKJvD+QrCqRFfYgGIr9EHk=
=hT1R
-END PGP SIGNATURE-